Design a vulnerability management program: severity-to-SLA policy, risk acceptance, and exception handling.
Key Talking Points
- ✓Normalize all sources into one system of record (dedupe, assign a single severity scale) so a 'critical' means the same thing regardless of which tool found it.
- ✓Define severity using CVSS as a base but adjust with environmental/business context (internet exposure, data sensitivity, exploit availability, compensating controls).
- ✓Tie SLAs to severity tiers (e.g. Critical 7d, High 30d, Medium 90d, Low best-effort) and to asset criticality — internet-facing crown-jewel apps get tighter SLAs.
- ✓Auto-route findings to the owning team with clear remediation guidance; ownership and a due date are mandatory fields.
- ✓Provide a formal risk-acceptance / exception process: requires a justification, a compensating control, an approver at the right level (higher severity = higher approver), and a mandatory expiry/re-review date — no permanent exceptions.
- ✓Track aging and SLA breaches; escalate overdue criticals to management automatically.
- ✓Group by root cause and feed recurring classes back into paved-road guardrails so the same bug stops recurring.
- ✓Report leadership-facing metrics: open risk by severity, SLA compliance trend, MTTR, and exception inventory.
A scalable vuln-management program turns findings into a governed workflow: standardized severity, risk-based SLAs, owned remediation, and a formal exception/acceptance path with expiry — all measured by aging and SLA compliance.