Personal-Data Breach Runbook

The operational playbook we follow when a personal-data incident is detected on the Altix platform. Published for transparency.

Effective 29 April 2026

0. Triggers

This runbook starts the moment any of the following is observed:

  • Confirmed unauthorised access to the production database, storage bucket, or hosting account.
  • Accidental disclosure of personal data (wrong recipient, public bucket misconfiguration, leaked link).
  • Loss or theft of credentials with production access.
  • A vulnerability report from a researcher or sub-processor that meaningfully raises breach risk.

1. Contain (T+0 to T+1h)

  • Rotate Supabase service-role key, Vercel deployment hooks, Resend API key.
  • Rotate the application encryption key and start a re-encryption job for sensitive identifiers.
  • Revoke any active Supabase user sessions if account takeover is suspected.
  • If a misconfiguration caused exposure, fix it and confirm the fix in production.

2. Assess (T+1h to T+24h)

  • Pull the audit log for the affected window. Identify which tenants and which data types are in scope.
  • Distinguish "personal data" from "special category" data — bank details, NI numbers, ID photos all warrant a higher severity.
  • Estimate the number of affected data subjects per tenant.
  • Record findings in breach_log with the incident severity and current resolution state.

3. Notify (within 72h of awareness)

  • Notify each affected Controller (firm owner) by email, providing: nature of the breach, categories and approximate number of data subjects affected, likely consequences, mitigations taken, and Altix's contact for further questions.
  • If the breach is likely to result in a high risk to data subjects, notify the data subjects directly without undue delay — typically by email to the worker.
  • For breaches that meet the UK GDPR threshold, notify the ICO within 72 hours of becoming aware. ICO online breach reporting: ico.org.uk/for-organisations/report-a-breach.

4. Resolve and learn

  • Close out the incident in the breach log with the final resolution and any post-incident actions.
  • Add monitoring or guardrails that would have caught the breach earlier.
  • Update this runbook if the response surfaced gaps.

Roles

The Operator (Viktor) is the incident commander for any breach. For incidents affecting a sub-processor (Supabase, Vercel, Resend), the Operator coordinates with that sub-processor's security team and relays material updates to affected Controllers.

Contacts