Traditional change management meant a change advisory board, a request form, and a weekly meeting. Software teams that deploy many times a day do not work that way, and auditors do not expect them to. For most of them, the pull request review is the change approval.
That works, provided the review does what an approval is supposed to do. It has to be independent of the author, happen before the change reaches production, cover every route by which production changes, and leave a record the auditor can sample. Teams usually get the first two right and lose points on the last two.
This article covers what the frameworks require, what a review has to establish, why independence matters, which changes must go through review, how to handle emergencies and small teams, and what an auditor will sample.
What the frameworks require
None of the major frameworks says "code review" as the method for change approval, with one partial exception.
SOC 2 CC8.1 requires changes to infrastructure, data, software, and procedures to be authorized, designed, developed or acquired, configured, documented, tested, approved, and implemented. Review is how most software teams evidence authorization, testing, and approval in one place.
ISO 27001:2022 Annex A 8.32 requires changes to information processing facilities and systems to follow change management procedures. Annex A 8.25 (secure development life cycle), 8.28 (secure coding), and 8.29 (security testing in development and acceptance) sit alongside it.
PCI DSS v4.0 Requirement 6.2.3 requires bespoke and custom software to be reviewed before release to identify and correct potential coding vulnerabilities. Where reviews are manual, 6.2.3.1 requires reviewers other than the original author who know code review and secure coding, and management approval before release. Requirement 6.5.1 sets the wider change procedure: reason, description, security impact, approval, testing, and back-out.
NIST SP 800-53 Rev. 5 CM-3 covers configuration change control, CM-4 impact analysis, and CM-5 access restrictions for change.
For SOC 2 teams, what the SOC 2 security criterion actually requires shows how CC8 relates to the other common criteria.
What a review has to establish
A review that serves as change approval should show four things for each change:
It was intended. The change links to a ticket, issue, or stated purpose. Some auditors ask for this; whether you require it should be in your change policy.
Someone other than the author reviewed it. A named approver, recorded by the system.
It was tested. Automated checks ran and passed before merge, and the reviewer could see the results.
Approval came before production. The approval timestamp precedes the merge and the deployment.
The reviewer is attesting that they read the change, understood it, and consider it fit to deploy. A review policy should say what they are expected to check: correctness, security implications, tests, and anything your secure coding standard calls out. An approval clicked in seconds on a large change will hold up in a sample, but it is a weaker control than it appears, and it will eventually miss something that matters.
Independence is the point
The value of review as a control comes from segregation of duties. The person who wrote the change should not be the only person who decided it could ship.
The ways independence quietly fails:
Self-approval. Some platforms allow it, or allow a second account owned by the same person.
Admin bypass. Administrators who can merge without review, even when rules require it for everyone else.
Changes after approval. New commits pushed after the review was given, merged without a fresh look.
Automation acting as approver. A bot that approves its own dependency updates, or an auto-merge that runs without a human review.
Each of these is usually prevented by repository settings. Configuring those settings is a topic of its own; the control question is whether they were in force throughout the period, and whether any bypass was recorded and justified.
Which changes must go through review
The review control only covers changes that pass through the repository. The auditor will ask how else production can change, and every other route needs either the same review or its own control.
Application code. The obvious case.
Infrastructure as code. Network rules, permissions, and resources defined in code should go through the same review.
Database migrations. Schema changes, reviewed like code.
Configuration and feature flags. Changes that alter production behavior without a deploy. Decide which flags are in scope and how changes to them are approved.
Direct console changes. Changes made by hand in a cloud console bypass review entirely. Restrict who can make them, log them, and review the log.
Production data fixes. Manual queries that change customer data. These need a request, an approval, and a record, even if not a pull request.
Console changes are a frequent gap. If engineers routinely change production by hand, the code review control is real but incomplete, and an auditor who compares the cloud change log with the repository will notice.
Emergency changes
Production incidents sometimes need a fix faster than a normal review allows. A sound policy permits that and controls it afterwards:
Define what qualifies as an emergency, and who can declare one.
Allow the fix with a reduced or delayed review, for example approval from the on-call lead.
Require a full retrospective review within a defined time, such as the next business day.
Label emergency changes so they can be found later as a population.
Auditors often sample emergency changes separately. A retrospective review that never happened is an exception, even if the fix was right.
Small teams
A two-person engineering team can review each other's work, and that meets the control. A solo engineer cannot.
For a team of one, be explicit. Document that independent review is not possible, and put a compensating control in place: a scheduled after-the-fact review of merged changes by a technical advisor or a manager, automated tests and security scanning that must pass before merge, and a deployment log that someone else reads. An auditor can work with a documented limitation. They cannot work with a policy that claims independent review that did not happen.
What an auditor will sample
The test is mechanical. The auditor asks for the population of changes deployed to production during the period, generated from the system: merges to the production branch, or deployment records. They sample from it. How auditors sample controls covers how the sample size is chosen.
For each sampled change they look for:
- Not done:
The pull request, with author and approver
- Not done:
An approver other than the author
- Not done:
Approval timestamped before merge
- Not done:
Required checks passed before merge
- Not done:
A deployment record that matches the merged change
- Not done:
A linked ticket or purpose, if your policy requires one
They will also ask for evidence that repository rules requiring review were in force across the period, and for any record of bypasses. Exports and audit logs from the source control system carry far more weight than screenshots of a settings page; screenshots vs system-generated evidence explains why.
The usual exceptions are predictable: a self-merged change, an admin bypass with no recorded reason, commits added after approval, and an emergency change with no retrospective review.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the code systems you connect and routes failures to their owners. Evidence collection gathers evidence from those systems on a schedule, timestamped and attributed, so the change population and repository settings are captured across the period rather than reconstructed for the audit.