Dutch supervisors are looking past policies to the people, suppliers and records that keep markets functioning.
At 02:17, an operations manager receives an alert. The system controlling access to a trading platform is behaving unusually. An outside provider hosts part of the environment. A group technology team runs another part. An engineer asks for permission to make an emergency change before the market opens.
The technology problem is urgent. The business decisions are just as urgent. Who owns the call? Which logs can the team trust? Could this be a major ICT-related incident? Who can notify the regulator, and does that person have access to the AFM portal?
These are the practical questions behind the AFM’s June 2026 review of ICT-risk management at trading venues. The review covered regulated markets, multilateral trading facilities and organised trading facilities. The venues generally had DORA’s foundations in place, while security monitoring, access management, logging, emergency changes and continuity management still needed work.
The direction is clear. A licensed company may outsource technology, but responsibility remains with the company.
The policy is not the operating system
DORA has applied since 17 January 2025. It covers ICT-risk management, major incident reporting, digital resilience testing, third-party ICT risk and cyber-threat information sharing for financial entities within its scope.
The AFM found that gap analyses at reviewed trading venues were often too general. Policies and procedures were not always clearly separated. That distinction matters when a system fails.
A policy sets direction, responsibility and approval. A procedure tells an employee what to do at 02:17. It identifies who receives the alert, who can authorise a change, who classifies the incident and how the team records the decision.
When a firm confuses the two, it creates a double weakness. The board may believe it has approved a working framework. The engineer may still rely on personal knowledge and hurried telephone calls. The company then moves more slowly and has a harder time reconstructing its decisions.
The register must describe the real business
The AFM’s 6 August update adds another layer. The share of information registers approved by the European Banking Authority rose from 40 percent in 2025 to 94 percent in 2026 across the wider AFM-supervised population. That shows progress in submission quality. It also puts continuing attention on the quality of the information behind each register.
A useful register reflects the live technology environment. It shows which supplier supports which critical function, what the service does, and where group companies or subcontractors enter the chain.
Descriptions such as “data exchange” or “IT support” offer little help during an incident. A stronger record shows whether a provider handles market data, identity controls, hosting, connectivity, monitoring or order flow. It also records the provider’s access and the recovery steps that depend on it.
The financial consequences reach beyond the technology invoice. A company that cannot explain a critical dependency will struggle to negotiate recovery commitments, audit rights, subcontracting transparency or exit support. During an outage, investigation, remediation, customer communication, management time and supplier disputes may carry the greater burden.
Group support does not remove local ownership
Many smaller regulated firms rely on group technology. That can be efficient and sensible. The AFM’s review found that DORA requirements were not always consistently reflected in group-level policies and documentation.
The governance point is straightforward. The Dutch licensed entity must check whether group documentation covers its own systems, risks and duties. A headquarters template cannot answer every local question. It may miss the Dutch reporting route, a specific trading connection or the authority needed outside office hours.
Return to the overnight incident. The group security team may control the monitoring platform. An external cloud provider may host the affected service. Neither arrangement tells local management whether trading can open safely, whether an emergency change is authorised, or whether the event meets the reporting criteria.
For AFM-supervised firms, major DORA incidents are reported through the AFM portal. Directors and statutory representatives are authorised in principle. Other employees require portal authorisation. After a firm classifies an event as major, the initial notification is due within four hours and no later than 24 hours after detection. An intermediate report follows within 72 hours, with a final report within one month of that intermediate report.
Authority and access therefore belong in the incident design. They should not emerge from an email drafted after the event.
Testing should expose decisions, not only defects
Certain DORA entities may be selected for threat-led penetration testing once every three years. For those entities, the test can reach critical or important business functions and the live production systems supporting them. Trading venues may be selected through market-share criteria or because of their ICT-risk profile, systemic character or potential effect on financial stability.
That standard reveals DORA’s deeper purpose. Resilience is not a certificate purchased from a cyber supplier. It is the capacity to connect systems, contracts, people and decisions under pressure.
A useful test shows whether alerts reach the right person, privileged access is controlled, emergency changes leave usable records and recovery can proceed while preserving evidence. These are operating questions. They sit as much with management and the board as with the security team.
Technology suppliers should take notice too. A supplier serving a regulated venue can expect sharper questions about access, logs, subcontractors, recovery times and incident cooperation. Those questions can affect contract value, insurance discussions and the strength of the client relationship.
By market opening, the overnight team needs one coherent answer. It needs a named decision-maker, reliable evidence, a controlled recovery route and clear reporting authority.
That is where Dutch supervision is heading. The rulebook matters, but the working system carries the real weight. When the screen goes dark, the company must still know who decides, who acts and who answers.
If your firm needs to test whether its DORA governance will hold up during a real trading-system incident, contact Pavan Geraedts.
The data, sourcing, and analysis behind this article were conducted by Paolo Maria Pavan. AI was not used to identify sources, build the factual basis, or produce the analytical judgment contained here. AI was used only as a drafting aid. The final English text was personally reviewed, edited, and approved by Paolo Maria Pavan before publication.
References
- Handelssystemen vragen om scherpere ICT-risicobeheersing onder DORA
- Autoriteit Financiële Markten - Later AFM update: implementation has progressed, proof and operational reporting remain weak points
- De Nederlandsche Bank - Supplier register, subcontracting visibility and formal reporting
- De Nederlandsche Bank - Incident reporting is a technical and governance process, not only an operational response
- Autoriteit Financiële Markten - Authority, access and the AFM reporting route
- Autoriteit Financiële Markten - Testing critical trading functions under supervisory oversight
- De Nederlandsche Bank - AI-driven cyber pressure and dependency concentration
- De Nederlandsche Bank - Digital autonomy, exit capacity and supply-chain resilience
