Change Management Policy

change-management.md·SOC 2 · CC8.1

Generate a Change Management Policy covering review, testing, approval, and rollback — the control enterprise security reviews check (mapped to CC8.1).

Generate this policy Browse all policies

What's in the policy

Ensures changes to systems are reviewed, tested, approved, and tracked.

✓Change request and approval workflow

✓Testing and rollback requirements

✓Segregation of duties

✓Emergency change procedures

✓Change logging and traceability

✓Release and deployment management

Mapped toSOC 2 (CC8.1)ISO 27001 (A.8.32)PCI DSS

What the document actually says

These are the standing requirements every generated copy of the document is written from — the clause text itself, not a description of it. The document you receive is drafted on top of them: it expands on them and fills the current-state detail from your intake, and the generator is instructed to keep them, to state them fully, and never to claim a certification or invent a fact you did not supply.

The change nobody planned for

Emergency changes to resolve an incident may bypass standard lead times but must still be recorded, reviewed retroactively within 2 business days, and approved by the document owner.

SOC 2 CC8.1 · ISO 27001 A.8.32 — the bypass is written down rather than improvised, and it still costs three things: a record, a retrospective review on a two-day clock, and an approval from the document owner.

Who may approve, and who may deploy

No single individual should be able to author, approve, and unilaterally deploy a high-risk change without oversight. Where team size limits strict separation, compensating controls (mandatory review, audit logging, post-deploy verification) are applied and documented.

SOC 2 CC8.1 · ISO 27001 A.5.3, A.8.32 — segregation stated as an outcome rather than a headcount, with the small-team escape hatch named and its three substitute controls listed instead of left to argue about.

The five things true of every production change

- All production changes are tracked through version control and/or a ticketing system with a clear description, author, and approver. - Code and infrastructure changes are peer-reviewed and approved by someone other than the author before merge/release. - Changes are tested (automated and/or manual) in a non-production environment before deployment to production. - Changes are deployed through an automated, repeatable pipeline wherever feasible, minimizing manual steps. - Every change is reversible — a rollback or forward-fix path is understood before release.

SOC 2 CC8.1 · ISO 27001 A.8.32 — the change record's required contents are enumerated as description, author and approver, and reversibility is owed before a release rather than discovered during one.

GitHub + Linear + PagerDuty

Filled in for a real stack

Placeholder

Code review & deployment process: To be confirmed.

Resolved

Code review & deployment process: every change opens a Linear issue and a GitHub pull request approved by somebody other than its author; main deploys itself once checks pass. A PagerDuty incident is what authorises an emergency change, and the retrospective approval is written back onto the same Linear issue.

What the auditor asks for alongside it

A sample of production changes, with the approver on each one who was not its author.

Your version control and ticketing history. This document sets what a change record must contain — a clear description, an author, an approver — and disqualifies one person from being two of them. The rows are yours; the standard they are read against is the clause.

Every emergency change in the period, and the retrospective approval attached to each.

Your incident tickets, read against the emergency clause. It is what lets standard lead times be skipped, and it prices the permission: recorded, reviewed retroactively within two business days, approved by the document owner. An emergency change with no retrospective approval is the exception a reviewer writes up.

Evidence that a release was actually reversed, and that the path back existed beforehand.

Your revert commit or rollback run, with the release note beside it. The reversibility bullet asks for a rollback or forward-fix path to be understood before release — a claim about what somebody knew in advance, which a rollback that worked shows and a runbook written afterwards does not.

Whether anything you have shipped since the last test invalidates its result.

The penetration test report, which limits itself in writing: a point-in-time evaluation of the in-scope assets, where changes made after testing may introduce new issues. Your change log across the same window tells a reviewer which of those changes touched the tested surface — and this policy is what obliges the log to exist.

Where these documents go stale

A change management policy goes stale in a settings page, not in the document. The rule that a second person must approve is a toggle on a branch; it gets loosened during one bad night and nobody remembers to tighten it again. A deploy key issued to a contractor for one sprint outlives the contract. A release that used to run from the pipeline starts being run by hand, because the pipeline is slow this week. The emergency clause routes every unplanned change to the document owner for retrospective approval, and when that role changes hands the clause carries on naming a job title rather than a person. Re-validating it is a sample, not a re-read: take your last twenty production changes, check each against the five requirements, then confirm every incident that touched production left a retro-approved record.

From intake to enterprise-ready in three moves

Tell us about your stack

Answer a short intake — cloud, data types, tools. No agents to install.

We generate a tailored draft

Not a blank template: a document written for your environment and pre-mapped to controls.

Review, edit, and share

Export it or attach it straight to an enterprise security review or questionnaire.

Change Management Policy, answered

What is a change management policy?

A change management policy states how a change to production is requested, approved, tested, released, and reversed, and who is permitted to do each of those. Reviewers use it to decide whether the code now running in front of your customers arrived there by a route somebody authorised.

What has to be in a change record?

A change record needs three things at minimum: a clear description of the change, the person who authored it, and the person who approved it, held in version control, a ticketing system, or both. The record missing an approver is the one an auditor pulls, because nothing in it shows the change was authorised.

Does SOC 2 require a change management policy?

Yes, in substance. CC8.1 is the criterion, and an auditor does not stop at the document: they pull a sample of real changes from the period and read each one against what it says. A policy nobody followed fails on the sample, not on the wording. This document is written against CC8.1 and ISO 27001 A.8.32.

What counts as an emergency change?

An emergency change is one made to resolve an incident. The policy lets that skip the standard lead times and nothing else: it must still be recorded, reviewed after the fact within two business days, and approved by the document owner. Labelling ordinary work an emergency to dodge review is the pattern this clause exists to expose.

How is this different from the secure SDLC policy?

Change management is about permission and reversal — what a change record holds, who signs it off, who may push it, and how it comes back out again. The Secure SDLC Policy is about craft: threat modelling, coding standards, scanners in the pipeline. A release can be perfectly authorised and still badly built.

Can a two-person team meet segregation of duties?

Yes, and the Change Management Policy says how. It asks for an outcome rather than a headcount: nobody authors, approves, and unilaterally deploys a high-risk change unchecked. Where the team is too small for strict separation it names the substitutes — review that cannot be skipped, an audit log, verification after the deploy — all documented.

How does Pentest Today generate the policy?

Answer a short intake about your stack and we generate a tailored draft — not a blank template — pre-mapped to the controls your framework requires. You review, edit, and export it.

Can I edit the generated policy?

Yes. Every document is a starting draft you can edit, brand, and export. It's written to be review-ready but stays fully under your control.

Free · no account

Start your Pentest

Our agent swarm and human experts test your endpoints and deliver an audit, fast.

Start your Pentest How it works

Generate your full security policy pack.

Get the change management policy plus everything else an enterprise security review asks for — generated from your real environment.

Get started Browse all policies