DORA Audit 2026: How to Prepare for a Supervisory Review

A DORA supervisory review in 2026 tests whether your operational resilience programme runs in practice: live processes, tested controls, and evidence examiners can trace back to the obligation. The Digital Operational Resilience Act (DORA) has applied since 17 January 2025, and by mid-2026 national competent authorities (NCAs) have shifted from guidance to active inspection. They're cross-checking Register of Information data automatically, issuing supervisory letters to institutions with material gaps, and scoping the first wave of mandatory penetration tests.

A DORA supervisory review is a regulatory examination of how your organisation meets DORA's operational resilience obligations in practice. Examiners look for live processes, tested controls, and traceable evidence that your programme operates as documented, going well beyond the paperwork checks of an ISO certification audit.

Who Conducts It

Your NCA conducts the review, coordinated with guidance from the three European Supervisory Authorities: the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA). For entities designated as Critical Third-Party Providers (CTPPs), the EU coordinates oversight through a Lead Overseer and Joint Examination Teams.

Who This Applies To

This applies to financial entities regulated under EU financial services law, including banks, insurers, investment firms, and payment institutions in scope under Regulation (EU) 2022/2554, alongside ICT third-party providers carrying flow-down obligations and those designated, or likely to be designated, as CTPPs under DORA's third-party oversight framework (Articles 28 to 44). It's aimed at compliance, risk, and IT teams preparing for their first formal DORA supervisory review, or responding to a supervisory letter already in hand. SureCloud's DORA Compliance Guide and the five pillars of DORA explained cover the regulatory foundations and scope behind these obligations; this guide picks up where they leave off, covering operational readiness and evidence preparation.

NCAs escalate through six defined stages before reaching the harshest sanctions, and most institutions never go beyond the first two if they engage constructively.

1. Desk review or data request: triggered by Register of Information analysis or incident report patterns.
2. Supervisory letter or findings letter: identifies gaps and sets a remediation timeline of 60 to 90 days.
3. On-site inspection: reserved for significant institutions or where desk review findings are material.
4. Formal remediation order: a legally binding requirement to fix specific gaps by a specific date.
5. Compulsion payment notice: a daily penalty for continued non-compliance after the deadline passes.
6. Administrative fine or public censure: the final sanction for wilful or repeated non-compliance.

Most institutions that engage at step two, the supervisory letter, close their gaps before an on-site inspection is ever scheduled. The Netherlands' DNB issued the first batch of these letters to institutions with material ICT risk gaps in early 2026, and Italy's regulators spent the same period finalising national Register of Information submission timelines. The costliest outcomes are reserved for entities that ignore supervisory correspondence entirely or fail to remediate material gaps after a formal order lands.

What Penalties Actually Look Like

Article 50 of DORA sets the principle: penalties must be effective, proportionate, and dissuasive. It leaves the exact ceiling to each member state, and that's produced real divergence, documented in detail by DLA Piper's analysis of DORA penalty regimes. Italy caps financial-entity fines at €20 million or 10% of annual turnover, whichever is higher, while Ireland caps at €10 million or 10% of turnover.

Individual senior managers face personal exposure too, ranging from €100,000 in Finland to €5 million in Germany depending on the jurisdiction. For Critical Third-Party Providers under direct EU oversight, the penalty structure is harmonised at EU level: the Lead Overseer can impose daily penalty payments of up to 1% of the provider's average daily worldwide turnover, for a maximum of six months.

The practical takeaway: check the specific penalty regime your NCA enforces. The gap between Luxembourg's flat €5 million ceiling and Italy's €20 million or 10% of turnover is wide enough to change how a board thinks about risk appetite.

Supervisory communications and industry intelligence from the first half of 2026 point to five areas receiving the highest examination priority, all drawn from the findings of the first formal wave of DORA supervisory reviews.

1. Register of Information Quality

The Register of Information (RoI) is the first thing NCAs cross-check, and it's now machine-readable. Supervisors run automated queries across submitted xBRL-CSV data, identifying missing ICT providers, anomalous concentration patterns, and discrepancies against previously reported incident data.

The most common deficiencies in the first submission wave: missing sub-contracting chain information, incorrect criticality classification (critical, important, or supporting), and incomplete geographic data-residency fields. Entities with incomplete registers received formal supervisory letters requiring remediation within 60 days.

Examiners expect every ICT-related contractual arrangement logged, including cloud marketplace purchases, SaaS subscriptions, managed services, and sub-outsourcing chains. Classification decisions need reasoning and documentation behind them: a wrong classification is a finding even when the contract itself is filed correctly. Small detail, real consequence.

2. Board-Level ICT Risk Framework Approval

Examiners expect the ICT risk management framework to carry the full board's formal approval. They'll ask for the board resolution, the framework document, and evidence that the board receives ICT risk reporting at least quarterly.

A framework signed off only by the CISO or CTO reads as a finding on its own; examiners look for minuted board engagement behind it. Institutions whose ICT risk taxonomy conflicts with their incident-reporting taxonomy under Article 18, DORA's incident-classification provision, are being flagged too. But the fix is straightforward: reconcile the two taxonomies before the review begins.

3. Article 30 Contract Compliance

Article 30, DORA's mandatory-contract-clauses provision, requires service level agreements, access and audit rights, data portability, termination assistance, and sub-outsourcing approval to appear in every contract with an ICT provider supporting a critical or important function.

Many institutions signed DORA-compliant addenda in 2024 and 2025. Examiners are now checking whether those addenda cover every subcontractor in the chain, extending past the primary contract most teams remember signing.

4. Incident Classification Methodology

Examiners request the internal decision tree or criteria matrix used to classify whether an event is a major ICT incident requiring regulatory notification under Article 18, using the materiality thresholds set out in Commission Delegated Regulation (EU) 2024/1772. A methodology that has never produced a notification is itself the finding: examiners read a zero-notification track record as evidence that classification thresholds are calibrated too conservatively.

5. Resilience Testing Programme

Every in-scope entity needs a documented annual testing programme covering vulnerability assessments, network security assessments, and scenario-based tests. Entities designated under Article 26 also need a Threat-Led Penetration Testing (TLPT) scheduling plan.

Every entity designated by its NCA must complete at least one TLPT by 17 January 2028. The first TLPT notifications are already going out in 2026, and institutions that haven't started planning face a genuinely tight window: the methodology is binding EU law under Commission Delegated Regulation (EU) 2025/1190, and a full cycle from provider procurement to attestation takes 9 to 14 months against fewer than 40 accredited providers across the entire EU.

Deloitte's Wave 3 DORA compliance survey, published in March 2025, found that only 50% of institutions expected to reach full compliance by the end of 2025, with 38% pushing their target into 2026. NCAs are treating progress plans as insufficient on their own now; proving the programme runs in practice is what matters.

Run an internal gap analysis against DORA's five pillars before examiners arrive, so any findings surface on your own terms, with time to remediate and evidence closure.

Use the five pillars as your frame: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. For each pillar, perform a control-by-control check against the relevant RTS obligations, capture gaps with owners and due dates in your risk register, confirm testing calendars run year-round with retests built in, and check that incident classification logic and report clocks are defined, rehearsed, and recorded.

If your organisation holds ISO 27001 certification or aligns to NIS2 (the EU's Network and Information Security Directive), significant work is already done. Map existing controls to DORA obligations, record the equivalence so auditors can trace each requirement to a live control, and reuse NIS2 artefacts where they already meet the same DORA outcomes. SureCloud's DORA vs NIS2 vs ISO 27001 comparison guide walks through where the three frameworks overlap and how to run one mapped control set across all of them instead of three parallel evidence trails.

Mock-audit methodology: self-review against Annex I to IV with a regulator-style request list, walk through real incidents and tests, show artefacts live, and time each step. Check traceability end-to-end, from obligation to control to owner to evidence to last refresh.

Document outcomes in your risk register, and track owners and due dates on a standing quarterly cadence.

Supervisors expect traceable, verifiable evidence for every obligation. Centralising it means requests get answered quickly and consistently. An evidence library assembled in the two weeks before a request lands creates real exposure at exactly the wrong moment.

Recommended categories: policies and procedures (ICT risk management policy, incident response, outsourcing and third-party rules, change management, ICT business continuity policy), registers and logs (Register of Information in xBRL-CSV format, incident log, asset register, vulnerability register, vendor tiering register), reports (risk reviews, resilience test results and retests, board and committee packs showing quarterly ICT risk reporting), and records and proof (board resolutions approving the ICT risk framework, meeting minutes, system exports, screenshots, tickets, version histories, and Article 30 contract-clause confirmations).

Tag each artefact to the DORA obligation and RTS or ITS field it proves, with a named owner and a refresh cadence. Keep version history and snapshot sets before major changes, and pre-assemble a model incident evidence pack with timestamps, approvals, and draft reports aligned to the reporting timeline below.

The Incident Reporting Clock

The four-hour initial-notification window for major ICT-related incidents is where institutions get caught out most often. Examiners verify when the clock starts and who authorises the major-incident classification, that the initial notification goes out within four hours of classification and no later than twenty-four hours from detection, that the intermediate report follows within seventy-two hours, that the final report lands within one month of the initial notification, and that the timing model holds across weekends and public holidays.

Pre-assemble a model incident evidence pack covering the incident summary with classification decision and clock start, a timeline with key timestamps and approvals, RTS- and ITS-aligned report drafts, root-cause notes, impact assessment, and follow-up actions with owners and due dates.

DORA cannot sit with a single team. The regulation touches governance, ICT operations, legal, procurement, and business continuity at the same time, and a cross-functional coordination model is what examiners look for when they ask how the programme runs.

Build the audit coordination team around Risk and Compliance as overall coordinator and owner of the request log, IT and Security as technical subject-matter experts for controls, testing, and Register of Information data, Legal for regulatory interpretation and Article 30 clause review, Procurement for contract artefacts and sub-outsourcing disclosure, business owners for service-impact assessments and continuity assumptions, and Internal Audit for independent challenge and mock-review execution.

Clarify ownership early: a single point of contact for the regulator with a named backup, evidence custodians per pillar with ready-to-show folders, a live request tracker with status and due dates, a scribe capturing commitments and timestamps during meetings, and an escalation path for overdue items.

Pillar briefing packs help too. For each of DORA's five pillars, prepare a one-page summary covering how the obligation is met, the key controls and policies, the primary evidence location, open issues with owners and due dates, and talking points so subject-matter experts answer consistently across the team. These packs do double duty: they prepare your team for walkthroughs, and a subject-matter expert working from one can answer three examiners in three different rooms without contradicting each other.

Supervisors test how your programme runs in practice. The questions below reflect where examination attention concentrated most in the first 2026 supervisory wave.

Sample questions examiners are asking in 2026:

1. How is your ICT risk framework integrated with enterprise risk management, and where is the board's approval documented?
2. Show us your incident classification decision tree, and walk us through the last time it produced a notification.
3. When did you last test critical system failovers, and what did the retest evidence show?
4. Which ICT providers are classified as critical or important, and how did you reach that classification?
5. Walk us through your Register of Information. How do you capture sub-outsourcing chains?
6. What is your exit strategy for your three largest cloud providers?
7. How do you govern AI tools used in ICT operations or decision-making?

Keep answers short and show the artefact live. Reference the control and, where relevant, the RTS or ITS field it satisfies. Point to time-bound outcomes: test dates, findings, retests, and the owner of each. Name the accountable owner and the next scheduled refresh, and log any remediation as a dated action during the session.

The answer pattern examiners reward follows a simple shape: name the control, show the evidence, give the date it was last tested, state the finding and when the retest confirmed closure, then name the owner and the next review date. Vague answers that reference policy documents without live evidence are a red flag; examiners are trained to tell the difference between a programme that operates and one that only documents.

A mock supervisory review is the single most effective preparation activity available. It surfaces the gap between what your policies say and what your team can actually produce under exam conditions.

Use Internal Audit or an external specialist to issue a regulator-style request list, and recreate the end-to-end flow: intake, evidence collection, walkthroughs, findings, and dated remediation actions. Time every stage so you know where delays happen and who unblocks them, and score each area on the evidence it actually produces.

The mock review should specifically test: whether you can produce a current, complete Register of Information on request, including sub-outsourcing chains; whether an incident-classification tabletop can actually produce a major-incident notification, since an exercise that can't produce one is telling you the classification criteria are the problem; whether your team can hit the four-hour, seventy-two-hour, one-month timeline under realistic conditions, including weekends; whether you can demonstrate TLPT planning progress and a realistic timeline to completion if designated or likely to be designated; and whether you can produce the documentary board-evidence file examiners want to see: training certificates, risk committee minutes, signed risk appetite statements, and quarterly ICT risk reports.

Close gaps as you find them: assign owners and due dates for each finding, schedule retests and attach proof to the original finding, update policies and registers and capture version history, and snapshot the before-and-after evidence set so improvement is visible at the next checkpoint.

Audit readiness is an operating rhythm, and the organisations that perform best under DORA supervision treat every quarter as though a supervisory letter could land the following Monday.

Use this as a planning model, and adapt durations to your size, complexity, and current maturity.

Days 0 to 15: Establish the Baseline

Confirm scope, owners, and operating rhythm across Risk, Compliance, IT, Legal, and Procurement. Stand up or audit the consolidated Register of Information, covering services, systems, data, and vendors including sub-outsourcing chains. Align incident intake forms to RTS and ITS data fields and reporting clocks, and verify whether the ICT risk framework is board-approved and minuted.

Days 16 to 30: Build the Evidence Library

Populate the evidence library with tagged artefacts and assign refresh cadences. Publish the annual resilience testing plan and schedule retests for open findings. Identify critical and important ICT suppliers, confirm Article 30 clause compliance in each contract, and assess TLPT applicability, seeking clarity proactively if your NCA hasn't issued guidance yet.

Days 31 to 60: Test the Programme

Run the first incident tabletop designed to produce a major-incident notification, and execute a business continuity drill with captured evidence. Launch supplier evidence collection on a documented calendar, and prepare TLPT scoping notes if designated or likely to be designated.

Days 61 to 90: Mock Review and Closure

Execute a full mock supervisory review with a realistic regulator-style request list. Close high-risk remediation items and snapshot updated evidence before and after. Produce an executive pack with current status, open gaps, and next-quarter actions, and confirm the board evidence file is complete: minutes, risk appetite sign-offs, and quarterly ICT risk reports.

Ongoing After Day 90

Treat this as a quarterly operating cycle. Submit the Register of Information to your NCA annually; most member states set a 31 March deadline, though some national regulators, including the Netherlands' DNB and AFM, set earlier dates in March depending on which body supervises your entity. NCAs then consolidate and report to the ESAs by 30 April. Run retests, update the testing programme, and keep the evidence library current.

Pre-assemble these categories so your team can respond to a supervisory data request within days.

Governance and framework: board resolution approving the ICT risk management framework, governance charter and RACI, committee minutes showing quarterly ICT risk reporting, and a signed and dated ICT risk appetite statement.

Risk and incident management: risk register with KRIs and KPIs and treatment plans, the incident classification decision tree or criteria matrix, and a model incident evidence pack covering summary, timeline, RTS- and ITS-aligned report drafts, root-cause notes, and follow-up actions.

Resilience testing: the annual resilience testing plan, test results and retest evidence with timestamps, and the TLPT scope memo and planning evidence if designated or under assessment.

Third-party risk and Register of Information: the current Register of Information in xBRL-CSV format, the vendor tiering register with criticality classifications and documented rationale, Article 30 contract-clause confirmation for critical and important providers, sub-outsourcing disclosure and flow-down evidence, and exit-strategy documentation for significant providers.

Board evidence file: board member ICT risk training certificates, risk committee minutes referencing ICT risk topics, and quarterly ICT risk reports submitted to the management body.

Per the ITS on the Register of Information, Commission Implementing Regulation (EU) 2024/2956, mandatory fields include the function supported, criticality classification with documented rationale, the location of data processing and storage, the sub-outsourcing chain, and an exit-strategy assessment. Missing fields in any of these categories make up the most common supervisory finding.

Audit readiness holds up when the evidence library stays current every quarter: policies, registers, reports, and records tagged consistently to DORA obligations and RTS or ITS fields, each with a named owner, a refresh cadence, and version history. Gracie AI Agents with Personas and Skills perform activities across that workflow: drafting evidence summaries, flagging gaps against obligations, and maintaining the evidence library between audit cycles, with every action immutably logged and reviewable by a person.

Teams running this way report real speed gains: third-party risk assessments complete 50% faster, and vendor onboarding drops by 40%, mostly because the evidence is already assembled when the decision point arrives. That's part of why customers report making decisions 40% faster overall. Layered on top of the 75% reduction in audit preparation time and the 50 to 65% reduction in manual evidence collection Gracie AI Agents deliver platform-wide, the aim is a programme examiners can watch operate live.