Vulnerability Management vs. Patch Management

Patch management is one way to fix a vulnerability. Vulnerability management is the wider operating process that finds risks, decides what matters, coordinates a response, and verifies the outcome. A small business needs both, but they answer different questions.

Patch management asks which vendor updates should be tested and installed. Vulnerability management asks which systems are affected, whether the weakness is exposed or actively exploited, what action is appropriate, and who owns the work.

The practical difference

Question	Patch management	Vulnerability management
Main job	Test and deploy relevant updates	Find, assess, prioritize, remediate, and track weaknesses
Typical evidence	Update availability, deployment state, device health	Asset inventory, scanner results, vendor advisories, exposure, business impact
Possible action	Install, defer, or roll back an update	Patch, reconfigure, restrict access, replace a system, or accept a time-bound risk
Proof of completion	Update installed successfully	Risk reduced and verification recorded

NIST describes patch management as identifying, prioritizing, acquiring, installing, and verifying updates. That verification matters: an update that installed without error may still need a service check or re-scan before it can be treated as complete. NIST SP 800-40 Rev. 4

Where patching is enough, and where it is not

If a vendor releases a security update for a supported workstation application, the right response may be straightforward: confirm the affected devices, test the update, deploy it, and check that the application still works.

Other findings need a different response. An unsupported server may have no safe patch. A scanner may identify a weak configuration rather than missing software. An internet-facing service might be safer after access is restricted while a permanent change is planned. Those decisions sit in vulnerability management because they require technical evidence, business context, an accountable owner, and a review date.

The Canadian Centre for Cyber Security recommends considering the full set of information systems and assets in scope, including owned, contracted, and otherwise used services. That is why a patch dashboard alone is not a complete risk view. Canadian baseline controls for small and medium organizations

A workable operating flow

Start with a current asset list. Include endpoints, servers, network devices, cloud accounts, remote-access services, software, and the business owner for each important system.

Use scanner results, vendor notices, internal reports, and threat intelligence to identify potential weaknesses. Then review the findings in context. A known-exploited issue on an internet-facing service often deserves faster attention than a higher technical score on an isolated test device.

For every important finding, record the chosen action, owner, target date, expected verification, and any temporary control. The action may be a patch, but it does not have to be. Re-scan, test the service, or collect another appropriate piece of evidence before closing the record.

One vulnerability, traced from advisory to closure

This is a hypothetical example, not a client case. A vendor publishes an advisory for a remote-access appliance, and the flaw appears in a catalog of known-exploited vulnerabilities.

Step	What happens	Which discipline
Identify	The advisory is matched against the asset list; one appliance is affected	Vulnerability management
Assess	The device is internet-facing, handles administrator logins, and the flaw is known to be exploited	Vulnerability management
Decide	Patch in the next window, and restrict access by source address until then	Vulnerability management
Apply the fix	The vendor update is tested and installed	Patch management
Verify	A re-scan or configuration check confirms the flaw is gone and the service works	Both
Record	Owner, date, interim control, and evidence are logged	Vulnerability management

Patching is one box in that table. If the team only tracked the update, it would miss the decision to restrict access while waiting, and the record of who accepted the interim risk.

How the Government of Canada frames the timeline

The Government of Canada vulnerability management guideline sets remediation deadlines by risk tier, from 48 hours for critical findings to 90 days for low ones, and requires accepted risks to carry an expiry date. Those targets are written for federal departments, but the principle applies to any business: urgency comes from risk, not from the patch calendar.

Common gaps

• Treating every scanner finding as a patching task can hide configuration, identity, and unsupported-software risks.
• Applying updates without testing can create avoidable business disruption.
• Deferring a patch without an owner, expiry date, and compensating control creates an untracked exception.
• Counting installed updates without checking asset coverage leaves unknown systems outside the process.

Who owns each part

Many small businesses split these tasks between an internal person, an IT provider, and a security provider. The table shows the usual dividing lines. Agree your own and write it down.

Task	Usually owned by
Asset inventory	Internal IT or the IT provider
Test and deploy updates	IT provider or internal IT
Scanning and finding review	Security provider or security lead
Priority and target dates	Shared, with the business owner approving
Exceptions and compensating controls	Business owner, advised by security
Verification and reporting	Security provider or security lead

Questions to use with an IT provider

Ask which assets are included, how new advisories are matched to them, who decides priority, and who can approve a change. Confirm how exceptions are documented, when they expire, and what evidence proves a remediation worked. The answers should be written down before an urgent issue forces a decision.

For the wider operating model, read the vulnerability management guide for SMBs. If the immediate question is how findings are generated, continue with how vulnerability scanning works.

For the full program around both, see How to Build a Vulnerability Management Program.

Need a clear view of patching, risk ownership, and unresolved findings? Talk to QuantM.