Change Management Security: Make Change Control Catch Risky Changes

Change control in most organisations is good at producing tickets and poor at stopping the change that takes production down or opens a hole: approvals are rubber-stamped, emergency changes become the norm and nobody notices changes made outside the process. Change management security means designing the IT change process so that risky changes get the right scrutiny, low-risk changes flow quickly, and unauthorised changes are detected. This guide covers change types, change advisory boards and peer review, risk scoring, security review triggers, emergency changes, unauthorised change detection, the link to the CMDB and the evidence auditors expect for ISO/IEC 27001 control A.8.32, SOC 2 CC8.1 and SOX IT general controls. It is for IT service management, platform and security leads. The ready-to-adopt policy is the Change Management Policy Template; the wider ITIL context is in the ITIL 4 Information Security Management Guide.

Key takeaways

• Route by risk, not by habit. Pre-approved standard changes, peer-reviewed normal changes and a small number of board-reviewed high-risk changes beat one heavyweight process for everything.
• Define security triggers explicitly. Changes to identity, network exposure, encryption, logging, privileged access or internet-facing systems should automatically pull in a security reviewer.
• Emergency changes need a retrospective, not a free pass. Track the emergency rate, review every one within days and treat a rising trend as a process failure.
• Detect what bypassed the process. Reconcile actual changes (configuration drift, cloud audit logs, deployment records) against approved tickets; unmatched changes are incidents until explained.
• Evidence is a by-product. If approvals, tests and deployments are recorded by the pipeline and the ticketing tool, ISO 27001, SOC 2 and SOX samples become a query rather than a scramble.

What change control is for

ITIL 4 calls the practice change enablement: maximising the number of successful changes by ensuring risks are assessed, changes are authorised and the schedule is managed. The security goal sits inside that: no change should silently weaken confidentiality, integrity or availability, and every production change should be attributable to an authorised person or pipeline. ISO/IEC 27001:2022 Annex A control A.8.32 Change management requires changes to information processing facilities and information systems to be subject to change management procedures. The AICPA Trust Services Criteria CC8.1 says the entity authorises, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures to meet its objectives. NIST SP 800-53 Rev. 5 covers the same ground in CM-3 Configuration Change Control, CM-4 Impact Analyses and CM-5 Access Restrictions for Change, and NIST SP 800-128 describes security-focused configuration management around them.

Change types and how to route them

• Change authority: ITIL 4 lets organisations assign the authority to approve each type of change to the level that matches its risk. A single CAB for everything is optional, not required.
• Change advisory board: keep it for high-risk and cross-team changes; give it a fixed agenda (risk, test evidence, rollback, schedule conflicts) and the power to defer.
• Peer review: for code and infrastructure as code, a mandatory pull request review by someone other than the author, enforced by branch protection, is a stronger and more auditable control than a weekly meeting.
• Segregation of duties: the requester cannot approve their own change, and developers do not push directly to production; where small teams cannot separate roles, compensate with post-deployment review.

Change risk assessment and security review triggers

A short scoring model makes routing consistent. Score each factor 1 to 3 and route totals above an agreed threshold to the change authority or CAB.

Security review is triggered by content, not score. Make these triggers explicit in the change form and in pipeline rules:

• Identity and access: new privileged roles, federation or single sign-on changes, conditional access or MFA policy changes, new service accounts, API keys or OAuth app grants. See the Human vs Non-Human Identity guide.
• Network exposure: new internet-facing endpoints, firewall or security group rules opening inbound access, VPN and remote access changes.
• Cryptography and secrets: certificate, key or TLS configuration changes and secret rotation in production.
• Security tooling: changes to logging, EDR policy, alerting or backup configuration, which attackers also target.
• Data: new stores of personal or regulated data, changes to retention, new data flows to third parties.
• Third-party code: new vendors, agents with privileged access, or CI/CD actions and dependencies pulled from outside.

Emergency changes without losing control

1. Define emergency narrowly: an active incident, an actively exploited vulnerability or an imminent service failure. Missed deadlines are not emergencies.
2. Name the emergency change authority: a small group (on-call service owner, a senior engineer and, for security fixes, the security on-call) who can approve by phone or chat, with the decision recorded.
3. Keep the minimum record before implementing: what, why, who approved, rollback plan.
4. Complete the ticket within one or two working days and review it at the next CAB: was it really an emergency, did it work, what follow-up is needed.
5. Measure the rate: a high or rising proportion of emergency changes means teams are using it to avoid the normal path.

Detecting unauthorised changes

A process only covers the changes people put through it. Detection closes the loop by comparing what changed with what was approved.

• Triage unmatched changes as potential incidents: an administrator skipping the process and an attacker with stolen credentials look the same in the logs.
• Use service identities for automation: when only the pipeline's identity may deploy to production, any human-identity change there stands out. Guard those pipeline credentials as privileged non-human identities.
• Watch source repositories too: in the tj-actions/changed-files compromise of March 2025, a stolen bot account token was used to point nearly all of the Action's version tags at a malicious commit that printed CI/CD secrets into logs. It was spotted because a runtime monitor flagged an unexpected network endpoint, not by any change process. Tag and release protection and alerts on tag moves are change controls.

See the Network Device Syslog and Configuration Change Detection Guide for network equipment.

Linking change to the CMDB

• Every change names its configuration items: this gives impact analysis (what depends on this?) and lets auditors trace a system's change history.
• Criticality drives routing: the risk score's service criticality comes from the CMDB, so stale CMDB data means mis-routed changes.
• Changes update the CMDB: closing a change should update the record automatically where tooling allows; discovery tools then confirm it.
• Collision detection: the schedule shows overlapping changes on related items before they clash.

See the Asset Inventory and CMDB Security Guide.

Audit evidence for ISO 27001, SOC 2 and SOX

The weak point in most audits is the population: auditors want the list of all changes from the system that made them (deployment logs, cloud audit logs), not from the ticket tool, so they can test that every change had a ticket. Build that reconciliation yourself first. See the SOX IT General Controls (ITGC) Guide, the SOC 2 Guide and the ISO 27001 Certification Guide.

Where identity fits

Modern change control is enforced through identities as much as through tickets. In a pipeline-driven estate the deploying identity is usually a non-human one: a CI/CD service principal, a workload identity or a bot token. That makes three identity controls part of change management:

• Scope deploy identities to their target: one pipeline identity per environment and service, with permission to change only what that pipeline owns, so a leaked credential cannot change everything. Prefer short-lived federated credentials (OIDC) over long-lived tokens. See the CI/CD Pipeline Identity Security Guide.
• Remove standing human write access to production: engineers change production through the pipeline, with just-in-time elevation for break-glass work that is itself logged as an emergency change.
• Treat identity changes as changes: creating a service account, granting a privileged role or rotating a production secret goes through the same routing and security triggers as a code release.

Rolling out a risk-based process

1. Baseline: pull three months of changes, incidents caused by change and emergency changes; find the change types that cause most incidents.
2. Define types and triggers: publish the standard change catalogue, the risk scoring model and the security triggers.
3. Automate the low-risk path: encode standard changes as pipeline templates with built-in tests, so they need no meeting.
4. Pilot: run the new routing with one platform team for a month in parallel with the old process; compare incident rates and lead time.
5. Turn on detection: start reconciliation of cloud audit logs and drift against approved changes, initially as a report, then as alerts.
6. Roll out by service tier, critical services last once the model is tuned.
7. Rollback plan: keep the old approval route available for a quarter; if change-related incidents rise, revert specific change types to CAB review while you fix the model.

Detection and measurement

• Change failure rate: percentage of changes causing an incident, rollback or hotfix, by change type.
• Emergency change rate: emergency changes as a share of all changes (a rising trend is a warning).
• Unauthorised change rate: detected production changes with no matching ticket or pipeline run per month (target zero, each investigated).
• Security review coverage: share of changes meeting a security trigger that actually received security review.
• Lead time for standard changes: evidence that the low-risk path is fast enough that nobody bypasses it.
• Post-implementation review completion for emergency and failed changes within the agreed time.

Common failure patterns

• CAB as theatre: dozens of changes approved in minutes with no test or rollback evidence. Move low-risk changes out so the board has time for the risky ones.
• Tooling that should block, but does not: Meta's engineering post on the 4 October 2021 outage describes a routine maintenance command that withdrew all backbone connections; an audit tool meant to stop such commands had a bug. Treat safety tooling as a change-controlled system and test it.
• Everything at once: the CrowdStrike content update of 19 July 2024 reached all online Windows hosts on affected sensor versions between 04:09 and 05:27 UTC. Staged rollout and canary rings belong in the change model for any component deployed everywhere, including vendor-pushed content.
• Emergency as the default: teams that find the normal route slow use the emergency path; fix the normal route.
• Tickets without reconciliation: a clean ticket queue proves nothing if changes made outside it are never looked for.
• Automation identities with no change scope: a pipeline token that can change anything anywhere turns one leaked secret into an unauthorised production change.

Practitioner checklist

• Publish standard, normal and emergency change definitions and a standard change catalogue.
• Adopt a simple risk score fed by CMDB criticality, blast radius and rollback.
• List the security review triggers in the change form and enforce them in pipelines.
• Enforce peer review and branch protection for code and infrastructure as code.
• Name the emergency change authority and review every emergency change within two working days.
• Reconcile cloud audit logs, drift and deployment records against approved changes, and alert on mismatches.
• Stage rollouts of agents and shared components in rings, including vendor-pushed updates where configurable.
• Track change failure, emergency, unauthorised change and security review coverage rates monthly.

Standards and references

• ISO: ISO/IEC 27001 Information security management systems
• NIST: SP 800-53 Rev. 5
• NIST: SP 800-128 Guide for Security-Focused Configuration Management of Information Systems
• NIST: Cybersecurity Framework 2.0
• AICPA: 2017 Trust Services Criteria (with revised points of focus, 2022)
• Meta Engineering: More details about the October 4 outage
• CrowdStrike: Falcon Content Update Preliminary Post Incident Report

Related NHI Mgmt Group resources: Change Management Policy Template · ITIL 4 Information Security Management Guide · SOX IT General Controls (ITGC) Guide · Asset Inventory and CMDB Security Guide