The Digital Operational Resilience Act (DORA) has applied to EU financial entities since 17 January 2025. For a CySEC-regulated FX or CFD broker, that is not a future deadline to plan around - it is a live obligation, and supervisors are now actively checking that firms have implemented it. Investment firms are squarely in scope, which means the broker's Cyprus Investment Firm (CIF) authorisation carries DORA obligations alongside the MiFID and CySEC requirements the compliance team already manages.
Many brokers came into this holding an ISO 27001 certificate, often obtained to satisfy institutional counterparties, liquidity providers, or a group information security policy. That certificate is genuinely useful. But "ISO 27001 certified" is not the same as "DORA compliant", and a supervisor will not treat the two as interchangeable. Understanding exactly where the certificate carries over - and where it does not - is what keeps a broker from either doing the work twice or discovering a gap during a supervisory review.
Why the certificate is not enough
ISO 27001 is a voluntary management-system standard assessed by a certification body. DORA is a directly applicable regulation enforced by the competent authority - for a Cyprus broker, that is CySEC. The audiences, the assessment criteria, and the consequences of falling short are different. An ISO 27001 auditor asks whether the information security management system conforms to the standard and is effective. A DORA supervisor asks whether the firm has implemented DORA's specific requirements and can demonstrate operational resilience under stress.
There are four areas in particular where DORA imposes obligations that an ISO 27001 certificate does not fully evidence.
1. An ICT risk framework owned by the management body. DORA places ultimate responsibility for ICT risk on the firm's management body - the board and senior management - not on the CISO or an IT function. The board must approve the ICT risk management framework, understand the firm's ICT risk exposure, and be able to show active involvement. ISO 27001 requires leadership commitment and top-management support, but it does not require the specific board ownership and accountability structure that DORA prescribes for ICT risk. For many brokers this is a governance change, not just a documentation change: the board minutes need to show the directors engaging with ICT risk, not delegating it.
2. Major-incident classification and regulatory reporting. ISO 27001 requires an internal incident management process with defined roles, records, and lessons learned. DORA goes further: firms must classify ICT-related incidents against prescribed criteria, and where an incident is classified as major, report it to the competent authority on a regulated timeline - an initial notification, an intermediate report, and a final report, each with its own deadline under the technical standards in force. ISO 27001 does not require any external regulatory reporting. A broker with a mature ISO 27001 incident procedure still needs a separate DORA classification methodology and a tested workflow that connects the incident response team to CySEC reporting within hours, not days.
3. A digital operational resilience testing programme. DORA requires a programme of regular testing of ICT tools and systems - vulnerability assessments, scenario-based testing, and more. For entities identified as significant, it also requires threat-led penetration testing (TLPT) against critical systems on a defined cycle. ISO 27001 covers management of technical vulnerabilities and independent review, and many certified brokers already run penetration tests, but ISO 27001 does not mandate a structured, recurring resilience testing programme with the scope and methodology DORA sets out. The testing has to be a defined programme with documented cadence, not an ad hoc annual exercise.
4. A prescribed ICT third-party register with contract, monitoring, and exit terms. This is often the largest gap. DORA requires firms to maintain a register of information on all contractual arrangements for the use of ICT services, classify which providers support critical or important functions, and ensure contracts contain specific provisions: audit and access rights, service levels, data location, incident cooperation, and - importantly - documented exit strategies. Firms must also assess concentration risk, meaning how dependent they are on any single provider. ISO 27001 supplier controls require written agreements with security terms and periodic review, but they do not require the prescribed register format, the exit-strategy provisions, or the concentration-risk analysis. For a broker running on a handful of critical vendors - trading platform, liquidity aggregation, cloud hosting, KYC and payments - this register and its exit planning are usually net-new work.
Where ISO 27001 evidence does carry over
The good news is that a broker holding ISO 27001 does not start from zero, and should not rebuild what it already has.
The ISO 27001 risk register, with treatment plans, owners, and review evidence, feeds directly into the DORA ICT risk framework - the underlying risk-based lifecycle is broadly the same. The asset inventory from the ISMS supports DORA's requirement to identify ICT assets, provided it is extended to flag which assets support functions the firm has classified as critical or important. The internal incident management procedure supplies the operational backbone that the DORA classification and reporting workflow sits on top of. The supplier documentation and existing contract review discipline give a head start on the ICT third-party register. And the governance habits an ISMS builds - internal audit, management review, documented policies - materially reduce the DORA implementation workload. Starting DORA from scratch with no management system in place is considerably harder.
The practical tool for capturing this is the Statement of Applicability. A broker can extend the SoA mapping so each Annex A control is tagged with the relevant DORA article where one exists. Controls that appear in both can be evidenced once; controls that appear only under DORA flag the genuine gaps.
Where a broker should start
A workable sequence for a CIF broker looks like this.
First, map the existing ISO 27001 control set to DORA articles so the overlap and the gaps are explicit. Second, build the ICT third-party register: inventory every ICT contract, classify criticality, and review each critical contract against DORA's required provisions, including exit terms. Third, define the major-incident classification and reporting workflow and test it end to end, so the team knows exactly who decides an incident is major and how the CySEC notification goes out within the deadline. Fourth, stand up a resilience testing cadence with documented scope and frequency, and determine whether the firm is in scope for TLPT. Fifth, put ICT risk formally under the board, with the framework approved and directors demonstrably engaged.
You can read more about how these pieces fit together in the DORA readiness overview, and how the underlying information security controls are structured in the ISO 27001 guide.
An honest word on outcomes
Kellwick prepares firms for this work - the mapping, the register, the incident workflow, the testing programme, and the governance changes that put ICT risk where DORA expects it. What Kellwick does not do is supervise or certify DORA compliance. That assessment sits with the competent authority. No adviser can guarantee a supervisory outcome, and any that claims to should be treated with caution. What good preparation does is make sure that when CySEC asks, the broker can produce a coherent ICT risk framework, a complete third-party register, a tested reporting procedure, and evidence of board ownership - rather than an ISO 27001 certificate and the hope that it counts for more than it does.
Not sure what applies to you?
Applicability first: DORA, NIS2, NIST CSF 2.0, SOC 2 or CMMC, read against your sector and jurisdiction.