Major Change Management Activities - Patch Management Steps

Receiving notice of the patch

This might come in the form of an announcement from the vendor(s), a third party (such as an anti-malware or business threat intelligence provider), or via general news sources. The organization should have a regular (at least daily) process in place to observe and analyze these sources.

Determining applicability

Because not every organization uses products in the same way (and with different dependencies/interrelated products), not every patch is applicable to every customer who owns the targeted system. The organization's change management practice should require patch analysis to determine the applicability and urgency.

Determining potential impacts

If a patch is determined necessary/ applicable, the next step is to figure out what other systems might be affected if the patch is implemented and what additional risks this might entail.

Testing the Patch

The organization should have a sample test bed that mimics the production environment (on a smaller scale; while every interdependency should be reflected in the test environment, not every machine needs to be replicated on a one-to-one basis). The test environment should be kept both logically and physically isolated ("air-gapped") from the production environment. The patch should be applied in that test environment, to determine whether it will cause any interoperability problems in the production environment. Testing should also address rollback procedures should the patch fail to perform properly in the production environment.

Even after testing, the patch might cause unforeseen issues upon actual implementation; the organization should have the capability to roll back to a previous version of the environment (before the patch) so as not to lose any data/transactions/capabilities.

Confirm installation of the patch for all target systems

This can be done with automated tools designed for the purpose. Verify that the patch is performing as expected, that the metrics associated with monitoring system performance have been updated to reflect the new risk of system operation and there are no identified disruptions of services.

Apply the Patch

This should be done in accordance with vendor/issuer instructions, industry best practices, and the organization's own formal process.

Solicit/Receive user feedback

The patch team should be ready to take input from the user community about possible operational changes/problems / issues that arise from the patch. Since most organizations would use their Help Desk to receive these reports, the Help Desk should be one of the stakeholders in the patch management process.

Rollback if warranted

If the patch does not work or has unacceptable effects, a rollback to a previous (pre-patch) state may be required. Typically, the criteria for rollback would be identified in the Request for Change and would automatically be performed when the rollback criteria were met.

Document

Everything must be annotated for later reference; patching records should be included in the asset inventory.