DORA resilience testing for microenterprises: what applies

Does DORA resilience testing for microenterprises cost less and take less time?

Microenterprises apply a risk-based testing plan under Article 25(3), balancing the time and resources they put into ICT testing against urgency, type of risk and the criticality of their assets and services. Entities under the simplified regime keep an ICT security testing plan under Article 36 of Delegated Regulation (EU) 2024/1774, and both groups must test backup and restore procedures at least once a year or after a major change to the continuity plan. Neither group is subject to threat-led penetration testing. Lighter obligations mean a lighter workload, but they do not mean a fixed price or a fixed number of weeks, so the honest answer depends on the entity's own environment.

The effort and cost are driven by three things: how many systems support critical or important functions, how many ICT third parties sit inside those systems, and how mature the entity's evidence already is. An entity with a current asset inventory, documented access controls and recent restore records has far less to build than one starting from scratch. Ask any provider or consultant to price the work against a written scope that lists each system, each third party, the test types and the evidence to be produced. Confirm whether the quote covers retesting after findings are fixed and whether the backup and restore test is included each year or only once.

The entity owns its tests, their scope and every decision taken on their results. An implementation partner can prepare test environments, backup records and evidence files, but only an independent tester or assessor issues a test report, and DORA does not give any authority a certification for these tests. Keep the roles separate in the contract so the board can see who is responsible for each deliverable. Confirm with your competent authority how it expects simplified-regime evidence to be presented, since supervision practice and reporting formats are set nationally.

What each regime requires for testing

Microenterprises carry the lightest testing duty in DORA. Article 25(3) asks them to combine a risk-based approach with strategic planning of ICT testing. The planning must balance the resources and time you allocate against the urgency and type of risk you face and the criticality of your assets and services. The Regulation does not fix a test frequency for this group, so the justification for what you test, when and why becomes the core evidence.

Duty: a risk-based approach with strategic planning of ICT testing under Article 25(3).
Review trigger: the plan should be revisited as your risk profile, critical assets or services change, so ask how your own review cycle is defined.
Evidence: a written rationale linking each test to a risk, asset or service, plus records of what was tested and what changed afterwards.
TLPT: threat-led penetration testing under Article 26(1) does not apply to entities listed in Article 16(1).
Illustrative example: a microenterprise with one customer portal may decide that internet-facing systems are tested each year, while internal tools are tested after significant changes.

Confirm with your competent authority how it expects the justification to be documented before relying on a verbal or informal plan.

How a smaller entity builds its testing plan and runs the yearly restore test

This sequence takes a microenterprise or simplified-regime entity from confirming its status to a first test cycle that produces a scoped testing plan, test records, a restore test report and evidence the competent authority can review.

Confirm regime and scope
Start by confirming which regime applies: whether the entity is a microenterprise under Article 25(3) of DORA, or a simplified-regime entity that follows the simplified framework in Delegated Regulation (EU) 2024/1774. The entity's management body owns this decision, and the outcome determines which testing obligations apply. Record the legal basis, the supervisor and the list of ICT systems and services in scope. The output is a scoped statement signed off by the management body. Ask any implementation partner to confirm the regime test in writing before any tooling or testing work begins.
Inventory critical systems and internet-exposed services
Build a list of ICT systems that support critical or important functions, along with every service reachable from the internet, such as web portals, remote access gateways, email and API endpoints. For each item, note its owner, its data, its hosting location and its dependencies on external ICT providers. Where the entity runs self-hosted open-source platforms, include the host, container and database layers as well. The output is an inventory that ties each system to its risk rating. Confirm the inventory with the people who operate the systems, since gaps here weaken every later test.
Set the testing plan and its review cycle
Write the ICT security testing plan that the simplified regime requires under Article 36 of Delegated Regulation (EU) 2024/1774. It should describe how the entity validates access control, operations, data and network security, and development and change measures, and it should explain how the plan is reviewed against the entity's risk profile. For microenterprises, the same content appears as a strategic testing plan that balances resources, time, urgency and asset criticality. The output is an approved plan with a named owner and a stated review trigger. Ask for the review cycle to be fixed in writing.
Schedule security tests and the backup and restore test
Map each planned test to a system on the inventory and set a date for it. Security tests should cover the internet-exposed services and the systems that support critical or important functions. Separately, schedule the business continuity test that covers backup and restore procedures, which Article 40 of Delegated Regulation (EU) 2024/1774 requires at least once every year or after every major change to the plan. Assign a tester, confirm that the tester is independent of the people who run the system, and agree the scope in writing. The output is a test calendar with named owners.
Run the tests and record results
Execute each test against the agreed scope and record what was tested, when, by whom, the method used, the findings and their severity. For the restore test, record the backup set restored, the target environment, the time taken to recover to a usable state, the data integrity checks performed and any step that failed. Keep raw tool output with the summary. The output is a dated test record for each test and a restore test report signed by the person responsible for continuity. Ask the tester to state its method and tool versions so the record can be reproduced.
Update measures from the results
Turn each finding into a corrective action with an owner, a priority and a closure check. For critical systems, Article 36 of Delegated Regulation (EU) 2024/1774 requires measures to be updated promptly after test results, so the entity should record when each change was made and who verified it. Where a restore test failed or ran beyond what the continuity plan allows, update the plan itself and note the change. The output is an updated measures register linked to each test record. Retesting the changed control confirms the fix worked.
Retain evidence for the competent authority
Assemble a single evidence file for the cycle: the signed scope, the inventory, the approved testing plan with its review history, the test calendar, the test records, the restore test report and the updated measures register. Store it where the entity can produce it on request from its competent authority, and set a retention period that its own legal advice confirms. Ask any implementation partner to hand over the file in an editable format so the entity owns its evidence. The output is a complete, dated cycle file that starts the next review.

Who gets paid for DORA testing at a smaller entity

This table lists each cost component of DORA testing at a microenterprise or simplified-regime entity, who is paid for it, whether it is one-time or recurring, and what moves it up or down. No figures were available for this page, so use the components to build a written scope and quote. The main takeaway is that the largest recurring cost is usually internal time and the yearly restore test, not a one-off engagement.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Internal staff time for owning the testing plan	Your own employees (salary cost, not a fee)	Recurring	Size of the ICT estate, number of critical systems, and how often the plan is reviewed against risk changes
Security or penetration tester	External tester or internal security staff, paid per engagement or by salary	Recurring, at the frequency your risk profile sets	Number and exposure of internet-facing systems, scope of applications and APIs, and whether results must be retested
Implementation partner for backup and restore setup	Implementation partner under a fixed-scope written agreement	One-time setup, with occasional rework after major changes	Number of systems in scope, complexity of backup architecture, and whether hosting is in your own infrastructure
Implementation partner for evidence preparation	Implementation partner or your compliance lead	Recurring, aligned to each test cycle	How well test records are kept during testing, and whether logs and reports are generated automatically
Tooling and hosting	Software vendors, cloud or data center providers, and open-source support contracts if bought	Mostly recurring (licences, hosting, storage for backups)	Backup volume and retention period, number of environments, and whether open-source tools are self-hosted
External restore test	Independent tester or your own team, depending on your choice	Recurring, at least once a year under the simplified regime	Size of data sets restored, number of procedures tested, and whether the test is witnessed or documented by a third party
Authority or assessor role	Competent authority supervises at no fee to you; an independent assessor is optional and paid by you	Occasional, only if you engage an assessor	Whether you commission a voluntary review; DORA sets no certification scheme for testing

What makes DORA testing more expensive or longer for smaller entities

For a microenterprise or simplified-regime entity, the size of the testing bill follows from a few choices made early: how many systems sit in scope, how exposed they are, and who else's testing you depend on. Each driver below can be narrowed or reused with documented decisions.

Systems supporting important functions

The more systems your documented risk assessment places in scope, the more tests you run and the more evidence you collect. Under the simplified regime, the ICT security testing plan must validate access control, operations, data and network security, and development and change measures across the systems you rely on. Ask whether each system is needed for a critical or important function, or whether it only supports internal convenience. Record the reasoning in the risk assessment so an assessor can follow it.

Internet-exposed services

Every service reachable from the internet adds external attack surface, and testing it usually takes more time than testing internal systems. Review what is published by your DNS records, cloud load balancers, and remote access tools, and separate services customers use from administrative interfaces. Retiring unused endpoints before the test window shrinks the scope and the number of findings you must track to closure.

ICT provider dependencies and shared testing

Testing gets longer when your platforms depend on providers who must cooperate in scenario tests or who need to confirm their own vulnerability handling. Check which providers host or operate systems in scope, and whether they already give you test reports or can take part in pooled or group tests with other customers. Confirm these terms in contracts before the test calendar is set, because a provider that cannot schedule access can delay the whole programme.

Maturity of backup and restore records

Yearly backup and restore testing is only as quick as the records behind it. If restore procedures are undocumented, backup logs are incomplete, or past restore results were never written down, you will spend time reconstructing history before the test can start. Keep a dated record of each restore exercise, its scope, its outcome, and who signed it off. A well-kept record lets you reuse last year's evidence and focus this year's effort on what has changed.

Hosting location and infrastructure type

Self-hosted platforms in your own data center, a private cloud, and a public cloud each need different access arrangements, network paths, and provider permissions for testers. Hybrid setups with components in several locations often need separate test plans and separate sign-off for each environment. Document where each system runs and which infrastructure layer you manage directly, so the test scope reflects who controls what. Confirm with your hosting provider which testing activities they permit before scheduling.

Frequency of major changes

Changes to the continuity plan or to critical systems can trigger new testing outside your normal annual cycle. Frequent upgrades, new integrations, or platform migrations therefore increase the number of tests and the time needed to validate each one. Use a change calendar that flags which changes are major, and batch planned upgrades where safe so one retest covers several changes. Ask your compliance lead to define what counts as a major change in writing before the year begins.

Why TLPT exclusion does not remove testing duties

Excluding an entity from threat-led penetration testing removes one regime, not the testing duty itself. Under Article 16(1), microenterprises and the other entities it covers are excluded from the threat-led penetration testing that Article 26(1) sets out. That exclusion does not reach the testing programme in Article 25, which lists the test types every entity must consider, and it does not reach the yearly backup and restore test that the simplified regime requires under Article 40 of Delegated Regulation (EU) 2024/1774. A firm that reads the TLPT exclusion as a general exemption from testing has misread the Regulation. The practical starting point is to list every ICT system supporting its services, then record which Article 25 test types apply to each one and when they will run.

The entity owns the decision on test scope, and it must write down the reasoning. For microenterprises, Article 25(3) asks for a risk-based approach combined with strategic planning, balancing the resources and time available against urgency, the type of risk and the criticality of assets and services. Nothing in the text hands that judgment to a supervisor or a vendor. The documented plan should state, for each test, whether it runs, how often, who performs it, and why any test type is skipped. Reasons that hold up are specific ones tied to the entity's risk profile, such as a system with no internet exposure or a component already covered by a yearly backup and restore test. Vague reasons such as 'low risk' or 'not needed for our size' will not carry weight on review.

The competent authority judges the plan, and no document guarantees acceptance. Supervision of DORA compliance sits with the national competent authority for each type of financial entity, using the powers in Article 50, and DORA provides no certification that would settle the question in advance. Entities should confirm with their own authority how it expects simplified-regime plans to look, including the format and level of detail it reviews, rather than assuming a plan that satisfies the text will be accepted as drafted. Outside help can prepare test plans, run the tests and assemble evidence, but the organization remains accountable for the scope decisions and the reasoning recorded behind them.

Run the tests in-house or buy them in

This table compares four ways a microenterprise or simplified-regime entity can meet its DORA testing duties: in-house staff, an external security tester, an implementation partner, or a combined retainer. Read each column to see which work the option suits, what the organization keeps control of, and what to settle in the contract before work starts.

Option	Work it fits	What the organization keeps	Independence and contract points
In-house execution	Routine checks against the ICT security testing plan, vulnerability scans, and configuration reviews where staff have the skills to run them	Full control of scope, timing and findings; direct knowledge of systems	Testers who build or run the systems they test lack independence; confirm who reviews results and whether a separate person signs off the plan
External security tester (penetration testing)	Independent penetration tests of internet-facing systems and access controls, typically once the plan calls for an external view	Ownership of the test plan, risk decisions and remediation priorities	Confirm tester qualifications, rules of engagement, data handling, liability and how findings are delivered and retested
Implementation partner (backup, restore and evidence)	Setting up backup and restore procedures, running the annual restore test, and assembling logs and records that show the test happened	Ownership of the continuity plan, sign-off on test results and the evidence it accepts	Confirm the written scope, deliverables, who holds administrator access during work, and that the partner does not issue any audit or attestation
Combined arrangement with a retainer	Ongoing support for the testing calendar, repeated restore tests after major changes, and periodic reviews of the plan as risk changes	Board accountability, the decision on what is tested, and the record of actions taken	Confirm response times, what happens after a major change, and how scope changes are priced and documented in writing
Who signs off the plan	Approving the security testing plan and the risk profile it rests on	The management body and accountable owners named in the organization's own governance	No outside party can approve the plan on the organization's behalf; confirm how external input is recorded
Evidence an assessor expects	Dated test records, scope statements, findings, and proof that critical system measures were updated after results	Custody of the original reports and logs	Ask providers for deliverables in a form the organization can keep, and confirm retention periods
Ongoing cost drivers	Number of systems in scope, frequency of changes, and how many tests the plan requires each year	Budget decisions and the choice of what is tested more often	Ask each provider to break its quote into one-time setup and recurring work so the two can be compared

Who owns the testing, who prepares it, and who signs off

Your organization owns the ICT testing plan, the risk decisions behind it and the board reporting that goes with it. Under the risk-based approach for microenterprises, and under the simplified-regime security testing plan, the plan must reflect your own risk profile, your critical systems and the urgency of the findings. A partner can draft material, but the management body must approve the plan, accept residual risk and receive the results.

Plan ownership: Decide which systems are in scope, how often each is tested and which test types apply, and record the reasons.
Risk decisions: Accept, mitigate or defer each finding, and document who made the call and why.
Backup and restore testing: Set the schedule for yearly restore tests and trigger additional tests after major changes to the continuity plan.
Board reporting: Present results, open gaps and remediation status to the management body in a form it can act on.
Remediation: Assign owners, set target dates and confirm that fixes were validated before closing findings.

Before engaging anyone, confirm internally who holds the testing plan and who has authority to sign it off.

How to choose a tester or implementation partner for a small DORA programme

A small DORA programme often depends on one outside firm for both building systems and testing them, so the choice carries real risk. The checks below help you confirm the partner has relevant experience, a written scope, independent testers, evidence your supervisor can read, clear sign-off on reports, and defined support terms.

Experience with financial entities

Ask whether the partner has previously run backup and restore tests and security testing for regulated financial entities, and how those tests mapped to the business continuity plan. Under the simplified regime, the backup and restore test is an annual obligation, so the partner should be able to describe how they time, record and repeat it. Confirm which tests they have carried out and which they only advise on, without naming clients.

Written scope and deliverables

Require a written scope listing each system tested, each test type, the deliverables, and the dates or milestones agreed before work starts. Check that the scope covers the systems supporting your critical or important functions and the ICT security testing plan the simplified regime requires. Ask what happens if a test uncovers a system outside the agreed scope, and who approves any change.

Separation between builders and testers

Ask who configured the systems and who will test them, and whether the same engineers perform both roles. Where the implementation partner also builds the platform, ask how it will keep testing independent, for example through different staff or a reviewer who did not build the system. Confirm this in writing, because a supervisor may ask how independence was ensured.

Evidence a supervisor can read

Ask what each test produces: the test plan, the raw output, the findings with severity, the remediation record and the retest result. Request a sample report, with sensitive details removed, and check whether it links each finding to the system and the date tested. Evidence should be stored in a format you can keep for your own records and share with your competent authority on request.

Who signs the test reports

Clarify who approves and signs each report on your side and on the partner's side. The partner can prepare evidence and reports, but the management body remains responsible for your ICT risk framework, and only an independent auditor or assessor issues attestations. Confirm the named individuals, their roles, and how a disputed finding is resolved before the report is final.

Ongoing support and retainers

Ask whether support after the initial test is covered by the fixed-scope agreement or offered as a separate retainer, and what that retainer includes, such as repeat testing, upgrades, backup verification and documentation updates. Confirm how changes to the business continuity plan trigger a new restore test, and what the partner will do between annual tests if a major change occurs.

What smaller entities ask about DORA testing before hiring help

Can a microenterprise run its own DORA testing without outside help?

Yes, a microenterprise can run its own testing if it has the skills and time to do so. Article 25(3) asks for a risk-based approach combined with strategic planning of ICT testing, balancing the resources and time available against urgency, the type of risk, and the criticality of assets and services. The firm still owns the plan, the choice of tests and the evidence. Outside help is usually most useful for testing that needs independent testers, for checking that the plan matches the firm's actual systems, or for producing clear records an assessor can follow. Ask any partner to put scope, deliverables and responsibilities in writing before work starts.

How much effort does the yearly backup and restore test take, and what does it need from staff?

The effort depends on how many systems and backup chains are in scope, how complex the restore steps are, and how well the procedures are already written down. Under Article 40 of Delegated Regulation (EU) 2024/1774, simplified-regime entities must test backup and restore procedures at least once a year or after every major change to the continuity plan. Staff need to know the procedure, have access to the backup media and a safe restore environment, and record what was restored, how long it took, and what failed. Ask a provider to estimate effort from a written list of systems, owners and recovery steps, not from a general daily rate.

Can a simplified-regime entity use one testing plan for all of its systems?

A single plan can work if it covers every system that matters and explains how each one is tested. Article 36 of Delegated Regulation (EU) 2024/1774 requires an ICT security testing plan that validates access control, operations, data and network security, and development and change measures. The plan must be reviewed according to the entity's risk profile, and measures must be updated promptly after test results for critical systems. Because the risk for a low-criticality system is lower, the plan can set different depths and frequencies for different systems. The key is a written rationale that an assessor can follow.

What counts as a major change that triggers new restore testing?

A major change is one that alters how the continuity plan or the backup and restore procedures work, so that the existing test no longer shows they will work. Examples include moving to a new backup platform, changing the systems that a restore depends on, replacing a critical application, or changing the hosting location of recovery data. Article 40 of Delegated Regulation (EU) 2024/1774 ties the retest to major changes to the plan. The entity should define what it considers major in its own policy, record each decision, and check the definition with its competent authority or auditor where the boundary is unclear.

Does TLPT exclusion mean a smaller entity does not need penetration testing?

No. Entities under Article 16(1) are excluded from threat-led penetration testing under Article 26(1), but they still must test their ICT systems. The exclusion removes the TLPT requirement only. Smaller entities still need the testing that Article 25 and the simplified framework require, including security testing that validates their controls. Before deciding on scope, confirm with the competent authority which exclusion applies, then map each internet-facing or critical system to a test type and frequency.

What should be requested in a quote for DORA testing support?

Ask for a written scope that lists the systems, the test types, the frequency, and the evidence each test will produce. The quote should name who performs each task, what the client must provide, and which outputs are delivered, such as test plans, test reports, restore records and remediation tracking. It should also state which parts are one-time work, such as the initial plan and procedure documentation, and which recur, such as annual restore tests or retainer support. DeployOpen does not publish a price list, and a quote follows from the written scope. Ask for assumptions about client access, environments and change windows, since these drive cost more than the number of tests.

How long does DORA testing support take to deliver?

Duration depends on the number of systems in scope, how documented the environment already is, how quickly the client can grant access, and how many restore tests must be run. Most engagements are fixed-scope, so the timeline is agreed in writing before work starts and tied to specific deliverables. The first phase usually involves confirming scope and gathering documentation, and it is the phase most often delayed by missing inventories or unclear ownership. Ask any provider for a dated plan that lists client dependencies, and check whether later restore tests are covered by a separate agreement or a retainer.

How DeployOpen works on this

DeployOpen works on DORA resilience testing for microenterprises and simplified-regime entities by scoping the testing in writing, building the test environment inside the client's own infrastructure, and handing over documented evidence the entity owns. The entity keeps responsibility for its testing programme, its risk decisions and its board sign-off, while DeployOpen prepares the systems, tests and records that support them.

How we scope

Agreed in writing before work starts, with systems, test types and deliverables named for each engagement.
Covers which ICT systems support critical or important functions and how the risk-based plan is set for the entity.
Records the testing schedule, the backup and restore test dates and the owner who signs off each result.

How we build

Sets up the security testing for the access control, operations, data, network and change measures in the simplified framework.
Runs backup and restore tests in the client's own environment, with the restore results recorded against the plan.
Keeps test scripts, configurations and tool versions documented so the entity can repeat the same tests in later years.

How we hand over

Delivers test reports, findings logs and a remediation list the entity's management body can review and approve.
Provides the yearly testing record, including backup and restore outcomes, in a form an internal audit or supervisor can check.
Documents the rationale for excluding threat-led penetration testing, so the decision is traceable to the entity's risk profile.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement ends.
Retesting after fixes is included in the written scope where the client agrees to it, so closure is evidenced.
Confirm with DeployOpen which assessment the entity's competent authority expects, since DeployOpen prepares evidence but does not issue reports or attestations.

DORA resilience testing for microenterprises and simplified-regime entities