Required by regulation
Digital operational resilience (DORA)
For financial entities and for their ICT service providers: the register of information, DORA clauses in supplier contracts and the resilience testing programme.
DORA — Regulation (EU) 2022/2554 — places obligations on financial entities. Where it applies, they pass part of them on by contract to their providers of information and communication technology (ICT) services, so the subject also concerns companies that are not supervised themselves.
Which of the two groups you belong to determines what you need from us — and that is the first thing we clarify.
Who it is for
Financial entities. The regulation applies to the types of financial entity listed in its Article 2 — among them credit institutions, payment and electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, managers of alternative investment funds and management companies. Within that circle the obligations are applied in proportion to size and overall risk profile (Article 4).
ICT service providers to the financial sector. Software companies, cloud and hosting providers, data centres, external IT, payment processors. Unless you are designated as a critical ICT third-party service provider (Article 31), the regulation reaches you through your customer: the contract has to contain specific provisions (Article 30). This group is usually larger and often has no compliance function; the clauses arrive without explanation, and refusing them means losing the client.
The register of information is the most concrete obligation
Financial entities maintain and update a register of information on all contractual arrangements for ICT services provided by ICT third-party service providers, distinguishing those that support critical or important functions (Article 28(3)). Competent authorities can request the full register.
The submission date is misleading. The register is compiled as at a reference date that comes before the date it is submitted — anyone who starts working to the submission deadline finds that missing supplier data can no longer be filled in retrospectively.
Where it fails most often: the register does not pass validation. The usual reasons are missing supplier identifiers, a mismatch between the contract and the service actually used, or a function that nobody has linked to a specific system.
Five areas a financial entity has to cover
ICT risk management. Financial entities must have a sound, comprehensive and well-documented ICT risk management framework as part of their overall risk management system (Article 6(1)). As part of that framework they have to identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk (Article 8(1)). The framework has to be reviewed at least once a year (Article 6(5)); microenterprises review it periodically. The ultimate responsibility for managing ICT risk lies with the management body (Article 5(2)), not with IT.
ICT-related incidents. Incidents are classified by their impact (Article 18), and major ICT-related incidents are reported to the competent authority (Article 19).
Digital operational resilience testing. A testing programme for financial entities other than microenterprises (Article 24); entities identified by the competent authority also carry out threat-led penetration testing (Article 26).
ICT third-party risk. Contractual provisions (Article 30), the register of information (Article 28(3)), exit strategies for services supporting critical or important functions (Article 28(8)) and the assessment of ICT concentration risk (Article 29).
Information sharing. Voluntary exchange of cyber threat information and intelligence among financial entities (Article 45).
DORA clauses have arrived in your contract
Part of the requirements follows directly from the regulation (Article 30), and your customer cannot drop it. Part is the customer’s own addition — and that can be negotiated, if you know which is which.
We review the addendum, separate what is mandatory from the addition, prepare material for the negotiation and fill in what you actually lack to meet the commitments.
Do not sign blindly. The clauses contain commitments with operational consequences — for example service restoration times or an obligation to allow an audit at your premises. Signing them and then not meeting them is worse than negotiating them. And if you can meet them, that is an argument that holds up against competitors.
From a testing programme to threat-led testing
The testing programme. Article 25 lists the kinds of tests it can include — from vulnerability assessments and scans to scenario-based tests and penetration testing. Scope and frequency follow the risk profile. It is not a one-off penetration test; it is a programme with a plan, outputs and follow-up of remediation. We draw up the programme and follow the remediation; the tests themselves are carried out by testing providers.
Threat-led penetration testing (TLPT). Testing on live production systems that support critical or important functions (Article 26(2)). Whether it applies to you is decided by the competent authority, which identifies the financial entities required to perform it (Article 26(8)) — not by you.
Where our role ends
We do not carry out penetration tests ourselves, threat-led or otherwise. We prepare the organisation, coordinate the process and go through the results with you; the test is carried out by testers who meet the requirements of Article 27, and we can recommend one. It is the same boundary as with audits: whoever prepared the environment should not be the one who tests it.
The register belongs to the financial entity, which maintains it and is responsible for it. Compliance with DORA is ensured by the competent authorities designated under Article 46, and it is they who assess whether the obligations have been met. A confirmation of compliance with DORA does not exist as a document issued by an adviser — we can build the register, keep it up to date and defend its content, not approve it.
Where to read more
How DORA sits alongside NIS2 and data protection in a financial institution: Financial sector.
For groups that deal with NIS2 transpositions in several countries alongside DORA: NIS2 audit by country.
ICT risk management under Articles 6 and 8 rests on a risk register — what that involves: Risk analysis.
Legal position verified as of 10 October 2026.
How we help
Packages, scope and indicative price
Register of information
The register of contractual arrangements on the use of ICT services, built in the required structure — including tracing missing data with suppliers and checking that it passes validation.
Gap assessment
Your current state compared with the requirements of the regulation, and a prioritised list of gaps — what needs resolving first and what can wait.
Contract clauses for suppliers
Review of the contract addendum from your financial customer: what is mandatory separated from the customer’s own addition, with material for the negotiation.
Resilience testing programme
A test plan based on the risk profile, with outputs and follow-up of remediation. The tests themselves are carried out by testing providers, not by us.
What determines the price
The price is determined by scope, not by the size of the company. Effort is driven mainly by an additional site, an additional information system in scope, a supplier that has to be assessed, and a second jurisdiction. Each such extension adds roughly a third to a half to the effort. We agree the scope at the initial assessment and the quotation states the number of days as well.
Tell us which side of DORA you are on
Whether you are a financial entity or a supplier that has received DORA clauses — send us what you have, and we will tell you what the work involves.