Incident response

Decide now, execute calmly later. Each runbook is ordered — do the containment step first, understand second, remediate third. Every action you take is itself audit-logged, which is exactly what you’ll want afterwards.

Runbook 1 — Fraud wave (spike in tamper signals / rejections)

Detect: monitoring alerts on repeated tamper-signal phrasing, retry clusters, or a rejection-rate step change.

1. Contain: if the wave targets one product, pause that product’s verification entry point (its UI), not the whole service. For a broad attack, temporarily tighten: raise the AI confidence floor and face-match threshold — more reviews, no bad auto-approvals.
2. Understand: pull the affected verifications; a reviewer inspects the actual documents in the vault. Same forgery template? Same document country? Same network origin (your edge logs)?
3. Sweep backwards: query for approved verifications sharing the pattern’s fingerprints from before detection. If any exist, treat as suspect: re-verify those users or suspend downstream access.
4. Remediate: add the pattern to the AI inspection prompt (it takes free-text guidance), and to reviewer guidance. File a hardening-roadmap entry.
5. Record: write the incident summary; if you’re an AML/CFT reporting entity, assess whether a Suspicious Activity Report is triggered.

Runbook 2 — API key exposed

Detect: key found in a repo/log, or anomalous usage from its fingerprint.

1. Contain (minutes): append a fresh key to BAQSHI_API_KEYS, deploy the consuming backend with it, remove the old key from the list. Old key dies instantly, service never blips.
2. Understand: audit-query everything the old fingerprint did since exposure — creations, status reads (data exposure!), attestations, erasures.
3. Remediate: any PII read via GET /v1/verifications/{id} during the window is a potential privacy breach — assess against Runbook 4.

Runbook 3 — Handoff token abuse

Low severity by design (tokens can’t read data), but noisy.

1. Revoke active tokens for affected verifications (DB: revoked = true).
2. Check uploaded artifacts on those verifications — garbage uploads simply fail the pipeline; nothing auto-approves.
3. If it’s volume abuse, tighten the capture rate-limit rule or front with a WAF.

Runbook 4 — Suspected data exposure

The nightmare scenario, pre-decomposed:

1. Scope by tier — this decides everything:
   • Database only → attacker has statuses, hashes, wrapped keys. No images, documents, or biometrics are exposed (wrapped keys are useless without the master key). Names/DOBs of verified users are in the DB — that subset is the exposure.
   • Vault/archive blobs only → ciphertext. No exposure.
   • Blobs and master key → full exposure of non-erased artifacts. Worst case.
2. Contain: rotate the master key (re-wrap procedure in Keys & encryption), rotate all API keys, revoke live handoff tokens, snapshot the audit chain and verify its integrity.
3. Assess notification duties: under the Privacy Act 2020, a breach likely to cause serious harm must be reported to the OPC and affected individuals. Identity-document exposure for named individuals almost certainly qualifies. Middle East / other jurisdictions: check their regimes for affected residents.
4. Remediate: close the vector, then honour any user deletion requests with cryptographic erasure — it works retroactively on stolen encrypted media.

Runbook 5 — Wrongly approved user (discovered after the fact)

1. Suspend the user in the consuming product (attestations already issued stay mathematically valid — act at the product layer).
2. Reviewer re-examines the vault artifacts; record the corrected finding via the review endpoints so it lands in the audit chain.
3. Trace the miss to a signal gap or threshold, then tune — that’s the feedback loop working as intended.

Contacts template

Keep this filled in and next to your pager:

Service operator:      [you]
Deploy access:         Railway project baqshi-kyc
Key custodian:         [who holds the offline master-key copy]
Reviewer on call:      [who works the review queue]
Privacy officer:       [who owns OPC notification decisions]