Change management

Change management is the formal process that governs how changes are made to systems and infrastructure. A change is requested, reviewed and approved by a change advisory function, tested outside production, scheduled, and implemented with a rollback plan ready if it fails. Approval is deliberately kept apart from implementation, an application of separation of duties. Documentation follows the whole path, so the organisation always knows what changed, when, why, and who approved it.

The nuance is that unauthorised change is a security event, not just an operational annoyance: an undocumented change is indistinguishable from an attacker’s modification, and unapproved changes are a classic root cause in outage and breach post-mortems. Emergency changes are the other trap. A genuine emergency may proceed with abbreviated approval, but it still receives the full review retrospectively; “it was urgent” never exempts a change from documentation and after-the-fact scrutiny.

Exam relevance: if a scenario mentions an outage traced to an undocumented modification, the missing control is change management. If it asks about an urgent fix applied at 2 a.m., the answer is that emergency changes require retrospective review and documentation, not that the process is waived. The process itself should be mandated in the organisation’s security policy; contrast change management, which governs modifications, with configuration management, which records and enforces the approved state those changes produce.