c4.8 Build a vulnerability management team
At this level, a dedicated vulnerability management team owns the process: tracking new vulnerabilities, setting severity criteria and remediation SLAs, coordinating fixes, and giving every team visibility into the vulnerabilities in their workloads.
Implementation guidance
What the team owns
A vulnerability management team turns ad-hoc patching into a governed process. Its responsibilities include:
- Tracking new vulnerabilities and issuing advisories to development teams.
- Alerting and escalating when critical vulnerabilities arise, and coordinating remediation.
- Defining how severity is classified (CVSS, EPSS, SSVC, VPR) and the timeframe in which each severity must be fixed.
- Getting DevOps teams to commit to remediation SLAs (or enforcing them top-down with CISO/CIO backing).
- Measuring remediation times and giving each team — and each manager — dashboards of the vulnerabilities in their workloads.
Define auto-fix vs. escalate rules
Have an agreed process for correcting deviations. Examples to adapt to your industry and risk appetite:
- Critical vuln in a non-prod OS: auto-apply the patch if not applied within X.
- Critical vuln in a prod OS: escalate if not applied within X.
- High/critical vuln in code: contact the team's Security Champion if not fixed within X hours; escalate if unresolved that day.
Aggregated dashboards per team and per manager drive engagement in fixing vulnerabilities.
How to validate
- Is there a team that owns vulnerability management with the responsibilities above?
- Are severity criteria and remediation SLAs defined and agreed with DevOps?
- Are auto-fix or escalation rules configured for aging vulnerabilities?
- Does each team have visibility into the vulnerabilities in their workloads?
Threats addressed
- Most large-scale exploitation happens days or weeks after a vulnerability is public and still succeeds because organizations lack the team, process, and tooling to patch in time.
- Patching everything immediately is impossible at scale and the risk of not patching is too high, so without severity-based definitions and SLAs, the wrong vulnerabilities get fixed first — or too late.