Athena — auditPic/incident-response.md

Incident Response Procedure — AuditPic

Compliance: GDPR Art.33/34, BIO A.16.1 Owner: GloryLabs Review cycle: Annual (or after any incident)


1. Scope

This procedure applies to any security incident that may involve personal data processed by AuditPic, including:

  • Unauthorised access to user accounts or photos
  • Data breach affecting the PostgreSQL database or MinIO storage
  • Compromise of JWT/HMAC signing secrets
  • Ransomware or data destruction on the VPS (136.144.174.219)
  • Unplanned exposure of user email addresses or photo metadata

2. Incident Classification

| Severity | Definition | Response SLA | |----------|-----------|-------------| | P1 — Critical | Personal data exfiltrated or destroyed; signing keys compromised | Immediate (< 1 h) | | P2 — High | Suspected breach under investigation; service unavailable > 4 h | < 4 h | | P3 — Medium | Anomalous access patterns; single-account compromise | < 24 h | | P4 — Low | Attempted intrusion blocked; no data affected | < 72 h |


3. Response Phases

3.1 Detection & Triage (0–1 h)

  1. Confirm the incident via logs, Grafana alerts, or user report.
  2. Classify severity (see table above).
  3. Notify the designated Incident Lead (GloryLabs on-call engineer).
  4. Open an incident channel in the internal communication tool.
  5. Preserve evidence: snapshot VPS disk, export relevant logs to a safe location before any remediation.

3.2 Containment (1–4 h)

  • Account compromise: Invalidate all refresh tokens for the affected user (DELETE FROM refresh_tokens WHERE user_id = ?).
  • Key compromise: Rotate JWT_SECRET and HMAC_SECRET via 1Password → re-deploy via Helm. All existing tokens are invalidated automatically.
  • MinIO breach: Revoke access keys, rotate credentials in 1Password Sealed Secrets, re-deploy.
  • Full VPS compromise (P1): Isolate the server, spin up a new instance from the latest backup.

3.3 Eradication & Recovery

  1. Identify root cause (vulnerability, misconfiguration, credential leak).
  2. Apply patch or configuration fix.
  3. Restore from the most recent verified backup (RTO ≤ 8 h, RPO ≤ 1 h — see BCP/DR doc).
  4. Re-validate integrity of production database: run Flyway checksums + spot-check photo signatures.
  5. Confirm service health before bringing traffic back.

3.4 Post-Incident Review (within 5 business days)

  • Write an incident report: timeline, root cause, impact, corrective actions.
  • Update threat model and risk register.
  • Schedule follow-up tasks in GitHub Issues (label: security).

4. GDPR Notification Obligations

Supervisory Authority (Art.33)

  • Deadline: 72 hours from awareness of a personal data breach.
  • Threshold: Breach likely to result in a risk to the rights and freedoms of natural persons.
  • Notification to: Autoriteit Persoonsgegevens (AP) — autoriteitpersoonsgegevens.nl/contact
  • Content required: Nature of breach, categories/approximate number of data subjects and records, likely consequences, measures taken/proposed.
  • Log: All notifications (including late notifications) must be documented.

Data Subjects (Art.34)

  • Threshold: Breach likely to result in a high risk to the rights and freedoms of data subjects.
  • Deadline: Without undue delay.
  • Method: Email to affected users from the registered AuditPic sender address.
  • Content: Plain-language description of nature, name/contact details of DPO (if applicable), likely consequences, recommended actions for affected users.

5. Contact List

| Role | Contact | |------|---------| | Incident Lead | GloryLabs on-call (see internal rotation) | | Data Protection Officer | See 1Password vault → auditpic-legal | | Supervisory Authority | Autoriteit Persoonsgegevens — +31 70 888 8500 | | Hosting provider (TransIP) | transip.nl/service |


6. Evidence Retention

All incident artefacts (logs, timeline, notifications) must be retained for 3 years in the reports/incidents/ directory and the corresponding GitHub Issue.

Reacties

Nog geen reacties