NIS2 vs GDPR: the differences, where they overlap, and how to handle one incident under both

NIS2 and GDPR protect different things. GDPR protects personal data and the people it describes; NIS2 protects the network and information systems behind essential and important services. Hospitals, ministries and cloud providers usually fall under both. One ransomware attack can then mean a NIS2 early warning within 24 hours and a GDPR notification within 72 hours, to two different authorities.

This guide covers the differences, who falls under which law, security duties, notification, fines, a worked example, a joint playbook and a checklist.

	GDPR, Regulation (EU) 2016/679	NIS2, Directive (EU) 2022/2555
Protects	Personal data and the rights of people	Network and information systems and the services they run
Legal form	Regulation, applies directly	Directive, applies through national law, which can add detail
Who is in scope	Controllers and processors of personal data (Arts 2, 3)	Annex I and II entities of medium size or larger, some regardless of size (Art. 2)
Security duty	Art. 32: security appropriate to the risk to people	Art. 21: measures appropriate to the risk to systems, ten minimum measures
What is reported	Personal data breach (Art. 4(12))	Significant incident (Art. 23(3))
Deadline	Without undue delay, where feasible within 72 hours (Art. 33)	Early warning 24 hours, notification 72 hours, final report one month later (Art. 23(4))
Who else is told	Data subjects, if high risk (Art. 34)	Recipients of services, where appropriate (Art. 23(1))
Authority	Data protection supervisory authority	CSIRT or NIS2 competent authority
Maximum fines	€10M or 2%, or €20M or 4% (Art. 83)	At least €10M or 2% essential, €7M or 1.4% important (Art. 34)

What is the difference between NIS2 and GDPR?

The main difference is whose risk counts. GDPR Article 32 sets security appropriate to the risk “for the rights and freedoms of natural persons”. NIS2 Article 21 requires measures against the risks to the systems an entity uses “for their operations or for the provision of their services”. A GDPR assessment asks what happens to people if their data is lost or exposed. A NIS2 assessment asks what happens to the service, and everyone who depends on it, if the systems fail. An outage with no personal data in it matters to NIS2, not GDPR.

NIS2 applies “without prejudice to” GDPR (Art. 2(12)): it softens no GDPR duty. Personal data processed under NIS2 is processed in accordance with GDPR (Art. 2(14)).

A note on numbers, because they get mixed up: GDPR Article 21 is the right to object. The GDPR security article is Article 32. In NIS2 it is Article 21.

Who falls under NIS2, GDPR or both?

GDPR applies to controllers and processors established in the EU, and to those outside it that offer goods or services to people in the EU or monitor their behaviour there (Art. 3). Almost every organisation is in, if only for its staff records.

NIS2 applies to entities of a type in Annex I or II that are medium-sized or larger under the EU SME definition (Art. 2(1)). Some are in regardless of size, such as trust service providers and central government (Art. 2(2)). The NIS2 scope checker gives a first answer.

Do public administration and healthcare fall under both?

Usually, yes. Both process personal data, and both are Annex I sectors under NIS2.

• Public administration. GDPR applies, and a public authority must designate a data protection officer (Art. 37(1)(a)). NIS2 covers central government regardless of size and regional government after a risk-based assessment (Art. 2(2)(f)). Member States may add local government (Art. 2(5)); national security, public security, defence and law enforcement are excluded (Art. 2(7)). Under both laws, each Member State decides whether public bodies can be fined (GDPR Art. 83(7), NIS2 Art. 34(7)).
• Healthcare. Health data is a special category (GDPR Art. 9), and processing it on a large scale as a core activity requires a data protection officer (Art. 37(1)(c)). Healthcare providers are an Annex I entity type, so a hospital of medium size or larger is in NIS2 scope, and a large one is an essential entity (Art. 3(1)(a)). Sector detail is in NIS2 for hospitals and pharma.

What about cloud providers?

Cloud computing service providers are an Annex I entity type under NIS2 in their own right, and usually processors under GDPR. GDPR Article 28 requires the processor to take the Article 32 measures, assist with Articles 32 to 36, allow audits, and use sub-processors only with prior specific or general written authorisation. NIS2 Article 21(2)(d) and (3) require an in-scope customer to manage security with its direct suppliers. In practice, one security annex covers both.

How do GDPR Article 32 and NIS2 Article 21 compare?

GDPR Article 32 names four measures “as appropriate”: pseudonymisation and encryption; confidentiality, integrity, availability and resilience; timely restoration after an incident; and regular testing. NIS2 Article 21(2) lists ten minimum measures, from risk analysis to multi-factor authentication where appropriate. Most controls serve both.

Two things differ. Coverage: NIS2 reaches every system used to run the service, including building management or medical device networks with no personal data. GDPR follows personal data wherever it goes, including paper files kept in a filing system (Art. 2(1)). Governance: under NIS2 the management body approves and oversees the measures, can be held liable for infringements of Article 21 and must follow training (Art. 20); GDPR makes the controller accountable (Art. 5(2)).

How does breach notification differ under GDPR and NIS2?

GDPR reports a personal data breach: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data (Art. 4(12)). The controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people. Late notifications must give reasons (Art. 33(1)); information can follow in phases (Art. 33(4)). Every breach is recorded internally (Art. 33(5)). If the risk is high, the people affected are told without undue delay (Art. 34), unless, for example, encryption made the data unintelligible (Art. 34(3)(a)).

NIS2 reports a significant incident: one that causes or can cause severe operational disruption or financial loss for the entity, or considerable damage to others (Art. 23(3)). The entity sends its CSIRT or competent authority an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month of the notification (Art. 23(4)). Details: the NIS2 incident reporting timeline and the significant incident threshold.

The thresholds run in opposite directions. GDPR reports by default and exempts only breaches unlikely to create a risk; “high risk” decides only whether individuals are told. NIS2 reports only what crosses the significance threshold.

Incident	NIS2 significant?	GDPR breach?	Reports
Ransomware encrypts a hospital’s patient records and stops admissions	Yes	Yes	Both
A patient’s letter goes to the wrong patient	Almost never	Yes	GDPR, unless no risk is likely
An attack halts a water utility’s treatment plant, no personal data touched	Yes	No	NIS2 only

Can you be fined under both NIS2 and GDPR?

Not for the same conduct. Under GDPR, infringing Articles 25 to 39, which include security (Art. 32) and notification (Arts 33 and 34), can cost up to €10 million or 2% of worldwide annual turnover, whichever is higher (Art. 83(4)). Infringing the Article 5 principles, which include “integrity and confidentiality”, can reach €20 million or 4% (Art. 83(5)), so a serious security failure can land in the upper tier.

For infringing NIS2 Article 21 or 23, national law must allow maximum fines of at least €10 million or 2% for essential entities, whichever is higher. For important entities it is €7 million or 1.4% (Art. 34). NIS2 has no 4% tier; see NIS2 administrative fines.

Article 35 connects the two:

1. A NIS2 authority that finds, in supervision or enforcement, that an infringement of Article 21 or 23 can entail a personal data breach notifiable under GDPR informs the data protection authority without undue delay (Art. 35(1)).
2. If the data protection authority fines under GDPR Article 58(2)(i), the NIS2 authority may not fine under Article 34 for an infringement arising from the same conduct (Art. 35(2)).
3. It can still use its other enforcement measures, such as warnings, binding instructions and orders (Arts 32(4), 32(5) and 33(4)).

On its wording, Article 35(2) covers the same conduct only: a late NIS2 early warning is arguably separate conduct that a GDPR fine does not cover.

One incident, two reports: a worked example

A hospital with 1,200 staff: an essential entity under NIS2 and a controller of health data under GDPR. Times are illustrative.

1. Monday 08:00. Ransomware confirmed, admissions diverted. Aware of a significant incident: the NIS2 clock starts.
2. Monday 13:00. Forensics finds the patient record database encrypted and large outbound transfers the night before. Aware of a personal data breach: the GDPR clock starts.
3. Monday 17:00. NIS2 early warning to the CSIRT: malicious act suspected, cross-border impact unknown. Deadline was Tuesday 08:00.
4. Tuesday. Health data and likely exfiltration mean high risk: patients are told (Art. 34), by public communication if individual letters would take disproportionate effort (Art. 34(3)(c)). Where appropriate, recipients of its services are told of the significant incident (NIS2 Art. 23(1)).
5. Wednesday. GDPR notification to the supervisory authority with what is known, more to follow. Deadline, where feasible: Thursday 13:00.
6. Thursday, by 08:00. NIS2 incident notification: severity, impact, indicators of compromise.
7. Within a month of that. NIS2 final report: root cause, mitigation, cross-border impact.

Two clocks five hours apart, two authorities, one set of facts. Had a cloud provider hosted the records, it would notify the hospital without undue delay (GDPR Art. 33(2)) and file its own NIS2 reports if the incident were significant for its service.

Joint NIS2 and GDPR incident playbook

JOINT NIS2 / GDPR INCIDENT PLAYBOOK

1. OPEN ONE INCIDENT RECORD
   ID, systems hit, services hit, first alert (UTC)

2. ASK TWO QUESTIONS, RECORD TWO TIMESTAMPS
   Q1 NIS2: significant incident?          Y / N / unknown
      severe disruption or financial loss for us?
      considerable damage to others?
      If Y: record T0, NIS2 awareness
   Q2 GDPR: personal data breach?          Y / N / unknown
      data destroyed, lost, altered, disclosed, accessed?
      which categories? health or other special data?
      If Y: record P0, GDPR awareness
   Ask both again at every update.

3. NIS2 TRACK (owner: incident lead)
   T0 + 24h    early warning, CSIRT or competent authority
   T0 + 72h    incident notification
   on request  intermediate report
   N + 1 month final report (N = notification sent)
   as needed   tell recipients of services

4. GDPR TRACK (owner: DPO or privacy lead)
   P0 + 72h    notify supervisory authority, where feasible,
               unless unlikely to result in a risk
               late: state reasons; incomplete: send in phases
   no delay    tell data subjects if high risk
   always      record in internal breach log
   processor?  tell the controller without undue delay

5. ONE SET OF FACTS
   Same timeline, scope and root cause in every report.
   Explain any difference between reports in writing.

6. CLOSE
   Lessons learned, gaps fixed, risk register updated.

What do NIS2 and GDPR leave open?

Both laws start the clock at “becoming aware”. Neither says how you become aware, or how you answer their questions in time.

• Two maps. NIS2 needs systems mapped to services and customers; GDPR needs systems mapped to categories of personal data. In practice IT keeps one, the DPO the other, and they do not join. Joined, they answer “was health data on the encrypted servers?” in minutes.
• Logs. Whether data left the network, and whether it was encrypted, decides whether individuals must be told. That needs queryable logs kept long enough, and encryption you can prove.
• One control set. Encryption, access control, MFA, patching and tested restores serve Article 32 and Article 21 at once. Collect the evidence once, map it twice. An ISMS already holds most of it: see ISO 27001 vs NIS2.

The CloudSoul platform, an automated platform with human-in-the-loop expertise, collects that evidence continuously, keeps one incident record for both tracks, and leaves significance and risk calls to a person. The wider programme is on the NIS2 compliance page.

NIS2 and GDPR checklist

• Keep one inventory mapping systems to services and to categories of personal data.
• Name an incident lead and a breach lead, each with a deputy reachable out of hours.
• Record the NIS2 and GDPR awareness timestamps separately in every incident.
• Prepare templates for the early warning, the GDPR notification and the notice to people, and test both reporting channels.
• Put processor and supplier notification duties, in hours, into contracts.
• Evidence one set of controls against both Article 32 and Article 21.
• Rehearse one incident through both tracks at least once a year.

Sources

• Regulation (EU) 2016/679 (GDPR), Articles 2, 3, 4, 5, 9, 21, 28, 32, 33, 34, 37, 58 and 83, EUR-Lex.
• Directive (EU) 2022/2555 (NIS2), Articles 2, 3, 20, 21, 23, 32, 33, 34 and 35 and Annex I, EUR-Lex.

Frequently asked questions