Change Management Policy: A Guide for Regulated EU Organisations

Change management in the context of regulated EU organisations is not simply an ITIL best practice — it is a regulatory obligation. Uncontrolled changes to ICT systems are a leading cause of service disruptions, security incidents, and data integrity failures. Regulatory frameworks including DORA, NIS2, and ISO 27001 recognise this reality by mandating formal change management processes that ensure changes are assessed, authorised, tested, and documented before implementation. The objective is not to slow down change, but to ensure that changes are deliberate, risk-assessed, and reversible.

A compliant change management process serves four regulatory purposes simultaneously. First, it supports operational resilience by ensuring that changes to critical systems are tested and validated before deployment, reducing the risk of change-induced outages that could trigger NIS2 incident reporting obligations or DORA operational disruption thresholds. Second, it supports security by ensuring that changes are reviewed for security implications before implementation — a code deployment that inadvertently exposes a new attack surface, or a network change that weakens segmentation, would be caught in a properly functioning change review process. Third, it supports auditability by creating a documented record of what changed, when, why, by whom, and with whose authorisation — essential for post-incident root cause analysis and supervisory inspections. Fourth, it supports accountability by establishing clear approval workflows that ensure changes are authorised by individuals with the appropriate knowledge and authority.

For organisations new to formal change management, the investment required is primarily in process design and cultural change rather than technology. While change management tools (ServiceNow, Jira Service Management, or equivalent) are valuable for workflow automation and audit trail maintenance, the core capability is a well-defined process that everyone follows consistently. A simple, well-adopted process produces better outcomes than a sophisticated tool with inconsistent adoption.

ISO 27001:2022 Annex A control A.8.32 (Change management) requires that changes to information processing facilities and information systems shall be subject to change management procedures. The control applies to all changes that could affect information security, including changes to applications, systems, infrastructure, network configurations, and security parameters. The ISO 27002:2022 implementation guidance for this control provides detailed expectations: changes should be planned and agreed, impact assessments should consider security implications, changes should be authorised before implementation, changes should be tested and validated, and records should be maintained.

The scope of A.8.32 extends beyond ICT changes to include changes to processes, procedures, and organisational structures that affect information security. A reorganisation that changes reporting lines for the security team, a process change that alters how sensitive data is handled, or a policy change that modifies access control rules all fall within scope. This breadth distinguishes the ISO 27001 change management requirement from the more technically focused DORA requirement — organisations pursuing both DORA and ISO 27001 compliance must ensure their change management process covers both ICT-specific and broader organisational changes.

ISO 27001 audit evidence for A.8.32 compliance should demonstrate: a documented change management policy and procedure, a change register or log showing all changes processed through the procedure, evidence of risk assessment for each change (proportionate to impact), approval records from authorised individuals, testing and validation records, rollback planning for high-impact changes, and post-implementation review records for significant changes. Auditors will typically sample the change register and trace selected entries through the complete lifecycle to verify that the procedure was followed consistently. Inconsistencies between the documented procedure and actual practice — changes deployed without approval, testing records missing, or risk assessments completed retroactively — are common audit findings that indicate process immaturity.

Emergency changes — changes required urgently to restore service, address a security vulnerability, or prevent imminent harm — require a distinct procedure that balances speed with governance. The emergency change procedure must be explicitly defined in your change management policy, because the worst time to design a process is during an emergency. A clear, pre-agreed emergency procedure ensures that urgent changes are executed with appropriate controls even when normal review timelines cannot be followed.

The emergency change procedure should define: the criteria for classifying a change as an emergency (service outage affecting defined thresholds, active security incident, regulatory mandate with an immediate deadline), the emergency approval authority (who can authorise an emergency change outside normal CAB processes — typically the change manager, on-call senior engineer, or CISO for security-related emergencies), the minimum documentation required at the time of implementation (what is being changed, why it is urgent, who authorised it, and what the rollback procedure is), and the retrospective review requirement (emergency changes must be reviewed by the CAB at the next scheduled meeting, with full documentation completed retrospectively). The retrospective review is non-negotiable — without it, the emergency procedure becomes a standing bypass for the normal process.

For DORA-regulated financial entities, emergency changes must still be documented with sufficient detail to demonstrate compliance with Article 9(4)(e). The ESA RTS do not provide an exemption for emergency changes — they must still be risk-assessed, tested where feasible, and documented. The practical accommodation is timing: the risk assessment and detailed documentation can be completed retrospectively within a defined window (typically 24-48 hours after implementation), but the approval, implementation, and rollback records must be captured in real time. Establish a digital audit trail for emergency changes that automatically timestamps each step: request submission, approval grant, implementation start, implementation completion, validation, and retrospective review closure. This timestamped trail provides the evidence needed to demonstrate that the emergency procedure was followed even under time pressure.

A mature change management process is not static — it improves continuously based on performance data and operational feedback. Establish a set of key performance indicators that measure both process efficiency and effectiveness. Process efficiency metrics include: change lead time (time from request to implementation), CAB review cycle time, percentage of changes processed on schedule, and percentage of changes requiring rework. Process effectiveness metrics include: change success rate (percentage of changes implemented without unplanned rollback or incident), change-related incident rate (number of incidents caused by changes as a proportion of total changes), emergency change percentage (should remain below 10-15% of total changes — a high percentage indicates either inadequate planning or process avoidance), and post-implementation review completion rate.

Analyse these metrics monthly and present a quarterly summary to the management body or risk committee. Trend analysis is more valuable than point-in-time values: a declining change success rate over three months signals a systemic issue that requires investigation, while a single failed change is an operational event to be reviewed and learned from. Common root causes of change management failures include: inadequate testing (changes that passed testing but fail in production due to environmental differences), incomplete impact assessment (changes that produce unintended side effects in connected systems), and communication gaps (changes that succeed technically but disrupt business processes because stakeholders were not informed).

Use failed changes and change-related incidents as learning opportunities, not blame events. Conduct blameless post-mortems for significant change failures, focusing on process gaps rather than individual errors. Feed the findings back into the change management procedure as improvements — if a class of changes consistently fails due to inadequate testing, strengthen the testing requirements for that class. If emergency changes are increasing as a percentage of total changes, investigate whether the normal process is too slow or restrictive, driving teams to classify routine changes as emergencies to bypass the CAB. A healthy change management culture balances rigour with pragmatism — the process should be thorough enough to prevent uncontrolled risk, but efficient enough that teams use it willingly rather than circumventing it.