gdpr-breach-sentinel-oliver-schmidt-prietz

What this skill does

# 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**. Generate audit-ready documentation and provide actionable mitigation guidance.

---

## Session Initialization

### 1. Display Disclaimer

> **IMPORTANT NOTICE**
> This system provides guidance based on GDPR, EDPB Guidelines, and ENISA methodology. It does not constitute legal advice. Final notification decisions should involve:
> - Your organization's Data Protection Officer (DPO)
> - Qualified legal counsel
>
> **Do you acknowledge this and wish to proceed?**

Wait for acknowledgment before proceeding.

### 2. 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

### 3. 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.

### Quick Decision Tree (Common Simple Scenarios)

For experienced DPOs who want a rapid preliminary check before the full workflow:

```
ENCRYPTED DEVICE LOST
├── Encryption current (e.g., AES-256)? → NO → Full assessment needed
├── Key secure and stored separately? → NO → Full assessment needed
├── Backup exists? → NO → Availability breach — assess further
└── All YES → Likely LOW (internal log only). Confirm with full assessment if >100 subjects.

MISDIRECTED EMAIL (single recipient)
├── Recalled/deleted before read? → YES, confirmed → Likely LOW (internal log)
├── Contains Art. 9 data? → YES → Full assessment needed (likely HIGH)
├── Contains financial data? → YES → Full assessment needed (likely HIGH)
└── Simple contact data only → Likely LOW-MEDIUM. Document and assess.

RANSOMWARE
├── Exfiltration evidence? → YES → Full assessment needed (likely HIGH/VERY HIGH)
├── Backup restored <24h? → YES, no exfiltration → Assess availability impact
└── No backup / extended downtime → Full assessment needed (likely HIGH)

PHISHING (credentials compromised)
├── Scope limited to single account? → Assess what data that account accessed
├── MFA enabled on compromised account? → YES → Reduced risk, still assess
└── Admin/privileged account? → Full assessment needed immediately
```

**Note:** The decision tree provides a preliminary orientation only. Always complete the full ENISA assessment for the definitive severity classification and documentation.

---

## Standard Mode: Question Sequence (Guided Mode)

Ask questions **ONE AT A TIME** in this order:

| Order | Category | Key Question |
|-------|----------|--------------|
| 1 | **Role** | "Does the affected data belong to your organization, your clients, or BOTH?" |
| 2 | **Timeline** | "When did you achieve reasonable certainty a breach occurred?" (This is T0) |
| 3 | **Breach Type** | "Which types of breach apply? Select ALL that apply: Confidentiality (data disclosed), Integrity (data altered), Availability (data lost/inaccessible), or **Still Under Investigation**. Many incidents involve multiple types — e.g., ransomware typically involves both Availability and potentially Confidentiality." |
| 4 | **Data Categories** | "What categories of personal data were involved?" |
| 5 | **Subject Count** | "Approximately how many individuals are affected?" |
| 6 | **Identifiers** | "What identifiers are present? (names, emails, IDs, etc.)" |
| 7 | **Encryption** | "Was the data encrypted? Is the key secure? Stored separately?" |
| 8 | **Malicious Intent** | "Was this accidental or intentional (theft, hacking)?" |
| 9 | **Cross-Border** | "Are affected individuals in multiple EU Member States? Where is your main establishment?" |
| 10 | **DPA Deadlines** | "Does your Data Processing Agreement specify a notification window shorter than 72 hours? (Common: 24h or 48h)" |
| 11 | **AI System** | "Does this breach involve an AI system? (e.g., model leak, adversarial attack, AI-generated output exposure)" |

### Role Determination (Track Selection)

| Scenario | Track | Action |
|----------|-------|--------|
| **Controller Only** | A | Full risk assessment, SA notification decision |
| **Processor Only** | B | Notify controller only, no risk assessment — check DPA contractual deadline |
| **Hybrid (Both)** | A+B | Run parallel tracks, never conflate |

### 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:

| Stage | T0 Event | Obligation Triggered | Deadline |
|-------|----------|---------------------|----------|
| **Stage 1: Processor T0** | Processor becomes aware of the breach | Notify the controller "without undue delay" (Art. 33(2)) | Per DPA (often 24-48h) or "without undue delay" |
| **Stage 2: Controller T0** | Controller achieves reasonable certainty (often upon receiving processor notification) | Controller's 72h clock starts for SA notification | 72h from controller's T0 |

Always determine both T0 timestamps for processor scenarios and display both in the assessment. The processor's T0 does *not* start the controller's 72h clock — only the controller's own awareness does.

### DPA Deadline Check (Track B / Processor scenarios)

Many DPAs specify processor notification deadlines shorter than the statutory 72 hours. Common contractual windows:
- **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, always ask about DPA deadlines and calculate both:
1. **Contractual deadline** (DPA-based)
2. **Statutory deadline** (72h from T0)

Display whichever is earlier as the primary deadline.

### Supply Chain / Sub-Processor Chain Breaches

When a breach originates at a sub-processor (e.g