DORA and NIS2: what applies to a bank and what it asks of its systems

Which law governs what

The NIS2 Directive (EU) 2022/2555 lists banking among its sectors. Article 4 of NIS2 says that where a sector-specific Union act sets cybersecurity and incident reporting rules at least equivalent to its own, that act applies instead. Article 1(2) of DORA, Regulation (EU) 2022/2554, declares itself exactly that act for financial entities. For a bank, ICT risk management, incident reporting, testing and third-party risk are DORA matters.

NIS2 still touches the bank in three places.

• National law. NIS2 is a directive, so each member state writes its own act and names its own authorities, CSIRTs and single points of contact. Those laws decide how banks are listed and how DORA supervisors and NIS2 authorities work together.
• Cooperation and double reporting. Under DORA Article 47, financial supervisors may join the NIS2 Cooperation Group and share information with NIS2 authorities. Under Article 19(1), a member state may require banks to send their incident reports to the NIS2 authorities or CSIRTs as well.
• Group entities that are not financial entities. A bank group's IT services company, data centre or other non-financial subsidiary is not covered by DORA as a financial entity. It may fall under the national NIS2 law in its own right, while the bank treats it as an intra-group ICT provider under DORA.

What DORA requires

DORA puts ICT risk on the management body's desk. Article 5 gives it ultimate responsibility for the bank's ICT risk and the digital operational resilience strategy. Beneath that sit five sets of obligations.

• An ICT risk management framework. Article 6 requires a sound, documented framework, reviewed at least once a year, covering identification, protection, detection, response, recovery and backup. Article 9 adds documented change management for software, hardware, firmware and security parameters.
• Incident classification and reporting. Article 18 sets the criteria: clients affected, duration, geographical spread, data losses, criticality of services and economic impact. Major incidents are reported under Article 19 in three stages: an initial notification, an intermediate report and a final report.
• Resilience testing. Article 24 requires appropriate tests at least yearly on all systems supporting critical or important functions. Banks identified by their supervisor must also run threat-led penetration testing (TLPT) at least every three years under Article 26.
• ICT third-party risk and the register of information. Article 28 requires a third-party risk strategy, exit strategies for critical services and a register of every contractual arrangement with ICT providers, reported to the supervisor. Article 30 sets the clauses those contracts must contain. Article 29 asks the bank to weigh concentration risk before it signs.
• Oversight of critical providers. Under Article 31, the European Supervisory Authorities designate critical ICT third-party providers and oversee them directly. Under Article 28(1), the bank stays fully responsible for its obligations whoever runs the service.

The dates

The rules are still moving. On 19 November 2025 the Commission proposed, in its digital omnibus package, a single entry point for incident reports under NIS2, GDPR and DORA. On 20 January 2026 it proposed targeted amendments to NIS2. Both are proposals, and neither changes what a bank must do today. In July 2026 the Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose NIS2.

Where banks get stuck

Policies are the easy part. The friction sits in the evidence and the systems behind them.

The register of information

The register asks for every ICT arrangement, the functions it supports and the subcontractors behind it, in a fixed format. The data lives in procurement files, contract folders and people's heads. Older contracts often lack the Article 30 clauses on audit rights, exit and support during incidents, and renegotiating them takes longer than filling a template.

Four hours from classification

The delegated rules in Regulation (EU) 2025/301 set the clock: the initial notification within four hours of classifying an incident as major and no later than 24 hours after becoming aware of it, the intermediate report within 72 hours of the initial one, and the final report within a month. That only works if monitoring, classification and approval run as one process, at night and at weekends.

Testing that touches production

Yearly testing of critical systems and TLPT on live systems need test environments that mirror production, clean test data and providers who agree to take part. Where the contract does not oblige the provider to join, the test stalls.

A few cloud providers behind everything

Core, channels, email, security tooling and analytics often lead back to the same few hyperscalers, directly or through subcontractors. Article 29 asks the bank to see that concentration before it signs, and the exit strategy has to work in practice.

Change control

DORA expects every change to be recorded, tested, approved and reversible. Large, infrequent releases and emergency fixes applied straight to production are where audit findings cluster.

What it takes inside the platform

DORA compliance shows up in how systems are built and run, not only in the policy library.

• Separate environments. Production, test and analysis kept apart, so testing and investigation never put live service at risk.
• Controlled releases. Changes reach production in small, tested steps, each approved and traceable.
• A complete audit trail. Every action records who acted, under which rule and with which authority, so an incident can be reconstructed quickly.
• Access down to the record. Role-based access and four-eyes verification where the bank requires it.
• Deployment the bank controls. A platform the bank can run on its own infrastructure, its own cloud or a dedicated environment, which makes exit planning and concentration assessment concrete.
• Figures that trace back. Supervisory reporting where every number leads to the record behind it.

Where ABC Tech fits

The ABC Tech core is built for the continuity requirements of a supervised bank, including DORA. It runs in separate production, test and analysis environments, releases reach production in small, tested steps, and every action carries an audit trail and a verification diary showing who acted, the rule and the authority. Role-based access reaches down to the record, with four-eyes verification where the bank requires it. The bank chooses where the platform runs: its own infrastructure, its own cloud or a dedicated environment. The ABC Tech Reporting Platform runs apart from the core, and every figure in it traces to the record behind it.