Eighteen months into DORA enforcement, the shape of the work has changed. The first full cycle of Register of Information submissions has gone to national regulators through the EBA's EU-wide data collection, and supervisors have moved from checking that a register exists to benchmarking its data quality against peers. Incident reports run on tiered clocks. Resilience testing is an annual expectation. What was an implementation project in 2025 is a running operation in 2026 — and running operations want tooling.
The market has answered with everything from six-figure GRC platforms to purpose-built register tools to the spreadsheet an operations analyst maintains on Thursday afternoons. Comparing them feature-by-feature misses the point. A regulator never examines tooling; a regulator examines evidence. The useful ranking orders each category by the evidence it actually produces for the institution that deploys it.
What the tooling has to produce
DORA's operational demands compress into five artefacts that must exist, stay current, and surface on request:
- An ICT risk-management framework with documented ownership
- The Register of Information on third-party ICT arrangements, in the EBA's submission format, refreshed as arrangements change
- Incident reports filed on the tiered clock — initial notification, intermediate report, final report
- Resilience-testing evidence, annually, proportionate to the institution's profile
- Third-party risk assessments, including concentration analysis and awareness of which providers regulators class as critical
Every tool category below earns its place by which of these five it genuinely produces — and is limited by which it leaves untouched.
The landscape, ranked
- Enterprise GRC suites. ServiceNow, MetricStream and their peers, most now shipping DORA-specific content packs. For a large institution already running one, extending it is the coherent move: the register lives next to the CMDB, incidents flow from the same ITSM pipeline, and audit gets one system to trust. The costs are equally structural — implementation is measured in quarters, licensing in six figures, and the DORA packs still need configuring into the institution's own taxonomy. The suite produces all five artefacts eventually; "eventually" is the operative word.
- Specialist DORA register and reporting tools. A newer generation of purpose-built products that do one thing quickly: produce a submission-ready Register of Information and handle the reporting formats. For a mid-sized institution that mainly feels DORA as a reporting burden, this is the fastest route to a clean submission. The trade-offs are scope and irony in equal measure: the tool covers one or two of the five artefacts, and the small vendor supplying it becomes, itself, a line in your third-party register — a dependency your regulator may ask about.
- Third-party risk platforms. UpGuard, SecurityScorecard and the wider vendor-monitoring class. Continuous security ratings, fourth-party dependency mapping, questionnaire automation — genuinely useful for the assessment artefact, and the only category that watches vendors between reviews rather than at them. They monitor the risk; they do not produce the register, the incident reports, or the testing evidence. A complement, not a spine.
- AI-assisted compliance analysis. The newest category: language models applied to the documents the other tools merely store — reading vendor contracts against DORA's required provisions, checking register entries against the underlying agreements, surfacing the gaps a manual review misses at scale. Deployed on the institution's own infrastructure, the analysis happens without compliance data leaving the perimeter — which matters, given that the data in question is a map of the institution's dependencies. This is the category where Digiwit works, building purpose-built models for exactly this kind of regulated document work. The honest limits: the category is young, it augments rather than replaces the register tooling above, and its output is analysis a human owner still signs.
- Spreadsheets. The actual incumbent in much of the market, and dismissing it would be dishonest. For a small institution with a dozen material ICT arrangements, a disciplined spreadsheet plus the regulator's template can be entirely defensible. It breaks predictably at scale: version drift, no audit trail, manual reformatting for each EBA submission, and one person who understands the file. The institutions that outgrow it usually discover this during a submission week.
If your institution is somewhere between these categories — a register submitted but a nagging sense the underlying contracts and the register no longer agree — that gap analysis is a conversation we do often.
What no tool closes
Three gaps survive every procurement. Supervisory benchmarking measures data quality, and data quality is produced by process discipline — a tool amplifies whatever register hygiene the institution already has, including the absence of it. Ownership cannot be licensed: DORA expects named accountability for the framework, and that responsibility stays with individuals whatever the dashboard says. And the perimeter keeps moving — the AI systems institutions deployed in the past two years are themselves ICT dependencies with their own register entries and, since the omnibus, their own regulatory calendar.
Where this lands
The ranking above reads differently depending on where an institution stands. Already on a GRC suite: extend it, and consider category four for the document-depth work the suite skims. Mid-sized with a reporting burden: category two now, category three as the vendor estate grows. Small and disciplined: the spreadsheet holds until the day it doesn't, and that day is usually a submission deadline.
What holds across all of them: the tooling market sells confidence, and the regulator buys evidence. An institution that knows which of the five artefacts it produces weakly has already done the analysis that matters — the tool is just the delivery mechanism. Choose for the gap, not for the demo.
Related reading: