Incident Response Playbook

Project: Pickles GmbH — AI Governance Framework Stage: Stage 4 — Monitoring & Operational Controls Status: Draft Version: v1 Date: 2026-02-26 Assumptions: Built on outline assumptions — not verified against real Pickles GmbH data

Purpose

This playbook defines how Pickles GmbH identifies, classifies, escalates, and resolves incidents involving its AI systems. It covers: - Internal incident management (all systems) - EU AI Act Article 73 serious incident reporting obligations (SYS-04, high-risk) - GDPR Article 33/34 personal data breach notification - BDSG §65/66 breach notification under German law - Client notification requirements - Root cause analysis template

[ASSUMPTION] Contact details, escalation paths, and authority assignments are placeholder — must be completed with real names and roles before operational use.

[LEGAL REVIEW REQUIRED] Regulatory reporting obligations under Article 73 and GDPR Article 33 are time-critical and carry legal consequences for non-compliance. This playbook must be reviewed by a qualified legal practitioner before it is relied upon operationally.

1. Incident Definition

1.1 What Is an Incident

For the purposes of this playbook, an incident is any unplanned event or pattern affecting a Pickles GmbH AI system that: - Causes or risks causing harm to a user, client, or third party - Represents a material failure of the system to operate within its intended purpose - Triggers a regulatory reporting or notification obligation - Results in a personal data breach - Causes or risks causing reputational, financial, or legal harm to Pickles GmbH

Monitoring alerts from L3-6.1 that breach defined thresholds are the primary source of incident triggers.

1.2 EU AI Act Serious Incident Definition

Article 3(49) defines a serious incident as an incident or malfunctioning of an AI system that directly or indirectly leads 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) The infringement of obligations under Union law intended to protect fundamental rights - (d) Serious harm to property or the environment

For Pickles GmbH: Article 3(49)(c) — infringement of fundamental rights obligations — is the most likely serious incident category. A materially flawed SYS-04 legal analysis output that is relied upon in legal proceedings without adequate lawyer review, and that causes a demonstrable infringement of a party's right to a fair trial or effective legal representation, could constitute a serious incident under this definition. [LEGAL REVIEW REQUIRED]

A personal data breach (GDPR Article 4(12)) is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed.

2. Incident Examples by System

Example Incident	System	Likely Classification
AI output contains a fabricated case citation relied upon by a lawyer in a court submission	SYS-01, SYS-04	P1 / potential Article 3(49)(c) serious incident
SYS-04 produces systematically flawed analysis for a specific document type (discovered via M-01)	SYS-04	P1 — immediate investigation; possible Article 20 corrective action
User-reported error rate spikes above threshold; root cause unknown	Any system	P2 — investigation; possible escalation to P1
Third-party model provider suffers security breach; client query data may be exposed	SYS-04	P1 — GDPR Article 33 clock starts; potential Article 73 implications
System returns outputs containing personal data from a different user's session (data isolation failure)	Any system	P1 — GDPR Article 33 breach notification; potential data subject notification
Unauthorised model drift detected: outputs changed without authorised update	SYS-04	P2 — activate L3-6.3; assess Article 20/73
Planned maintenance window overruns; system unavailable for 4 hours	Any system	P3 — client notification; no regulatory trigger
Single user complaint about output quality; no pattern detected	Any system	P4 — log and investigate; no escalation

3. Severity Classification

Severity	Definition	Examples	Response Time
P1 — Critical	Actual or probable serious harm to a person; potential Article 3(49) serious incident; confirmed personal data breach; Article 20 non-conformity	Fabricated legal citation in court submission; data breach exposing client personal data; SYS-04 systemic failure	Immediate — within 1 hour of detection
P2 — High	Material quality failure without confirmed harm; unplanned model drift; suspected (unconfirmed) data breach; pattern of errors meeting L3-6.1 alert thresholds	Spike in user error reports; citation accuracy below 90%; unauthorised model drift detected	Within 4 business hours of detection
P3 — Medium	Degraded performance affecting users; planned maintenance overruns; single client escalation with potential pattern	System latency exceeding SLA; extended planned downtime; second client complaint in same category within 30 days	Within 1 business day
P4 — Low	Isolated user complaint; minor quality issue; no threshold breach; no harm	Single user error report; cosmetic output formatting issue; feature request misidentified as defect	Within 3 business days

4. Escalation Paths

P1 — Critical Incident Escalation

Detection (L3-6.1 monitoring / user report / deployer notification)
    │
    ▼ Within 15 minutes
Head of Engineering — confirmed? → If not confirmed: investigate; escalate if confirmed
    │
    ▼ Within 1 hour
AIRO notified — initiates P1 incident log; assigns Incident Commander
    │
    ├─► CEO notified immediately
    ├─► DPO notified immediately (if data breach suspected)
    └─► Legal counsel notified (if Article 73 or GDPR reporting may be required)
    │
    ▼ Within 2 hours
Regulatory clock assessment:
    ├─► EU AI Act Article 73 trigger? → If yes: prepare report; see Section 6
    └─► GDPR Article 33 trigger? → If yes: 72-hour clock starts; see Section 7
    │
    ▼ Ongoing
Incident log updated every 2 hours until resolution
Client notification assessed — see Section 8
System suspension decision if harm ongoing (Article 20)

P2 — High Severity Escalation

Head of Engineering → Head of Product → AIRO (within 4 hours) → CEO (if Article 20 obligations may arise) → DPO (if data-related)

P3 — Medium Severity

Head of Engineering → Head of Product → client notification if SLA breach → AIRO weekly summary

P4 — Low Severity

Head of Product → logged in incident register → reviewed in monthly monitoring report

5. Regulatory Reporting Triggers

5.1 EU AI Act Article 73 — Serious Incident Reporting (SYS-04 Only)

Article 73 applies to SYS-04 (high-risk) only. Reporting is to the market surveillance authority of the Member State where the incident occurred. [ASSUMPTION] For Pickles GmbH, the competent German market surveillance authority must be identified and contact details maintained. [LEGAL REVIEW REQUIRED — confirm which authority is competent for SYS-04 in Germany]

Reporting trigger: Reasonable likelihood that the incident is causally linked to SYS-04, AND the incident meets the Article 3(49) serious incident definition.

Incident Type	Reporting Deadline	Notes
Standard serious incident (Art. 3(49)(a)(c)(d))	15 days from provider awareness of causal link or reasonable likelihood	Initial report may be incomplete (Art. 73(5))
Widespread infringement OR critical infrastructure (Art. 3(49)(b))	2 days from awareness	Immediate notification
Death of a person (Art. 3(49)(a))	10 days from awareness; immediate when causal link suspected	Highest priority

Post-notification obligations (Article 73(6)): - Immediately investigate incident and AI system - Conduct risk assessment of incident - Take corrective action - Cooperate with competent authorities - Do NOT alter the AI system in ways that may affect evaluation of incident causes before informing authorities

Article 20 non-conformity trigger: If the incident indicates SYS-04 is not in conformity with the EU AI Act, Article 20 requires: - Immediate corrective action (up to and including withdrawal/recall) - Notification to deployers (lawyer clients) - If Article 79(1) risk: inform market surveillance authority

Trigger: A personal data breach has occurred (GDPR Article 4(12) definition met).

Deadline: Without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach.

Supervisory authority: [ASSUMPTION] For Pickles GmbH: the Federal Commissioner for Data Protection and Freedom of Information (Bundesbeauftragter für den Datenschutz und die Informationsfreiheit — BfDI), or the relevant Landesbeauftragter depending on Pickles GmbH's registration. [LEGAL REVIEW REQUIRED]

Report must include (Article 33(3)): - Nature of the breach including categories and approximate number of data subjects and records - Name and contact details of the DPO - Likely consequences of the breach - Measures taken or proposed to address the breach

Exception: Notification not required if the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

BDSG §65 parallel obligation: Same 72-hour deadline applies to notification to the Federal Commissioner under the BDSG framework for processing under Part 3 BDSG. [LEGAL REVIEW REQUIRED — confirm which regime applies]

Trigger: Personal data breach is likely to result in high risk to the rights and freedoms of natural persons.

Deadline: Without undue delay.

Exemptions (Article 34(3)): - Affected data was encrypted and unintelligible to unauthorised persons - Subsequent measures have eliminated the high risk - Disproportionate effort — public communication instead

BDSG §66 parallel obligation: Where the breach results in substantial risk to legally protected interests of natural persons, data subjects must be notified without delay. [LEGAL REVIEW REQUIRED]

6. Incident Log Template

A new log entry is created for every incident at P4 or above. Log is maintained by the AIRO.

INCIDENT LOG — [INCIDENT-ID: INC-YYYY-MM-DD-NN]

Date/time detected:
Date/time reported to AIRO:
Detected by:
System affected:
Severity classification (P1/P2/P3/P4):
Incident Commander (P1/P2 only):

DESCRIPTION
What happened:
How detected (monitoring / user report / deployer report / other):
Systems and data affected:
Number of users/clients potentially affected:
Personal data involved? (Y/N):
If yes — categories and approximate number of data subjects:

REGULATORY TRIGGER ASSESSMENT
EU AI Act Article 3(49) serious incident? (Y/N/Under assessment):
If yes — Article 73 reporting deadline:
GDPR Article 33 breach notification required? (Y/N/Under assessment):
If yes — 72-hour clock start time:
GDPR Article 34 data subject notification required? (Y/N/Under assessment):

TIMELINE
[Timestamp] — [Action taken] — [By whom]

CONTAINMENT ACTIONS
Immediate containment steps taken:
System suspended? (Y/N):

CLIENT NOTIFICATION
Clients notified? (Y/N — if P1/P2):
Date/time of client notification:
Method:

REGULATORY NOTIFICATIONS
Article 73 report submitted? (Y/N — SYS-04 serious incidents only):
Submission date/reference:
GDPR Article 33 report submitted?
Submission date/reference:

RESOLUTION
Root cause (summary — full RCA in Section 7 template):
Corrective actions taken:
Date resolved:
Recurrence prevention measures:

SIGN-OFF
AIRO:                    Date:
DPO (if data breach):    Date:
CEO (if P1):             Date:

7. Root Cause Analysis Template

To be completed for every P1 and P2 incident; recommended for significant P3 incidents.

ROOT CAUSE ANALYSIS — [INCIDENT-ID]

1. INCIDENT SUMMARY
   What happened:
   Impact (users affected, data affected, regulatory obligations triggered):

2. TIMELINE OF EVENTS
   [Chronological sequence from first signal to resolution]

3. CONTRIBUTING FACTORS
   Technical factors:
   Process/governance factors:
   Human factors:
   Vendor/third-party factors (if applicable):

4. ROOT CAUSE STATEMENT
   Primary root cause:
   Secondary contributing causes:

5. WHY THE INCIDENT WAS NOT PREVENTED
   What detection or prevention mechanisms should have caught this earlier:
   Why they did not:

6. CORRECTIVE ACTIONS
   | Action | Owner | Target Date | Status |
   |--------|-------|-------------|--------|
   |        |       |             |        |

7. PREVENTIVE MEASURES
   Changes to monitoring (L3-6.1):
   Changes to change management (L3-6.3):
   Changes to vendor contracts (L2-5.3):
   Changes to system design or documentation:

8. RESIDUAL RISK AFTER CORRECTIVE ACTION
   Remaining risk:
   Accepted by (AIRO / CEO):

9. LESSONS LEARNED
   What would have changed the outcome:
   Actions to prevent recurrence across other systems:

10. SIGN-OFF
    Prepared by:           Date:
    AIRO review:           Date:
    DPO review (if applicable): Date:
    CEO approval (P1):     Date:

8. Client Notification Requirements

8.1 When to Notify Clients

[ASSUMPTION] Pickles GmbH notifies lawyer clients in the following circumstances:

Situation	Notification Trigger	Timing
P1 incident affecting client data or outputs	Mandatory	As soon as practical; before regulatory notification where possible
P1 incident where client may have relied on affected outputs	Mandatory	Within 24 hours of classification
System suspension under Article 20	Mandatory	Immediately; before or concurrent with suspension
GDPR personal data breach involving client data	Mandatory (and client's own GDPR Article 33 clock may start)	Without undue delay — client needs information to meet their own obligations as controller
P2 quality incident with pattern affecting client's practice area	Recommended	Within 2 business days
P3 SLA breach	Per contractual SLA terms	Per SLA

8.2 Client Notification Content (P1)

A P1 client notification must include: - Description of the incident in plain language - Systems and outputs affected - Period during which affected outputs were produced - Whether client's data was involved (and what categories if so) - Actions Pickles GmbH has taken - Actions the client should take (e.g., review outputs from the affected period) - Contact point for further information (DPO for data-related; AIRO for AI-related)

9. Post-Incident Review

Every P1 and P2 incident triggers a post-incident review within 30 days of resolution: - AIRO presents RCA findings to CEO and relevant heads - Monitoring thresholds reviewed for adequacy - Playbook updated if gaps identified - If Article 73 was triggered: review whether reporting was timely and complete - ISO/IEC 42001 Clause 10.2 corrective action documented

Document Control

Field	Detail
Document ID	L3-6.2
Next review	Annual; immediately after any P1 incident
Regulatory basis	EU AI Act Articles 3(49), 20, 73, 79; GDPR Articles 33, 34; BDSG §65, §66
Cross-references	L3-6.1 (triggers), L3-6.3 (change management post-incident), L2-5.3 (vendor breach)
Assumptions relied upon	A-001, A-003, A-008, A-009