Decision guide · Compliance
How to reach DORA readiness as a financial entity
DORA turns ICT risk management into a structured programme of decisions, each of which must survive a supervisory review. The right approach decomposes DORA into its five pillars (governance and risk management, incident management, digital operational resilience testing, ICT third-party risk, information sharing) and runs each pillar as a cluster of weighted, auditable decision cases that feed the management body's accountability file.
TL;DR
DORA is five pillars, each a cluster of decisions. Every cluster needs its own evidence trail.
Who owns this decision
Management body as accountable party, CISO or CRO as programme owner, ICT operations, Legal, Procurement and Internal Audit as active stakeholders.
Key criteria to weight
Governance and risk framework
Documented, board-approved, reviewed. The management body owns it.
ICT incident classification and reporting
Aligned with RTS. Times, thresholds, cascade.
Resilience testing scope and frequency
TLPT eligibility assessed. Non-TLPT testing programmed.
ICT third-party register completeness
Art. 28 register. Critical versus non-critical classification explicit.
Contractual provisions
Art. 30 minimum clauses in every ICT contract of record.
Exit strategies per critical provider
Documented, funded, rehearsed.
Step-by-step decision flow
- 1
Confirm entity type
Credit institution, investment firm, insurer, payment institution, CASP or critical ICT TPP. Each has different applicability detail.
- 2
Build the management framework
Governance, roles, RACI, board-approval cadence. Document every step.
- 3
Map the ICT third-party register
Complete, classified, Art. 30 clause coverage assessed.
- 4
Design the testing programme
Annual testing, TLPT where in scope, documentation.
- 5
Run each material sourcing decision as a structured case
Trigger, options, criteria, scoring, risks, memo. Attach to procurement record.
- 6
Feed the supervisory file
Each memo, register entry and test result links into the file the supervisor will ask for.
Compliance note
DORA applies from 17 January 2025. Regulatory Technical Standards finalise the operational detail. DecisionOS memos are shaped to map directly onto Art. 28, 29 and 30 evidence expectations.
Common pitfalls
- !Treating DORA as NIS2 with a financial label. The depth of prescription is different.
- !Third-party register kept in a spreadsheet with no classification.
- !Skipping exit strategies for critical providers.
- !No rehearsal of the incident reporting cascade.
FAQ
Who is in scope for DORA?
Financial entities in the EU — credit institutions, investment firms, insurance undertakings, payment institutions, crypto-asset service providers and certain ICT third-party service providers. DORA is lex specialis for financial services and typically tightens expectations above NIS2.
What does DORA require from vendor selection?
Articles 28–30 require structured risk assessment of ICT third-party providers, explicit contractual provisions, exit strategies and concentration-risk analysis. Each selection decision produces a file that must hold up under supervisory review.
How does DORA differ from NIS2 in practice?
DORA is financial-services specific, more prescriptive and more audit-heavy than NIS2. In the same organisation, NIS2 covers enterprise-wide operational resilience while DORA adds financial-service obligations on top. DecisionOS treats both as selectable scopes that activate different dealbreakers.