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:

Triage Verdict	Meaning	Next Step
SECURITY INCIDENT ONLY	No personal data affected (e.g., DDoS against a static site, malware on a system holding no personal data)	Art. 33/34 not triggered. Document why no personal data was involved (offer a short internal security-incident record, .docx), advise preserving that documentation, screen parallel regimes (NIS2 etc.), and stop the GDPR workflow — no dashboard, no ENISA run
BREACH CONFIRMED	Personal data demonstrably affected	Proceed to intake — the 72h clock analysis applies
BREACH LIKELY — UNDER INVESTIGATION	Personal data probably affected but not yet confirmed	Proceed to intake; treat T0 conservatively and use the "Still Under Investigation" pathway
INSUFFICIENT FACTS	Cannot yet say whether personal data is affected	Preserve evidence (logs, system images, access records), define fact-finding actions with owners and deadlines, re-triage as soon as facts emerge

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:

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? (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 without undue delay; prepare provisional factual/risk support package; final Art. 33/34 decision remains with the controller
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 (T0-P)	Processor becomes aware of the breach	Notify the controller "without undue delay" (Art. 33(2))	Statutory: without undue delay; contractual: per DPA (often 24-48h)
Stage 2: Controller T0	Controller is informed by the processor (per EDPB Guidelines 9/2022, the controller should be considered "aware" once the processor has informed it)	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 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)

Category	Score
Simple (name, contact)	1
Behavioral (location, browsing)	2
Financial (bank, salary)	3
Sensitive Art. 9 (health, biometric)	4

DPC Cap Rule: After applying contextual adjustments (see enisa-methodology.md), the final DPC is capped at 4.0 and floored at 1.0. Where adjustments would exceed the cap (e.g., Art. 9 base 4 + vulnerable subjects +3 = theoretical 7), note the excess factors as qualitative aggravating circumstances in the Strategic Advisory — they reinforce severity but do not change the numeric score.

EI (Ease of Identification): 0.25-1.00

Level	Score
Negligible	0.25
Limited	0.50
Significant	0.75
Maximum	1.00

CB (Circumstances): 0-2 (additive)

• Confidentiality loss: 0 / +0.25 / +0.50
• Integrity loss: 0 / +0.25 / +0.50
• Availability loss: 0 / +0.25 / +0.50
• Malicious intent: +0.50

Severity Verdicts (Presumptive)

SE Score	Level	Presumptive action (subject to Art. 33/34 legal test)
< 2	LOW	Presumption: internal log only (Art. 33(5))
2 – < 3	MEDIUM	Presumption: SA notification (Art. 33)
3 – < 4	HIGH	Presumption: SA + Data Subjects (Art. 33 & 34)
≥ 4	VERY HIGH	Presumption: SA + Subjects + consider public communication

The Legal Test — Art. 33/34 Bridge (MANDATORY)

The ENISA score informs the legal assessment; it does not mechanically determine notification duties. The statutory triggers are normative legal tests:

• Art. 33(1): notify the SA unless the breach is "unlikely to result in a risk to the rights and freedoms of natural persons". If you cannot positively conclude "unlikely", the presumption is to notify.
• Art. 34(1): communicate to data subjects when the breach is "likely to result in a high risk" to rights and freedoms — unless an Art. 34(3) exception applies (see Art. 34 Decision Module below).

Every assessment MUST contain a written bridge from score to conclusion:

LEGAL BRIDGE
ENISA score:      [SE value + level]
Key facts:        [what happened, to whose data, at what scale]
Safeguards:       [in place before the breach / applied after]
Likely impact:    [likelihood & severity of consequences for individuals]
→ Art. 33(1):     [NOTIFY SA / NO — unlikely to result in a risk, because …]
→ Art. 34(1):     [NOTIFY SUBJECTS / NO — no high risk, because … /
                   NO — exception Art. 34(3)(a)/(b)/(c) applies, because …]

If the legal conclusion diverges from the score's presumption — in either direction — state why in writing. The score creates a presumption; the bridge is the decision. A worked example is in references/enisa-methodology.md §4a.

Borderline Score Guidance

When a score is within 0.25 of a threshold (2.0 / 3.0 / 4.0), explicitly note this in the assessment, apply the borderline guidance table in references/enisa-methodology.md §4b, lean conservative, and recommend the user discuss the borderline classification with their DPO or legal counsel.

Flags to Apply

Flag	Condition	Effect
🚩 SCALE	>100 individuals	Increased SA scrutiny
🔒 ENCRYPTED	Data encrypted, key secure	May support Art. 34(3)(a) exception
👶 VULNERABLE	Minors, patients	Consider upgrading notification
⚠️ CROSS-BORDER	Cross-border processing	One-stop-shop analysis (see Cross-Border Rules)
🇬🇧 UK SUBJECTS	UK residents affected	Separate ICO notification required (see UK note below)
🤖 AI SYSTEM	AI system involved	Check AI Act Art. 73 obligations

UK GDPR Note: For UK-resident data subjects, ICO guidance may differ from EDPB recommendations. The UK is not bound by EDPB guidelines — it follows ICO guidance under the UK GDPR and Data Protection Act 2018. The ENISA methodology provides a useful analytical framework, but ICO's own risk assessment approach should also be consulted. Always use the ICO's self-assessment tool when available, and note that the ICO has its own notification portal and forms separate from any EU SA.

---

Evidence Posture (include in EVERY assessment)

Defensible breach decisions separate what is known from what is assumed. Every assessment output must contain:

EVIDENCE POSTURE
Established facts:       [verified, with source — logs, forensics, admissions]
Working assumptions:     [explicitly labelled, with their basis]
Material unknowns:       [what is not yet known that could change the verdict]
Evidence still needed:   [next fact-finding actions — owner, deadline]
Confidence level:        [HIGH / MEDIUM / LOW]
Impact on notification:  [how the unknowns affect the Art. 33/34 conclusions]

Never present an assumption as a fact. Phased notification (Art. 33(4)) exists precisely so that incomplete facts do not delay the initial notification.

---

AI Act Intersection (Art. 73 Check)

If the user confirms the breach involves an AI system, perform an additional assessment:

1. Classification: Is this a high-risk AI system (AI Act Annex III, or a product-embedded system under Annex I)? Is it deployed in a regulated sector (healthcare, law enforcement, critical infrastructure)?
2. Serious incident test (Art. 3(49)): Does the incident directly or indirectly lead to (a) the death of a person or serious harm to a person's health; (b) a serious and irreversible disruption of the management or operation of critical infrastructure; (c) an infringement of obligations under Union law intended to protect fundamental rights; or (d) serious harm to property or the environment?
3. If yes → Art. 73 reporting: The provider (or, where applicable, the deployer) reports to the market surveillance authority of the Member State(s) where the incident occurred — immediately after establishing a causal link between the AI system and the incident (or its reasonable likelihood), and at the latest 15 days after awareness. Shortened deadlines: 2 days for widespread infringement or a critical-infrastructure incident under Art. 3(49)(b); 10 days in the event of death. An initial incomplete report followed by a complete report is permitted.
4. Applicability: Art. 73 applies from 2 August 2026 (high-risk systems embedded in Annex I regulated products: 2 August 2027; sectoral reporting equivalences under Art. 73(9)-(10)). Before the applicable date, state that the duty "will apply from" that date — it is not yet a live obligation.
5. Parallel obligations: Art. 73 runs in parallel to GDPR notification — separate obligations, separate recipients, separate deadlines.

Full detail (definitions, deadlines, deferrals): read references/parallel-regimes.md.

Output

When the AI SYSTEM flag is set, insert this block into the Assessment Dashboard as its own AI ACT STATUS section (placed before LEGAL VERDICT), in addition to the one-line AI Act Art. 73 row:

AI ACT STATUS: [Applicable / Not Applicable / Not Yet Applicable / Requires Further Assessment]
Art. 73 Reporting: [Required / Not Required / Not Yet Applicable / Under Assessment]
AI System Classification: [High-Risk Annex III / High-Risk Annex I product-embedded / Limited Risk / Minimal Risk / Not Classified]

Do not take the user's Annex III classification at face value: a CE-marked medical device or other Annex I regulated product is product-embedded high-risk (application 2 Aug 2027; Art. 73(9)-(10) defer largely to sectoral vigilance regimes such as MDR/IVDR, which may impose live reporting duties today). Recommend verifying with the user's regulatory team.

---

Sectoral Parallel-Regime Screen

A personal data breach often triggers duties outside the GDPR. Run a lightweight screen after the GDPR assessment — or directly at triage exit for SECURITY INCIDENT ONLY verdicts — identify, do not analyse in depth unless the user asks:

Regime	Trigger Hint
NIS2 / national implementation	Essential/important entity with a significant ICT incident — if the nis2-navigator skill is available, use it for that track
DORA	Financial entity with an ICT-related incident
eIDAS	Trust service provider
AI Act Art. 73	High-risk AI system serious incident (see above)
ePrivacy / telecoms	Provider of publicly available electronic communications services
Criminal law	Report to police/judicial authorities (also an EDPB template field)
Insurance	Cyber policy notification clauses — often short windows
Contracts	Customer/partner notification clauses beyond DPAs
Employment	Works council / employee representative involvement where employee data is affected (especially in Germany)

Output line for the dashboard: "Potential parallel regimes identified: [list] — not assessed in detail unless requested." Details and screening questions: references/parallel-regimes.md.

---

EDPB Case Matching

After risk assessment, match to EDPB Guidelines 01/2021 cases. See references/edpb-cases.md.

Categories:

• Ransomware: Cases 01-04
• Data Exfiltration: Cases 05-07
• Internal Human Risk: Cases 08-09
• Lost/Stolen Devices: Cases 10-12
• Mispostal: Cases 13-16
• Social Engineering: Cases 17-18

Analogy warning: EDPB cases are illustrative analogies, not binding decisions. Factual differences matter, and an analogy never replaces the Art. 33/34 legal test on the actual facts. State the closest case, the limits of the analogy, and where your facts differ (see the analogy rules in the reference).

Output format:

"This scenario resembles EDPB Case [XX]: [Description]. EDPB recommendation: SA [YES/NO], Subjects [YES/NO]. Your situation differs in: [differences]. Limits of the analogy: [limits]. This [supports/suggests reconsidering] your calculated verdict."

---

Dynamic Web Research Module

After completing the ENISA calculation and EDPB case matching, automatically perform targeted web research to enrich the assessment. Read references/web-research.md for specific query templates (enforcement precedents, SA-specific guidance, sector trends, EDPB updates, AI Act, damages precedent) and how to incorporate findings. Apply the source discipline rules in that reference: official sources (SA / EDPB / Commission) first, no SEO or marketing pages as the basis for legal conclusions, cite access dates, and never invent portal links or SA contact details. Add a "Regulatory Intelligence" section to the Assessment Dashboard.

---

Cross-Border Rules

First: Is It Actually Cross-Border Processing?

One-stop-shop requires genuine cross-border processing (Art. 4(23)) — processing in the context of establishments in more than one Member State, or processing that substantially affects individuals in more than one Member State. Do not assume cross-border processing merely because affected individuals live in several Member States — the test is the processing, not subject residence. Analyse before applying the one-stop-shop.

Controllers WITH EU Establishment

• Notify Lead SA only (one-stop-shop), where a main establishment and lead SA can be determined
• Lead SA = location of main establishment
• Indicate affected Member States in the notification (the EDPB template asks for per-country subject counts)

Controllers WITHOUT EU Establishment

• One-stop-shop does NOT apply — the mere presence of an EU representative does not trigger it (EDPB Guidelines 9/2022 v2.0, para 73)
• Notify EACH SA where affected subjects reside in their Member State
• Track submissions individually; national portals may require local formats and fields

Lead SA Determination Questions

1. "Where are decisions about this data processing made?"
2. "Where is your central administration?"
3. "Which establishment has authority over this processing?"

SA Contact Directory