An auditor asks for evidence of your change management process. The instinct is panic, followed by building something: a change request form, an approval board, a weekly meeting. Six weeks later engineers are routing around it, and you have a process that produces documents nobody believes.
You already have change management. It is your pull request workflow, and it produces better evidence than any form, because it is generated by the work rather than alongside it.
This post is how to map what you already do to what an auditor needs, and the four gaps where your existing process genuinely does not cover you. For whoever is preparing for SOC 2 or ISO 27001 at a company that ships continuously.
What the control actually requires
Strip the framework language and change management asks four things:
Changes are authorised. Somebody other than the author agreed it should happen.
Changes are tested. There is evidence the change was exercised before reaching production.
Changes are traceable. You can connect what is running to who approved it and why.
Changes can be reversed. There is a way back.
Nothing in that list requires a form, a board, or a scheduled window. Those are one implementation, designed for infrequent releases to systems where rollback is hard. They fit continuous deployment badly, which is why teams route around them.
What your existing workflow already proves
Map each requirement to the artifact you already generate.
Authorisation: the pull request approval. A required review from someone other than the author, enforced by branch protection, is a stronger authorisation record than a signature on a form, because it cannot be applied retrospectively and it names a specific commit.
Testing: the CI run attached to the commit. Status checks required before merge, with the results retained. This is better evidence than a tester's checklist, since it is reproducible.
Traceability: the commit history, plus a deployment record linking an artifact to a commit. The link is what matters and it is the part most often missing. A deploy log saying "deployed v1.4.2" is weak; one saying "deployed image sha256:4f8e2b, built from commit 4a91c2" is a chain an auditor can follow.
Reversibility: your rollback procedure, plus evidence you have used it. A documented process that has never been exercised is a plan; a deploy log showing three rollbacks this year is a capability.
Write that mapping down as a one-page document. It is the single most useful artifact for an audit, because it tells the auditor where to look, and it converts your existing workflow into your stated control rather than something additional.
Make the enforcement real
The mapping only holds if the controls cannot be bypassed. Check these specifically, because this is where audits actually fail:
- Branch protection on every branch that deploys, not just the main branch of your main repository. Enumerate the repositories that can reach production and check each one.
- Administrators included. Most platforms let admins bypass required reviews by default. An auditor will ask, and "admins can merge without review" is a finding.
- Force push disabled, otherwise history is not evidence.
- Required status checks that actually run. A required check that is skipped on certain paths is a gap.
- Retention long enough. CI logs that expire in thirty days do not support an audit covering twelve months. Export what you need.
The four gaps
Your pull request process genuinely does not cover these, and every one of them will come up.
Emergency changes. Something breaks at 03:00 and somebody pushes a fix without waiting for review. This is legitimate and it needs its own path: allowed, logged, and reviewed after the fact within a stated window. An emergency process that exists on paper and is never used is a sign people are using the normal process dishonestly instead.
Infrastructure changes outside the repository. Someone changes a security group in a console. If your infrastructure is not entirely code, and it is not, this happens. The answer is either to bring it into code or to ensure the platform's own audit log is retained and reviewed, and to say which you have chosen.
Configuration and feature flags. A flag flipped in a dashboard can change behaviour as much as a deploy, with none of the controls. This is the gap teams most often do not realise they have. Treat significant flags as changes: log who flipped what and when, and retain it.
Data changes. A manual update to production data, run to fix a customer's record. Frequently invisible to every control above. At minimum it should require a second pair of eyes and leave a record.
Each of these needs a stated position. "We allow this, here is how it is recorded, here is who reviews it" is an acceptable answer. Silence is not, because the auditor will find one and then ask what else is uncontrolled.
Do not build a parallel process
The failure mode worth naming: a team builds a change ticket system to satisfy an auditor, engineers fill it in after merging because the real work happened in the pull request, and the tickets become a fiction that everyone maintains.
That is worse than having no process, because you now have documented evidence of a control that does not operate as described, which is a more serious finding than the gap it was meant to cover.
If your pull request workflow is the real process, make it the stated process, and put the effort into the four gaps instead.
The concession
There is a legitimate case for heavier change control. Systems where rollback is genuinely impossible, where a change has physical consequences, or where a regulator specifically requires a scheduled window and a named approver. Medical devices, industrial control, some financial settlement systems.
If that is you, the pull request workflow is a component rather than the whole control, and the additional process is doing real work. The argument here is narrower: for a SaaS product deploying several times a day with automated rollback, the heavyweight version adds latency without adding assurance, and the evidence it produces is weaker than what your pipeline already generates.
The implication
Auditors are not asking you to hold meetings. They are asking whether changes are authorised, tested, traceable and reversible, and whether you can show it.
You can, for nearly everything, from artifacts you already produce. Write the mapping, verify the enforcement, and spend the remaining effort on the flags, the console changes and the manual data edits, which are the parts genuinely not covered.
