DORA Framework: Structure, Pillars, and Practical Impact
DORA is not a checklist. It is a legally binding framework that reshapes how financial entities across the EU manage digital operational resilience, evidence controls, report incidents, test resilience, and govern ICT third-party risk.
Trusted by 100+ organisations across Europe
DORA 
ICT Risk 
Article 30 
TLPT What you need to know about the DORA framework
- The DORA framework is built on five mandatory pillars: ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing.
- The management body is directly accountable under Article 5 for approving and overseeing the ICT risk management framework. This cannot be delegated away.
- Major ICT incidents require a structured reporting workflow, including initial notification, intermediate reporting, and a final report with root cause analysis and lessons learned.
- Every ICT contract covering a critical or important function must include the mandatory clauses set out in DORA Article 30. Legacy contracts must be reviewed and updated.
- Significant financial entities must conduct threat-led penetration testing (TLPT) at least every three years, following the TIBER-EU framework or an equivalent recognised framework.
- Proportionality applies to smaller entities under Article 4, but this means simplified controls, not absent controls. Evidence is still required.
- StartComply maps DORA activities to articles, owners, controls, and evidence so teams can prove compliance instead of rebuilding records after the fact.
Sources: DORA Regulation, EIOPA DORA overview. Last updated May 2026.
DORA is a framework. Regulators expect proof, not policy theatre.
A documented, article-mapped, continuously evidenced framework
- Article 5 governance accountability at management body level
- Articles 5 to 16 ICT risk management framework with annual review and control evidence
- Articles 17 to 23 incident classification, escalation, and regulatory reporting workflow
- Articles 24 to 27 resilience testing, including TLPT for significant entities
- Articles 28 to 44 ICT third-party risk management, register, monitoring, and Article 30 contracts
Penalty exposure: DORA enables supervisory measures, periodic penalty payments, and direct sanctions for critical ICT third-party providers. Source: DORA Regulation.
Policies, spreadsheets, contracts, and evidence scattered everywhere
- No single ICT asset inventory mapped to critical or important functions
- Incident workflows that depend on email chains during a live crisis
- Article 30 contract gaps hidden across legacy ICT agreements
- Testing evidence disconnected from remediation owners and deadlines
- Third-party registers that are incomplete, outdated, or not regulator-ready
- No board-level decision trail showing review, challenge, approval, and follow-up
The audit reality: regulators do not just ask whether a framework exists. They ask for files, dates, owners, decisions, test results, contract clauses, and remediation evidence.
The Five DORA Pillars in One Evidence Platform
ICT Risk Management
Articles 5 to 16 form the foundation of the DORA framework. StartComply helps you document governance, classify ICT assets, map controls, and maintain a continuously updated evidence trail.
- Management body accountability mapped to Article 5 responsibilities
- ICT asset inventory linked to critical and important functions
- Protection, detection, response, recovery, and learning workflows
- Annual review records, sign-offs, and control evidence
Incident Management and Reporting
DORA requires financial entities to classify ICT-related incidents and report major incidents through strict regulatory timelines. StartComply gives teams the workflow, ownership, and audit trail needed during a live incident.
- Major incident classification workflow aligned to DORA reporting criteria
- Initial notification workflow for 4-hour classification and 24-hour awareness windows
- 72-hour intermediate report and one-month final report tracking
- Root cause analysis, lessons learned, and remediation evidence
Digital Operational Resilience Testing
Articles 24 to 27 require entities to test ICT tools, systems, and processes. StartComply connects testing plans, findings, remediation tasks, and evidence in one place.
- Annual testing programme for ICT tools and systems
- Vulnerability assessments, network security analyses, and scenario-based tests
- TLPT planning support for significant financial entities
- Remediation ownership, due dates, and closure evidence
ICT Third-Party Risk Management
Articles 28 to 44 create one of DORA’s most demanding pillars. StartComply automates third-party assessments, ICT register maintenance, contract gap tracking, and ongoing provider monitoring.
- ICT third-party register for all relevant arrangements
- Critical or important function mapping before contract approval
- Article 30 contractual clause gap analysis
- Sub-outsourcing visibility and continuous risk monitoring
Information Sharing Arrangements
Articles 45 to 49 allow voluntary cyber threat intelligence sharing through trusted arrangements. StartComply helps teams keep participation structured, documented, and aligned with governance expectations.
- Information sharing records linked to cyber threat context
- Governance review before joining trusted sharing communities
- Documentation of shared indicators, decisions, and follow-ups
- Evidence of policy alignment and responsible participation
DORA Framework Requirements vs. Audit Evidence
DORA is easier to manage when every pillar is connected to the evidence regulators will expect during supervisory review.
StartComply connects the DORA framework to operational evidence, so compliance teams can prove what was reviewed, approved, tested, remediated, and monitored.
What the DORA Framework Actually Covers
DORA applies to more than 20 categories of financial entity, including credit institutions, investment firms, payment institutions, insurance undertakings, and crypto-asset service providers. It also brings ICT third-party service providers, including cloud providers, into scope under a direct oversight regime managed by the European Supervisory Authorities.
The regulation is built on five pillars. Each pillar has its own chapter in the regulation, its own set of articles, and its own audit trail requirements. The pillars are interdependent. A weakness in your ICT risk management framework can cascade into failures in incident reporting, testing, and third-party oversight.
The framework is also tiered. Proportionality applies to microenterprises and smaller entities under Article 4, which allows a simplified ICT risk management framework. But proportionality does not mean optional. Simplified does not mean absent. Your organisation still needs to implement, document, and evidence controls, even if the depth of those controls is scaled to your size.
One framework, five connected pillars. StartComply maps controls, evidence, owners, deadlines, and remediation activity directly to DORA’s structure so your programme is audit-ready from day one.
How StartComply Operationalises the DORA Framework
Approve the ICT risk framework Article 5
Define management body accountability, governance cadence, ICT strategy ownership, budget visibility, and decision records. StartComply keeps board-level evidence attached to the relevant DORA articles.
Map ICT assets and functions Article 8
Maintain a current inventory of ICT assets, systems, providers, and dependencies that support critical or important functions. Evidence is updated as the environment changes.
Operate the ICT risk lifecycle Articles 9 to 14
Run protection, detection, response, recovery, and learning activities as one workflow. Policies, controls, incidents, recovery objectives, and lessons learned stay connected.
Manage major ICT incidents Articles 17 to 23
Classify incidents, trigger reporting tasks, assign owners, and track initial, intermediate, and final report evidence against DORA’s strict timelines.
Evidence operational resilience Articles 24 to 27
Plan vulnerability assessments, scenario testing, and TLPT where required. Findings flow into corrective actions with owners, deadlines, and closure evidence.
Control ICT third-party risk Articles 28 to 44
Assess providers before signing, maintain the ICT third-party register, monitor risk continuously, and track Article 30 contract gaps until closure.
Document threat intelligence sharing Articles 45 to 49
Record governance approvals, sharing arrangements, cyber threat intelligence exchanged, and follow-up decisions in one traceable evidence trail.
Client Testimonials
“We evaluated enterprise platforms costing 10x more. StartComply does what we need at a price that makes sense.”Elena Kowalski
“Finally, a compliance tool that understands European regulations. StartComply got us audit-ready in weeks, not months.”Maria Papadopoulou
“The AI policy engine alone saved us hundreds of hours. And the third-party risk management is exactly what DORA requires.”Thomas Müller
Frequently Asked Questions About the DORA Framework
What is the DORA framework and who does it apply to?
The DORA framework is the Digital Operational Resilience Act, a European Union regulation that applied from 17 January 2025. It applies to over 20 categories of financial entity operating in the EU, including banks, insurers, investment firms, payment institutions, and crypto-asset service providers. ICT third-party providers that support critical functions, including major cloud providers, also fall under a direct supervisory oversight regime managed by the European Supervisory Authorities. Financial entities in scope must be able to evidence compliance, not just describe it.
How many pillars does the DORA framework have?
The DORA framework is structured around five pillars: ICT risk management (Articles 5 to 16), ICT-related incident management and reporting (Articles 17 to 23), digital operational resilience testing (Articles 24 to 27), ICT third-party risk management (Articles 28 to 44), and information sharing arrangements (Articles 45 to 49). Each pillar carries distinct obligations, and the pillars are interdependent.
What is the difference between the DORA framework and NIS2?
NIS2 is a cybersecurity directive that applies broadly across critical sectors, including energy, transport, healthcare, and financial services. DORA is a sector-specific regulation that applies to financial entities and their ICT service providers. Where both apply to a financial entity, DORA takes precedence as the more specific instrument under the lex specialis principle. DORA is more prescriptive around Article 30 contracts and TLPT under Article 26.
Does the DORA framework apply to smaller financial entities?
Yes, but with proportionality. Article 4 of DORA allows microenterprises and certain smaller entities to apply a simplified ICT risk management framework. However, proportionality does not mean exemption. Smaller entities must still implement controls, evidence their risk management activities, report major incidents within the required timelines, and maintain contractually compliant ICT third-party agreements.
What are the fines for non-compliance with the DORA framework?
Fines under DORA depend on the competent authority in each member state. The regulation sets a framework for supervisory powers, including periodic penalty payments of up to 1% of average daily worldwide turnover for continued non-compliance. For critical ICT third-party providers under direct ESA oversight, fines can reach €5 million or 1% of total annual worldwide turnover, applied daily until the breach is remediated. Management accountability can also apply depending on the jurisdiction.
How does DORA’s third-party risk framework differ from existing outsourcing rules?
DORA replaces and supersedes the EBA, ESMA, and EIOPA outsourcing guidelines that previously governed third-party arrangements in financial services. The key differences include mandatory contractual clauses codified in Article 30, a register of all ICT third-party arrangements, direct oversight of designated critical ICT third-party providers, and explicit sub-outsourcing requirements. Existing contracts must be reviewed and updated where they do not meet DORA requirements.
Stop Managing DORA with Disconnected Documents.
Who Falls Under the DORA Framework?
DORA applies to a wide range of financial entities operating in the EU and also creates a direct oversight regime for critical ICT third-party service providers. The key question is not only whether your organisation is in scope, but whether you can show documented operational resilience across ICT risk, incidents, testing, providers, and governance.
DORA is sector-specific. If your financial entity also falls under NIS2, DORA generally operates as the more specific framework for ICT risk and incident obligations.
DORA Compliance Timeline: Where Things Stand Now
DORA was published in the Official Journal as Regulation (EU) 2022/2554 on digital operational resilience for the financial sector.
DORA entered into force. Financial entities had a transition period to prepare governance, risk management, reporting, testing, and third-party controls.
DORA became applicable. In-scope financial entities were expected to have operational resilience controls, registers, reporting workflows, and evidence ready.
Competent authorities and the European Supervisory Authorities continue building supervisory activity, technical standards, and oversight processes for DORA implementation.
Enforcement is live. Organisations that still rely on disconnected documents, outdated registers, and manual incident workflows are carrying active regulatory risk.
Operating in EU financial services? By now, your DORA framework should include scope classification, ICT asset mapping, Article 30 contract coverage, an ICT third-party register, incident reporting workflow, testing plan, and remediation evidence.
The 10 Components of a Complete DORA Framework Implementation Plan
A working DORA framework is more than a policy document. It contains ten components, each with a clear owner, a defined cadence, and the evidence trail regulators expect.
Scope and applicability
Identify the legal entities, licences, financial activities, ICT dependencies, and third-party services that bring the organisation into DORA scope.
Governance model
Define management body responsibilities, approval cadence, committee ownership, escalation routes, and evidence expectations under Article 5.
ICT asset inventory
Maintain a current inventory of ICT assets, systems, data flows, and services that support critical or important functions.
Risk management controls
Map protection, detection, response, recovery, and learning controls to DORA Articles 9 to 14 with owners and review dates.
Incident classification workflow
Create a process for classifying ICT-related incidents, escalating major incidents, and producing initial, intermediate, and final reports.
Resilience testing programme
Plan annual testing, vulnerability assessments, scenario exercises, and TLPT where required for significant entities.
ICT third-party register
Document all ICT third-party arrangements, supported functions, data processed, locations, sub-outsourcing, and criticality.
Article 30 contract review
Assess ICT contracts for mandatory clauses, audit rights, data location, termination, cooperation, and portability obligations.
Continuous monitoring
Monitor ICT assets, incidents, third-party providers, remediation actions, and changing risk signals throughout the lifecycle.
Evidence and reporting pack
Keep board papers, approvals, test results, incident reports, risk decisions, contract reviews, and remediation records ready for audit.
