Auditors expect specific SLAs for vulnerability closure. Implementing the 7/30/90 day standard correctly is more than writing it in a policy — it’s a tracked, exception-handled, evidenced operation. Here’s how we run it.
Origin of the 7/30/90 standard
The model — Critical within 7 days, High within 30, Medium within 90 — became the de facto baseline because it maps cleanly to severity and gives engineering realistic windows. It’s the standard auditors recognize and buyers expect.
Critical / High / Medium / Low classification
Classify by exploitability and impact, typically anchored to CVSS plus context (is it internet-facing? does it touch customer data?). Critical: active or trivial exploit on exposed, sensitive systems. Low: theoretical or internal-only. Context can raise or lower the raw CVSS rating — document the rationale.
SLA tracking architecture
The SLA clock lives in the ticket. On creation, set a due date by priority; surface breaches on a dashboard; escalate automatically as the deadline approaches. The end-to-end workflow this plugs into is in the vulnerability remediation pillar.
Exception handling
Some findings can’t be fixed in window — a vendor patch isn’t available, or a fix needs a major release. Handle these with a documented exception: compensating control, risk acceptance signed by an owner, and a revised date. This is the difference between a defensible miss and an audit finding.
Reporting and board updates
Report monthly: findings by severity, closure rate within SLA, open exceptions, and trend. Boards want the narrative — are we improving, where’s the risk concentrated — not just the raw numbers, which ties into the board-reporting gap in the compliance automation gap.
Auditor evidence expectations
For sampled findings, produce detection time, owner, fix, rescan, and closure date — proving the SLA was met or the exception was handled. The connected tooling that produces this automatically is in the Tenable + Jira + Vanta workflow.
Where Attri Edge fits
Running the SLA cadence — classification, tracking, exceptions, monthly reporting — is part of the Active Retainer. The diagnostic shows whether your current process would survive an auditor’s sampling.
Related reading: