How a NIS2 failure becomes a GDPR breach case
A failure under Article 21 (the risk-management measures) or a late or missing report under Article 23 can expose personal data, which means two regulators may act on the same event: the national competent authority under NIS2 and the data protection authority under the GDPR. Article 35 is the rule that governs how those two tracks meet. When an infringement of Article 21 or 23 can entail a personal data breach that must be notified under Article 33 of the GDPR, the NIS2 authority must inform the GDPR supervisory authority without undue delay. The reverse protection matters just as much: if the data protection authority imposes a fine for the same conduct, the NIS2 authority may not impose its own Article 34 fine for that infringement, although it can still use other enforcement measures. In practice, the aim is that one set of conduct is not punished twice in monetary terms.
The legal text is short, so the hard part is operational. Your organization needs to know, within hours of discovering an incident, whether it has a personal data breach, whether that breach is notifiable, and whether the same facts also trigger an Article 23 report. Those answers depend on evidence: the timeline of when the incident was detected and contained, which systems and records were affected, and what each decision was based on. Ask your incident response lead to confirm who decides on GDPR notification, who decides on NIS2 reporting, and where the two decisions are recorded. Reviewing the time limits that apply under each regime with counsel or your data protection officer is a sensible step before an incident occurs, because the GDPR and NIS2 clocks do not start at the same point in every case.
Treat each incident as one case with one evidence trail, then branch it into the two notifications. A case management platform such as DFIR-IRIS can hold the affected assets, indicators, tasks and evidence in a single record with an audit trail, and build a consolidated timeline that both regulators can be shown. Confirm three things before you rely on any tool: that your reporting templates capture the fields each regulator asks for, that your timestamps are synchronized across sources, and that you can export the case record without losing its audit history. The DFIR-IRIS documentation sets out what the platform records, which is a sound starting point for that check. The legal analysis of how Article 35 applies to your case still belongs to counsel and your data protection function.
Which incidents and entities trigger Article 35
Article 35 applies only when three conditions meet at once: an entity in scope under Article 2, an infringement of Article 21 or 23, and a personal data breach that may be notifiable under GDPR Article 33. The cards below cover the scoping decisions that determine whether those conditions are met and who must be told.
In-scope entity and the Article 2 test
Article 35 only reaches entities that NIS2 covers. Confirm first whether the organization is an essential or important entity under Article 2 and the Annex I or II sector rules, because an out-of-scope company cannot be fined under NIS2 for the same conduct. Record the scoping decision and its basis so it can be shown to a supervisor. Also check whether a sector-specific law displaces NIS2 for part of the business.
Article 21 or 23 infringement
The trigger is a failure under Article 21 risk-management measures or Article 23 reporting duties, not any security incident. An incident that is caught, contained and reported on time may involve no NIS2 infringement at all. Map each incident to the specific obligation it touches, such as a missing access control or a late early warning, so that the NIS2 and GDPR analyses start from the same facts.
Systems that process personal data
Identify which in-scope network and information systems hold personal data, including HR, customer, logging and backup stores. A breach in a system with no personal data stays outside GDPR Article 33, while a breach in a shared identity or log platform can expose personal data across many services. Keep a current data inventory mapped to the systems in the NIS2 asset register.
Processors and cloud providers
Where a cloud provider, managed service provider or hosting partner processes personal data for the organization, the processor duties under GDPR apply alongside NIS2 supply chain duties. Confirm the contract requires the processor to tell the controller about a breach without undue delay, and that the controller can meet its own 72-hour GDPR clock. Ask suppliers which of their logs and notices will support the assessment.
Separate CSIRT and data protection authorities
In some Member States the CSIRT or competent authority under NIS2 and the data protection authority under GDPR are different bodies, possibly in different jurisdictions for a group. Map each entity's main establishment and the authority each filing goes to before an incident occurs. Article 35(1) requires the NIS2 authority to inform the GDPR supervisory authority, but the organization should not assume that makes its own filings unnecessary.
Single incident, two filings
One incident can require a NIS2 report to the CSIRT or competent authority under Article 23 and a personal data breach notification to the data protection authority under GDPR Article 33. Confirm which trigger is met first, which clock starts, and who in the organization signs each filing. Keep one case record that holds the timeline, evidence and both assessments so that the two reports stay consistent.
How the competent authority refers the case to the GDPR authority
The sequence moves a possible personal data breach from the NIS2 authority to the GDPR supervisory authority, then settles whether an Article 34 fine can still be imposed for the same conduct. Each step leaves a record that shows the referral and the decision were made in order.
Identify a possible personal data breach
During an inspection, audit, scan or review of an Article 21 or 23 infringement, the NIS2 competent authority checks whether the conduct can entail a personal data breach notifiable under Article 33 GDPR. The authority makes this assessment itself, based on the facts in its file, such as the systems affected and the categories of data involved. The output is a documented finding that a personal data breach is possible, recorded in the case file with the facts that support it. Organizations should expect questions on exactly these points, so their own incident and breach records should already map affected systems to the personal data they hold.
Inform the GDPR supervisory authority
Once the possible breach is identified, the NIS2 authority must inform the GDPR supervisory authority without undue delay, as Article 35(1) requires. The notice goes from the NIS2 authority to the data protection authority, not from the organization, although the organization should expect the authority to request the same facts it has already supplied. The output is a referral record showing the date of the notice, the authority that received it and the infringement it concerns. Ask your counsel which national authorities are competent for both regimes, since the NIS2 authority and the GDPR authority may sit in different bodies.
Assess the GDPR fine decision
The GDPR supervisory authority decides on its own powers whether to impose a fine under Article 58(2)(i) GDPR for the personal data breach. The NIS2 authority does not make this decision and cannot direct it. The output is a GDPR decision or a documented decision not to fine, which the NIS2 authority needs before it can apply Article 35(2). Organizations should keep their own breach notifications and responses separately documented, because the GDPR authority will assess them against the GDPR record, not the NIS2 file.
Test whether the same conduct is fined
The NIS2 authority compares the GDPR fine with its own infringement. If the GDPR authority has imposed a fine under Article 58(2)(i) for conduct arising from the same facts, the NIS2 authority may not impose an Article 34 administrative fine for that infringement. The test turns on whether the conduct is the same, not on whether the two regimes use the same label. The output is a written determination that an Article 34 fine is barred or is still open, with reasons. Where the facts differ, a separate NIS2 fine may remain possible, so the reasoning matters.
Apply the remaining enforcement measures
Where an Article 34 fine is barred, the NIS2 authority still holds the other enforcement measures available under the Directive, including binding instructions, compliance orders and other measures set out in Article 32 and 33 supervision. The authority decides which measures fit the remaining infringement and records each one with its legal basis. The output is a set of enforcement decisions that address the Article 21 or 23 failings not covered by the GDPR fine. Organizations should confirm with their national transposition law which measures apply to their sector and entity type.
Record the outcome in the case file
The NIS2 authority closes the referral by recording the GDPR outcome, the Article 35(2) determination and any remaining enforcement measures in one case file. The organization receives the decisions that affect it and can use them to plan corrective work. The output is a closed case file linking the NIS2 decisions to the GDPR decision, which lets both regimes be reviewed together. Organizations should keep copies of every notice and decision they receive, because a later review may depend on the sequence of events.
How an assessor tests the GDPR interaction
This table lists what a supervisor or reviewer checks when one incident may breach both NIS2 Article 21 or 23 and GDPR, the evidence each check needs, and where files usually fall short. Read each row as a question the file must answer on its own, without relying on memory or verbal explanation.
| Test | What the reviewer checks | Evidence that passes | Where files usually fail |
|---|---|---|---|
| Referral recorded | Whether the competent authority recorded that the infringement may entail a personal data breach and informed the GDPR supervisory authority | Dated referral record or correspondence showing the authority identified the GDPR link and the recipient supervisory authority | No referral record exists, or the entity assumes the authority will refer the matter without any documented contact |
| Timeline alignment | Whether the NIS2 early warning, notification and final report dates line up with the GDPR Article 33 notification clock | One incident timeline with timestamps for detection, awareness, each NIS2 filing and each GDPR filing | Timelines reconstructed from memory, or the two filings carry different detection or awareness dates |
| Consistent facts | Whether the nature, scope, affected systems, data categories and root cause match across both filings | A single source-of-record incident file from which both filings were drafted, with a version history | Filings describe the affected service or record count differently, or the root cause changes between submissions |
| Same-conduct analysis | Whether the entity can show how it separated NIS2 Article 21 or 23 findings from GDPR findings for the same conduct | Written mapping of each finding to the legal basis it engages, with the reasoning for any overlap | No analysis exists, so the entity cannot show why a second fine for the same conduct would be avoided |
| Fine avoidance | Whether any Article 58(2)(i) GDPR fine was imposed and whether an Article 34 NIS2 fine was then withheld for the same conduct | Copy of any GDPR decision, the authority's record of the Article 35(2) outcome, and the entity's own tracking of open proceedings | Parallel proceedings run without a shared register, so the entity cannot confirm which authority has acted |
| Personal data handling | Whether personal data processed during response complied with the GDPR, consistent with NIS2 Article 2 scope language | Records of processing activities, retention decisions and access logs for evidence collected during the incident | Forensic copies of personal data kept without a documented legal basis or retention limit |
| Evidence integrity | Whether the incident evidence supporting both filings can be verified and traced to its source | Case records with hashes, chain of custody and an audit trail, such as those produced by DFIR-IRIS | Screenshots and emails stored without hashes, or access to the case file not logged |
What the rule against double fines does and does not stop
The rule against double fines is narrow. It bars a national competent authority from imposing an Article 34 administrative fine for an infringement of Article 21 or 23 where the same conduct has already led a GDPR supervisory authority to impose a fine under Article 58(2)(i) GDPR. The bar is triggered only by that specific GDPR fine and only for the same conduct. It does not stop a NIS2 authority from acting in other ways. Under Article 35(2), the authority may still use the other enforcement measures available to it, such as warnings, binding instructions, compliance orders and orders to bring processes into line with the Directive. Where a GDPR fine is not imposed, or concerns different conduct, the bar does not apply at all. Organizations should not assume that a GDPR penalty closes the NIS2 file.
The rule also does not change the underlying duties. NIS2 applies without prejudice to the GDPR, and any processing of personal data carried out under NIS2, such as logs, incident records, contact details of users or evidence collected during an investigation, must still comply with the GDPR. Security measures that protect that data, the lawful basis for processing it and the rules on transfers continue to apply in full. An entity that treats NIS2 reporting as a separate track from its data protection program is likely to find gaps when both authorities review the same incident. Review the records of processing and the data retention settings used by your incident response tooling so they match what each regime requires.
Confirm how your Member State transposed Article 35 into national law before relying on this analysis. Ask your national competent authority or your legal counsel whether the national text adds procedural steps, changes the sequence in which the two authorities act, or sets out how the fine bar is applied in practice. Also confirm which data protection authority is competent for your establishment, since that determines who receives the information under Article 35(1). The NIS2 Directive text on EUR-Lex is the starting point, but the national law and its guidance decide how the bar works for your organization.
Evidence that shows one incident was handled under both regimes
When one incident triggers both NIS2 reporting and a GDPR breach notification, the authorities will compare the two records against each other. The artifacts below are what connects them, and each should be kept current between incidents rather than assembled after the fact.
Single incident record
Keep one case record per incident that holds the affected assets, indicators of compromise, tasks, timeline and evidence items, each with an audit trail. Both the NIS2 notification and the GDPR notification should be drawn from this record. Check that asset names, data categories and timestamps are identical in every copy, because a mismatch is the first thing a reviewer will look for.
Copies of both notifications
Retain the exact Article 23 submissions to the CSIRT or competent authority and the Article 33 GDPR notifications to the data protection authority, with submission times and reference numbers. Confirm that the facts stated in each are consistent, and record any later updates sent under either regime. Notifications sent in different formats can still describe the same incident, so the matching check should be deliberate.
Decision log
Record who decided whether the incident was significant under NIS2, whether it involved a personal data breach likely to require notification, and why each decision was made, with dates. Article 35 turns on whether the competent authority informs the GDPR supervisory authority, so this log shows the reasoning behind that step. Assign an accountable owner for each entry.
Supervisory correspondence
Keep every communication with the NIS2 authority and the data protection authority, including information requests, inspection notices, binding instructions and any fine or decision. Article 35(2) bars a second Article 34 fine for the same conduct where a GDPR fine has been imposed, so the fine record for each regime must be easy to locate. Note which authority issued each document.
Asset and data inventory
Maintain the list of systems, network segments and personal data stores that the incident record links to. Include the data categories held and the processing purpose for each, so that the GDPR assessment and the NIS2 scope of affected systems can be tied to the same inventory. Review the inventory on a set schedule and after material system changes.
Currency between incidents
Run tabletop exercises that walk one simulated incident through both notification paths and produce the same artifacts. Review templates, contact lists and decision criteria after each exercise and after any change to supervisors or internal roles. Ask your implementation partner and your counsel to confirm which retention periods apply in your Member State, because the requirements for retaining records are set by national law and your own policies.
What it costs to be ready for a dual NIS2 and GDPR case
Legal counsel is usually the first external cost in a dual case. The work is to map when an incident can trigger an Article 23 report to the CSIRT or competent authority and when it can also trigger an Article 33 GDPR notification to the data protection authority, then to write the decision steps, the authority contacts and the sign-off rules that connect the two. Counsel is paid for this analysis and drafting, and the cost is one-time for the initial design, with periodic recurring review when national transposition rules, supervisory guidance or the entity's processing changes.
- Initial process design: counsel maps the reporting triggers, deadlines and recipients under both regimes for the entity's Member States.
- Template and playbook drafting: notification templates, decision logs and the rules for who approves each submission.
- Jurisdiction work: the cost rises with each Member State where the entity operates, because national transposition and supervisory practice can differ.
- Periodic review: a recurring cost tied to legal change and to material changes in processing systems.
- Scope of advice: ask whether the quote covers only the notification process or also the Article 35(2) interplay with fines.
Ask the firm to state in writing which jurisdictions, regulators and document types are covered, and whether revisions after a live incident are included.
Case records keep the facts that both regimes will ask for: what happened, which systems and personal data were involved, when each decision was taken, and who took it. Tooling can be a licensed platform, a self-hosted open-source case manager, or a combination. Costs split between the software or licence, the hosting in the entity's own infrastructure, integration with alert sources, and the staff time to administer it. DFIR-IRIS, an open-source case management tool, keeps each case as one record of assets, indicators of compromise, tasks and evidence with an audit trail, which is the kind of record a reviewer can follow across both notifications.
- Licence or software: for open-source tools, the cost is mainly hosting and administration; for commercial tools, ask for the licence model and renewal terms.
- Hosting and operations: compute, storage, backups and patching in the entity's own cloud account or data center, which recur every year.
- Integration work: connecting SIEM, EDR and other alert sources to cases is usually one-time per source, with upkeep when sources change.
- Retention and access control: configuring retention periods and role-based access to personal data within the case record.
- Administration: a recurring share of an analyst's or platform engineer's time.
Ask the implementer to confirm which alert sources are integrated in the quote and what the handover documentation includes.
Building the consolidated timeline is engineering work. Each incident needs a record of detection, containment, scope and notification decisions, and reviewers expect the times to be traceable to logs or system records. The effort depends on how many systems hold personal data, how well logging is centralized, and whether timestamps are synchronized. This is mostly a one-time build of templates, parsers and reporting views, followed by recurring effort each time the environment changes.
- Log source inventory: identifying which systems hold personal data and produce logs suitable for a timeline.
- Timeline templates and parsers: one-time build for the common event types and the notification milestones.
- Report generation: configuring reports from case data so that the same facts feed both the NIS2 and GDPR submissions.
- Environment changes: each new processing system or cloud region adds recurring integration work.
- Testing: exercises that prove a timeline can be produced under time pressure.
Illustrative example: an entity with a few systems holding personal data will usually need far less integration than one with dozens of systems across several cloud accounts. Ask the quote to state the number of systems in scope, the log sources assumed and the hours or days allocated to each.
Evidence has to be current when a supervisor or data protection authority asks for it. Upkeep covers keeping incident records complete, storing evidence with integrity checks, reviewing access to personal data in the case records, and retaining proof that the reporting process was tested. Most of this cost recurs, because evidence decays when systems change and when staff turn over. The cost depends on the number of incidents, the volume of logs retained and the number of teams that touch the reporting process.
- Record maintenance: recurring time to close cases, link evidence and keep the audit trail complete.
- Evidence integrity: verifying stored evidence, for example with hashes and chain-of-custody records, on a schedule.
- Access reviews: periodic checks of who can view personal data inside incident records.
- Exercise records: keeping the results of tabletop and technical exercises that show the process works.
- Retention and storage: recurring storage cost for logs and case evidence, set by the retention period the entity chooses.
Ask the provider to state which evidence items are delivered at handover and which must be kept current by the entity's own staff.
External review tests whether the design works before a real case. An independent assessor or security testing firm can review the process, run an exercise, or test the tooling. These firms are paid per engagement, and the cost is usually one-time for the initial review, with recurring reviews on a schedule or after material change. Only an independent auditor or assessor can issue a report on compliance; an implementation partner prepares the systems and evidence but does not issue them. Scope, number of exercises and number of jurisdictions are the main drivers.
- Process review: an independent check that the reporting steps match the legal analysis.
- Exercise facilitation: the cost of running a scenario that involves both an Article 23 report and a GDPR notification.
- Technical testing: security testing of the case tooling and the systems that feed it, scoped in writing.
- Repeat reviews: recurring work after changes to processing, tooling or law.
- Reporting format: ask whether findings are delivered as a written report with remediation tracking.
Request a written scope that names the reviewer, the deliverables and the dates, and confirm that the reviewer is independent of the team that built the process.
How DFIR-IRIS supports the single incident record
This table maps DFIR-IRIS capabilities to the evidence needs of one incident reported under both NIS2 and the GDPR. Read each row as a capability the team should confirm in its own environment, not as a compliance outcome, since the organization still decides what it reports and to whom.
| Need in a dual NIS2 and GDPR incident | What DFIR-IRIS provides | What to confirm before relying on it |
|---|---|---|
| One case for both notifications | Keeps one case record holding assets, indicators of compromise, tasks and evidence, with a full audit trail | Confirm the case fields your NIS2 and GDPR reports require are captured or exported |
| Alert intake | Triages alerts from SIEM, EDR and REST sources into cases for the same incident | Confirm connectors and alert formats match your monitoring stack |
| Consolidated timeline | Builds one investigation timeline that can show when the incident was detected and escalated | Confirm timestamps are synchronized and the timeline supports your reporting clock |
| Affected personal data records | Tracks affected assets and related tasks so data categories can be linked to systems | Confirm your data inventory is maintained separately and cross-referenced to the case |
| Evidence integrity | Logs evidence with SHA-256 verification and chain of custody | Confirm hashing and custody procedures meet your evidence handling policy |
| Report generation | Generates reports from case data for internal and external review | Confirm report templates match the content each authority expects, which your counsel should review |
| Role of the platform | Supports the evidence trail; it does not decide whether an incident is reportable | Assign the reporting decision to a named owner with documented criteria |
Who owns the notifications, the evidence and the decision
The entity owns every notification it makes under Article 23 of NIS2 and, where the same event involves personal data, every personal data breach notification under Article 33 of the GDPR. Those two filings describe the same facts to different authorities, so the entity has to keep them consistent. Management carries overall accountability, while legal, the data protection officer and the incident response team each handle a distinct part of the work.
- Management body: approves the incident response plan, sets who may sign filings, and accepts accountability for the decisions taken during an incident.
- Legal counsel: judges whether the event is significant under NIS2 and whether a GDPR breach is notifiable, and manages contact with authorities.
- Data protection officer: assesses the personal data impact, maintains the breach register and drafts the GDPR content for the supervisory authority.
- Incident response team: establishes the timeline, preserves evidence and supplies the technical facts that every filing relies on.
- Accuracy of filings: the entity remains responsible for the content of each submission, including any later correction.
Confirm with your counsel which national competent authority and which CSIRT receive your filings, since transposition laws differ by Member State.
An implementation partner such as DeployOpen prepares the systems that let the entity meet its deadlines and document its work. The partner builds and configures the tooling, writes the procedures for triage and evidence handling, and runs exercises that test whether the people involved can act on them. It does not decide whether an incident is reportable, does not sign any filing, and does not issue reports or decisions about compliance.
- Case tooling: deploys and configures self-hosted incident case management, such as DFIR-IRIS, in the client's own infrastructure, with access roles and audit logging set up.
- Timeline and evidence preparation: designs how alerts become cases, how evidence is logged with hashes and chain of custody, and how case data feeds the report drafts.
- Procedure documentation: writes the reporting runbook so that the organization's own staff know which template, approver and channel apply at each stage.
- Exercises: runs tabletop and technical exercises that rehearse a single incident under both NIS2 and GDPR reporting.
- Limits of the role: the partner's output is evidence for the entity and its assessors, not a statement of legal conclusions.
When you request a quote, ask for a written list of deliverables and state which decisions remain with your own staff.
Under Article 35(1), the competent authority that receives a NIS2 report must inform the GDPR supervisory authority when an Article 21 or 23 infringement can entail a notifiable personal data breach. The authority then decides on any fine. Under Article 35(2), if the data protection authority has already imposed a fine under Article 58(2)(i) GDPR for the same conduct, the NIS2 authority may not impose an Article 34 fine, although other enforcement measures remain open. Independent auditors or assessors may review the entity's controls and evidence, but they do not decide penalties.
- NIS2 competent authority: receives Article 23 reports, supervises the entity, and decides whether an Article 34 fine applies.
- GDPR supervisory authority: receives Article 33 notifications, assesses the breach, and decides whether an Article 58 fine applies.
- Independent reviewers: test controls and evidence in an assessment engagement and report their findings to the client, without deciding penalties.
- Coordination: authorities exchange information on the matter, so inconsistent statements in either filing can surface in both proceedings.
- Procedure: the national rules set how authorities cooperate and what appeal rights the entity has.
Confirm with counsel how your national authorities handle the referral and which party must make the first contact.
Where dual NIS2 and GDPR cases usually break down
A single incident can start two regulatory clocks: NIS2 reporting to the CSIRT or competent authority and a GDPR breach notification to the data protection authority. Most failures happen where those two tracks share facts but not owners, records or tests, so the gaps below are the ones to close before an incident.
Separate NIS2 and GDPR clocks
Teams often track the NIS2 reporting deadlines in the incident system and the GDPR 72-hour window in a privacy inbox or spreadsheet, so each clock starts from a different moment. Put both deadlines on one incident timeline with the time each was first known recorded beside it. Then check that the person on call can see both clocks in the same place.
Inconsistent breach facts
When the NIS2 report describes the affected systems one way and the GDPR notification describes them another, the authorities will ask why. Keep one controlled fact sheet for the incident, covering scope, systems, data categories, number of records and status, and draw both filings from it. Re-check the sheet each time a new fact emerges.
No record of the referral
Article 35(1) requires the competent authority to inform the GDPR supervisory authority when an infringement can entail a notifiable breach. If nobody records that the referral was made, when and on what basis, the organization cannot show what it disclosed. Log each referral, the recipient, the date and the content in the case record, and confirm with counsel how the national authority handles it.
Unclear CSIRT and DPO roles
The security team may assume the data protection officer owns the breach decision, while the DPO assumes the CSIRT does. Write a RACI for the dual case that names who drafts each filing, who approves it, who speaks to each authority and who records the decision. Confirm that the DPO is consulted before any statement about personal data leaves the organization.
Untested dual playbooks
Many incident response plans cover security or privacy alone, so the first real test of the joint process is a live breach. Run a tabletop exercise that starts with an event that is both a significant incident and a personal data breach, and time how long it takes to produce both filings. Record the gaps and assign owners for fixing them.
Questions buyers ask about Article 35
Does Article 35 mean an organization only gets one fine for one incident?
Not in every case, but it prevents a second NIS2 administrative fine for the same conduct when the data protection authority has already fined under Article 58(2)(i) GDPR. Under Article 35(2), the NIS2 authority may not impose an Article 34 fine for an infringement arising from that same conduct. It may still use other enforcement measures, such as warnings, binding instructions or compliance orders. The rule covers the same conduct, so an organization can still face separate proceedings if the NIS2 infringement and the GDPR infringement rest on different acts or omissions. Ask counsel to map each finding to its legal basis before assuming the rule applies.
Who notifies the data protection authority when a NIS2 incident involves personal data?
The NIS2 competent authority informs the GDPR supervisory authority, and the organization still has its own duty to notify. Under Article 35(1), when an infringement of Article 21 or 23 can entail a personal data breach notifiable under Article 33 GDPR, the competent authority must inform the data protection authority without undue delay. That does not replace the controller's obligation under Article 33 GDPR. In practice, the organization should send its NIS2 report to the CSIRT or competent authority under Article 23 and make its own personal data breach notification where the GDPR requires it. Confirm the notification route, timing and contact points with your national competent authority and your data protection authority.
What does the organization need to have ready before an incident?
The organization needs one incident record that can feed both reporting tracks. Essential groundwork includes a documented response plan, a classification step that flags possible personal data involvement, named owners for NIS2 and GDPR decisions, and templates for the early warning, notification and final report. Evidence should show what happened, which systems and data were affected, when each fact was known, and who approved each submission. A case management platform helps keep assets, indicators of compromise, tasks, evidence and the timeline in one place with an audit trail. Test the process in an exercise so the first live use is not the first test.
Can an organization handle NIS2 and GDPR incident reporting in-house?
Yes, if it has staff who understand both regimes and the capacity to run an incident around the clock. Many organizations keep decision-making in-house, including the legal basis for each report and the final sign-off, because the management body remains accountable for compliance. Work that can be outsourced includes building the response plan, configuring case management tooling, writing report templates and running tabletop exercises. Outside help may also cover monitoring or after-hours triage through a managed service. Whatever you choose, document who owns each reporting decision, because a regulator will ask.
How long does preparing for Article 35 reporting take?
The time depends on how many systems, data stores and reporting routes are in scope, and on how mature the existing incident process already is. An organization with a tested incident response plan and a single case record process needs less work than one that must join SIEM, EDR and ticketing data, build reporting templates for two regulators and train several teams. No duration is set by NIS2 or the GDPR for this preparation, so ask any implementation partner for a timeline based on a written scope that lists systems, data categories, reporting routes and exercise dates. Confirm any deadline that applies to your entity with your national authority.
What does the work cost, and what drives the price up?
Cost comes from people, tooling and exercises, and most of it is one-time setup followed by recurring operation. Internal staff time for policy, training and exercises is a cost even when no vendor is paid. External costs may include an implementation partner for setup, licensing or hosting for the case platform, and ongoing support or monitoring. The main drivers are the number of log sources and assets, the number of reporting regimes and member states involved, the maturity of existing processes, and how often exercises are run. When requesting a quote, ask for line items separating one-time setup, recurring support and internal effort, and state which regulator reports the scope covers. No public figure for this work is established here, so compare quotes against the same written scope.
What should we confirm with the national authority before relying on Article 35?
Confirm how your Member State has transposed NIS2 and which authority receives your reports. Ask the national competent authority which CSIRT or authority you report to, what early warning and notification forms it accepts, and how it shares information with the data protection authority under Article 35(1). Ask the data protection authority how it handles personal data breach notifications linked to a NIS2 report and whether it expects a joint or separate submission. Also confirm whether any sector-specific law displaces parts of NIS2 for your entity. Record every answer in writing, because a later fine decision will depend on what you disclosed and when.
Does using open-source incident tooling help with the evidence?
It can, provided the tool keeps the evidence your reporting needs. DFIR-IRIS, an open-source incident response platform under the LGPL-3.0-or-later license, keeps each case as one record of assets, indicators of compromise, tasks and evidence, with a full audit trail. It can triage alerts from SIEM, EDR and REST sources into cases, build a consolidated investigation timeline, log evidence with SHA-256 verification and chain of custody, and generate reports from case data. Confirm the exact features and deployment model against the DFIR-IRIS documentation before you rely on them, and test that the reports contain the fields both regulators will ask for.
How DeployOpen prepares dual-regime incident records
DeployOpen helps organizations set up one incident record that serves both NIS2 reporting under Article 23 and GDPR breach assessment under Article 33. The organization owns its decisions on reporting and fines, while DeployOpen prepares the self-hosted systems and evidence that support them.
How we scope
- The written scope names which NIS2 and GDPR notification paths the record must support, agreed before work starts.
- Scope lists the systems that feed incidents, such as SIEM, EDR and ticketing sources, deployed in your own environment.
- Scope states who owns each decision, including the NIS2 authority contact and the GDPR supervisory authority contact.
How we build
- We deploy DFIR-IRIS in your infrastructure and configure case templates for NIS2 and GDPR reporting fields.
- We connect alert sources so triage creates cases with a consolidated investigation timeline for each incident.
- We configure evidence logging with SHA-256 verification and chain of custody so records hold up if an authority asks.
How we hand over
- Handover includes configuration documentation, runbooks for opening and closing a dual-regime case, and an operator walkthrough.
- We document how report generation from case data maps to the reporting fields your legal team must complete.
- Your staff run a test case end to end so you can confirm the record and audit trail behave as documented.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer support can cover platform upgrades and updates to templates when your reporting obligations change.
- Confirm with your counsel and data protection officer that the record design fits your authorities and procedures.
