When DORA lands on a desk, it is usually handed to the IT or security team with the words "this one's for you." That instinct is understandable — the Digital Operational Resilience Act is full of ICT language. It is also the single biggest reason organisations get DORA wrong. DORA is not really about technology. It is about whether the business can keep delivering its critical functions when technology fails — and that is a question only leadership can own.
Having sat on both sides — building security inside banks and advising boards — I can tell you the regulators are not asking "is your IT secure?" They are asking "if your most important service goes down, how badly are your customers, the market and the system harmed, and how quickly can you recover?" That is a business resilience question wearing a technical costume.
What DORA actually demands
DORA rests on five pillars, and only one of them is purely technical:
- ICT risk management — a governance framework, owned and overseen by the management body, not delegated away.
- ICT incident management and reporting — classifying major incidents and notifying authorities within defined timelines.
- Digital operational resilience testing — from basic testing to threat-led penetration testing (TLPT) for significant entities.
- ICT third-party risk — a register of arrangements, due diligence, contractual rights, concentration analysis and exit strategies for critical providers.
- Information sharing — voluntary exchange of cyber-threat intelligence among financial entities.
Read that list again as a CEO, not a CIO. Every pillar lands on the business: accountability, customer harm, supplier dependence, market trust. The technology is the means; resilience of the business is the end.
DORA's real test is not "did you document it?" but "can you still serve customers when your critical provider goes dark?"
Why it is a board issue, by design
DORA deliberately puts the management body on the hook. The board must approve the ICT risk framework, understand the firm's exposure, allocate budget, and stay informed — and members can be held accountable. This is not a formality. It mirrors what happened with financial risk after 2008: resilience is now a governance duty, not an operational afterthought.
There are three reasons it cannot live in IT alone:
- Only the business can rank what matters. Deciding which services are "critical or important" — and how much downtime is tolerable — is a commercial and customer judgement, not a server inventory.
- Concentration risk is a strategic exposure. If three of your critical functions all depend on one cloud provider, that is a board-level bet on a single point of failure.
- Recovery is a whole-organisation effort. Communications, legal, operations and customer service all act in an incident. None of them report to IT.
The shift in the question
The most useful thing a leadership team can do is change the question it asks. Move from "Is our IT secure?" to "Which business services must never stop, what do they depend on, and can we prove we'd survive a severe-but-plausible disruption?" Once that question is owned at the top, the technical work has direction and the spending has meaning.
Practical tips: running DORA as a business capability
- Start with critical business services, not systems. Map your important functions, then trace the people, processes and ICT they depend on. This "service view" is the spine of everything DORA asks.
- Put it on the board agenda — with a real owner. Name an accountable executive, brief the board in plain language, and record approval of the ICT risk framework. Train directors so oversight is genuine, not a signature.
- Build the ICT third-party register early. It takes longer than anyone expects. Capture every arrangement, flag the critical ones, and assess concentration — where many services lean on one provider.
- Fix your contracts and exit strategies. Critical-provider contracts need audit rights, incident cooperation, sub-outsourcing transparency and a workable exit plan. "We could never leave them" is a finding, not a strategy.
- Set impact-based incident classification. Decide in advance what makes an incident "major" in business terms (customers affected, downtime, data, reputation), so reporting clocks start correctly under pressure.
- Test severe-but-plausible scenarios, together. Run exercises that include business, legal and communications — not just technical recovery. For significant entities, plan threat-led penetration testing (TLPT) as a distinct, scheduled programme.
- Reuse your ISO 27001 backbone. Most ICT-risk and incident requirements already live in a working ISMS — map DORA onto it rather than building a parallel programme.
- Report resilience to the board like a KPI. Tolerances, test results, top supplier dependencies and open actions — a single quarterly view the board can actually act on.
The pitfalls to avoid
The classic failure is "compliance theatre": polished policies, an untested recovery plan, and a third-party register that nobody maintains. The second is treating resilience testing as a box-tick rather than a genuine attempt to break things and learn. The third — and most dangerous — is leaving the whole effort inside IT, so the board is surprised on the worst possible day. DORA was written precisely to prevent that surprise.
Digital operational resilience is, at heart, a promise to your customers and the market that you can keep going when things go wrong. That promise is made by the business and kept by the whole organisation. Technology is how you deliver it — but it was never "just an IT issue."
Preparing for DORA?
We help financial entities and their providers turn DORA from an IT project into a board-owned resilience capability — practical, testable, proven.
Book a 20-minute discovery callThis article is general information from circl3.tech, not legal advice. DORA obligations depend on your classification, size and role in the financial ecosystem — we recommend a scoped assessment for your organisation.