An hour of platform downtime used to end with an apology email and a note in the operations log. Under the Digital Operational Resilience Act it may end with a report to the national competent authority on a defined timetable. That shift in status, from internal issue to supervised event, is the substance of DORA.
What DORA is and who it applies to
DORA is an EU regulation covering information and communication technology risk across the financial sector. Because it is a regulation rather than a directive, it applies directly rather than through national transposition, which removes much of the country-by-country variation firms are used to with MiFID II.
The scope is broad. Investment firms, credit institutions, payment and electronic money institutions, crypto-asset service providers under MiCA, trading venues and several other categories are in. Proportionality applies, so a small firm is not held to the same programme as a systemic bank, but being small does not put you outside the regulation.
For a licensed CFD broker in the EU, the practical answer is straightforward: you are in scope, and the question is only how heavy your implementation needs to be.
The five things it actually asks for
Strip away the recitals and DORA rests on a small number of obligations.
ICT risk management. A documented framework, owned by the management body, covering identification of critical functions, protection, detection, response and recovery. The board cannot delegate accountability for it, which is the sentence that changed governance papers across the industry.
Incident classification and reporting. Firms must classify ICT-related incidents against defined criteria and report major ones to the competent authority, with an initial notification, an intermediate update and a final report. Deadlines are short, so the classification decision has to be made under time pressure by someone who knows the criteria.
Resilience testing. A regular programme of testing appropriate to the firm, with a heavier threat-led penetration testing obligation applying to a subset of significant entities rather than to everyone.
Third-party risk. Contracts with ICT providers must contain specified terms, including access and audit rights, subcontracting conditions, exit strategies and service level provisions. Firms must also maintain a register of information about their ICT arrangements. A designation regime exists for critical third-party providers, placing certain large vendors under direct oversight.
Information sharing. Voluntary arrangements for sharing cyber threat intelligence between financial entities.
The register of information is the obligation firms most often underestimate. It is a structured inventory of every ICT contract, mapped to the functions each supports and flagged where the function is critical or important. Building it late, from scattered contracts and a vendor list nobody owns, is far more work than maintaining it from the start.
What this means for the platform and CRM stack
If your trading platform, CRM, KYC provider or hosting is supplied by a third party, each of those is an ICT third-party arrangement. Under the older outsourcing guidance many firms treated a software licence as a purchase. DORA treats it as a dependency to be documented, contracted for and exited from if necessary.
The questions a vendor should be able to answer in writing: where is the data processed and stored, what is the incident notification commitment to us, who are the material subcontractors, what audit access do we have, and what does an exit look like in operational terms. If the answer to the exit question is that your client data leaves in a format nobody can import, that is a finding waiting to happen. The concentration problem is covered in the piece on platform concentration risk, and the underlying engineering questions in how uptime clusters are built.
Data protection obligations sit alongside all of this rather than being replaced by it. GDPR for trading firms remains a separate regime with its own breach reporting clock, and an incident can easily trigger both.
Where firms are getting stuck
Three patterns come up repeatedly. Contracts signed years ago do not contain the required clauses, and renegotiating with a vendor who has no commercial incentive to reopen the agreement is slow. The register of information is incomplete because nobody in the firm holds a full list of what is running. And incident classification is theoretical until the first real event, at which point the firm discovers that the person who knows the criteria was asleep.
The fix for the third one is unglamorous: a written classification decision tree, a named on-call owner, and one rehearsal. Firms that run a tabletop exercise once a year handle their first real report calmly. Firms that have only a policy document do not.
Supervisory attention to operational resilience is not going to soften, and it interacts with the regular examination cycle described in the broker audits piece. The reasonable posture for a mid-sized firm is a proportionate framework, a maintained register, a tested incident path, and vendor contracts that were reviewed by someone who read the regulation rather than the vendor's summary of it.
This article describes a regulatory regime in general terms. It is not legal advice, requirements are subject to technical standards and supervisory guidance that continue to develop, and firms should take advice on their own scope and obligations.
"Before DORA, a firm could tell its regulator that the outage was the vendor's fault. That answer no longer works, and the contracts had to change to match."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- DORA applies directly across the EU to a wide set of financial entities, including investment firms, payment institutions and crypto-asset service providers.
- Major ICT incidents must be classified against defined criteria and reported to the competent authority on a short, staged timetable.
- ICT third-party contracts must contain specified terms covering audit access, subcontracting and exit, and every arrangement goes into a register of information.
- Accountability for the ICT risk framework sits with the management body and cannot be pushed down to the technology team or out to a vendor.
Frequently Asked Questions
Does DORA apply to a small EU broker?
Yes, if the firm is a listed financial entity type. Proportionality shapes how heavy the implementation must be, but small size does not remove the firm from scope.
Is my trading platform vendor regulated under DORA?
The firm is responsible for the arrangement regardless. Separately, a designation regime can place certain large ICT providers under direct oversight as critical third-party providers, but that applies to a small set of vendors.
How quickly must a major incident be reported?
DORA requires staged reporting with an initial notification followed by intermediate and final reports, on deadlines set out in the regulation and its technical standards. Firms should hold a written classification and escalation procedure rather than deciding at the time.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.