Financial sector

Financial institutions had risk management in place long before anyone talked about NIS2. DORA, however, redrew it around the part that had until then been scattered across contracts — the providers of information and communication technology (ICT) services. The question is no longer only whether you can restore operations, but whether you know whom you depend on to do so and what happens if they fail.

Which regimes usually concern you

It is usually a combination of three things. Which of them carries the weight depends on the type of entity and on the authorisation under which you operate.

• DORA. Regulation (EU) 2022/2554 is directly applicable, without transposition. It applies to the financial entities listed in its Article 2, and within that circle the extent of the obligations varies with size and overall risk profile (Article 4) — not every obligation falls on everyone in the same way.

• Cybersecurity (NIS2). For financial entities that are essential or important entities under the national rules transposing Directive (EU) 2022/2555, DORA is the sector-specific Union act within the meaning of Article 4 of that Directive (Article 1(2) of DORA). In the areas it covers, its requirements apply in place of the corresponding NIS2 provisions. That does not make NIS2 irrelevant: Article 4(1) of the Directive sets aside only the relevant provisions, and whether the national rules still reach part of your activity depends on what you provide.

• GDPR. Financial data are sensitive in the everyday sense of the word, even though they are not a special category under the Regulation. The focus is usually on the scope of access rights, profiling when assessing clients and the chain of processors — the same contracts that DORA requires, seen from the other side.

The register of information is the most visible obligation

The register of information on all contractual arrangements for ICT services provided by ICT third-party service providers (Article 28(3) of DORA) is maintained and updated on an ongoing basis. It is usually the first place where it turns out that the list of suppliers in accounting and the list of suppliers in IT are not the same set — and that you know least about your suppliers’ own subcontractors.

Yet the register is only a record. What matters is what it shows: which functions are critical, where concentration risk arises, what the contracts say about audit rights and termination, and whether there is a workable exit strategy. These are the questions that come up in supervisory findings.

Where our boundary lies: the register belongs to the entity, which provides it to the supervisor and is responsible for it. Compliance with DORA is ensured by the competent authorities designated under its Article 46, and it is they who assess whether you have met the obligation. 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.

What we do for the financial sector

We build or clean up the register of information and review the contracts with ICT third-party service providers against what they need to contain. We carry out a risk analysis that includes concentration risk and exit strategies, prepare the documentation for ICT third-party risk management and set up incident reporting so that it meets the deadlines. We do not carry out penetration tests ourselves, threat-led or otherwise. If threat-led penetration testing under Article 26 of DORA concerns you, we will say so — it is carried out by testers who meet the requirements of Article 27, and in that case we can recommend one.