NIS2 · Sector deep-dive
NIS2 for Banking
Banking is an Annex I sector of high criticality: credit institutions as defined in EU banking law are listed alongside financial market infrastructure. Large credit institutions are therefore normally essential entities under NIS2. The complication that makes banking different from every other sector is DORA — Regulation (EU) 2022/2554 — which regulates the same subject matter in far greater detail and takes precedence where the two overlap.
How NIS2 and DORA fit together
NIS2 anticipates that other EU acts will regulate cybersecurity in specific sectors. Where such an act imposes requirements at least equivalent in effect to the NIS2 obligations, the sector-specific act applies instead — the lex specialis principle. DORA is the clearest example in the whole framework: it covers ICT risk management, incident classification and reporting, resilience testing including threat-led penetration testing, and oversight of critical ICT third-party providers.
For a credit institution this means the operative rulebook for ICT risk is DORA, supported by its regulatory and implementing technical standards, not the ten measures of Article 21. What NIS2 still contributes is the entity's presence in the national register, the member state's supervisory architecture, cooperation with the national CSIRT, and any national obligations added in transposition that DORA does not address.
The mistake we see most often is treating this as an either/or decision taken once. It is a mapping exercise: build to DORA's standard, then keep a cross-reference showing which DORA control satisfies which NIS2 article, so that a question from a national authority does not turn into a project.
Where banks typically have the biggest gaps
- The register of information is incomplete. DORA requires a structured register of all contractual arrangements for ICT services. Subcontractors, intra-group providers and shadow SaaS are routinely missing from it.
- Concentration risk is unmeasured. Several critical functions often depend on the same cloud region, the same core-banking vendor or the same payment processor without anyone having quantified the combined exposure.
- Incident classification is not operational. Staff can describe the thresholds but cannot apply them at 03:00. The classification decision needs a written test and a named decision-maker, not a policy paragraph.
- Board evidence is thin. Both regimes make the management body accountable and require training. Attendance lists and agendas are the evidence supervisors ask for, and they are frequently not retained.
What supervisors expect to see documented
- An ICT risk management framework with identified critical or important functions, tolerance for disruption, and a review cycle approved by the management body.
- A maintained register of information covering every ICT service contract, including subcontracting chains supporting critical functions.
- A tested resilience programme — scenario testing annually, and threat-led penetration testing for the institutions in scope for it, with findings tracked to closure.
The ten NIS2 measures remain the right baseline for any group entity that is not a financial entity under DORA — see the Article 21 requirements page — and management liability under Article 20 mirrors DORA's own governance duties closely enough that one training programme can satisfy both.
Documentation
Our DORA package is in preparation. In the meantime, the NIS2 Starter Kit's governance, risk and supplier templates map cleanly onto the equivalent DORA articles for group entities outside DORA's own scope.