Personal Data Breach Response Procedure
Version 2.0 - Effective 2026-07-08 - Change log
Template document: review by a qualified data-protection lawyer or DPO before commercial reliance. Not legal advice.
This is Amaigo's operational runbook for security incidents and personal data breaches affecting the Whistle service, aligned to Articles 33 and 34 of the EU GDPR and UK GDPR. Amaigo acts as processor; our clients (law firms and other businesses) are controllers. Contractual commitments in this procedure are mirrored in the DPA.
1. Definitions and severity classes
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.
| Class | Definition | Examples |
|---|---|---|
| S1 | Confirmed personal-data breach | Database exposure, exfiltrated lead records, misdirected export |
| S2 | Suspected personal-data breach, not yet confirmed | Anomalous admin-token use, provider alert implicating our data |
| S3 | Security incident with no personal data involved | DDoS absorbed by Cloudflare, vulnerability found before exploitation |
S2 incidents are worked with S1 urgency until personal-data impact is ruled in or out. S3 incidents follow steps 2, 6, and 7 only.
2. Detect and contain
Detection sources: monitoring and alerts from Railway, Vercel, and Cloudflare; notifications from providers on the sub-processor list; reports from clients or data subjects to [email protected]; findings from our own reviews.
Containment actions (as applicable): revoke and rotate exposed credentials and the admin bearer token; disable affected tenant configurations or endpoints; apply Cloudflare WAF rules or rate limits; isolate or snapshot the affected database; suspend outbound email if compromised.
Evidence preservation starts at detection: do not destroy or overwrite logs, snapshots, or affected records during containment. Where containment and preservation conflict, preserve first if it is safe to do so.
3. Assess
Establish, and record in the incident log:
- the nature of the breach and how it occurred;
- the categories of data subjects (typically prospective clients of our controller clients) and of personal data (contact details, enquiry content, booking data);
- the approximate numbers of data subjects and records concerned;
- the likely consequences for the individuals affected;
- the risk level, which drives the controller-facing advice in step 5.
4. Forensics and evidence
Sources available for timeline reconstruction:
- Append-only audit log: compliance events (consents, exports, erasures, purges) without personal data; cannot be altered after the fact.
- Platform logs: Railway application and database logs and Vercel function logs, each subject to the provider's retention window, so export them early: they age out.
- Database state: take a snapshot of affected tables before remediation where safe.
- Provider dashboards: Cloudflare security events, deploy histories.
Reconstruct a timeline (first malicious event, detection, containment, notification) and preserve exports of all of the above before any remediation that would alter them, where doing so does not extend the exposure.
5. Notify
Amaigo's duty as processor: we notify each affected controller without undue delay and in any event within 48 hours of becoming aware of a personal data breach affecting their data. Notification includes the Article 33(3) content: nature of the breach, categories and approximate numbers of data subjects and records, our contact point, likely consequences, and measures taken or proposed. Where full information is not yet available, we notify with what we have and provide phased updates as the investigation progresses; the 48 hours are never spent waiting for a complete picture.
Reminder table for controllers (your obligations, not ours; we supply the information you need to meet them):
| Obligation | Who | Deadline |
|---|---|---|
| Notify the ICO (UK GDPR Art. 33) | UK controller | 72 hours from becoming aware, unless unlikely to result in a risk |
| Notify the competent supervisory authority (EU GDPR Art. 33) | EU controller | 72 hours from becoming aware, unless unlikely to result in a risk |
| Notify affected data subjects (Art. 34) | Controller | Without undue delay, where high risk to rights and freedoms |
6. Remediate and post-mortem
- Fix the root cause, not just the symptom; verify the fix in production.
- Record corrective and preventive actions with owners and dates.
- Update the breach register (maintained per Article 33(5)): facts, effects, remedial action, for every breach whether or not notifiable.
- Review whether the Security Overview, DPIA, or TRA need updating, and whether client-facing documents require a version bump via the change log.
7. Contacts
- Incident lead: Amaigo Privacy Lead, [email protected].
- Client contacts: each controller's nominated data protection contact, recorded per engagement.
- Data subjects who contact us directly are referred to the relevant controller per the DSAR Procedure, with the controller informed.
This document is a GDPR-aligned template and must be reviewed by a qualified data-protection lawyer or DPO before commercial reliance. It is not legal advice.