Does DORA for microenterprises mean a lighter load for small financial entities?
Yes, but only in specific places. Under DORA, a microenterprise is a financial entity, other than a trading venue, central counterparty, trade repository or central securities depository, that employs fewer than 10 persons and has an annual turnover and/or annual balance sheet total of no more than EUR 2 million (Article 3(60)). Microenterprises are relieved of the independent ICT risk control function, of internal audit of the ICT risk management framework, and of the testing programme duties in Article 24. They may also agree with a provider that the entity's access, inspection and audit rights are delegated to an independent third party appointed by that provider (Article 30(3)). Confirm the classification against both the headcount and the financial thresholds, because the test is applied to the entity itself and a firm near either limit should document how it reached its position.
The relief is not a blanket exemption. The ICT risk management framework must still exist, be documented and be reviewed at least once a year, with periodic review allowed for microenterprises and an additional review after major ICT-related incidents or supervisory findings (Article 6(5)). Incident handling and the reporting duties in Chapter III are not waived by the size test. Microenterprises must still run ICT testing, but Article 25(3) asks them to plan it on a risk basis, weighing resources and time against urgency, risk type and the criticality of assets and services. Redundancy of ICT capacity is assessed against the entity's own risk profile rather than mandated in the way Article 12(4) requires for larger entities.
The answer also depends on what else the firm is. A small investment firm, payment institution or occupational pension scheme may fall under the simplified regime in Article 16(1), which disapplies Articles 5 to 15 for that category, so the microenterprise relief is only one of several routes. Ask your competent authority how it reads the interaction between these provisions, and keep a written note of the classification decision. DeployOpen can prepare systems, configuration and evidence for the controls that remain, but the organization owns its controls, and only an independent auditor or the competent authority assesses whether they meet DORA.
Which DORA requirements are relaxed for microenterprises and which still apply
This table compares five DORA obligations against the relief available to microenterprises and what the entity must still do. Read each row as a pair: the relaxation sets the minimum, and the right-hand column shows the duty that survives. The main takeaway is that relief reduces who must run a function and how often certain steps happen, but it does not remove the need for a documented, risk-based ICT framework.
| Requirement | Relief for microenterprises | What still applies |
|---|---|---|
| Independent ICT risk control function and internal audit (Article 6(4) and (6)) | Microenterprises are relieved of the duty to maintain an independent ICT risk control function and internal audit of the framework. | The management body still owns the ICT risk management framework and must approve and oversee it, and risk checks must still be performed by someone. |
| Framework review frequency (Article 6(5)) | Review is periodic rather than annual for microenterprises. | The framework must be documented and reviewed after major ICT-related incidents and after supervisory instructions or test or audit conclusions. Confirm the chosen interval with your competent authority. |
| Testing programme duties (Article 24 and Article 25(3)) | Microenterprises are relieved of the Article 24 testing programme duties and may apply a risk-based approach. | Strategic planning of ICT testing is still required, balancing resources and time against urgency, type of risk and criticality of assets and services. |
| Redundant ICT capacity (Article 12(4)) | Microenterprises assess the need for redundant ICT capacity based on their own risk profile. | The assessment itself must be documented and justified. Entities other than microenterprises must maintain redundant capacity adequate for business needs. |
| Audit rights over ICT providers (Article 30(3)) | The entity and its provider may agree that access, inspection and audit rights are delegated to an independent third party appointed by the provider. | The contract must still give the entity a path to exercise audit rights, and the delegation must be agreed in writing. Confirm acceptable third-party arrangements with your supervisor. |
| Incident management, ICT risk identification and register of information | Not listed as relaxed in the supplied facts for this page. | Treat as applicable in full. Confirm any relief with your competent authority before relying on it. |
What the Article 16 simplified regime covers and who it reaches
Article 16 is a separate route from the microenterprise test. It switches off Articles 5 to 15 for five groups of smaller entities, but whether a given firm lands in one of them depends on its authorization type, its exemptions and what its member state has decided. The cards below set out each group and the checks that decide the outcome.
Small and non-interconnected investment firms
Article 16(1) disapplies Articles 5 to 15 for small and non-interconnected investment firms. Whether a firm qualifies depends on its size and on whether it is interconnected with other market participants, so the test is not the same as the microenterprise headcount and turnover thresholds. Confirm the firm's category under the investment firm rules and document why it is not interconnected. Articles 16 onward still apply in full to the firm's remaining duties.
Payment institutions exempted under PSD2
Payment institutions that benefit from an exemption under PSD2 fall within Article 16(1). The exemption is the trigger, so a firm that is a payment institution but does not hold a PSD2 exemption is not covered by this route. Check the exemption decision issued by the competent authority and keep a record of it, since the relief depends on that status rather than on the firm's size alone.
CRD-exempted institutions
Institutions exempted under the Capital Requirements Directive can fall under Article 16(1), but only where the member state has not excluded them under Article 2(4). This is the clearest case where national choice decides the outcome. Ask the national competent authority whether the member state has used the Article 2(4) option for the entity and record the answer in the compliance file before relying on the simplified regime.
Exempted electronic money institutions
Electronic money institutions that hold an exemption are within the scope of Article 16(1). Like payment institutions, the exemption status is what brings them in, so the firm should hold written confirmation of its exempt position. Electronic money institutions that do not hold an exemption follow the full DORA framework in Articles 5 to 15, and the difference between the two needs to be explicit in the firm's scope analysis.
Small occupational retirement provision institutions
Small institutions for occupational retirement provision are covered by Article 16(1). Whether a scheme is small enough is set by the rules that apply to the institution, and the member state's implementation can add conditions. Confirm the classification with the supervisor, and check whether any sectoral rules for pension schemes change the duties that remain after Articles 5 to 15 are disapplied.
Microenterprise test is separate
A firm can be a microenterprise under Article 3(60) without falling under Article 16, and the reverse is also possible. The microenterprise test relaxes specific duties, such as the independent control function and internal audit, while Article 16 disapplies whole chapters for a defined set of authorization types. Map each entity against both tests separately and record which relief applies, because the two routes can produce different duties for the same firm.
Microenterprise, Article 16 or full scope: how the decision changes the work
This tab covers a firm that meets the microenterprise definition in Article 3(60) but is not disapplied under Article 16. The firm still owns a documented ICT risk management framework and incident process, and the relief is narrower than many firms expect.
- Documents still needed: an ICT risk management framework, an ICT security policy, an incident management procedure and a register of information. Under Article 6(5), the framework must be reviewed periodically for microenterprises, after major ICT-related incidents and after supervisory instructions or testing findings.
- Testing expected: the formal testing programme duties of Article 24 are relieved, but Article 25(3) still requires a risk-based approach combined with strategic planning of ICT testing, weighed against urgency, risk type and the criticality of assets and services.
- Provider contract duties: the contract terms that Article 30 requires still apply. Under Article 30(3), the firm and its provider may agree that access, inspection and audit rights are delegated to an independent third party appointed by the provider, so confirm that the delegation is written into the contract.
- Ownership: the management body approves the framework. Because an independent ICT risk control function is not required, a named senior manager usually runs the framework and an outside reviewer or the management body provides challenge. Confirm who signs off each review.
Before relying on this tab, confirm that the firm's headcount and turnover or balance sheet totals still fall within the microenterprise thresholds, since changes can move the firm into a different regime.
This tab covers a firm that falls within the categories listed in Article 16(1). Those categories include small and non-interconnected investment firms, payment institutions exempted under PSD2, certain institutions exempted under the Capital Requirements Directive, exempted electronic money institutions and small institutions for occupational retirement provision. For these firms, Articles 5 to 15 are disapplied and the firm works to a simplified framework instead.
- Scope check: confirm which exemption applies. For CRD-exempted institutions, check whether the member state has excluded them under Article 2(4), because that decision determines whether Article 16 is available.
- Documents still needed: a simplified ICT risk management framework that is documented, approved by the management body and proportionate to the firm's activities. Ask the competent authority which documents it expects to see.
- Testing expected: do not assume that no testing applies. Plan ICT testing on a documented, risk-based footing and keep records of what was tested and what changed as a result.
- Provider contract duties: confirm with counsel which Article 30 requirements still apply to ICT services under the simplified regime, and record that position in the file. Contract terms with providers should be checked against that analysis.
- Ownership: the management body approves the simplified framework. An operations lead or the head of IT typically maintains it and evidences it. The Article 16 text on EUR-Lex is the starting point for the scope analysis.
Check the exemption in writing with the competent authority before adopting the simplified framework, because a firm that outgrows the exemption must move to the full regime.
This tab covers a firm that is neither a microenterprise under Article 3(60) nor disapplied under Article 16. Such a firm applies the full DORA regime, including Chapter II in full, the testing programme and the complete third-party contract duties. The work is larger, but the requirements are the same ones that govern the large entities in each sector.
- Documents still needed: the full set of framework documents, including the resilience strategy, the ICT risk assessment, the asset inventory, the continuity documentation and the register of information. The framework must be reviewed at least once a year and after major incidents.
- Testing expected: the testing programme required by Article 24 applies in full, including basic testing of ICT tools and systems. Threat-led penetration testing applies only if the firm is designated for it, and the conditions for that designation should be confirmed with the competent authority.
- Provider contract duties: the full Article 30 terms apply, and the firm keeps its own access, inspection and audit rights rather than delegating them to a third party. Confirm that each contract contains the required clauses before the service continues.
- Ownership: the management body is accountable for the framework. The ICT risk control function and internal audit must be independent of each other and of the operations they review, so assign them separately. Procurement signs contracts only after the control function has reviewed them.
- Redundancy: Article 12(4) requires redundant ICT capacities adequate for business needs, so the operations owner must document how those capacities are maintained and tested.
Record the scope decision in writing with the management body before choosing which tab's work applies, and revisit that decision whenever size or exemption status changes.
How a small firm plans DORA readiness from scoping to supervisory review
This sequence takes a small financial entity from confirming whether the microenterprise test and the Article 16 simplified regime apply, through to a documented framework, a risk-based testing plan, provider contracts and an evidence file that can be produced when the competent authority asks for it.
Confirm classification under Article 3(60) and Article 16
Test the entity against the microenterprise definition in Article 3(60): fewer than 10 persons, and annual turnover and/or annual balance sheet total of no more than EUR 2 million, excluding trading venues, central counterparties, trade repositories and central securities depositories. Then check whether the Article 16(1) disapplication applies to the entity's licence type and whether the member state has excluded it. Output: a signed classification memo stating which relief applies and the legal basis for each point. Sign-off: the management body, with the compliance lead preparing the analysis. Confirm the national competent authority's view where the licence category is unclear, and treat a borderline headcount or turnover figure as a question for counsel, not an assumption.
Inventory ICT systems and third-party services
List every ICT system, data store, network connection and ICT service the entity uses, including cloud services, outsourced administration and self-hosted open-source platforms run in the entity's own environment. Record the business function each supports and mark which ones are critical or important. Output: an asset and service inventory that feeds the risk assessment and the register of information. Sign-off: the head of IT or operations, reviewed by the risk owner. The inventory is complete when each entry has an owner, a function and a provider, and when a second person has checked it against invoices and access records.
Document the ICT risk framework and its review
Write the ICT risk management framework that matches the entity's size and risk profile, covering governance, identification, protection, detection, response, recovery and communication. Set the review rule under Article 6(5): a documented review at least periodically for a microenterprise, plus reviews after major ICT-related incidents and after supervisory instructions or testing or audit conclusions. Output: an approved framework document and a dated review log. Sign-off: the management body approves the framework. Keep the review log current so that a report on the most recent review can be produced on request.
Set a risk-based testing plan under Article 25(3)
Build a testing plan that reflects Article 25(3), which asks a microenterprise to combine a risk-based approach with strategic planning. Rank the systems in the inventory by criticality and by the risk they carry, then decide which tests, such as vulnerability scans, configuration reviews or penetration tests, cover each one and how often. Balance the time and resources available against urgency and the type of risk. Output: a written multi-year testing plan with a results log. Sign-off: the management body, with the security lead or external tester reviewing scope. Record why any system was tested less often, since that reasoning is what a supervisor will ask to see.
Align provider contracts and audit rights under Article 30(3)
Review each contract with an ICT provider that supports a critical or important function. Check that the contract covers service levels, data location, incident support, subcontracting, exit and termination. For a microenterprise, check whether the entity wants to rely on the derogation that lets its access, inspection and audit rights be delegated to an independent third party appointed by the provider, and document that agreement in writing. Output: a contract checklist and a signed amendment where needed. Sign-off: the management body or delegated officer, with legal counsel confirming the wording. Ask providers to confirm which audit reports or certifications they hold, and do not treat a provider's own report as proof that the contract terms have been met.
Assemble the evidence file for a supervisory request
Gather the signed classification memo, the inventory, the approved framework and review log, the testing plan and results, contract records, incident records and the register of information into one controlled file with an index. Check that each document is dated, approved and traceable to the requirement it supports. Output: an evidence index that a supervisor can navigate without help from the team. Sign-off: the compliance lead confirms completeness and the management body accepts the file. Run a short internal walkthrough so that the people who would answer questions know where each item sits.
Respond to supervisory review and close actions
When the national competent authority requests information or raises findings, answer from the evidence file and record each request, the response and the date it was sent. Where a finding requires a change, update the relevant framework, inventory, testing plan or contract, then repeat the review step so the change is documented under Article 6(5). Output: a request and response log with closed findings and updated documents. Sign-off: the management body approves material responses. Preparation support from an implementation partner can help assemble the file, but the entity remains responsible for its answers and the authority decides on compliance.
What a small firm must have in place before outside help is useful
A microenterprise or small entity can hand much of its DORA work to a partner, but only if the underlying records already exist and someone at the firm owns them. The six items below are the artifacts a partner needs to start from, and each one can be checked by the firm's own management before any engagement begins.
Current register of ICT assets
Start with a list of every system, device, application and data store the firm uses, including cloud services and software it runs itself. For each item, record the owner, the business function it supports and where it is hosted. Check the list by picking three systems at random and confirming they appear, with correct owners, and that nothing in daily use is missing. A partner can build this inventory with the firm, but the firm must confirm it reflects reality.
ICT risk framework with named ownership
A short, written ICT risk framework should state what the firm is protecting, the risks it accepts, and the controls it applies. Each part needs a named person who answers for it, and that person should be a member of the management body or report directly to it. Check that the document names owners by role and that the owner can explain the main risks without reading from the page. For a microenterprise, one page per risk area may be enough, but the ownership line must be explicit.
Incident handling procedure
The firm needs a written process that says how an ICT incident is detected, who is told, who decides whether it is major, and how the firm contacts its competent authority when reporting is required. Test the procedure with a tabletop walk-through using a plausible scenario, such as a ransomware alert on a laptop or a cloud account outage. Check that staff can name the first call they would make and that contact details are current. A partner can draft the procedure and run the exercise, but cannot confirm that the firm would follow it under pressure.
Provider inventory with contract terms
List every ICT third party that supports a function, with the service it provides, where data is held and whether the service is critical to operations. Next to each provider, record the contract terms that matter under DORA, including audit or access rights, notice periods and exit provisions. Check the list against invoices and signed agreements to find providers that were added informally. Where the firm relies on the delegated audit route in Article 30(3), the inventory should show which provider and which independent third party is involved.
Risk-based testing plan
A microenterprise must plan its ICT testing on a risk basis, balancing the time and resources it can spend against how urgent each risk is and how critical each asset is. The plan should list the systems to be tested, the type of test, the expected frequency and the person responsible for acting on findings. Check that the plan links to the asset register and that the last test results are on file. The plan is the firm's document, so a partner can propose a schedule but the firm must approve and follow it.
Dated framework review record
The ICT framework must be reviewed periodically for a microenterprise, and reviewed after major incidents or when supervisors or tests raise issues. Keep a dated log that records each review, who carried it out, what changed and which trigger prompted it. Check that the log has entries for the most recent incident or test and that a report on the latest review can be produced on request. Partners can prepare the review template and run the first review, but the dated record and management sign-off must come from the firm.
Who does what: your team, an implementation partner and the independent auditor
Under DORA, the financial entity remains accountable for its ICT risk, including where it relies on outside help. Even as a microenterprise, your organization owns the controls, approves the policies and decides which residual risk it accepts. The relief available to microenterprises changes how much you must document and test, not who answers for the outcome.
- Controls ownership: Operate and evidence the ICT controls that protect your services, including access management, backups and incident handling.
- Policy approval: Have the management body approve the ICT risk framework and the policies that sit under it.
- Framework review: Review and document the framework at the interval set for microenterprises, and after major ICT incidents or supervisory findings.
- Risk acceptance: Record which residual risks you accept, who signed off and when.
- Provider oversight: Keep your own due diligence and provider records, even where a partner performs the technical work.
Check that each named owner can explain their control in their own words and that someone internal can answer a supervisor's question without the partner present.
DeployOpen plans, implements, documents and prepares evidence for self-hosted open-source platforms inside your own infrastructure. The partner works under a written, fixed scope and prepares systems and evidence for your review. It does not set your risk appetite, approve your policies or sign your framework review, and it does not issue audit reports, attestations or certifications.
- Planning and design: Map the systems in scope, propose the controls and agree the deliverables in writing before work starts.
- Implementation and hardening: Configure, integrate and harden the platforms, including backup and recovery set-up.
- Documentation: Draft runbooks, configuration records and evidence packs for your team to review and approve.
- Testing where scoped: Run the security testing defined in the scope and hand findings to your team, which decides how to remediate them.
- Support after handover: Where you agree a retainer, cover upgrades, continuous testing and periodic refresh of evidence.
Ask the partner to list which documents it drafted, which you must approve and which the independent assessor will receive.
The independent assessor tests your controls and issues any report. DORA sets no certification scheme, so no DORA certificate is issued to your organization by a partner. Supervision comes from the national competent authority responsible for your type of financial entity under Article 46, which uses the powers in Article 50. For microenterprises, Article 30 allows the entity and its provider to agree that access, inspection and audit rights are delegated to an independent third party appointed by the provider.
- Independence boundary: The party that designs or implements a control should not be the party that assesses it.
- Competent authority: Supervises compliance, may request the framework review report and can require remediation.
- Article 26(7) attestation: The only authority-issued attestation DORA provides for, which concerns threat-led penetration testing. Confirm the process with your authority.
- Delegated audit rights: Confirm whether your provider agreement delegates audit rights to an independent third party, and who that party is.
- Assessor selection: Confirm the assessor's independence, its ICT audit competence and whether its output meets your supervisor's expectations.
Confirm in writing who will assess each control and who receives the output before the engagement starts.
How to choose an implementation partner or assessor for a small DORA scope
Small financial entities often buy help once and then live with the result for years, so the choice matters more than the size of the project suggests. The six checks below separate who builds the controls from who tests them, and they ask for the written terms that make a fixed-scope engagement easy to verify.
Experience with financial entities
Ask for examples of work done for regulated financial entities and for self-hosted open-source platforms, described without client names if confidentiality requires it. A partner that understands ICT risk management, incident logging and third-party contracts will map a small firm's obligations faster and with fewer gaps. Ask which DORA articles the partner has worked through in practice and how it handled a platform it had not deployed before.
Independence of the assessor
The firm that builds or configures the controls should not be the one that tests them and signs the conclusion. Confirm in writing whether the reviewer had any role in the implementation. Where a microenterprise delegates audit rights over a provider to an independent third party under Article 30(3), check that the appointed party has no commercial tie to that provider or to the entity's own implementation work.
Written fixed scope and deliverables
Most engagements for small entities should be fixed-scope, with the systems, policies, providers and deliverables listed before work starts. Ask for a written statement of what is excluded, such as ICT services supplied by group companies or cloud accounts the firm does not control. Acceptance should depend on the listed deliverables, not on a general statement that the entity is compliant.
Evidence produced and its ownership
Ask which artifacts will be delivered, such as the documented framework, the review record required once a year, asset inventories, backup test results and change logs. Confirm that the entity holds the copies, in its own repositories and in formats it can give to its competent authority on request. Evidence that sits only in a partner's ticketing system becomes a problem at the next supervisory request or at contract end.
Supervisor expectations and proportionality
Small entities are supervised by their national competent authority, so the partner should be able to explain how that authority applies proportionality in practice. Ask the partner to name the supervisor's published guidance it relies on and which expectations it will not assume. The partner does not decide what the supervisor accepts, so confirm the supervisor's position directly or through the entity's own compliance function.
One-off readiness versus retainers
Readiness work is a bounded project, while retainers cover upgrades, periodic review, testing and support over time. Ask for the two to be quoted separately, with the recurring items named, such as the annual framework review and patch cycles. The entity should understand what it still needs to staff internally after the project closes, and what it would pay for each year if it keeps a partner.
Questions small financial entities ask before hiring help
Does a microenterprise need an internal audit function under DORA?
No. Microenterprises are relieved of the internal audit of the ICT risk management framework, so an internal audit function is not a DORA requirement for a firm in that category. The relief does not remove the duty to keep the framework documented and reviewed. Under Article 6(5), a microenterprise reviews its framework periodically rather than on the annual cycle that applies to other entities, and it must still act after major ICT-related incidents and after supervisory instructions. Management remains accountable for the framework, so a named senior person should own the review and sign it off. If the firm later exceeds the microenterprise definition, the internal audit duty applies. Confirm with your competent authority how it expects the review to be evidenced, and whether it expects any independent check.
Can a small financial firm do its DORA work in-house?
Often yes for parts of the work, but the answer depends on the firm's skills, its providers and what its competent authority expects. The core duties sit with management: the management body must approve the framework, understand ICT risk and keep the documents current. Routine tasks such as maintaining an asset list, keeping backup and patch records, and logging access can be run internally if someone owns each one. Tasks that usually need outside help include the gap analysis against the technical standards, contract review for ICT providers, testing design and the register of information. Be honest about capacity. A person who runs the systems may still lack the time to write the evidence. Ask any partner to show which parts they will hand over and which the firm must keep.
What does DORA compliance cost for a microenterprise?
This page does not state a price, because cost depends on the firm's systems, providers and chosen scope. Four components drive it: internal staff time, outside advice, tooling, and the work needed on provider contracts. One-time costs include the initial scoping, the gap analysis, drafting the policies and updating contracts with ICT providers. Recurring costs include the periodic framework review, patching, backups, incident drills and any retained support. Costs rise with the number of ICT services, the number of providers, how critical the functions are, and how much the firm runs itself rather than buying as a service. Ask any advisor for a written, fixed-scope quote that lists deliverables, what the firm must provide, and what is excluded. DeployOpen agrees scope and deliverables in writing before work starts and does not publish a price list, so its quote follows from that scope.
How long does DORA preparation take for a small firm?
The duration depends on the firm's starting position, so ask for a timeline tied to milestones rather than a single number. The main drivers are how much of the ICT estate is already documented, how many ICT providers need contract changes, whether the firm runs its own systems, and how much staff time is available. Work usually runs in sequence: scoping and classification, gap analysis, documentation, provider contracts, then testing and review. Contract negotiation with providers is often the slowest step because it depends on parties outside the firm. Ask for a plan that names each dependency on the firm and on its providers, and confirm the date your competent authority expects evidence to be available.
What does DORA ask of management in a small firm?
Management carries responsibility for the ICT risk framework even when the firm is small. In practice, the management body approves the framework and its core documents, sets the firm's tolerance for ICT risk, and oversees the periodic review and its findings. It also needs to assign a clear owner for ICT risk and for incident handling, and to make sure staff receive suitable training. Time is the practical constraint. A director who signs documents without reading them leaves a weak record that a supervisor will question. Set a review calendar, name a responsible person, and keep minutes that show decisions and the information behind them. Ask any advisor to provide short briefing material that management can read in one or two sessions.
Does a microenterprise still have to report ICT incidents?
Assume yes until your competent authority confirms otherwise. The microenterprise relief covered in this topic concerns framework governance, the independent control function, internal audit, the testing programme and delegated audit rights. It does not, on the provisions covered here, remove the incident management and reporting regime in Chapter III. Read the incident articles directly and check the authority's guidance on how reports should be made. Build the basics before an incident occurs: a written procedure for detecting, classifying and escalating incidents, named contacts, a log of every incident, and a tested route to the authority that works within the required deadlines. Incident handling is far easier to run from a prepared process than to design under pressure.
When should a small firm revisit its microenterprise classification?
Review the classification at each periodic framework review and whenever headcount or financial figures could move the firm across the threshold. DORA defines a microenterprise as a financial entity that employs fewer than 10 persons and has an annual turnover and/or annual balance sheet total of no more than EUR 2 million. The test uses the figures, not the firm's intentions, so a strong growth year, an acquisition or a large new contract can change its status. Other triggers include hiring, a merger, a change in the type of entity, or year-end accounts that differ from the forecast. If the firm falls outside the definition, the relief ends and the full set of duties applies. Record each year's test with the figures used and the date, so the decision can be shown to a supervisor.
How DeployOpen scopes and prepares DORA evidence for small firms
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For microenterprises and small financial entities, that work is shaped around the relief DORA provides, and DeployOpen prepares systems and evidence while the organization keeps ownership of its controls.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which DORA relief the entity relies on, such as the Article 6 and Article 25 provisions for microenterprises.
- Scope also names the platforms, providers and evidence items covered, so the entity knows exactly what is delivered and what it still owns.
How we build
- Systems are deployed in the client's own cloud accounts, data centers or air-gapped networks, with logging and access records kept from the start.
- Security testing is planned on a risk-based basis, matching the proportionate testing approach the Regulation allows for smaller entities.
- Configuration, backup and recovery steps are documented so the entity can show how its ICT systems are run and restored.
How we hand over
- Deliverables include the policies, asset inventory and review records the entity chooses to keep, mapped to the DORA articles it relies on.
- Handover covers runbooks and evidence folders so the entity's own staff or management body can review and sign off the documentation.
- Where a provider's audit rights are delegated to an independent third party, the written arrangement is documented as part of the handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
- Framework reviews after major ICT incidents or supervisory feedback can be supported on request, with the review record kept by the entity.
- Confirm with DeployOpen in the quote which support tasks, and which competent authority or auditor questions, sit inside the retainer.
