Change Management Policy: Comprehensive Guide + Free Template (2026)

Your engineer pushes a fix to production on a Friday. By Monday, three customers are locked out, the payment integration is broken, and nobody can tell you what changed or why. That is what happens without a change management policy.

A change management policy is a formal document that governs how changes to your IT systems, infrastructure, code, and configurations are proposed, reviewed, approved, tested, deployed, and recorded. It defines who can authorise a change, what information must be captured before deployment, and what happens when something goes wrong. Every organisation that operates software in production needs one, and every major security framework requires one.

Frameworks that reference change management:

• SOC 2: CC8.1 (Change Management)
• ISO 27001: A.8.32 (Change management, 2022 version)
• NIST 800-53: CM-3 (Configuration Change Control), CM-5 (Access Restrictions for Change)
• HIPAA: Security Rule §164.312(b) (Audit controls)

By the end of this guide, you will know exactly what a change management policy needs to cover, how it maps to each framework, and how to write one your team will actually use.

Here is what I will cover:

• What a change management policy is (and how it differs from change control)
• Why skipping this policy is one of the most common audit failures
• Which companies are required to have one
• What to include in your policy document
• A free inline template you can adapt today
• How it maps to SOC 2, ISO 27001, and NIST
• What auditors will ask to see as evidence
• Common mistakes that trip up startups

Change Management Policy: Definition and Core Concepts

A change management policy is the document that says: before anything changes in your production environment, here is how it gets approved, tested, and recorded.

It defines the process for requesting a change, the criteria for approval, who has authority to sign off, what testing is required before deployment, how changes are documented, and what the rollback procedure looks like if something goes wrong. Without it, changes happen informally, which means approvals happen informally too: a Slack message, a verbal “yeah looks fine,” or nothing at all.

The policy applies to anyone who makes changes to systems that matter: engineers, DevOps teams, IT administrators, security teams, and any third parties with access to your infrastructure.

Change Management vs. Change Control: What’s the Difference?

These two terms are often used interchangeably, and the distinction matters less than people think.

Change management is the broader governance framework: the policy, process, culture, and tooling that ensure changes are handled consistently. Change control is the specific approval and gating mechanism within that framework, the part where someone reviews the change and says yes or no before it goes to production.

If you have both a documented policy and a real approval process, you have what every framework is looking for. Do not get stuck on terminology when the auditor comes calling.

IT Change Management Policy

An IT change management policy scopes the process specifically to IT systems, networks, servers, hardware, and infrastructure. It typically covers operating system updates, network configuration changes, hardware additions or replacements, access control changes, and changes to security tooling.

For companies with a dedicated IT function separate from engineering, this is usually a distinct document with its own owner, often the IT Manager or Head of Infrastructure.

Configuration Change Management Policy

A configuration change management policy focuses on software configuration, system baselines, and infrastructure-as-code. If your team uses Terraform, Kubernetes, or similar tools, changes to those configurations are just as much in scope as code changes. Auditors know this, and they will ask for evidence of configuration change approvals alongside application deployments.

The Real Cost of Skipping Change Management

I have talked to founders who found out their change process was broken during a live SOC 2 audit. Not before. During.

The auditor pulls a sample of 25 recent changes and asks for the approval record, the test results, and the rollback plan for each one. The company has tickets in Jira, but half of them were self-approved by the engineer who made the change, and none of them have a rollback documented. That is not a minor finding. That is a material weakness that can delay certification or kill a deal.

There are three ways a missing change management policy hurts you.

Security risk. Uncontrolled changes are one of the leading causes of security incidents. Misconfiguration from an unreviewed change, access controls accidentally widened during a deployment, a firewall rule added “temporarily” and never removed. The pattern is almost always the same: the change happened outside any formal process, so nobody caught the risk before it became an incident.

Audit failures. SOC 2 CC8.1 and ISO 27001 A.8.32 both require evidence that changes are controlled and documented. If you cannot show a consistent, repeatable process across your sampled changes, you fail the control. That is not a theoretical risk; it is one of the most commonly failed controls in first-time audits.

Regulatory exposure. In banking, healthcare, and government, the regulatory change management policy requirements are not optional. HIPAA requires audit controls over system activity. PCI DSS CC6.4 requires testing and approvals for software changes. Financial regulators expect a documented change register. For companies in these sectors, the absence of a policy is not just an audit risk; it is a compliance violation.

Does Your Company Need a Change Management Policy?

If you have engineers pushing code to a production environment, yes. The question is not whether you need one; it is how complex it needs to be.

SaaS and Tech Startups

If you are pursuing SOC 2 Type II, a change management policy is not optional. CC8.1 is one of the most consistently tested controls, and auditors will sample your change history across the entire audit period. Every sampled change needs an approval record, a test result, and a rollback plan.

The good news: for a small team, “ticket in Jira with a peer review and a rollback note” is a perfectly valid process. You do not need a Change Advisory Board or a weekly CAB meeting. You need a documented, consistently followed process that produces evidence for every change.

Healthcare and Fintech

If your systems touch ePHI (electronic protected health information) or payment card data, your regulatory obligations go beyond SOC 2. HIPAA’s Security Rule requires audit controls over system activity, which includes changes to systems that process or store ePHI. PCI DSS requires testing and approval of all changes to in-scope systems.

For companies operating in banking or financial services, the change management policy for banks requirement is even more explicit. This is a regulatory change management policy obligation: regulators expect a documented change register, approval workflows, and evidence of testing. They audit it directly, not just through a third-party certification. Change management policies at these companies are not just compliance documents; they are regulatory artefacts.

Cyber Security Change Management Policy

Security teams have an additional layer of concern. A cyber security change management policy specifically gates changes that affect your attack surface: firewall rules, IAM permissions, network segmentation, encryption settings, and security tooling configuration.

A developer adding a new outbound firewall rule, or widening an S3 bucket policy “just for this deployment,” are exactly the kinds of changes that should trigger a security review before they go to production. If your change management policy does not explicitly include security-impacting changes, it has a hole.

Building Your Change Management Policy Document: What to Include

The most common gap I see in a change management policy document is scope. The policy covers code deployments but silently excludes infrastructure changes, configuration updates, and emergency fixes. Auditors notice.

Your change management policy and procedures should account for every type of change that affects the security, availability, or integrity of your systems. Think of it as the companion document to your patch management policy: patches are a common trigger for change requests, and the two processes should be explicitly linked. Here is what every section should cover:

Free Change Management Policy Template

Below is a sample change management policy you can adapt for your organisation. This change management policy example covers the core sections that SOC 2, ISO 27001, and NIST require.

Use it as your change management policy and procedures starting point, then customise the change types, approval workflow, and tooling references to match how your team actually works. A sample change management policy like this one is what most auditors expect to see as your base document. Adjust the change types, approval thresholds, and tooling references to match how your team actually works.

A PDF version is available to download below.

How to Write and Roll Out a Change Management Policy

Writing the document is the easy part. Getting your team to actually follow it is where most companies struggle.

Here is a step-by-step approach that works for teams of any size:

1. Assign an owner. This should be your IT Manager, CISO, or Head of Engineering. Without a named owner, the policy will never get reviewed or enforced. One person is accountable.

2. Audit your current process. Before you write anything, document how changes actually happen today. Are engineers using pull requests with peer reviews? Jira tickets? Slack messages? Nothing at all? Your policy should formalise what works and fix what does not.

3. Define what counts as a change. Be explicit. Code deployments, infrastructure changes, configuration updates, network rule changes, IAM permission changes, and changes to third-party integrations all count. If you leave out a category, people will treat it as out of scope.

4. Classify your change types. Three categories work for most teams: standard (pre-approved, routine), normal (requires review and approval), and emergency (expedited with retrospective). Start here and add complexity only if you need it.

5. Design your approval workflow. Who approves which type of change? What information is required before approval? What is the SLA? Document this clearly. Ambiguity is how approvals get skipped.

6. Choose your tooling. Map the policy to the tools your team already uses. If engineers live in GitHub, define how pull requests serve as change records. If you use Jira, define the ticket fields required for a change request. A policy that lives separately from your tooling will not be followed.

7. Draft, review, and get leadership sign-off. The policy owner drafts it. Legal, IT, and engineering leadership review. An executive signs off. This is what auditors mean by “formally approved.”

8. Communicate and collect acknowledgements. Send the policy to everyone it applies to. Collect acknowledgements: a signed form, a checkbox in your onboarding system, or a confirmation in your compliance tool. Auditors will ask for this.

9. Map to compliance controls. Link the policy to the specific controls it satisfies: SOC 2 CC8.1, ISO 27001 A.8.32, NIST CM-3. This makes evidence collection straightforward at audit time.

10. Schedule the first review now. Set a calendar reminder for 12 months from the effective date. Do not wait until audit prep to review the policy; by then it is always out of date.

Change Management Policy Requirements: SOC 2, ISO 27001, and NIST

Every major framework has a change management requirement. The language differs, but the expectation is the same: evidence that changes are controlled, approved, and documented.

Change Management Policy for SOC 2

SOC 2 CC8.1 is one of the most consistently tested controls in a SOC 2 Type II audit. The auditor will pull a sample of changes from across your audit period, typically 25 to 40, and ask for the approval record, test evidence, and rollback plan for each one.

What they want to see:

• A change request (ticket) exists for every sampled change
• The change was approved by someone other than the person who made it
• Pre-deployment testing was completed and the result is documented
• A rollback procedure was identified before deployment
• Emergency changes have a retrospective on file

If half your sample has no approval record, you have a finding. If any sampled change was self-approved, you have a finding. The bar is not high, but it requires consistency across the entire audit period, not just the week before the audit.

ISO 27001 Change Management Policy

ISO 27001 A.8.32 (2022 version) requires that changes to information processing facilities and systems are formally managed. Specifically:

• Changes must be assessed for security impact before implementation
• Changes must be tested before deployment where possible
• Documentation must be maintained for all significant changes
• Rollback procedures must exist for changes that could have major impact
• Emergency changes must be reviewed retrospectively

Your policy must be formally approved, version-controlled, and reviewed at least annually. Unlike SOC 2, ISO 27001 does not prescribe a specific sample-based audit approach, but your certification auditor will review the policy document itself and select a sample of changes to test.

What Auditors Actually Want to See

The policy document is table stakes. Auditors test whether the process is actually happening. Here is what they will ask you to produce:

All of this evidence feeds into your broader logging and monitoring policy: change logs and deployment records are part of the same audit trail that your logging infrastructure should be capturing.

The most common gap: teams have a policy and they have change tickets, but the tickets are missing approval records for a significant portion of the sample. Auditors treat that as evidence the process is not being consistently followed, even if it is mostly followed.

Change Management Policy Mistakes That Trip Up Startups

I have reviewed enough change management findings to know these come up again and again. None of them are hard to fix in advance. They are all hard to explain to an auditor after the fact.

1. No emergency change process. When something breaks in production at 2am, the last thing anyone is thinking about is filing a change request. Without a defined emergency process, every urgent fix bypasses the policy entirely. Then the auditor pulls a sample, the outage-related changes are in it, and there is no approval record anywhere. Build the emergency path into the policy from day one: fast approval, mandatory retrospective.

2. Scope that only covers code. The policy says “all code deployments require approval.” Infrastructure changes, Terraform runs, firewall rule updates, IAM permission changes: none of them are “code,” so teams treat them as out of scope. Auditors do not. Define scope explicitly and include every category.

3. No rollback requirement. A change ticket with no rollback plan is not a complete change request. It is an assumption that everything will go fine. It almost always does. But when it does not, the absence of a documented rollback makes the incident worse and the audit finding harder to defend.

4. Approvals that are rubber stamps. If every change is approved within five minutes by the same person without any questions asked, auditors will flag it. They are looking for evidence of a real review, not a formality. An approval with a brief comment (“reviewed, LGTM, rollback plan confirmed”) looks very different from 300 tickets all stamped in sequence.

5. Policy not connected to tooling. The policy says “submit a change request” but does not specify where or what fields are required. So every engineer does it differently: some use Jira, some use Notion, some send a Slack message. When the auditor asks for the change log, there is no consistent record to show. Define the tool and the required fields in the policy itself.

6. Policy never updated after incidents. If a change caused a major outage and the post-mortem concluded the process needed to change, that change should be reflected in the policy. Leaving the policy as-is after an incident that proved it did not work signals to auditors that the process is not taken seriously.

7. IT and engineering are in scope but security is not. Changes to firewall rules, IAM policies, and security tooling configuration have security impact. If those changes are made by a security team that is not covered by the change management policy, you have a significant gap that most auditors will find.

IT Change Management Policy vs. Enterprise: Getting the Scale Right

A 10-person startup and a 500-person enterprise both need a change management policy. Change management policies do not need to be the same size to be effective. The goal is a process that produces consistent evidence, not maximum bureaucracy.

Small Teams and Startups (under 50 people)

Keep it simple. A GitHub pull request with a peer review, a required rollback note in the PR description, and a merge by someone other than the author is a legitimate change management process. You do not need a formal CAB, a separate change request form, or a weekly approval meeting.

What you do need:

• A documented process people actually follow
• Approval by someone other than the change requester
• A rollback plan written down before deployment
• A log of what changed and when

That is it. That is enough to pass SOC 2 CC8.1 at a startup scale, provided you do it consistently.

Growing Companies (50–200 people)

At this stage, informal processes start to break down. People join the company and do not know the process. The team is big enough that a single peer reviewer is not always a real review. You need to formalise.

• Define your change types explicitly
• Set SLAs for approval (24 hours for normal changes is common)
• Consider an async Change Advisory Board: a dedicated Slack channel where changes are posted for review with a 24-hour window before deployment
• Require a named approver, not just “a peer”
• Start tracking your change log in a consistent tool

Enterprise Change Management Policy

At enterprise scale, an enterprise change management policy needs formal governance structures that a small team does not. Expect:

• A Change Advisory Board that meets regularly (weekly or bi-weekly)
• A formal change calendar showing planned maintenance windows
• Separate approval tracks for standard, normal, and emergency changes with defined escalation paths
• Integration with ITSM tooling (ServiceNow, Jira Service Management)
• Full audit trail exportable on demand
• Legal and compliance review of the policy itself before approval

The process should match the risk. An enterprise deploying to systems used by thousands of customers has more at stake in each change than a startup with 50 users.

Keeping Your Change Management Policy Audit-Ready with ComplyJet

Managing a change management policy manually means tracking approvals in a ticketing tool, chasing acknowledgements over email, and hoping someone scheduled the annual review before the auditor asks for it.

ComplyJet handles the admin. You get a pre-built change management policy template already mapped to SOC 2 CC8.1, ISO 27001 A.8.32, HIPAA, and NIST. Assign the policy owner, customise the change types and approval workflow for your team, and collect acknowledgements from everyone the policy applies to, all in one place.

Every review cycle is time-stamped and signed off in ComplyJet. When your auditor asks for the review history or the acknowledgement records, you export them directly. No spreadsheets, no hunting through email threads.

Control mapping is built in. Link your change management policy to the SOC 2 or ISO 27001 controls it satisfies, and your evidence package is always up to date.

FAQs

What is a change management policy?

A change management policy is a formal document that governs how changes to IT systems, infrastructure, code, and configurations are proposed, reviewed, approved, tested, deployed, and recorded. Its purpose is to prevent uncontrolled changes from causing outages, security incidents, or audit failures. Every organisation operating software in production needs one, and most security frameworks explicitly require it.

What is the difference between change management and change control?

Change management is the broader governance framework: the policy, process, and culture that ensures changes are handled consistently. Change control is the specific approval and gating mechanism within that framework: the step where someone reviews a proposed change and approves or rejects it before deployment. In practice, most frameworks use the terms interchangeably. What matters is having both a documented policy and an approval process that produces evidence.

What should a change management policy include?

A complete change management policy should cover: purpose and scope (which systems are included), definitions of change types (standard, normal, emergency), roles and responsibilities (who requests, who approves), the change request process (how to submit, what information is required), testing and rollback requirements, documentation requirements, emergency change procedures, exceptions handling, enforcement, and review cadence.

Does SOC 2 require a change management policy?

Yes. SOC 2 Trust Services Criteria CC8.1 explicitly covers change management. Auditors will sample changes from across your audit period and verify that each one has an approval record, test evidence, and a rollback procedure documented. Consistently missing any of these for sampled changes results in a finding. This is one of the most commonly failed controls in first-time SOC 2 audits.

How do I write a change management policy?

Start by documenting how changes actually happen at your company today. Then define your change types, design your approval workflow, choose your tooling, draft the policy, get leadership sign-off, communicate it to the team, and collect acknowledgements. Map it to your compliance controls and schedule the first annual review before you publish it. The full step-by-step is in the implementation section above.

How often should a change management policy be reviewed?

At minimum, annually. You should also trigger a review after any major incident caused by a change that went wrong, after a significant change to your infrastructure or architecture, after receiving an audit finding related to change management, or when a new compliance requirement introduces new change management obligations.

What is an emergency change and how should it be handled?

An emergency change is a high-priority change that cannot wait for the normal approval process because of a live incident or critical security vulnerability. It should be approved verbally or asynchronously by an authorised approver, deployed with a record of who approved it and when, and followed by a mandatory retrospective within 24–48 hours documenting what changed, why it was treated as an emergency, the outcome, and any preventive actions.

Related Policies

• Logging and Monitoring Policy: Change logs and deployment records are a key part of the audit trail your logging infrastructure should capture. The two policies should reference each other.