Change Management Policy Template: Approval, Emergency Changes and Segregation of Duties

Most change management policies were written for people raising tickets, yet most production changes today are made by pipelines, bots and service accounts that no change advisory board ever sees. This template sets out a change management policy that covers standard, normal and emergency changes, approval authority, segregation of duties and the evidence each change must leave behind. It treats infrastructure-as-code, CI/CD pipelines and automated changes made by non-human identities as changes in their own right, with controls enforced in the tooling rather than on paper. It is written for IT operations, platform engineering, security and risk teams who need a policy they can adopt and then implement through procedures. Adapt the roles, thresholds and lead times to your organisation before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [Change manager] and [X days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a documented exception may be justified.
• The change types follow the widely used standard, normal and emergency model. Rename them if your service management tool uses different terms, but keep three distinct approval routes.
• Where approval is enforced by a tool (for example a protected branch or deployment environment), the policy accepts the tool record as the change record. Say so in your procedure so teams do not duplicate effort.
• Review the policy at least annually and after any incident caused by a change.

1. Purpose

This policy sets the requirements for requesting, assessing, approving, implementing, verifying and recording changes to [Organisation]'s production systems. Its aims are to reduce the risk of outages and security incidents caused by change, to ensure that no single person or identity can make and approve a significant change alone, and to provide an audit trail of who changed what, when, why and with which credential.

2. Scope

This policy applies to changes to production and production-supporting environments, whether on premises, in cloud or delivered by third parties, including:

• Application code and configuration released to production.
• Infrastructure, network, firewall and cloud configuration, including changes made through infrastructure-as-code.
• CI/CD pipeline definitions, build runners, deployment workflows and third-party actions or plugins they use.
• Identity and access configuration: identity provider policies, roles, privileged groups, service accounts, API keys and OAuth applications.
• Security tooling configuration, such as EDR policy, logging and SIEM rules.
• SaaS tenant configuration and integrations.

Routine operational activity that does not alter configuration, such as restarting a service within a runbook, is out of scope unless [procedure reference] says otherwise. The policy applies to all staff, contractors, third parties and non-human identities that make changes.

3. Roles and responsibilities

• [Change manager]: owns the change process, chairs the change advisory board (CAB), maintains the change calendar and the catalogue of standard changes.
• Change advisory board (CAB): reviews high-risk normal changes and advises the change authority. Membership includes [operations], [security], [service owners] and [business representatives].
• Change authority: the person or body with authority to approve a given change type, as defined in section 4.2.
• Emergency change authority: [named on-call manager or ECAB] who approves emergency changes.
• Change requester and implementer: raise changes, assess impact, prepare test and rollback plans and carry out the change.
• [Platform engineering]: configures the technical controls that enforce this policy in source control and pipelines.
• [IAM team]: owns the service accounts and workload identities used by pipelines and automation, including their permissions and review.
• [Security team]: reviews changes with security impact and monitors for unauthorised change.

4. Policy statements

4.1 Change types

4.2 Requesting and assessing changes

• Every change outside the standard catalogue must have a change record, either in [ITSM tool] or in a linked pull request, stating the purpose, systems affected, risk assessment, test evidence, implementation plan, rollback plan and implementation window.
• The risk assessment must consider security impact, including any change to authentication, access rights, network exposure, encryption, logging or secrets.
• Changes that grant new permissions to a service account, workload identity or API key, or that create new credentials, must be classed as at least normal medium risk and reviewed by [IAM team] or [Security team].
• A change to a standard change procedure is itself a normal change.

4.3 Segregation of duties

• The person who authors a normal change must not be the only person who approves it. Approval must come from a different, authorised person.
• The approval of the final version must be given by someone other than the person who last modified it. Approvals must be invalidated when the change is modified after approval.
• No individual may hold both the ability to merge to a protected production branch without review and the ability to deploy directly to production, unless an exception is approved under section 5.
• Administrators must not be able to bypass review controls on production branches and environments as a matter of routine. Any bypass must be logged and reviewed within [1 working day].
• In small teams where full separation is not possible, a compensating control must apply, such as retrospective review by [named reviewer] within [X days].

4.4 Infrastructure-as-code and pipeline changes

• Production infrastructure must be changed through infrastructure-as-code and approved pipelines wherever the platform supports it. Manual console changes to production are permitted only as emergency changes or under an approved exception.
• Production branches must be protected: changes require a pull request, at least [one] approving review from someone other than the author, passing required status checks (including security scans), and approval of the most recent push.
• Changes to pipeline definitions (for example .github/workflows or equivalent), deployment scripts and infrastructure modules must require review by a designated code owner from [Platform engineering] or [Security team].
• Deployment to production must go through a protected environment with required reviewers, self-review prevented, and production secrets released only to jobs that pass those rules.
• Third-party actions, plugins and modules must be pinned to an immutable reference (such as a full commit SHA or digest), and updating that reference is a change.
• The infrastructure plan (proposed diff) must be attached to, or visible from, the change record before approval.

4.5 Changes made by service accounts and automation

• Each pipeline, bot and automation tool must use its own non-human identity. Personal credentials must not be used by automation.
• Pipeline identities must hold only the permissions needed for their deployment target, and should use short-lived, federated credentials (for example OIDC workload identity) rather than stored long-lived keys.
• A bot or service account must not be able to approve its own change or a change authored by another automated identity without human review, unless the change is in the standard change catalogue.
• Every automated change must be traceable to an approved change record or pull request, and to the identity that executed it.
• Permissions of deployment identities must be reviewed at least [quarterly] by [IAM team] and the pipeline owner.

4.6 Emergency changes

• Emergency changes must be approved by the [Emergency change authority] before implementation, by phone or chat if necessary, and the approval recorded.
• Emergency access to production must use break-glass or just-in-time privileged access, which is logged and revoked after use.
• A full change record must be completed within [1 working day], and the change reviewed at the next CAB.
• Repeated emergency changes for the same cause must trigger a problem record.

4.7 Implementation, verification and records

• Changes must be implemented within the approved window and must not conflict with the change freeze calendar.
• Each change must be verified after implementation. Failed changes must be rolled back according to the plan and recorded as failed.
• Change records, approvals, pipeline logs and audit logs of the executing identity must be retained for [X months].

4.8 Detecting unauthorised change

• [Security team] must monitor for changes that have no matching approved record, including configuration drift between infrastructure-as-code and live state, new or modified pipeline definitions, changes to branch protection settings and new credentials for deployment identities.
• Unauthorised changes must be treated as security events under the [Incident Response Plan] until shown to be benign.

5. Exceptions

Exceptions must be requested by the system owner, assessed by [Change manager] and [Security team], approved by [CISO or CIO], recorded with compensating controls and an expiry date of no more than [12 months], and reviewed before expiry.

6. Compliance and monitoring

[Change manager] will report change volume, failure rate, emergency change rate and unauthorised changes monthly to [governance forum]. [Internal audit] will sample changes at least annually to confirm approval, segregation of duties and evidence. Unauthorised changes may result in removal of change rights. Breaches of this policy by staff may be handled under [disciplinary procedure].

7. Review and approval

This policy is owned by [policy owner], approved by [approving body] on [date], and will be reviewed at least annually, or sooner after a major incident caused by change or a significant change in delivery tooling.

Implementation guidance

Enforcing the policy in tooling

Sections 4.3 and 4.4 map directly to controls in modern source control platforms. In GitHub, for example, protected branch rules can require pull request reviews, dismiss stale approvals when new commits are pushed, require review from code owners, require approval of the most recent push by someone other than the pusher, require status checks and signed commits, and, through "Do not allow bypassing the above settings", apply the rules to administrators. Deployment environments add required reviewers, a "prevent self-review" option, wait timers, branch restrictions and environment secrets that are released only after the rules pass. Other platforms have equivalents; record in your procedure which settings implement which policy statement.

Phased rollout

1. Inventory the routes to production: ITSM-driven changes, pipelines, console access and the identities each uses.
2. Define the standard change catalogue from the most frequent low-risk changes, so teams gain speed from the policy early.
3. Turn on branch protection and protected environments for the most critical services first, in report or audit mode where the platform allows, and fix blocked workflows before enforcing.
4. Move pipeline credentials to short-lived federated identities and remove standing production access from individuals.
5. Enable drift and unauthorised change detection, then route alerts to [Security team].
6. Roll back an enforcement setting only through a recorded exception, never by silently disabling it.

Decision guidance

A CAB adds value for genuinely high-risk or cross-team changes; routing every pipeline deployment through it slows delivery without improving safety. Teams with mature automated testing should push most changes into the standard or tool-approved normal route and keep CAB for the exceptions. Small organisations may have no separate approver: use retrospective review and strong logging as the compensating control rather than pretending separation exists.

Framework mapping

Weak pipeline change control is a supply chain risk: MITRE ATT&CK T1195.002 Compromise Software Supply Chain describes attackers altering software before it reaches users.

Metrics

• Change failure rate: percentage of changes that cause an incident or rollback.
• Emergency change rate: emergency changes as a percentage of all changes (a rising trend signals planning problems).
• Unauthorised changes: changes detected with no matching approved record.
• Enforcement coverage: percentage of production repositories with branch protection and protected environments enabled.
• Review bypasses: number of administrator bypasses per month and percentage reviewed on time.

Common failure patterns

• Bots approving bots: in the tj-actions/changed-files compromise, a malicious commit disguised as a dependency bot update was merged through an automatically approved pull request using a stolen bot token, and version tags were repointed to it.
• Unreviewed workflow files: in the GhostAction campaign, compromised accounts with push access added workflow files that exfiltrated CI/CD secrets. Code owner review of workflow directories puts a human check on that path.
• Mutable references: pipelines that pull actions or modules by tag run whatever the tag points to today.
• Admin bypass by default: branch protection that exempts administrators protects nothing against a compromised admin account.
• Paper CAB, real console: changes are approved in the ticket but made by hand in the console, so drift is never reconciled.

References and related guides

• NIST: SP 800-53 Rev. 5 (CM and AC families)
• NIST: Cybersecurity Framework 2.0
• GitHub Docs: About protected branches
• GitHub Docs: Managing environments for deployment
• MITRE ATT&CK: Compromise Software Supply Chain
• Pipeline and IaC controls: see the CI/CD Security Guide, the CI/CD Pipeline Identity Security Guide and the Infrastructure as Code Security Guide.
• Separation of duties in depth: see the Segregation of Duties Guide.

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Incident Response Plan Template · Logging and Monitoring Policy Template · Firewall Rule Review Checklist · Service Account Security Guide