AFM DORA Update 7: Strong Register Progress, but ICT Quality and Incident Reporting Gaps Remain
The Dutch Authority for the Financial Markets (AFM) published its seventh DORA progress update on 6 August 2026, and it carries a split verdict. EBA-approved ICT third-party registers have surged from 40 percent in 2025 to 94 percent in 2026, which is a genuine leap forward. At the same time, the AFM has identified persistent weaknesses in register data quality, policy documentation, and incident notification volumes that it expects firms to address without delay. For accounting firms, auditors, and CFOs operating in the Dutch and broader EU financial sector, the update is a checklist in everything but name.
What DORA Requires and Why the AFM Is Still Watching
The Digital Operational Resilience Act came into force across the EU in January 2025, imposing binding requirements on financial entities covering ICT risk management, incident classification and reporting, third-party risk oversight, and digital resilience testing. The AFM is the designated competent authority for most financial firms licensed in the Netherlands, and it has been running supervisory reviews since DORA's application date.
Scope of the Supervisory Reviews
The AFM's oversight covers ICT policy frameworks, procedures, and the registers that firms must maintain to document their use of ICT third-party service providers. The EBA manages a centralised register of such providers, and national competent authorities assess whether the entries submitted by firms in their jurisdiction meet the required format and completeness standards. The jump to 94 percent approval is attributed, in the AFM's own assessment, largely to firms gaining familiarity with the required format rather than to substantive improvements in underlying data quality. That distinction matters because format compliance and substantive accuracy are not the same thing.
The Three Specific Gaps the AFM Has Identified
The update does not read as a congratulatory notice. The AFM uses its supervisory findings to highlight three areas where action is still needed.
1. ICT Register Quality and Underlying Data
The AFM explicitly warns that firms should not treat register approval as a sign-off on data quality. Approval means the format was acceptable; it does not validate the accuracy or completeness of the information entered. The regulator calls on firms to maintain ongoing attention to the quality of the register and its underlying data so that future information requests from supervisors can be handled smoothly. For any firm that has submitted a register and moved on, that is a direct prompt to schedule a data accuracy review.
2. Policy Documentation and Periodic Self-Assessment
Supervisory investigations have found that not all firms hold every mandatory policy document and procedure that DORA requires, and that some of those that do exist do not accurately reflect how the firm actually operates. The AFM's instruction is clear: firms should verify that their ICT risk management framework, policies, and procedures are current and aligned with day-to-day practice.
A specific sub-issue arises for firms that rely on group-level policies drafted by a parent entity or group compliance function. DORA places regulatory responsibility squarely on the licensed entity, not the group. A firm cannot delegate accountability upward. If a policy was written at group level, the licensed entity must independently verify that every applicable DORA requirement is actually covered in that document. The AFM makes clear that the licence holder remains responsible regardless of where the policy originated.
3. Incident Detection, Classification, and Notification
Incident reporting volumes received by the AFM are running below what the regulator expected given the size and activity levels of the supervised population. This indicates one or more of the following: incidents are not being detected promptly, they are being classified below the thresholds that trigger a reporting obligation, or the internal workflow from detection to notification is not functioning within the legally required timeframes. The AFM's instruction is to ensure that incidents are detected quickly, classified correctly, and reported to the regulator within statutory deadlines where that obligation applies.
Threshold Calculations for Insurance Intermediaries
A more technical piece of the update addresses insurance intermediaries specifically. Additional guidance is now available on how threshold values should be calculated when insurance mediation represents only a minor part of a firm's overall activities. Parallel clarification has also been provided on threshold calculations within group structures. Any insurance intermediary that has not already reviewed the relevant Q&As should do so to determine whether its current threshold methodology needs adjustment.
What This Means for Accounting Firms, Auditors, and CFOs
DORA's direct scope covers financial entities, but the practical workload lands on compliance teams, internal audit functions, external auditors, and the advisers those firms rely on. The AFM update sharpens several audit and advisory obligations.
Audit and Assurance Implications
External auditors reviewing DORA compliance programmes should treat the AFM's specific findings as a framework for fieldwork. The three gaps identified, register accuracy, policy completeness, and incident process functionality, map directly onto audit procedures. A review that confirms format-level EBA register approval without testing the underlying data accuracy is not providing the assurance that clients and regulators now expect.
For firms that use crypto accounting software or digital asset accounting software as part of their ICT estate, those tools qualify as ICT services within the DORA framework if they are material to the firm's operational continuity. That means the contracts, service levels, sub-processing chains, and concentration risks associated with those tools may need to appear in the ICT third-party register. Auditors should ask whether the firm has made that assessment and documented its conclusion.
CFO and Finance Function Actions
CFOs at Dutch-licensed financial entities carry budget and governance responsibility for the ICT estate that DORA covers. The update creates at least three near-term actions at the finance and governance level.
First, commission a data quality review of the ICT third-party register if one has not been completed since the initial submission. Format approval is not a substitute for accuracy. Second, request confirmation from legal or compliance that every mandatory DORA policy document exists, is current, and reflects actual operating practice. If the firm relies on group-level policies, the review must confirm that those documents meet the full DORA standard for the licensed entity specifically. Third, verify that the incident management process has a functioning detection-to-notification workflow with defined ownership and documented timelines. If incident reporting volumes internally are low, that may indicate a classification or detection problem rather than genuinely low incident frequency.
Implications for Digital Asset and Crypto-Active Firms
Crypto asset service providers and other digital asset firms that hold Dutch licences or passporting authorisations are subject to DORA on the same basis as traditional financial firms. For these entities, the ICT third-party risk register is particularly complex because the technical stack often includes a larger number of third-party dependencies: blockchain node providers, custodians, oracle services, and software-as-a-service platforms. Each material dependency requires assessment and, where applicable, inclusion in the register.
The incident reporting gap flagged by the AFM is especially relevant here. Digital asset operations are exposed to a broader range of operational incidents, from smart contract failures and key management events to exchange connectivity outages, than traditional financial services. If the incident classification criteria have not been calibrated to that environment, reportable events may be going unrecognised. Firms should map the DORA incident classification criteria against the specific incident types their operations generate.
For firms using crypto bookkeeping software or other digital asset accounting software that is integrated into core financial reporting workflows, that integration itself warrants a DORA materiality assessment. The question is whether a disruption to that software would impair the firm's ability to meet its financial reporting or regulatory obligations. If the answer is yes, the provider likely belongs in the ICT third-party register.
This is also a relevant consideration in the context of ESMA's fourth MiCA CASP register update, which has been expanding the population of authorised crypto asset service providers across the EU. As more firms obtain formal authorisation, DORA obligations apply to them in full from the point of licence, not after a transitional period. The AFM update is a timely reminder that DORA compliance is a continuous programme, not a one-time implementation project.
Periodic Self-Assessment as a Compliance Discipline
One of the most practical recommendations in the AFM update is the call for periodic self-assessment of DORA compliance. The word periodic is deliberate. DORA requirements do not change with every regulatory cycle, but the firm's operations, contracts, and ICT estate do. A policy that was accurate at implementation may not reflect current practice twelve months later. A register that was complete when submitted may omit services added since then.
Building a Self-Assessment Calendar
Firms should treat DORA self-assessment as a scheduled activity, not a reactive one. A practical approach is to align the review cycle with the firm's annual risk assessment and audit planning timetable. The review should cover: completeness and accuracy of the ICT third-party register; currency and operational accuracy of all mandatory policy documents; functionality of the incident detection, classification, and reporting workflow; and, for group-subsidiary structures, confirmation that group-level policies satisfy the licensed entity's obligations in full.
Advisers working on AML and sanctions best practices for digital asset firms will recognise this rhythm. Operational resilience, like AML compliance, requires ongoing monitoring rather than point-in-time assessment. The AFM's update reinforces that principle explicitly.
Frequently Asked Questions
Does DORA apply to crypto asset service providers licensed in the Netherlands?
Yes. Any entity holding a financial sector licence in the Netherlands, including those authorised under MiCA as crypto asset service providers, falls within DORA's scope. The AFM is the competent authority for most such firms and applies DORA requirements on the same basis as it does for banks, investment firms, and insurers.
What does EBA register approval actually confirm?
EBA approval of an ICT third-party register confirms that the submission met the required format. It does not validate the accuracy, completeness, or currency of the underlying data. The AFM has explicitly stated that firms should not treat format approval as a quality sign-off.
Can a firm rely on group-level DORA policies prepared by its parent?
A firm may use group-level policies as a foundation, but it cannot simply adopt them without independent verification. DORA places compliance responsibility on the licensed entity. The firm must confirm that every DORA requirement applicable to it is fully addressed in those documents. If gaps exist, the firm is accountable, not the group.
Why are incident reporting volumes below the AFM's expectations?
The AFM has not specified a single cause, but the likely factors include incidents being classified below the thresholds that trigger a reporting obligation, detection delays that push notifications outside statutory timeframes, or gaps in the internal workflow between incident identification and regulatory notification. Firms should review each stage of that process.
Does crypto accounting software need to appear in a firm's ICT third-party register?
It depends on a materiality assessment. If a disruption to the software would impair the firm's ability to meet its financial reporting, client servicing, or regulatory obligations, it is likely material and should be included. Firms should document their assessment reasoning regardless of the conclusion they reach.