Summary
DORA compliance requirements start with the legal entity and its regulated activities. Article 2 contains exclusions; Article 16 gives specified categories a simplified ICT regime. Small size alone does not establish an exemption. (DORA, Arts. 2–4, 16.)
Under the standard regime, the management body retains ultimate responsibility for ICT risk. Firms must maintain documented controls, recovery arrangements and evidence of review. Outsourcing does not transfer their responsibility. (DORA, Arts. 5–6, 11–12, 28(1)(a).)
Firms must record all ICT incidents and significant cyber threats, then apply the major-incident classification rules. Mandatory reporting includes initial, intermediate and final submissions with distinct deadlines. (DORA, Arts. 17–19; Delegated Regulations (EU) 2024/1772, Arts. 6, 8–9, and 2025/301, Art. 5.)
Ordinary resilience testing and advanced threat-led penetration testing have different scope and frequency rules. The advanced programme applies to identified entities, with express exclusions. (DORA, Arts. 24–27; Delegated Regulation (EU) 2025/1190, Art. 2.)
The register of information covers all contractual arrangements for third-party ICT services. Services supporting critical or important functions attract additional contract, monitoring and exit requirements. (DORA, Arts. 28–30; Implementing Regulation (EU) 2024/2956, Arts. 1–3 and Annexes.)
DORA compliance software should support the firm's applicable duties and produce usable records. A supplier's product claim cannot establish that the customer has performed its own obligations. (DORA, Arts. 5–7, 28(1)(a).)
Scope and proportionality
DORA scope follows the categories in Article 2. Covered businesses include credit institutions, payment institutions, investment firms, insurers and specified fund businesses. The list also includes crypto-asset service providers authorised under the EU markets in crypto-assets rules and issuers of asset-referenced tokens. The term "fintech" does not determine which duties apply. A group should identify each relevant legal entity and its regulatory category before assigning controls. (DORA, Art. 2(1)–(2).)
Covered crypto-asset service providers include authorised entrants and specified existing financial institutions permitted to provide services through MiCA's notification procedure. The scope assessment must distinguish the Article 63 authorisation route from the Article 60 route for those institutions. A separate new crypto licence is therefore not the sole basis for DORA coverage. (DORA, Arts. 2(1)(f), 3(55); Regulation (EU) 2023/1114, Arts. 3(1)(15), 59(1), 60.)
The exclusions need a separate check. Article 2(3) excludes specified fund managers, insurers and other categories, including qualifying smaller insurance intermediaries. Article 2(4) permits Member States to exclude certain institutions. Article 16 replaces Articles 5–15 for its listed categories, including small and non-interconnected investment firms and specified exempt payment or electronic money institutions. Those entities remain subject to the duties that Article 16 and the other applicable DORA provisions retain. (DORA, Arts. 2(3)–(4), 16; Delegated Regulation (EU) 2024/1774, Title III.)
Proportionality concerns the firm's size, risk profile and the nature, scale and complexity of its operations. It does not permit a firm to disregard an applicable obligation because implementation is expensive. Microenterprises receive specific adjustments, whose conditions differ from the Article 16 regime. A scope assessment should therefore identify the legal basis for each exclusion or adjustment. (DORA, Arts. 3(60), 4, 6(5), 16, 24–26.)
Articles 5–15 govern the standard ICT risk regime. Article 16 entities instead follow Article 16 and Title III of Delegated Regulation 2024/1774. Their simplified regime still requires documented ICT controls, incident handling, continuity measures, testing and review. (DORA, Art. 16(1)–(2).)
Management responsibility
The management body must approve and oversee the firm's ICT arrangements under the standard regime. Its responsibilities include the digital operational resilience strategy, risk tolerance, continuity and recovery plans, audit arrangements, resources and the policy for ICT providers. Members must maintain sufficient knowledge and undertake regular training appropriate to the risks they oversee. Approval records should identify decisions, responsible functions and the resources committed to implementation. (DORA, Arts. 5(2)–(4), 6(8).)
Firms other than microenterprises must assign ICT risk oversight to an appropriately independent control function and arrange regular internal audits. Article 6 requires follow-up procedures for critical audit findings. Annual review is the default for the ICT risk management framework; microenterprises review it periodically. Major incidents, supervisory instructions and relevant testing or audit conclusions also require review. The practical record should connect each identified weakness with its treatment and verification. (DORA, Art. 6(4)–(7).)
Staff training must include compulsory ICT security awareness and digital resilience modules for employees and senior management. The content must match their responsibilities. Firms must also maintain crisis communication plans, distinguish operational responders from staff who need information, and assign the public communication function. Training records and communication exercises should cover those responsibilities. (DORA, Arts. 11(6)(b), 13(6), 14.)
ICT controls and recovery
The firm must identify the business functions that depend on ICT and document their supporting assets and dependencies. Classification must address which functions are critical or important under Article 3(22). Inventory entries should connect a function with its systems, information, responsible roles and external providers. A list of software licences alone cannot satisfy the wider mapping duties. (DORA, Arts. 3(22), 8(1), (4)–(6).)
Security controls must address the risks associated with those assets. The standard regime requires controls for access, authentication, encryption, change management, patches and anomaly detection. Delegated Regulation 2024/1774 gives further requirements for the relevant policies and procedures. Implementation records should show that authorised changes were assessed, tested and approved, and that access rights and vulnerabilities receive review. (DORA, Arts. 9–10; Delegated Regulation (EU) 2024/1774, Arts. 6–10, 15–17, 20–23.)
Recovery planning must reflect the consequences of service disruption. The business impact analysis must consider functions, support processes, information assets and third-party dependencies. Firms must set recovery time and recovery point objectives for each function. Backup arrangements require documented scope and frequency, periodic tests and controls that protect restored data. Successful copying does not by itself demonstrate that the firm can restore a service within its objectives. (DORA, Arts. 11(5), 12(1)–(3), (6)–(7).)
Under Article 11(6), firms must test ICT continuity and response and recovery plans for systems supporting all functions at least yearly. Substantive changes to systems supporting critical or important functions trigger further testing. Microenterprises have a specific adjustment to the required test scenarios. Article 16 entities follow their separate testing duties. Test records should identify the service restored, elapsed recovery time, data checks and any unresolved failures. (DORA, Arts. 11(6), 16(1)(g); Delegated Regulation (EU) 2024/1774, Arts. 25–26, 39–40.)
After a major ICT incident disrupts core activities, the firm must review the causes and identify required improvements. Lessons from incidents and the advanced tests under Articles 26–27 must feed back into ICT risk assessment. Recovery records should therefore preserve findings and the actions taken to address them. (DORA, Art. 13(2)–(3).)
Incident classification
Recording and regulatory reporting have different triggers. Article 17 requires records of all ICT-related incidents and significant cyber threats. A firm must assess which incidents qualify as major under the prescribed criteria. The classification must address affected services and the applicable materiality thresholds, rather than relying solely on an internal severity label. (DORA, Arts. 17(2)–(3), 18; Delegated Regulation (EU) 2024/1772, Arts. 6, 8–9.)
An incident is major where it affects critical services under Article 6 and meets either of two additional conditions. The first is the special threshold in Article 9(5)(b): successful, malicious and unauthorised access capable of causing data losses, outside Article 9(5)(a). Alternatively, at least two other threshold categories under Article 9(1)–(6) must be met. Those categories concern clients, financial counterparts or transactions; reputation; duration or service downtime; geographical spread; data losses; and economic impact. Two subconditions within the same category do not count as two categories. (Delegated Regulation (EU) 2024/1772, Art. 8(1), read with Art. 9.)
Article 6 covers affected ICT supporting critical or important functions, affected financial services requiring authorisation, registration or supervision, and successful malicious unauthorised access. Its scope therefore extends beyond the firm's list of critical or important functions. Individually non-major recurring incidents can also qualify collectively. For entities subject to that rule, monthly assessment covers incidents occurring at least twice within six months, with the same apparent root cause. The incidents must collectively meet the major-incident criteria; microenterprises and Article 16 entities are exempt from that aggregation rule. (Delegated Regulation (EU) 2024/1772, Arts. 6, 8(2).)
Credit institutions, payment institutions, account information service providers and electronic money institutions must also apply Chapter III to operational or security payment-related incidents. Those incidents can fall within the reporting regime even when they are unrelated to ICT. Classification procedures for these entities must cover the additional category. (DORA, Arts. 3(9), 23.)
Incident reporting deadlines
The reporting process must distinguish awareness, classification, submission and recovery timestamps. For a major ICT-related incident, the general deadlines are:
- The initial notification is due as early as possible, within four hours after classification as major and no later than 24 hours after awareness. If the incident is first classified as major more than 24 hours after awareness, notification is due within four hours of that classification.
- The intermediate report is due no later than 72 hours after the initial notification, even if the incident's status has not changed. Updates follow relevant changes and supervisory requests. Updated intermediate reports are required without undue delay and, in any case, when the firm restores regular activities.
- The final report is due no later than one month after the intermediate report or the latest updated intermediate report. It follows completion of the root-cause analysis and availability of actual impact figures to replace estimates.
A procedure that allows every initial notification 24 hours after classification would exceed the general deadline. Firms unable to meet a reporting deadline must notify the authority and explain the reasons without undue delay, and no later than that deadline. That notification does not establish an automatic extension. (DORA, Art. 19(4); Delegated Regulation (EU) 2025/301, Art. 5(1)–(3).)
Relief applies where a deadline falls on a weekend or bank holiday in the firm's Member State, subject to exceptions. Article 5(4) permits submission by noon on the next working day. The relief does not apply to initial and intermediate reports by credit institutions, central counterparties or trading venue operators. Financial entities identified as essential or important under Directive (EU) 2022/2555, known as NIS2, also fall within that exclusion. An authority may withdraw the initial and intermediate reporting relief from other significant or systemic entities under Article 5(6). Its decision applies to incidents reported after the entity receives notice. The reporting calendar must reflect those conditions. (Delegated Regulation (EU) 2025/301, Art. 5(4)–(6).)
Firms must use the prescribed forms and procedures. A major incident affecting clients' financial interests requires client information without undue delay as soon as the firm becomes aware. The communication must explain the incident and the measures taken to limit its adverse effects. Significant cyber-threat notifications to authorities are voluntary under Article 19(2). Where applicable, firms must separately inform potentially affected clients about protective measures they can consider taking. Reporting providers may prepare or submit reports under permitted outsourcing arrangements, while the financial entity retains responsibility for fulfilment. (DORA, Art. 19(1)–(5); Implementing Regulation (EU) 2025/302, Arts. 1, 4, 6 and Annexes I–II.)
Outsourced reporting also requires notice to the competent authority as soon as the arrangement is concluded. The notice must precede the first notification or report under that arrangement and identify the reporting provider. The authority must also receive notice as soon as the firm stops outsourcing those reporting obligations. (Implementing Regulation (EU) 2025/302, Art. 6.)
Resilience testing
Firms other than microenterprises must maintain a resilience-testing programme and arrange appropriate tests at least yearly for systems supporting critical or important functions. Tests require independence, risk-based selection and procedures to remedy findings. Article 25 lists available testing methods and gives microenterprises a proportionate testing duty. The firm should record why its selected methods and system coverage satisfy its applicable testing duties. (DORA, Arts. 24–25.)
Threat-led penetration testing, or TLPT, applies to entities identified under Article 26 and the technical selection criteria. Microenterprises and Article 16 entities are excluded. Selected firms must conduct TLPT at least every three years, subject to the authority's power to adjust frequency. The tests cover critical or important functions on live production systems, with controls over test risks and documented remediation. (DORA, Arts. 26–27; Delegated Regulation (EU) 2025/1190, Arts. 2, 4–5, 7–13.)
ICT providers and contracts
Firms other than microenterprises and Article 16 entities must adopt and regularly review an ICT third-party risk strategy. It must include a policy for ICT services supporting critical or important functions. That policy requires management-body review at least annually and implementation across the relevant contract lifecycle. Approval records should identify the applicable policy and its latest review. (DORA, Art. 28(2); Delegated Regulation (EU) 2024/1773, Arts. 3–4.)
The register of information must cover all contractual arrangements for third-party ICT services. It must distinguish arrangements supporting critical or important functions and use the prescribed templates. Article 28(3) separately requires annual reporting about new arrangements and access to the full register on request. Planned arrangements supporting critical or important functions require timely notice to the competent authority. Notice is also required when a function becomes critical or important. A supplier list limited to outsourced critical services would omit part of the required register. (DORA, Art. 28(3); Implementing Regulation (EU) 2024/2956, Arts. 3–6 and Annexes I–IV, as corrected.)
Before contracting, the firm must assess the service's criticality, supervisory conditions, risks, provider suitability and conflicts of interest. For services supporting critical or important functions, concentration analysis must address replaceability and dependencies on the same or closely connected providers. The firm must consider relevant risks arising from third-country providers and subcontracting chains. Due-diligence records should explain the assessment and the decision to proceed. (DORA, Arts. 28(4)–(5), 29; Delegated Regulation (EU) 2024/1773, Arts. 3–8.)
Written contracts must allocate rights and obligations. Baseline terms address service descriptions, delivery and data locations, data protection, recovery and return, service levels, incident assistance, cooperation with authorities, termination and training-participation conditions. Incident assistance must carry no additional cost or a cost determined in advance. Article 30(3) adds requirements for services supporting critical or important functions, including measurable service targets, reporting duties, tested continuity arrangements and audit rights. These additional duties depend on the function supported, even where the provider has no critical-provider designation. (DORA, Arts. 30(1)–(4), 31(1).)
Microenterprises may agree to delegate certain audit rights to an independent third party appointed by the provider. They must retain the ability to request information and assurance from that third party at any time. The contract assessment must identify the applicable terms and the arrangements for exercising those rights. (DORA, Art. 30(3), final subparagraph.)
Where ICT services supporting critical or important functions, or material parts, are subcontracted, the firm must assess and monitor the arrangement. Contractual provisions must address permitted subcontracting, notification and assessment of material changes, and relevant termination rights. Contract approval should confirm that any general subcontracting permission preserves the required notice, assessment and termination rights. (Delegated Regulation (EU) 2025/532, Arts. 3–6.)
For ICT services supporting critical or important functions, exit strategies must include documented plans, sufficient testing and periodic review. The firm must identify alternatives and plan how to transfer services and data or return them in-house. Contractual transition periods must support that process. A termination right without a workable transition plan leaves the separate exit obligations unsatisfied. (DORA, Arts. 28(8), 30(3)(f); Delegated Regulation (EU) 2024/1773, Art. 10.)
Supervision and enforcement
Competent authorities may inspect records, investigate and require remedial measures. Member States must establish administrative penalties, subject to their option to use criminal penalties for the relevant breaches. National conditions also govern individual responsibility. Administrative penalty and remedial decisions under Article 50 must be reasoned and subject to appeal. A firm's penalty exposure therefore requires analysis of the relevant national law. (DORA, Arts. 50–52.)
The separate periodic penalty power for designated critical ICT providers can reach 1% of average daily worldwide turnover in the preceding business year. The payment applies daily until compliance, for no more than six months after notification of the penalty decision. It concerns failure to comply with specified oversight measures and carries procedural conditions. It is not a general fine formula for every financial firm's DORA breach. Provider designation also leaves the financial customer's own duties in place. (DORA, Arts. 28(1)(a), 31, 35(6)–(11).)
DORA compliance checklist
A practical review can organise the required evidence into the following records. This grouping translates the cited duties into review tasks; DORA does not prescribe seven separate documents or this checklist's layout.
- A scope assessment identifying the regulated entity, applicable regime and basis for any adjustment. (DORA, Arts. 2–4, 16.)
- Management approvals, allocated responsibilities, training records and documented ICT risk reviews. (DORA, Arts. 5–6, 13(6).)
- Current asset and dependency inventories, security-control records and risk assessments for relevant changes. (DORA, Arts. 8–10.)
- Business impact analysis, recovery objectives, backup procedures and results of continuity and restoration tests. (DORA, Arts. 11–12.)
- Incident records showing classification decisions, reporting timestamps, submissions, client communications and corrective action. (DORA, Arts. 17–19; Delegated Regulation (EU) 2025/301, Art. 5.)
- A testing programme, results and verified remediation, with a separate TLPT record where required. (DORA, Arts. 24–27.)
- The register of information, provider assessments, contracts, subcontracting reviews and tested exit plans. (DORA, Arts. 28–30.)
Each record must reflect the applicable regime. Management should be able to trace a claimed control to the system, service or decision it covers. Open audit findings require documented follow-up under Article 6(7), and testing findings require treatment under Article 24(5). A completed questionnaire cannot establish performance where the supporting record identifies an unresolved failure.
DORA compliance software
DORA requires appropriate ICT systems, protocols and tools. The cited provisions do not prescribe the purchase of a product marketed as "DORA compliance software". A firm may organise its work across existing systems if their capabilities satisfy its applicable obligations. Any purchasing specification should identify which duty the proposed product supports and which records remain elsewhere. (DORA, Arts. 6(2)–(3), 7, 9.)
Useful procurement criteria follow from the operational duties. A firm can test whether a product links services to assets and providers, records approvals and control reviews, and produces the prescribed register. Incident functions should preserve classification and awareness timestamps, apply the correct reporting clocks and support the required submissions. Testing functions should retain findings and evidence of remediation. These are implementation criteria derived from the duties, whose precise configuration depends on the firm's regime. (DORA, Arts. 6(5)–(7), 8, 17–19, 24(5), 28(3).)
The firm should assess the software provider under the same third-party rules when the arrangement constitutes an ICT service. Data access, security and availability form part of the assessment; services supporting critical or important functions require the enhanced exit arrangements. Article 28(1)(a) keeps responsibility with the financial entity, while Article 6(10) preserves responsibility even when compliance verification is outsourced. Product acceptance should therefore depend on demonstrated performance of the functions purchased and access to the records needed for supervision. (DORA, Arts. 6(10), 28(1), (4)–(8), 30.)
