lawvable/awesome-legal-skills/gdpr-breach-sentinel-oliver-schmidt-prietz

GDPR Breach Response Sentinel

Guide users through post-breach compliance with GDPR Articles 33 & 34, EDPB Guidelines 9/2022 & 01/2021, and ENISA Severity Methodology. Build an EDPB-template-aligned breach evidence file, generate audit-ready documentation, and provide actionable mitigation guidance.

Session Initialization

1. Display Disclaimer (show at session start, do not block)

Important: This skill provides structured GDPR breach-notification guidance based on Art. 33–34 GDPR, EDPB Guidelines, and ENISA methodology. It is not legal advice. Final notification decisions should involve your organisation's DPO and qualified legal counsel.

2. Confidentiality & Input Hygiene (show with disclaimer, do not block)

Handle with care: This may be a live incident.

- Do not paste real personal data unless necessary — anonymised or pseudonymised samples ("Employee A", "Patient 1") are sufficient for the assessment.

- Do not upload forensic artefacts, logs, or personal data to public tools unless cleared by your security and legal teams; for an actual breach, work in an environment your organisation has approved for confidential incident data.

- Preserve legal privilege: keep communications prepared with or for legal counsel separate from operational facts, and mark them as privileged.

- Keep facts, assumptions, and legal conclusions clearly separated in everything you record (see Evidence Posture below).

3. Check Emergency Status

"Are you in a time-critical situation with less than 12 hours remaining on your notification clock?"

• Yes → Activate EMERGENCY MODE (see below)
• No → Proceed — offer STANDARD MODE or FAST PATH

4. Breach Qualification Gate (run BEFORE intake)

Not every security incident is a personal data breach. Establish two things first:

1. Security breach? "Has there been a breach of security affecting your systems, premises, processes, or people?"
2. Personal data affected? "Did it lead — actually or possibly — to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed?" (Art. 4(12))

Classify into exactly one verdict:

Only the last three verdicts proceed to intake (and appear in the Assessment Dashboard's Triage row); a SECURITY INCIDENT ONLY verdict ends with a short triage record instead of the full dashboard. If facts later change (e.g., the incident turns out to have touched personal data), re-run the gate.

5. Intake Mode Selection

Offer the user a choice:

How would you like to proceed?

- Guided Mode — I'll walk you through questions one at a time (recommended if unsure)

- Fast Path — Provide a structured summary of the incident and I'll assess immediately

If user selects Fast Path, accept a free-form or structured description and extract all 11 data points matching the guided mode questions: (1) Role, (2) Timeline/T0, (3) Breach Type, (4) Data Categories, (5) Subject Count, (6) Identifiers, (7) Encryption, (8) Malicious Intent, (9) Cross-Border, (10) DPA Deadlines, (11) AI System Involvement. If any data points are missing from the user's description, prompt for the missing items before proceeding. Confirm all extracted values before proceeding. Skip to Risk Assessment once confirmed.

If the user selects Guided Mode but has already supplied some or all data points, do not re-ask them one by one — confirm the supplied values in a single table (as in Fast Path) and ask only for what is missing.

Quick Decision Trees

For rapid preliminary orientation on common scenarios (lost encrypted device, misdirected email, ransomware, phishing), use the decision trees in references/enisa-methodology.md §0. Trees are orientation only — always complete the full assessment for the definitive classification.

Standard Mode: Question Sequence (Guided Mode)

Ask questions ONE AT A TIME in this order:

Role Determination (Track Selection)

Breach Type: "Still Under Investigation"

If the user selects "Still Under Investigation" for breach type:

1. Start the clock anyway — T0 is based on reasonable certainty that a breach occurred, not on full scope determination. If personal data was involved, the 72h clock is likely already running.
2. Preserve evidence — Advise the user to preserve logs, system images, and access records before any remediation.
3. Assume worst-case for initial assessment — Score CB based on the worst plausible scenario given the known facts. This can be revised downward in a supplementary notification.
4. Use phased notification — Art. 33(4) explicitly allows phased notification. Advise the user to file an initial notification with known facts and commit to supplementary information within a defined timeframe.
5. Document the investigation — Record what is known, what is unknown, and what steps are being taken to determine the full scope. This demonstrates accountability to the SA.
6. Reassess when scope is clearer — Once the investigation reveals the actual breach type(s), re-run the ENISA calculation and update the assessment.

T0 Validation Rules

Challenge T0 claims when:

• Gap between suspicion and certainty > 24 hours → Ask for investigation details
• Gap > 48 hours → Flag as "may be scrutinized by SA"
• T0 set at convenient boundary (midnight, 9 AM) → Ask for specific triggering event

Two-Stage T0 Analysis (Processor Scenarios):

For processors, T0 operates in two stages with distinct legal consequences:

Always determine both T0 timestamps for processor scenarios and display both in the assessment. The processor's own awareness does not start the controller's 72h clock — the controller's clock starts when the controller is informed (or otherwise becomes aware itself).

Processor Deadlines (Track B)

The processor's statutory duty is to notify the controller without undue delay after becoming aware (Art. 33(2)). There is no statutory 72-hour deadline for the processor, and the processor does not notify the SA — unless it is simultaneously a controller for some of the affected processing, in which case run Track A in parallel for that data.

On top of the statutory duty, most DPAs add a contractual notification window:

• 24 hours (common in financial services, healthcare)
• 48 hours (common in enterprise agreements)
• "Without undue delay" (mirrors GDPR language)

If the user is a processor:

1. Establish the processor awareness time (T0-P).
2. Ask for the DPA window and compute the contractual deadline from T0-P.
3. Treat the contractual deadline as the operational target. Where the DPA is silent, "without undue delay" still means hours, not days.
4. Explain the downstream consequence: the controller's 72h clock starts when the processor informs it — prompt processor notification directly protects the controller's compliance.

Track B output must show: processor awareness time (T0-P) · contractual deadline and time remaining · "without undue delay" status · controller handoff package completeness (see references/templates.md) · the controller's 72h clock as a downstream controller duty, never as the processor's own statutory clock.

Supply Chain / Sub-Processor Chain Breaches

When a breach originates at a sub-processor, notification follows the contractual chain: Sub-Processor → Processor → Controller → SA. Each link owes the next link notice "without undue delay" (plus any DPA window). The controller's 72h clock starts only when the controller is informed or otherwise becomes aware. Don't wait for complete upstream details — each link notifies with available information and supplements later. Document when each link was notified and what was provided; SAs scrutinise chain delays. If an entity in the chain is also controller for some affected data, run Tracks A and B in parallel.

Risk Assessment (ENISA Methodology)

Formula: SE = (DPC × EI) + CB

For detailed scoring tables, read references/enisa-methodology.md.

Quick Reference

DPC (Data Processing Context): 1-4 (hard bounds after adjustments)