Incident Playbook — Data Breach¶

One page, for reading during an incident. Full process: Incident Response Procedure. The notification obligations are in the Personal Data Breach Notification Procedure, and that clock starts the moment you become aware — not when you finish investigating.

What this looks like at Soon¶

Soon holds the workforce data of its customers' employees. Soon is a processor, so a breach obligation runs to the customer, who is the controller and who then has 72 hours to tell their regulator. Being slow to tell them makes their legal position worse, not just ours.

Realistic routes: leaked or committed credentials; a tenant-isolation flaw exposing one customer's data to another; an exposed infrastructure endpoint; a sub-processor's breach; or a misdirected export.

Detection signals¶

GuardDuty findings on anomalous data access or unusual API calls
A customer or researcher reporting they can see data they should not
Secret scanning or Aikido flagging a committed credential
Unusual query volume or bulk export in the database logs
Sentry payloads containing data they should not

First hour¶

#	Action	Who
1	Declare, and note the exact time you became aware. That timestamp is a legal fact — write it down before anything else	Whoever notices
2	Contain: revoke the credential, close the endpoint, disable the account, block the access path	Thomas
3	Preserve evidence before cleaning up — logs, CloudTrail, database audit trails, the offending commit. Cleanup destroys the record of scope	Thomas
4	Establish scope: whose data, how much, what categories, over what period, and whether it was actually accessed or merely could have been. Both answers matter, and they are different answers	Thomas + Olaf
5	Start the notification assessment in parallel — do not wait for a complete picture	Olaf
6	Identify affected controllers — which customer tenants	Olaf

"We found no evidence of access" is not the same as "no access occurred." Say which one you mean, to yourself first and then to the customer. If logging cannot answer the question, that is itself the finding — and it is the reason the logging gaps in this ISMS get fixed.

Notification¶

Follow the Personal Data Breach Notification Procedure. In outline:

To the customer (controller): without undue delay. Check each DPA — some specify a fixed period, often 24 or 48 hours.
The controller notifies their supervisory authority, normally within 72 hours. Soon gives them what they need to do it.
Soon notifies its own supervisory authority (AP) only where Soon is the controller — its own employee or prospect data.
Tell them what you know, then update. An early partial notification beats a late complete one.

Then¶

Root cause, not just the fix. A committed credential is never only a credential — how did it get committed, and why did nothing catch it?
Rotate everything the compromised path could reach, not only what you can prove was used.
Record it fully in Linear: timeline, scope, notifications made and when, root cause, corrective actions, closure. This is the record a regulator or auditor asks for.
If a sub-processor breached, Soon still owes its customers notification — the Vendor & Sub-processor Register tells you which customers are affected by which vendor.

Change log¶

Version	Date	Author	Comments
0.1	2026-08-22	ISMS	First version — written from the processor position, with the awareness timestamp and the "no evidence of access" distinction made explicit.