One Year After DORA: Why Brokers Are Still Playing Catch-Up on ICT Incidents, Outsourcing, and Evidence
DORA is no longer a “readiness project.” It has been applicable since 17 January 2025 and applies to a wide range of EU-regulated financial entities, including many investment firms and CFD brokers. (Regulation (EU) 2022/2554).
Yet a year into applicability, we still see the same pattern in broker groups: policies exist, but evidence is thin, vendor governance is inconsistent, and incident reporting is treated as a cyber team task rather than an operating requirement.
DORA compliance is proving to be operationally heavy, especially where firms rely on cloud, market data stacks, white-label platforms, and multi-vendor execution layers.
Publish Date
4 Mar 2026
Reading Time
10 minutes
Category
Legal News
Jurisdiction
EU
What DORA Requires in practice for brokers
DORA is structured around a few practical pillars that matter most to brokers:
- ICT risk management that is owned at senior level, not delegated to IT.
- ICT-related incident classification and reporting based on materiality thresholds, not gut feeling.
- Digital operational resilience testing, including more advanced testing for larger/complex firms.
- Third-party ICT risk management with enforceable contractual and oversight controls.
- Oversight pressure increasing as “critical” ICT providers are designated and supervised by the ESAs.
The catch is that most of this requires “operational proof.” Regulators will not accept a policy set without logs, records, and measurable controls.
Major ICT incident reporting: the thresholds are not vague anymore
A recurring weakness is incident classification. Under the DORA delegated RTS on classification and reporting details (Commission Delegated Regulation (EU) 2024/1772), an incident can qualify as “major” if it meets specific threshold conditions across criteria such as clients/transactions, duration, geographic spread, data losses, reputational impact, and economic impact.
Examples of the “hard triggers” that firms often underestimate:
- Client impact can trigger materiality where affected clients exceed 10% of clients using the affected service, or exceed 100,000 affected clients (among other conditions).
- Service downtime can be material where downtime is longer than two hours for ICT services supporting critical or important functions (again, among other conditions).
- Financial impact thresholds include figures such as €100,000 in some scenarios (as reflected in the RTS criteria).
Operator insight: your incident process must start with a measurable question: did we cross a DORA threshold? If you cannot answer within hours, you have a governance problem, not an IT problem.
Why Cloudflare-type outages are a DORA governance test
Brokers rarely “cause” major outages. They inherit them through vendors.
Cloudflare’s published postmortem on its 20 February 2026 outage explains that the event involved route withdrawals (BGP) affecting customers using BYOIP, leading to reachability failures and timeouts.
When an upstream provider fails, brokers still need to do three things fast:
- classify the incident against DORA thresholds,
- decide whether this is a “major ICT-related incident” requiring reporting, and
- collect evidence for the initial report and follow-ups.
This is exactly where many brokers are still behind. They can write a post-incident narrative, but they cannot produce the evidence pack that DORA expects on day one.
The real backlog: third-party ICT risk and the “register of information”
DORA outsourcing controls are not a one-time legal exercise. Brokers typically run complex stacks: cloud, CRM, KYC vendors, trading platform providers, price feeds, liquidity bridges, comms tooling, and customer support systems.
DORA expects contracts and oversight that match the criticality of each service, plus a maintained record of outsourcing arrangements (often discussed as the “register of information”). National authorities have also published practical instructions and portals for incident reporting and related compliance steps, reinforcing that this is now a supervisory workflow, not a theoretical requirement.
Operator insight: firms get stuck not on the concept, but on classification: which vendor services support “critical or important functions,” and where is the proof that you can monitor and exit?
DORA is also tightening the vendor ecosystem, not only brokers
A major 2025 milestone was the designation of “critical” ICT third-party providers under DORA’s oversight framework, enabling EU-level supervisory authorities to directly oversee certain key providers used by financial entities.
For brokers, that changes the vendor conversation. Large providers will face more structured oversight, but broker obligations do not disappear. If anything, brokers must be able to show they understand dependency concentration and have mitigation plans.
What “good” looks like one year into DORA
If we were assessing a broker group today, we would not start with policy documents. We would start with “proof.”
A practical DORA maturity checklist for brokers:
- Incident classification playbook mapped to RTS thresholds, with decision logs.
- Reporting readiness: who drafts, who approves, who submits, and by when.
- Vendor inventory and criticality scoring tied to business functions.
- Contract clauses that match DORA expectations and real operations.
- Evidence of monitoring, testing, and remediation, not only annual reviews.
- A realistic exit strategy for critical vendor dependencies.
The difference between “compliant” and “exposed” is usually the same: can you evidence control operation under stress?
How we help
We help brokers, investment firms, and payment and fintech groups translate DORA into an operating model that survives outages and inspections. That includes incident classification design, reporting workflows, outsourcing governance, and evidence packs aligned to DORA RTS/ITS.
FAQ: DORA for brokers and trading firms
When did DORA start applying?
DORA has been applicable since 17 January 2025.
What makes an ICT incident “major” under DORA?
Materiality is assessed against specific criteria and thresholds set out in the delegated RTS, including client impact and downtime thresholds.
Do vendor outages still trigger broker obligations?
Yes. Even if the incident originates at a provider, the broker must classify it, decide whether reporting is required, and collect evidence.
Why are brokers still “catching up”?
Because DORA requires operational proof: logs, decision records, vendor criticality mapping, and working reporting processes—not only policies.
Check Our Available Ready-Made Licenses
Below are all the off-the-shelf license options available for purchase. Browse through the list of licenses and read the details to choose the option that is right for your business:
