DORA Resilience Testing for Smaller Firms: What Proportionality Really Allows

ByOfficer

Last updated: May 2026

DORA resilience testing obligations reach almost every financial entity in the EU. Not just the systemically important ones. Not just the ones with dedicated security teams. The exception that matters here is the microenterprise: the Article 24 testing programme applies to financial entities other than microenterprises, while microenterprises test on a lighter, risk-based basis under Article 25(3). The regulation also draws a clear line between threat-led penetration testing (TLPT), which only applies to entities designated by competent authorities, and baseline digital operational resilience testing under Articles 24 and 25. Smaller firms often conflate these two tracks and either over-scope their testing programme or, worse, assume proportionality means they can skip testing entirely. Neither is correct.

The operational cost of getting this wrong cuts both ways. Over-testing burns budget on red team exercises your firm was never required to run. Under-testing creates gaps that will surface during supervisory review or, more painfully, during an actual ICT disruption. I have seen mid-sized fund administrators allocate six-figure budgets for TLPT-style engagements they were never designated for, while neglecting the vulnerability assessments and scenario-based tests that DORA actually expects from them.

Related reading: DORA TLPT: What Designated Entities Must Prepare Now

DORA Resilience Testing Under Article 24: What the Regulation Actually Says

Article 24 of Regulation (EU) 2022/2554 establishes the general requirements for digital operational resilience testing. Every financial entity within DORA’s scope, other than microenterprises, must establish, maintain, and review a sound and comprehensive digital operational resilience testing programme. This is not optional, and it is not something that only applies after a supervisory nudge. Microenterprises are the one exception: Article 24 expressly carves them out, and they instead perform the Article 25(1) tests on a risk-based basis under Article 25(3).

The testing programme must form an integral part of the ICT risk management framework. Article 24(2) requires it to include a range of assessments, tests, methodologies, practices, and tools. The regulation does not prescribe a single testing method. Instead, it lists a menu in Article 25 and asks entities to apply it proportionately.

Proportionality enters through Article 4, the regulation’s proportionality principle, which Article 4(2) extends to the testing chapter. Articles 24 and 25 build that principle in directly by requiring the programme and its tests to follow the criteria set out in Article 4(2). The testing programme must be proportionate to the entity’s size and overall risk profile, taking into account the nature, scale, and complexity of its services, activities, and operations. This is not a blanket exemption. It is a scaling mechanism. A small payment institution and a large credit institution both need a testing programme, but the depth, frequency, and selection of tools differ.

One thing teams commonly misread: Article 24(6) requires that all ICT systems and applications supporting critical or important functions be tested at least yearly. “Critical or important functions” is the threshold. If a smaller firm has identified its critical functions under its ICT risk management framework, those systems need annual testing. The proportionality principle adjusts how you test, not whether you test critical systems.

The Testing Menu Under Article 25

Article 25(1) lists the types of tests that fall under baseline digital operational resilience testing. These are distinct from TLPT under Article 26. The list includes:

  • Vulnerability assessments and scans
  • Open-source analyses
  • Network security assessments
  • Gap analyses
  • Physical security reviews
  • Questionnaires and scanning software solutions
  • Source code reviews where feasible
  • Scenario-based tests
  • Compatibility testing
  • Performance testing
  • End-to-end testing
  • Penetration testing

This is a broad catalogue, and no entity is expected to run every type every year. The proportionality principle in Article 4, carried into the testing chapter through the Article 4(2) criteria, applies here: a smaller firm with straightforward ICT infrastructure might rely primarily on vulnerability scans, network security assessments, and scenario-based tests. A firm with complex, interconnected systems would need a wider selection.

Where teams get this wrong: penetration testing appears on the Article 25 list and is a baseline test, not a TLPT exercise. The distinction matters. Article 25 penetration testing is scoped by the entity itself, targets specific systems or applications, and does not require the threat intelligence-led methodology mandated under Article 26. Some firms avoid penetration testing altogether because they associate it exclusively with TLPT. The regulation does not support that reading. If penetration testing is proportionate to your risk profile, it belongs in your baseline programme.

Article 25(3) addresses microenterprises specifically: they still perform the tests listed in Article 25(1), but combine a risk-based approach with strategic planning, balancing the resources and time spent on testing against the urgency, type of risk, and criticality of the assets and services involved. Entities on the simplified ICT risk management framework under Article 16(1) are a separate category, and DORA treats the two distinctly. Article 16 disapplies only Articles 5 to 15, not the testing chapter, so Article 16(1) entities remain subject to Chapter IV testing. They scale it to their risk profile rather than skipping it.

Article 16 Entities: Simplified Framework, Not Simplified Testing

Article 16 of DORA establishes a simplified ICT risk management framework for certain entity types. These include small and non-interconnected investment firms (as defined under Article 12(1) of the Investment Firms Regulation, (EU) 2019/2033), payment institutions exempted under PSD2, institutions exempted under CRD where Member States chose not to apply certain DORA options, electronic money institutions exempted under the E-Money Directive, and small institutions for occupational retirement provision.

The simplified framework under Article 16 reduces certain ICT risk management obligations, particularly around governance structures and the detail of ICT security policies. It does not eliminate the testing requirement. Article 16 disapplies only Articles 5 to 15, not the testing chapter, so Article 16(1) entities stay subject to Articles 24 and 25 to the extent they are not also microenterprises, which Article 24 carves out, leaving them on the lighter Article 25(3) route. DORA treats microenterprises and Article 16(1) entities as distinct categories.

The practical difference for Article 16 entities is scope and method, not exemption. An entity under the simplified framework might reasonably run annual vulnerability scans on its core systems, a network security assessment, and a tabletop scenario exercise. It would not typically need source code reviews, end-to-end testing of complex integrations, or performance testing unless its ICT architecture warrants it.

I have worked with smaller fund service providers who treated the simplified framework as a complete carve-out from Chapter IV testing obligations. Their compliance mapping stopped at the ICT risk management framework itself and omitted the testing programme entirely. When supervisory questionnaires arrived, they had nothing to point to. The simplified framework simplifies the ICT risk management requirements of Articles 5 through 15. It does not override the testing chapter.

What TLPT Is and Why Most Smaller Firms Do Not Need It

TLPT under Articles 26 and 27 is an advanced testing obligation. It applies only to financial entities identified by competent authorities based on criteria including systemic importance, ICT maturity, and the specific ICT risk profile. The identification process follows criteria laid out in Article 26(8) and the related RTS.

Smaller firms are, in most cases, not designated for TLPT. The regulation does not impose a size threshold that automatically triggers designation. Instead, competent authorities assess each entity individually, considering factors such as the impact of potential ICT disruptions on the financial system. For the typical small or mid-sized entity, TLPT is not a current obligation.

The common error runs in both directions. Some smaller firms panic-budget for TLPT because they read “threat-led penetration testing” and assume it applies universally. Others use TLPT’s inapplicability as a reason to minimise all testing. Neither interpretation aligns with the regulation. TLPT is one specific, advanced layer. Baseline testing under Articles 24 and 25 is the universal requirement.

If your entity has not received a formal designation from your competent authority for TLPT, you do not need to prepare for it. But you absolutely need a documented, proportionate testing programme under Article 24. For a practical overview of what designated entities face, see our guide on DORA TLPT requirements for designated entities.

Building a Proportionate Testing Programme

The regulation does not provide a prescriptive template for what a proportionate testing programme looks like. That ambiguity is deliberate, but it creates real implementation questions. Based on the regulation’s text and the ESAs’ RTS on ICT risk management, here is what a defensible programme for a smaller entity typically includes.

Start with the critical function inventory. Article 24(6) ties annual testing to systems supporting critical or important functions. If your DORA register of information is up to date, it already maps your ICT third-party dependencies. The testing programme should align with that mapping. Systems that support critical functions get tested annually. Non-critical systems follow a risk-based cycle, which might mean every two to three years or after significant changes.

Vulnerability assessments and scans are the minimum baseline. These are low-cost, automatable, and address the most common ICT risks. Run them at least annually on systems supporting critical functions, and after any material change to the ICT environment. Most firms already do this as part of general IT hygiene, but DORA requires it to be documented within the formal testing programme and reported to the management body.

Scenario-based testing is where proportionality shows its practical value. A large bank might simulate a multi-day outage across data centres. A smaller firm might run a tabletop exercise: what happens if the primary cloud provider is unavailable for 48 hours? What if a key ICT vendor suffers a data breach? The regulation does not specify the format. It requires that the testing programme include scenarios that are relevant to the entity’s actual risk landscape. Teams that default to generic scenarios from a vendor template miss the point. The scenario should test your specific ICT incident response and escalation procedures.

Documentation is a requirement, not a nice-to-have. Article 24(5) requires financial entities to establish mechanisms to prioritise, classify, and remedy all issues revealed during testing. Results must be reported to the management body, and any identified weaknesses must be addressed. For a smaller firm, this means a written testing plan, test execution records, a findings log, and a remediation tracker. Supervisory expectations here are not lighter because the entity is smaller. The evidence trail matters.

Reporting and Audit Implications

DORA does not create a standalone reporting obligation for baseline testing results. Entities are not required to submit test reports to their competent authority as a routine filing. However, testing outcomes feed into several other DORA obligations that do have supervisory visibility.

The ICT risk management framework, which under Article 6(5) must be documented and reviewed at least once a year, with a report on that review made available to the competent authority on request, should reflect testing results. If vulnerability scans reveal gaps, those gaps should appear in the ICT risk assessment. If scenario testing exposes weaknesses in business continuity arrangements, those weaknesses should feed into the ICT business continuity policy under Article 11.

The DORA compliance framework is interconnected. Testing results inform the register of information, incident response preparedness, and the annual review of the ICT risk management framework. Treating testing as an isolated compliance checkbox, rather than an operational input, is where smaller firms most frequently fall short.

From an audit perspective, competent authorities can request evidence of the testing programme during supervisory reviews or on-site inspections. The expectation is that the entity can demonstrate a documented programme, evidence of execution, findings, and remediation. Proportionality applies to scope and method, not to the quality of record-keeping.

Common Missteps for Smaller Entities

Three patterns recur across smaller financial entities implementing DORA testing obligations.

First, conflating baseline testing with TLPT and either over-investing or ignoring both. The regulation separates these clearly. If you are not designated for TLPT, your obligation is under Articles 24 and 25 only. That obligation is real and enforceable, but it is fundamentally different from threat-led testing.

Second, assuming the simplified ICT risk management framework under Article 16 removes the testing obligation. It does not. Article 16 entities still fall under Chapter IV. The simplified framework adjusts the ICT risk management requirements in Chapter II, not the testing requirements in Chapter IV.

Third, treating testing as an annual event rather than a programme. The regulation requires a programme, meaning a planned, documented, and recurring set of activities. A single annual vulnerability scan does not constitute a programme. Even for a small firm, the programme needs to cover different test types, align with the critical function inventory, and produce documented outcomes that feed back into the ICT risk management framework.

A fourth, subtler issue: outsourcing the entire testing programme to a vendor without retaining internal oversight. Article 24(4) requires that tests be undertaken by independent parties, whether internal or external, and where an internal tester is used, that the entity dedicate sufficient resources and avoid conflicts of interest. Read with the entity’s duty to establish and maintain the programme under Article 24(1), this keeps ownership of the programme with the entity. The entity remains responsible for the programme design and findings review, regardless of who executes the tests. Delegating execution is fine. Delegating accountability is not.

Frequently Asked Questions

Does DORA require smaller firms to conduct TLPT?

No. TLPT under Article 26 applies only to financial entities specifically identified by competent authorities. Smaller firms are generally not designated. Their testing obligation falls under the baseline requirements of Articles 24 and 25.

What types of tests must smaller firms run under DORA?

Article 25(1) provides a menu including vulnerability assessments, network security assessments, scenario-based tests, penetration testing, and others. Proportionality means the entity selects the tests appropriate to its size, risk profile, and ICT complexity. There is no fixed minimum list beyond the annual testing requirement for critical systems.

How often must testing be conducted?

Article 24(6) requires that all ICT systems and applications supporting critical or important functions be tested at least once a year. The broader testing programme follows a risk-based frequency for non-critical systems.

Are Article 16 entities exempt from DORA testing?

No. Article 16 provides a simplified ICT risk management framework, but it does not exempt entities from the testing obligations in Chapter IV. Article 16 disapplies only Articles 5 to 15, not Chapter IV, so Article 16(1) entities remain subject to baseline testing under Articles 24 and 25. The risk-based testing route in Article 25(3) is written specifically for microenterprises, which DORA treats as a separate category.

Can a smaller firm outsource all testing?

The entity can outsource test execution, but Article 24 requires the entity itself to establish and maintain the testing programme. The responsibility for programme design, findings review, and remediation stays with the entity. Outsourcing execution to a vendor does not transfer accountability.

Is penetration testing the same as TLPT?

No. Penetration testing appears in the Article 25 baseline testing menu. TLPT under Article 26 is a specific, advanced form of testing that follows a threat intelligence-led methodology, targets live production systems, and is conducted by testers meeting the Article 27 requirements. DORA allows internal testers for up to two of every three cycles, requires an external tester at least every third test, and requires significant credit institutions to use external testers, while the threat intelligence must always come from an external provider. Standard penetration testing scoped by the entity itself is a baseline activity, not TLPT.

Do testing results need to be reported to the competent authority?

DORA does not create a routine reporting obligation for baseline test results. However, testing outcomes feed into the ICT risk management framework, which is subject to supervisory review. Competent authorities can request evidence of the testing programme, execution records, and remediation actions during supervisory assessments or inspections.

Key Takeaways

  • All DORA-scope financial entities other than microenterprises must maintain a digital operational resilience testing programme under Article 24; microenterprises instead perform the Article 25(1) tests on a risk-based basis under Article 25(3).
  • TLPT under Articles 26-27 applies only to entities designated by competent authorities. Smaller firms are generally not designated.
  • Proportionality, anchored in Article 4 and applied to the testing chapter through the Article 4(2) criteria, adjusts the scope, method, and frequency of testing. It does not let any in-scope entity skip testing altogether, though microenterprises follow the lighter risk-based route in Article 25(3).
  • Article 16 entities follow a simplified ICT risk management framework but remain subject to Chapter IV testing obligations.
  • ICT systems supporting critical or important functions must be tested at least annually.
  • Penetration testing in Article 25 is a baseline activity, distinct from the threat-led methodology required for TLPT.
  • Testing results must be documented, reported to the management body, and used to inform the ICT risk management framework. Record-keeping is not scaled down for smaller entities.
  • Outsourcing test execution is permitted, but the entity retains responsibility for programme design, findings review, and remediation.

Related Articles

Sources and References

  • Regulation (EU) 2022/2554 of the European Parliament and of the Council on digital operational resilience for the financial sector (DORA) – EUR-Lex
  • Commission Delegated Regulation (EU) 2024/1774 supplementing DORA with RTS on ICT risk management tools, methods, processes, and policies, and the simplified ICT risk management framework – EUR-Lex
  • ESAs Final Report on draft RTS on ICT risk management framework and simplified ICT risk management framework (JC 2023 86) – ESAs Joint Committee (EBA, ESMA, EIOPA) – EBA publication page
  • Regulation (EU) 2022/2554, Recital 42 on proportionality and the simplified framework for certain financial entities – EUR-Lex

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts