Auditors are not testing whether you have a change process. Everyone has one. They are testing whether anything reached production without going through it, and whether the changes that did go through it were authorised, tested and approved by someone other than the person who wrote them.
That reframing matters because it tells you where the effort goes. Documenting your beautiful pull request workflow is the easy half. Proving that the workflow is the only way code gets to production — that is the half that determines whether your change management controls survive testing.
What the auditor is actually testing
For a Type 2, an auditor will typically want to see four attributes for each sampled change: that it was requested or tracked somewhere, that it was tested, that it was approved by someone independent of the author, and that what was approved is what was deployed. The fourth is the one teams forget — traceability from the deployed artifact back to the approved change.
They are also testing that the process described in your system description is the process that ran. If your description says “all production changes require peer review and passing automated tests prior to merge”, then a single merge with a failing test suite and an admin override is a direct contradiction of the words you published, and it will be treated as one.
The population is every change to production
This is where high-velocity teams get into trouble, and it is worth being precise about it. The auditor needs a complete list of production changes across the period before they can sample from it. Their standing question is: how do you know this is all of them?
An incomplete population undermines everything sampled from it. If ten changes are pulled from a list that covers only your main application pipeline, every one of them can be immaculate and the auditor still cannot conclude that the control operated — because the changes that bypassed the pipeline were never eligible for selection. Completeness is not administrative fussiness; it is the difference between a sample that means something and a sample that means nothing.
The paths to production people forget:
- Infrastructure changes made through the cloud console rather than through code
- Database changes — schema migrations, and worse, manual data fixes run against production
- Configuration and feature flag changes that alter behaviour without a deploy
- Emergency hotfixes shipped outside the normal branch flow
- Third-party and vendor-pushed changes to systems in your scope
- Scheduled jobs and scripts run by engineers with production credentials
You do not necessarily need identical rigour for all of these, but you do need to have decided what counts as a change, said so in your policy, and be able to produce the list.
Preventive configuration is stronger evidence than a log
The most efficient answer to the completeness question is to make the bypass impossible rather than to detect it afterwards.
If branch protection on your production branch requires an approving review from someone other than the author and a passing status check, and administrators cannot override it, then the configuration itself is testable evidence. An auditor can look at that setting, look at the list of people who could change it, and conclude that merges to that branch necessarily carried review. The population then becomes something clean and defensible: merges to the release branch, exported from your source control system.
Layer a detective control underneath it. Cloud audit logs showing who made changes directly in the console, alerting when a deploy happens outside the pipeline, and a short list of humans holding standing production write access all support the claim that the pipeline is the only meaningful path.
Reconcile the two at least once during the period. Take the pipeline’s deployment records and the source control merge list and confirm they line up. Doing this yourself, and keeping the record, is a far better position than having the auditor do it for the first time during fieldwork.
What a sampled change should look like
For each change the auditor selects, aim to hand over a single linked chain:
- The ticket or issue describing what was being changed and why
- The pull or merge request, showing an approving review from someone who is not the author
- The automated test or build results for that specific commit
- The deployment record with a timestamp, the actor or pipeline run, and the version or commit hash deployed
- Where relevant, evidence of the release being verified after deploy
The linkage is what makes this cheap. Requiring the ticket identifier in the branch name or commit message means the chain assembles itself; without it, someone spends fieldwork week manually correlating merge times with deploy times.
Two things that quietly ruin otherwise good evidence
Log retention. Pipeline run history, cloud audit logs and deployment records frequently roll off at thirty or ninety days by default. If your observation window is twelve months and your CI history covers ninety days, months one through eight are simply unevidenced, and there is no way to recover them after the fact. Check retention settings before the window starts, not during fieldwork. This single item causes more avoidable pain than any control design question.
Approvals that are not approvals. A pull request approved by an automated account, approved by the author using a second account, or merged with a “review requested” that was never completed will not carry the control. Similarly, a “self-approve” allowed by policy for trivial changes needs to be defined in the policy with clear criteria, not applied at engineer discretion.
Emergency changes, honestly
Every company has emergencies, and auditors know it. What they look for is that the emergency path is defined, that it was used as defined, and that the retrospective approval actually occurred.
A workable pattern: emergency changes may bypass pre-approval, must be logged within a stated window, and must be reviewed and approved retrospectively by a named role within a stated timeframe. Then hold to it. An emergency change with no retrospective review is a common finding, and it is common precisely because the fix — a five-minute review the next morning — is the sort of thing that gets skipped once the fire is out.
Watch the volume as well. If a third of your changes are emergencies, the auditor will reasonably conclude that the emergency path is the normal path.
Segregation of duties on a small team
With four engineers, the person who wrote the code often deploys it, and pretending otherwise in your description is worse than acknowledging it. What you can usually do is separate authorship from approval even when you cannot separate authorship from deployment: another engineer reviews the change, the pipeline performs the deploy, and the deploy record shows what was deployed.
Where full separation is not achievable, some auditors will accept compensating detective controls — deployment notifications to a channel the whole team sees, periodic review of production changes by an engineering lead, and audit logging that cannot be altered by the deployer. Others will want the limitation described plainly in the system description. Practice varies by firm and by how much of the change surface is affected, so raise it during readiness rather than at fieldwork.
Making the evidence a by-product
The setup that costs the least over a year looks roughly like this. Tickets carry the change rationale. Branch protection enforces independent review and passing checks, with admin override disabled. Commit messages carry the ticket identifier. The pipeline is the only credentialed path to production, and its run history is retained for longer than your audit period. Emergency changes have their own ticket type with a mandatory retrospective approval field. Once a quarter, someone reconciles deploys against merges and files the result.
None of that is compliance work. It is the engineering hygiene most teams already want, arranged so that the record falls out of it.
What to do next
Check two settings today: your CI and cloud audit log retention periods, and whether administrators can override branch protection on your production branch. Those two answers determine whether your change management evidence will exist at all when it is requested.
Then list every way code or configuration can reach production and ask, for each one, what record it leaves behind. Any path with no record is the path your auditor will find.
Assurion performs SOC 1 and SOC 2 examinations and can review your change population and evidence chain during readiness, while the retention settings can still be fixed.