11. Incident response for data breach¶

The discipline reduces the rate of leaks. It does not eliminate them. The last chapter is what the platform does when, despite all the previous work, data does get out: containment, notification, remediation, and learning.

A security engineer at a Pune SaaS company gets a page at 02:14 on a Sunday: leak detection (chapter 08) has flagged a credential with 2,400 reads of regulated-tier fields in an hour, far above its baseline. The on-call investigates within ten minutes. Triage: the credential belongs to an internal analytics service; the access is using a purpose that does authorise regulated reads (analytics:cohort_aggregate); the volume is anomalous because the service was supposed to run nightly but a scheduling bug has fired it hundreds of times. The leak is "data accessed beyond its policy intent" rather than "data crossed the platform's boundary." Still, the engineer follows the response flow: contain (revoke the credential), assess scope (which records, which subjects), notify (security and platform leads), remediate (fix the scheduling bug), document. By Sunday evening, the response is in writing; by Monday, the patch is shipped; by Friday, the postmortem is published; the platform's policies are tightened so the same shape of incident cannot recur.

This chapter is the response flow. Containment first, blast assessment, notification under regulation, remediation, postmortem, and the discipline that turns each incident into improvement.

What "data breach" means here¶

A data breach is an unauthorised or unintended access, disclosure, modification, or loss of personal or sensitive data, regardless of whether it crossed the platform's external boundary.

The "regardless of whether it crossed the boundary" is important. A breach is a breach when data is accessed beyond its policy — even if it never left the platform. Regulators in most regimes treat internal-unauthorised access as a breach event, with notification obligations.

Examples:

An agent reads a different customer's data (chapter-1 incident).
A credential is used to read more data than its purpose allows (chapter-11 opening).
An employee with valid credentials exfiltrates data via API.
A backup is left in an unrestricted storage bucket.
A model provider's logs retain data the contract said they would not.

Each is a breach in scope; the response shape is similar.

The response phases¶

Five phases. Each has a time window and a deliverable.

1. Detection and triage (minutes to hours)

The leak-detection alarm fires, or a user reports, or an audit query reveals. Within ten minutes, an engineer assesses: real incident? What scale? What data? Who is involved?

2. Containment (minutes to a few hours)

Stop the bleeding. Revoke the credential. Disable the agent or the affected feature. Freeze the suspect actor. The first hour is about stopping ongoing harm, not understanding the root cause.

3. Blast assessment (hours to days)

Map what happened. Which records were touched, by whom, on whose behalf, in what window, with what disposition? The audit log is the substrate. The output is a precise scope: who is affected, what was exposed, what was the duration.

4. Notification and remediation (days to weeks)

Per regulation: notify the data protection authority, notify affected data subjects, notify customers (per contract), notify internal leadership. Each has its own deadline (GDPR is 72 hours for the DPA; DPDP has similar windows; sectoral rules vary). Concurrently, the technical fix is shipped: patch the bug, tighten the scope, rotate credentials, update the policy.

5. Postmortem and improvement (one to two weeks after containment)

Write the postmortem: timeline, root cause, blast, response. Identify the systemic improvements: what discipline was missing, what monitor would have caught earlier, what control would have prevented. Land the improvements as backlog items with owners.

Containment — the first hour¶

The first hour is the most important. The team's job is to stop the data from being accessed further. Concrete actions in priority order:

Action	When
Identify the affected credential or actor	Always
Revoke the credential	Within minutes if specific to one credential
Disable the affected agent or feature	If multiple credentials involved or the feature itself is the vector
Freeze the suspect actor's session	If a session is active and the leak is ongoing
Block the exfiltration path if identified	If the breach is external (network egress, untrusted call site)

Containment is not the same as understanding. The team contains first, understands second. Acting on partial information is the right move when ongoing harm is the alternative.

Containment may be reversed once the situation is understood. A credential revoked for ten minutes that turns out to be a false positive is a small cost; a credential left active during a real breach is a large one.

Blast assessment¶

Once contained, the team maps the blast. The audit (chapter 07) is the source.

Per audit record involved: - Which data subject(s) are affected? - Which fields were exposed? - Through what channel did the data flow? - Was it copied, transmitted externally, or only viewed?

The output is a per-subject list (the subjects whose data was affected) and a per-record list (the actual records exposed). Each subject's data may include items that were exposed and items that were not; the assessment is field-level when possible.

For a small breach (one subject, a few records), the assessment takes hours. For a large breach (thousands of subjects, structured exfiltration), the assessment takes days and may require forensic specialists.

Notification¶

Regulatory and contractual notification has hard deadlines.

GDPR. Notify the supervisory authority within 72 hours of becoming aware. Notify affected data subjects "without undue delay" if the breach is likely to result in a high risk to rights and freedoms. The notification content is specified: nature of breach, categories and approximate numbers, contact point, likely consequences, measures taken.

DPDP (India). Notify the Data Protection Board "as soon as may be" in accordance with prescribed rules. The notification format and timing is being finalised at the time of writing; the obligation is real and expected to align with GDPR-like windows.

HIPAA (US healthcare). Notify affected individuals within 60 days. Notify HHS depending on size (>500 individuals = immediate; smaller = annual).

Sectoral. Financial regulators, telecom regulators, sectoral notifications.

Contractual. Customer agreements often specify notification obligations to the customer organisation (e.g., the platform's enterprise customers); these typically have shorter windows than regulatory notifications.

The team's playbook should have a notification checklist with the specific regulations applicable, the specific contacts at each, and the deadline. The first time a notification is composed under time pressure is the wrong time to be reading regulations.

Notification content¶

A reasonable structure for the notification to a data subject:

Subject: Notice regarding the security of your data

Dear [name],

We are writing to inform you of an event involving your personal data
held by [platform]. On [date], we became aware that [description of
what happened in plain language]. The data involved included [specific
categories — names, emails, etc.]. We do not believe the data has been
used for purposes outside [our own platform / its intended use], but
we cannot exclude that possibility.

We have taken the following steps:
- [containment action]
- [remediation action]
- [improvement action]

We recommend you [steps the subject can take — change password if
relevant, monitor account, contact us with questions].

We are notifying [DPA or equivalent regulator] of this incident per
applicable law.

If you have questions, contact us at [contact].

Sincerely,
[platform]

The notification is honest about what happened, what data, what action was taken, what the subject can do. Avoid corporate language; avoid downplaying; avoid surplus reassurance ("we take data security very seriously" is empty and signals defensiveness).

Remediation¶

The technical fix. Sometimes the fix is small (the chapter-opening case: fix the scheduling bug). Sometimes large (re-architect the affected component). The remediation is sized to prevent recurrence of this specific incident and to address any systemic gap revealed.

The remediation has an owner and a date. It is tracked alongside the incident; the postmortem is not closed until the remediation is shipped and verified.

Postmortem¶

Within one to two weeks of containment, the postmortem is written and circulated. The structure:

Timeline. When the incident started, when it was detected, when each phase happened, when it was contained, when notifications went out.
Root cause. What specifically allowed the incident to occur — a code bug, a misconfigured scope, an over-broad credential.
Contributing factors. Conditions that made the root cause possible or undetected — missing tests, weak monitor, untested operational path.
Blast. Who was affected, what was exposed, what the operational/regulatory/reputational impact was.
Response assessment. What worked in the response, what did not, what should be faster next time.
Action items. Specific improvements with owners and dates. Each addresses a contributing factor.

The postmortem is blameless — it names the system that allowed the failure, not the engineer who happened to be the proximate cause. Module 05_ai_incident_operations covers postmortem discipline in depth.

A few patterns are specific to agent platforms.

Cross-user data in an agent's response. The agent surfaced one user's data to another. Investigation: which request, what scope was authorised, what was actually queried, what was returned. Often a scope-binding gap (chapter 04).

Prompt-injection-driven exfiltration. A malicious input convinced the agent to act on attacker's behalf. Investigation: the prompt, the model's reasoning trace if available, the tools called, the data accessed. The defence is multi-layer — scope, output filtering, suspicious-pattern detection. Module 01_prompt_injection_security covers prevention; this chapter covers response.

Provider retention of regulated data. The model provider's logs retained data that the contract said they would not. Investigation: which provider, which data, what contract clause, what notice timing. Response is contractual (the provider's breach) and notification (your customers must be notified that their data was retained).

Cross-tenant leak. Tenant A's data appeared in tenant B's context. Investigation: which audit records crossed; how the tenant scope failed. Often the most severe class because multi-tenant platforms are typically large and the affected subject count is high.

Audit log compromise. The audit itself is altered or accessed without authorisation. Investigation: who accessed the audit, what was modified, what tamper-evidence detected. The integrity of every previous claim now depends on the audit's integrity.

What incident response does not solve¶

Preventing breaches. Response is the back-stop. Most of the work to prevent breaches is in chapters 02-10.
Reputational repair. Notifications are honest; the reputational story is largely outside engineering's control.
Cost of consequences. Regulatory fines, customer churn, increased compliance overhead — these are costs the response cannot avoid, only acknowledge.

The discipline is "respond well, learn from, prevent recurrence." Recurrence is the failure that turns one breach into a pattern that ends platforms.

How incident response interacts with the other surfaces¶

Audit (chapter 07) is the substrate of the investigation.
Leak detection (chapter 08) is the input to detection.
All policy chapters (02-10) are the source of the contributing factors and the targets of remediation.
AI incident operations (01_ai_engineering/05) is the broader incident discipline; this chapter is the data-breach-specific application of it.
Prompt injection security (03_ai_security_safety/01) covers attack vectors; this chapter covers response after the attack is detected.

Interview Q&A¶

Q1. The leak detection fires; the credential's reads are above baseline but within authorised purpose. What is the response? Contain first — even though the reads are authorised, the rate is anomalous and the cause is unknown. Revoke the credential, freeze the affected actor. Investigate within minutes: walk the audit, identify the scope, look for the cause. If the cause is benign (the chapter-opening scheduling bug), reverse the containment quickly with a tracked remediation. If the cause is suspicious or unclear, keep contained and escalate to a security investigation. The discipline is "contain first, understand second"; the cost of a brief containment is small. Wrong-answer notes: "wait until we understand" produces ongoing harm if real.

Q2. The breach involves 2,000 EU customers. Walk through the notification timeline. Within 72 hours of becoming aware: notify the supervisory authority (the relevant Data Protection Authority for the platform's main establishment). Concurrently or within "undue delay": notify the affected data subjects. The supervisory notice is structured (nature, categories, numbers, consequences, measures). The subject notice is in clear language. Internal notifications go to leadership and the affected customer organisations (per contract). The 72-hour clock starts at becoming aware, not at full investigation; the initial notification may be partial with updates following. Wrong-answer notes: "we'll notify when we know everything" misses the 72-hour clock.

Q3. What is the difference between the team's response to a "leak detection alarm" and a "confirmed breach"? The alarm produces investigation; the confirmed breach produces notification. Many alarms turn out to be benign (chapter 08); their resolution is internal. A confirmed breach — where unauthorised access has occurred — triggers the regulatory and contractual machinery. The transition from alarm to confirmed breach happens when the investigation determines that authorisation was exceeded or scope was violated in a way the platform must report. The team's playbook distinguishes the two phases explicitly. Wrong-answer notes: treating every alarm as a confirmed breach produces over-notification and alarm fatigue.

Q4. The postmortem identifies that the scope-binding code did not enforce per-call narrowing in one path. What does the action-item list look like? Specific. (a) Fix the per-call scope binding in the affected path, with tests. (b) Audit all other agent code paths for the same gap. (c) Add a CI check that all data-access calls go through the mediator. (d) Extend leak-detection to catch this specific shape (e.g., reads of multiple distinct resources beyond the active scope). (e) Update the architect checklist to include this specific check. Each action has an owner and a date. The postmortem is closed when all items are shipped, not when the immediate fix is shipped. Wrong-answer notes: "we fixed it" without the systemic improvements is the path to recurrence.

What to do differently after reading this¶

Build the incident response playbook before the first incident. Notification templates, regulatory contacts, escalation tree.
Rehearse the response. Tabletop exercises where the team walks a hypothetical incident through the five phases.
Set the bar that every breach produces a postmortem with systemic action items.
Treat the audit as the substrate; if the audit cannot answer "what was accessed," the incident response is hobbled at the start.
Maintain the discipline of containment-first; alarm fatigue is the failure mode that turns real incidents into delayed responses.

Bridge. Eleven chapters of discipline. The last two synthesise. The next chapter is the architect's checklist — twenty items that distinguish a defensible data-access governance posture from one that is not. → 12-architect-checklist.md