How to Handle a Customer-Impacting Incident Under GDPR and SOC 2
The database exposed a set of user records for 14 minutes before the fix. Now legal is in the channel asking whether this triggers GDPR notification. The security lead is asking whether the timeline is complete enough for the SOC 2 evidence file. The commander is trying to keep the response moving. This is where good incident practices meet compliance requirements, and the two agendas are more aligned than most teams realize.
What does GDPR actually require during an incident?
Three requirements, on three different clocks.
- Awareness. The 72-hour notification clock starts when you become aware of a breach, which is defined as when you have reasonable certainty a security incident has led to personal data being compromised. Not when the incident began. Not when the fix was deployed. When you knew, or should have known, that data was exposed.
- Notification to the supervisory authority. Within 72 hours of awareness, notify the relevant EU or UK data protection authority. Late notification requires justification.
- Notification to affected data subjects. Without undue delay when the breach is likely to result in a high risk to their rights and freedoms. There is no fixed hour count, but 72 hours is a defensible ceiling; anything longer needs a good story.
The 72-hour clock is the number every incident commander should have in their head. It sets the pace of legal and communications workflows once data exposure is suspected.
What does SOC 2 require from your incident process?
SOC 2 Type II auditors look at your incident management as evidence for the Common Criteria (specifically CC7.3 and CC7.4, covering system monitoring and response). They want to see three things in the audit file for every material incident.
| Evidence | What it looks like |
|---|---|
| Contemporaneous timeline | A timeline with timestamps captured during the incident, not reconstructed after. Auditors can tell the difference. |
| Consistent severity assignment | A defined severity rubric, applied to each incident, with the assignment recorded at declaration. |
| Action item closure | Postmortems produce action items that are tracked in your work management system to closure, with dates. |
None of these are exotic. They are the same practices a well-run incident response process already produces. The compliance overlay is documentary rather than operational.
What is the escalation ladder for compliance-sensitive incidents?
Add compliance escalation triggers to your standard runbook. These are not judgment calls; they are rules that fire on specific conditions.
- Suspected personal data exposure. DPO or privacy lead paged within 15 minutes.
- Unauthorized access or authentication anomaly. Security lead paged immediately.
- Confirmed exposure of PII covering more than a defined threshold of users. Legal counsel paged within 30 minutes.
- Regulated data (health, financial) potentially affected. Compliance officer paged within 30 minutes.
- Notification likely required. External counsel and communications lead pulled in within 60 minutes.
Each trigger is a runbook rule with a name attached. The commander does not decide whether to escalate; they check the trigger conditions and follow the rule. This is the same discipline as the ordinary escalation ladder, just extended to compliance-sensitive scenarios.
How do you keep the incident channel usable when legal is watching?
The failure mode of adding legal, PR, and executives to a live incident channel is that the response degrades. Every technical message gets misread. Every hypothesis gets treated as a fact. The responders start hedging their language, which slows communication.
The fix is a two-channel model.
- Response channel. All technical detail, full responder participation, hypotheses discussed openly. Legal and PR may lurk but do not participate directly.
- Broadcast channel. Structured updates every 15 to 30 minutes, written by the comms lead in customer-safe language, aimed at executives and stakeholders. This is where legal, PR, and non-technical leadership live.
The broadcast is compiled from the response channel and the timeline, not the other way around. The responders stay focused; the stakeholders stay informed; the compliance file gets both artifacts.
What data goes into the compliance audit file?
For every incident that involves customer data or triggers notification, the audit file should include:
- The complete timeline with timestamps
- The severity assignment and its justification against the rubric
- The declaration and closure statements, verbatim
- The postmortem, including contributing factors and action items
- The notification decisions and their timing (notified, not notified, and why)
- The customer communications sent, with timestamps and recipients
- The action item closure record
If your incident tooling produces the first four as automatic outputs, the audit file is essentially assembled at the moment of postmortem publication. Manual assembly is where most compliance audit stress comes from, and it is entirely avoidable.
How do you decide whether to notify under GDPR?
This is a legal decision, not an engineering one. But engineering owes legal a clean set of facts fast, and the facts are what the timeline captures.
The four facts legal needs to make the notification decision:
- What data was exposed (schema, fields, PII flags)
- Who could have accessed it (public, authenticated, specific IPs, internal)
- How many data subjects were affected (row count, unique user count)
- What the window of exposure was (start time, end time, detection time)
If your timeline captures all four during the incident, the notification decision can be made within hours. If any of them require post-incident forensics, you burn the 72-hour clock waiting for facts.
What about customer communications during a compliance incident?
Two audiences, two channels, two languages.
- Affected customers directly. Formal notification, drafted by legal and reviewed by executive comms. Sent by email plus in-product notice. This is what GDPR requires and what customer trust demands.
- All customers via status page. Operational communication about the incident, service impact, and resolution. This is the same language you would use for any incident, minus specifics about data exposure until the legal notification has gone out.
Do not conflate the two. A status page update that hints at data exposure before customers have been formally notified creates legal and trust problems that were entirely avoidable.
The mistake to avoid
Treating compliance as a bolt-on to your incident response. If you are running incidents with a live timeline, defined severities, and disciplined action item tracking already, you are 90% of the way to compliance. If you are not, adding GDPR and SOC 2 requirements to a chaotic response process will not make either better; it will just make the incidents feel more expensive. Structured incident management is the same investment for operations and for compliance, and building it once serves both audiences.
Frequently asked questions
What triggers GDPR breach notification requirements?
A personal data breach, defined as any incident leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data. If your incident touches customer PII (email addresses, phone numbers, IP addresses, usage data linked to identity), it is potentially in scope. The 72-hour notification clock starts when you become aware, not when the incident began.
Does every incident need to be reported under GDPR?
No. Only breaches likely to result in a risk to the rights and freedoms of natural persons. A performance degradation that did not expose data does not trigger notification. A misconfigured access control that briefly exposed usernames does. The 'likely to result in a risk' test is not obvious; when in doubt, involve legal and the DPO in the incident channel.
What does SOC 2 auditors actually look at during an incident review?
Three things: the timeline (was it captured contemporaneously, not reconstructed after), the severity assignment (was it applied consistently against defined criteria), and the action item tracking (do postmortems produce items that are tracked to closure). If you have all three, the incident portion of a SOC 2 audit is largely a paperwork exercise.
Who should be pulled into the incident channel for a compliance-sensitive incident?
The DPO or privacy lead within 15 minutes of suspecting data exposure. Legal counsel within 30 minutes if the incident is likely to trigger notification. Security lead immediately if unauthorized access is suspected. The rule is that these people are on the escalation ladder for specific triggers, not judgment calls: 'suspected data exposure' pages the DPO the same way a database saturation alert pages the on-call.
How do you keep the incident channel usable when legal and PR are watching?
By separating the response channel from the executive briefing channel. Responders stay in the incident channel with full technical detail. Executives, legal, and PR get a broadcast channel with structured updates every 15 to 30 minutes. This keeps the response productive while keeping the stakeholders informed, and it also gives you a cleaner record for the compliance audit.
Run the next incident, not the chaos
Octenor opens the channel, assigns the commander, captures the timeline, and drafts the postmortem, so your team fixes the thing instead of coordinating around it.
Request early access