# Runbook — Privacy Incident

> Suspected or confirmed exposure, leakage, unauthorized access, or mis-handling
> of personal data. Includes cross-tenant leakage, DSAR compromise, retention
> violation, consent bypass, and unauthorized processing.

## Scope

Triggers:

- Cross-tenant data exposure (one tenant sees another's data).
- DSAR (Data Subject Access Request) export contains data outside the scope of
  the requesting subject.
- Deletion request not honored within retention window.
- Memory adapter (Iris) writes against the wrong subject identifier.
- Consent withdrawal not propagated to downstream caches/exports.
- Logs or telemetry contain personal data in violation of retention policy.
- Unauthorized access to admin surfaces or audit exports.
- Vendor sub-processor incident affecting Oshun data subjects.

This runbook owns the immediate response. The compliance team owns the regulator
notification and the privacy-by-design remediation backlog.

## Severity classification

| Sev  | Condition                                                                                                                                  |
| ---- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| sev1 | Cross-tenant leakage confirmed, OR DSAR export delivered to wrong subject, OR special-category data (health, minors, biometrics) exposed.  |
| sev1 | Unauthorized admin access or audit-export read by an unauthorized principal.                                                               |
| sev2 | Retention violation discovered (data kept beyond policy), OR consent-withdrawal propagation lag > 24 h, OR PII detected in logs/telemetry. |
| sev3 | Single-record self-report from a subject; no systemic exposure; remediation handled inside the privacy queue without incident declaration. |

Source events: `admin.privacy.dsar_*`, `admin.audit.export_*`,
`admin.security.unauthorized_access_detected`, `iris.memory.tenant_mismatch`
from `admin-taxonomy.ts`/`assistant-taxonomy.ts`.

## Detection signals

- Alerts: `memory-access-denied-spike`, `memory-consent-revoke-burst` from
  `alerts-manifest.ts`; the `audit-export-failure` and audit-pipeline alerts for
  evidence-preservation gaps.
- Self-reports: a customer or admin reports the suspected exposure via the
  privacy-report channel.
- Anomaly detection: spike in `auth.session.unusual_location`,
  `admin.rbac.privilege_escalation_attempted`,
  `iris.memory.cross_tenant_detected`.
- Vendor advisory: a sub-processor publishes a security advisory.

## Initial triage (first 15 minutes)

The first action is **evidence preservation**, not mitigation. Mitigation that
destroys evidence creates regulatory exposure.

1. Acknowledge `oshun-compliance-oncall`. Page the privacy lead and the security
   lead in parallel — privacy + security + reliability run a joint incident
   bridge for privacy incidents.
2. **Freeze affected exports and deletions**: enable the privacy-incident freeze
   flag — outstanding DSAR exports and deletion jobs pause in place. Each paused
   job emits `admin.privacy.job_frozen` for the audit trail.
3. **Preserve audit evidence**: enqueue the audit-export job for the affected
   window and the affected tenants. The job runs against a write-once
   preservation bucket. Do not modify the audit pipeline during preservation.
4. **Begin DSAR impact assessment**: scope the affected subject set, the data
   classes involved, the geographies, and the time window. Use the
   `admin.privacy.impact_scope_recorded` event to capture the scope as a
   structured admin record.

## Diagnosis

1. Identify the failure mode using the structured event taxonomy:
   - Cross-tenant memory: `iris.memory.cross_tenant_detected` — confirm the
     offending request, the tenant boundary, and whether any data was actually
     read or only attempted.
   - DSAR export miss: `admin.privacy.dsar_export_completed` with
     subject-mismatch flag.
   - Deletion miss: `admin.privacy.deletion_requested` with
     `deletion_verified=false` after the retention window.
   - Consent withdrawal lag: `admin.privacy.consent_revoked` followed by
     downstream events still showing consent=true.
2. Confirm exposure scope by cross-referencing the audit pipeline. Do not
   estimate the cohort; query the audit store for the exact set of subjects
   whose records were read, exported, or processed.
3. Determine notification obligations:
   - GDPR Article 33 (regulator) within 72 hours.
   - GDPR Article 34 (subject) without undue delay if high-risk.
   - CCPA / state laws per residency mapping.
   - Tenant-contract obligations (B2B notification windows).
   - Vendor-incident obligations per the sub-processor agreement.

## Mitigation

1. **Stop the bleed** by the failure mode:
   - Memory cross-tenant: set `memory.writes_enabled=false` per
     `assistant-failure.md` step 1, then disable reads until the tenant boundary
     is verified.
   - DSAR scope miss: pause the DSAR export pipeline, audit the last 30 days of
     exports, and resend correctly-scoped exports only after a tenant + subject
     re-verification step.
   - Deletion miss: re-run the deletion job with the corrected predicate against
     the preservation bucket, then verify with a deletion-audit pass.
   - Consent lag: force-flush the consent cache and re-run consent-aware
     downstream jobs for the affected subjects.
2. **Notify privacy/legal**: privacy lead drafts the regulator and subject
   notifications using the `incident.regulator.email.resolved` and
   `incident.customer.email.resolved` templates as the structural baseline, then
   customizes per jurisdiction. Legal review is mandatory before send.
3. **Revoke access**: if unauthorized access is suspected, rotate the
   compromised credentials, invalidate sessions for the affected admin
   principals, and force re-MFA. Capture the revocation actions as audit events.
4. **Vendor incident**: notify the sub-processor relationship owner; request the
   vendor's incident packet; assess whether to pause the integration via the
   vendor circuit-breaker.

## Communication cadence

Privacy incidents are **always** internal-first. Customer/regulator comms happen
only after legal review.

| Phase                  | Template ID                                        | Audience          | Cadence                       |
| ---------------------- | -------------------------------------------------- | ----------------- | ----------------------------- |
| Internal (immediate)   | `incident.internal.slack.investigating`            | internal          | within 5 min                  |
| Leadership (immediate) | `incident.leadership.email.resolved` (adapt)       | leadership        | within 30 min                 |
| Regulator (Article 33) | `incident.regulator.email.resolved` (adapt)        | regulator         | within 72 h (GDPR) per region |
| Subject                | `incident.customer.email.resolved` (adapt)         | customer          | per Article 34 / state law    |
| Partner/tenant         | `incident.partner.email.identified`                | partner           | per contract                  |
| Postmortem             | `incident.customer.status_page.postmortem` (adapt) | status_page/legal | per regulator order if any    |

Always co-author the customer- and regulator-facing text with legal. Do not
publish a status-page entry that names a tenant or subject.

## Escalation

- Compliance lead is the incident commander; security lead and privacy lead
  co-lead.
- For sev1, executive on-call is paged at minute 0, not by standard escalation
  timing — privacy incidents do not wait for the escalation ladder.
- Legal counsel is paged at sev1 minute 0 and at sev2 within 30 min of
  declaration.

## Recovery verification

- No new `cross_tenant_detected` or DSAR-mismatch events for 24 h.
- Re-issued exports / re-run deletions verified against the preservation bucket.
- Audit-export of the incident window archived with a write-once seal.
- Regulator and subject notifications delivered and tracked.
- Vendor incident resolved per sub-processor SLA, or the integration remains
  paused with an exit plan.

## Post-incident

- Privacy postmortem produced **with legal review**, filed in the
  privacy-incident registry. The postmortem includes: subject set, data classes,
  time window, root cause, evidence preserved, notifications delivered,
  remediation owners, and a privacy-by-design backlog item.
- Update the residency, retention, or consent policy if the incident revealed a
  policy gap.
- Update the privacy-impact-assessment template if a new failure mode is now in
  scope.
- Schedule the next privacy operator training to include the incident pattern
  (anonymized) as a scenario drill.