Change Management

Change management. This is the single most important control in I-T operations, and one of the crown jewels of I-T general controls. The exam tests it constantly.

Here is why it matters. A change went into production on Friday and took the ordering system down for the whole weekend. When you trace it, there was no test record, no approval, and no plan to undo it. The developer who wrote it also deployed it, on their own judgement, straight to live. The fix for the outage was itself an unauthorised, untested change. Change management is everything this scene was missing.

A change is controlled when three things are true before it reaches production. First, it is authorised: the appropriate change authority has approved it, a delegated approver for routine changes, a change advisory board for significant ones that assesses risk and impact.

Second, it is tested: shown to work, and shown not to break anything else, in an environment that is not production.

And third, it is reversible: there is a documented backout plan to return to the previous working state if the change fails once it is live.

That third one carries a lot of weight. No change can ever be guaranteed not to fail, which is exactly why the backout plan matters. Control is not the promise that nothing goes wrong; it is the ability to authorise, verify, and recover. When a question asks what must be true before a change goes live, look for these three.

Change management recognises different routes for different risks. Standard changes are low-risk and pre-authorised, handled through a streamlined path. Normal changes go through the full process, with the change advisory board weighing risk and impact. And emergency changes address something urgent, a critical failure, an actively exploited vulnerability, using an expedited approval route.

And here is the exam’s favourite point. An emergency change is expedited, not exempted. The fix can be made fast, but authorisation is still obtained, even if from a single on-call approver, and the change is documented and formally reviewed afterwards. Bypassing change management entirely, at the very moment the system is most fragile, is the wrong answer.

Now segregation of duties. The developer who deployed their own code broke it. The person who builds a change must not be the one who authorises and deploys it. When a single individual controls the whole path from writing code to running it in production, an error, or a deliberate malicious change, reaches live systems with no independent check.

So the environments and the roles are kept separate. Developers work in development, changes are tested elsewhere, and a distinct authority or process moves approved, tested changes into production. It is the same principle as an auditor not remediating their own finding, applied to the pipeline that feeds production.

Which is why an unauthorised change is the classic finding: a change sitting in production with no approval, no test record, and no backout plan. It is exactly the gap through which the Friday outage arrived.

So carry three things away. Authorise, test, be able to undo. Emergencies are expedited, not exempt, so expedite the approval, do not abandon it, and review afterwards. And the person who builds a change must never be the one who approves and deploys it.