GDPR and NIS2 together: how to avoid duplicating compliance effort

A mid-market European company with a competent DPO and a serious GDPR programme already covers somewhere between 35% and 55% of what NIS2 will ask. A mid-market European company that builds its NIS2 programme from scratch, ignoring the existing GDPR work, will do the same job twice, pay twice for it, and end up with two policy stacks that contradict each other in three places.

This is the article we wish more compliance teams had read in the second half of 2024, when the first wave of NIS2 transposition arrived. It is not too late for the second wave that is coming now. The point is not to make NIS2 sound smaller than it is. It is large. The point is to make sure your team does not build a parallel programme when the existing one already does half the work.

The honest overlap

Both regulations require, at minimum:

• A risk-based approach to security measures, documented and reviewed.
• Technical and organisational controls proportionate to the risk.
• Incident detection, response, and notification.
• Supply chain accountability.
• Management body responsibility for security oversight.
• Demonstrable evidence that the above is actually in place.

The vocabulary differs. GDPR talks about "personal data" and "data subjects". NIS2 talks about "network and information systems" and "service recipients". But the underlying controls (access management, encryption, logging, backups, incident response, third-party assessment, training) are largely the same. If your access management policy is well-written for GDPR, it does not need a parallel access management policy for NIS2. It needs an annex that explains how the same policy satisfies the additional NIS2-specific scope.

The honest divergence

The two regulations differ in three important ways that no merged programme can paper over.

Different harm models

GDPR protects natural persons and the personal data about them. The harm GDPR cares about is harm to individuals: identity theft, discrimination, financial loss, reputational damage. NIS2 protects the continuity and integrity of services that society depends on. The harm NIS2 cares about is operational disruption with knock-on effect on essential or important services.

This means the same incident can have different significance under each regime. A confidentiality breach with no service impact may be a major GDPR event and a minor NIS2 event. A 48-hour service outage with no personal data loss may be a major NIS2 event and a non-event for GDPR.

Different notification regimes

GDPR requires notification of a personal data breach to the supervisory authority within 72 hours of awareness when the breach is likely to result in a risk to the rights and freedoms of natural persons. The data subjects themselves must be notified when the risk is high.

NIS2 requires an early warning to the relevant CSIRT within 24 hours of awareness of a significant incident, a full incident notification within 72 hours, and a final report within one month. The service recipients must be informed when a significant incident is likely to materially affect their ability to use the service.

The two clocks can be running at the same time, with different recipients and different content requirements. Companies that merge the two processes naively underestimate how complex the first dual-notification incident will be.

Different governance anchors

GDPR governance lands on the DPO function, which is required for certain types of processing. NIS2 governance lands on the management body, which has direct training obligations and personal liability exposure.

In a mid-market company without a CISO, the temptation is to ask the DPO to absorb NIS2 governance. That is a mistake. The DPO has a defined independence from the controller's operational decisions; the cybersecurity leader for NIS2 needs to be inside the operational chain. The two roles can sit next to each other; they cannot collapse into one.

A merged programme that works

We have built and operated dual GDPR-NIS2 programmes in several mid-market client engagements. The pattern that consistently works has five elements.

Element 1 · One control catalogue, two policy lenses

Build one cybersecurity control catalogue. Tag each control with the GDPR articles and the NIS2 articles it satisfies. Use it as the source of truth for audit, for board reporting, and for evidence. Avoid the duplicated parallel catalogues that often emerge from siloed compliance projects.

Element 2 · Two governance forums with explicit interfaces

Keep the data protection committee (DPO-led, GDPR-focused) and create or strengthen the cybersecurity committee (cybersecurity leader-led, NIS2 plus broader scope). Define the interface explicitly: what does each forum present to the other, on what cadence, who attends both. A quarterly joint session covering incident metrics and supply chain risk works in most mid-market companies.

Element 3 · One incident response plan with dual notification paths

The IRP itself is shared. The notification annexes are split. The plan should make it explicit that an incident may trigger a GDPR notification, a NIS2 notification, both, or neither, and the decision tree should be visible to the responder during the first hour of an incident.

Test this annex during your next tabletop exercise. The first time the dual-notification flow runs in a real incident, with both clocks running and the leadership team asking questions, is not the time to discover ambiguity in the plan.

Element 4 · One supply chain assessment, two reporting flows

The third-party assessment process is shared. The output feeds both the GDPR records of processing activities and the NIS2 supply chain risk register. Make sure the assessment questionnaire collects the data both regimes need: data categories and locations for GDPR, criticality and incident notification commitments for NIS2.

Element 5 · One evidence repository, two audit views

A single evidence repository (whether a GRC platform, a ticketing system, or a structured document repository) holds the evidence. Two saved searches or two views give each audience what they need. The DPA auditor sees the GDPR-relevant evidence; the NIS2 supervisor (or your internal NIS2 audit) sees the NIS2-relevant evidence.

The 90-day merged uplift

For a company that has a working GDPR programme and is starting from zero on NIS2, the realistic uplift is 90 days of focused work. Compressing it further is possible only at the cost of quality. Stretching it further is possible but the political cost of "still working on it" usually exceeds the technical cost of finishing.

A realistic week-by-week shape:

• Weeks 1-2. Gap analysis: map the existing GDPR control catalogue to NIS2 article 21 requirements. Identify the genuine gaps, not the relabelling work.
• Weeks 3-4. Governance: set up the cybersecurity committee, define its interface with the data protection committee, schedule management body training.
• Weeks 5-6. Risk assessment: extend the existing GDPR risk methodology to cover the broader NIS2 scope (service availability and integrity, not only confidentiality of personal data).
• Weeks 7-8. Incident response plan refresh: add the NIS2 notification annex, run a tabletop exercise that exercises both clocks.
• Weeks 9-10. Supply chain: extend the existing third-party assessment to cover NIS2 supply chain criteria, refresh the contracts of the top 10 critical suppliers.
• Weeks 11-12. Documentation, evidence repository setup, and the first internal audit pass.

After 90 days, the residual work (subsidiaries, additional sectors, sector-specific obligations) becomes incremental. The structural work is done.

The pitfalls we see most often

• Treating NIS2 as a security project, not a governance project. The management body training and the personal liability conversation are non-negotiable. If they slide, the whole programme is brittle.
• Asking the DPO to be the cybersecurity leader. This breaks the DPO's independence and undersizes the cybersecurity role.
• Buying a "NIS2 compliance platform" before doing the gap analysis. Tools should serve the programme. A platform purchased before the programme is designed becomes a constraint on the design.
• Forgetting subsidiaries. A parent company that scopes NIS2 only to itself, and not to its subsidiaries operating in essential or important sectors, has a scope gap that an audit will find.
• Confusing certification with compliance. Neither GDPR nor NIS2 requires ISO 27001 certification. ISO 27001 helps; it does not substitute for the regime-specific evidence each authority will ask for.

> "The cleanest dual GDPR-NIS2 programmes we have audited share one feature: a single owner who treats both regimes as one programme with two reporting flows. The messiest share another: two parallel projects that meet once a quarter and disagree." — IBL audit review of 2025 dual programmes

What we do at IBL

We run merged GDPR-NIS2 uplift engagements for mid-market companies that already have a working GDPR programme and need to build the NIS2 layer on top without duplication. The engagement is typically a fixed 90-day scope with a named lead, a weekly stand-up with the client's compliance and IT leadership, and a written report at the end that the management body can present to its supervisor of choice.

If you want a conversation about your current GDPR-NIS2 posture, write to [email protected]. We answer within one business day.

---

Ibida Black Level S.L. is a boutique cybersecurity advisory firm headquartered in Málaga, Spain, with an operational team in Romania. We focus on mid-market European companies that prefer technical honesty to vendor packaging. We were founded in 2026; we do not invent a longer history.

Related reading

• NIS2 self-assessment: 25 questions to check if your company complies (cluster Q3 pillar)
• DMARC explained: why your email is vulnerable and how to fix it in 24 hours (cluster Q3 pillar)
• NIS2 vs ISO 27001: when each is the right lever (cluster Q3 pillar)

Tags: gdpr, nis2, compliance, data-protection, incident-notification, supply-chain, governance