DORA has been in force for nearly seventeen months. The Regulation's position is clear: resilience is not a diagram on a slide, it is evidence of tested recovery. Teams that understood this early have built drills, documentation, and third-party evidence into ordinary operations. Teams that treated DORA as a future planning exercise are now catching up under active regulatory scrutiny.
DORA has applied since 17 January 2025. The ESAs — EBA, EIOPA, and ESMA — have published final regulatory technical standards covering ICT risk management, incident classification, threat-led penetration testing, and third-party risk register requirements. On 3 June 2026, the ESAs also published their first annual overview of major ICT-related incidents under DORA, highlighting borderless, interconnected ICT risks and the operational importance of third-party risk management during incident response.
WHERE_ARCHITECTURE_ASSUMPTIONS_BREAK
Every platform has hidden coupling that the architecture diagram does not show. DNS resolvers, identity providers, shared payment rails, internal certificate authorities, backup storage endpoints. These become visible when something fails. The objective under DORA is to find them before regulators or customers do.
Explicit failure domains make graceful degradation achievable rather than theoretical. When you know which dependencies sit in the critical path of which customer journeys, you can make reasonable decisions about load shedding, read-only fallback modes, and what a meaningful partial outage looks like compared to a total one. The June 2026 ESA incident overview reinforces that this is not only an internal reliability problem: system failures, external events, and outsourced service dependencies become supervisory facts once they are reported under DORA.
"Resilience is measured in minutes of confusion you avoid, not years of uptime you claim."
TESTED_RECOVERY_IS_THE_EVIDENCE
Under the DORA technical standards, tested resilience is a documented output, not a verbal assurance. Restore tests need to demonstrate actual data integrity, not just successful backup job completion. Failover drills need timestamps and decision logs. ICT third-party risk registers need to cover not just who the providers are, but concentration risk, substitutability, and what a realistic transition plan would require in practice.
- Trigger traffic movement based on real user-facing signals, not a single-node health check that misses dependency failures upstream.
- Protect the highest-priority journeys explicitly with defined load-shedding sequences — secondary work should degrade first, in a documented order.
- Run backup restoration drills with verification steps that confirm data integrity, not just a successful restore command that completes without error.
- Keep ICT third-party risk registers current — if the list of critical providers changes, the register needs to reflect it before the next supervisory review.
THE_OPERATOR_OWNERSHIP_PROBLEM
Most incident plans fail at the handoff between automation and human judgment. Automation handles clean failover. It cannot decide when to roll back a deployment that is degrading slowly, when to escalate to a supplier, or when to invoke a disaster recovery site. Those decisions need named owners with on-call authority and written thresholds — not intuition developed in real time during the incident itself.
- Map every critical dependency to a named owner with authority to act, not just awareness of the failure.
- Set quantitative rollback and escalation thresholds in writing, tied to SLO burn rates rather than gut feel.
- Run tabletop exercises on the scenarios that are hardest to automate, not just the ones you already have runbooks for.
THREAT_LED_PENETRATION_TESTING_UNDER_DORA
Threat-led penetration testing (TLPT) under DORA is mandatory for significant financial entities identified by competent authorities. It differs from standard penetration testing in that the scope and approach are derived from current threat intelligence about the entity's specific threat landscape rather than from a standard methodology applied uniformly. The test is conducted against live production systems and must be validated by the competent authority, not just reported internally.
For entities in scope for TLPT, the practical implication is that the test cannot be planned and scoped in isolation by the internal security team. It requires engagement with the competent authority on scope approval, selection of a TIBER-EU or equivalent qualified test provider, and production of a full report with findings, severity assessments, and a documented remediation plan. The remediation plan is reviewed by the authority, and the remediation evidence is expected to be produced within the agreed timeframe.
For entities not currently in TLPT scope, the DORA testing framework still requires a regular advanced testing programme that includes scenario-based testing, not just technical vulnerability scanning. The distinction matters because scenario-based tests — which simulate a realistic adversary pursuing a specific objective across the full attack path — surface different failure modes from standard vulnerability assessments and are what the DORA resilience testing requirements are designed to incentivize.
- Identify whether your entity is in scope for mandatory TLPT by checking with your competent authority. The scope is determined by the authority, not by the entity.
- For scenario-based testing outside TLPT scope, write scenarios that reflect realistic adversary objectives for your business context — not generic attack patterns.
- Document the test methodology, scope, and limitations alongside the findings, so the report is interpretable by reviewers who were not present for the test.
- Produce a remediation plan with prioritized findings, owners, and realistic timelines — and track remediation status in the same system as other risk items.
CONCENTRATION_RISK_ASSESSMENT_IN_PRACTICE
DORA requires financial entities to assess concentration risk at multiple levels: the share of critical operations depending on a single ICT provider, the share of the relevant market served by that provider, and the ease of substitution at the product and process level. The assessment is not a one-time exercise — it needs to reflect the current state of both the entity's own infrastructure and the provider landscape.
The practical difficulty with concentration risk assessment is that critical dependencies are not always visible at the level at which procurement decisions are made. A product team that uses three different SaaS tools may not be aware that all three run on infrastructure from the same cloud provider, creating concentration risk that is not visible from the tool-by-tool assessment. Mapping the sub-service topology — not just the direct suppliers but their infrastructure dependencies — is the level of detail the DORA requirements expect.
Substitutability analysis is where the concentration risk assessment produces its most actionable output. For each critical ICT provider, a realistic substitution analysis should produce a documented estimate of the time, cost, and operational risk required to transition to an alternative. Estimates that are not grounded in actual migration experience or vendor capability assessments will not survive scrutiny under supervisory examination. The most credible substitutability assessments reference actual transition testing results or documented industry benchmarks for similar transitions.