DORA and NIS2 Boundaries

The distinction is straightforward in outline, even though practice can be tangled. NIS2 concerns organisational cybersecurity and risk-management obligations, while DORA concerns continuity of important services and digital operational resilience for financial entities. DORA applies from 17 January 2025. NIS2 and DORA therefore overlap in language, since both talk about risk management, incidents, and supply chains, but they differ in who they name, what they are ultimately protecting, and which authority supervises them. A firm that treats them as interchangeable will misdirect its reporting, its evidence, and its governance.

Consider an illustration, and only an illustration: a financial entity and a non-financial essential service provider may both run complex technology estates and both worry about cyber threats, yet the regime that names each of them, the service each regime cares about, and the supervisor each answers to can all differ. The boundary guide exists to keep those three questions separate.

Confusion arises for understandable reasons. Both regimes arrived in the same period of European digital regulation, both use the language of risk management, incident handling, and supply chain security, and both expect senior involvement and documented processes. A firm that hears the same words in two contexts can easily assume that one set of work satisfies both regimes, or that a report made under one regime automatically counts under the other. The confusion is deepened where a group contains both financial and non-financial entities, or where a provider serves both kinds of customer, because the same system or the same incident can then be relevant to two regimes at once, for different reasons.

NIS2 is a broad cybersecurity regime for essential and important entities across a range of sectors, and its centre of gravity is organisational cybersecurity and risk management. It asks entities to manage cyber risk, to protect networks and information systems, to handle incidents, and to manage supply chain security, in a way that fits their sector and their importance to society or the economy. Its scope logic is sectoral and importance based: an entity is in scope because of the sector it operates in and the importance of its services, not because it is a financial entity as such. Its supervision and reporting channels reflect that broad, cross-sector design, and they differ from the financial supervision channels under DORA.

DORA is a financial sector regime, and its centre of gravity is the continuity of important services through digital disruption. It asks financial entities to manage ICT risk, to report ICT-related incidents, to test digital operational resilience, to oversee ICT third-party providers, and to share threat information, all around the services customers and markets rely on. Its scope logic is financial: an entity is in scope because DORA names its category of financial entity, and its supervision follows financial authorisation and competent authorities. That financial focus gives DORA a service level precision that a broad cybersecurity regime cannot offer on its own, because it ties risk, testing, and provider oversight to named financial services.

Overlap is real, and it is most visible in three places: risk management, incident handling, and supply chain oversight. A cyber risk assessment, an incident playbook, and a provider due diligence process may all be relevant to both regimes, and a firm may reasonably use shared controls, shared monitoring, and shared evidence where the underlying work is genuinely the same. The discipline is to keep the regimes distinct at the level of duty and reporting, even where the underlying work is shared. A shared control should be mapped to each duty it serves, a shared incident record should be checked against each regime's classification and reporting channel, and a shared provider review should be read against each regime's expectations. Shared work is efficient; merged duties are a source of error.

Three questions, asked in order, usually clarify the position. First, which regime names this entity, in this activity, and for this service? Second, which authority supervises that duty, and through which reporting channel? Third, what is the regime protecting in this instance: organisational cybersecurity in a broad sense, or the continuity of a particular financial service? If the answers point to different regimes for different parts of the same incident or provider relationship, that split is itself the answer, and the firm should handle each part under its own regime rather than forcing a single label. Where doubt remains, the doubt should be recorded, with the reasoning and the question to be clarified, rather than resolved by assumption.