A software update applies a fix or change to software already in use. For security, the responsibility is broader than installing a patch: you must know what needs updating, test the change, and schedule its release. Bugs and unforeseen effects of features can create exploitable openings, so letting an enterprise fall far behind on patches increases risk. section 12.1 section 12.10
Make updates a repeatable operating process:
- Keep a current inventory of software, libraries, and versions. Compare it with vendor notices, open-source release notes, and CVE alerts; periodically check that alert subscriptions still work. section 12.1.1
- Schedule small, frequent updates—at least monthly—rather than dismissing changes without checking whether they apply. section 12.1.2
- Test patches in development or staging before committing them where possible. A blue-green deployment can make that easier; otherwise, include the patch in a tested periodic release. section 12.1.2
- Document the patch-release steps, success criteria, failure signs, and point at which a release can still be canceled. Do not make updating depend on one person. section 11.2.5
- Include network-connected hardware in update checks. Some devices need a manual check through an administration console; record the latest check in an asset log. section 12.1.3
When staging is not available
An email or file server may have to be updated in production. Prefer an out-of-hours window, with time afterward to resolve problems. That constraint changes the schedule, not the need to update. section 12.1.2
Ask: Can you name every version in use, identify which alerts apply, and show how the next patch will be tested and released? If patching has not happened in years—or nobody has a safe place to test changes—treat that as a leadership and operational gap. section 12.1.1 section 1.3
