Change management is where compliance and engineering most often collide. Auditors ask for evidence that production changes were authorised, tested and traceable; engineering hears a request to reinstate a weekly approval board and deploy monthly. Both readings are avoidable, because what the control actually requires maps cleanly onto a well-run pipeline.
What the control is really asking
Strip the vocabulary away and every framework wants four things:
- Authorisation. Someone other than the author agreed the change should happen.
- Testing. It was verified before reaching production.
- Segregation. The person who wrote it is not the only person involved in releasing it.
- Traceability. You can reconstruct afterwards what changed, when, by whom, and why.
Nothing in that list mentions a committee, a change window, or a form. A pull request with a required independent reviewer, automated tests, and a pipeline that records the deployment satisfies all four - and produces better evidence than minutes of a meeting, because it is complete and cannot be reconstructed after the fact.
Evidencing it from a pipeline
- Branch protection requiring review before merge - this is your authorisation control, and the configuration is the design evidence.
- Block self-approval. The most commonly missed setting, and the one that breaks segregation entirely if left open.
- Automated test gates that must pass, with results retained.
- Deployment only through the pipeline, with direct production access removed or broken-glass only. If engineers can deploy manually, your evidence covers the changes that went through the pipeline and says nothing about the others.
- Immutable deployment logs tying a release to a commit, a reviewer and a time.
- Linkage to a ticket capturing the business reason - the "why" that a commit message rarely records.
Configure it once and every change is evidenced automatically, with a population an auditor can sample. That is a materially stronger control than a monthly meeting, and it costs the engineering team nothing per change.
Evidence change control automatically
GRC Copilot connects to your source control and ticketing, maps change evidence to the controls it satisfies, and flags deployments that bypassed the approved path.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Three change types, three routes
- Standard changes - pre-approved, low-risk, repeatable. Adding a user to a documented group, routine patching, scaling. Approved once as a category, then executed without individual sign-off. Keeping this category well-populated is what stops a change process from becoming a tax.
- Normal changes - the default path: review, test, approve, deploy, record.
- Emergency changes - expedited, with reduced pre-approval but mandatory post-implementation review within a defined window. This is where audits find problems.
Emergency change, the area that fails
Emergency changes are legitimate and necessary. They become findings when the retrospective half never happens. What an auditor checks:
- Emergency changes are a small proportion of the total. If a third of changes are emergencies, the normal process is unusable and people are routing around it - which is a process problem, not a discipline problem.
- Each has a documented justification for why it was an emergency.
- Each received retrospective approval and review within the stated window.
- Any temporary access granted was revoked afterwards - frequently missed.
Changes that are not code
Scope routinely gets drawn too narrowly around application deployments. Also in scope: infrastructure and cloud configuration, firewall and network rules, identity and access configuration, database schema and data fixes, third-party integrations, and security tooling configuration. Manual database changes in production are a perennial finding - they are often the only category with no pipeline and no reviewer.
What auditors sample
Typically a set of production changes from the period, checking each for approval before deployment, evidence of testing, an approver different from the implementer, and a rollback plan for significant changes. They will also work the other direction - taking deployment logs and confirming each has a corresponding approval. That reverse test is what finds the changes that bypassed the process, so run it on yourself first.
Frequently asked questions
Does continuous deployment conflict with change management?
No. Automated gates and required reviews satisfy the control at any deployment frequency. Deploying fifty times a day with enforced review is stronger than deploying monthly after a meeting.
Do we need a change advisory board?
No framework requires one. It is one way to achieve authorisation, and usually not the best one for software changes - though it can still make sense for high-risk infrastructure work.
Can the same engineer write and deploy?
Writing and triggering a deployment is acceptable if an independent reviewer approved the change and the pipeline enforces the gates. What fails is unreviewed code reaching production on one person's action.
How do we handle a two-person team?
Mutual review, and where genuinely impossible, a documented compensating control - post-deployment review of all changes by the other person, with the constraint and its acceptance recorded.
Key takeaways
- The control wants authorisation, testing, segregation and traceability - not a committee.
- Block self-approval and remove manual production deploys, or your evidence is incomplete.
- Keep the standard-change category well-populated so the process is not a tax.
- Emergency changes fail on the missing retrospective review - and on unrevoked temporary access.