lakehouse/docs/runbooks/BIPA_DESTRUCTION_RUNBOOK.md

BIPA Biometric Data Destruction Runbook

Spec: docs/PHASE_1_6_BIPA_GATES.md §1 Gate 5 (BIPA §15(a)) Audience: Operators (J + named operators with legal-tier credentials) Status: Engineering scaffold — ⚖ COUNSEL must review for legal sufficiency before adoption

This runbook tells an operator HOW to destroy biometric data when a destruction trigger fires. It is a procedural document, not a design document. The cryptographic substrate that the destruction writes against (per-subject HMAC audit log + tombstone manifests) already ships in crates/catalogd/.

---

1. When this runbook fires

Destruction is mandatory when ANY of the following occurs:

Trigger	Source signal	SLA
Retention expiry	Daily retention_sweep flags consent.biometric.retention_until < now	30 days from sweep flagging
Consent withdrawal	Candidate submits withdrawal per consent template §2	30 days from receipt
Right-to-be-forgotten request	Candidate submits RTBF request through documented contact channel	30 days from receipt
Court-ordered erasure	Legal counsel directs erasure via a documented order	Per court order; default 30 days

⚖ COUNSEL — confirm 30 days is correct for all four. Some deployments have stricter contractual or jurisdictional clocks (CCPA: 45 days but sooner is better; GDPR Art. 17: "without undue delay").

---

2. Pre-destruction checks (5 minutes)

Before initiating destruction, the operator MUST:

1. Verify the trigger. Cross-reference one of the four sources above. If the trigger is a candidate-initiated request, confirm identity per the standard PII verification procedure (knowledge factor + possession factor; see counsel for the threshold).

2. Pull the current subject record. Hit GET /audit/subject/{candidate_id} with the legal-tier token. The response includes:

   • The current SubjectManifest (including consent.biometric.status)
   • The full HMAC-chained audit log
   • chain_verified: true (if false, STOP — chain integrity issue must be investigated before destruction)

3. Check for legal hold. ⚖ COUNSEL — if a legal hold can apply to a subject's data (litigation, regulatory inquiry, subpoena), document the procedure for checking that no hold is in force before erasing.

4. Get the second-operator sign-off. Per BIPA defensibility, destruction is a two-operator action (operator-of-record + one witness). The witness records their attestation in the destruction-event audit row (§4 below).

---

3. Destruction procedure

Step 1 — Erase via identityd

Invoke the legal-tier erasure endpoint:

curl -sf -X POST "http://localhost:3100/v1/identity/subjects/${CANDIDATE_ID}/erase" \
  -H "Authorization: Bearer $(cat /etc/lakehouse/legal_audit.token)" \
  -H "Content-Type: application/json" \
  -d '{
    "trigger": "retention_expiry|consent_withdrawal|rtbf|court_order",
    "trigger_evidence_path": "<path to signed artifact>",
    "operator_of_record": "<operator name>",
    "witness": "<witness name>"
  }'

⚖ ENGINEERING — POST /v1/identity/subjects/{id}/erase is Phase 1.6 Gate 3 dependent. Until it ships, the manual procedure is:

a. Set SubjectManifest.consent.biometric.status = "withdrawn" and SubjectManifest.status = "erased" via direct registry write (operator-of-record only). b. Securely overwrite + unlink the quarantined photo path: shred -uvz data/biometric/uploads/${CANDIDATE_ID}/*.jpg (or equivalent for the configured backend). c. NULL the deepface classification fields on the subject row. d. Append the destruction-event audit row (Step 2 below).

Step 2 — Append the destruction-event audit row

The erasure endpoint AUTOMATICALLY writes one row to the subject's per-subject audit log:

{
  "schema": "subject_audit.v1",
  "ts": "<ISO-8601>",
  "candidate_id": "<id>",
  "accessor": {
    "kind": "biometric_erasure",
    "daemon": "identityd",
    "purpose": "biometric_erasure",
    "trace_id": "<X-Lakehouse-Trace-Id>"
  },
  "fields_accessed": ["biometric_classifications", "biometric_data_path", "biometric_template_hash"],
  "result": "erased",
  "prev_chain_hash": "<previous row hmac>",
  "row_hmac": "<new chain link>"
}

The HMAC chain extends through the erasure event, so the audit log itself is preserved as anonymous-event proof of compliant destruction even after the underlying biometric data is gone.

Step 3 — Verify destruction

Run the verification script:

./scripts/staffing/verify_biometric_erasure.sh "${CANDIDATE_ID}"

⚖ ENGINEERING — script TODO. Acceptance:

• Subject row biometric fields are NULL
• data/biometric/uploads/${CANDIDATE_ID}/ directory is empty
• Most recent audit log row has result: "erased", accessor.kind: "biometric_erasure"
• Chain still verifies (chain_verified: true) under the legal-tier endpoint

If any check fails: STOP, do not mark the destruction complete, escalate to engineering.

Step 4 — Notify the candidate (when applicable)

For consent-withdrawal and RTBF triggers, the operator notifies the candidate that destruction is complete. ⚖ COUNSEL — supply the notification template (typically email; medium and language are counsel-determined).

---

4. Backup window disclosure

Per IDENTITY_SERVICE_DESIGN.md v3-B12, biometric data may persist in encrypted system backups for up to 30 days after destruction (rolling backup window). The candidate must be informed of this when destruction is requested, and the destruction-event audit row records the backup-window expiry date so the operator knows when the residual is fully eliminated.

⚖ COUNSEL — confirm whether the 30-day backup window is acceptable under BIPA. Some interpretations require backups to be addressed within a shorter window; some accept the operational reality of backup retention.

---

5. Reporting cadence

Monthly, the operator-of-record produces a destruction-events report:

./scripts/staffing/biometric_destruction_report.sh \
  --month "$(date +%Y-%m)" \
  --output reports/biometric/destruction_$(date +%Y_%m).md

⚖ ENGINEERING — script TODO. The report aggregates:

• Total destruction events in the month
• Breakdown by trigger (retention / withdrawal / RTBF / court)
• Median time-to-destruction from trigger to completion
• Any failures / escalations

The monthly report is available to outside counsel on request. It does NOT include candidate-identifying details — only the counts, timings, and cryptographic attestations of the events.

---

6. Audit trail attestation

The per-subject HMAC chain is the cryptographic substrate that makes destructions defensible after the fact. To produce an attestation for a specific candidate's destruction:

1. Hit GET /audit/subject/{candidate_id} with legal-tier token
2. Confirm chain_verified: true and most-recent row has accessor.kind: "biometric_erasure"
3. Cross-runtime verify: the same audit log is byte-identical under Rust + Go (per scripts/cutover/parity/subject_audit_parity.sh)
4. Counsel signs an attestation referencing the audit log's chain root hash

The chain root hash is itself a tamper-evident anchor. A motivated insider would need the HMAC signing key (held in a separate location from the audit logs themselves, per the spec) AND the original log to forge a clean destruction record — and the cross-runtime parity probe would catch a forgery that touched only one runtime's view.

---

7. Operator acknowledgment

Operators with legal-tier credentials acknowledge they have read, understood, and will follow this runbook before being granted access to the legal_audit token.

Operator	Date acknowledged	Signature
J	_____	_______________
_____	_____	_______________

⚖ COUNSEL — adopt this acknowledgment as the substrate for §3 of Phase 1.6 (employee training acknowledgment), or specify a separate training program.

---

8. Change log

• 2026-05-03 — Initial scaffold. ⚖ COUNSEL review required before adoption.