Insights · Field note · Infrastructure and resilience
Change management in high-consequence environments
Where a bad change stops a hospital, a plant or a trading floor, the change process is the control that matters most and the one most often bypassed under pressure.
Change management in a high-consequence environment is the governed process by which every change to production is requested with its rationale, assessed for risk and dependencies, tested where possible, authorized by someone accountable for the consequence, scheduled in a window, executed with a rollback ready, verified afterward and recorded. It is the control most often bypassed under pressure, with an emergency change that was never reviewed, and the one whose absence is most visible in outage reviews. The process is proportionate: routine changes move quickly through a standard path, consequential changes get the full assessment, and emergency changes are reviewed after the fact without exception.
In detail
What the evidence shows.
Proportion
Not every change needs a committee. Standard changes with known risk follow a pre-approved path. Normal changes are assessed and authorized. Emergency changes are executed under defined authority and reviewed afterward. The classification is written down so that nobody decides under pressure that their change is routine.
Assessment
What could this change break. What depends on the system. What is the rollback and how long does it take. Has it been tested in a representative environment. Who is affected and have they been told. The dependency map and the asset register make the assessment possible; without them it is a guess.
Authorization and execution
Authorized by someone accountable for the service, not only by the engineer making the change. Executed in a window with the secure maintenance discipline: loosened controls listed, monitoring maintained, every action logged, closure verified. Configuration records updated.
Review
Changes that caused incidents, emergency changes and failed changes are reviewed and the process adjusted. Change records are evidence for auditors and the first thing an outage review examines. NIST SP 800-53 and SP 800-171 require configuration change control; the discipline above is how it is done. See secure maintenance workflows, secure maintenance windows and testing failover without causing an outage.
Sources
Primary references.
- NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (physical and environmental protection and configuration management families)
- NIST SP 800-171 Rev. 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations (physical protection and configuration management requirements)
- Performance Data engagement observations (first-hand: David Selakovic); method described under Infrastructure Resilience.
By David Selakovic · Published 2026-10-16 · Revised 2026-10-16 · Reviewed every 180 days