Change Management in IT Infrastructure: How Uncontrolled Changes Create Compliance Gaps

Why Uncontrolled Change is the Root Cause of Most Incidents

Uptime Institute's 2024 Outage Analysis found that 40% of significant IT outages are caused by human error during change activities — patching, configuration updates, deployments, and maintenance windows that went wrong. Equally important from a compliance standpoint: ISO/IEC 27001:2022 Annex A.8.32 mandates change management procedures for information processing facilities. CERT-In requires documented change procedures for critical IT systems. Without a formal change management process, your organisation cannot demonstrate controlled IT operations to an auditor — regardless of how good the actual work is.

Change Categories and Approval Paths

• Standard Changes: Pre-approved, low-risk, frequently repeated changes (e.g., routine OS patching on non-critical servers). These can proceed without individual CAB approval — but must still be logged.
• Normal Changes: All other planned changes. Must be submitted as a Request For Change (RFC), assessed for risk and impact, scheduled, and approved by a Change Advisory Board (CAB) before implementation.
• Emergency Changes: Urgent changes required to restore service or address a critical security vulnerability. Require post-implementation documentation and retrospective CAB review. Emergency changes must not become the default path for poorly planned work.

The Rollback Requirement

Every normal and emergency change must include a documented rollback procedure — the tested steps to undo the change if it causes unintended consequences. "We'll figure it out if something goes wrong" is not a rollback plan. Auditors reviewing change records will look for rollback procedures as a mandatory element. Changes without rollback documentation represent untested risk in production.

Change Management Evidence for Audits

ISO 27001 auditors will ask to see a sample of change records. Adequate records must include: RFC reference number, description of change, risk and impact assessment, test results from non-production environment, CAB approval with names and date, implementation log with timestamps, post-implementation test results, and closure record. CERT-In expects evidence that changes to critical infrastructure are formally controlled and documented.