How NIS2 and GDPR reporting run on one incident
One cyber incident can start two separate reporting clocks. If it is significant under NIS2, the organization must send an early warning within 24 hours of becoming aware of it and an incident notification within 72 hours under Article 23. If the same incident exposes personal data, GDPR Article 33 requires notifying the data protection authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to individuals. The two obligations run in parallel. Each has its own recipient, its own required content and its own test for whether individuals must be told. A single reporting workflow with one shared decision point can check both obligations at the same time.
The organization owns every notification. It decides whether the incident is significant, whether personal data is affected and whether the risk threshold for individuals is met, and it makes and signs each submission to the CSIRT or competent authority and to the data protection authority. An implementation partner can prepare the work that makes those decisions fast: a decision record template, pre-registered contacts for each authority, the DPO's details for the notice, and an evidence file with timestamps showing when the organization became aware. Confirm which national CSIRT or competent authority and which data protection authority apply to each establishment, because channels and forms are set nationally.
No independent body issues a NIS2 certificate for this process. National competent authorities supervise compliance, and under Article 35 they must inform the GDPR supervisory authority when an infringement can entail a notifiable personal data breach. Your evidence is the reporting record itself: the timeline, the notifications as sent and the reasons for any late submission under Article 33(1). Processors must notify the controller without undue delay (Article 33(2)), so supplier contracts should name the contact point and the expected timing. Ask your processors and cloud providers to confirm how fast they will tell you, and check that any notice to customers uses the clear and plain language Article 34(2) requires.
NIS2 and GDPR clocks after one incident
This sequence turns the moment an organization becomes aware of an incident into a recorded decision, two parallel reporting clocks and a processor-to-controller handoff, so each authority receives what it needs within its deadline. Each step closes with a document the compliance lead can produce on request.
Record the moment of awareness
The NIS2 and GDPR clocks both start when the organization becomes aware of the incident, so the incident lead should log the date and time of that awareness in the incident record as the first entry. Record who detected the event, what was known at that point, and who made the first decision to treat it as a possible incident. Confirm the time with the on-call log or ticketing system timestamps. The step is done when the record is signed off by the incident lead and stored where the compliance lead can retrieve it.
Decide whether the incident is significant
The incident lead, with legal and the DPO, decides whether the event is a significant incident under NIS2 and whether it is also a personal data breach that may need GDPR notification. Use the significance criteria in the reporting obligations and the Implementing Regulation for your sector, and document the facts relied on. Record a separate view on whether the breach is unlikely to result in a risk to individuals, since that conclusion removes the GDPR notification duty. The step closes with a signed significance and personal data assessment that names the decision makers.
Process the processor's notification to the controller
If a processor or supplier hosts or handles the affected personal data, the processor must notify the controller without undue delay after it becomes aware of the breach. Check your contracts for the notification route, named contacts and the information the processor must supply. Log the processor's notice as an event with its own timestamp, because a late supplier notice does not move the controller's clock. The step is done when the supplier notice is on file and linked to the incident record.
Submit the NIS2 early warning
For a significant incident, the entity must submit an early warning without undue delay and in any event within 24 hours of becoming aware. Keep the content short and factual: whether the incident is suspected to be caused by unlawful or malicious acts or could have a cross-border impact, based on what is known at that point. Send it through the channel your national competent authority or CSIRT designates, and keep the transmission receipt. The step is done when the receipt and the submitted text are stored with the incident record.
Notify the GDPR supervisory authority
The controller must notify the competent data protection authority without undue delay and, where feasible, within 72 hours of awareness. If the notice is late, the file must state the reasons for the delay. The notice must describe the nature of the breach, including the categories and approximate numbers of data subjects and records where possible, the DPO or contact point, the likely consequences and the measures taken or proposed. The step is done when the authority's acknowledgement is stored with the notice, or the reasons for delay are recorded.
Submit the NIS2 incident notification
Within 72 hours of becoming aware of the significant incident, the entity must submit the incident notification to the same authority, with an updated assessment of severity and impact and indicators of compromise where available. Reconcile its facts with the GDPR notice so both filings describe the same incident, scope and dates. Keep the submission receipt with the incident record. The step is done when a reconciliation note confirms that the two filings do not contradict each other.
Hold the reporting file for the authorities
Keep one reporting file that contains the awareness record, the significance and personal data decisions, the processor notice, both submissions, receipts and any later updates. The NIS2 final report and any further GDPR information follow from this file, so it must stay current as facts change. Ask the authorities whether they need the same evidence in a set format. The step is done when a compliance lead can produce the complete file, with timestamps, within a short working period of a request.
What each notification must contain
A single incident can require up to four notifications: two under NIS2 and two under GDPR. Each has its own clock and its own content rules, so the same facts often need to be reshaped for each recipient. Keep one incident record that feeds all four.
NIS2 early warning
Due without undue delay and in any event within 24 hours of becoming aware of a significant incident. It is a short first signal to the CSIRT or competent authority, sent before the facts are settled. Check whether the incident is suspected to be unlawful or malicious and whether it may have cross-border impact, since those are the points the early warning is expected to flag. Confirm the exact fields and submission channel with your national authority before you need them.
NIS2 incident notification
Due without undue delay and in any event within 72 hours of becoming aware of the significant incident. It updates the early warning with an initial assessment of severity and impact, and records any indicators of compromise available at that point. Use the same incident identifier across every submission so the authority can follow the thread. Confirm with your national authority which assessment fields it expects at this stage.
GDPR Article 33 notification
Sent by the controller to the data protection supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach. It must describe the nature of the breach, including the categories and approximate numbers of data subjects and records where possible. It must give the DPO or other contact point, likely consequences, and measures taken or proposed. If it is late, it must give the reasons for the delay.
GDPR Article 34 communication
Sent to affected individuals when the breach is likely to result in a high risk to their rights and freedoms. It must describe the nature of the breach in clear and plain language, not regulatory wording. It must also give contact details, likely consequences, and the measures taken or proposed. Confirm with your DPO when the high-risk threshold is met and who signs the message, since customers may need a parallel notice under their contracts.
Controller, processor or supplier: who notifies whom
When the organization decides why and how personal data is processed, it is the controller. If an incident is both a significant NIS2 incident and a personal data breach, the organization owns two separate filings: an early warning and notification to its CSIRT or competent authority under Article 23 NIS2, and a notification to the data protection authority under Article 33 GDPR. The GDPR clock runs from the moment the controller becomes aware of the breach, and a late filing must explain the delay.
- NIS2 filing: The organization files the 24-hour early warning and the 72-hour incident notification with its competent authority or CSIRT, as set by its national transposition law.
- GDPR filing: The organization notifies the supervisory authority within 72 hours where feasible, unless the breach is unlikely to result in a risk to individuals.
- Content: The GDPR notice must describe the nature of the breach, the likely consequences, contact details of the DPO or another contact point, and the measures taken or proposed.
- Individuals: Where the breach is likely to result in a high risk, the controller informs affected individuals in clear and plain language.
- Coordination: Notifications should use consistent facts, since the authority may pass information to the GDPR supervisor under Article 35 NIS2.
Confirm with counsel which national CSIRT or authority receives your NIS2 filings and which GDPR supervisory authority is competent for your main establishment.
When the organization processes personal data on behalf of a customer, it is a processor. The GDPR duty is narrow: the processor must notify the controller without undue delay after becoming aware of a personal data breach. The customer then decides whether and how to file with its own authority. If the customer is an in-scope NIS2 entity, the processor's own NIS2 duties depend on whether the processor is itself in scope, which the implementing rules and national law determine.
- Processor duty: Notify the controller without undue delay once aware of the breach, without waiting for a complete analysis.
- Customer filings: The customer files the GDPR notification and any NIS2 early warning or notification, and the processor supplies facts on request.
- Information flow: Agree on the channel, the named contacts, and the information the processor will provide in the first notice and later updates.
- Contract terms: Set the notification window, the data the processor must supply, cooperation duties, and who pays for individual notices.
- Standard clauses: Commission Implementing Decision (EU) 2021/915 provides standard contractual clauses between controllers and processors that can serve as a starting point.
Check whether your contracts state a notification window and who bears the cost of notifying individuals, because those points are often missing.
When the organization supplies services or products to an in-scope NIS2 entity, it usually has no direct NIS2 reporting duty for the customer's incident. Its exposure runs through the contract and through its own GDPR role. If the supplier processes personal data for the customer, it is a processor. If it also processes data for its own purposes, it may be a controller for that processing. The supplier's job is to detect and report to the customer quickly so the customer can meet its deadlines.
- Customer's clock: The entity's 24-hour early warning and 72-hour notification run from its own awareness, so supplier delay shortens its window.
- Supplier notice: Notify the customer without undue delay once the supplier becomes aware of an incident affecting the customer's systems or data.
- Filings: The customer files NIS2 reports. The supplier files only its own GDPR notifications where it is a controller.
- Contract terms: Define incident types, notice timing, information content, contacts, and the supplier's support obligations.
- Assurance: Agree evidence the supplier will provide, such as incident logs or post-incident reports.
Confirm whether your customers are in scope of NIS2 and what their contracts require from you.
Informing individuals and customers without over-sharing
Individuals must be told only when the breach is likely to result in a high risk to their rights and freedoms. Under Article 34 of the GDPR, the controller communicates a personal data breach to the affected individuals without undue delay in that case. The notification to the data protection authority under Article 33 is a separate step with a lower bar: it is required unless the breach is unlikely to result in a risk to individuals. The EDPB's Guidelines 9/2022 on personal data breach notification set out how to assess that risk, weighing the type of data, the ease of identifying people, the severity of consequences and the number of individuals affected. Record the assessment for every incident, including the decision not to inform individuals, because the supervisory authority may ask for it. Confirm each threshold decision with counsel or your data protection officer before the message goes out, since the same facts can land on either side of the line.
Customers may need their own NIS2 information in addition to any GDPR communication. Where a significant incident affects the services you provide, Article 23 requires you to inform the service recipients that may be affected, and to tell them about measures or remedies they can take in response. This duty is tied to service impact, so a customer can need a message even when no personal data is involved, and a customer can need no NIS2 message even when personal data is involved. Map each recipient group to the trigger that applies to it before drafting. Keep one fact base for every audience: the same description of the incident, dates, scope and measures should appear in the regulator filing, the individual notice and the customer message. Differences in wording invite questions from supervisors and erode trust, so route all drafts through the same incident lead and legal review.
Give individuals and customers only what they need to act and what the regulator already has. A GDPR communication to individuals must describe the breach in clear and plain language and include contact details, likely consequences and measures taken or proposed. Avoid naming unconfirmed root causes, internal tooling, unverified attacker details or numbers that may change, and state that the investigation continues if that is true. Agree in advance who approves each message and who answers follow-up questions. Confirm with your data protection officer and, for customer messages, with the NIS2 competent authority or CSIRT contact you use, which details must appear and which should stay out of public or customer-facing text.
NIS2 and GDPR notifications by incident type
This table compares four incident situations and shows which NIS2 and GDPR notifications may apply, what each contains and what the organization should record. Read each row as a separate decision, because the two regimes are triggered by different tests: significance under NIS2 and risk to individuals under GDPR.
| Incident situation | NIS2 reporting | GDPR notification | What to record |
|---|---|---|---|
| Significant incident, no personal data | 24-hour early warning, 72-hour notification and final report to the CSIRT or competent authority | Not required unless personal data is affected | Significance assessment, times of awareness, reports sent and reasons for classification |
| Personal data breach, not a significant incident | Not required under Article 23 unless the incident meets significance criteria | Notify the supervisory authority within 72 hours where feasible, unless no risk to individuals is likely | Breach facts, data categories, risk assessment and any reasons for delay |
| Significant incident that is also a personal data breach | Early warning within 24 hours and notification within 72 hours of awareness | Notify the GDPR authority within 72 hours where feasible, with the Article 33(3) content | Both timelines, the shared facts, the contact point and copies of each submission |
| Breach unlikely to create risk to individuals | Depends on NIS2 significance, reported separately if significant | Notification may not be required, but the breach must still be documented | Written justification of the risk conclusion, reviewed by the DPO or responsible officer |
Coordination between authorities and the rule against double fines
When an infringement of Article 21 or Article 23 of NIS2 can entail a personal data breach that must be notified under Article 33 GDPR, the competent authority must inform the GDPR supervisory authority without undue delay (Article 35(1)). The duty runs from the NIS2 regulator to the data protection authority, so an entity does not have to brief both regulators separately to start that exchange. It does not, however, replace the entity's own obligations: the 24-hour early warning, the 72-hour notification and the GDPR breach notification each still run on their own clocks. Keep a single timeline of what was reported, to whom and when, so that answers to either authority match the record.
Article 35(2) sets the limit on penalties. If the GDPR supervisory authority imposes a fine under Article 58(2)(i) GDPR for the same conduct, the NIS2 authority may not impose an administrative fine under Article 34 NIS2 for an infringement arising from that conduct. Other enforcement measures remain open to the NIS2 authority, so the rule limits one category of fine rather than ending enforcement. The GDPR fine ceilings are set in Article 83 GDPR, and the reader should treat them as the reference point for the GDPR side only. Confirm with counsel or the national authorities how each Member State applies Article 35(2) in practice, including the order in which proceedings run and how the NIS2 authority documents that a GDPR fine covers the same conduct.
Before an incident, decide who on the response team owns the link between the two regulatory tracks, and agree what evidence you will hand each authority on request. Ask your national CSIRT or competent authority how it will notify the data protection authority, and whether it expects a copy of the GDPR notification. Confirm your national supervisory authority's breach notification channel and the current status of the EDPB common data breach notification template referenced in the topic sources, so the reporting team uses the form the regulator expects.
Where reporting one incident goes wrong
When one incident triggers both NIS2 and GDPR duties, the same small gaps repeat across organizations: late clocks, unmatched notices, missing contacts and conflicting descriptions. Each card below names one failure and the control that prevents it, so the reporting team can check these points before a real incident forces the question.
Starting the clock late
The 24-hour early warning and the 72-hour notification both run from the moment the entity becomes aware of the significant incident. If nobody records when awareness happened, the team cannot prove when the clock started and may argue about it afterward. Use a single incident record that stores the time of first detection, the time the incident was classed as significant, and the name of the person who made that call. Check that every alert source feeds this record, so the timestamp is never reconstructed from memory.
NIS2 notice without GDPR assessment
A NIS2 notification can go out while the organization has not yet decided whether personal data was affected. The GDPR controller must notify the supervisory authority unless the breach is unlikely to result in a risk to individuals, so a missing assessment leaves the second obligation unresolved. Require a short personal data assessment as a fixed step in the incident record, completed or explicitly marked open before the 72-hour notification is filed. Ask the data protection officer to sign off the outcome.
Missed processor notice to the controller
Where a cloud provider, managed service or other processor hosts the affected data, the processor must notify the controller without undue delay after it becomes aware of the breach. Controllers often assume the processor will call, and the processor often assumes the customer already knows. Put a contractual notice duty and a named processor contact in each data processing agreement, and test that the processor's alert path reaches the controller's incident mailbox outside business hours.
Missing DPO or NIS2 contacts
A notification must give the contact details of the data protection officer or another contact point, and the NIS2 report must identify the entity's own contact. When these details are missing, incomplete or outdated, the notice is weakened before it is read. Maintain a named contact list with two deputies for each role, including phone numbers and out-of-hours routes, and review it on a fixed schedule. Confirm which contact point each national authority expects for its portal or email channel.
Inconsistent breach descriptions
The GDPR notice, the NIS2 report and the customer communication must describe the same breach, but each is often drafted by a different team at a different hour. Differences in the number of affected people, the data categories or the likely consequences invite questions from both authorities and erode customer trust. Keep a pre-approved description template with the facts that have been verified, mark which facts are still open, and require each update to revise the shared record before any outgoing message is sent.
Questions buyers ask about NIS2 and GDPR reporting
Does one notification satisfy both NIS2 and GDPR?
No. A single incident can trigger two separate duties, each with its own authority, timeline and content. NIS2 reporting under Article 23 goes to the CSIRT or competent authority, with an early warning within 24 hours and a notification within 72 hours of becoming aware of a significant incident. A personal data breach notification under Article 33 GDPR goes to the data protection authority, with a 72-hour clock where feasible. The NIS2 notice covers significance, impact and recovery; the GDPR notice must describe the nature of the breach, the categories and approximate numbers of data subjects and records, the contact point, likely consequences and measures taken. Ask your legal team to map which filings apply to each incident before the first alert arrives.
Can an implementation partner prepare the NIS2 and GDPR reporting templates and drills?
Yes, as preparation. A fixed-scope implementation partner such as DeployOpen can help draft reporting templates, map fields across both notifications, configure the logging and ticketing systems that collect the facts, and run tabletop drills that rehearse the deadlines. The organization owns the decisions: it determines whether an incident is significant, who signs each filing and what is submitted. DeployOpen does not file reports on an organization's behalf and does not issue audit reports or certificates. Agree the templates, drill scenarios and deliverables in writing before work starts, and confirm with counsel which contact points each authority accepts.
How long does it take to prepare a joint NIS2 and GDPR reporting process, and what drives it?
The duration depends on the scope agreed in writing, and no fixed figure applies to every organization. The main drivers are the number of systems that hold personal data, how mature the existing incident response plan already is, whether separate teams own security operations and privacy, and how many Member States the entity operates in, since national transposition laws set the details of reporting. Expect preparation work to cover a current-state review, template design, integration with detection and ticketing tools, and at least one rehearsal. Ask any provider for a written timeline tied to named deliverables and dependencies on your staff.
What does the process need from our own staff?
It needs named owners from several functions working on the process, because the facts that feed both notices come from different places. Typically this includes a security lead who decides significance, a privacy or DPO contact who assesses personal data impact, legal counsel who reviews filings, a communications lead for customer notices, and system owners who confirm affected assets and records. Staff time is needed for interviews during the review, for template sign-off, and for drills that take a few hours each. Confirm availability at the start, because a process that depends on one person's calendar will miss the 24-hour window.
Does a GDPR breach notification count as a NIS2 report?
No. A GDPR notification to the data protection authority under Article 33 does not replace the NIS2 early warning or incident notification to the CSIRT or competent authority. The two regimes use different authorities, different thresholds and different content. Article 35 of NIS2 requires the competent authority to inform the GDPR supervisory authority when an infringement may entail a notifiable personal data breach, so the authorities share information, but the entity must still submit each filing itself. Keep both notices consistent in facts and timing, and record the reasons for any difference.
Does an independent auditor certify our NIS2 incident reporting?
No certificate of NIS2 compliance exists. NIS2 creates no certification scheme for reporting. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. An independent auditor or assessor can test your process against your own documented procedures, but any report it issues is an assessment, not a NIS2 certificate. Ask your national authority which evidence it expects during supervision, and keep records of each incident, decision and filing so that you can show them on request.
How DeployOpen prepares NIS2 and GDPR reporting
DeployOpen prepares the systems, runbooks and evidence an organization needs to report one incident under NIS2 and GDPR. The organization keeps ownership of its reporting decisions, and only the competent authorities and data protection authorities assess what is submitted.
How we scope
- Written scope names the entities, self-hosted platforms and reporting channels covered by the NIS2 and GDPR work.
- Scope records which teams decide significance and who signs each early warning and notification.
- Fixed-scope engagements agree deliverables and timelines in writing before any work starts.
How we build
- Configure logging and alerting in your own infrastructure so the 24-hour and 72-hour clocks can be tracked.
- Build a combined NIS2 and GDPR notification template covering nature, contacts, consequences and measures.
- Set up processor-to-controller notice paths with suppliers hosting the self-hosted platforms.
How we hand over
- Deliver a documented reporting runbook with owners, decision points and submission steps for each authority.
- Provide test records showing the reporting workflow was exercised, with lessons logged for follow-up.
- Hand over configuration, access and evidence locations so your own staff can operate the process.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the handover.
- Retainers can keep runbooks and contact lists current as national rules and supervisor guidance change.
- Confirm with your counsel and independent assessor which evidence they will accept before the engagement starts.
