The DORA Software That Drives Your Operational Resilience

DORA applies to financial entities across the Union in a broad sense: credit institutions, investment firms, payment and electronic money institutions, insurers, reinsurers and insurance intermediaries, fund managers, crypto-asset service providers, market infrastructures and credit rating agencies. ICT third-party providers are caught in two ways: through the contractual requirements placed on their financial clients, and, for those the European Supervisory Authorities designate as critical, through direct oversight at EU level. A simplified ICT risk management framework remains open to certain smaller entities.

No. DORA is an EU regulation, not a certification scheme: no body issues a DORA certificate and no organisation can call itself DORA certified. Compliance is demonstrated to the competent authority that supervises you, which in France means the ACPR for banks and insurers and the AMF for asset management and market participants. What it looks at is your documentation: the ICT risk management framework, the register of information, incident reports and test results.

NIS2 is a directive transposed by each member state and spans many sectors; DORA is a directly applicable regulation aimed at the financial sector alone. Where the two could overlap, DORA takes precedence as the sector-specific text: a financial entity within its scope applies DORA for its cyber risk management measures and its incident reporting. The two texts share enough logic for a good share of the controls to serve both.

It is a function whose disruption would materially impair the financial performance of the entity, the soundness or continuity of its services and activities, or its ability to keep meeting the conditions of its authorisation and its other regulatory obligations. The label is not cosmetic: it triggers stricter requirements on the contractual terms agreed with the ICT provider concerned, on testing, and on what the register of information has to record. It is one of the first decisions to document, and to revisit whenever the scope moves.

DORA asks for a testing programme proportionate to risk, including at least yearly tests of the systems supporting critical or important functions: vulnerability assessments, continuity tests, security analyses. On top of that, entities designated by their competent authority on the basis of their risk profile and their impact on the financial sector must run threat-led penetration testing (TLPT) at least every three years, aligned with the TIBER-EU framework.

The regulation sets a baseline for every ICT service arrangement: a full description of the services, the locations where they are delivered and where data is processed or stored, data protection and data return, service levels, assistance in the event of an incident, cooperation with the authorities, and termination conditions with notice periods. Where the provider supports a critical or important function the bar rises: precise performance targets, unrestricted access, inspection and audit rights, participation in testing, and documented, tested exit strategies. That means reworking the stock of existing contracts, not only the new ones.

The register follows a format set at European level: several tables linked by identifiers, where a contractual arrangement points to the signing entity, to the provider, to its subcontractors and to the functions it supports. In a spreadsheet those links come apart on the first update, and one inconsistent reference is enough to fail the data quality checks when the file is submitted. A dedicated tool holds the relationships, verifies consistency before submission, and saves rebuilding the register for every collection round.