Run automatic updates with clear stop conditions

Automatic updates can take over recurring operational work. A successful installation step does not show whether your application and its connections still work as intended. The decision to continue therefore needs a defined test case.

NIST includes prioritisation, installation and verification of installation in patch management. For your own operations, that leads to a practical question: which application workflow must still work after the change?

Check a critical connection path

In this fictional example, an automated routine installs an update. The web service starts, but background job J-61 can no longer use its connection to the linked system. The installation message is positive; the required workflow remains interrupted.

For this case, the team plans to test the connection and its intended result before proceeding with the rollout. The test is prepared in an approved environment with suitable test data. No update was installed or linked system contacted here.

Define the response to a failed test

This table is a planning template, rather than a rollout performed here. Stopping means making a controlled decision about the next change. The necessary security fix remains an open task and needs a defined follow-up process.

Plan the way back and the remaining work

Returning to the old software version must be compatible with the data state and changes already made. Establish in advance which recovery route has been tested for the specific update and who may execute it. An older file alone is not a tested way back.

Finally, record who handles failed checks and when open cases are reassessed. Automation can then follow the agreed process while exceptions retain a clear route to a responsible decision.

Sources

• NIST: Guide to Enterprise Patch Management Planning