Breach response

1. Establish facts: what happened, when it was discovered (the 72h clock starts at awareness), data and number of subjects affected, whether data was encrypted, containment status.
2. Classify: confidentiality / integrity / availability breach.
3. Risk assessment: likelihood and severity of harm to individuals. Decide: no notification (document only) / notify supervisory authority (Art. 33) / also notify data subjects (Art. 34, high risk).
4. Draft the authority notification (nature of breach, categories and approximate numbers, DPO contact, likely consequences, measures taken) and, if needed, the data subject notice in plain language.
5. Produce an internal breach log entry (Art. 33(5)) and a remediation action list.

Always state the deadline and time remaining. Note that processors must notify the controller without undue delay. This is guidance, not legal advice.

Judgement points

• Awareness: the clock starts when the controller has reasonable certainty a breach occurred, not when it happened. Ask whether anyone noticed earlier and note any argument for an earlier start.
• Risk threshold: unauthorised disclosure of identifiable data to an unverified recipient is not "unlikely to result in a risk": notify the authority. A confirmed deletion by a known trusted recipient may support a document-only outcome for small numbers, but record the reasoning. Treat free-text fields as potentially special-category until checked.
• Unconfirmed containment: treat as not contained; escalate to written confirmation and reassess Art. 34.
• Authority: identify the lead authority (main establishment, one-stop-shop) or the one where the controller is established.
• Phased reporting: if facts are incomplete at 72h, notify with what is known and follow up (Art. 33(4)); give reasons for any delay.
• Provide the log entry as a table (ID, occurred, aware, data and subjects, type, cause, risk, notified, containment, rationale, owner, closed) and list missing facts as questions.