Patch Management for Small Businesses: What Gets Patched and When

Patch management is the process of finding software and device updates, deciding which ones are urgent, installing them safely, and checking that they worked. For a small business, the hard part is not clicking Update. It is knowing which laptops, servers, firewalls, apps, and cloud services you own, which fixes matter most, and who follows up when an update fails. A simple inventory and a visible exception list make your patch program more reliable than an untested promise to update everything.

What systems belong in a patch plan?

Include workstations, servers, phones, firewalls, routers, VPN devices, browsers, line-of-business apps, and any software your team uses to reach customer data. Cloud services may update their own platform, but your tenant settings, connected apps, and managed devices still need attention. Start with an inventory that names each system, its owner, its current version, and the person responsible for applying updates. If a device is missing from your inventory, it will be missing from your patch reports too.

Which patches should you install first?

Prioritize known exploited vulnerabilities, internet-facing systems, and devices that hold privileged access. Then weigh the affected software, exposure, business impact, and whether a reliable fix exists. CISA's Known Exploited Vulnerabilities catalog is a useful signal because it identifies flaws already observed in attacks. That does not make every other update safe to ignore. It gives your team a defensible order when several fixes arrive at once.

CISA's ransomware guide recommends timely patching, especially on internet-facing systems and known exploited vulnerabilities.

How do you patch without disrupting work?

Group devices by role and test changes on a small representative set before a wider rollout. Schedule restarts so users know when their work may pause. For critical systems, record the rollback path and the person who can approve a delay if the patch breaks a required application. Your process should separate an approved exception from a forgotten device. An exception needs a reason, compensating control, owner, and date for review.

How do you know the patch installed?

A deployment command is not proof. Compare the installed version or patch status after the maintenance window, then investigate the machines that did not report back. Watch for devices that are offline, out of storage, or no longer managed. Keep a short report that shows coverage, failed updates, overdue high-risk fixes, and open exceptions. That gives you something useful for a security review or cyber insurance question.

Who should own the patch process?

One person or provider should own the inventory, prioritization, deployment, follow-up, and reporting. The business still decides when an outage risk is acceptable for a critical application. If you outsource IT, ask for the overdue-patch list and a sample of completed verification, not only a claim that updates are automatic. A managed plan should make these responsibilities explicit.

What does a workable patch schedule look like?

Use two tracks: an urgent path for actively exploited or high-exposure issues, and a regular maintenance window for routine updates. The urgent path needs a named decision maker who can approve out-of-cycle work and tell staff about a restart. The regular path needs a predictable test group, rollout window, and follow-up date. Avoid promising that every patch will be installed within the same number of days regardless of exposure; a public-facing VPN flaw and a low-risk desktop feature update require different decisions. Write the target time for each risk class in your own policy and review misses against it.

CISA's Known Exploited Vulnerabilities catalog identifies flaws observed in active attacks and supports risk-based remediation.

What should happen in the first 30 days?

In the first week, identify every managed endpoint and internet-facing device and assign an owner. In the second, compare installed versions with vendor support status and the urgent vulnerability list. In the third, choose a small test group for routine updates and document one emergency approval path. By the fourth week, complete a rollout, verify installation, and review every failure with its owner. This is a starting sequence, not a claim that a month closes every gap. A legacy application may need a longer replacement plan and temporary controls while you work through it.

How do third-party apps and end-of-support devices fit?

Operating-system updates are only part of the picture. Browsers, PDF readers, line-of-business applications, network firmware, and remote-access tools can all be entry points. Decide who updates each one; a vendor-managed application can still leave your team responsible for approving downtime or checking that the fix reached your environment. If a device or software version is no longer supported, mark it separately from a missed patch. It may need isolation, restricted access, a documented replacement date, or a vendor migration. Reporting it as fully patched would hide the actual risk.

Which numbers show whether patching is working?

Track the percentage of inventoried systems reporting in, urgent fixes past your target date, failed installations, and approved exceptions that have passed their review date. Review these by system importance, not only as one fleet-wide average. Ninety-eight percent coverage can still leave the one internet-facing firewall that matters most exposed. Give the business owner a short monthly list of unresolved items, the risk and temporary measure for each, and the person responsible for closure. That is a more useful record than a green dashboard with no exceptions shown.

What happens to laptops that miss the update window?

A laptop may be off, traveling, low on storage, or unable to reach the management system during the scheduled rollout. Your patch report should show when each device last checked in, whether the update installed, and whether a restart is still pending. Set a follow-up path for the employee and a point at which the device is restricted from sensitive systems until it is current. Do not mark the whole rollout complete when the deployment tool has merely queued a task. The last few missing devices often take more human follow-up than the first hundred that updated automatically.

What does a useful exception record look like?

Suppose a line-of-business application fails a required vendor test after a server update. Record the affected server and patch, the business process it supports, the reason for delay, who approved it, and the next review date. Add the temporary measure, such as limiting access or increasing monitoring, and a plan to retest with the vendor. The exception should be visible in the same report as completed patches so leadership understands the remaining exposure. If the review date passes without a new decision, the exception becomes an overdue risk, not a permanent permission to leave the system vulnerable.

See how managed IT covers device upkeep and ongoing support.

Read the wider infrastructure guide for the systems a patch plan needs to cover.