Owner: Security engineering on-call rotation. Applies to: every reported vulnerability — internal (security-scan, penetration tests) or external (responsible disclosure, customer report).
Severity rubric
| Severity | Description | Examples |
|---|---|---|
| P0 — Critical | Active exploitation, customer data exposed, complete RCE on a prod surface | Auth bypass on /api/v1/*, cross-tenant data leak |
| P1 — High | Pre-auth path to elevated privilege; sensitive data at risk under realistic conditions | Stored XSS in viewer, SSRF that bypasses allowlist |
| P2 — Medium | Auth required + non-trivial exploitation; or breaks defense-in-depth without direct impact | CSRF on a low-risk endpoint, broken rate limiter, missing audit on admin route |
| P3 — Low | Theoretical / requires multiple unlikely conditions; or quality-of-defense issue | Missing security header on internal page, weak crypto on already-private channel |
SLA targets
| Severity | Acknowledge | Mitigate (workaround) | Fix (root cause) | Customer notice |
|---|---|---|---|---|
| P0 | 1 hour | 4 hours | 24 hours | Within 24 hours, even if fix is incomplete (must include workaround) |
| P1 | 4 hours | 24 hours | 7 days | Within 7 days, after fix is shipped |
| P2 | 1 business day | 7 days | 30 days | Aggregate in monthly security update |
| P3 | 5 business days | 30 days | Next scheduled release | Optional — quarterly trust portal post |
“Acknowledge” means: ticket opened, on-call notified, severity confirmed. “Mitigate” means: an immediate workaround that removes the active risk even if the root cause is not yet fixed (feature flag off, route 503’d, firewall rule, etc). “Fix” means: root-cause fix merged and deployed to all environments.
Workflow
- Triage — Security-on-call assigns severity within the acknowledgement window. If unclear, default to one severity level higher and re-grade later.
- Mitigation — apply the minimum-impact workaround that closes the exploit window. Capture the workaround in the ticket.
- Fix — root-cause fix. Goes through normal code review +
security-reviewskill before merge. - Validation — fix verified in staging by a different engineer than the author. P0/P1 fixes must include a regression test.
- Postmortem — P0/P1 require a postmortem within 14 days.
Filed in
docs/runbooks/postmortems/. - Customer comms — Compliance + Legal coordinate the trust portal advisory and direct customer notice per the table above.
Escalation
- P0/P1 page the on-call (PagerDuty:
security-oncall). - If acknowledgement SLA breached → page security engineering manager.
- If mitigation SLA breached → page CTO + General Counsel.
Evidence
Every remediation must produce:
- An audit_log entry (
security.remediation_started/..._fixed) - A linked ticket with severity, timeline, owner.
- For P0/P1: a postmortem doc.
These flow into the SOC 2 evidence bundle automatically — auditors
can query security.remediation_* actions in the audit log to verify
SLA compliance.
Definitions
- “Business day” — UTC, Mon-Fri excluding statutory holidays in the primary engineering region (DE).
- “Customer notice” — email to security-contact + trust portal post.
- “All environments” — production, staging, sandbox, GovCloud.
Last reviewed: 2026-05-15.