DORA compliance software: when to leave Excel and how to choose without a misleading RFP

DORA compliance software becomes necessary when the organisation can no longer produce, on time and without manual reconciliations, a coherent register of information, control evidence or a consolidated view of its ICT-related risks. The threshold does not depend on a universal number of entities: it is crossed as soon as concurrent versions, provider dependencies, incidents and audit requests make Excel untraceable or the advisory firm indispensable for every update. DORA does not mandate buying software; it mandates outcomes that the framework must be able to reproduce and justify.

Short answer: switch when evidence is no longer reproducible

The switching criterion is the inability to restitute complete, dated and attributable information quickly without manual rework. A simple test is to ask teams to produce, then reproduce a few days later, four deliverables on the same scope:

1. the RoI — register of information — at the individual, sub-consolidated or consolidated levels required by Article 28(3) of the DORA regulation;
2. the chain linking an entity, a function, the ICT service used, the contract, the ICT third-party service provider and its subcontractors;
3. the history of a decision or validation, with its author, date and the elements reviewed;
4. an export that can be used without rebuilding the file in parallel.

The decisive test: produce the same scope twice and get the same result

Gaps between the two productions reveal a weak audit trail: data changed without a log, consolidation rules applied manually, supporting documents kept in mailboxes, or arbitrations not linked to their source. A correct restitution obtained only because the person who “knows the file” intervened is not a reproducible process.

Why no universal threshold of entities or providers is defensible

A single-entity organisation can cross that threshold with several delegates, subcontracting chains and heterogeneous contracts. Conversely, a group may still control a spreadsheet if its scope is limited, identifiers are normalised and updates are controlled. The right threshold is therefore operational: number of manual reconciliations, change frequency, consolidation level required and ability to produce evidence without individual dependency.

Warning signals: Excel and the firm become a bottleneck

The spreadsheet stops scaling when compliance rests on human reconciliations between entities, functions, contracts, incidents and providers. The advisory firm reaches its limit when it becomes the operational holder of the data rather than its reviewer or adviser.

Multi-entity: duplicates prevent reliable consolidation

The most visible signals are different identifiers for the same provider, multiple versions of a contract, subcontractors entered under non-normalised names, or ICT services assigned different criticalities by entity. Consolidation then adds rows instead of reconstituting dependencies.

RoI: periodic updates mask obsolete operational data

The RoI becomes fragile when it is updated only before a filing or inspection, by collecting files and emails. Implementing Regulation (EU) 2024/2956 sets the standard templates applicable to the register, with machine-readable restitution in xBRL-CSV. A file that is technically exportable remains unusable if contracts, critical or important functions, providers and subcontractors are not linked and governed upstream. Recurring errors are detailed in our analysis of the DORA register of information.

Audits and inspections: lack of history turns every request into a project

The switch is justified when the organisation cannot isolate changes since the last audit, find the owner of a data point or demonstrate who approved an assessment. Other alerts: evidence re-collected for every campaign, a register rebuilt by the firm, and an export impossible without its working files. The firm then becomes an outsourced operator of the framework, with continuity and knowledge risk.

Selection grid: evaluate evidence and exports, not a feature list

Software must be assessed on scenarios run with data representative of the buyer. Each scenario must produce a verifiable deliverable, scored on accuracy, traceability and the volume of remaining rework.

RoI and supervisor export: test templates, identifiers and consolidations

The candidate must import a sample of contracts and produce the RoI according to the applicable regulatory templates. The test must cover identifiers, consistency checks, relationships between tables and the individual, sub-consolidated and consolidated levels. A “DORA export” announced on a product sheet is worthless if manual corrections remain necessary before submission.

Incidents: verify chronology, classification and versions

The scenario should start from a documented real or fictitious event and show its qualification, chronology, validations and retention of notified versions. You must be able to distinguish the information available at each stage, find the author of a change and link the elements that led to classifying — or not classifying — a major ICT-related incident. The expected logic is detailed in the incident classification decision tree.

TPRM: link criticality, concentration, subcontracting and exit

TPRM must not be an isolated supplier questionnaire. The test must link third-party assessment to the services provided, functions supported, contracts, subcontractors, concentration risk and exit strategies. A supplier view without dependencies by entity and by function cannot measure real exposure. See also the TPRM lifecycle under DORA.

Evidence: require source, owner, date, status and history

For each control, the platform must retain the source, owner, collection date, status, approver, comments and history. An attachment dropped in a library is not, on its own, control evidence: you must demonstrate what was verified, under which rule and with which conclusion.

Reversibility: recover data, relationships and logs

The final test is to extract data, attachments, relationships, reference data and logs in reusable formats. APIs, restitution timelines, costs, documentation and exit conditions must be contractualised. This grid must apply without exception to every vendor assessed, including Axenia.

What software does not replace: decision, accountability and negotiation

The platform structures data and retains evidence; it transfers neither regulatory responsibility nor arbitration.

Management and the business remain owners of arbitrations

Article 5 of DORA keeps the management body accountable for the ICT risk-management framework. The entity must decide which functions are critical or important, assess the materiality of an incident, accept or refuse residual risk and validate an exit strategy. A score calculated by the software can inform the decision, not take it.

The advisory firm brings interpretation, independent review and negotiation

The firm remains relevant to interpret a requirement, review the framework, challenge a classification, negotiate a contract or prepare an inspection. It should not be needed for every provider change or every export. The complementarity is clear: the firm advises and reviews; the entity governs; the platform operates the data and its traceability.

The platform retains, links and restitutes decisions taken

Article 28 states that using ICT services does not relieve the financial entity of its obligations. Article 30 notably requires a description of services, locations, data protection, access, recovery and return conditions, service levels, assistance in the event of an incident, cooperation with authorities, termination rights and participation in awareness actions. For services supporting critical or important functions, detailed performance objectives, audit rights, tested continuity arrangements, participation in tests, subcontracting controls and exit strategies are added. The detail is in our analysis of the mandatory contractual clauses under Article 30.

Selection mistakes: five shortcuts that make the RFP unusable

Confusing functional coverage with control evidence

Yes/no answers must be excluded for decisive requirements. Replace “RoI management: yes/no” with a demonstration that produces the register, its consistency checks and its change log.

Believing a tool can certify DORA compliance on its own

A vendor “DORA compliance” claim does not replace analysis of configuration, data, processes and responsibilities. No software can certify that the classifications, accepted risks or negotiated clauses of the entity are legally sufficient.

Evaluating a demo without representative data

A preloaded environment hides identification, deduplication and consolidation difficulties. The elimination test must use a sample provided by the buyer: anonymised real contracts, naming variants, subcontractors and incomplete history.

Underestimating data migration and governance

The RFP must specify who cleans data, reconciles providers, qualifies functions, validates migrations and maintains each object. Without update responsibilities, the new software will reproduce the spreadsheet’s defects in a more expensive interface.

Omitting reversibility and recreating a critical dependency

Absence of commitments on exports, logs, APIs, attachments, timelines and restitution costs creates a new dependency on an ICT provider. Reversibility must be tested before signature, then built into contractual terms and the exit strategy.