Trust Center

Vulnerability remediation SLAs

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

Audience
customers, auditors, on-call engineers
Last reviewed
2026-05-15

Owner: Security engineering on-call rotation. Applies to: every reported vulnerability — internal (security-scan, penetration tests) or external (responsible disclosure, customer report).

Severity rubric

SeverityDescriptionExamples
P0 — CriticalActive exploitation, customer data exposed, complete RCE on a prod surfaceAuth bypass on /api/v1/*, cross-tenant data leak
P1 — HighPre-auth path to elevated privilege; sensitive data at risk under realistic conditionsStored XSS in viewer, SSRF that bypasses allowlist
P2 — MediumAuth required + non-trivial exploitation; or breaks defense-in-depth without direct impactCSRF on a low-risk endpoint, broken rate limiter, missing audit on admin route
P3 — LowTheoretical / requires multiple unlikely conditions; or quality-of-defense issueMissing security header on internal page, weak crypto on already-private channel

SLA targets

SeverityAcknowledgeMitigate (workaround)Fix (root cause)Customer notice
P01 hour4 hours24 hoursWithin 24 hours, even if fix is incomplete (must include workaround)
P14 hours24 hours7 daysWithin 7 days, after fix is shipped
P21 business day7 days30 daysAggregate in monthly security update
P35 business days30 daysNext scheduled releaseOptional — 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

  1. Triage — Security-on-call assigns severity within the acknowledgement window. If unclear, default to one severity level higher and re-grade later.
  2. Mitigation — apply the minimum-impact workaround that closes the exploit window. Capture the workaround in the ticket.
  3. Fix — root-cause fix. Goes through normal code review + security-review skill before merge.
  4. Validation — fix verified in staging by a different engineer than the author. P0/P1 fixes must include a regression test.
  5. Postmortem — P0/P1 require a postmortem within 14 days. Filed in docs/runbooks/postmortems/.
  6. 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.