GDPR incident response plan: the 72-hour process

GDPR incident response plan: how the 72-hour process works

The controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless the breach is unlikely to result in a risk to individuals. If the notice goes out later, it must explain the reasons for the delay. The first notice may be incomplete, because information can follow in phases without undue further delay where not everything is known at the start. Your plan should be built around that deadline, not around the hope that the full picture will be clear within it. Recital 87 expects you to have appropriate technological and organisational measures in place to establish immediately whether a breach has happened, and to inform the authority and affected people promptly. A plan that depends on someone noticing an alert days later does not meet that expectation. The shape of the plan depends on your role, size, systems and the number of EU countries affected. A controller decides whether to notify and what to say. A processor must inform its controller without undue delay and does not have to judge the likelihood of risk first, which the EDPB's Guidelines 9/2022 leave to the controller. Your plan should name who in your organization owns each decision, including the person who can declare the incident, the decision-maker on notification, and the DPO or contact point named in the notice. Your organization owns the plan, its decisions and the notification. An implementation partner can prepare runbooks, logging and alerting configuration, and evidence templates, but only the supervisory authority receives the notification itself. The clock question is the one most teams get wrong. EDPB Guidelines 9/2022 treat a controller as aware once it has a reasonable degree of certainty that a security incident has occurred and has led to personal data being compromised. Write down, in your plan, the events that start that assessment, such as a confirmed exfiltration alert or a processor's notice, and the time from which you will count. Then confirm with your DPO and legal counsel how your organization records that time, because the authority will ask when awareness began. The EDPB's common breach notification template, adopted for public consultation on 10 June 2026, is a useful reference for the fields your first notice must cover.

When the 72-hour clock starts and how to prove it

This sequence turns a first alert into a dated record that shows when the controller became aware of a breach, which is the moment the 72-hour window under Article 33 starts. Each step leaves a timestamped output that an assessor or supervisory authority can check against the notification.

Log the initial alert with a timestamp
The security operations team or whoever first receives a signal from monitoring, a user report, a processor notice or an external party records the alert in the incident system as it arrives. The entry captures the source, the time received, the person who received it and the systems involved. Do not wait for analysis before logging. The output is an incident ticket with an immutable creation time, which becomes the first entry in the breach timeline and the starting point for every later question about when the organization knew.
Triage the alert against defined severity criteria
The incident responder or on-call lead decides whether the alert is a genuine security incident or a false positive, using written criteria agreed in the response plan. The triage notes state what was checked, who reviewed it and the time the review finished. Triage is about understanding the event quickly, not about deciding whether notification is needed. The output is a triage record that either closes the alert with reasons or escalates it to the incident lead, with each decision time-stamped.
Confirm whether personal data was compromised
The incident lead, supported by the DPO or privacy lead and the system owners, establishes which systems were affected and whether they hold personal data. Logs, access records and data inventories are used to determine if personal data was accessed, altered, lost or disclosed without authorization. Where the answer is not yet known, the team records what is still unknown and the steps taken to find out. The output is a written finding stating what personal data may be involved, dated and signed off by the lead.
Establish the point of reasonable certainty
The incident lead and DPO decide when the organization has a reasonable degree of certainty that a security incident has occurred and that it has led to personal data being compromised. EDPB Guidelines 9/2022 use this test to mark awareness, so the decision cannot be left to an informal conversation. The decision memo states the evidence relied on, the time the certainty was reached and the people who agreed. The output is a signed awareness determination that fixes the start of the 72-hour period as a documented timestamp.
Record the clock start and the notification deadline
The incident lead enters the awareness timestamp in the breach register and calculates the 72-hour deadline from it, noting that notification is due without undue delay and no later than 72 hours after awareness where feasible. A short period of triage before certainty is reached does not pause this clock once awareness exists, so the record must show any gap between first alert and awareness and why it occurred. The output is a register entry showing both timestamps and the deadline, visible to everyone on the response team.
Document the timeline as the response proceeds
The scribe keeps a running timeline of actions, decisions, communications and changes to the scope of the breach, each entry timestamped and attributed. Entries are added as events happen rather than reconstructed later, because an authority reviewing a late notification will ask what was known at each point. The output is a complete, time-ordered incident log that can be exported with the notification and the internal breach record, showing how the organization moved from alert to awareness to notification.
Retain the timeline as evidence for the authority
The DPO or legal lead reviews the timeline and confirms it is consistent with system logs, ticket histories and communications. Any delay between awareness and notification is explained with reasons, as Article 33(1) requires for late notifications. Logs and records are preserved under the organization's retention and legal hold procedures. The output is a reviewed, locked timeline package stored with the breach file, ready to support the notification or to show an assessor why no notification was needed.

What the first notification must contain

Article 33(3) sets four content areas that the notification to the supervisory authority must address. The first notice often goes out before facts are settled, so the plan should pre-assign who drafts each area and which gaps can be filled later in phases.

Nature of the breach

Describe what happened in plain terms: confidentiality, integrity or availability loss, and the system or process involved. Where possible, state the categories of data subjects (for example, customers or employees) and personal data records affected, with approximate numbers. Say when the breach began and when it was found. Avoid guessing exact counts in the first notice. Give a reasoned estimate and label it as provisional so the team can refine it later.

DPO or contact point

Name the data protection officer or another contact point with working details that the authority can reach during the 72-hour window. If your organization has no DPO, name the person who will answer follow-up questions. Confirm that the contact is staffed outside business hours, since the clock keeps running over weekends. A generic mailbox that nobody checks on a Friday night will delay the reply that the authority needs.

Likely consequences

Explain the probable effects on individuals, such as identity theft risk, financial loss, discrimination, loss of confidentiality of sensitive data, or inability to access services. Base this on the data types and the attacker's likely use, not on the most optimistic view. The consequences section is where a weak first assessment shows up, so the risk analysis behind it should be written down and kept with the breach record.

Measures taken or proposed

List containment steps already taken, such as isolating accounts, revoking keys or blocking an endpoint, along with remedial steps proposed to address the breach and reduce its effects. Include any measures to mitigate possible adverse effects on individuals. Keep the list current with the incident log so the phased follow-up does not contradict the first notice. Vague wording like "we are investigating" does not meet the requirement without specific actions.

Phased information under Article 33(4)

If all information cannot be given at once, Article 33(4) allows phased notification without undue further delay. Send what is known within the window and state which items are still under investigation, with a date for the next update. Use the EDPB's common breach notification template, adopted on 10 June 2026 for public consultation, to check that the notice covers each Article 33(3) area. Run the template check before sending, and keep a copy of each phase.

What processors must do and how contracts should reflect it

A processor must notify the controller without undue delay after becoming aware of a personal data breach. The processor does not need to assess whether the breach is likely to result in a risk to individuals; that assessment belongs to the controller. Under EDPB Guidelines 9/2022, the controller is in principle considered aware once the processor has informed it. That means the processor's notice is the event that starts your 72-hour clock, so a slow processor notice shortens the time you have to investigate, decide and notify the supervisory authority. Your incident plan should assume the clock may start the moment a processor's engineer or support desk recognizes the incident, not when the processor's own report reaches your mailbox.

Processor contracts, including any data processing agreement built on the clauses in Commission Implementing Decision (EU) 2021/915, should state how quickly the processor must notify you, through which channel, and to which named contact. They should also set out the processor's duty to cooperate, including providing the facts you need for the Article 33(3) content, updating you as the investigation develops so information can follow in phases, and assisting with notices to affected people. Ask each processor to confirm in writing what its notice period is, whether it is expressed in hours or as "without undue delay," and who makes the call when the processor is unsure whether an event is a breach. Where the contract is silent or vague, treat that as a gap to close before an incident, not during one.

Check every notice period against your own 72-hour deadline. Work backward: if your internal triage, risk assessment and notification drafting need a set number of hours, the processor's notice must arrive well before that point, with enough margin for the processor's own investigation. Record the result in your breach register and your supplier list, and re-test it when a processor adds sub-processors, changes its hosting or revises its support model. The contract cannot shift your legal responsibility to the processor, so the practical test is simple: could you meet the deadline if the processor's notice arrived at the latest time the contract allows?

Who does what during a breach: your team, a partner and the authority

The controller owns the breach response and its legal consequences, so the internal team makes every notification decision and signs off on what leaves the organization. The clock under Article 33(1) runs from the moment the controller becomes aware, and the team must be able to assemble facts quickly enough to meet it. Named roles should be agreed in advance, with deputies for absence.

Incident lead: coordinates triage, keeps the timeline and decides when the 72-hour clock is treated as started.
Data protection officer: advises on the notification decision, owns the breach register and is the contact point named in the notice where one is designated.
Legal counsel: reviews the notification wording, privilege and contractual duties to customers and processors.
Communications lead: prepares any message to affected people under Article 34 and handles press and staff queries.
Technical responders: contain the incident, establish what data was affected and record the causes and remedial action.

Confirm with your own legal team which person may submit a notice to the authority and who has authority to instruct a partner.

Documenting every breach, including the ones you do not notify

Every personal data breach must be documented, whether or not it is notified to the supervisory authority or the affected people. EDPB Guidelines 9/2022 say so directly and encourage the controller to keep an internal breach register. For a 72-hour plan, this means the incident record is opened at the moment the controller becomes aware, not after a decision to notify has been made. A breach judged unlikely to result in a risk to individuals still gets an entry, with the reasons for that judgment written down.

The EDPB guidelines expect each record to cover the causes of the breach, what happened, the personal data affected, the effects, and the remedial action taken. In practice, the responders should capture the affected systems and data categories as the investigation finds them, the timeline of detection and containment, the decisions taken and by whom, and the controls changed afterwards. Confirm with your DPO or legal team which fields your register must hold and where it lives, and restrict edit rights so the record stays credible under review.

Article 33(5) requires the controller to document the breach, its effects and the remedial action so the supervisory authority can verify compliance with Article 33. When an authority asks why no notice was given for a given incident, the register is the answer: it should show the risk assessment, the reasoning and the date of each decision. Review the register at regular intervals to spot repeated causes, which is the evidence regulators look for when judging whether the security measures under Article 32 are appropriate.

What must be in place before an incident happens

The 72-hour clock starts when the controller becomes aware of a breach, so most of the work happens before any incident. The six items below are the pieces that let a team detect, decide, notify and document quickly. Each one can be checked with a tabletop exercise or a review of the evidence the organization already holds.

A written plan with named roles

The plan should name who declares an incident, who decides on notification, who speaks to the supervisory authority and who signs off the record. Each role needs a named person and a deputy, not a team mailbox. In a tabletop exercise, give the team a scenario and time how long it takes to reach a notification decision. A plan that nobody can find at 2 a.m. has not been tested.

Detection and logging that show awareness

Recital 87 expects measures that establish immediately whether a breach has happened. Logs for identity systems, endpoints, databases and file shares must be retained and searchable, or the team cannot tell when it became aware. Check this by picking a sample alert and tracing whether the logs can show what was accessed, by whom and when.

A tested contact list for DPO and legal

The DPO's details must appear in the notification, so the contact list must hold current phone numbers, out-of-hours routes and a legal adviser who can be reached quickly. Call every number during an exercise and confirm that someone answers within the time the plan allows. Stale contacts are one of the most common reasons decisions slip.

Pre-drafted notification fields

Article 33(3) requires the nature of the breach, likely consequences, measures taken or proposed, and contact details. Prepare a draft with those headings, plus fields for categories and approximate numbers of data subjects and records. Use the EDPB common template once it is final, and confirm which format your supervisory authority accepts. In the exercise, check that a draft can be filled in with partial facts.

Processor contacts and notice terms

A processor does not assess risk before notifying, and the controller is treated as aware once the processor has informed it. Keep a list of every processor, its 24-hour contact route and the notice period written into its contract. Review those contract clauses and confirm the processor's incident contact is included in the exercise.

A breach register template

EDPB Guidelines 9/2022 expect every breach to be documented, whether or not it is notifiable, with causes, facts, personal data affected, effects and remedial action. Set up a register with those fields before an incident. To check it, open the register and confirm that a recent near miss, or an exercise scenario, has a complete entry with a decision and its reasons.

Frequently asked questions about the GDPR 72-hour process

Does the 72-hour clock start at detection or at confirmation?

The clock starts when the controller becomes aware of the breach, not when someone first notices an alert. The EDPB's Guidelines 9/2022 treat the controller as aware once it has a reasonable degree of certainty that a security incident has occurred and personal data has been compromised. Recital 87 expects the organization to have the technical and organizational measures in place to establish quickly whether a breach has happened, so a slow internal triage is not a reason to delay. Build your plan so that triage has a time limit, a named owner and a written record of when awareness was reached. Ask your counsel to confirm how your supervisory authority applies this test in practice.

What happens if the 72 hours pass without a notification?

A notification sent after 72 hours is not automatically a violation, but it must be accompanied by reasons for the delay under Article 33(1). The notification should still be made without undue delay once the facts are clear enough to report. The reasons you give should be specific, such as the time needed to confirm scope or to recover logs, and they should match what your breach register shows. Regulators assess the delay together with the quality of your detection and response process, so a documented timeline is your strongest defense. Late notification combined with missing records is the pattern most likely to draw scrutiny.

Can we notify the supervisory authority in phases?

Yes. Article 33(4) allows information to be provided in phases when it is not possible to give everything at the same time, provided the phases follow without undue further delay. The first notice should describe the nature of the breach, the approximate categories and numbers of people and records where known, the contact point, the likely consequences and the measures taken or proposed. Details still under investigation can follow in later updates. Your plan should therefore include a template for the initial notice and a schedule for follow-up reports. The EDPB adopted a common breach notification template for public consultation on 10 June 2026, which offers predefined options to help make sure Article 33 content is covered.

Can a processor notify the authority on our behalf?

A processor must inform the controller, but the controller is the party that notifies the authority. According to EDPB Guidelines 9/2022, the processor does not need to assess the likelihood of risk before it informs the controller, and the controller is in principle considered aware once the processor has told it. Your processing contracts should set the processor's notice duty in advance, including a short contractual deadline, the information the processor must supply and a named contact. Some organizations also agree that a processor may send a notice under their instruction, but the legal responsibility stays with the controller. Confirm the arrangement with your legal team and check the standard contractual clauses or your own data processing agreement.

Do we have to record breaches that are too small to report?

Yes. The EDPB's Guidelines 9/2022 say every personal data breach must be documented whether or not it is notifiable. The internal breach register should record the facts of each case, including its causes, what happened, the personal data affected, the effects and the remedial action taken, along with the reasoning for deciding not to notify. Keeping these records is what allows you to show a supervisory authority that you assessed the event properly. Small incidents are also useful for spotting patterns, such as repeated misdirected emails, that may later amount to a notifiable breach. Ask your DPO or privacy lead to define a minimum set of fields so records are consistent across teams.

How much effort does a breach response plan take to build, and what does it need from our team?

The effort depends mainly on the size and number of systems that hold personal data, how many teams and processors are involved, and how much of the detection and logging stack already exists. The work usually includes mapping where personal data sits, agreeing roles across security, legal, privacy and communications, writing notice templates, setting up a breach register, and running at least one tabletop exercise. Your internal team must own decisions about scope, risk assessment and sign-off, which cannot be delegated to an outside party. Ask any provider for a written scope listing deliverables, the staff time expected from your side and the systems they will need access to. Obtain estimates for both one-time build work and recurring exercises and reviews.

Can an outside partner run the breach process for us?

An outside partner can prepare the systems, plans and evidence, but it cannot make the controller's decisions or notify on the controller's behalf as an accountable owner. DeployOpen plans, implements and documents self-hosted open-source platforms inside a client's own infrastructure, runs security testing and private cyber ranges, and prepares systems and evidence for compliance assessments. It does not issue audit reports or certifications, and it does not replace your DPO or your legal decision-makers. A practical split is that the partner helps build the logging, runbooks and register, runs rehearsals in a cyber range, and supports the response technically, while your organization decides on notification. Engagements are usually fixed-scope, with scope and timelines agreed in writing before work begins.

How DeployOpen works on this

DeployOpen plans and builds the technical side of a GDPR breach response plan inside your own infrastructure, so detection, logging and evidence collection support the 72-hour clock. Your organization owns the decisions, the notification and the legal judgment, and we prepare the systems, runbooks and records that make those decisions possible.

How we scope

Written scope names the systems, data stores and processors covered by the breach response plan before work starts.
Scope sets out which runbooks, notification templates and breach register fields will be delivered, agreed in writing.
Engagements are fixed-scope, so deliverables and timelines for the response plan are confirmed before any build begins.

How we build

We configure logging and alerting on self-hosted platforms so suspected breaches are surfaced and time-stamped promptly.
We draft a runbook that tracks awareness, assessment, notification and phased follow-up steps with named owners.
We set up an internal breach register structure capturing causes, affected personal data, effects and remedial action for every incident.

How we hand over

We run a tabletop exercise against the runbook so your team can test the 72-hour process end to end.
We document the plan, templates and register so your DPO and security staff can operate them without us.
We hand over system configurations, procedures and evidence in a form your independent auditor or supervisory authority can review.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so the plan stays current with your platforms.
We can review the runbook and register after changes to processors, sub-processors or hosting locations.
Your legal and DPO team remain responsible for notification decisions, and we confirm what your environment can evidence, not whether a notice is required.