Incident Response Playbook

Version 1.1 · Effective 2026-07-15. This playbook governs how X-com detects, contains, assesses, and reports personal data breaches under GDPR Articles 33 and 34, the UK GDPR, and the Swiss FADP. It is the operational counterpart to Section 9 of our Data Processing Addendum.

1. Scope & definitions

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data (GDPR Art. 4(12)). This playbook covers three breach categories:

• Confidentiality — unauthorised access or disclosure (e.g. RLS bypass, leaked token, misdirected email).
• Integrity — unauthorised alteration (e.g. tampered records, corrupted backup).
• Availability — loss of access to data (e.g. ransomware, deletion, permanent outage without restore).

2. Roles

3. The 72-hour decision timer

The clock starts when X-com becomes aware of a breach — i.e. when we have a reasonable degree of certainty that a security incident has occurred and led to personal data being compromised (EDPB Guidelines 9/2022). Awareness is not the moment of first alert; it is confirmation. The IC records the aware timestamp in the incident ticket.

Processor obligation: where we act as processor (default for Customer Personal Data), we notify the affected Customer without undue delay after becoming aware — target within 24 hours — so the Customer can meet its own 72-hour clock as controller (Art. 33(2)).

4. Risk assessment

The Privacy Lead scores each breach for likelihood and severity of risk to data subjects using the ENISA methodology:

• Data Processing Context (DPC) — categories, volume, identifiability.
• Ease of Identification (EI) — can individuals be identified from the exposed data?
• Circumstances of Breach (CB) — loss of confidentiality / integrity / availability, malicious intent.

Score bands and outcomes:

• Low — internal log only. No Art. 33 notification unless required by contract.
• Medium — Art. 33 notification to supervisory authority. Art. 34 optional.
• High / Very High — Art. 33 and Art. 34 notification to affected data subjects, unless an exception in Art. 34(3) applies (encryption safe harbour, subsequent measures neutralising risk, or disproportionate effort with public communication).

5. Containment & forensics

1. Revoke compromised credentials, tokens, API keys; rotate signing secrets.
2. Isolate affected systems; take a snapshot for forensics before remediation.
3. Preserve audit_log, admin_routing_events, edge logs, and Supabase logs for the incident window (minimum 90 days).
4. Verify backup integrity; do not restore over evidence.
5. Deploy a patch or configuration change; confirm the vector is closed with a targeted test.

6. Notification templates

6.1 Controller notification (we are processor → Customer)

Subject: [Security Notice] Personal data incident affecting your X-com workspace

Dear [Customer contact],

We are writing to inform you, without undue delay under Article 33(2) GDPR,
of a personal data incident that may affect personal data you process using
X-com.

1. Nature of the incident
   [Short factual description. Type of breach: confidentiality / integrity / availability.]

2. Categories and approximate number of data subjects
   [e.g. ~1,240 end users of your workspace.]

3. Categories and approximate number of personal data records
   [e.g. email addresses and hashed passwords; no payment data.]

4. Likely consequences
   [e.g. risk of credential stuffing on third-party sites if users reuse passwords.]

5. Measures taken or proposed
   - [Containment step 1]
   - [Containment step 2]
   - Forced password reset for affected accounts at [time, UTC].

6. Contact
   Our Privacy Lead is available at privacy@x-com.example for follow-up.
   Incident reference: INC-[YYYY]-[####].

We will send a follow-up within [X] hours as the investigation progresses.

[Name], Incident Commander
X-com

6.2 Supervisory authority notification (we are controller)

To: [Lead supervisory authority] — via online breach form
Subject: Article 33 notification — X-com — INC-[YYYY]-[####]

Controller: X-com [legal entity, address, DPO contact]
Aware timestamp (UTC): [ISO-8601]
Notification timestamp (UTC): [ISO-8601]
Delay beyond 72h: [none | reason per Art. 33(1)]

1. Nature of the breach
   [Confidentiality / integrity / availability. Concise factual account.]

2. Categories and approximate number of data subjects concerned
3. Categories and approximate number of personal data records concerned
4. Likely consequences for data subjects
5. Measures taken or proposed to address the breach and mitigate adverse effects
6. Whether data subjects have been / will be informed (Art. 34)
7. Cross-border scope: [Member States affected]
8. Contact point for further information: privacy@x-com.example

Attachments: incident timeline, technical report summary.

6.3 Data subject notification (Art. 34)

Subject: Important security notice about your X-com account

Hello,

We are contacting you directly because a recent security incident at X-com
likely affected your personal data. We are required under Article 34 GDPR
to tell you what happened, what it means for you, and what we are doing.

What happened
   [Plain-language description in 2-3 sentences.]

When
   Detected: [date, UTC]. Contained: [date, UTC].

What data was involved
   [Specific list — e.g. email address, display name, message metadata.
    Explicitly call out what was NOT affected — e.g. passwords remain hashed
    with bcrypt and were not exposed; no payment data is stored by X-com.]

What this means for you
   [Concrete risk, e.g. phishing attempts referencing your account.]

What we recommend
   1. [Action 1, e.g. reset your password if you reuse it elsewhere.]
   2. [Action 2, e.g. enable two-factor authentication.]
   3. Be alert to unexpected emails claiming to be from X-com.

What we are doing
   [Containment + follow-up. Reference /trust for our controls.]

Questions
   privacy@x-com.example — reference INC-[YYYY]-[####].

We are sorry this happened.

The X-com team

6.4 Internal declaration (Slack / incident channel opener)

:rotating_light: INCIDENT DECLARED — INC-[YYYY]-[####]
Severity: [SEV-1 | SEV-2 | SEV-3]
Aware at (UTC): [ISO-8601]  ← 72h clock starts here
IC: @[name]   Security: @[name]   Privacy: @[name]

Summary: [one line]
Suspected data involved: [one line]
Current status: investigating

Channel: #inc-[####]   Doc: [link]   Next update: T+1h

7. Severity matrix

The IC assigns severity at declaration and revises it as facts change. Severity drives paging, communication cadence, and executive involvement — it is independent of the Art. 33/34 notification decision (a SEV-3 can still be notifiable if it involves personal data).

7.1 SEV decision flow

Use this flow at declaration and re-run it whenever new facts land. Answer questions top-down; the first "yes" fixes the floor severity — the IC may escalate further but must not downgrade without written justification in the incident doc.

1. Q1 — Is production data or a production system confirmed compromised, actively exfiltrating, encrypted by ransomware, or fully down > 30 min?
   → Yes: SEV-1. Page all on-call + CTO + CEO. Open evidence ticket (§8). Start Art. 33 clock (§4). Legal + Comms on-bridge within T+30 min.
   → No: go to Q2.
2. Q2 — Is there credible risk of compromise without confirmed data access?Examples: leaked staff credential in use, RLS bypass observed in staging, exploited vuln with no evidence of data read yet, partial outage affecting a customer segment.
   → Yes: SEV-2. Page security on-call + IC. Open evidence ticket. Privacy Lead drafts risk assessment (§4) in parallel — do not wait for confirmation to start the 72 h clock if personal data is in scope.
   → No: go to Q3.
3. Q3 — Is there a suspected issue that needs investigation but no evidence of exploitation? Examples: anomalous access pattern, low-severity vuln disclosed, third-party advisory affecting a dependency in use.
   → Yes: SEV-3. Security on-call during business hours. Daily update in #inc-[####]. No evidence ticket required unless upgraded.
   → No: go to Q4.
4. Q4 — Informational only? Single failed WAF signature, spam signup wave, isolated bot noise.
   → SEV-4. Log for weekly pattern review. No paging.

7.2 Escalation triggers (any one bumps severity up one level)

• Personal data confirmed in scope → minimum SEV-2 and start §4 Art. 33 assessment.
• Special-category data (Art. 9) or children's data in scope → minimum SEV-1.
• Admin or service-role credential involved → minimum SEV-1 (assume lateral movement).
• Media, regulator, or customer inquiry received before disclosure → minimum SEV-2, loop in Comms immediately.
• Detection gap > 24 h between event and discovery → bump one level; scope is likely wider than first evidence suggests.
• Backup, log, or audit trail integrity in question → minimum SEV-1; evidence collection (§8) takes priority over remediation.

7.3 Symptom → SEV quick map

8. Evidence collection & chain of custody

Evidence integrity is what separates a defensible investigation from speculation. Every SEV-1 and SEV-2 opens an evidence ticket the moment the incident is declared. Items, hashes, and every custody event are logged in the internal incident evidence register (platform admin only).

1. Preserve before you remediate. Take a read-only snapshot of any host, database, or storage bucket in scope before pushing config changes, rotating credentials, or restarting services. Ephemeral state (memory, active sessions, in-flight connections) is lost otherwise.
2. Collect systematically.
   • Application: Supabase logs, edge logs, audit_log, admin_routing_events, rate-limit counters — export the full incident window ±2h.
   • Database: PITR snapshot of the affected schema; pg_stat_activity and pg_stat_statements extracts; row counts before/after.
   • Storage: object listings with versions, ACLs, and access logs for the affected buckets.
   • Identity: Supabase Auth sign-in events, MFA state, session token metadata (never token values), OAuth consent history.
   • Network: Cloudflare/WAF logs, edge origin IPs, TLS handshake anomalies.
   • Endpoint (if staff device involved): EDR timeline, browser history, USB events.
3. Hash and label. For every artifact captured: compute SHA-256, record collector name, collection UTC timestamp, source system, and hash in the evidence register. Store the hash separately from the artifact.
4. Store in the evidence bucket. Write-once storage with object lock; access limited to Security Lead + Legal. Never in the incident Slack channel, never in personal drives.
5. Track custody. Every access (view, copy, share with counsel or regulator) is logged with who, when, and why. Do not modify original artifacts — work from copies.
6. Retention. Minimum 2 years after incident closure; longer if under litigation hold or regulatory inquiry. Do not delete evidence during a pending Art. 33 dialogue with a supervisory authority.

9. Scenario runbooks

9.1 Ransomware / destructive malware

1. Declare SEV-1. Assume lateral movement until proven otherwise.
2. Isolate affected hosts at the network layer — do not power off; memory is evidence.
3. Revoke all long-lived credentials on affected systems; rotate Supabase service role key, connector keys, VAPID keys, EMBED_JWT_SECRET, Stripe webhook secrets.
4. Snapshot affected databases via PITR to an isolated staging project (see backup drill). Verify snapshot integrity before considering restore.
5. Identify patient zero: which credential, service, or vulnerability enabled entry.
6. Assess whether personal data was accessed (confidentiality breach), altered (integrity breach), or only encrypted in place (availability breach). All three are notifiable if risk to data subjects is met.
7. Do not pay a ransom without CEO + Legal + Board sign-off; check sanctions lists (OFAC/EU) — payment may itself be illegal.
8. Restore from a known-clean backup predating initial compromise, not the most recent one.
9. Force password reset + session invalidation for all users on affected workspaces.

9.2 Credential compromise (staff or customer)

1. SEV-2 for a single confirmed compromise; SEV-1 if staff admin credential or if used to access customer data.
2. Immediately revoke the specific credential (Supabase Auth session, connector token, personal access token). For a customer-facing account, force password reset and invalidate all sessions.
3. Query audit_log and Auth sign-in events for the compromised principal: full IP/UA history, actions taken, records read or exported, invitations sent, role changes.
4. Search for pivot: were other credentials created, other MFA devices enrolled, other roles granted? Rotate them.
5. If staff credential: check for OAuth app authorizations added, git access, cloud console access; revoke and audit each.
6. If a customer credential: notify the affected customer within 24 h per Art. 33(2); include the actions observed under the account.
7. Enforce MFA on the affected principal type if not already required; re-check password strength policy.
8. Investigate the source: phishing, malware, credential stuffing, third-party breach reuse. Add IoCs to detection rules.

9.3 Insider threat (malicious or negligent)

1. SEV-1 for suspected malicious insider (data exfil, sabotage). SEV-2/3 for negligent (misdirected email, oversharing).
2. Loop in Legal + HR immediately, before confronting the individual. Preserve evidence discreetly to protect any employment or criminal action.
3. Quietly restrict access: revoke production access, disable exports, watch — do not fire and alert. Coordinate with HR on timing.
4. Collect evidence covering the entire tenure or the last 90 days (whichever is shorter): audit_log, admin actions, data exports, storage downloads, unusual query patterns, off-hours access.
5. For negligent disclosure: retrieve/recall the data if feasible (email recall, deleted-file recovery on recipient side under contract), assess Art. 34 risk based on recipient trust and data sensitivity.
6. Coordinate with HR on employment action; coordinate with Legal on civil or criminal referral.
7. Post-incident: review the access model that allowed the action (least privilege, separation of duties, dual control for exports) and change it — the fix is structural, not a warning email.

9.4 Vulnerability exploited (RLS bypass, SSRF, IDOR, etc.)

1. Severity by evidence of exploitation: SEV-1 if exploited in prod against real data; SEV-2 if exploitable but no evidence yet; SEV-3 if theoretical.
2. Reproduce in staging to confirm scope. Do not test on prod without IC approval.
3. Deploy a mitigation (WAF rule, feature flag off, RLS policy patch) even before the full fix — reduce the exposure window.
4. Query logs to identify who exploited it and against which rows/records. Enumerate every affected data subject.
5. Ship the permanent fix; add a regression test; run the security linter (supabase--linter) and dependency scan.
6. If the vector was reported by an external researcher, credit them per our vulnerability disclosure policy; do not litigate good-faith reports.

10. Documentation (Art. 33(5))

Every incident — reportable or not — is documented in the incident register with: aware timestamp, facts, effects, remedial action, and the reasoned decision on whether Art. 33 and Art. 34 notifications were made. The register is retained for a minimum of five years and is available to the supervisory authority on request.

11. Post-mortem

Within 30 days the Security Lead publishes a blameless post-mortem covering: timeline, root cause, contributing factors, customer impact, corrective actions with owners and due dates, and any changes to Annex II measures. Post-mortem outcomes feed the next access review and the security testing cadence.

12. Contacts

• Security: security@x-com.example
• Privacy / DPO: privacy@x-com.example
• Legal: legal@x-com.example
• 24/7 on-call: paged via internal PagerDuty rotation

This playbook is operational documentation, not legal advice. Regulatory obligations depend on the specific facts of each incident and applicable jurisdiction; Legal confirms the final notification decision.