DORA Compliance Cost: What Mid-Market Financial Firms Should Budget

A practical reference for CTOs, CIOs, and engineering leaders on the 4-hour, 72-hour, and 1-month reporting clock — and what it actually takes to hit it. DORA incident reporting is the process by which banks, insurers, investment firms, payment institutions, and their ICT providers notify EU regulators about ICT-related incidents under the Digital Operational Resilience Act (Regulation (EU) 2022/2554). Since the regulation's application date of 17 January 2025, any financial entity in scope must be able to detect an incident, classify it against seven regulatory criteria, and — if it qualifies as "major" — file an initial notification within 4 hours, an intermediate report within 72 hours, and a final report within one month. For engineering leaders, that timeline is not a compliance footnote; it is an operational requirement that depends on monitoring, alerting, and infrastructure readiness built long before the incident happens. This guide breaks down exactly who is in scope, how the classification thresholds work, what each reporting stage requires, and where most teams lose time when the clock is already running. What Is DORA Incident Reporting? DORA — the Digital Operational Resilience Act — is the EU regulation that harmonises how financial entities manage, test, and report on ICT risk. Incident reporting is one of its five pillars, set out in Articles 17 through 23 of the DORA regulation itself. It replaces a patchwork of national and sectoral incident-reporting rules (previously scattered across PSD2, national banking supervision, and NIS-derived frameworks) with a single reporting flow per Member State. DORA defines an ICT-related incident as a single event or series of linked events that compromises the security of network and information systems and adversely affects the availability, authenticity, integrity, or confidentiality of data, or the services a financial entity provides. A major ICT-related incident is one with a high adverse impact on the systems supporting an entity's critical or important functions — and it's this "major" classification that triggers the formal 4h/72h/1-month reporting clock. Who Must Comply with DORA Incident Reporting? DORA casts a wide net across the EU financial sector. If your organisation is authorised or supervised by an EU financial regulator — or you provide critical ICT services to one — DORA incident reporting almost certainly applies to you, including entities operating in fintech and digital banking. Credit institutions and banks — retail, commercial, and investment banks supervised under CRD/CRR. Payment and e-money institutions — including PSD2-regulated firms, whose operational/security incident reporting is now consolidated under DORA. Insurance and reinsurance undertakings, pension funds (IORPs), and their intermediaries. Investment firms, trading venues, and market infrastructure providers. Crypto-asset service providers (CASPs) brought into scope alongside MiCA. Critical ICT third-party providers — cloud, data centre, and software vendors designated as critical under DORA's oversight framework, who must support their financial-entity clients' reporting obligations even when the incident originates in the provider's environment. The Three DORA Reporting Streams DORA doesn't only govern major incidents. Article 19 establishes three distinct reporting obligations, each with its own trigger, template, and deadline: StreamTriggerTemplate / FormatDeadlineMajor ICT-related incident(Art. 19)Classification per RTS 2024/1772RTS 2025/301 Annex II (initial / intermediate / final)4h / 72h / 1 monthSignificant cyber threat(Art. 19(2))Voluntary — the entity judges the threat is relevant to the wider sectorRTS 2025/301 Annex III (threat notification)As soon as practicableRegister of Information(Art. 28(3))All contractual arrangements with ICT third-party providersITS 2024/2956 (xBRL-CSV harmonised template)Annually, by 30 AprilThe Three DORA Reporting Streams Each Member State designates a single competent authority as the entry point for these reports (Article 19(1)); that authority forwards aggregated information to the ESAs, the ECB, and ENISA under Article 19(6). The 7 Classification Criteria: What Makes an Incident "Major"? Commission Delegated Regulation (EU) 2024/1772 — the RTS on classification of ICT-related incidents — sets out seven criteria used to decide whether an incident crosses the "major" threshold. An incident is classified as major if it meets at least two of these criteria, or one criterion combined with the economic-impact threshold. CriterionWhat it measuresClients, counterparts & transactionsNumber and percentage of clients affected, including presence of relevant counterparties such as central counterparties.Reputational impactMedia coverage, repeated client complaints, regulatory enforcement risk, contagion to other entities.Duration & service downtimeIncident duration against recovery time objectives; downtime of services supporting critical or important functions.Geographical spreadNumber of Member States affected; cross-border or third-country impact.Data lossesImpact on confidentiality, integrity, or availability of personal, sensitive, or business-critical data.Criticality of services affectedImpact on Critical or Important Functions (CIFs) or on services delegated to ICT third-party providers.Economic impactGross direct and indirect costs and losses — a threshold of EUR 100,000 triggers this criterion on its own.The 7 Classification Criteria: What Makes an Incident "Major"? Why this matters operationally: classification isn't a legal exercise done after the fact — it has to happen fast enough that the 4-hour clock still leaves time to act. DORA requires classification "without undue delay," and in practice most entities set an internal SLA of well under 24 hours from detection. That means your monitoring stack needs to surface the data (affected clients, downtime, geography, cost estimate) these seven criteria require, not just an alert that "something broke." DORA Incident Reporting Timelines: The 4-Hour, 72-Hour, and 1-Month Clock Once an incident is classified as major, the financial entity enters a three-stage reporting path with its competent authority. Critically, the clock starts at the moment of classification — not at the moment of detection. 1. Initial notification — within 4 hours of classification The entity notifies its competent authority that a major incident has occurred, using the harmonised template in RTS 2025/301 Annex II. This first submission only needs the basic facts: when it happened, where, the type of incident, which services are affected, a preliminary impact estimate, and a contact point. Classification itself must happen without undue delay — the European Supervisory Authorities have set this out as no later than 24 hours after the entity became aware of the incident. 2. Intermediate report — within 72 hours of the initial notification This report goes deeper: a preliminary root-cause analysis, quantified business and operational impact (clients, transactions, services, and any third parties involved), the containment and recovery measures taken so far, and forward-looking actions. If the situation has stabilised sooner, the entity may submit this report earlier than the deadline. 3. Final report — within 1 month of the intermediate report The final report contains the full root-cause analysis, total quantitative and qualitative impact, lessons learned, and a description of the corrective and preventive actions implemented. If an incident is fully resolved before the 72-hour intermediate deadline, entities can typically combine the intermediate and final reports into a single submission. Once filed, the competent authority forwards aggregated incident information to the relevant European Supervisory Authority, the ECB (for SSM-supervised banks), and ENISA. Per the ESAs' first annual report on major ICT-related incidents, published in 2026, financial entities across the EU reported 3,383 major incidents in the covered period — around a third with cross-border impact, but only 10% tied to cybersecurity, with system failures and external events the dominant cause. That last point is worth sitting with: most major-incident reports aren't triggered by attackers. They're triggered by infrastructure that wasn't resilient enough to absorb an ordinary failure. What Goes Into the DORA Reporting Templates (RTS 2025/301) RTS 2025/301 — read alongside the accompanying Implementing Technical Standards — defines the exact data fields competent authorities expect at each stage, so that reports are comparable across Member States and sectors. In practice, this means building (or buying) a workflow that can populate: Annex II — major incident report: classification rationale against the seven criteria, timeline of detection through resolution, affected services and Critical/Important Functions, client and transaction impact, economic cost estimate, and root-cause narrative at each stage. Annex III — significant cyber threat notification: threat description, tactics/techniques/procedures observed, indicators of compromise, affected systems, mitigation actions, and a recommendation on whether the threat should be shared more broadly. Teams that treat this as a documentation problem alone tend to struggle at 3 a.m. during an actual outage. The entities that consistently hit the 4-hour deadline are the ones that have already mapped their critical functions to underlying infrastructure ahead of time, so the classification form is a lookup exercise, not a research project. A Worked Example: Classifying and Reporting a Major Incident Consider a representative (illustrative) scenario: a mid-size EU bank's online banking platform goes unresponsive during peak hours due to a denial-of-service attack against its load balancer. Mobile and web banking are down for just under three hours; queued bill payments are delayed; clients in two Member States are affected; direct and indirect costs (incident response, fee waivers, compensation) total roughly €220,000. Against the seven criteria: clients/transactions affected (yes), geographical spread across two Member States (yes), critical function disruption — retail payment services (yes), and economic impact above the €100,000 threshold (yes). Multiple primary criteria plus the economic threshold means this is unambiguously a major incident. The 4-hour clock starts at the classification decision, the intermediate report follows 72 hours later with a preliminary DDoS root-cause analysis, and the final report — delivered roughly a month out — documents the load-balancer capacity gap and the DDoS-scrubbing upgrade implemented afterward. This is exactly the kind of resilience gap that a proactive SRE practice is designed to catch during testing, not during a live incident. Common Pitfalls in DORA Incident Reporting Confusing detection with classification. The 4-hour clock starts at classification, but classification itself must happen without undue delay — treating 72 hours as an acceptable internal SLA is already too late. Ignoring third-party incidents. Under Article 17, a major incident at a critical ICT third-party that affects your critical functions must be reported even if you only learn about it indirectly — a strong argument for tightening vendor and outsourcing oversight. Underreporting cumulative impact. Recurring, related incidents must be aggregated when assessing economic impact rather than analysed in isolation. Missing the 30 April Register of Information deadline. This is a separate annual filing from incident reporting, and the mandatory xBRL-CSV format catches many teams off guard. Forgetting client notification. Article 19(3) requires entities to inform affected clients without undue delay when a major incident touches their financial interests — a communications step that's easy to lose in the scramble to file the regulatory report. How Gart Solutions Helps You Meet the DORA Incident Reporting Clock DORA's reporting deadlines are, at their core, an infrastructure problem before they're a paperwork problem. Hitting a 4-hour classification window requires monitoring that surfaces the right signals, a documented escalation path, and systems resilient enough that "major incidents" are the exception rather than the norm. That's the work Gart Solutions does every day for regulated and high-availability businesses across Europe and the US. IT Monitoring & SRE Real-time observability and on-call practices that turn incident detection and impact data into a classification decision in minutes, not hours. See SRE & IT Monitoring → Compliance & Security Audits Gap assessments against DORA's ICT risk management, resilience testing, and reporting requirements — mapped to your actual architecture. See Compliance Audit Services → Backup & Disaster Recovery DRaaS design that reduces the duration and downtime that push an incident over DORA's "major" threshold in the first place. See Disaster Recovery Services → Fractional CTO Senior technology leadership to own ICT risk governance and resilience strategy without a full-time executive hire. See Fractional CTO Services → We're not here to replace your legal or compliance team — we build the operational backbone that makes their reporting obligations achievable under real deadline pressure. Talk to Gart about DORA readiness Key Takeaways DORA incident reporting compresses what used to be a multi-day compliance process into a 4-hour, 72-hour, 1-month sequence — and the ESAs' own data shows most major incidents are caused by ordinary system failures, not sophisticated attacks. The organisations that meet these deadlines comfortably are the ones that invested in monitoring, resilience, and a rehearsed classification process before their first major incident, not during it. You might also like Resilience by Design: Engineering Antifragile IT Infrastructure Site Reliability Engineering: Key Best Practices for World-Class Reliability SOC 2 Compliance: A Step-by-Step Guide to Preparing for Your Audit Fedir Kompaniiets Co-founder & CEO, Gart Solutions · Cloud Architect & DevOps Consultant Fedir is a technology enthusiast with over a decade of diverse industry experience. He co-founded Gart Solutions to address complex tech challenges related to Digital Transformation, helping businesses focus on what matters most — scaling. Fedir is committed to driving sustainable IT transformation, helping SMBs innovate, plan future growth, and navigate the "tech madness" through expert DevOps and Cloud managed services. Connect on LinkedIn.

If you run technology or risk for a bank, insurer, investment firm, or payment institution in the EU, the DORA register of information is probably the single compliance artifact keeping your team up at night. It is the inventory of every ICT third-party arrangement your organization relies on, and it is now the first document national regulators pull when they open a supervisory file. Get it wrong — incomplete fields, mismatched contract data, an outdated exit strategy — and it becomes the fastest route to a formal enforcement letter. Get it right, and it becomes a genuine map of your operational risk. This guide explains what the register is, who has to file one, what belongs inside it, the 2026 deadlines, and a practical path to building (and maintaining) one, including where a compliance audit can shortcut the process. What Is the DORA Register of Information? The DORA register of information is a structured, continuously updated record of every contractual arrangement a financial entity has with ICT third-party service providers — cloud vendors, SaaS platforms, data centers, managed security providers, and any subcontractor that supports a critical or important business function. It is mandated under Article 28 of Regulation (EU) 2022/2554, better known as the Digital Operational Resilience Act (DORA). The register exists to solve a specific supervisory problem: regulators previously had no system-wide view of how many banks and insurers were quietly dependent on the same handful of cloud and infrastructure providers. The register of information gives the European Supervisory Authorities (ESAs) and national competent authorities (NCAs) that visibility. It feeds three things directly: 1. Oversight of concentration risk — regulators can see when too much of the financial sector depends on one provider. 2. Designation of Critical ICT Third-Party Providers (CTPPs) — providers deemed systemically important come under direct ESA oversight. 3. Supervisory review of your own ICT risk management — an incomplete or inconsistent register is treated as a governance failure in itself. Who Has to Maintain a DORA Register of Information? DORA's scope is deliberately broad. If your organization holds an EU financial services license, you are almost certainly in scope. That includes: Credit institutions and payment institutions, including e-money institutions and account information service providers. Investment firms, fund managers, and management companies operating under MiFID or the UCITS/AIFMD frameworks. Insurance and reinsurance undertakings, including intermediaries above the small-entity thresholds. Crypto-asset service providers and crowdfunding platforms brought into scope under DORA's extended definitions. Non-EU entities with an EU branch or subsidiary — DORA's extraterritorial reach means a US or UK-headquartered firm with an EU license has the same obligation as a domestic one. Critical ICT third-party providers themselves — including major cloud and hyperscaler platforms designated under the oversight framework — face a parallel but separate reporting regime supervised directly by the ESAs, as described by the European Banking Authority. What's Inside the Register: Templates and Mandatory Fields This is where most teams underestimate the effort. The register of information isn't a single spreadsheet under Commission Implementing Regulation (EU) 2024/2956, it's a set of roughly 15 interconnected templates that must reconcile with each other before submission. Every ICT provider, contract, service line, and subcontractor needs its own record, cross-referenced by consistent identifiers. Template areaWhat it capturesEntity & provider identityLegal Entity Identifier (LEI), country, provider type, and CTPP designation status for every direct ICT providerContractual arrangementsOne record per contract: counterparty, reference date, governing law, notice period, and criticality flagServices & business functionsEach contract broken into individual ICT service lines, mapped to the business function each one supportsSub-outsourcingMaterial subcontractors used by providers that deliver critical or important functionsCost dataActual prior-year spend and estimated current-year cost per arrangement, reported in EURCriticality & exit strategyClassification of critical or important functions (CIF) and the documented exit plan for each oneWhat's Inside the Register: Templates and Mandatory Fields Once populated, the whole package is exported as an xBRL-CSV report — a table-oriented data format with an accompanying metadata file — using the taxonomy published by the ESAs. This is not a format most compliance or risk teams work with natively, which is why register-building is increasingly treated as a joint effort between compliance, procurement, and infrastructure engineering. 2026 Submission Deadlines (and What "Consolidated" Actually Means) Financial entities don't submit straight to the ESAs — they submit to their national competent authority first, which validates, consolidates, and forwards the data. Deadlines vary by country and sector, but they cluster tightly around Q1 2026: Jurisdiction / sectorFinancial entity submission window (2026)Netherlands (DNB)By 20–22 March 2026Germany, France, Belgium, Ireland, Italy, SpainBy 31 March 2026Luxembourg (CSSF, via eDesk)11 February – 31 March 2026Insurance/reinsurance undertakings (e.g., CAA-supervised)By 1 March 2026ESA consolidation deadline (all NCAs)31 March 20262026 Submission Deadlines (and What "Consolidated" Actually Means) According to De Nederlandsche Bank, national competent authorities must forward their fully consolidated registers to the ESAs by 31 March of each calendar year — meaning your own internal submission window will close weeks earlier to give your NCA time to validate the file. Miss the internal deadline and you risk being flagged before the ESA even sees the data. One detail teams frequently miss: the register isn't a once-a-year exercise. Per ESMA's DORA guidance, the underlying register must be kept continuously accurate — the annual submission is simply a snapshot of a system that should already be current. Why the Register of Information Is the First Thing Regulators Check Enforcement moved from "readiness checks" to active supervision in 2026, and Article 28 has become one of the two most frequently examined provisions (alongside Article 5 governance requirements). The financial exposure is real: material non-compliance carries fines of up to 2% of global annual turnover or EUR 10 million, whichever is higher, and individual board members can face personal liability of up to EUR 5,000,000 under national governance provisions. Designated critical providers face their own penalty track, including periodic payments of EUR 500,000 to EUR 5,000,000 per day. In practice, national competent authorities are now cross-checking register of information data automatically against other regulatory filings. An incomplete provider record, a contract missing a termination notice period, or an exit strategy that was never actually tested tends to surface immediately — and has already become the leading cause of first-round supervisory letters. How to Build a DORA Register of Information: A Step-by-Step Approach Whether you're starting from scratch or cleaning up a register assembled under deadline pressure last year, the same sequence applies: Inventory every ICT third-party arrangement — including shadow IT and SaaS tools procured outside central IT, which are the most common gaps. Classify which functions are "critical or important" (CIF) — this classification determines how much detail each contract needs and whether sub-outsourcing has to be tracked. Standardize provider identity data — obtain and validate LEIs for every direct provider; inconsistent identifiers are one of the most common reconciliation failures between templates. Map contracts to the ITS template structure — decompose each contract into individual service lines and link each to the business function it supports. Trace sub-outsourcing chains for any provider supporting a critical function, down to material subcontractors. Document (and actually test) exit strategies for every critical arrangement — a written plan that has never been rehearsed is a common audit finding. Convert to xBRL-CSV and validate against the ESA taxonomy before your NCA's internal deadline, then establish an owner and a quarterly review cadence so the register never goes stale between annual submissions. Most of this work is less about compliance paperwork and more about infrastructure visibility — knowing exactly which cloud accounts, environments, and vendors sit behind each business function. Teams that already have clean infrastructure documentation from an IT audit typically move through steps 1–4 in a fraction of the time. Common mistakes that trigger regulator follow-up Most register problems trace back to a handful of recurring habits. Teams treat the register as a one-time export instead of a living record tied to procurement and vendor-management workflows, so it drifts out of date within weeks of submission. Subcontractors one or two levels down the chain get missed for critical functions, because nobody owns visibility that deep into a provider's own vendor stack. Exit strategies exist on paper but were never operationally validated, which surfaces the moment an auditor asks for evidence of a test run. And inconsistent LEIs or provider names across templates quietly break the automated cross-checks an NCA runs the moment the file lands. How Gart Solutions Helps You Get (and Stay) DORA-Ready Building an accurate DORA register of information is fundamentally an infrastructure and vendor-visibility problem before it's a paperwork problem — you can't document dependencies you haven't fully mapped. Gart Solutions works with fintech, insurance, and payments teams on exactly that groundwork: Compliance audits that map every ICT vendor, contract, and subcontractor against DORA's Article 28 requirements before you build the register. Infrastructure audits that surface shadow IT and undocumented cloud dependencies — the most common source of register gaps. SRE and disaster-recovery engineering to design and actually test the exit strategies your critical-function contracts require. Fractional CTO support for teams that need senior technical ownership of the register-building process without adding full-time headcount. Talk to our team about your DORA readiness Fedir Kompaniiets Co-founder & CEO, Gart Solutions · Cloud Architect & DevOps Consultant Fedir is a technology enthusiast with over a decade of diverse industry experience. He co-founded Gart Solutions to address complex tech challenges related to Digital Transformation, helping businesses focus on what matters most — scaling. Fedir is committed to driving sustainable IT transformation, helping SMBs innovate, plan future growth, and navigate the "tech madness" through expert DevOps and Cloud managed services. Connect on LinkedIn.

If your organization touches EU financial services — as a bank, insurer, payment provider, crypto-asset firm, or as an ICT vendor selling to any of them — a DORA compliance checklist is no longer optional homework. The Digital Operational Resilience Act (DORA) has been fully in force since January 17, 2025, and 2026 is the year national regulators stop reviewing paperwork and start demanding proof: real-time evidence of resilience, tested incident response, and a fully mapped ICT supply chain. This guide breaks DORA's five pillars into a checklist your IT and security teams can actually execute, and shows where a structured compliance audit can shortcut the gap analysis. In short: DORA compliance means proving — with documentation, tested controls, and a maintained Register of Information — that your organization can identify, withstand, respond to, and recover from ICT-related disruptions. It rests on five pillars: ICT risk management, incident reporting, resilience testing, third-party risk management, and information sharing. Non-compliance can cost up to 2% of global annual turnover or €10 million, whichever is higher. What Is DORA, and Who Needs to Comply? What it is: The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is an EU regulation that standardizes how financial entities and their critical technology vendors manage, report, and recover from ICT risk. Unlike earlier frameworks that treated cybersecurity as a checkbox, DORA is built around demonstrable operational resilience — your ability to keep critical functions running through a cyberattack, outage, or vendor failure, not just your ability to write a policy about one. Who it applies to: Per the European Banking Authority, DORA's enforcement perimeter now covers more than 22,000 financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers, and trading venues — plus an estimated 15,000 ICT third-party providers that serve them, including cloud platforms, SaaS vendors, and data center operators. If your product touches an EU-regulated financial entity's critical or important function, DORA reaches you contractually even if you're not a financial institution yourself. Fintech platforms in particular should check our breakdown of DevOps and cloud infrastructure for fintech for how this plays out operationally. When it's enforced: DORA became directly applicable across all EU member states on January 17, 2025. 2025 functioned as a de facto transition year, with regulators focused on readiness assessments. In 2026, national competent authorities (NCAs) have moved to active enforcement — formal audits, information requests, and financial penalties are now standard practice. The DORA Compliance Checklist: 5 Pillars You Must Cover Every credible DORA compliance checklist is organized around the regulation's five pillars. Treat each one as a workstream with its own owner, evidence trail, and testing cadence — not a document to file away after the initial audit. Pillar 1: ICT Risk Management Checklist This is DORA's foundation — a governance framework that your board formally owns, not just IT. Auditors will look for evidence, not intent. ICT risk management framework documented, board-approved, and reviewed at least annually Complete inventory and classification of ICT assets, systems, and data flows supporting critical or important functions Defined risk tolerance thresholds tied to business-impact analysis Identity, access, and network security controls mapped to identified risks Business continuity and disaster recovery plans tested, not just written Clear internal accountability — a named function (often the CISO or a dedicated resilience lead) reporting risk posture to the board Most of this pillar overlaps with existing frameworks — if you've already built a risk management system for ISO 27001, you're covering roughly 60–70% of DORA's ICT risk requirements already. Pillar 2: ICT Incident Reporting Checklist DORA replaces vague "notify without undue delay" language with hard deadlines. Your incident response runbook needs these timers built in, not calculated manually under pressure. Incident classification criteria in place (severity, client impact, reputational impact, geographic spread, duration) Initial notification to the relevant national competent authority within 4 hours of classifying an incident as major Intermediate report submitted within 72 hours with updated status and impact assessment Final report submitted within one month, including root cause and remediation Designated Critical ICT Third-Party Providers report major incidents to their Lead Overseer within 2 hours Incident logging and evidence retention process that survives an auditor's request for the last 12 months of history Pillar 3: Digital Operational Resilience Testing Checklist DORA does not accept a policy document as proof of resilience — it requires proof you've broken your own systems on purpose and recovered. Annual basic testing program covering vulnerability assessments, scenario-based tests, and network security assessments Threat-Led Penetration Testing (TLPT) every three years for entities identified as significant, simulating real adversary tactics against production-like environments Testing results tracked to remediation with owners and deadlines, not just filed as a report Independent testers used where required, with results reported to management and regulators as applicable Pillar 4: ICT Third-Party Risk Management Checklist This is the pillar catching the most organizations off guard in 2026, largely because of one deliverable: the Register of Information (RoI). Register of Information covering every ICT third-party contract supporting critical or important functions, in the ITS 2024/2956 format RoI submitted to your national competent authority ahead of the 2026 deadline (most EU states set 31 March 2026; the Netherlands set 22 March 2026) Pre-contractual due diligence process for new ICT vendors, including sub-outsourcing chain visibility Contracts updated with DORA-mandated clauses: audit rights, exit strategies, service levels, and incident cooperation Concentration risk assessed — how many critical functions depend on a single cloud or SaaS provider Monitoring in place for providers designated as Critical ICT Third-Party Providers (CTPPs) by the European Supervisory Authorities If your third-party register includes payment processors, the due-diligence bar is even higher — cross-check it against the controls covered in our PCI DSS audit guide and, for entities also subject to U.S. financial rules, our SOX compliance overview. Pillar 5: Information and Intelligence Sharing Checklist The lightest-touch pillar — encouraged, not mandated — but still worth formalizing so it doesn't fall through the cracks during an audit. Participation (or a documented decision not to participate) in a threat-intelligence sharing arrangement with peers or sector groups Internal process to act on shared indicators of compromise and TTPs, not just receive them Legal and data-protection review of any information-sharing arrangement before joining Reality check: Most organizations we assess have partial coverage on Pillars 1–3 from prior ISO 27001 or SOC 2 work, but a near-blank Register of Information for Pillar 4. Third-party risk management is where a targeted cloud infrastructure and vendor review pays off fastest. Full DORA Compliance Checklist by Pillar Use this table as a working audit tracker — assign an owner and a status to each row before your next internal review. PillarCore RequirementTypical OwnerEvidence NeededICT Risk ManagementBoard-approved risk framework, asset inventory, tested BC/DR plansCISO / IT GovernanceFramework doc, risk register, DR test logsIncident Reporting4-hour / 72-hour / 1-month reporting cadence to NCASOC / Incident Response LeadIncident log, timestamped reports, escalation recordsResilience TestingAnnual testing plus TLPT every 3 years for significant entitiesSecurity / DevSecOpsTest reports, remediation tickets, retest evidenceThird-Party RiskRegister of Information, due diligence, DORA-compliant contractsProcurement / IT AuditRoI submission, contract addenda, vendor risk scoresInformation SharingThreat-intel participation and internal action processCISO / LegalMembership records, IOC-response workflowFull DORA Compliance Checklist by Pillar DORA Compliance Timeline: Key 2026 Deadlines DORA compliance in 2026 is not a one-time deadline — it's a recurring supervisory cycle. These are the dates IT and security leaders should have on their calendar right now. Ongoing: Full DORA applicability since January 17, 2025 — every requirement below is already enforceable. Q1 2026 (31 March for most member states; 22 March for the Netherlands): Annual Register of Information submission to your national competent authority. Throughout 2026: National regulators cross-reference registers across entities, flagging providers that appear inconsistently or "sub-outsourcing chains that don't exist" for major cloud vendors — expect follow-up requests if your data doesn't match your vendors' filings. Rolling: Designated Critical ICT Third-Party Providers — 19 named by the ESAs in November 2025, including major hyperscalers — now operate under direct ESA oversight. Confirm whether any of your critical vendors are on that list and adjust monitoring accordingly. What Happens If You're Not DORA Compliant? Regulators have made clear that 2026 is the enforcement year, and the penalty structure reflects it: Financial entities: Per the official DORA regulation text, fines up to 2% of total annual global turnover or €10 million, whichever is higher, plus individual penalties up to €1 million for accountable executives. Critical ICT Third-Party Providers: Daily penalty payments of up to 1% of average daily global turnover for continued non-compliance, for up to six months, plus corrective measures dictated by the Lead Overseer. Member-state variation: Some countries go further — Italy allows ceilings up to €20 million or 10% of turnover, and Article 52 permits criminal penalties, including imprisonment, for the most severe violations. Beyond fines, the operational cost is often higher: emergency remediation under regulatory scrutiny, contract renegotiation with vendors, and lost enterprise deals once prospective financial-sector clients ask for your DORA evidence during procurement. Common DORA Compliance Mistakes IT Teams Make Across compliance audits, the same gaps recur regardless of company size: Treating DORA as a paperwork exercise. A written policy with no test logs, no incident drill records, and no remediation tracking won't survive an NCA review. Underestimating the Register of Information. Mapping every ICT contract, sub-outsourcer, and data flow into the ITS 2024/2956 format takes longer than teams expect — start well before the March deadline, not the week of. Missing concentration risk. Multiple critical functions quietly depending on one cloud region or one SaaS vendor is a red flag regulators specifically look for. These same failure patterns show up across regulatory checklists generally — our FISMA audit checklist walks through a comparable evidence-first approach if you're benchmarking your audit process against other frameworks. Turn This Checklist Into an Audit-Ready Program Gart Solutions runs compliance audits that map your current ICT risk management, incident response, and third-party contracts directly against DORA, ISO 27001, SOC 2, and NIST requirements — then translate the gaps into a DevOps-executable remediation plan. We work across AWS, Azure, and GCP, so the controls we recommend get built into your CI/CD and cloud infrastructure, not bolted on as a separate process. For teams that need ongoing resilience testing and incident readiness without hiring a full internal security function, our SRE and disaster recovery services and fractional CTO engagements plug directly into your existing team. Get a free DORA readiness consultation Fedir Kompaniiets Co-founder & CEO, Gart Solutions · Cloud Architect & DevOps Consultant Fedir is a technology enthusiast with over a decade of diverse industry experience. He co-founded Gart Solutions to address complex tech challenges related to Digital Transformation, helping businesses focus on what matters most — scaling. Fedir is committed to driving sustainable IT transformation, helping SMBs innovate, plan future growth, and navigate the "tech madness" through expert DevOps and Cloud managed services. Connect on LinkedIn.