1. Purpose and scope
This procedure governs how ABN detects, contains, reports and learns from personal-data breaches and security incidents. It covers the ABN software, the customer Node and ABN's own infrastructure.
Because ABN holds no copy of customer data (local execution), the most severe class — central exfiltration of customer data — is architecturally precluded. This procedure nonetheless treats every incident seriously.
2. Roles
| Role | Responsibility |
|---|---|
| Incident Lead | Owns the incident end to end; decides on notification |
| Security Engineer | Containment, forensics, root cause |
| Legal/DPO contact | Art. 33/34 assessment; legal@abnplatform.com |
| Customer liaison | Keeps the affected customer(s) informed |
3. Detection
Incidents surface through: the customer-owned audit tables and
HMAC-signed attestations (any tampering is detectable); the
abn-security anomaly detector; the supervisor health checks;
kill-switch activations (each is logged and alerts); and customer
reports.
4. Severity classification
| Level | Definition | Example |
|---|---|---|
| SEV-1 | Confirmed personal-data breach | identifiable data exposed |
| SEV-2 | Security incident, no confirmed data exposure | sandbox escape attempt blocked |
| SEV-3 | Degraded control / near miss | expired mTLS cert denied a service |
5. The 72-hour timeline (Art. 33)
T+0h Detection. Incident Lead assigned. Containment begins.
T+0–4h Triage: scope, severity, whether personal data is involved.
T+4–24h Containment confirmed; forensic evidence preserved;
affected customers/controllers notified so THEY can meet
their own Art. 33 duty (ABN is the processor).
T+≤72h If a personal-data breach: the controller notifies the
supervisory authority (in Sweden: IMY) within 72 hours of
becoming aware. ABN, as processor, notifies the controller
"without undue delay" (Art. 33(2)) — in practice within 24h.
Ongoing Art. 34: if high risk to data subjects, the controller
informs the data subjects without undue delay.
Processor duty: ABN does not notify the supervisory authority itself — it notifies the controller without undue delay and provides all information the controller needs for its own notification (nature of the breach, categories and approximate numbers, likely consequences, measures taken).
6. Containment and eradication
Pause/stop affected agents from the dashboard; activate the
abn-security kill-switch for any affected sandbox; rotate mTLS
certificates and any affected secrets; if a connector is implicated,
disable it (enabled = false). Preserve audit tables and attestations
as evidence before any remediation.
7. Notification content (to the controller)
Per Art. 33(3): description of the breach; categories and approximate
number of data subjects and records; contact point (legal@abnplatform.com);
likely consequences; measures taken or proposed.
8. Post-incident review
Within 10 working days a written review records: timeline, root cause, what worked, corrective actions, and whether the DPIA / threat model needs updating. Every SEV-1/SEV-2 review updates this procedure.
9. Register
All incidents are logged in an internal incident register (Art. 33(5) documentation requirement), retained for at least 2 years.