Stop shopping for DORA compliance software

If you run risk or compliance at a bank, insurer, or investment firm, your inbox has a new theme this year. Every ICT vendor, every GRC platform, every consultancy is selling you DORA compliance software. The pitch is always the same: the Digital Operational Resilience Act is in force, the deadline has passed and you need a tool for it.

You do not need a tool for it. You need to govern operational resilience. If you already do that well, you have most of DORA already. Here is why the software-shopping instinct is the wrong one and what to look at instead before you sign anything.

DORA did not create a new problem

The Digital Operational Resilience Act has applied to EU financial entities since 17 January 2025. It is a real regulation with real teeth. It is not vague either: it sets out requirements across ICT risk management, incident reporting, resilience testing, ICT third-party risk and information sharing. Twenty types of financial entity are in scope, from credit institutions to crypto-asset service providers, along with the ICT providers they depend on.¹

Read the requirements and notice what is missing: anything new. ICT risk management is risk management. Incident reporting is incident reporting. Third-party oversight is vendor risk you were supposed to be doing. What DORA did was take practices that mature financial institutions already ran and make them legally enforceable across the whole bloc. The novelty is the enforcement, not the substance.

This matters because it changes the question. "Which DORA product should we buy" assumes DORA is a discrete thing you bolt on. It is not. It is a legal floor under disciplines you either run or you do not. A firm with a working operational resilience framework, a live register of its ICT dependencies and an incident process that already meets tight reporting clocks is most of the way there. A firm buying a DORA tool in 2026 is usually a firm admitting it was not running those disciplines, hoping software will paper over the gap.

Software does not paper over a governance gap. It makes the gap auditable.

The register of information is a symptom, not the disease

The single most-searched panic in DORA is the register of information: the structured inventory of every contractual arrangement for ICT services, with a prescribed schema that supervisors can collect. It is fiddly. It has specific fields, entity identifiers and a format regulators expect to receive. Vendors have built entire products around producing it in a submission-ready form. Firms are paying for them.

Step back and ask why the register is hard. It is hard because most firms do not know their ICT third-party estate. They have contracts scattered across procurement, security and business units. They do not know which providers support critical or important functions. They cannot say, on demand, which fourth parties sit behind their third-party dependencies. The register is difficult to produce because the underlying ICT third-party risk was never being managed as a live inventory in the first place.

A product that generates the register from a spreadsheet you fill in once solves the artifact and ignores the disease. Next year the estate has drifted, the contracts have changed, a provider has been acquired and you are filling in the spreadsheet again. The register of information is not a document to produce. It is the output of knowing your ICT dependencies week after week. If you manage that estate properly, the register is a report you run. If you do not, no tool saves you, because the tool is only ever as current as the last time someone updated it by hand.

What good ICT risk management looks like

Here is the uncomfortable part for anyone hoping to buy their way out. Every DORA pillar resolves to a practice that never stops, not a deliverable you hand in once.

ICT risk management is not a policy document. It is a live control environment with owners, evidence and review cycles. Incident reporting is not a template. It is an incident process wired tightly enough to classify a major incident and notify a supervisor inside the reporting window, which for the initial notification is measured in hours, not days. Resilience testing is not an annual pen test. For entities their supervisor designates it includes threat-led penetration testing on a multi-year cycle. For everyone it means a testing programme that feeds findings back into controls. ICT third-party risk is not a signed contract. It is ongoing oversight of concentration, exit strategies and the specific providers behind critical functions.

An operational resilience framework worth the name ties these together. It maps the important business services, identifies the ICT and third-party dependencies underneath each one, then sets impact tolerances. Evidence proves the firm can stay inside those tolerances when something breaks. That is the discipline DORA is testing for. A checklist that gets ticked in December and forgotten in January is not that discipline. It is theatre with an [audit trail](/lexicon/ai-model-audit-trail).

The firms that will pass a DORA supervisory review comfortably are not the ones with the best DORA software. They are the ones for whom DORA is a reporting layer over governance they were already doing.

The UK already ran this play

None of this is speculative, because a very similar experiment already happened next door. The FCA and PRA operational resilience rules required UK financial firms to identify important business services, set impact tolerances, then map the dependencies underneath. Firms were expected to remain within tolerances by a 31 March 2025 deadline. The logic matches DORA's almost line for line; the regulatory accent is the only difference.

The firms that treated the UK regime as a one-off mapping exercise, filed away once done, ended up redoing it. The firms that treated it as an operating model, where dependency mapping and testing never pause, absorbed DORA with far less drama, because the hard work was already institutional. The lesson transfers directly. Regulators across jurisdictions are converging on the same expectation: prove, on a live basis, that you can withstand and recover from disruption. They are not converging on the expectation that you own a particular piece of software.

If you are evaluating your DORA posture, the most useful comparison is not to other DORA tools. It is to how your firm handled FCA and PRA operational resilience. The gaps rhyme.

The tell: are you buying a tool or building a discipline

There is a simple diagnostic for whether you are about to spend money well. Ask what the product does between audits.

A DORA tool that helps you produce a register, generate a policy pack and export an evidence bundle for the assessor is optimising for the moment of inspection. It makes the audit smoother. It does nothing for the other fifty-one weeks of the year, while the estate keeps changing. A tool like that treats compliance as an event, so it sits idle between events while the governance quietly rots underneath the clean report.

The alternative is to treat DORA as one more framework sitting on top of an ICT risk and third-party governance capability that runs all year. In that model the requirements map to controls that carry owners and evidence. The ICT third-party estate is a maintained inventory rather than an annual reconstruction, with the register of information as a view over that inventory rather than a document you rebuild. The next regulation will land eventually; when it does, you map it onto the same control environment instead of buying another point tool.

That is the difference between buying DORA compliance software and building operational resilience. The discipline outlives the next regulation; the tool purchase sets up your next procurement cycle.

Where a platform helps and where it does not

To be fair to the category, tooling is not the enemy. The mistake is buying a tool scoped to a single regulation. A governance platform earns its place when it does the opposite: it holds one control environment that many frameworks map onto, keeps a live inventory of vendors and ICT dependencies, then attaches evidence to controls so the audit trail is a by-product of the work rather than a year-end fire drill.

This is the model VerifyWise is built on. It manages frameworks as requirements mapped to controls with evidence and assessments. It maintains a vendor and third-party register as living data. It already governs financial-services model risk under regimes like SR 11-7 (now SR 26-2), SS1/23 and OSFI E-23. The ICT third-party estate that DORA cares about is the same estate a vendor risk module tracks. The rolling evidence that an operational resilience framework needs is exactly what a control environment produces.

To be clear about scope: DORA is a regulation VerifyWise's architecture is designed to govern, not a pre-built checklist you switch on. Any vendor who tells you their software makes you DORA-compliant by default is selling you an audit-day product in a nicer box.

The honest version of the pitch is smaller and more useful than the market's. No software makes you resilient. Software makes resilience measurable, repeatable and auditable, once you are doing the governance. If you are not doing the governance, start there, not in a procurement portal.

If you want to see what running this as a year-round practice looks like rather than shopping for a single-regulation tool, talk to us.

Before you buy, ask this

DORA is not the last operational resilience regulation you will face. It is one of a converging set. The ones after it will ask the same core question in slightly different words: can you prove, on any given day, that you understand your ICT dependencies and can keep critical services inside their tolerances when things fail.

So before you shop for DORA compliance software, ask whether the problem is that you lack a tool, or that you lack the discipline the tool is supposed to report on. If it is the discipline, a point product will not fix it; the register of information will be just as painful next year. If it is the reporting layer, buy a platform that governs the discipline all year and treats DORA as one framework among many, not a single-regulation tool you will replace the moment the next acronym arrives.

The firms that stop shopping and start governing are the ones for whom the next regulation is a mapping exercise instead of a fire drill.

Footnotes

1. Article 2 of the regulation lists 21 lettered categories. The twenty-first is ICT third-party service providers, which are not financial entities, so the count of financial-entity types is twenty. Some public summaries cite twenty-one by counting all the lettered points together. ↩