How quickly we acknowledge, mitigate, and fix security issues by severity. Quotable in MSAs.

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-review skill 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.

Vulnerability remediation SLAs