Data Breach Response

Tools

Breach Severity Calculator

Calculates ENISA breach severity score from breach parameters. Determines notification obligations based on severity verdict.

# Calculate severity from parameters
python scripts/breach_severity_calculator.py \
  --dpc 3 --ei 0.75 \
  --confidentiality 0.5 --integrity 0.25 --availability 0 \
  --malicious

# JSON output
python scripts/breach_severity_calculator.py \
  --dpc 2 --ei 0.5 --confidentiality 0.5 --json

# With T0 timestamp for countdown
python scripts/breach_severity_calculator.py \
  --dpc 3 --ei 1.0 --confidentiality 0.5 \
  --t0 "2026-04-10T08:00:00" --json

# Generate input template
python scripts/breach_severity_calculator.py --template

Output includes:

• ENISA severity score (SE)
• Severity verdict: LOW / MEDIUM / HIGH / VERY HIGH
• Notification obligations (SA, data subjects, public)
• Time remaining for GDPR 72h notification from T0

Breach Timeline Tracker

Tracks breach response timeline from T0 (moment of awareness). Records events, monitors deadlines, and generates status dashboards.

# Initialize a new breach timeline
python scripts/breach_timeline_tracker.py init \
  --breach-id "BR-2026-001" --t0 "2026-04-10T08:00:00" \
  --description "Unauthorized database access" \
  --output breach_timeline.json

# Record an event
python scripts/breach_timeline_tracker.py event \
  --timeline breach_timeline.json \
  --action "Containment team activated" --category containment

# View status dashboard
python scripts/breach_timeline_tracker.py status --timeline breach_timeline.json

# Check deadlines
python scripts/breach_timeline_tracker.py deadlines --timeline breach_timeline.json

# JSON status output
python scripts/breach_timeline_tracker.py status --timeline breach_timeline.json --json

Tracks:

• GDPR 72-hour SA notification deadline
• DPA contractual deadlines (24h / 48h processor notification)
• NIS2 24-hour early warning and 72-hour notification
• Completed vs. pending response actions
• Time elapsed and time remaining per deadline

Reference Guides

ENISA Methodology

references/enisa_methodology.md

Complete ENISA breach severity methodology:

• DPC (Data Processing Context) scoring 1-4
• EI (Ease of Identification) scoring 0.25-1.00
• CB (Circumstances of Breach) additive scoring
• Formula: SE = (DPC x EI) + CB
• Adjustments for encryption, pseudonymization, volume
• EDPB case matching (18 reference cases)

Notification Obligations

references/notification_obligations.md

Multi-regulation notification requirements:

• GDPR Art. 33 (SA within 72h) and Art. 34 (data subjects)
• CCPA, HIPAA, PCI DSS, NIS2, state breach notification
• Controller vs. Processor obligation matrix
• Cross-border notification rules
• AI Act Art. 62 serious incident reporting

Workflows

Workflow 1: Standard Breach Response

Step 1: Emergency check — is there <12h remaining on any deadline?
        → If yes, skip to Step 4 (emergency notification)

Step 2: Initialize breach timeline
        → python scripts/breach_timeline_tracker.py init --breach-id "BR-2026-001" \
          --t0 "2026-04-10T08:00:00" --description "Description"

Step 3: Calculate severity
        → python scripts/breach_severity_calculator.py --dpc N --ei N \
          --confidentiality N --integrity N --availability N [--malicious]

Step 4: Based on severity verdict, determine notifications
        → LOW (<2): Internal log only, no external notification
        → MEDIUM (2 to <3): Notify supervisory authority within 72h
        → HIGH (3 to <4): Notify SA + individual data subjects
        → VERY HIGH (>=4): Notify SA + data subjects + consider public notice

Step 5: Execute containment and record events
        → python scripts/breach_timeline_tracker.py event --timeline breach.json \
          --action "Action taken" --category containment

Step 6: Monitor deadlines continuously
        → python scripts/breach_timeline_tracker.py deadlines --timeline breach.json

Step 7: Complete notification obligations and document

Workflow 2: Emergency Mode (<12h Remaining)

Step 1: Calculate severity immediately
        → python scripts/breach_severity_calculator.py --dpc N --ei N \
          --confidentiality N --t0 "original-t0" --json

Step 2: If MEDIUM or higher, prepare phased notification
        → Art. 33(4) allows phased notification when full information unavailable
        → Initial notification: what is known + promise of update
        → Supplementary notification: full details when available

Step 3: File initial SA notification before deadline expires

Step 4: Initialize timeline for ongoing tracking
        → Continue gathering information for supplementary notification

Step 5: Document emergency timeline and decisions

Workflow 3: Processor Breach Notification

Step 1: Processor becomes aware of breach
        → T0 for processor = moment of awareness

Step 2: Processor must notify controller "without undue delay"
        → Check DPA for specific contractual deadline (24h/48h common)

Step 3: Controller's T0 starts when controller becomes aware
        → Controller's 72h clock starts at this point

Step 4: Controller assesses severity independently
        → python scripts/breach_severity_calculator.py (controller's assessment)

Step 5: Controller makes notification decisions
        → Processor provides information; controller decides on SA/subject notification

ENISA Severity Formula

SE = (DPC x EI) + CB

Severity Verdicts

Notification Decision Matrix

Quick reference for notification obligations per regulation and severity.

Controller vs. Processor Obligations

Troubleshooting

Success Criteria

• Breach severity calculated within 2 hours of awareness -- ENISA methodology applied with documented parameters and scoring rationale
• SA notification filed within 72 hours of T0 -- for MEDIUM or higher severity breaches, phased notification used when full information unavailable
• Data subject notification completed without undue delay -- for HIGH or higher severity breaches, clear communication of impact and protective measures
• All response actions tracked with timestamps -- breach timeline maintained from T0 through closure with all events recorded
• Cross-regulation obligations identified and met -- GDPR, CCPA, HIPAA, PCI DSS, NIS2, and AI Act obligations assessed and fulfilled per applicable law
• Post-breach documentation complete -- internal breach log maintained per Art. 33(5) regardless of notification decision

Scope & Limitations

In Scope:

• ENISA breach severity calculation with full parameter support
• GDPR Art. 33/34 notification timeline tracking
• Multi-regulation notification obligation assessment (GDPR, CCPA, HIPAA, PCI DSS, NIS2, AI Act)
• Controller vs. processor obligation guidance
• Cross-border breach notification routing
• Phased notification guidance per Art. 33(4)
• Breach response event tracking and deadline monitoring

Out of Scope:

• Technical incident containment (network isolation, forensics, malware removal)
• Filing notifications with supervisory authorities (document preparation only)
• Insurance claim processing or coverage analysis
• Law enforcement coordination
• Public relations or crisis communications strategy
• Forensic investigation methodology

Anti-Patterns

• Delaying T0 determination to buy more time -- T0 is the moment the controller becomes "aware" of the breach, not when full details are known; deliberately delaying awareness to extend the 72-hour window is a compliance violation and will be treated as such by regulators
• Defaulting to no notification without documented analysis -- every breach must be documented and assessed, even if the conclusion is that notification is not required; "we decided not to notify" without documented severity analysis is indefensible
• Treating processor notification as controller notification -- processor notifying its own SA does not satisfy the controller's Art. 33 obligation; the controller must make its own independent notification decision and filing
• Using encryption as an automatic notification exemption -- Art. 34(3)(a) exemption requires that the encrypted data was rendered unintelligible AND the encryption key was not compromised; weak encryption or compromised keys do not qualify
• Ignoring AI Act obligations for AI-involved breaches -- if the breach involves a high-risk AI system, Art. 62 serious incident reporting (15 days to market surveillance authority) applies in addition to GDPR; these are separate obligations with different timelines

Tool Reference

breach_severity_calculator.py

Calculates ENISA breach severity score and determines notification obligations.

breach_timeline_tracker.py

Tracks breach response timeline, events, and regulatory deadlines.