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#

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.

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.