Incident Response Playbook

Implements: Information Security Policy Section 8 (Incident Response) Owner: Security Lead Last Updated: 13 April 2026 Next Review: 13 July 2026

Severity Classification

P1 Critical. Confirmed Breach or Full Outage

Immediate (0-1 hour)

1. Acknowledge the incident in the #incidents Slack channel
2. Assess scope: Which services are affected? What data may be exposed?
3. Contain: If a key is compromised, rotate it immediately via wrangler secret put. If a service is the attack vector, disable it
4. Notify: Alert the ISMS Owner by phone if after hours
5. Open incident doc: Create a Google Doc titled INC-YYYY-MM-DD: [Brief description]

Investigation (1-4 hours)

6. Collect logs: Pull Cloudflare Workers Logs from Grafana Loki via LogQL for the affected time window
7. Identify root cause: Trace the attack path through API logs, access logs, and deployment history
8. Assess data impact: Determine exactly which data categories were exposed (IP hashes? Nullifiers? Keys?)
9. Document findings in the incident doc with timestamps

Notification (within 4 hours for enterprise, 24 hours for standard)

10. Notify affected customers (controllers) per DPA obligations
11. If GDPR personal data breach: Prepare supervisory authority notification (72-hour deadline from discovery)
12. If affecting children’s data: Escalate COPPA notification requirements

Recovery

13. Remediate: Deploy fix, rotate credentials, patch vulnerability
14. Verify: Confirm the attack vector is closed
15. Monitor: Watch for recurrence over 48 hours

Post-Incident (within 5 business days)

16. Root cause analysis: Write up what happened, why, and how it was missed
17. Lessons learned: What detection would have caught this earlier?
18. Action items: Create tickets for preventive measures
19. Update this playbook if the incident revealed a gap

P2 High. Potential Breach or Active Attack

1. Acknowledge in #incidents within 4 hours
2. Investigate: Is this a confirmed breach or a false positive?
3. If confirmed breach: Escalate to P1 procedure
4. If active attack (DDoS, credential stuffing): Enable Cloudflare Under Attack Mode, tighten rate limits
5. If suspicious API key usage: Disable the key, notify the customer, issue a replacement
6. Document in incident doc
7. Post-incident review within 5 business days

P3/P4 Medium and Low

1. Log the event in #security-events Slack channel
2. Assess whether escalation is needed
3. For dependency vulnerabilities: Follow the Vulnerability Management Procedure
4. Track resolution in GitHub Issues
5. Monthly summary of P3/P4 events for management review

Communication Templates

Customer Breach Notification (P1)

Subject: Security Incident Notification. Provii Age Verification Service

Dear [Customer],

We are writing to inform you of a security incident affecting the Provii age verification service. We detected [brief description] on [date/time UTC].

What happened: [Description] What data was affected: [Specific data categories] What we have done: [Remediation steps taken] What you should do: [Any actions required by the customer]

We will provide updates as our investigation progresses. For questions, contact security@maelstrom.au.

Supervisory Authority Notification (GDPR Article 33)

Nature of breach: [Description] Categories and approximate number of data subjects: [Number] Categories and approximate number of personal data records: [Number] Contact details of DPO or contact point: privacy@maelstrom.au Likely consequences: [Assessment] Measures taken or proposed: [Remediation]

Incident Register

All incidents are logged in the incident register with:

• Incident ID (INC-YYYY-NNN)
• Date and time of detection
• Severity level
• Brief description
• Root cause
• Data affected (if any)
• Remediation actions
• Lessons learned
• Status (Open / Resolved / Closed)

The register is reviewed quarterly during management review.

Docs Sandbox KV-Sweep Scenarios

The Phase 0A docs interactive sandbox introduced two prefix classes whose compromise scenarios warrant a documented response procedure: docs-sbx-* (issuer and verifier credential identifiers issued by the docs gateway) and mwallet-sbx-* (mobile sandbox install allowlist entries). Both classes are isolated from production by the controls in UC-186, but the gateway itself stores session, credential, challenge, and install state in Cloudflare KV under TTLs documented in the Data Retention Policy. When a sandbox compromise is suspected, or when a customer-controller withdraws a Developer’s access under the DPA Docs Sandbox Addendum, the procedures below are the primary response.

Triggers

A sandbox KV-sweep is triggered by any of:

• A sandbox-issued credential identifier (docs-sbx-* or mwallet-sbx-*) observed at the production provii-verifier or provii-management ingress (production middleware will reject the request, but the observation itself is a P2 incident).
• Suspected leak of DOCS_SESSION_HMAC_KEY or DOCS_ATTESTATION_ED25519_SEED from the Cloudflare Secrets Store namespace (maintained internally; available to auditors and enterprise customers on request).
• Confirmed Scalar supply-chain compromise (RISK-2026-DOCS-M05) within the docs origin’s __Host-docs_session issuance window.
• Customer-controller written request to terminate a Developer’s sandbox access under the DPA Docs Sandbox Addendum.
• Quarterly rotation rehearsal (planned, not incident).

Severity classification

Sandbox-production isolation breaches are classified as P2 High by default and escalated to P1 Critical if any sandbox-issued credential is observed to have reached a downstream production system that does not implement the prefix rejection middleware. A sandbox-only incident with no production exposure is P3 Medium.

KV-sweep procedure

The KV-sweep procedure removes the affected sandbox state from Cloudflare KV and rotates any compromised key material. It is exercised quarterly as part of the standard sandbox issuer identity rotation rehearsal documented under asset CRYPTO-003 in the Asset Register. Refer to the rollback runbook from in the docs DX delivery tracker for the executable form; the high-level steps are:

1. Identify the affected scope. Determine which prefix classes are in play (docs-sbx-*, mwallet-sbx-*, or both) and which Cloudflare account and Worker the affected KV namespaces belong to.
2. List the affected keys. For each prefix and KV namespace, run wrangler kv:key list --remote --prefix <prefix> against the relevant namespace ID. Capture the output for the audit trail.
3. Sweep delete. For each listed key, run wrangler kv:key delete --remote --namespace-id=<id> <key>. Sweep docs-session:* first (active sessions), then docs-cred-v:* and docs-cred-i:* (credential cache), then docs-chal:* (challenge state), then mwallet-sbx-* (mobile install allowlist), in that order.
4. Rotate compromised key material. If DOCS_SESSION_HMAC_KEY or DOCS_ATTESTATION_ED25519_SEED are implicated, rotate the affected key in the Cloudflare Secrets Store namespace (maintained internally; available to auditors and enterprise customers on request) and update the kid prefix accordingly. Both the old and new keys are retained for the 4-hour session hard-cap window only when the rotation is planned; under compromise, the old key is revoked immediately.
5. Verify the production boundary. Re-run the negative tests covering the production middleware prefix rejection (covered by UC-186 layer 4). Confirm docs-sbx-* and mwallet-sbx-* requests at the production provii-verifier and provii-management still 404 before reaching any handler.
6. Trigger re-issuance. Affected Developers will need to re-authenticate against the docs gateway; bearer tokens issued before the sweep will be invalidated.
7. Log the sweep into the audit pipeline. Each sweep emits a sandbox_kv_sweep event into the audit pipeline with the trigger, prefix classes touched, key counts deleted, and any key material rotated.

Cross-references for sandbox incidents

Rollback runbook reference

The full rollback runbook for sandbox-production isolation breaches is referenced from the deliverable in the docs DX delivery tracker. The runbook covers the Cloudflare Worker rollback (wrangler rollback on provii-demos/demo-web-provii-agegate), the Cloudflare Secrets Store rotation procedure, the negative-test verification checklist for the production middleware prefix rejection, and the customer-notification template under the DPA Docs Sandbox Addendum. The runbook is exercised quarterly as part of the rotation rehearsal and is updated in lockstep with this playbook.

Post-incident review specific to the sandbox

In addition to the standard P1/P2 post-incident review, sandbox incidents trigger the following specific outputs:

• A re-evaluation of the inherent and residual scores for the implicated RISK-2026-DOCS-* entry, ratified at the next quarterly management review.
• A check whether the Children’s Code Standard 2 DPIA and the Docs Sandbox DPIA reassessment triggers have been hit, and a documented determination on whether the DPIAs need to be re-issued.
• A check whether the Sub-Processors list needs any update arising from the incident root cause.
• A check whether the Developer Privacy Notice needs amendment, with any change routed through the Change Management Procedure.
• An entry in the Change Management Record (maintained internally; available to auditors and enterprise customers on request) if the incident response materially changed any control or procedure.