Vulnerability Management vs Patch Management: Who Owns Each Decision

Most organisations that say they "do vulnerability management" actually run a patching schedule, and the gap between the two is where exploited systems, stolen session tokens and forgotten exceptions live. Vulnerability management is the decision process: find exposure, judge risk, choose a response and prove it worked. Patch management is one of the responses, and the most common one, run by the teams who own the systems. This page is about the operating model between them: who owns which decision, where the hand-offs break, what each side should measure, and where non-patch remediation such as configuration changes, credential rotation, compensating controls and exceptions belongs. It is written for security leaders, vulnerability management leads and infrastructure managers designing or repairing that split. For the mechanics of each discipline, see the Vulnerability Management Guide and the Patch Management Guide.

Key takeaways

• The short answer: vulnerability management decides what risk must be reduced and by when; patch management delivers updates reliably across the estate. One is a risk process, the other an engineering service.
• NIST frames patching as one response among several. SP 800-40 Rev. 4 describes accept, mitigate, transfer and avoid, with patching as one way to mitigate.
• A patched system is not always a remediated one. CitrixBleed and the ToolShell SharePoint exploitation both left attackers with valid sessions or keys after the fix was installed.
• Ownership must be explicit at three hand-offs: finding to owner, owner to fix, and fix to verification. Most programmes fail at the first and the last.
• Measure each side on what it controls. Patch teams own deployment coverage and time to install; vulnerability management owns exposure time, risk acceptance and verified closure.

The difference in one table

NIST SP 800-40 Rev. 4 makes the relationship explicit. It describes a vulnerability management lifecycle that applies to all risk responses: learn that a vulnerability affects assets, plan the response, execute it (prepare, implement, verify, continuously monitor), and support it with documentation, audit logging and change management. Patch management sits inside that lifecycle as one response, with its own steps of preparing, deploying, verifying and monitoring.

Threat model: what each discipline protects against

Patch management handles the high-volume, predictable threat: known flaws in supported software that attackers exploit once a fix is public, typically through public-facing applications (ATT&CK T1190 Exploit Public-Facing Application). Its strength is coverage and repeatability. Its failure modes are operational: devices that never check in, updates that fail silently, rings that stall after a bad release, and software the patch tool does not manage.

Vulnerability management handles everything a patch schedule cannot see or cannot fix:

• Weaknesses with no patch: misconfigurations, exposed management interfaces, default credentials and insecure protocols. These need configuration change, which the Configuration Drift and Baseline Enforcement Guide covers.
• Zero-day and pre-patch windows: the vendor publishes mitigations before a fix, and someone must decide to apply them now.
• Post-compromise persistence: the exploit happened before the patch, so stolen sessions, keys and accounts survive it.
• Unpatchable assets: end-of-life software, operational technology and embedded devices, where isolation or removal is the only response.
• Risk decisions: NCSC states that the decision not to update is a senior-level risk decision. Patch teams cannot make that call; vulnerability management brings it to the right owner.

Ownership: a RACI that survives audit

NCSC notes that the process spans IT operations, security and risk teams, and that senior leaders may need to be involved where those teams report to different board members. Write the split down. A workable default:

The pattern to avoid is security owning tickets it cannot close and operations owning a backlog it did not prioritise. Security owns the decision and the verification; operations owns the change; a named senior owner signs anything left open.

The three hand-offs where programmes break

1. Finding to owner: a scanner finding has no accountable team because the asset is not in the inventory, or is tagged to a team that no longer exists. NCSC's "own your estate" principle is the fix: know what you run, who is responsible for it, and what vulnerabilities are present. Measure the share of findings with a valid owner within 24 hours.
2. Owner to fix: the owner receives a CVE identifier with no fix instructions, or a fix that the patch tool cannot deliver. Vulnerability management should hand over a remediation action, not a score: patch, configuration change, credential rotation, isolation or removal, with the deadline.
3. Fix to verification: the patch tool reports "installed" and the ticket closes. NIST SP 800-40 Rev. 4 notes that authenticated scans give better results than passive, unauthenticated scans; closure should come from a rescan or equivalent evidence, not from the deployment report alone.

Non-patch remediation: where it sits

NIST SP 800-40 Rev. 4 lists the alternatives explicitly: disable the vulnerable feature, remove unneeded services, isolate or segment the asset, add firewall controls, or avoid the risk by uninstalling or decommissioning. It also describes emergency mitigations that deactivate functionality or isolate assets, later replaced by permanent fixes. These belong to vulnerability management as decisions, even when platform teams carry them out.

CISA's Binding Operational Directive 22-01 shows how narrow the choices become for actively exploited flaws: federal civilian agencies must apply the catalogue's required actions, generally the vendor update, and where an asset cannot be updated the only other known mitigation is removal from the network, with isolation accepted as a form of removal. There are no waivers. Many private organisations adopt the same rule for KEV entries. See the CISA KEV Catalogue Guide and the Virtual Patching and Compensating Controls Guide.

Where identity fits: patched but still compromised

The clearest case for keeping vulnerability management separate from patching is what happens to credentials. When a flaw was exploited before the fix, installing the patch closes the door but leaves the attacker holding keys.

• Session tokens: in CitrixBleed 2023, patching stopped new session cookies leaking but did not invalidate those already stolen; Citrix told customers to upgrade and then kill all active and persistent sessions.
• Machine keys: in the ToolShell SharePoint exploitation 2025, stolen ASP.NET machine keys let attackers forge trusted data after the fix; Microsoft and CISA advised rotating the keys and restarting IIS, and the analysis recommends rotating other secrets on affected hosts.
• Scanner and patch tool credentials: both disciplines run on privileged non-human identities that can log in to every asset. Treat them as tier zero; see Securing the patch management tool itself.

Build a rule into the hand-off: any finding that was exploitable on an internet-facing system before patching triggers a credential and session review, owned by vulnerability management and incident response, not by the patch team.

Metrics: who owns which number

NIST SP 800-40 Rev. 4 warns against overly simple metrics such as the overall percentage of vulnerabilities patched, and suggests reporting percentage patched by deadline and mean and median time to patch, broken down by vulnerability importance and asset importance, then by platform, business unit and maintenance group. Split ownership so each team is measured on what it controls.

A useful cross-check: if patch coverage is high but the exposure window for critical findings is long, the problem is prioritisation, hand-offs or non-patch work, not patch delivery.

Decision guidance: one team or two

• Small organisations often run both from one IT team. That works if the risk decision is still separated: a named person outside the patching role sets priorities, signs exceptions and checks closure. Automatic updates plus a short list of manual exceptions covers most of the estate; NCSC's first principle is to default to patching, ideally automatically.
• Mid-sized organisations benefit most from the RACI above: a small vulnerability management function in security, and patching run by endpoint, server and cloud platform teams with service levels for routine and emergency updates.
• Large and regulated organisations add maintenance groups and maintenance plans. NIST SP 800-40 Rev. 4 describes a maintenance group as assets with similar characteristics and maintenance needs, each with a plan per scenario, and says assets that cannot be patched still belong to a group rather than being labelled exceptions. This keeps operational technology and legacy platforms inside the model.
• Cloud-native estates shift patching to image rebuilds and redeployment. Vulnerability management then tracks findings in images, registries and running workloads, and the "patch" is a pipeline change owned by application teams.

Deadline policy, fixed SLAs versus risk-based windows, is covered in Fixed Patch SLAs vs Risk-Based Remediation Windows; ranking findings in the Vulnerability Prioritisation Guide.

Worked scenario: an exploited edge appliance

A KEV entry lands for a remote access appliance on a Thursday afternoon. Here is how the split plays out when it works.

1. Vulnerability management declares an emergency: confirms the affected version is in use from the inventory, sets a deadline, and issues the vendor mitigation as an immediate action.
2. Platform team applies the mitigation, then the fix: following the emergency procedure, with a short canary step, as NIST describes for emergency patching.
3. Vulnerability management checks for prior exploitation: with incident response, it reviews logs and integrity checks from before the patch.
4. Credentials and sessions are revoked: active sessions killed, service account secrets and certificates on the appliance rotated, users forced to sign in again.
5. Closure is verified: a rescan confirms the fixed version, and the ticket records the mitigation, the patch, the hunt result and the rotations.

In the failure version, the patch team installs the update, the ticket closes on the deployment report, and nobody owns step 4.

Common failure patterns

• Patch compliance reported as vulnerability management: a high percentage installed says nothing about misconfigurations, end-of-life software or credentials.
• Tickets closed on "installed": no rescan, so failed installs and vulnerable copies elsewhere on the host stay invisible.
• Exceptions with no expiry: risk accepted once by a manager who has since left. Use the Vulnerability Risk Acceptance and Exception Template.
• Non-patch findings routed to the patch queue: configuration and credential findings sit unowned because the patch tool cannot fix them.
• No post-patch credential review: the CitrixBleed and ToolShell pattern, where stolen sessions and keys outlive the fix.
• Unmanaged software outside both scopes: applications the patch tool does not manage and the scanner cannot authenticate to.

Framework mapping

See the CIS Control 7 Continuous Vulnerability Management Guide for safeguard-level detail.

How to implement the split

1. Write the RACI: agree it with IT operations and the risk function, and name the senior risk owner for exceptions.
2. Fix ownership routing first: map every scanned asset to an owning team; route findings automatically and report unowned ones weekly.
3. Define remediation actions: for each finding class, state the expected response (patch, configuration, rotation, isolation, removal) so hand-offs carry instructions.
4. Separate routine and emergency paths: security declares emergencies; platform teams run them with a pre-agreed accelerated process.
5. Add the post-exploit rule: internet-facing, exploited-before-patch findings trigger credential and session review.
6. Close on evidence: require a rescan or equivalent before closure; pilot on one business unit, then expand.
7. Report split metrics monthly: patch delivery numbers from operations, exposure and exception numbers from security, side by side.

Practitioner checklist

• A written RACI separates the risk decision, the change and the verification.
• Every scanned asset maps to an owning team, and unowned findings are reported weekly.
• Findings reach owners with a remediation action and deadline, not just a score.
• Non-patch findings (configuration, credentials, end-of-life) have their own queue and owner.
• Exploited-before-patch findings trigger session and credential revocation.
• Closure needs rescan or equivalent evidence, not a deployment report.
• Exceptions carry a senior signatory, compensating controls and an expiry date.
• Patch and vulnerability metrics are reported separately and compared.
• Scanner and patch tool service accounts are managed as privileged identities.

Standards and references

• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• NIST: SP 800-40 Rev. 4 full text (PDF)
• NCSC: Vulnerability management guidance
• CISA: Binding Operational Directive 22-01
• CIS: Control 7 Continuous Vulnerability Management
• NIST: SP 800-53 Rev. 5, Security and Privacy Controls

Related NHI Mgmt Group resources: Vulnerability Management Guide, Patch Management Guide, CTEM vs Vulnerability Management, Remediation SLAs and Vulnerability Exceptions Guide.