UNDA — Personal-Data Breach Incident Response

Status: Draft. This process must exist and be executable before production health data is stored (§15.2). Owner: Security officer (TBD) — until named, the CTO / lead engineer holds this responsibility.

Applicability

A "personal-data breach" is defined per GDPR Art. 4(12): a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

Any of the following is a suspected breach until triaged otherwise:

• Reported data exposure (external researcher, user, employee).
• Unexpected access log entry to a sensitive table.
• Unknown-device authentication on an account.
• Lost/stolen developer machine with production access.
• Vendor incident affecting a sub-processor holding UNDA data.
• Malicious dependency detected in a shipped build.

Notification deadlines (EU/Spain)

• Regulator (AEPD): notification within 72 hours of becoming aware, unless the breach is unlikely to result in risk to individuals' rights and freedoms (GDPR Art. 33).
• Affected individuals: without undue delay when the breach is likely to result in a high risk to their rights and freedoms (GDPR Art. 34).
• Sub-processor incident (Supabase, Strava, etc.): the processor's DPA obliges them to notify UNDA "without undue delay" — receipt of such a notice starts the 72-hour clock for UNDA.
• Cyber Resilience Act (from 11 September 2026): significant vulnerabilities / actively exploited flaws in products with digital elements must be reported to the coordinator/ENISA on shorter windows once the CRA reporting portal is live. Formal CRA applicability assessment is on the Pre-Public-Launch Gate.

Process

1. Detection & intake

• Route: security@ mailbox (to set up) + internal #unda-security channel.
• Any team member observing a suspected incident opens a ticket immediately; no triage before opening.

2. Containment

• Stop the bleed: revoke credentials, disable compromised accounts/API keys, rotate secrets, pull affected release, take service offline if needed.
• Preserve evidence: snapshot logs, DB state, and any artefacts before cleanup. Chain-of-custody notes in the ticket.

3. Severity classification

Use the following matrix. Highest applicable severity wins.

Signal	S1	S2	S3
Sensitive health data of >100 users exposed	✓
Sensitive health data of 10–100 users exposed		✓
Sensitive health data of <10 users exposed			✓
Identity-only data (email, UUID) exposed		✓	✓ (small numbers)
Credentials / tokens exposed	✓	✓
Data altered/destroyed with no backup	✓
Availability incident (>4h outage)		✓	✓

4. Personal-data impact assessment

Document:

• Categories of data involved (per data-inventory.md).
• Approximate number of affected data subjects.
• Approximate number of records.
• Likely consequences for those individuals (reputational, discrimination, financial, physical safety — including in jurisdictions where reproductive health data can carry legal risk).
• Measures taken to address the breach and mitigate its adverse effects.

5. Decision maker

The responsible decision maker (CTO / security officer) approves:

• Whether to notify AEPD.
• Whether to notify affected users.
• Whether to notify sub-processor's incident channel.
• Public disclosure timing (coordinated with legal counsel).

6. Notifications

• AEPD notification — via the AEPD's electronic office. Template to be added to this repo once security officer is named.
• User notification — via in-app banner + email. Must include: nature of the breach, categories and approximate numbers, likely consequences, measures taken, contact for further information.
• Processor cascade — notify our processors if they are affected downstream.

7. Post-incident

• Root-cause analysis published internally within 14 days.
• Remediation plan with owners and dates.
• Lessons integrated into threat-model.md and, where applicable, this file.
• Retrospective log kept for audit.

Contact points (to be filled in before beta)

Role	Person	Backup
Security officer	TBD	TBD
Legal / DPO	TBD	External counsel: TBD
Product engineering lead	TBD	TBD
Communications	TBD	TBD
AEPD registration record	TBD	—

Testing

Run one tabletop exercise per quarter starting in the beta period, exercising the full sequence with a fictional but realistic scenario (e.g. "Supabase incident affecting our EU project; ~250 users' cycle data confirmed exposed").