Incident Response Plan for GDPR and NIS2 Compliance

An incident response plan is the documented process an organisation uses to detect, assess, contain, report and recover from a cyber incident.

It is what turns an uncertain security alert into coordinated action. It is why the controller can assess a personal data breach before the CNIL notification deadline expires. It is how an essential or important entity prepares for the staged reporting duties under NIS2. It is what keeps technical containment, legal decisions, business continuity and public communication aligned when reliable information is still limited.

At 8:15 a.m., a French company discovers that ransomware has locked its customer portal, internal file servers and employee records. The attackers claim that they copied personal data before encryption. Technical teams are trying to contain the intrusion while the DPO is calculating the GDPR deadline, management is assessing service disruption, and legal advisers are deciding whether the event may also fall under NIS2.

In this blog, you will learn how to build an incident response plan France organisations can use for GDPR and NIS2 compliance, including the response workflow, reporting timelines, roles, severity levels, communication rules, documentation requirements, testing methods and a copyable plan template.

What Is an Incident Response Plan?

An incident response plan defines how an organisation prepares for and manages events that threaten the confidentiality, integrity, availability or authenticity of its systems, services and information. It explains how employees report suspicious activity, who confirms that an incident exists, how the event is classified, which containment actions are authorised and who decides whether regulators, customers or affected individuals must be informed.

The plan is broader than a technical playbook. A ransomware playbook may tell analysts how to isolate infected devices, block malicious infrastructure and restore clean backups. The incident response plan coordinates that work with privacy assessment, legal review, supplier management, business continuity, executive decisions and communications.

A strong plan should answer six questions without forcing the response team to search through a lengthy policy: What happened? What is affected? Who is leading? What must happen next? Which reporting clocks have started? What evidence supports each decision?

The need for this discipline is increasing. The CNIL received 6,167 personal data breach notifications in 2025, and one in two notified incidents involved hacking. The authority also stated that supplier involvement was a recurring feature of major breaches.

Why GDPR and NIS2 Require Incident Response Planning

GDPR and NIS2 do not require every organisation to use a document with this exact title, but their duties make an organised response process necessary.

Under Article 32 of GDPR, controllers and processors must apply security measures appropriate to risk, including restoration capability and regular testing. Articles 33 and 34 require breach assessment, documentation, supervisory authority notification and, when high risk exists, communication to affected people. Those duties depend on pre-assigned roles and fast access to reliable information. The legal text is available in the General Data Protection Regulation.

NIS2 has a wider operational focus. Article 21 covers incident handling, continuity, crisis management, backup, recovery, supply-chain security and testing. Article 23 establishes staged reporting for significant incidents, while management bodies must approve and oversee cybersecurity risk measures. The full requirements appear in the NIS2 Directive.

For France, timing matters. As of 3 August 2026, ANSSI still described national NIS2 transposition as ongoing, and ReCyF remained a working document. Organisations should prepare against the directive while checking final French legislation, thresholds, authority procedures and reporting tools as they are adopted.

GDPR and NIS2 Requirements: What Is the Difference?

A single attack can trigger GDPR, NIS2, both regimes or neither notification duty. The response team must apply each legal test separately.

A GDPR personal data breach is a security breach that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of or access to personal data. The key question is the risk created for individuals’ rights and freedoms. A breach can concern confidentiality, integrity or availability. Ransomware can therefore become a GDPR breach even when there is no confirmed extraction if personal data is unavailable and that loss of availability creates risk.

A significant NIS2 incident is assessed by its effect on the services of an essential or important entity. It is significant if it has caused or can cause severe operational disruption or financial loss for the entity, or if it has affected or can affect other people or organisations through considerable material or non-material damage. Personal data does not need to be involved.

The distinction matters during a cyber incident. A misdirected email containing employee salary data may require GDPR assessment but is unlikely to become a significant NIS2 incident. A denial-of-service attack that stops a critical digital service may trigger NIS2 reporting even when personal data remains protected. Ransomware that exposes customer records and disrupts essential operations may trigger both.

The Incident Response Workflow

The workflow should be simple enough to follow under pressure and detailed enough to preserve accountability.

Preparation establishes roles, contacts, tools and decision authority. Detection identifies suspicious behaviour through monitoring, employee reports, supplier notifications or customer complaints. Internal escalation brings the event to the incident manager and relevant specialists. Triage establishes what is known, what is affected and whether the event is still active.

Severity classification determines the response level. Containment limits further harm while preserving evidence. Regulatory assessment runs in parallel with technical work, not after it. Notification is completed when the relevant legal threshold is met. Eradication removes malicious access and underlying weaknesses. Recovery restores systems in a controlled order. Review identifies root causes and assigns corrective actions.

A common error is treating notification as the final step after forensic work. The GDPR and NIS2 clocks can expire while the investigation is still active. The plan must permit an initial report based on confirmed facts and clearly identified gaps.

What Should an Incident Response Plan Include?

The plan should begin with its purpose, scope, owner, approval authority and review date. Scope should identify covered entities, systems, services, personal data processing and critical suppliers. Definitions should separate a security event, cyber incident, personal data breach, significant NIS2 incident and business crisis.

Activation criteria should explain who can declare an incident, when specialists join and when executive crisis management is required. A protected contact directory should include primary and alternate role holders because ransomware or identity compromise may make normal systems unavailable.

The remaining content should cover severity, escalation, containment authority, GDPR and NIS2 decision paths, evidence, supplier coordination, communications, recovery approval and post-incident review. Detailed playbooks can support common scenarios such as ransomware, account compromise, data leakage, denial-of-service attacks and supplier breaches.

How to Build an Incident Response Plan for GDPR and NIS2

1. Establish Scope and Legal Applicability

Start by identifying the legal entities, services, systems and processing activities that the plan covers. Record where personal data is stored, which services are critical, which countries are affected and which third parties operate key technology.

Determine which entity acts as controller or processor, whether NIS2 may apply and whether sector rules or contracts add further reporting duties. Produce an applicability matrix connecting each service to its authority and internal decision owner.

2. Map Critical Systems, Data and Dependencies

The response team cannot assess impact quickly without knowing what the affected asset supports. Build a current inventory connecting systems to business services, information owners, personal data categories, recovery priorities and suppliers.

Connect important applications to business services, data owners, recovery priorities and suppliers. Include shared identity, remote access, cloud and managed-service dependencies that could spread impact across several services.

3. Appoint the Response Team and Decision Owners

Assign the incident commander before an incident occurs. This role coordinates priorities, meetings, decisions and handovers but does not need to perform every technical task.

Assign technical, privacy, legal, operations, business, communications and executive responsibilities, with an alternate for each role. State who can isolate systems, disable accounts, activate continuity and submit notifications.

4. Create Severity and Escalation Rules

Severity should reflect technical, operational, privacy and public impact. A four-level model is usually sufficient.

Allow reclassification whenever new evidence changes the impact.

5. Design Detection and Internal Reporting

Employees, contractors and suppliers need a clear route for reporting suspicious activity. The route must continue to function when corporate email or collaboration tools are unavailable.

Capture the reporter, time, affected asset, observed behaviour and actions already taken. Tell employees not to delete evidence, investigate independently or contact an attacker. Combine monitoring alerts with reports from staff, suppliers and customers.

6. Prepare Containment, Evidence and Recovery Procedures

Containment authority must be agreed in advance. Security teams may need to disable accounts, isolate endpoints, block domains, restrict remote access or segment a network before senior executives can meet.

Preserve logs, forensic images, malicious messages, cloud audit records and decision logs with clear custody records. ReCyF emphasises technical records, crisis organisation, continuity, recovery, communications and exercises. Recovery must also verify that the entry point, compromised credentials and attacker persistence have been addressed before production resumes.

7. Build GDPR and NIS2 Decision Paths

Create separate assessment forms for GDPR and NIS2. The GDPR form should capture affected data, people, record volumes, sensitivity, protection measures, likely consequences and risk level. The NIS2 form should capture service disruption, duration, affected users, financial impact, cross-border reach, wider harm and indicators of compromise.

Record awareness time, evidence, conclusion, approver and notification status. Keep the legal tests separate even when both decisions appear on one dashboard.

8. Prepare Communication and Notification Templates

Draft templates before a crisis for the CNIL, NIS2 authority, affected individuals, employees, customers, suppliers and media. Templates should include placeholders for confirmed facts, affected services or data, likely consequences, containment measures, contact details and protective actions.

Separate confirmed facts from matters under investigation. Do not deny data access or promise recovery dates without supporting evidence.

Professionals responsible for building these procedures can strengthen their capability through the Cybersecurity Incident Response Training, which covers incident detection, escalation, containment, evidence, communication, regulatory duties and recovery.

GDPR Breach Notification Process and the CNIL 72-Hour Rule

The GDPR process begins when the organisation identifies a security incident that may have affected personal data. The controller should establish whether a breach occurred, when it became aware, what data and people are involved and what risks may follow.

A controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware when the personal data breach is likely to result in a risk to people’s rights and freedoms. If the report is late, the controller must explain the delay. A processor must notify the controller without undue delay after becoming aware.

The notification must describe the nature of the breach, including available categories and approximate numbers of affected people and records. It must provide the DPO or contact point, likely consequences, and measures taken or proposed to address and mitigate the breach. When all information is not available at once, GDPR permits it to be supplied in phases without undue further delay.

In France, notifications are submitted through the CNIL personal data breach notification service. The CNIL advises organisations not to wait for complete information when a breach is already established. An initial notification can be submitted within the deadline and supplemented later.

The controller must also communicate the breach to affected individuals without undue delay when it is likely to create a high risk, unless an applicable exception removes that requirement. The message should use clear language and explain the nature of the breach, contact details, likely consequences and measures taken.

Every personal data breach must be documented internally, including those not notified to the CNIL. The record should contain the facts, effects, risk analysis, decision, remedial action and supporting evidence. The CNIL guidance on managing incidents and breaches is a useful reference for designing this process.

NIS2 Incident Reporting Timeline

NIS2 reporting applies to a significant incident affecting an essential or important entity. The Article 23 test asks whether the incident has caused or can cause severe operational disruption or financial loss, or whether it has caused or can cause considerable material or non-material damage to other people or organisations.

The directive makes clear that reporting should not divert resources from urgent incident handling. That principle does not remove the deadline. It means the organisation should prepare concise reports, assign a separate notification owner and avoid forcing investigators to stop containment work to build a polished narrative.

ENISA summarises the NIS2 sequence as a 24-hour early warning followed by a 72-hour incident notification to the relevant national authority or CSIRT.

French entities should follow the latest instructions on the ANSSI NIS2 information page and verify the final national reporting process once the complete transposition package is in force.

Roles and Responsibilities During a Cyber Incident

The incident commander controls priorities, meetings, handovers and the incident log. The CISO or security lead directs investigation, containment and monitoring. IT operations implements system changes and recovery. The DPO assesses personal data impact and advises on CNIL notification. Legal counsel reviews overlapping duties, contracts and law-enforcement contact.

A data response team, or DRT, can support the DPO by mapping affected datasets, processors and people. Business owners set recovery priorities, communications manages stakeholder messages, supplier management obtains evidence from providers, and senior management approves major operational or public decisions.

NIS2 strengthens this governance dimension by requiring management bodies of essential and important entities to approve cybersecurity risk measures and oversee implementation. Incident readiness is therefore a management responsibility, not only a technical function.

Communication and Documentation Rules

Internal messages should identify safe systems, suspended activities, reporting routes and authorised spokespeople. Backup channels are necessary when email, identity or collaboration platforms are compromised.

External messages must fit the audience. Regulators need required facts, affected individuals need clear risk and protective actions, and customers need accurate service information. Public statements should avoid speculation, unsupported attribution and premature claims that data is safe.

The incident log should record detection, escalation, awareness, containment, affected assets, approvals, notifications, evidence, recovery and corrective actions. Supplier contracts should require rapid reporting, named contacts, cooperation and access to relevant evidence. A processor’s notice does not replace the controller’s GDPR assessment, and the CNIL reported that service providers were often involved in major 2025 breaches.

How to Test the Incident Response Plan

Tabletop exercises allow decision-makers to work through a developing incident without touching live systems. Technical simulations test detection, isolation, evidence and recovery, while communication exercises test regulatory drafting and backup channels.

A useful exercise can begin with supplier account compromise, add suspicious data transfers and a portal outage, then introduce an attacker’s public claim. Participants must decide when to declare the incident, whether GDPR or NIS2 applies and what must be reported.

Measure time to detect, escalate, classify, contain and prepare notifications. Check contacts, authority, evidence access, backup communications and recovery priorities. Every finding needs an owner, deadline and verification method. ReCyF includes crisis response and exercises, while ISO/IEC 27035 covers preparation, detection, reporting, assessment, response and lessons learned.

Common Incident Response Plan Mistakes

The most damaging mistake is writing the plan only for IT. Technical teams cannot decide CNIL notification, customer communication, contractual reporting or business continuity alone.

Other failures include waiting for complete forensic certainty, leaving isolation and notification authority unclear, relying on one communication system, accepting vague supplier reporting periods, restoring backups without removing persistence and closing the incident without tracked corrective actions. GDPR and NIS2 permit staged reporting, so an unfinished investigation is not a reason to ignore a deadline once enough facts are known.

How ISO 27001 Supports GDPR and NIS2 Incident Management

ISO/IEC 27001 supports incident readiness by requiring an organisation to establish, operate, monitor and continually improve an information security management system based on risk. Its broader management approach helps connect policies, responsibilities, asset knowledge, supplier controls, monitoring, continuity and corrective action. The official ISO/IEC 27001 overview explains that the standard is designed to preserve confidentiality, integrity and availability through a managed risk process.

ISO/IEC 27035 is more directly focused on incident management. It covers preparing for, detecting, reporting, assessing and responding to incidents, followed by lessons learned. Organisations can use the ISO/IEC 27035-1 incident-management process to strengthen the operational detail supporting an ISO/IEC 27001 information security management system.

Certification to ISO/IEC 27001 does not automatically prove GDPR or NIS2 compliance. The standard can provide organised controls and evidence, but the organisation must still apply the legal definitions, thresholds, deadlines and national procedures relevant to each incident.

Conclusion

An effective incident response plan gives a French organisation control over the first hours of a cyber incident. It identifies who leads, what must be protected, how severity is determined, which evidence must be retained and when GDPR, CNIL or NIS2 reporting may be required.

The most important design choice is to connect technical response with legal and operational decisions from the beginning. GDPR assessment cannot wait until systems are restored. NIS2 significance cannot be judged only by whether personal data was stolen. Supplier involvement does not remove the organisation’s own responsibilities.

Build the plan around short decision paths, named authority, separate GDPR and NIS2 assessments, tested backup communications and staged notification templates. Then test it under realistic pressure and convert every weakness into a tracked improvement. That is how incident response becomes a repeatable compliance capability rather than a document opened for the first time during a crisis.