The two DORA testing programs

Every firm building a DORA-aligned testing program faces the same choice, even if nobody frames it that way. 

The first program is built to satisfy the regulation. It commissions what is required, scopes it as narrowly as the requirement allows, collects the artifacts, and files them. It will pass a supervisory review. It will not tell you whether your organization would hold up under real adversarial pressure, because it was never designed to answer that question. 

The second program is built to answer that question. It runs the same activities, covers the same pillars, cites the same articles. It looks nearly identical on a compliance checklist. The difference is in what each activity is actually scoped to test, how frequently it runs, and whether the findings connect to anything that changes how your organization behaves between exercises. 

Both programs exist right now, across the regulated financial institutions that have spent the last two years building DORA compliance infrastructure. Most firms are building the first one, because it is cheaper, faster to stand up, and sufficient for the current enforcement climate. The firms building the second one have made a different calculation: that the actual attack, not the audit, is the event that determines whether the last two years of compliance investment meant anything. 

This post maps what the second program looks like, pillar by pillar and month by month, and where the first program falls short of it in ways that will not show up until something tests them. 

---

This is the third post in a four-part series on DORA and genuine operational resilience. Post one covers DORA’s five pillars and the current enforcement picture. Post two covers threat-led penetration testing under Article 26.

---

Where the minimum program fails, pillar by pillar 

Articles 24 and 25: What the annual test is actually being asked to do

The minimum program commissions some form of annual security testing, points to Articles 24 and 25, and considers the obligation satisfied. The problem is not the type of test. It is what any single, point-in-time test cannot do. 

DORA’s testing requirement is not asking you to find vulnerabilities. It is asking you to demonstrate preparedness for handling ICT-related incidents and achieving operational resilience. Those are different questions.  

Breach and attack simulation (BAS) is the capability that closes that gap. Rather than the obsolete model of a point-in-time test against a pre-agreed scope, BAS runs continuously or on a defined cycle against your live environment, testing known attack techniques against your actual detection and response controls. A vulnerability scan tells you what is exposed. BAS tells you whether your defenses would notice if someone used it. That is the question DORA’s testing mandate is built around. 

The constant attack lifecycle approach, running BAS twice a year at minimum against current threat intelligence, keeps your detection validation from going stale between annual exercises. Threat intelligence changes faster than a twelve-month cycle accounts for. An organization running point-in-time tests against last year’s threat model is validating defenses against attacks that have already evolved.  

Articles 28 to 30: The perimeter you are not testing 

The minimum program adds the Article 30 mandatory clauses to new contracts, works through the existing ones, and considers the third-party obligation managed. 

DORA’s requirement is not contractual compliance. It is operational assurance. The 19 Critical ICT Third-Party Providers designated by the ESAs in November 2025, including AWS, Microsoft Azure, Google Cloud, IBM, Salesforce, SWIFT, and FIS, are now under direct regulatory oversight. Their downstream clients are expected to have RoI entries that reflect the actual complexity of those relationships, including sub-outsourcing dependencies. The EBA has already flagged blank sub-outsourcing templates for major cloud providers as not credible. 

The resilient program exercises the audit rights those contracts provide. It requires evidence of testing from critical providers rather than collecting attestations. It treats the Register of Information as a live document that changes every time a provider updates their sub-outsourcing arrangements, not a submission made once and revisited at renewal. 

Your testing obligation does not stop at your own perimeter. The minimum program acts as if it does, and that assumption is precisely where supply chain attacks find their entry point. The firms that treat third-party assurance as a contractual exercise, rather than a security one, are not just failing a DORA obligation. They are leaving an attack surface unexamined that a sophisticated adversary will use to reach them through a provider they trusted. 

Physical and social engineering vectors 

The minimum program tests digital systems. A real adversary does not limit themselves to digital systems. Your critical and important functions depend on people and physical infrastructure: data centres, office access, personnel who can be manipulated into granting access to both. 

A TLPT exercise that tests only digital attack chains is not testing the full threat model a real adversary would use. Physical security testing and social engineering assessments, including phishing, vishing, and pretexting, are within DORA’s full testing scope. The minimum program treats them as optional extras. In a genuine adversarial exercise, they are entry points. 

Chapter II: The inventory everything else depends on 

Every testing activity in a DORA-aligned program is only as useful as the asset inventory it runs against. A stale inventory means scoped tests miss material infrastructure. Not by accident, but by design. 

The minimum program refreshes its asset inventory periodically. The resilient program runs attack surface management continuously: permanent discovery of internet-facing assets, shadow IT, and changes to your environment between formal testing cycles. The ICT risk register your board reviews should reflect your environment as it is, not as it was when someone last had capacity to update it. 

Articles 17 to 19: The clock your team cannot start 

DORA’s incident reporting timelines, four hours from classification, 72 hours for an intermediate report, one month for the final, only work if your team can detect and classify an incident quickly enough to start the clock. 

That capability is not tested by a penetration test. It is tested by purple teaming exercises that validate detection and response processes against realistic attack scenarios. Purple teaming is where you find out whether the controls your penetration test validated would actually be noticed by the people responsible for responding to them. 

The minimum program does not include purple teaming. The resilient program treats it as the exercise that connects offensive testing to the defensive readiness DORA’s reporting obligations assume you already have. 

What the resilient program looks like across 12 months 

The minimum program satisfies each pillar. The resilient program satisfies each pillar at the right frequency, with the right scope, connected to what happens between exercises. 

Continuous, throughout the year 

Attack surface management running at all times. Without it, every other activity in this program is working from a picture of your environment that is already out of date. 

Quarterly 

Vulnerability assessments and targeted penetration testing across systems supporting critical or important functions, rotated so the full estate is covered within the year rather than tested once and left. Social engineering assessments on a rotating basis, phishing simulations at minimum, vishing and pretexting worked into the cycle, to keep human-vector resilience current rather than assessed once and assumed stable. 

Twice a year 

BAS exercises validating detection and response against current threat intelligence. This is the cadence the minimum program skips. It is also the one most likely to reveal that the controls your annual test found intact are not being monitored in a way that would catch someone actually using them. 

Annually, at minimum 

The full digital operational resilience testing program required under Articles 24 and 25: comprehensive testing across all in-scope systems, board-approved, with findings feeding into the ICT risk management framework at governance level, not sitting in a technical report that no one above the security team reads. Physical security assessment of premises and data centre access controls supporting critical functions. 

Every three years, on designation 

The full TLPT exercise under Article 26: threat intelligence phase, red team campaign on live production systems, purple team closure, conducted by accredited providers under TIBER-EU, CBEST, or STAR-FS. The most intensive point in the cycle. Not the only point in it. 

Integrated throughout, not treated as a separate workstream 

Vendor and third-party security assurance: reviewing evidence from critical providers, keeping the Register of Information current, verifying that contractual security clauses are being met in practice. Every sub-outsourcing notification from a critical provider triggers an update obligation. The resilient program has a process for that. The minimum program discovers the gap at the next supervisory review. 

The argument DORA is actually making 

The regulation exists because point-in-time compliance has repeatedly failed to predict operational resilience. DORA’s architects understood that a firm can satisfy every documented requirement and still be fundamentally unprepared for a real adversary. That is why they wrote testing requirements that specify live production systems, unaware blue teams, and continuous rather than periodic obligation. 

A program designed only to satisfy the minimum recreates the exact failure mode DORA was written to prevent. It produces documentation of resilience rather than resilience itself. And the difference between the two does not show up in a supervisory review. It shows up when something actually tests it. 

Both programs will exist across the regulated financial sector for the foreseeable future. Most firms will build the first one. The question worth asking now, before the choice is made for you, is which one yours is. 

---

The fourth and final post in this series makes the harder argument directly: why passing DORA’s requirements, including TLPT, does not mean your organization is actually resilient, and what genuine operational resilience looks like as an ongoing posture rather than a compliance state. 

If this post surfaced the question of whether your current program would hold up under real pressure, the DORA Readiness Guide maps the full picture: requirements, the most common compliance gaps, and this 12-month program as a practical planning tool. We have a UK/EU version and a US-adapted version available. If you would like a copy, get in touch and we will send it over. Contact us to request your copy.