Patch Management

A vendor discovers a flaw in a software product and releases an update, but installing it on one laptop does not protect the other laptops, servers and devices using that product. Patch management makes the response consistent across the business.

NIST describes identifying, prioritising, acquiring, installing and verifying updates, and these steps are preventive maintenance, not a single monthly click. First build an inventory that includes laptops, servers, phones, network gear, cloud workloads, applications and embedded systems where practical, because an unknown system cannot be patched systematically.

Record software versions, since the same product may need different fixes by version or operating system and a device list without installed versions misses that distinction. Assign owners who approve maintenance windows, operate update tools and handle exceptions, with security teams setting policy while system owners validate service effects.

Track vendor notices from authentic vendor channels rather than random download links, since vendors publish fixes, supported versions and sometimes emergency instructions. Prioritise risk, because a flaw already exploited by attackers can deserve urgent action, and CISA's Known Exploited Vulnerabilities catalogue is one input, not a complete list of every risk.

Look at exposure and business impact too, since a public web server and an isolated test device can face different immediate risks, and define deadlines by risk, because a single "patch everything within 30 days" target can leave urgent systems exposed and the exact time limit belongs in the organisation's risk policy. Test where needed, since an update can affect a billing system or medical device differently from an ordinary laptop, and use representative systems before broad rollout.

Stage deployment by trying a small group, then larger groups, while checking failures, though an urgent exploit may require a faster path with compensating controls. Plan downtime for server restarts and application dependencies by agreeing maintenance windows and telling affected teams, and take backups with a rollback plan, remembering that a backup is useful only if restoration has been tested.

Install from trusted sources such as central tools and verified vendor channels, which reduce the chance of counterfeit updates, and record the target version. Verify installation, because a successful deployment job is not proof that a system is protected, so check version, reboot status and vulnerability scan results as appropriate.

Investigate failures such as offline devices, insufficient storage and incompatible applications, and retry or create a documented exception rather than marking the campaign complete. Track unsupported software, firmware and third-party applications, since a vendor may no longer provide fixes, routers and other devices may need special update methods, and browsers, document readers and business plugins can carry exploitable flaws that operating-system updates do not cover.

Document exceptions with owner, reason, risk, mitigation and review date, measure coverage by reporting how many in-scope devices have the required updates and how long urgent gaps stay open, because a headline percentage can hide one exposed crown-jewel server, and separate patching from vulnerability management, since scanning finds weaknesses and patching is one response among configuration changes, isolation or retirement. After an incident, ask whether a missing inventory item, delayed decision or failed verification allowed exposure, budget for automation, testing and maintenance windows as ordinary operating maintenance, and remember that for an owner the key question is whether the business knows what needs fixing, fixes it in risk order and checks that the fix actually landed.