A quarterly operational risk report that takes four months to produce is already a DORA problem, and nobody has opened the regulation yet. By the time the report lands, two newer quarters of incidents, supplier changes and control failures have happened. The Digital Operational Resilience Act, Regulation (EU) 2022/2554, has applied since 17 January 2025, so the open question for most financial entities is no longer when to start. The question is whether their data, owners and processes can answer a supervisor within hours instead of months.
The short answer is to build one maintained dependency model that links each critical or important function to its information, ICT assets, providers, contracts, incidents and test results, and then run the five DORA chapters on top of it. The chapters cover ICT risk management, incident management and reporting, resilience testing, ICT third-party risk, and information sharing. Most of the effort sits in the links between those chapters. A firm that treats them as five projects ends up with five registers that disagree with each other.
This guide is for risk owners, compliance officers, internal auditors and security leads who have to turn the regulation into working procedures. It follows the order in which a program usually runs, and it separates what the regulation requires from what is a sensible implementation choice. It also corrects several statements that circulate in conference slides and vendor material, such as the idea that DORA requires threat-led penetration testing from every firm.
What Does DORA Require of Financial Entities?
DORA is an EU regulation on digital operational resilience for the financial sector. It is directly applicable in every member state without national transposition, it entered into force on 16 January 2023, and it has applied since 17 January 2025. Its stated aim is that financial entities can withstand, respond to and recover from all types of ICT-related disruption and threat. That is a wider target than cybersecurity, because a failed software release, a provider outage and a corrupted data feed all count. A companion directive, Directive (EU) 2022/2556, amends existing financial sector laws so they line up with DORA.
The regulation is organized into five functional areas. The first is ICT risk management, which starts at Article 5 and includes the identification duties in Article 8. The second is the management, classification and reporting of ICT-related incidents, in Articles 17 to 23. The third is digital operational resilience testing, in Articles 24 to 27, which includes threat-led penetration testing, usually shortened to TLPT. The fourth is the management of ICT third-party risk, which begins at Article 28 and also contains the EU oversight framework for critical providers. The fifth is the voluntary sharing of cyber threat information, in Article 45.
The regulation sets the obligation and a set of delegated and implementing regulations set the detail, so you need to read both. Delegated Regulation (EU) 2024/1774 covers the ICT risk management framework. Delegated Regulation (EU) 2024/1772 sets the criteria for classifying incidents. Delegated Regulation (EU) 2025/301 sets the content and time limits for incident reports, and Implementing Regulation (EU) 2025/302 provides the templates. Delegated Regulation (EU) 2025/1190 covers TLPT. Anyone who builds a procedure from the Level 1 text alone will miss thresholds, data fields and deadlines that auditors will test.
Accountability sits at the top. Article 5 makes the management body responsible for ICT risk, including approval and oversight of the ICT risk management framework. That has a practical consequence for how you report: a quarterly paper that lists policy status will not show a board whether any critical or important function can be recovered. DORA also has a proportionality principle and a simplified framework for certain smaller, low-risk entities, but an established bank, insurer or payment firm should plan for the full framework unless its competent authority says otherwise. Check your entity type before you assume a lighter regime applies.
Two clarifications save a lot of confusion. For financial entities, DORA is the specialist rule, so its incident regime applies in place of the general NIS2 reporting regime. And no part of DORA requires a particular GRC platform, a certificate or a single enterprise taxonomy. ISO/IEC 27001 is a useful reference for running an information security management system, but DORA uses its own terms and its own obligations, so a certificate does not by itself show compliance. Judge every tool and every standard by the evidence it produces for the articles above.
Why Do DORA Programs Stall in the First Year?
They stall on data and ownership, and rarely on a lack of understanding of the regulation. Many firms run legacy, heavily customized systems that operate in silos with little integration. Workflows differ by team, methods are applied inconsistently, and data quality is poor. DORA then asks questions that cut across all of those silos at once: which function depends on this provider, which assets support that function, and how fast can you tell the supervisor?
Consider a composite situation, offered as an illustration with assumed numbers and not as a documented engagement. A mid-sized insurer needs four months to assemble its quarterly risk report. The arithmetic is unforgiving: the report for the quarter ending 31 March is ready around the end of July, and by then the quarter ending 30 June is already closed and waiting. The team is permanently compiling data that is at least four months old, and two reporting cycles overlap at all times. A supervisor who asks for the current dependency picture of a payment function gets an answer that describes the firm as it was in the spring.
Gap assessments tend to turn up the same findings in firms like this one. There are several overlapping documents for incident management, sometimes six or more, and they contradict each other on who declares an incident and when. The configuration database tracks hardware and software but has no field for physical location or the business function an asset supports. Operational incidents and security incidents follow separate processes, so early triage becomes an argument about whose incident it is. Nobody holds the baseline numbers, such as total clients served through each branch, app and ATM channel, that are needed to calculate impact thresholds when something breaks.
Each of those findings maps to a specific obligation. Missing location and function data defeats the identification duty in Article 8. Conflicting incident procedures defeat the documented process required by Article 17. Missing baselines make it impossible to apply the classification criteria in Delegated Regulation 2024/1772 inside the reporting deadlines. A reader who sees this mapping stops treating DORA as a documentation exercise and starts treating it as a data engineering problem with legal deadlines attached.
The decision rule is simple. Before you buy or configure a tool, run a gap assessment against the five chapters and score each requirement by evidence, not by whether a policy exists. A policy that no process follows scores zero. Assign every gap to a named owner, usually the head of operational risk, the chief information security officer, the head of third-party management or the compliance lead, and give it a due date. Keep the gap register as audit evidence, because it shows the management body that the program started from facts.
How Do You Map Critical or Important Functions to ICT Assets?
Start from the business function and work down. A hardware and software inventory cannot show that a payment service can survive a failure, because it says nothing about what the service needs in order to run. Article 8 requires you to identify, classify and document business functions, the information and ICT assets that support them, their dependencies, and the interconnections with third-party providers. Use DORA's own term, critical or important functions, which covers functions whose disruption would materially impair financial performance, the soundness or continuity of your services, or your continued compliance with authorization and financial services obligations. Classify by business impact, never by technology spend or application popularity.
A practical top-down chain runs from the legal entity to the function, then to the business processes and operational steps, then to applications, ICT services and information assets, then to shared infrastructure, and finally to locations, providers, contracts and relevant subcontractors. Present it as a hierarchy but store it as a many-to-many model, because one application supports several functions and one function depends on several applications, providers and locations. Hold workshops with business owners, operations, ICT, risk and compliance, and walk through how the function really operates. A payment function, for instance, might receive an instruction, authenticate it, screen it, authorize it, execute it, reconcile it and report it, and each step has its own applications, data, external services and manual workarounds. Record the recovery time and acceptable data loss that the business impact analysis supports for each function.
Then check the model from the bottom up. Business owners know deadlines and workarounds, but they rarely know the hidden technical dependencies. Architecture records show the intended design and often differ from production. Discovery tools and cloud inventories show what is deployed and which connections exist, though traffic alone does not tell you what matters to the business. Reconcile all four sources, and send every discrepancy to a named owner. Useful exception reports include assets that were discovered but not mapped, critical functions without a recovery plan, and supplier contracts with no linked service.
Do not stop at connections. A line between Application A and Provider B explains nothing about recovery. The fields in the table below turn a diagram into something a recovery team can use, and they are recommended extensions to the mandatory asset records, not requirements of the regulation.
| Dependency field | Question it answers |
|---|---|
| Direction | Does A need B, or does B need A? |
| Failure effect | Does a failure stop the function, degrade it or delay it? |
| Workaround | Can staff operate manually, for how long and at what capacity? |
| Recovery sequence | What must be restored before this component can work? |
| Evidence and confidence | Was the link observed technically, confirmed by an owner or assumed? |
| Last validation | When was the relationship checked, and by whom? |
Shared technical services cause the surprises. Identity and privileged access, DNS and connectivity, certificates and encryption keys, backup and restoration, scheduling and monitoring are all easy to leave off a function map, and a function can stop while its main application is perfectly healthy. Prioritize deep mapping for critical or important functions, but do not exclude other ICT-supported functions and assets from the identification and inventory duties. Review the classification and documentation at least yearly and after major changes, and trigger updates from change management, supplier changes and incident findings. For one selected function, an assessor should be able to follow the line from classification and owner to process, assets, locations, providers, contracts, recovery requirements and tested recovery evidence.
How Do You Meet the DORA Incident Reporting Clock?
Build one incident process that classifies, decides reportability and files within three deadlines. Once a financial entity classifies an ICT-related incident as major, Delegated Regulation 2025/301 sets the clock shown below. The incident ID, the timestamps of detection and classification, and the submission records are the evidence a supervisor will ask for first.
| Report | Deadline |
|---|---|
| Initial notification | Within four hours of classifying the incident as major, and no later than 24 hours after the entity became aware of it |
| Intermediate report | Within 72 hours of the initial notification, even if the status has not changed |
| Final report | No later than one month after the intermediate report, or after the latest updated intermediate report |
Two details trip teams up. If you did not classify the incident as major within 24 hours of becoming aware of it but do so later, the initial notification is still due within four hours of that classification. And when a deadline falls on a weekend or a bank holiday in the member state of the reporting entity, the regulation allows submission by noon on the next working day. Reports go to the competent authority in the formats set by Implementing Regulation 2025/302. Run a tabletop exercise that starts a provider outage at 17:00 on a Friday and see who files what, because that scenario exposes every gap in on-call coverage and approval paths.
Keep two decisions separate, and record them separately. The first is internal severity, which drives who is woken up and how much effort the response gets. The second is regulatory reportability, which depends on the classification criteria in Delegated Regulation 2024/1772, such as clients affected, duration and downtime, geographic spread, data losses and economic impact. A common enterprise severity scale must not replace the DORA assessment, because an incident can be minor by your internal ranking and still meet a reporting threshold. Both decisions hang off one incident ID, so nobody counts the same event twice.
The classification criteria only work if you hold the baselines behind them. To state what share of clients an incident affected, you need the total number of clients per product and per channel, including physical channels such as branches and ATMs, and you need that number before the incident, not during it. The same applies to transaction volumes, the services in scope and the locations involved. Assign ownership of those baselines to a named role, refresh them on a schedule, and test the calculation with last year's real incidents. A firm that has never recalculated a historical incident against the current thresholds does not yet know whether it can meet the four-hour limit.
Merge the procedures. If six documents describe incident handling, retire five and keep one, with a single triage path for operational and security events and a defined handoff to the reporting team. Link each incident record to the affected assets, the supplier service, the business function and any control that failed, so that the risk team can reassess the related scenario without rekeying data. Article 13 expects incidents to produce lessons that improve the framework, but do not change policy automatically after every event. First decide whether the cause was an inadequate requirement, poor implementation, a control that failed to operate, an unrecognized dependency, or an accepted risk that materialized, since each cause calls for a different fix. The head of incident management owns the process, compliance owns the reportability call, and internal audit should sample closed incidents to check that both decisions were made on time.
How Should You Manage ICT Third-Party Providers Under DORA?
Begin with a register that ties every ICT arrangement to the function it supports. Article 28 requires a formal ICT third-party risk strategy and a register of information covering all contractual arrangements for ICT services, and it requires you to keep that register current. The register is more granular than a typical vendor list. Expect to collect legal entity identifiers, headquarters locations, the services provided, the functions each service supports, and details of subcontractors along the supply chain. Supervisors use it, and the European Supervisory Authorities used the registers submitted by financial entities as a data source when they assessed which providers to designate as critical.
The scope is wider than traditional outsourcing. DORA covers all ICT services, so a software license, a data feed and a managed security service count alongside a classic outsourced operation. For banks, parts of this overlap with the earlier EBA outsourcing guidelines, but the DORA perimeter is broader. Producing a list of ICT providers is the easy part. Separating the providers that support critical or important functions from the rest is the work that matters, because the strictest rules attach to those. Tag every arrangement with the functions it supports and the date someone last confirmed the tag.
For arrangements that support critical or important functions, Article 30 requires specified contract content. It covers service levels, access, inspection and audit rights for the financial entity and the authorities, provider contingency plans and security measures, cooperation with your TLPT where it applies, and exit arrangements. Due diligence before signing should cover the provider's insolvency law, data protection provisions and concentration risk. Do not accept a certificate or an independent audit report as an automatic substitute for your own assurance. Such reports can be evidence, but they show nothing about whether your configuration and your recovery path were tested. Pooled audits can be appropriate, provided you keep your contractual rights and your own responsibility.
The word critical carries two meanings in DORA, and mixing them up causes bad scoping decisions. A provider that supports your own critical or important function is critical to you, whatever its size. A critical ICT third-party provider, in the formal sense, is one that the European Supervisory Authorities designate, and they published the first list of designated providers on 18 November 2025. Designated providers sit under direct EU oversight by a lead overseer, who can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover for each day of non-compliance, for no more than six months. That framework exists because a single bank has little bargaining power to negotiate bespoke terms with a very large technology provider. It does not move your responsibility to the supervisors, and a provider outside the designated list can still stop your payment function.
Look for shared failure points across suppliers, because a supplier-by-supplier review misses them. Ask whether two apparently independent providers use the same cloud region, whether your recovery environment depends on the same identity service as production, and whether several critical functions rely on one managed service provider. Ask whether an alternative supplier uses the same material subcontractor. Set a decision rule for new arrangements: do not approve a provider for a critical or important function until the business owner can state the exit path, the realistic substitute and the time the move would take. Escalate to the management body when a contract for such a function lacks audit access or TLPT cooperation and the provider will not agree to add it.
How Do You Include Providers in Resilience Testing and TLPT?
Test the function and treat the vendor as one of its dependencies. Article 25 requires a risk-based testing programme, and Article 26 and Article 27 set out the separate TLPT regime. The most common misreading is that TLPT applies to everyone. It does not: only financial entities identified by their competent authority must carry out TLPT, at least every three years, based on factors such as systemic importance and ICT risk profile. Confirm with your authority whether you have been identified, and do not wait for the notice before you prepare.
TLPT is an intelligence-led, controlled adversarial test of live production systems that support critical or important functions, and the authority validates the scope. It is not a larger vulnerability scan, and a tabletop exercise or an ordinary penetration test is not equivalent. Delegated Regulation 2025/1190 has applied since 8 July 2025 and sets the detailed process. Testers are contracted under Article 27, and when an entity uses internal testers it must contract external testers every three tests. After the test, you notify the authority of the attestation, a summary of the relevant findings and the remediation plans. This regime collides with a policy that many firms still hold, which is a ban on testing in production. Production is the point of TLPT, so the policy needs a controlled exception built from a control team that knows the exercise, rules of engagement, stop conditions and emergency contacts. Most of the security team normally stays uninformed, because the exercise measures real-time detection.
Providers are where TLPT gets difficult. When a provider falls inside the TLPT scope, you must take the measures and safeguards needed to secure its participation, which is why the contract matters. An audit clause does not grant permission for intrusive technical testing, so agree a written authorization process, permitted targets, prohibited actions, named contacts and a way to stop the test. Add procedures for telling a real attack from test activity without spoiling the exercise. Where a provider serves many customers, Article 26 allows pooled TLPT, and the technical standards expect at least one scenario that covers the provider's underlying systems supporting the participating entities. Before you rely on a pooled test, confirm that your contracted service and your business dependencies were actually represented, and that you receive findings and remediation evidence you can use.
Most of your testing will be ordinary resilience testing, and the scenarios should challenge the business dependency. Useful scenarios include a provider outage at a settlement deadline, compromise of the provider's privileged access, data corruption replicated into backups, simultaneous failure of primary and recovery environments that share a dependency, a provider that cannot supply incident information in time for you to report, and failure of a material subcontractor. Agree the success criteria before each test. Define the business outcome to restore, the recovery time and data-loss objectives, the minimum acceptable capacity, the decision and escalation times, the integrity checks and the conditions for declaring failure. A test passes when the function resumed with usable data and working integrations, and a provider restarting a server proves very little.
Testing is incomplete until findings are corrected or escalated. Record each finding against the affected function, the provider service and the control that failed. Assign an owner on your side and on the provider's side, set a date, assess the business impact while the weakness exists, and retest to confirm closure. Escalate overdue or ineffective actions through the supplier management line to the management body. Keep the scenario design, authorizations, execution evidence, recovery measurements and closure evidence together per function, because an assessor will follow that chain.
What Does DORA Expect on Threat Intelligence Sharing?
Article 45 gives financial entities a legal basis to exchange cyber threat information and intelligence with each other, and the arrangements are voluntary. DORA does not prescribe data formats. In practice the useful material includes technical indicators of compromise such as malicious IP addresses and file hashes, together with the tactics, techniques and procedures that describe how an attacker works, including phishing patterns. The regulation expects the exchange to take place within trusted communities and to protect business confidentiality and personal data. Banking associations with active cybersecurity teams are a natural home for these exchanges, though insurers and smaller entities can join sector communities too.
This chapter is the least used in practice, even though the data is already available through industry peers. The usual cause is a lack of ownership rather than a lack of interest. Nobody is assigned to read what peers share, nobody can approve what the firm may share, and the legal team has not decided what counts as safe to release. The fix is a short operating model. Name an owner, usually the head of threat intelligence or the chief information security officer. Have legal and the data protection officer pre-approve categories of data that may be shared and strip customer data from everything that leaves. Define where incoming indicators go, so that detection engineers load them and someone records what changed.
Connect this chapter to the others, because the value comes from reuse. Incoming intelligence should inform the scenarios you pick for resilience testing and the threat inputs used for TLPT. Your own closed incidents produce indicators and patterns that peers can use, once they are validated and sanitized. Share what you have verified and label your confidence, since unverified indicators waste the time of every member of the community. Check with your competent authority whether it expects notice of your participation in a sharing arrangement, and keep the answer on file.
Measure the practice with something other than volume. A useful indicator is the share of received indicators that reached a detection or blocking control within an agreed time. Another is the number of shared items that peers acknowledged as useful. A third is the number of test scenarios that began from shared intelligence. These are management indicators and not DORA targets, but they show an auditor that the arrangement is a working process and not a mailing list subscription.
How Do You Join Risk, Cyber and Supplier Data Without One Giant Database?
Unify the language and the governance, and leave the operating systems where they are. DORA requires a documented ICT risk management framework inside the entity's overall risk management, with governance in Articles 5 and 6 and third-party risk managed as an integral part of ICT risk in Article 28. It does not require one platform or one prescribed taxonomy. Cybersecurity can keep its tools, procurement its supplier system and operations its incident platform, as long as their information supports coherent identification, assessment, response, oversight and reporting. A centrally governed taxonomy with linked records is a practical way to get there, and it is a recommendation, not a legal requirement.
Define the objects first and give each a stable identifier. A business function is the outcome exposed to disruption. A risk scenario is an uncertain event with business consequences, such as a cloud outage that prevents payments before a settlement cut-off. A threat is what could trigger it, a vulnerability is a weakness that raises exposure, and a control reduces likelihood or impact. An incident is an event that happened, a finding is evidence that a requirement or control is not met, and a remediation action corrects it. A policy requirement is the internal rule that governs the activity. Keeping these apart stops teams from treating an incident category, a vulnerability and a risk scenario as interchangeable, and it lets records link to one another: function to scenario, scenario to asset and supplier service, control to policy, incident and test to finding, finding to remediation and retest.
Classify with a primary category plus extra dimensions, and keep classification apart from scoring. A ransomware attack on a managed service provider can be one record with a primary category of ICT service disruption and additional dimensions for threat type, delivery dependency, affected function, information impact and concentration. It then appears in operational, cyber and supplier reporting without three competing records and without triple counting. Hold separate governed definitions for category, impact, likelihood, control effectiveness, residual risk, incident severity and regulatory reportability. Teams that use identical labels can still produce incompatible assessments, so standardize the method as well: common impact dimensions, a stated time horizon for likelihood, agreed treatment of inherent and residual risk, control ratings that separate design, implementation and demonstrated operation, and calibration sessions where different teams score the same scenario.
Treat a single source of truth as a set of authoritative owners, not one database. Function criticality lives in the business function catalogue and the impact analysis repository. Assets and technical relationships live in the configuration database, cloud inventory or service mapping tool. Supplier contracts and services live in the contract repository and the register of information. Risk scenarios and acceptances live in the enterprise risk register, incidents in the incident platform, and test results and findings in the assurance repository. Connect them with shared identifiers, named record owners, version history, reconciliation checks and rules for resolving conflicts. Govern the taxonomy like a financial reporting structure, with an owner, versioned changes and preserved historical mappings, since a drop in reported cyber risk may only mean that someone changed a classification.
Integration must not erase independence. The management body approves the framework and oversees risk appetite, business owners decide on treatment within their authority, ICT and security teams operate controls and provide evidence, supplier management maintains provider information, risk and compliance own the method and challenge assessments, and internal audit gives independent assurance. A shared taxonomy should never let a control operator become the only approver of that control's effectiveness. Write down who may accept residual risk and for how long, who may approve policy exceptions, who may close findings and who may override an assessment. Make risk acceptances time-limited and evidence-based. Policies also have to reach the front line, since DORA implementation that stays inside the risk and compliance teams will not change how staff run daily operations.
Which Controls Should a DORA Program Put in Place?
These thirty controls are a practical implementation baseline across five domains. They are not an official DORA list or an exhaustive checklist, so apply them in proportion to your entity’s risk profile, including any eligibility for the simplified ICT risk management framework. For every control, name an owner, document the requirement, set a frequency, retain evidence, assess effectiveness and track remediation. A policy alone shows intent, and operating records and test results show the control runs.
1. Governance and Risk Foundations
| # | Control | What to implement | Evidence to retain | Typical owner | Common failure | Basis |
|---|---|---|---|---|---|---|
| 1 | Management-body accountability | Approve the ICT risk framework, resilience strategy, responsibilities and resources. Review material exposures and remediation at each board cycle, including functions whose recovery is not yet demonstrated. | Approved framework, minutes, decisions, board training records | Board, CEO, CRO | Annual approval with no exposure reporting in between | Arts. 5 to 6 |
| 2 | Integrated risk taxonomy and assessment | Use one set of definitions, impact scales, likelihood horizons and methods for operational, cyber and third-party risk. Link each risk to a function and a control. | Methodology, risk register, calibration session records | Head of operational risk | Same labels, incompatible scores; one exposure counted three times | Arts. 6, 28 (implementation method, not a prescribed taxonomy) |
| 3 | Defined ownership and independent challenge | Assign business risk owners, ICT control owners, supplier owners and escalation authorities. Keep operations, control functions and audit separate. | Accountability matrix, committee mandates, delegated authorities | COO, CRO, Head of Internal Audit | Control operator is the only approver of its own effectiveness | Arts. 5 to 6 |
| 4 | Function-to-asset dependency mapping | Identify critical or important functions. Map their information, applications, infrastructure, locations and provider dependencies as a many-to-many model. Reconcile with discovery data and the CMDB. | Owner-validated maps, asset records, change history | Business owners, Head of ICT | Application inventory exists but nothing links it to functions | Art. 8 |
| 5 | ICT risk appetite and treatment | Set impact tolerances with measurable units (hours of downtime, minutes of data loss), risk tolerance levels, treatment plans and exception escalation rules. Give every risk acceptance an expiry date. | Approved tolerances, treatment plans, risk decisions | CRO, business owners | Tolerances stated in words that nobody can test | Arts. 6, 8 |
| 6 | Independent assurance and remediation | Audit the ICT risk framework on a risk-based plan. Track findings to closure confirmed by someone other than the finding owner. Sample the other 29 controls for paper-only controls. | Audit reports, action register, closure evidence | Head of Internal Audit | Findings closed on owner say-so | Art. 6 |
2. Preventive and Detective ICT Controls
| # | Control | What to implement | Evidence to retain | Typical owner | Common failure | Basis |
|---|---|---|---|---|---|---|
| 7 | Identity and access management | Enforce least privilege, controlled privileged access, strong authentication and prompt removal at role change or exit. Recertify permissions periodically. | Access approvals, authentication settings, review and removal records | CISO, IAM lead | Leavers keep access; shared privileged accounts | Art. 9, technical standards |
| 8 | Secure configuration and hardening | Maintain approved security baselines. Detect deviations. Control unnecessary services, insecure settings and unsupported technology. | Baselines, compliance scans, exception records | Head of ICT operations | Baselines exist but drift is not measured | Arts. 7, 9 |
| 9 | Vulnerability and patch management | Discover vulnerabilities, rank by exposure and by the function the asset supports, deploy fixes and verify remediation. Record time-limited exceptions. | Scan results, patch records, approved exceptions | CISO, system owners | Ranking by score alone, ignoring business dependency | Art. 9 |
| 10 | Network security and segmentation | Segment by risk and criticality. Restrict connections, secure remote access and monitor relevant traffic. | Network diagrams, rule reviews, test results | Network security lead | Diagram does not match firewall rules | Art. 9 |
| 11 | Data protection and cryptography | Classify information. Protect confidentiality, integrity and availability with suitable encryption, key management and handling rules. Track key and certificate expiry. | Classification rules, encryption standards, key-management records | CISO, data owners | Expired certificate or lost key stops a function | Art. 9 |
| 12 | Secure development and change management | Assess security and resilience before release. Require testing, approval, segregation of duties and a tested rollback path. | Change records, security tests, approvals, rollback evidence | Head of engineering, change manager | Rollback never tested | Art. 9 |
| 13 | Logging, monitoring and anomaly detection | Collect relevant logs. Detect abnormal activity and service degradation. Route alerts to accountable responders. Test detection with known harmless events. | Logging standards, alert rules, investigations, detection test results | SOC lead | Alert rules never triggered, so detection time is unknown | Art. 10 |
3. Incident Response and Recovery
| # | Control | What to implement | Evidence to retain | Typical owner | Common failure | Basis |
|---|---|---|---|---|---|---|
| 14 | Incident recording and classification | Record every incident, assess impact and set severity. Decide DORA reportability as a separate step from internal priority, using client, duration, geographic, data loss and economic impact criteria. | Incident register, classification decisions, supporting evidence | Head of incident management, Compliance | Internal severity scale used in place of DORA criteria | Arts. 17 to 18 |
| 15 | Major-incident regulatory reporting | Run one process for initial, intermediate and final reports: 4 hours from classification (24 hours from awareness at the latest), 72 hours after the initial notification, one month after the intermediate report. Name a submitter and a backup. | Procedures, submissions, timestamps, exercise results | Compliance, Head of incident management | Weekend or late-classification cases untested | Art. 19, reporting standards |
| 16 | Incident response and crisis communication | Maintain playbooks, escalation paths and communication arrangements for staff, customers, providers and authorities. Verify contact lists on a schedule. | Playbooks, contact lists, exercise results, communication records | Head of incident management, Communications | Stale contact details | Arts. 11, 14, 17 |
| 17 | Business impact analysis and continuity | Assess disruption impact and dependencies. Define recovery time and data-loss objectives and continuity arrangements for critical or important functions, signed off by business owners. | BIA, approved objectives, continuity plans, owner sign-offs | Business continuity manager, business owners | Objectives seen only by IT | Art. 11 |
| 18 | Backup, restoration and recovery | Protect backups and keep them separated from production. Test restoration, integrity checks and recovery procedures, including restore from a point before simulated corruption. | Backup records, restore tests, measured recovery times | Head of ICT operations | Backups exist; restores never measured | Art. 12 |
| 19 | Lessons learned and framework updates | Investigate major incidents and test failures. Classify the cause (inadequate requirement, poor implementation, control failure, unrecognized dependency, accepted risk) before changing anything. Update risks, controls, training and recovery plans. | Root-cause reviews, improvement actions, revised documents | CISO, CRO | Policy rewritten after every incident without diagnosis | Arts. 6, 13 |
4. Resilience Testing and Capability
| # | Control | What to implement | Evidence to retain | Typical owner | Common failure | Basis |
|---|---|---|---|---|---|---|
| 20 | Risk-based resilience testing programme | Keep a coordinated programme covering relevant systems, threats and test methods. Test systems and applications supporting critical or important functions at least annually, where applicable. Use a function-by-test-type coverage matrix. | Test strategy, coverage matrix, schedule, results | Head of resilience testing, CISO | Testing only in non-production environments | Arts. 24 to 25 |
| 21 | End-to-end scenario and recovery testing | Exercise realistic disruptions across processes, technical dependencies and providers. Agree success criteria first and measure business recovery, not infrastructure restart. | Scenarios, results against objectives, remediation records | Business owners, Head of resilience testing | Test passes because a server restarted | Arts. 11, 24 to 25 |
| 22 | TLPT readiness and execution | Confirm with your competent authority whether you are identified. If so, run TLPT at least every three years with approved scope, qualified testers, control team, provider participation and stop conditions. If not, record the confirmation and its date. | Applicability decision, scope, authorizations, reports, remediation | CISO, Head of resilience testing | Assuming TLPT applies to everyone, or assuming it never will | Arts. 26 to 27, Reg. 2025/1190 |
| 23 | Role-based training and awareness | Train staff and senior management by role, with providers included where appropriate. Incident coordinators rehearse reporting; board members rehearse a major outage decision. | Training plans, completion records, exercise results | HR, CISO | One generic course for everyone | Arts. 5, 13 |
5. ICT Third-Party Risk Management
| # | Control | What to implement | Evidence to retain | Typical owner | Common failure | Basis |
|---|---|---|---|---|---|---|
| 24 | ICT provider and contract register | Maintain the register of information for all ICT contractual arrangements in the prescribed structure and identifiers. Reconcile with procurement and service records and tag each arrangement with the functions it supports. | Validated register, reconciliations, required submissions | Head of third-party management | Vendor list with no link to functions | Art. 28, supporting standards |
| 25 | Pre-contract due diligence | Assess capability, security, resilience, suitability and conflicts before contracting. Decide whether the service supports a critical or important function. | Assessments, approvals, service classification | Procurement, business owner | Classification decided after signature | Art. 28 |
| 26 | Mandatory contractual safeguards | Include service, location, data protection, incident support, termination and cooperation provisions. Strengthen terms for critical or important functions. | Clause assessments, executed terms, gap remediation | Legal, Head of third-party management | Legacy contracts never re-papered | Art. 30 |
| 27 | Access, audit and testing rights | For critical or important function contracts, secure access and audit rights and TLPT cooperation. Convert them into authorization procedures, named contacts and stop rules. | Clauses, authorizations, assurance plans, test arrangements | Legal, CISO | Audit clause exists but no way to authorize intrusive testing | Art. 30(3) |
| 28 | Ongoing provider and subcontractor oversight | Monitor performance, security, incidents and material subcontracting changes. Escalate deficiencies and verify corrective actions. | Reviews, metrics, notifications, supplier remediation | Supplier owners | Annual questionnaire as the only oversight | Arts. 28 to 30, subcontracting standards |
| 29 | Concentration and common-dependency analysis | Assess dependence on hard-to-replace providers, related providers and shared subcontractors, infrastructure and regions. Record a treatment decision for each concentration. | Concentration assessments, dependency analysis, decisions | CRO, Head of third-party management | Supplier-by-supplier review misses shared cloud region or identity service | Art. 29 |
| 30 | Tested exit and transition plans | For services supporting critical or important functions, document alternatives, data transfer and continuity during transition, and test feasibility. | Exit plans, feasibility assessments, test results, action records | Business owners, Head of third-party management | Exit plan never exercised | Art. 28(8) |
Sequence. Start with controls 1 to 6 and 24 to establish accountability and visibility. Then close immediate exposure with controls 7 to 19, validate with controls 20 to 22, and run controls 25 to 30 in parallel where a critical function depends on a provider with gaps. The numbering groups controls by domain and is not a risk ranking.
The Owner and Common failure columns are my additions as typical examples, so adapt them to your organization. Check each article reference against the consolidated regulation before publishing.
How Do You Phase a DORA Program Around Daily Operations?
Phase the work and keep the business running. The rigid big-bang rollout has largely given way to staged programs, and DORA demands that approach, because the deadlines are fixed while payments, claims and customer service cannot pause. Day-to-day risk programs and existing compliance obligations continue while you add the DORA layers. A sensible order follows the dependencies between the chapters: governance and ownership first, then the function and asset map, then the incident pipeline, then the provider register and contracts, then testing, and information sharing alongside once someone owns it. Each phase should deliver something an auditor can inspect, which means a register, a procedure, a test result or an approved decision.
Start with the foundation, which is a shared taxonomy, named owners and a baseline gap assessment. In the second phase, run the function workshops, reconcile the top-down map with discovery data and fix the fields the incident thresholds need. In the third, retire the competing incident documents, set up the two-decision classification and rehearse the reporting clock. The fourth phase covers the register of information, the Article 30 contract gaps and the concentration analysis. The fifth designs the testing programme from the dependency map, including a TLPT readiness plan if your authority has identified you. Taking this route builds the foundation first and extends it, so each phase reuses the work of the one before.
Use a small dashboard that tells the management body whether the mapping supports decisions under pressure. Useful indicators include the number of critical or important functions with owner-validated dependency maps, critical assets missing an owner, location or recovery information, unverified supplier and subcontractor dependencies, shared dependencies with no effective alternative, recovery requirements that testing has not demonstrated, incidents not linked to risk scenarios, and overdue remediation or expired risk acceptances. These are management indicators and not prescribed DORA percentages. Report the trend and the exceptions, and attach a named owner to each exception.
Several anti-patterns recur. Buying a platform before agreeing the data model produces an expensive copy of the old silos. Testing only in virtual environments leaves the production behavior unproven. Treating the annual review as the only update lets the map drift between exercises. Accepting provider certificates as proof of resilience leaves your own recovery path untested. And declaring the mapping finished confuses one component with the whole: mapping is a part of DORA compliance and does not prove compliance with the regulation.
Set escalation triggers in advance. Escalate when a critical or important function has no accountable owner, when its recovery requirement has never been demonstrated, when a provider refuses audit access or TLPT cooperation in a contract for such a function, or when a classification decision for a major incident was late. The escalation goes to the management body with the evidence attached and a proposed action. Technical standards and supervisory expectations keep changing, so review the program when a new delegated act, authority notice or ESA publication appears, and record the review date.
Final Perspective
The next decision in front of most programs is where to spend the next quarter's effort, and the answer is usually the links and not another policy. A function with a validated dependency map, a classification process that meets the reporting clock, a provider contract with usable audit and test rights, and a recovery test that passed on business outcomes gives you something to defend in front of a supervisor. Anything else is documentation. Expect the supervisory conversation to move from whether you have the registers to whether the registers agree with each other and with what happens during a real disruption.
Pick one critical or important function this week and trace it end to end: its owner, its processes, its assets, its providers and contracts, its recovery targets, and the last test that proved them. Write down every place the trace breaks. That list is your honest program backlog, and it will rank itself. How many of your critical functions could you trace in under a day, and who would you call first?
References
- European Parliament and Council, Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), EUR-Lex, https://eur-lex.europa.eu/eli/reg/2022/2554/oj
- European Commission, Commission Delegated Regulation (EU) 2025/301, content and time limits for reporting of major ICT-related incidents (text reproduced at https://advisera.com/cdr-2025-301/time-limits-for-the-initial-notification-and-for-the-intermediate-and-final-reports/)
- European Commission, Commission Delegated Regulation (EU) 2024/1772, classification of ICT-related incidents and significant cyber threats; Commission Delegated Regulation (EU) 2024/1774, ICT risk management framework; Commission Implementing Regulation (EU) 2025/302, reporting templates (listed at https://www.vixio.com/insights/pc-mapping-eu-legislation-regulation-eu-20222554-digital-operational)
- DORA Article 26, advanced testing based on TLPT (text reproduced at https://streamlex.eu/articles/dora-en-art-26/)
- European Commission, Commission Delegated Regulation (EU) 2025/1190, threat-led penetration testing under DORA, applicable from 8 July 2025 (summary at https://luxgap.com/lois/dora-tlpt/?lang=en)
- DORA Article 35, powers of the Lead Overseer (text reproduced at https://advisera.com/dora-regulation/powers-of-the-lead-overseer/)
- EBA, EIOPA and ESMA, The European Supervisory Authorities designate critical ICT third-party providers under the Digital Operational Resilience Act, 18 November 2025, https://www.esma.europa.eu/press-news/esma-news/european-supervisory-authorities-designate-critical-ict-third-party-providers
- A&L Goodbody, Digital Operational Resilience Act (DORA) overview, https://techreg.algoodbody.com/techreg/dora