# What to Prepare Before a DORA Supervisory Review Source: https://www.cyadviso.com/dora-inspection-preparation Last reviewed: 2026-07-28 Tags: DORA, Supervisory Review, Compliance, ICT Risk After receiving a DORA supervisory review notice, EU-licensed fintechs have weeks to prepare. This checklist covers the ICT risk documents NCAs request first. --- **Last reviewed: 28 July 2026** **Key takeaways** - After a DORA supervisory review notice, the initial phase typically runs four to eight weeks — the window to assemble the evidence package the NCA examines. - The recurring pattern: documents exist but reflect the last advisory engagement, not the current state — a stale risk register, no recent management body ICT risk reporting, a third-party register missing new vendors. - The post-notice checklist runs in six steps: confirm scope, assess framework state, compile the evidence index, update the third-party register, verify management body oversight, and review incident classification. - These are operational gaps, not document-assembly tasks; where the ICT risk function operates continuously, the review is a verification exercise, not a first attempt to pass. --- When a National Competent Authority issues a DORA supervisory review notice, the typical initial phase runs four to eight weeks. That is the window for a fintech to pull together the evidence package the NCA will examine: the ICT risk management framework documentation, management body oversight records, the incident log, and the third-party ICT provider register. The pattern CyAdviso encounters consistently is this. EU-licensed fintechs receive the notice and find that their documents exist but reflect the state at the time of their last advisory engagement rather than the current state. The risk register has not been updated since that project closed. The management body has received no dedicated ICT risk report since the consultant delivered their findings. The third-party register does not include vendors onboarded in the past twelve months. DORA Article 6(1) requires the ICT risk management framework to be "sound, comprehensive and well-documented." Sound means operating continuously, not assembled when a notice arrives. If the notice is your first trigger to update the register, the review will find what it finds. This is the post-notice playbook: what an EU-licensed fintech should work through in the weeks *after* a review notice arrives, in parallel with normal operations. It is not a substitute for ongoing ICT risk governance. For the examination side — what an NCA actually examines and the finding patterns it applies — see the hub article [what NCAs examine in a DORA supervisory review →](/dora-supervisory-review). That article covers what is reviewed; this one covers how to prepare for it. --- ## How to prepare for a DORA supervisory review ### Step 1: Confirm the scope and timeline in the notice Read the notice carefully. NCAs use different formats: an initial supervisory questionnaire, a document request letter, an invitation to a supervisory meeting, or a notification of on-site examination. Each has different urgency and documentation requirements. The notice will state the scope: specific DORA titles, specific risk areas, or a general ICT risk management framework review. Note the response deadline. If anything in the notice is ambiguous, contact the NCA coordinator named in the letter promptly. A delayed clarification question delays your preparation by the same amount. Assign internal accountability for the response. One person should own the preparation process and serve as the primary contact point with the NCA. Where the ICT risk function is externally resourced, brief the external function owner immediately and confirm their availability for the response period. ### Step 2: Assess the current state of your ICT risk management framework Before assembling documents, assess where the framework stands. Work through the core DORA Title II requirements: ICT risk policy (Article 6), ICT asset identification and risk classification (Article 8), security controls (Article 9), anomaly detection (Article 10), business continuity and ICT incident response plans (Article 11), and backup and recovery procedures (Article 12). For each area: is the document current? When was it last reviewed? Does it reflect the actual ICT environment the entity operates today, not the environment at the time the policy was written? An NCA does not only check whether a policy exists. It checks whether the policy corresponds to how the entity actually operates. If significant gaps appear at this stage, note them. A gap addressed before the review is managed. A gap discovered during the review becomes a finding. If your organisation has not completed a [DORA gap assessment →](/dora-gap-analysis), this step effectively becomes one. It should not be the first time you are doing this assessment. ### Step 3: Compile your ICT evidence index The ICT evidence index is the practical organiser for the supervisory response: a structured list of all DORA-relevant documents, their location, their last review date, and their current status. NCAs typically request documents against this kind of index during the questionnaire phase. Without it, requests generate confusion about which document version applies to which DORA requirement. A complete evidence index covers: the ICT risk management policy and framework documentation; the ICT risk register with the date of last update and the name of the function owner; the ICT incident log with classification records; management body ICT risk reporting records; the third-party ICT provider register under Article 28; and ICT testing records under Articles 24 through 27. For a structured template to build this index, see the [DORA evidence index template →](/dora-evidence-index-template-fintech). The index should be assembled before the first NCA document request arrives, not in response to it. Entities that also hold a SWIFT connection run a parallel evidence cycle on the same kind of clock: see our [SWIFT CSP independent assessment](/swift-csp-independent-assessment) page for how the CSCF findings report and attestation-ready summary fit alongside this index. ### Step 4: Review and update your third-party ICT provider register Article 28(3) requires a register of all third-party ICT service providers; Article 29 requires an assessment of concentration risk. NCAs request this register early in supervisory reviews because it quickly reveals the entity's operational dependencies and how those dependencies are governed. Check the register against current vendor relationships. Cloud providers, SaaS platforms, payment processors, core banking systems, and any infrastructure vendor providing ICT services to the entity should be included. Verify that contractual documentation exists against Article 30 requirements. Assess whether any single provider failure would cause significant service disruption without viable alternatives: this is the concentration risk question Article 29 is designed to surface. Any vendors onboarded since the last register update must be added. NCAs compare the register against invoicing records and system access logs when the register appears incomplete. Gaps in the register are among the most common findings in early DORA supervisory reviews. ### Step 5: Verify management body oversight documentation Article 5(2) requires the management body to approve and oversee the ICT risk management framework. Article 5(4) requires the management body to maintain updated knowledge of ICT risks. Before the review, locate and confirm the following: the formal management body approval of the ICT risk management framework, recorded as a resolution, board minute, or decision record; ICT risk reports received by the management body with their dates; any material ICT risk decisions documented at management body level; and evidence of the board's review of the framework after material incidents or regulatory triggers. This documentation is distinct from compliance reporting. An annual compliance report that refers to ICT risk in a summary section does not satisfy Article 5(4). Regulators look for a dedicated ICT risk reporting track: regular, documented, with records showing that the management body engaged with ICT risk information and made or ratified decisions based on it. ### Step 6: Review ICT incident records for DORA-aligned classification Articles 17 through 23 establish the incident reporting framework: severity classification criteria, initial notification timelines, and final incident report requirements. NCAs examine incident records to verify whether the entity applied DORA-aligned classification to incidents that occurred during the review period. Work through the incident log against the classification criteria in Article 18. For any incident classified as major under DORA, verify that the initial notification was made within the required timeline and that a final report was submitted. For incidents not classified as major, document the classification rationale: the NCA may ask why a given incident did not meet the major threshold. If the entity has operated under DORA since January 2025, the incident log should cover that period. The absence of any recorded incidents across an extended period is not automatically a finding, but an implausible gap may prompt questions about whether the detection mechanisms required under Article 10 are functioning. --- ## What NCAs request first Based on preparation work undertaken with EU-licensed fintechs under EU financial-sector supervision, the first-phase document requests in a DORA supervisory review typically cover: - The ICT risk policy document, aligned to DORA Articles 5 through 16. - The current ICT risk register, with the date of last update and the name of the function owner. - Management body ICT risk reporting records from the previous twelve months. - The third-party ICT provider register under Article 28. - ICT incident records from the previous twelve months, with classification rationale. The second phase, where the NCA proceeds to a deeper documentary review or on-site examination, typically adds: ICT business continuity and incident response plans with test records; the ICT testing programme documentation under Articles 24 through 27; and governance records for critical third-party ICT dependencies, including subcontractor chains where relevant. --- ## The gaps that generate findings The canonical finding taxonomy NCAs apply is set out in [what NCAs examine in a DORA supervisory review →](/dora-supervisory-review); the gaps below are the same patterns seen from the preparation side, not a separate list. The most consistent pattern in early DORA supervisory reviews of EU-licensed fintechs is not a missing policy. It is a policy or register that does not reflect the current state of the entity. The ICT risk register reflects the advisory engagement from eighteen months ago. The management body has received no dedicated ICT risk reporting since that engagement closed. The third-party register shows the vendors the entity had at the time of the last register exercise, not the current vendor set. The incident log exists, but incidents are classified according to internal IT severity tiers rather than DORA criteria under Articles 17 through 18. These are operational gaps, not documentation gaps. Closing them requires an ICT risk function that operates on an ongoing basis, not a document assembly exercise triggered by the review notice. The review verifies that the function operates. The preparation confirms it does. {/* [HUMAN-FILL: anonymized vignette — category (EMI/PI/CASP) + regulator-as-subject + outcome, C-1 name-scan before publish. Natural slot: one anonymized post-notice preparation where stale evidence was the gap, and what closing it required. No client name, no fabricated numbers ([live-check]). */} [Latvijas Banka, the Latvian National Competent Authority](/dora-bank-of-latvia), and [Lietuvos bankas, the Lithuanian National Competent Authority](/dora-bank-of-lithuania) have both emphasised in supervisory guidance that documented ongoing ICT risk governance, rather than periodic advisory engagement, is the expected standard under DORA Title II. --- ## Frequently asked questions ### What should a fintech do immediately after receiving a DORA supervisory review notice? Read the notice for scope, format, and response timeline. Assign one person as the internal coordinator for the response and, where the ICT risk function is externally resourced, brief the external function owner immediately. Begin the evidence index assessment (Step 3) and the ICT risk framework review (Step 2) in parallel. Do not wait until the full picture is clear before starting: the preparation time is fixed, and the clock starts when the notice is received. ### How long does a fintech typically have to respond to a DORA supervisory review notice? DORA does not set a uniform response timeline. An initial supervisory questionnaire phase typically runs four to eight weeks, depending on the NCA, the scope, and the entity's complexity. An on-site examination is typically scheduled with two to four weeks' notice after the questionnaire phase. Response timelines are stated in the notice. Under DORA Article 6(5), the ICT risk management framework and its supporting evidence should be maintained continuously: the notice should not be the moment the evidence is first assembled. ### What are the most common gaps NCAs find in EU fintech DORA preparations? The most consistent pattern is an ICT risk register or evidence package that reflects the state at the time of the last advisory engagement rather than the current state. Related findings include: no dedicated management body ICT risk reporting (compliance reports only); a third-party register missing vendors onboarded after the last register exercise; and ICT incident classification based on internal IT tiers rather than DORA criteria under Articles 17 through 18. These are function gaps. They indicate that the ICT risk management framework has not operated on an ongoing basis since the last project. ### Does a fintech need legal support during a DORA supervisory review? DORA supervisory reviews are regulatory examinations, not enforcement proceedings. Legal representation is not required during the examination and document request phase. Fintechs typically manage supervisory reviews through their ICT risk function owner and compliance officer. Legal support becomes relevant if the review produces formal findings, a remediation requirement, or enforcement proceedings under DORA. During preparation and examination, the ICT risk function owner is the appropriate operational contact. --- ## How CyAdviso supports DORA supervisory review preparation CyAdviso works with EU-licensed fintechs, including EMIs, Payment Institutions, and CASPs, to prepare for and manage DORA supervisory reviews. Based on engagements under EU financial-sector supervision, the typical scope covers: ICT risk framework gap assessment against DORA Articles 5 through 16; evidence index assembly and quality review; management body oversight documentation review; and, where CyAdviso acts as the ICT risk function owner, direct coordination of the supervisory response. The preparation work described in this checklist is most effective when it is not the first time the entity has done it. Where the ICT risk function operates continuously, a supervisory review is a verification exercise. Where the function has not been maintained, the review becomes both the test and the first attempt to pass it. To discuss your fintech's readiness for a DORA supervisory review, [schedule a consultation with CyAdviso](https://cal.com/andrey-gubarev/15min) or contact us at info@cyadviso.com. --- Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA). CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs. Canonical HTML: https://www.cyadviso.com/dora-inspection-preparation