DORA Compliance Checklist for Financial Services 2026

‍This guide builds on foundational research from The Digital Operational Resilience Act (DORA): A Comprehensive Guide to TPRM Compliance, co-authored by Evelyn Partners, Emily Hodges and Chris Luenen (Risk Ledger), updated here to reflect DORA's first enforcement cycle. Examples in this guide are drawn from real engagements. Identifying details have been changed to protect client confidentiality.

DORA has applied since 17 January 2025. For financial services firms today, the challenge is no longer understanding what the regulation says. It’s proving that ICT risk, supplier dependencies, incident reporting, resilience testing and exit plans are operationally ready.

In this guide, we’ll map the main DORA obligations to the controls financial services teams need to operate, the evidence they should retain, and the legal references that matter - including Article 30 contractual provisions, the Register of Information, major ICT incident reporting, TLPT, subcontracting and fourth-party risk.

A programme that can only answer “we reviewed the supplier” is only really compliant on paper, a programme that can answer the dependency, incident, testing and exit questions is much closer to being resilient in practice.

‍

Executive summary

DORA compliance in 2026 is best understood as an evidence and operating-model challenge, not a policy-writing exercise.

Financial services firms need to show that they can:

Confirm which entities, services and ICT arrangements are in scope
Evidence management-body accountability for ICT risk
Maintain an ICT risk management framework
Map ICT assets, services, suppliers and critical or important functions
Maintain a complete and usable Register of Information
Classify and report major ICT-related incidents
Run digital operational resilience testing
Determine whether threat-led penetration testing applies
Manage ICT third-party risk across the supplier lifecycle
Update ICT contracts to Article 30 standard
Assess subcontracting and fourth-party risk
Identify concentration risk and substitutability limits
Test supplier incident readiness
Maintain tested exit plans for ICT services supporting critical or important functions

The hardest items aren’t the ones that produce the most documents, they’re the ones that require you to connect information across teams, suppliers and systems: concentration risk, subcontracting, incident readiness, exit planning and continuous monitoring.

That is where many DORA programmes remain weakest. Supplier evidence may exist, contracts may have been reviewed, but if you can’t quickly answer how a supplier failure would affect critical services or whether two backup providers share the same fourth party, the programme is still only partially tested.

‍

Who this DORA checklist is for

This checklist is written for financial services teams responsible for turning DORA from regulatory text into an auditable operating model.

That includes:

Operational resilience teams;
ICT risk teams;
Third-party risk management teams;
Supplier assurance teams;
Procurement and vendor management;
Compliance and legal teams;
Security and incident response teams;
Business owners responsible for critical or important functions.

It’s also useful for ICT suppliers serving financial services customers. DORA may not make every supplier directly regulated, but it changes what regulated customers will ask for in due diligence, contracts, incident response, subcontracting and ongoing monitoring.

‍

DORA is now live: what changed in 2026?

DORA became applicable on 17 January 2025.

Before application, many firms were asking: What is DORA? Are we in scope? Which policies and contracts need updating? What needs to be ready by the deadline?

In 2026, the questions are now:

Can we evidence how ICT risk is governed?
Does our Register of Information support real decisions?
Can we classify and report a supplier-originated ICT incident quickly enough?
Do we know which suppliers support critical or important functions?
Have we tested our exit and failover assumptions?
Can we identify shared fourth-party dependencies across suppliers?
Can the management body see the risk clearly enough to oversee it?

This is the practical difference between having a DORA programme and having one that actually holds under pressure.

Key takeaways

DORA compliance in 2026 is an evidence problem, not a policy problem

DORA has applied since 17 January 2025. The open question for financial services firms now isn't what the regulation says, it's whether the programme holds up when something actually goes wrong.

15 obligations, one test each
From scope confirmation to exit planning, each item needs a requirement, action, evidence set and an operational test, not just a document.
The Register of Information has to earn its keep
A spreadsheet of suppliers isn't enough. It needs to support incident response, concentration risk analysis and exit planning, not just a submission format.
The weak spots sit between teams, not within them
Concentration risk, subcontracting, incident readiness and exit planning all require connecting information across suppliers, not assessing them one at a time.
Supplier-by-supplier assurance has a ceiling
A questionnaire can confirm what a supplier says about itself. It can't show whether three suppliers all share the same fourth party or cloud region.
Contracts, tests and exit plans need to be usable under pressure
An Article 30 clause, a resilience test or a named backup supplier only counts if it still works when a live incident is underway, not just on paper.
90 days is enough to move from documents to evidence
Prioritise the critical view first, then close supplier and contract gaps, then test the operating model with a real tabletop exercise.

The test that matters

If a critical ICT supplier failed tomorrow, could you explain which services would be affected, which dependencies matter, what evidence supports the risk decision, and how the business would keep operating? If the honest answer is "we reviewed the supplier," that's the gap this guide is written to close.

‍

Who does DORA apply to?

DORA applies directly to a defined set of financial entities in the EU financial sector. These include, among others, credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies and crowdfunding service providers.

DORA also affects ICT third-party service providers because regulated financial entities must manage supplier risk through due diligence, contractual provisions, monitoring, incident response, exit planning and reporting.

A cloud provider, software vendor, data processor, managed service provider or infrastructure supplier may therefore receive DORA-specific requirements through its financial services customers, even where the supplier is not itself a financial entity.

A smaller group of ICT providers can be designated by the European Supervisory Authorities as critical ICT third-party providers. These providers are subject to direct EU oversight because of their systemic importance to the financial sector.

That designation doesn’t transfer responsibility away from financial entities. Firms still need to understand where they rely on those providers, how substitutable the services are, and what happens if the provider or a supporting dependency fails.

For UK firms, DORA should be treated carefully. UK-regulated firms are not automatically subject to DORA simply because the UK has similar operational resilience expectations. But DORA may still matter directly or commercially where a UK firm has EU-regulated entities, serves EU financial entities, belongs to a group with EU operations, or provides ICT services into the EU financial sector.

‍

What secuiry teams ask next

‍

The five DORA pillars

DORA is commonly described through five pillars:

ICT risk management: The governance, policies, controls and processes used to identify, protect, detect, respond to and recover from ICT risk.
ICT-related incident reporting: The classification, escalation and reporting of major ICT-related incidents to competent authorities.
Digital operational resilience testing: Testing ICT systems, controls and processes, including advanced threat-led penetration testing for certain firms.
ICT third-party risk management: Managing ICT supplier risk across due diligence, contracts, monitoring, concentration risk, subcontracting, exit planning and the Register of Information.
Information sharing: Arrangements for sharing cyber threat information and intelligence where appropriate.

For implementation teams, the pillars should not be treated as five disconnected workstreams, they interact.

A Register of Information is not just an inventory, it should support incident response, concentration risk analysis, resilience testing and regulatory reporting.

An Article 30 contract is not just a legal document, it should support audit rights, incident assistance, subcontracting controls and exit.

And a resilience test is not just a technical exercise, it should validate whether critical services can continue when ICT suppliers or shared dependencies fail.

The common mistake is to build DORA around documents rather than decisions. Policies, registers and contracts are necessary, but they are only useful if they help you answer operational questions under pressure.

‍

The DORA compliance checklist for financial services

Each item should be assessed in five ways:

Requirement: what DORA expects.
Action: what the firm needs to do.
Evidence: what to retain.
Reference: where the obligation comes from.
Operational test: how to know whether it works in practice.

‍

1. Confirm DORA scope under Article 2

Requirement

The firm needs to confirm which legal entities, regulated activities and ICT arrangements are in scope under DORA.

Action

Create a scope assessment covering:

Relevant financial entities
Group entities and branches
Regulated activities
ICT services and systems
ICT third-party service providers
Services supporting critical or important functions
Any simplified ICT risk management framework considerations

Evidence to retain

DORA scope memo
Legal entity map
Regulated activity mapping
List of in-scope ICT services
List of in-scope ICT third-party arrangements
Rationale for any excluded entities or services
Legal or compliance sign-off

Legal reference

Regulation (EU) 2022/2554, Article 2.

Operational test

Ask: If a regulator or board member asked why a specific entity, service or supplier is in or out of scope, could you explain the reasoning and show who approved it?

‍

2. Evidence management-body accountability under Article 5

Requirement

DORA places responsibility for ICT risk management at management-body level. The management body is expected to define, approve, oversee and periodically review the ICT risk management framework.

Action

Make accountability visible in governance, not just policy wording. The firm should be able to show how ICT risk is escalated, reviewed and challenged.

Evidence to retain

Board or committee minutes
Approved ICT risk management framework
ICT risk appetite statements
Role and responsibility documents
Reporting packs
Budget and resource decisions
Management-body ICT risk training records
Evidence of periodic review

Legal reference

Regulation (EU) 2022/2554, Article 5.

Operational test

Ask: Could the management body explain your most material ICT third-party risks, the services affected, and the decisions made to accept, reduce or monitor those risks?

‍

3. Maintain an ICT risk management framework

Requirement

The firm needs an ICT risk management framework covering identification, protection and prevention, detection, response and recovery, learning and evolving, and communication.

Action

Maintain a framework that connects ICT assets, services, controls, risks, incidents, suppliers and recovery arrangements.

Evidence to retain

ICT risk management framework
ICT policies and standards
Asset inventories
Access control records
Vulnerability and patching records
Backup and restoration procedures
Business continuity and disaster recovery plans
Control testing results
Remediation logs

Legal reference

Regulation (EU) 2022/2554, Articles 6–16; Delegated Regulation 2024/1774.

Operational test

Ask: Can you quickly identify which ICT assets and suppliers support a critical or important function, and what controls protect them?

‍

4. Map ICT assets, services and critical or important functions

Requirement

DORA expects financial entities to understand the ICT assets, systems and third-party services that support their business. For implementation, the key step is connecting ICT dependencies to the services and functions the business actually needs to keep running.

Action

Map ICT assets and third-party services to:

Business services
Legal entities
Critical or important function
Data processed or stored
Systems and applications used
Direct ICT providers
Material subcontractors or fourth parties
Recovery and continuity requirements

The goal is not to create a perfect architecture diagram for every system. It is to understand which ICT dependencies matter most to operational resilience and regulatory obligations.

Evidence to retain

ICT asset inventory
Service catalogue
Supplier-to-service mapping
Critical or important function assessment
Data-flow mapping
Business impact analysis
Ownership records
Dependency map
Change logs showing how the mapping is maintained

Legal reference

DORA’s ICT risk management and ICT third-party risk management requirements, including Articles 6-16 and Article 28.

Operational test

Ask: If a critical service was disrupted, could you identify the supporting systems, suppliers, data flows and recovery owners quickly enough to support incident response and management-body reporting?

‍

5. Maintain the Register of Information

Requirement

DORA requires financial entities to maintain a Register of Information covering contractual arrangements with ICT third-party service providers.

The Register of Information is more than a supplier list. It should help the firm understand which ICT services are provided, which entities and functions they support, whether they relate to critical or important functions, and what contractual and subcontracting dependencies exist.

Action

Build and maintain a structured Register of Information that captures ICT third-party contractual arrangements at the right level of detail.

At minimum, the firm should be able to use the register to answer:

Which ICT third-party providers do we rely on?
Which contracts and services are linked to each provider?
Which legal entities use the service?
Which business functions or services are supported?
Does the service support a critical or important function?
Where is the service provided from?
What data is involved?
Are subcontractors involved?
Who owns the relationship internally?
When was the record last reviewed?

Evidence to retain

Register of Information export;
Data owner list;
Update process;
Completeness checks;
Quality assurance records;
Mapping between contracts, suppliers, services and functions;
Criticality tagging methodology;
Exception records;
Evidence of periodic review.
Legal reference

DORA Article 28 and the ESA / EBA Register of Information implementing technical standards and related guidance.

Operational test

Ask: Does the register help you make decisions, or does it merely satisfy a reporting format?

A strong Register of Information should support incident response, concentration risk analysis, supplier monitoring, exit planning and supervisory requests. If the register cannot help answer which critical services depend on a given provider, it is probably not yet operationally useful.

‍

6. Classify ICT-related incidents

Requirement

DORA requires financial entities to establish a process to detect, manage and classify ICT-related incidents. Major ICT-related incidents must be reported to the relevant competent authority.

The practical challenge is not only having an incident response policy. It is having a classification process that works quickly when information is incomplete, especially when the incident starts with a supplier.

Action

Create or update an incident classification process covering:
What counts as an ICT-related incident;
How incidents are escalated internally;
Who determines whether an incident is major;
What criteria are used to classify severity;
How supplier-originated incidents are handled;
What information is needed from third parties;
Who approves regulatory reporting decisions;
How decisions are recorded.

This process should be integrated with existing security operations, operational resilience, legal, compliance and supplier management workflows.

Evidence to retain

Incident classification policy;
Major incident decision tree;
Escalation matrix;
Incident response playbook;
Regulator notification process;
Supplier notification requirements;
Incident logs;
Classification decisions;
Legal and compliance review records;
Post-incident reviews.

Legal reference

DORA Articles 17-18 and related regulatory technical standards on incident classification.

Operational test

Ask: If a critical supplier reported an outage or breach at 09:00, could you decide whether it may be a major ICT-related incident, identify what information is missing, and escalate to the right decision-makers the same day?

‍

7. Prepare for major ICT incident reporting deadlines

Requirement

DORA requires financial entities to report major ICT-related incidents through the prescribed reporting process. The reporting framework includes an initial notification, intermediate reporting and a final report.

For financial services firms, supplier-originated incidents are one of the hardest scenarios. The firm may be responsible for reporting, but the information needed to classify and explain the incident may sit with the supplier.

Action

Prepare a reporting process that covers:

Who submits reports to the competent authority
Who approves the initial notification
Which incident information must be captured immediately
How supplier information is requested and escalated
How updates are managed
How intermediate and final reports are prepared
How reporting records are retained
How lessons learned feed into remediation

The incident playbook should define what information is needed from ICT suppliers, including:

Incident start time
Affected services
Affected locations or regions
Data affected
Containment actions
Expected recovery time
Customer or business impact
Root cause, where known
Subcontractors or fourth parties involved
Next update timing

Evidence to retain

Incident reporting playbook
Regulator contact list
Reporting templates
Internal approval workflow
Supplier escalation contacts
Submitted notifications and reports
Timestamps and decision logs
Communications records
Post-incident review
Remediation tracker

Legal reference

DORA Articles 19-23 and Delegated Regulation 2025/301 on major ICT-related incident reporting.

Operational test

Ask: Have you tested whether a supplier-originated incident can produce enough reliable information to support the initial notification and follow-up reporting process?

If the answer is “we assume suppliers will tell us”, the process is not yet tested.

‍

8. Run digital operational resilience testing

Requirement

DORA requires financial entities to establish, maintain and review a digital operational resilience testing programme. Testing should be risk-based, proportionate and designed to identify weaknesses in ICT systems, controls and processes.

The important point for third-party risk teams is that resilience testing should not stop at internal systems. If a critical or important function depends on ICT suppliers, the testing programme should account for those dependencies.

Action

Build a testing programme that includes, where proportionate:

Vulnerability assessments
Network security assessments
Scenario-based testing
Compatibility testing
Performance testing
End-to-end testing
Penetration testing
Business continuity and disaster recovery tests
Supplier failure scenarios
Remediation and retesting

For supplier risk, the firm should test assumptions such as:

Whether the supplier can meet recovery expectations
Whether escalation contacts work
Whether backup providers are genuinely independent
Whether data can be recovered or transferred
Whether a workaround exists for critical services
Whether a fourth-party outage would affect multiple suppliers

Evidence to retain

Annual resilience testing plan
Test scope and methodology
Test results
Vulnerabilities identified
Remediation plans
Remediation completion evidence
Retest results
Business owner sign-off
Supplier participation records
Lessons-learned outputs

Legal reference

DORA Articles 24-25.

Operational test

Ask: Does testing validate real business-service continuity, or only technical control performance?

A penetration test may show a system weakness. A supplier resilience test should show whether the business can keep operating when an ICT dependency fails.

‍

9. Determine whether TLPT applies

Requirement

DORA requires certain financial entities to carry out threat-led penetration testing, commonly referred to as TLPT. TLPT is not a universal requirement for every firm. It applies where the relevant criteria and supervisory expectations are met.

The risk in many checklists is that TLPT is presented as if every DORA-regulated entity must do it. A better approach is to document the applicability decision clearly.

Action

Determine whether TLPT applies to the firm and, if so, plan the testing cycle and governance model.

The assessment should consider:

Entity type
Size and systemic relevance
ICT risk profile
Criticality of services
Supervisory expectations
Whether third-party providers need to be included in scope
Tester independence and competence
Remediation governance

Evidence to retain

TLPT applicability assessment
Supervisory correspondence, where relevant
Test scope
Provider selection records
Tester independence evidence
Threat intelligence scope
Test plan
Final report
Remediation plan
Management-body reporting

Legal reference

DORA Article 26 and the relevant regulatory technical standards on threat-led penetration testing.

Operational test

Ask: Can you explain whether TLPT applies, why that decision was made, and how any required test would include the ICT services and third-party dependencies that matter most?

‍

10. Manage ICT third-party risk under Article 28

Requirement

DORA requires financial entities to manage ICT third-party risk as an integral part of ICT risk management. This includes strategy, policy, due diligence, contractual arrangements, monitoring, concentration risk, exit planning and the Register of Information.

For financial services firms, this is one of the central implementation challenges. A supplier review process that only collects documents once a year is unlikely to provide enough visibility into changing risk.

Action

Maintain an ICT third-party risk management framework covering the full supplier lifecycle:

Supplier identification
Service criticality assessment
Pre-contract due diligence
Risk-based approval
Contract review
Ongoing monitoring
Incident escalation
Subcontracting review
Concentration risk analysis
Exit planning
Termination and post-exit review

The framework should distinguish between:

All ICT third-party arrangements
ICT services supporting critical or important functions
Internally critical suppliers
ESA-designated critical ICT third-party providers
Subcontractors and fourth parties that materially affect service delivery

Evidence to retain

ICT third-party risk policy
Supplier inventory
Due diligence records
Supplier risk assessments
Criticality methodology
Approval records
Monitoring reports
Issue and remediation logs
Concentration risk analysis
Exit plans
Supplier incident records
Register of Information linkage

Legal reference

DORA Article 28.

Operational test

Ask: Can you show why different suppliers receive different levels of scrutiny?

If supplier tiering is based mostly on spend or company size, it may miss the real DORA question: what happens to the business if this service fails?

‍

11. Update ICT supplier contracts to Article 30 standard

Requirement

DORA Article 30 sets out key contractual provisions for ICT third-party service arrangements. Contracts for ICT services supporting critical or important functions require enhanced attention.

The point is not simply to add a DORA clause to every contract. The contract needs to support operational resilience, incident response, auditability, subcontracting control and exit.

Action

Review ICT supplier contracts against Article 30 requirements and remediate gaps.

A practical Article 30 review should check for:

Clear description of the ICT service
Service locations and data processing locations
Information security requirements
Availability, authenticity, integrity and confidentiality requirements
Access, inspection and audit rights
Assistance with ICT incidents
Participation in resilience testing where relevant
Subcontracting conditions
Termination rights
Exit and transition support
Data return, access and deletion provisions
Service levels and reporting obligations
Obligations for services supporting critical or important functions

Evidence to retain

Article 30 clause matrix
Contract inventory
Signed contract copies
Gap assessment
Remediation tracker
Legal review notes
Supplier negotiation records
Exceptions and risk acceptances
Enhanced provisions for critical or important functions

Legal reference

DORA Article 30.

Operational test

Ask: If a critical supplier had an incident tomorrow, would the contract give you the information, access, assistance and exit rights needed to respond?

A contract that looks compliant but cannot be used in an incident is not doing its job.

‍

12. Assess subcontracting and fourth-party risk

Requirement

DORA requires firms to understand and manage ICT subcontracting risk, especially where ICT services support critical or important functions. Subcontracting matters because operational dependency often sits beyond the direct supplier.

A financial entity may contract with one ICT provider, but the service may rely on cloud infrastructure, managed service providers, software components, data centres, processors or other subcontractors further down the chain.

Action

Create a proportionate subcontracting review process that identifies material subcontractors and assesses whether they affect:

Service delivery
Resilience
Security
Data access or processing
Recovery
Exit
Concentration risk
Regulatory reporting
Critical or important functions

The process should also define how suppliers notify the firm of material subcontracting changes.

Evidence to retain

Subcontractor inventory
Supplier-provided dependency information
Subcontracting approval workflow
Change notification records
Risk assessment of material subcontractors
Contractual subcontracting provisions
Concentration risk analysis
Exit impact assessment

Legal reference

DORA Article 28, Article 30 and Delegated Regulation 2025/532 on subcontracting ICT services supporting critical or important functions.

Operational test

Ask: Could you identify which subcontractors matter to a critical ICT service, and whether a change in subcontractor would require review, approval or risk acceptance?

‍

13. Map concentration risk and substitutability

Requirement

DORA requires financial entities to consider ICT concentration risk. In practice, this means understanding where multiple services, suppliers or fallback options depend on the same underlying provider, technology, geography or subcontractor.

This is one of the hardest DORA risks to identify because it rarely appears in a supplier-by-supplier assessment.

Action

Map concentration risk across critical ICT services and suppliers.

Look for shared dependencies such as:

Cloud providers
Cloud regions
Data centres
Managed service providers
Software platforms
Identity providers
Payment processors
Specialist subcontractors
Common backup providers
Common geographic locations
Common technology components

Then assess substitutability:

Could the supplier be replaced?
How quickly?
What would transition require?
Would the replacement depend on the same underlying providers?
Would the business tolerate the disruption?
Is the backup actually independent?

Evidence to retain

Concentration risk analysis
Supplier dependency map
Fourth-party mapping
Cloud and region exposure analysis
Substitutability assessment
Failover assumptions
Scenario analysis
Management-body reporting
Documented risk decisions

Legal reference

DORA Article 28 and ICT third-party risk management requirements.

Operational test

Ask: if two “independent” suppliers both failed at the same time, could the firm tell whether they shared an underlying dependency?

This is where many paper-compliant programmes break down. A supplier questionnaire asks a supplier about itself. Concentration risk often only appears when the firm compares dependencies across suppliers.

‍

14. Test supplier incident readiness

Requirement

DORA incident reporting and ICT third-party risk management depend on suppliers providing accurate information quickly when incidents occur. Contracts may define notification obligations, but readiness is only proven when the handoff is tested.

A supplier can have a good incident response plan. The financial entity can have one too. The gap appears when the two plans have never been introduced to each other.

Action

For ICT suppliers supporting critical or important functions, test the incident handoff.

The test should cover:

Named escalation contacts
Notification routes
Initial notification timing
Minimum information required
Update cadence
Decision-making roles
Regulatory reporting inputs
Communications with customers or stakeholders
Post-incident review process
Remediation ownership

This does not always need to be a full simulation. A tabletop exercise or structured contact test can expose major gaps.

Evidence to retain

Supplier incident contact list
Notification SLA
Tabletop exercise materials
Test attendance records
Test results
Gaps identified
Remediation actions
Updated escalation process
Supplier acknowledgement

Legal reference

DORA incident reporting requirements, Article 30 incident assistance provisions and Article 28 ICT third-party risk management requirements.

Operational test

Ask: Have you tested whether the supplier can provide the information needed for DORA incident classification and reporting, or has it only written that expectation into a contract?

‍

15. Maintain tested exit plans

Requirement

DORA requires firms to consider exit strategies for ICT third-party arrangements, especially where services support critical or important functions. Exit planning is not just a procurement exercise. It is an operational resilience question.

A named alternative supplier is not enough if the firm has not tested whether transition is possible within the disruption tolerance of the business service.

Action

Maintain exit plans for ICT services supporting critical or important functions.

An exit plan should cover:

Trigger events
Decision owners
Transition steps
Data access, return and deletion
Migration requirements
Operational workarounds
Alternative providers
Internal capability gaps
Contractual termination rights
Supplier cooperation requirements
Expected timeline
Risks during transition
Customer or regulatory communications

You should also test whether the plan is realistic.

Evidence to retain

Exit strategy
Supplier-specific exit plans
Alternative provider assessment
Data portability assessment
Transition runbook
Exit test results
Business owner sign-off
Contractual exit provisions
Lessons learned
Risk acceptance where exit is limited

Legal reference

DORA Article 28 and Article 30.

Operational test

Ask: If the supplier had to be exited under stress, could you move the service, recover the data or operate a workaround within the time the business can tolerate?

If the answer is unclear, the exit plan is not yet tested.

‍

DORA evidence matrix: what strong evidence looks like

The difference between a weak DORA programme and a strong one is often the quality of evidence. A policy may prove that a process exists. It does not prove the process works.

Use this matrix to test whether evidence is merely documentary or operationally useful.

DORA compliance

What weak evidence looks like next to strong evidence

The same DORA area can be "covered" on paper in two very different ways. This is what separates a checkbox answer from something that holds up under regulator scrutiny.

DORA area	Weak evidence	Strong evidence
Scope	A broad statement that DORA applies	Entity, activity, service and supplier scope assessment with rationale and sign-off
Management-body accountability	ICT risk mentioned in a committee pack	Board-approved ICT risk framework, recurring reporting, challenge, decisions and training records
ICT risk framework	Policy document only	Framework linked to assets, services, controls, incidents, suppliers, testing and remediation
Critical or important functions	Unclear supplier criticality labels	Documented mapping between services, functions, suppliers, systems and business impact
Register of Information	Spreadsheet of suppliers	Structured register mapped to entities, contracts, ICT services, functions, criticality and subcontracting
Incident classification	Incident response policy	Classification decision tree, escalation workflow, decision logs and tested supplier inputs
Incident reporting	Regulator contact details	Reporting templates, submission process, timestamps, approval records and post-incident review
Resilience testing	Annual technical test	Risk-based test plan tied to critical services, third-party dependencies and remediation tracking
TLPT	Assumption that it does or does not apply	Documented applicability assessment and, where required, scoped testing and remediation evidence
ICT third-party risk	Annual supplier review	Lifecycle process covering due diligence, contracts, monitoring, incidents, subcontracting and exit
Article 30 contracts	Standard DORA addendum	Clause matrix, signed contract status, exceptions, enhanced terms and remediation ownership
Subcontracting	Supplier says subcontractors are used	Material subcontractor inventory, risk assessment, change notification and approval process
Concentration risk	Individual supplier assessments	Cross-supplier dependency view showing shared providers, technologies, locations and fourth parties
Supplier incident readiness	Contractual notification clause	Tested escalation process with supplier contacts, timings, information needs and lessons learned
Exit planning	Named alternative supplier	Tested exit plan showing data portability, transition steps, owners, timing and substitution limits

‍

The hard part: why supplier-by-supplier assurance is not enough

Traditional supplier assurance looks at one supplier at a time. That’s useful, but it has a limit.

A supplier questionnaire can tell you whether a supplier has a security policy, incident response plan, certifications, access controls and backup process. It can’t easily show whether three different suppliers all rely on the same fourth party, cloud region or managed service provider.

That’s the concentration risk problem.

It also explains why repeated questionnaires create diminishing returns. Suppliers serving multiple financial services customers are often asked near-identical questions in different formats, on different cycles, by different teams. Over time, that leads to stale evidence, rushed answers and lower engagement.

The issue is not that questionnaires are useless. They remain necessary for collecting direct evidence from named suppliers. The problem is expecting one-off, supplier-by-supplier evidence collection to answer network-level questions.

DORA pushes firms toward questions that sit across supplier relationships:

Which suppliers support critical or important functions?
Which of those suppliers rely on the same fourth parties?
Which backup providers share dependencies with the primary provider?
Which suppliers have changed subcontractors since the last review?
Which evidence is stale?
Which supplier incident would affect multiple business services?
Which exit plans rely on assumptions that have never been tested?

Those questions need a more connected view of supplier risk.

‍

DORA implementation roadmap

DORA implementation is too broad to “finish” in 90 days. But a financial services firm can use 90 days to move from a document-led view to a more operational view of the suppliers and dependencies that matter most.

First 30 days: build the critical view

Focus on scope, ownership and prioritisation.

Actions:

Confirm which entities and services are in scope
Identify services supporting critical or important functions
Review management-body reporting and accountability
Validate the Register of Information for completeness
Identify the top ICT suppliers supporting critical services
Check whether supplier criticality is based on business impact and substitutability, not just spend
Identify obvious evidence gaps

Outputs:

Scope assessment
Critical service and supplier shortlist
Register of Information quality review
Governance gap list
Priority remediation plan

Days 31-60: close supplier and contract gaps

Focus on the suppliers most likely to affect resilience.

Actions:

Review Article 30 contract coverage
Create a contract remediation tracker
Refresh due diligence for critical ICT suppliers
Add subcontracting and fourth-party questions to reassessment
Check incident notification and escalation clauses
Identify shared dependencies across the critical supplier shortlist
Document exceptions and risk acceptances

Outputs:

Article 30 clause matrix
Supplier evidence gap list
Subcontracting inventory for priority suppliers
Concentration risk first pass
Incident escalation contact list
Updated supplier risk ratings

Days 61-90: test the operating model

Focus on whether the programme works under pressure.

Actions:

Run a tabletop exercise involving a critical ICT supplier scenario
Test the supplier incident handoff
Stress-test one exit or failover plan
Verify whether backup providers share dependencies with primary providers
Review incident reporting decision-making
Update governance reporting with real findings
Define triggers for reassessment and monitoring

Outputs:

Tabletop results
Incident handoff test evidence
Exit or failover test findings
Updated dependency map
Remediation owners
Management-body reporting pack

The aim is not to make every supplier perfect. It is to prove that the firm understands the suppliers and dependencies that matter most, and that risk decisions are timely, documented and defensible.

‍

How Risk Ledger supports DORA compliance for financial services

Risk Ledger helps financial services teams manage the ICT third-party risk requirements that are hardest to sustain through manual, point-in-time assurance.

DORA increases the need for current supplier evidence, subcontracting visibility, concentration risk analysis and ongoing monitoring. But simply sending more questionnaires is not a sustainable answer. It increases supplier burden and often produces worse evidence over time.

Risk Ledger is designed around a different model.

Reusable supplier evidence

Suppliers maintain one profile that can be shared with multiple customers. That reduces duplicate questionnaires and gives financial services teams more consistent, current evidence across the supplier base.

Better supplier engagement

When suppliers are not forced to answer the same questions repeatedly in different formats, they are more likely to keep evidence current and engage properly with assurance requests.

Fourth-party and concentration risk visibility

A network model makes it easier to identify where suppliers converge on the same underlying providers, services or technologies. That helps firms spot hidden concentration risk that would not appear in a supplier-by-supplier review.

Continuous monitoring

Supplier evidence can stay current over time, helping teams move beyond annual-only reassessment for critical ICT suppliers and services supporting critical or important functions.

More defensible risk decisions

DORA does not remove the need for judgement. Financial entities still need to define risk appetite, determine criticality, approve exceptions, run tests and own regulatory accountability. But stronger, fresher supplier evidence gives teams a better basis for making and defending those decisions.

Risk Ledger supports the parts of DORA that are hardest to manage manually: ICT third-party risk, subcontracting visibility, concentration risk, reusable evidence and continuous monitoring.

‍

DORA compliance FAQs

What is the difference between a supplier supporting a critical or important function and a designated critical ICT third-party provider?

A supplier supporting a critical or important function is important to a specific financial entity because of the service it supports. That classification affects due diligence, monitoring, contractual requirements and exit planning.

A designated critical ICT third-party provider is a provider formally designated by the European Supervisory Authorities because of its systemic importance to the EU financial sector. Those providers are subject to direct EU oversight.

Most suppliers that a firm treats as critical will not be ESA-designated critical ICT third-party providers. The two concepts should not be conflated.

What is the DORA Register of Information?

The Register of Information is the structured record of ICT third-party contractual arrangements that financial entities must maintain under DORA. It should show which ICT services are provided, which entities and functions they support, whether they support critical or important functions, and what supplier, contract and subcontracting information is relevant.

A strong Register of Information is not just a reporting file. It should help the firm manage supplier risk, incidents, concentration risk, exit planning and supervisory requests.

What has to be in a DORA-compliant supplier contract?

DORA Article 30 sets out key contractual provisions for ICT third-party service arrangements. These include clear service descriptions, service and data locations, security requirements, access and audit rights, incident assistance, subcontracting conditions, termination rights and exit support.

Contracts supporting critical or important functions require additional attention because the operational impact of failure is higher.

Does DORA require fourth-party mapping?

DORA requires financial entities to manage ICT third-party risk, including subcontracting and concentration risk. It does not mean every firm must map every supplier chain to unlimited depth from day one.

A proportionate approach is to start with ICT services supporting critical or important functions, identify material subcontractors and shared dependencies, and extend mapping where the information would change a risk decision, resilience test or exit plan.

How often should DORA-critical suppliers be reassessed?

DORA does not set one universal reassessment frequency for every supplier. Review frequency should be risk-based and proportionate to the service, function supported, supplier criticality, substitutability, incident history and material changes.

For ICT services supporting critical or important functions, annual-only reviews are difficult to defend if they are not supported by trigger-based reassessment and ongoing monitoring.

Is information sharing mandatory under DORA?

DORA includes provisions for cyber threat information and intelligence sharing arrangements. This is different from mandatory incident reporting. Firms should treat information sharing as an important resilience practice where appropriate, but not conflate it with compulsory major ICT incident reporting.

‍