# Incident Response Playbook — Vigilant Entities

> ISO 27001 A.16 / SOC 2 CC7.3 / NIST 800-61 Rev. 2 compliant.
> Owners: Platform Lead + Security Lead. Reviewed quarterly.

## 0. Severity matrix

| Sev | Examples                                                            | Response time |
|-----|---------------------------------------------------------------------|---------------|
| P0  | Active data exfiltration; full platform down; ransomware            | < 15 min     |
| P1  | Auth bypass; cross-tenant data leak; privilege escalation           | < 1 h        |
| P2  | Credential stuffing surge; targeted phishing on Maker account       | < 4 h        |
| P3  | Vulnerability disclosed via responsible disclosure (no exploitation) | < 24 h       |
| P4  | Hygiene issue (verbose error in prod, outdated dependency)          | < 7 d        |

## 1. Detect

Detection sources:
1. **Automated** — `vigilant.errors` log spike, audit-chain verify fails, brute-force lockouts, suspicious-signin alerts, Dawud high-risk blocks.
2. **External** — `security@vigilantentities.com`, security.txt reports.
3. **User-reported** — support tickets mentioning "I didn't sign in", "weird transactions", etc.

On any P0/P1 signal, the on-call rotation pages the Security Lead within 15 minutes.

## 2. Triage

1. Open a private incident channel (Slack / Discord — `#inc-YYYY-MM-DD-shortid`).
2. Generate or capture the `incident_id` from the structured logs.
3. Open a tracking issue in the private security repo.
4. Determine scope:
   - Affected tenants
   - Affected user count
   - Data classes touched (PII? credentials? financial?)
   - Active vs. historical compromise

## 3. Contain

| Threat vector              | Containment action                                                          |
|----------------------------|-----------------------------------------------------------------------------|
| Credential compromise      | `POST /api/auth/sign-out-everywhere` for affected accounts; force password reset |
| API key leak               | Rotate the key at the provider; update `.env`; restart backend             |
| JWT secret leak            | Rotate `JWT_SECRET`; all sessions invalidated on next request              |
| Tenant data leak           | Lock the tenant (set `is_active=false`); rotate API keys; audit-chain verify|
| Active attacker on prod    | Block source IP at edge (Cloudflare); enable enhanced rate limit           |
| Code-level vuln (RCE/SSRF) | Roll back via `git revert` + redeploy; do not delete the vulnerable code   |

## 4. Eradicate

- Remove the root cause (patch the code, rotate the secret, revoke the access).
- For dependency CVEs: bump version, run `pip-audit` / `yarn audit`, re-run tests.
- For misconfigurations: update `.env` template + this playbook.
- Verify the fix with a targeted test (replay the exploit safely).

## 5. Recover

- Restore data if needed (`BACKUP_RUNBOOK.md`).
- Re-enable affected tenants in stages, monitor closely.
- Send customer comms (template below).
- Update `account_activity` and `audit_logs` with the incident reference.

## 6. Post-incident

Required artifacts within 72 h of P0/P1 close:
- **Timeline**: ISO-8601 events, owner per row.
- **Root cause**: 5-whys analysis.
- **What went well / didn't** (blameless).
- **Action items**: with owners + due dates, tracked in the next sprint.
- **Disclosure log**: who was notified, when, via what channel.

## 7. Regulatory clocks

| Trigger                                  | Clock starts at | Deadline          | Recipient                              |
|------------------------------------------|-----------------|-------------------|----------------------------------------|
| Personal data breach (GDPR Art. 33)      | Discovery       | 72 hours          | Lead DPA + affected data subjects      |
| Material breach (SOC 2 customer)         | Discovery       | 24 hours          | Customer security contact              |
| Payment data leak                        | Discovery       | Per PCI DSS 12.10 | Acquiring bank + Stripe                |

## 8. Customer notification template

> **Subject**: Vigilant Entities Security Notice — [incident_id]
>
> On [date], we detected [brief description of issue]. Our investigation
> confirmed [scope statement]. We took the following actions: [actions].
>
> What this means for you: [user-facing impact]
> What you should do: [user-facing action]
>
> We are committed to transparency. The full post-incident report will
> be available at https://vigilantentities.com/security/incidents/[incident_id]
> within 7 days.
>
> Sincerely,
> The Vigilant Entities Security Team
> security@vigilantentities.com

## 9. Tabletop drill schedule

| Quarter | Scenario                                  | Lead          |
|---------|-------------------------------------------|---------------|
| Q1      | Credential stuffing surge → lockout drill | Security Lead |
| Q2      | Tenant data leak via SSRF                 | Platform Lead |
| Q3      | Backup restore from prod corruption       | Ops Lead      |
| Q4      | Maker account compromise                  | CEO           |

## 10. Contact card

| Role             | Primary                           | Backup                          |
|------------------|-----------------------------------|---------------------------------|
| Security Lead    | security@vigilantentities.com     | platform@vigilantentities.com   |
| Platform Lead    | platform@vigilantentities.com     | security@vigilantentities.com   |
| Legal / Privacy  | legal@vigilantentities.com        | privacy@vigilantentities.com    |
| Customer Comms   | support@vigilantentities.com      | (auto-rotation)                 |

## Last reviewed: 2026-02-12 · Next: 2026-05-12