What CISOs need to know about DORA
The EU has been working on the Digital Operational Resilience Act (DORA) for some time, and it's finally made it into law at the EU and member state level. As with all EU regulation there's been a lot of wailing and gnashing of teeth - largely from US companies - about how very dare government try and enforce some decent security standards. Although DORA has been a legal obligation since the start of 2025, a number of EU countries were slow to set up the reporting framework within their 'competent authorities', which gave plenty of organisations a grace period to get their compliance in place. That grace period is now well and truly over.
In this article I'm going to cut through the FUD and explain what DORA is, what CISOs need to do, who is on the hook for what, and why this level of regulation is well overdue.
What is DORA?
DORA is a single set of rules for managing Information and Communication Technology (ICT) risk across the EU financial sector. It covers banks, insurers, investment firms, payment providers, crypto-asset service providers and a long list of others, along with the ICT suppliers they rely on. Before DORA, every regulator in every member state had their own take on what good looked like. Now there is one rulebook, with the detail filled in by technical standards from the three European Supervisory Authorities (the EBA, EIOPA and ESMA).
DORA is built on five pillars:
ICT risk management
ICT incident reporting
Digital operational resilience testing
ICT third-party risk management
Information and intelligence sharing
If you've been doing security properly for the last decade, none of this will come as a surprise. It is the basics of good security practice, written into law with deadlines and fines attached.
Who is responsible for what?
This is the part your board needs to read twice, because the outdated idea that security is just about technology is now properly dead. Senior leadership across the business are not - quite rightly - being held accountable for security within the business.
Article 5 of DORA says the management body "shall define, approve, oversee and be responsible for" the ICT risk management framework. The board carries the can. They have to approve the digital operational resilience strategy, set the organisation's tolerance for ICT risk, approve the business continuity and recovery plans, approve the policy on using ICT suppliers, and sign off the internal ICT audit plans. They also have to put budget behind it, including for security awareness and training.
My favourite bit is that the board members themselves have to keep their knowledge and skills up to date so they actually understand ICT risk. I've sat in plenty of board meetings where a director proudly announced they "don't really do computers", or "That's why we have a CTO". Under DORA, that director is now a compliance problem and a business risk in themselves.
Day to day ownership of ICT risk sits with a control function that DORA requires to have "an appropriate level of independence". In practice that's normally the CISO, and DORA expects a three lines of defence model (or something equivalent) so the people running the systems aren't the same people marking their own homework. If your CISO reports into the CIO, with no direct line to the board or the risk committee, you will struggle to show that independence to a regulator.
Internal audit has to review the framework regularly, using auditors who know what they're looking at, and there has to be a formal follow-up process for what they find.
Someone also has to own third-party ICT risk, either as a dedicated role or as a named member of senior management. In most organisations I've worked with, this is the bit that falls through the cracks between procurement, legal, and security, with each team assuming one of the others is dealing with it.
Finally, the big cloud and tech providers designated as critical ICT third-party providers are now directly overseen by the European Supervisory Authorities. Some people have taken this to mean the regulator is now checking AWS and Microsoft for them. It isn't. You remain responsible for the risk of depending on those providers, and you'll still be asked to show how you manage it.
What your ISMS already covers
The good news is that if you have a working Information Security Management System (ISMS), you're a good way down the road already.
An ISO27001 ISMS gives you a risk assessment methodology, a risk register and treatment plans, documented policies, defined roles and leadership commitment, internal audit, and management review. That is very much the shape of the DORA ICT risk management framework. The Annex A controls give you a solid base for asset management, access control, cryptography, logging and monitoring, vulnerability management, incident management, backups, and supplier security. If you've also got ISO22301 for business continuity, you've covered a lot of DORA's continuity and recovery requirements as well.
Your existing security awareness programme can be extended to cover DORA's training requirements, and your internal audit and management review cycle already gives you the continual improvement loop the regulation expects.
ISO27001 and SOC2
I still see a lot of organisations holding up a SOC2 report as evidence that they are secure. SOC2 is an auditor's opinion on a set of controls that you chose, written to reassure your customers. It tells a regulator very little about how you identify, manage and govern risk across the business.
ISO27001 is a management system. It forces leadership involvement, risk-based decision making, and regular review, which is exactly what DORA is asking for. If all you have is a SOC2 report, building out an ISO27001 ISMS is the best starting point for DORA compliance you'll find.
Where the gaps are
Even with a mature ISMS, there are some areas where DORA asks for a lot more, and these are the ones I see organisations tripping over.
Incident reporting is the big one. ISO27001 asks you to manage incidents. DORA asks you to classify them against specific criteria - number of clients affected, duration, geographic spread, data losses, how critical the affected services are, and economic impact - and then report major incidents on a tight clock. The initial notification goes to your regulator within 4 hours of classifying the incident as major (and no later than 24 hours after you first become aware of it), followed by an intermediate report within 72 hours and a final report within a month, all using the regulator's templates. You also have to tell affected clients. Very few incident response processes I've reviewed were built for that.
Then there's the register of information. DORA requires a register of every contractual arrangement you have with ICT third-party providers, in a set format, which you have to submit to your regulator. It includes the subcontractors further down the supply chain. Most ISMS supplier lists I've seen are a spreadsheet with a vendor name and a renewal date, which is nowhere near enough.
Article 30 sets out mandatory clauses for ICT contracts, including service descriptions, where data is processed and stored, access and audit rights, termination rights, and cooperation with regulators, with extra requirements where the service supports a critical or important function. That means going back and renegotiating contracts. Good luck getting your hyperscaler to the table, but you need to try, and you need to keep a record that you did.
For critical or important functions you also need exit strategies that have been thought through and tested, and an assessment of concentration risk. If your entire business runs in a single region of a single cloud provider, that's now a risk you have to document and justify to a regulator.
Resilience testing goes well beyond anything ISO27001 asks for. DORA expects an annual testing programme for the systems supporting critical functions, covering vulnerability scanning, scenario-based testing, performance testing and penetration testing. Entities designated by their regulator also have to run threat-led penetration testing at least every three years, based on the TIBER-EU framework. This is proper red teaming with external testers and regulator involvement, and it takes months to plan.
DORA also thinks in terms of business functions. You need to map which systems, data and suppliers support each critical or important function. Most ISMS asset registers stop at the asset and never make that link back to the business.
Lastly, check your ISO27001 scope. Plenty of certificates cover a single data centre, office, or product line. DORA covers the whole entity.
There is some proportionality built in. Smaller and less complex organisations can use a simplified ICT risk management framework, and threat-led testing only applies to firms their regulator selects. Being small doesn't get you out of the basics, though.
Why regulation is needed
I'm not a fan for more regulation, and 'd love to say that none of this regulation was needed. But for decades the financial sector has treated security as a cost to be squeezed, outsourced critical services with no idea how to get them back, and kept disaster recovery plans that have never been tested. When was the last time you saw a company do a proper DR exercise? Do you even know where yours is documented?
Security is a solved problem. The tools and practices have been around for years, and they aren't complex or expensive. What has been missing is leadership investing in them, in large part because leaders haven't been the ones to suffer when a breach happens. DORA puts responsibility squarely with the board, which should make the CISO's job a lot easier.
So use it. Build on the ISMS you already have, close the gaps, and the next time a vendor offers you a DORA-compliance-in-a-box solution, you can show them the door with a clear conscience and the happy smile of a job well done.