# 3.4 Vulnerability and Patch Management

# Goals

Vulnerability and patch management is the process of finding known weaknesses, deciding what must be fixed first, applying updates or mitigations, and proving the issue was handled.

Attackers do not need a new technique when an old vulnerability is still open.

The company needs a repeatable process for operating systems, applications, browsers, servers, network devices, websites, SaaS platforms, cloud systems, third-party software, and business-critical tools.

This section covers the protection work: patching, mitigation, ownership, timelines, verification, and reporting.

# Step 1: Assign Vulnerability and Patch Management Owners

Name the people responsible for the process.

Do not leave this as “IT handles patches.”

Record who owns each platform: Microsoft 365, Google Workspace, servers, laptops, firewalls, routers, VPNs, websites, databases, cloud platforms, and business applications.

# Step 2: Define the Scope

List the systems covered by the patch process.

Anything connected to company data or company operations belongs in scope.

# Step 3: Build the Patch Register

Create one tracker for patch status and vulnerabilities.

A spreadsheet is acceptable for many SMEs. The important part is keeping the tracker alive.

# Step 4: Use Trusted Vulnerability Sources

Use trusted sources to know what matters.

Also monitor vendor advisories for key systems:

Do not rely only on news articles. Use official advisories and scanner results for action.

# Step 5: Run Regular Vulnerability Scans

Use scanning to find missing patches, exposed services, weak versions, risky software, and known vulnerabilities.

Suggested scan frequency:

Scanning without remediation is not progress. Every scan must produce actions.

# Step 6: Prioritize What Must Be Fixed First

Do not patch only by severity score.

Prioritize using business and attacker context.

A “Critical” vulnerability on an unused internal test system may matter less than a “High” vulnerability on a public VPN or firewall.

# Step 7: Set Remediation Timelines

Create clear timelines.

Use faster timelines for exploited, internet-facing, identity, backup, firewall, VPN, remote access, website, and business-critical systems.

Use written exceptions when a deadline cannot be met.

# Step 8: Create the Standard Patch Cycle

Run a normal monthly patch process.

A patch is not complete until it is verified.

# Step 9: Create an Emergency Patch Process

Some vulnerabilities cannot wait for the next monthly cycle.

Trigger the emergency process when:

Emergency patching must have a named owner, decision maker, communication path, and verification step.

# Step 10: Test Before Wide Rollout

Patches can break systems.

Test first where practical.

For emergency patches, testing may be shorter. Document what was tested.

# Step 11: Patch Endpoints

Patch laptops and desktops consistently.

Check:

Endpoints that never reboot often remain unpatched.

Track reboot compliance.

# Step 12: Patch Servers

Servers need coordinated patching.

Check:

Servers that cannot be patched quickly need compensating controls.

# Step 13: Patch Network and Edge Devices

Firewalls, VPN appliances, routers, switches, Wi-Fi controllers, and remote access gateways are high-value targets.

Check:

Edge devices are commonly missed because they do not look like normal computers.

Do not ignore them.

# Step 14: Patch Websites and CMS Platforms

Public websites need a regular update process.

Check:

A vulnerable website can become a foothold, spam source, malware host, or data leak.

# Step 15: Patch Cloud Systems and Containers

Cloud environments need patch visibility too.

Check:

Containers are not automatically safe because they are rebuilt often. Old base images can carry old vulnerabilities.

# Step 16: Patch Third-Party Applications

Many attacks target common business software.

Check:

Do not focus only on the operating system.

Third-party applications often create the easier path.

# Step 17: Manage Software Dependencies

Companies that build websites, applications, scripts, or internal tools need dependency management.

Check:

Developer dependency risk belongs in the patch process. A vulnerable library can expose the application even when servers are patched.

# Step 18: Handle Systems That Cannot Be Patched

Some systems cannot be patched immediately.

Record the reason and apply temporary protection.

Unpatched systems must not disappear from the register.

They need owners, due dates, and compensating controls.

# Step 19: Verify Remediation

Do not close a vulnerability because someone says it was patched.

Verify it.

Close the issue only after verification.

# Step 20: Track Exceptions

Exceptions are allowed only when they are documented.

An exception with no expiration date is not an exception. It is unmanaged risk.

# Step 21: Remove End-of-Life Systems

End-of-life software and devices are a security problem.

Track:

Do not keep unsupported systems connected because they are “still working.”

Working is not the same as safe.

# Step 22: Report Progress

Create a simple monthly report.

Include:

Leadership does not need every scanner detail. They need to know whether dangerous exposure is going down.

# Step 23: Review the Process Regularly

Review the patch process at least quarterly.

Check:

Patch management gets weaker when nobody checks the process.

# Places Commonly Missed

# Recommended Tools and Resources

# Practical Tool Stack for SMEs

# Vulnerability and Patch Management Register Template

# Expected Outputs from This Section

At the end of this section, the company should have:

• A named vulnerability and patch management owner.
• A defined scope of systems covered.
• A vulnerability and patch register.
• Trusted vulnerability sources.
• A regular scanning schedule.
• A prioritization method based on exploitation, exposure, business criticality, and severity.
• A standard monthly patch cycle.
• An emergency patch process.
• Documented remediation timelines.
• Patch coverage for endpoints, servers, network devices, websites, cloud systems, SaaS tools, and third-party applications.
• Dependency scanning for code and software projects where applicable.
• A process for systems that cannot be patched.
• Verification evidence for completed fixes.
• An exception register.
• An end-of-life system list.
• A monthly patch status report.
• A quarterly review process.

# Objectives

Do not measure patch management by effort - measure it by closed exposure.

A company should leave this section able to say:

“We know which vulnerabilities affect us, which systems are exposed, what must be fixed first, who owns the fix, when it is due, and how we proved it was remediated.”

---