DORA Compliance Deepdive

1. Overview

What DORA Is

Regulation (EU) 2022/2554, the Digital Operational Resilience Act (DORA), is the EU's unified ICT risk framework for the financial sector. It entered into force on 16 January 2023 and became fully applicable on 17 January 2025. DORA harmonizes ICT risk management across financial entities operating in the EU and, critically for technology vendors, extends directly to the ICT third-party service providers (TPSPs) those financial entities depend on. The consolidated regulation, supporting Regulatory Technical Standards (RTS), Implementing Technical Standards (ITS), and European Supervisory Authorities (EBA, EIOPA, ESMA) guidance are published at eur-lex.europa.eu and the joint ESAs portal.

Who It Applies To

DORA applies to twenty types of financial entities under Article 2(1) including credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers, securitisation repositories, and account information service providers. A narrow exemption applies to microenterprises (Article 16) but most B2B SaaS customers fall outside it.

Why It Reaches the Supply Chain

DORA Title V (Articles 28 to 44) establishes ICT third-party risk management as a direct regulatory concern, not just a contractual one. Financial entities must apply DORA's third-party risk framework to all their ICT TPSPs. Article 28 prescribes mandatory pre-contractual due diligence and ongoing monitoring. Article 30 lists mandatory contractual provisions. Article 29 governs sub-contracting and the register of information. Articles 31 to 44 establish the Critical ICT Third-Party Service Provider (CTPP) designation regime and the Lead Overseer oversight framework. The practical effect for a SaaS vendor selling into a bank or insurer is that DORA arrives through the contract, the security questionnaire, and the renewal cycle.

Outcome

DORA does not produce a certificate. Compliance is demonstrated through documented programs, contractual provisions, audit cooperation, and the ability to operationalize incident reporting clocks. Financial entity customers will require DORA self-assessments alongside ISO 27001 certificates and SOC 2 reports as part of due diligence. Where a TPSP is designated as Critical (CTPP) under Article 31, it falls under direct ESA oversight including inspections, recommendations, and periodic penalty payments under Article 35 up to one percent of average daily worldwide turnover per day of non-compliance.

Security Consultants supports DORA programs through the DORA compliance service, typically combined with ISO 27001 for the underlying ISMS and SOC 2 for the customer-facing attestation.

2. Scope & Applicability

Financial Entity Scope

Twenty types of financial entity are enumerated in Article 2(1). The scope is intentionally broad and includes both traditional banking and capital markets entities and newer categories such as crypto-asset service providers and crowdfunding service providers.

ICT Service Definition (Article 3(21))

ICT services means digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis, including hardware as a service and hardware services. SaaS, IaaS, PaaS, managed security services, identity providers, data analytics platforms, payment processing platforms, monitoring tools, communication platforms, and consulting services delivered via ICT all fall in scope.

Critical or Important Function

A critical or important function is one whose disruption would materially impair the financial performance of a financial entity, its services, or compliance with regulatory obligations. The financial entity classifies which of its functions are critical or important. If your service supports a function the entity considers critical or important, the entire DORA framework applies to your relationship with that entity, not a lighter subset.

CTPP Designation (Article 31)

The ESAs designate CTPPs based on quantitative criteria including systemic impact, criticality of the financial entities the TPSP serves, reliance on the TPSP, substitutability, and concentration risk. The first list of designated CTPPs was expected from 2025. Designated CTPPs fall under direct Lead Overseer oversight (Articles 32 onward) with inspection rights, recommendations, and penalty powers.

Sub-Contractors and the Chain

Article 29 requires the TPSP to maintain a register of sub-contractors supporting critical or important functions, obtain authorization for sub-contracting where required, and flow DORA-relevant provisions down. The chain extends through tiers.

3. Core Principles — The Five Pillars

DORA is organized into five pillars:

• ICT Risk Management (Articles 5–15): governance, ICT risk framework, identification, protection and prevention, detection, response and recovery, learning and evolving, communication.
• ICT-Related Incident Management, Classification and Reporting (Articles 17–23): incident process, classification thresholds, reporting clocks, harmonized templates.
• Digital Operational Resilience Testing (Articles 24–27): routine testing programme, advanced testing through Threat-Led Penetration Testing (TLPT) for significant financial entities.
• ICT Third-Party Risk Management (Articles 28–44): contractual provisions, sub-contracting, register of information, exit strategy, CTPP designation, Lead Overseer regime.
• Information Sharing (Article 45): voluntary cyber threat information sharing arrangements between financial entities.

4. Control Breakdown

ICT Risk Management (Articles 5–15)

Article 5 — Governance and Organisation: management body bears ultimate accountability for ICT risk; defined roles, training, oversight cadence.
Article 6 — ICT Risk Management Framework: documented framework covering strategies, policies, procedures, ICT protocols, and tools. Reviewed annually and on major incidents.
Article 7 — ICT Systems, Protocols and Tools: appropriate, reliable, sufficient capacity, technologically resilient, equipped to handle peak demand.
Article 8 — Identification: identify all sources of ICT risk; classify and document business functions, roles, ICT assets, information assets, interdependencies, and processes.
Article 9 — Protection and Prevention: secure systems, prevent unauthorized access, network security, identity management, change management, patch management, encryption, secure communications, physical security.
Article 10 — Detection: detection mechanisms, alert thresholds, monitoring of network and information system activity, ICT-related operational anomalies.
Article 11 — Response and Recovery: ICT business continuity and ICT response and recovery plans, RTO and RPO documented, testing.
Article 12 — Backup Policies, Restoration and Recovery Procedures: backup; secondary processing site for critical or important functions; restoration tested at least annually.
Article 13 — Learning and Evolving: post-incident reviews, lessons learned, continuous improvement, awareness programmes.
Article 14 — Communication: crisis communication plan for staff, customers, financial-entity counterparties, and competent authorities.

ICT-Related Incident Management (Articles 17–23)

Article 17 — Incident Management Process: documented process for detection, handling, follow-up.
Article 18 — Classification: criteria including clients affected, data loss, reputational impact, duration, geographical spread, economic impact, and criticality of services affected, per the final RTS.
Article 19 — Reporting of Major Incidents and Significant Cyber Threats: harmonized reporting to competent authorities. Three notifications per the final RTS: initial notification within 4 hours of classification but no later than 24 hours from awareness; intermediate report within 72 hours; final report within one month.
Article 23 — ICT-Related Incidents Affecting ICT Third-Party Service Providers: TPSPs notify financial entities of incidents affecting them per the contractual notification clock, typically tighter than the regulatory clock so the financial entity can meet its own deadlines.

Digital Operational Resilience Testing (Articles 24–27)

Article 24 — General Requirements: every financial entity establishes a digital operational resilience testing programme.
Article 25 — Routine Testing: vulnerability assessments, scans, scenario-based tests, performance tests, end-to-end testing, penetration testing. Frequency proportionate to risk. ICT systems supporting critical or important functions tested at least annually.
Article 26 — Advanced Testing Based on Threat-Led Penetration Testing (TLPT): applies to significant financial entities under Article 26(8) thresholds. TLPT every three years on the financial entity and on the critical TPSPs that support critical or important functions, following the TIBER-EU framework or equivalent.

ICT Third-Party Risk Management (Articles 28–44)

Article 28 — Key Principles for ICT Third-Party Risk Management: pre-contractual due diligence, ongoing monitoring, exit strategies, contractual arrangements compliant with Article 30.
Article 29 — Preliminary Assessment of ICT Concentration Risk and Further Arrangements: financial entity considers concentration risk when entering ICT third-party arrangements supporting critical or important functions; maintains a register of information.
Article 30 — Key Contractual Provisions: mandatory contractual clauses including description of services, locations of data processing and service performance, monitoring and reporting obligations, audit rights, service levels, security obligations, incident response, sub-contracting, termination rights, and exit strategy.
Articles 31–44 — CTPP Oversight Framework: designation criteria, Lead Overseer powers, inspections, recommendations, follow-up, periodic penalty payments under Article 35.

Information Sharing (Article 45)

Voluntary cyber threat information sharing arrangements between financial entities. TPSPs may be asked to contribute via customer arrangements.

5. Minimum Requirements (Non-Negotiable) — TPSP View

Mandatory Documents

• ICT risk management framework aligned with DORA Articles 5 to 15
• ICT asset and information register with classification and interdependencies
• Sub-contractor register supporting critical or important functions of financial-entity customers
• Incident response plan with classification thresholds and the three-clock reporting workflow
• Business continuity and ICT recovery plan with RTO and RPO documented
• Exit strategy for each financial-entity customer where a critical or important function is supported
• Information register per Article 28 specifications
• Article 30 contract template aligned with financial-entity requirements
• Customer due diligence response package

Mandatory Processes

• Incident notification to financial-entity customers per contractual SLA
• Sub-contracting change notification per Article 30(3) (at least 30 days for critical or important functions)
• Annual customer due diligence cycle support
• Audit cooperation for financial-entity audits and competent authority inspections
• Exit strategy testing on schedule

Technical Controls

• Strong authentication including MFA for privileged and customer access
• Encryption in transit and at rest with documented key management lifecycle
• Network segmentation and boundary protection
• Centralized logging and monitoring with sufficient retention
• Vulnerability and patch management
• Backup and disaster recovery tested at least annually

6. Technical Implementation Guidance

Build on ISO 27001 / SOC 2 Foundation

DORA aligns substantially with ISO 27001:2022 Annex A and SOC 2 Trust Services Criteria. For a TPSP already operating an ISMS, the DORA-specific extensions are: incident classification thresholds and harmonized reporting templates; ICT third-party risk register with sub-contractor information; exit strategy testing; TLPT readiness; Article 30 contractual provisions.

Incident Classification & Reporting Workflow

• Implement harmonized incident classification logic per the final RTS
• Document the three-clock reporting workflow: initial notification within 4 hours of classification (no later than 24 hours from awareness); intermediate report within 72 hours; final report within one month
• Pre-draft customer notification templates per the contractual clock

Exit Strategy

• Document per major financial-entity customer: data extraction procedures, format, timeline, transition support, knowledge transfer obligations
• Test the exit strategy at least every two years; retain test evidence

Sub-Contracting Discipline

• Maintain the sub-contractor register per Article 29
• Flow DORA-relevant contractual provisions to sub-contractors supporting critical or important functions
• Notify financial-entity customers in advance of sub-contracting changes per Article 30(3)

TLPT Readiness

• For TPSPs supporting critical or important functions of significant financial entities, expect to participate in TLPT every three years
• TLPT follows the TIBER-EU framework: threat intelligence, red team, blue team, purple team, replay
• Coordinate with the financial entity's TLPT lead and the appointed testing provider; see our penetration testing service

7. Policy & Procedure Requirements

• ICT Risk Management Framework Policy
• ICT Asset Management Policy and Procedure
• Identification, Protection, Detection, Response, Recovery, and Learning Procedures
• Incident Response Plan with DORA classification thresholds and three-clock reporting workflow
• ICT Business Continuity and Disaster Recovery Plan
• Backup, Restoration and Recovery Procedure
• Crisis Communication Plan
• ICT Third-Party Risk Management Policy
• Sub-Contractor Register and Sub-Contracting Authorization Procedure
• Exit Strategy per Financial-Entity Customer or master template
• Customer Due Diligence Response Procedure
• Information Sharing Arrangement where entered

8. Audit Evidence & Verification — TPSP View

DORA does not certify TPSPs. Compliance is demonstrated through:

• Documented ICT risk management framework with management body approval
• ICT asset and information register
• Sub-contractor register
• Incident management records and reporting templates
• Business continuity and disaster recovery test reports
• Exit strategy test report
• Vulnerability assessment, scan, and penetration test reports
• Article 30 contract templates and signed customer agreements
• Customer audit cooperation evidence
• For CTPPs only: Lead Overseer recommendations and follow-up evidence

Common Remediation Items

• Exit strategy missing or untested for major financial-entity customers
• Sub-contractor register incomplete or stale
• Customer contracts pre-DORA and missing Article 30 provisions
• Incident classification thresholds not aligned with the final RTS
• Audit rights not extended to sub-contractors
• ICT risk management framework lacks evidence of management body approval and annual review

9. Implementation Timeline Considerations

Typical Duration — TPSP

• TPSP with mature ISO 27001 ISMS: 3 to 5 months to DORA readiness
• TPSP without an ISMS: 9 to 12 months including ISO 27001 foundations
• CTPP designation track: continuous, with annual Lead Overseer engagement once designated

Milestones

• Customer base mapping and TPSP classification
• Article 28 contract gap analysis
• ICT risk management framework build
• Incident management workflow with three-clock reporting
• Sub-contractor register and exit strategy documentation
• Customer due diligence response package
• vCISO operations cycle for ongoing maintenance

10. Ongoing BAU Requirements

• Annual ICT risk framework review
• Annual business continuity and DR test
• Annual vulnerability assessment and scenario test
• Penetration testing on risk-driven cadence (annual is common)
• TLPT every three years for TPSPs supporting critical or important functions of significant financial entities
• Incident reporting workflow rehearsed
• Sub-contractor register refresh and notification of changes
• Customer due diligence response cycle
• Article 30 contract renewal alignment

11. Maturity Levels

Minimum Compliance

• ICT risk framework documented
• Article 30 contract template in customer paper
• Incident response with three-clock workflow
• Exit strategy documented for top customers

Intermediate

• ISO 27001 ISMS extended with DORA articulations
• Automated incident classification
• Sub-contractor lifecycle managed in supplier risk platform
• TLPT-ready posture

Advanced

• Integrated DORA + ISO 27001 + SOC 2 + NIS 2 evidence library
• Continuous control monitoring with real-time evidence
• Automated customer due diligence response
• Full CTPP-tier readiness even if not designated

12. FAQs

Are we in scope of DORA?

If you are a financial entity in any of the twenty Article 2(1) categories, yes directly. If you are an ICT third-party service provider selling to those entities, DORA reaches you through the Article 30 contractual flow-down and the supply chain risk management framework your customers are required to apply.

What is a Critical ICT Third-Party Service Provider?

A TPSP designated by the ESAs based on Article 31 quantitative criteria including systemic impact, criticality of entities served, reliance, substitutability, and concentration. The first designations were expected from 2025. CTPPs fall under direct Lead Overseer oversight including inspections and periodic penalty payments under Article 35.

How fast do incidents need to be reported?

For financial entities: initial notification within 4 hours of classification (no later than 24 hours from awareness); intermediate report within 72 hours; final report within one month. For TPSPs: per the contractual notification clock in the customer agreement, typically faster than the regulatory clock so the financial entity can meet its own deadlines.

What is TLPT and does it apply to us?

Threat-Led Penetration Testing under Article 26 applies to significant financial entities every three years. TPSPs supporting critical or important functions of those entities are in scope and must agree to participate. See our penetration testing service.

What is the exit strategy requirement?

Article 28(8) requires financial entities to have an exit strategy for each ICT third-party arrangement supporting critical or important functions. As a TPSP, you support this by documenting data extraction procedures, format, timeline, transition support, and knowledge transfer. The strategy is tested at least every two years.

How does DORA relate to NIS 2?

DORA is lex specialis for financial entities. Article 1(2) provides that DORA applies to ICT-related incidents and cyber threats notwithstanding NIS 2 for financial entities in scope. For TPSPs serving both financial entities and other NIS 2 in-scope sectors, both frameworks apply to the relevant customer relationships. See our NIS 2 service.

How does DORA relate to ISO 27001?

ISO 27001 is a certifiable ISMS standard with substantial overlap with DORA ICT risk management. Holding ISO 27001 reduces the DORA gap substantially but is not equivalent. DORA-specific extensions are required: incident classification per the final RTS, three-clock reporting workflow, sub-contractor register, exit strategy testing, Article 30 contractual provisions.

How does DORA relate to SOC 2?

SOC 2 attestation reports are widely consumed by financial-entity customers as evidence of operational controls. DORA does not replace SOC 2; financial entities may continue to require a SOC 2 Type 2 report alongside DORA-specific evidence. A Type 2 report covering the DORA-relevant period accelerates customer due diligence substantially.

What are the penalties?

For financial entities, penalties are set in member state law per Article 50. For CTPPs, the Lead Overseer can impose periodic penalty payments under Article 35 up to one percent of average daily worldwide turnover for each day of non-compliance, capped at six months.

13. Summary

DORA is the EU's unified ICT risk framework for the financial sector with explicit and detailed flow-down to the ICT third-party service providers the sector depends on. For a B2B SaaS or consulting firm selling into EU financial entities, DORA arrives through Article 30 contractual provisions, the incident notification clock, sub-contracting transparency, exit strategy testing, and customer due diligence. The path to readiness leverages ISO 27001 or SOC 2 foundations and extends them with DORA-specific articulations. Where you are designated as a Critical ICT Third-Party Service Provider, oversight by the ESAs Lead Overseer regime adds direct regulatory engagement.

To scope an engagement, book a call from the DORA compliance service page, or talk to us about combining DORA with ISO 27001, SOC 2, NIS 2, or a complete vCISO program for ongoing supply chain compliance.