A defensible program knows what software and versions run where, learns of relevant releases, ranks them by exploitation status and exposure rather than severity alone, tests for operational impact, deploys on a defined cadence with an emergency path, and confirms the patch was applied and remains in place.
The discipline sits inside vulnerability management but has its own failure modes: inventory gaps, update mechanisms that silently fail, dependencies that block deployment, and end-of-life software that will never receive another fix. Each of those needs a named treatment — compensating control, isolation, or replacement — not an open exception that ages indefinitely.
Key points
Inventory and intakeMaintain current records of software, firmware, dependencies, and owners; monitor vendor and authoritative advisories, including actively exploited-vulnerability catalogs.
PrioritizationWeight known exploitation, exposure, asset criticality, and compensating controls over raw severity scores; define when the emergency process applies.
Testing and deploymentStage rollout, test security and functional impact, define rollback, and track coverage and exceptions with owners and expiry.
Important limitationA patch deployment report is not proof of remediation. Failed installs, pending reboots, rolled-back changes, and unreachable assets leave the vulnerability open, and unsupported software cannot be patched at all.