vm-3 High priority Vulnerability Management / Vulnerability Management

Critical and high vulnerabilities are remediated within defined SLAs

Vulnerability management without SLAs is just a list of problems nobody is accountable to fix. SLAs convert scan findings into commitments: critical vulnerabilities are remediated within a defined window, high findings within a longer window, and so on. Without defined and tracked SLAs, critical findings can sit open for months while teams focus on other work. SLAs need to be realistic, enforced, and reported on to have any effect.

2h estimated effort

sla patch-management remediation vulnerability-management

Complete first: vm-1 , vm-2

Implementation steps

1

Define written SLAs for each vulnerability severity tier

Document remediation SLAs by CVSS severity or your internal risk tier. Common targets are: critical within 15 days, high within 30 days, medium within 90 days, low within 180 days. Adjust for context: internet-facing critical systems should have tighter timelines. Get SLAs approved by engineering leadership and publish them in your security policy.

confluence notion drata vanta google-docs
2

Automate ticket creation and SLA tracking for scan findings

Configure your vulnerability scanner to create tickets automatically in your issue tracker when new findings are detected. Assign each ticket an owner based on the affected system's team. Set due dates based on the SLA. Configure alerts when tickets are approaching or past their SLA deadline. Do not rely on manual ticket creation.

tenable qualys jira servicenow linear
3

Report SLA compliance to leadership monthly

Produce a monthly report showing the number of open findings by severity, the percentage closed within SLA, and any exceptions. Share this report with engineering and security leadership. Use it to identify chronic offenders, typically specific teams or system types that consistently miss deadlines, and address the root cause.

tenable qualys drata tableau google-sheets