Wiki

What is patch management as a repeating organizational process?

Patch management schedules how an organization finds, tests, deploys, and confirms fixes so known flaws do not linger for long.

It is the repeating operation around many patches, with owners, windows, exceptions, and proof, rather than any single vendor file.

How it works

The cycle starts with an inventory of what you run, because you cannot schedule a fix for a product you do not know you have.
Testing checks that the fix does not break a critical workflow, deployment puts it on the running systems, and confirmation shows the old version is actually gone.

Exceptions happen, yet each exception needs an owner and an expiry so a skipped patch does not become a permanent hole with nobody watching.
A downloaded installer that nobody rolls out is not management, which is why this page is not the same as the definition of a patch.

Concrete examples

  • A monthly window updates laptops, while internet facing systems get a faster track when the vendor marks a flaw as being exploited.
  • A factory line delays a controller update for two weeks under a named exception and then shows evidence that the update landed.
  • An audit sample finds three servers still on the old build because the tool reported success to a management server the hosts could not reach.

Protective measures

  • Keep an inventory that includes appliances and embedded copies, not only the operating systems your endpoint tool can see.
  • Define a normal window and a faster path for flaws that are already being used against organizations like yours.
  • Require every exception to name an owner and an end date, and review the list in the same meeting that reviews incidents.
  • Verify versions on a sample of systems after each cycle so a green dashboard is not your only evidence.

Related articles

The vendor change that corrects one flaw, as distinct from the program around it, is explained in What is a security patch for one known software flaw?.

A flaw that showed why inventory and fast deployment matter is described in What is Log4Shell in the widely used Log4j logging library?.

Devices that often cannot take a normal workstation update are covered in What is IoT device risk for connected products in production?.

‹ Back to the wiki