Vulnerability Management Roadmap: 6-Month Plan From Scanning to SLAs

9 min read · 2026-10-25

A vulnerability management roadmap is a dated plan for building a program that finds weaknesses in your systems, ranks them by real risk, gets them fixed by the teams that own the systems, and proves it with numbers. It moves you from occasional scans and long spreadsheets of findings to a steady cycle with clear owners and agreed fix times.

The template below covers 26 weeks in six phases: governance, asset inventory, scanning coverage, risk-based prioritization, remediation workflow, and reporting. It is written for security managers, vulnerability management leads, IT operations managers and CISOs who must get infrastructure, application and cloud teams to fix things they did not choose to prioritize. You also get a filled-in example, who owns what, the metrics to report and the traps that leave programs with thousands of open findings and no progress.

The roadmap at a glance

Goal: By week 26, every critical asset has an owner and is scanned on schedule, findings are ranked by real risk, fixes are tracked in the teams' own ticket queues against agreed SLAs, and leadership gets a monthly risk report. Duration: 26 weeks

1. Governance and policy (Weeks 1-3)

   Agree who is responsible for what and how fast different risks must be fixed.

   • Name the program owner and an executive sponsor, usually the CISO and the CIO.
   • Draft a vulnerability management policy covering scope, scan frequency, severity levels and fix time targets.
   • Agree remediation SLAs with IT operations and engineering leads, with shorter targets for internet-facing and critical systems.
   • Write an exception process: who can accept a risk, for how long, and with which compensating controls.

   Milestone: A signed policy with SLAs and an exception process, approved by the CIO and the heads of IT operations and engineering.

2. Asset inventory and ownership (Weeks 2-8)

   Know what you have, who owns it and how much it matters.

   • Combine asset data from the CMDB, cloud accounts, endpoint management and network discovery into one list.
   • Assign an owning team to every asset or asset group.
   • Tag each asset by criticality and exposure: internet-facing, holds sensitive data, supports a critical business service.
   • Find assets that no one claims and resolve them with IT leads.

   Milestone: An asset inventory where every in-scope asset has an owner, a criticality rating and an exposure tag, with unclaimed assets below an agreed threshold.

3. Scanning coverage (Weeks 6-12)

   Scan everything in scope on a regular schedule with reliable results.

   • Set up authenticated scans for servers and endpoints, since unauthenticated scans miss many findings.
   • Add cloud configuration scanning and container image scanning for cloud and engineering teams.
   • Add external attack surface scans for internet-facing systems.
   • Schedule scans by asset type and agree maintenance windows with system owners.
   • Compare scanned assets with the inventory every week and close coverage gaps.

   Milestone: Authenticated scan coverage for all critical assets, external scans running weekly, and a coverage report comparing scanned assets with the inventory.

4. Risk-based prioritization (Weeks 10-16)

   Rank findings by real risk so teams fix what matters first.

   • Combine CVSS severity with exploit data such as the CISA Known Exploited Vulnerabilities catalog and EPSS scores.
   • Weight findings by asset criticality and exposure from the inventory.
   • Define three or four priority levels, each tied to an SLA in the policy.
   • Group findings by fix, such as one patch or config change that clears many findings, so tickets are actionable.

   Milestone: A priority model documented and applied to all open findings, with each priority level mapped to an SLA and reviewed by IT operations.

5. Remediation workflow (Weeks 14-22)

   Get fixes done inside the owning teams' normal work.

   • Send findings to each team's own queue, such as ServiceNow or Jira, instead of a separate security spreadsheet.
   • Link patching to the change process and regular patch cycles for servers and endpoints.
   • Run a weekly triage call with owners of the most overdue items.
   • Track exceptions with an expiry date and review them every month.
   • Verify fixes with a rescan before closing tickets.

   Milestone: All priority findings flowing to owner queues automatically, rescans closing tickets, and the first month of SLA performance measured.

6. Reporting and improvement (Weeks 20-26)

   Show leadership the trend and keep improving the program.

   • Build a monthly dashboard by business unit and team: open critical findings, SLA performance and coverage.
   • Present the first monthly risk report to the CIO and CISO.
   • Review root causes of repeat findings, such as unsupported software or missing build standards.
   • Plan next steps, such as hardened images, application security testing or penetration test follow-up.

   Milestone: Monthly risk report delivered twice in a row, and an improvement plan for the next two quarters approved by the CISO.

Common mistakes to avoid

• Sending security spreadsheets to IT by email leaves findings unworked, so route each finding to the owning team's ticket queue.
• Ranking by CVSS score alone buries the real threats, so add exploit data such as the CISA KEV catalog and EPSS, plus asset criticality.
• Scanning without credentials misses many findings and creates false comfort, so set up authenticated scans with read-only service accounts.
• Setting SLAs without IT's agreement turns every report into an argument, so agree targets with IT operations and engineering before you publish the policy.
• Letting exceptions live forever hides real risk, so give every exception an owner, compensating controls and an expiry date.
• Reporting total open findings as the headline makes better coverage look like failure, so lead with coverage, SLA compliance and exploited vulnerabilities.

Frequently asked questions

What are the main steps of vulnerability management?

The usual cycle is to identify assets, scan them for vulnerabilities, prioritize findings by risk, remediate or mitigate them, verify the fix, and report. A roadmap puts governance and asset inventory first so the rest of the cycle has clear owners.

What is risk-based vulnerability management?

It ranks findings by the real risk they pose instead of severity score alone. It combines severity with exploit information, such as whether a vulnerability is being exploited in the wild, and with how critical and exposed the affected asset is.

What are typical vulnerability remediation SLAs?

There is no single standard. Many organizations set the shortest target for exploited or critical vulnerabilities on internet-facing systems, and longer targets for lower risk. Agree targets with IT and engineering, and check any rules your industry, customers or regulators set.

Who is responsible for fixing vulnerabilities?

The team that owns the system fixes it, such as IT operations for servers or engineering for applications. The security team runs the program, finds and ranks issues, follows up and reports. Write this split into your policy.

What is the CISA KEV catalog?

The Known Exploited Vulnerabilities catalog is a public list maintained by CISA of vulnerabilities that have been exploited in real attacks. Many teams use it to decide what to fix first, since these vulnerabilities pose an active threat.

Generate this roadmap with AI