Change management evidence auditors accept
Change management is one of the most heavily sampled controls in any audit. Engineering teams often do it well and evidence it badly. Here is what auditors look for.
In a SOC 2 Type II audit, change management (CC8.1) is one of the most heavily sampled controls: the auditor picks changes from across the period and asks you to prove each one was authorised, tested and approved before production. ISO 27001 (A.8.32), PCI DSS (6.5.1, 6.5.2) and NIS2's Implementing Regulation (point 6.4) ask for the same thing in different words. Engineering teams usually do the work; the evidence is what goes missing.
What auditors test
For a sample of changes, they want to see:
- The change was requested and described: a ticket or pull request saying what and why.
- It was reviewed by someone other than the author: segregation of duties.
- It was tested before production, with results.
- It was approved before deployment.
- What was deployed is what was approved: no unreviewed code reached production.
- The population is complete: every production change went through the process, including infrastructure and configuration.
Evidence that passes
- Branch protection: the main branch requires at least one approving review from someone other than the author, and passing checks, before merge. Export the settings and show they didn't change during the period.
- Pipeline-only deployment: production deploys come only from the protected branch through CI/CD; engineers can't push directly.
- Linked records: each deployment links to the merged pull request, which links to its ticket.
- Infrastructure as code under the same rules, so infrastructure changes leave the same trail.
- A complete change list from the deployment tool for the period, from which the auditor can sample.
Emergency changes
Every process needs a fast path for incidents, and auditors expect one. Define it: who can approve, how quickly retrospective review happens (within one or two working days is common), and how the change links to the incident. Then make sure emergency changes really are rare.
What fails audits
- Admins with direct production access who sometimes bypass the pipeline.
- Self-approved pull requests, or reviews by bots only.
- Configuration changes made in a console with no record.
- Branch protection switched off "temporarily" during the period.
- No test evidence beyond "CI passed", where the change needed more.
Sampling: what the auditor will actually do
In a SOC 2 Type II, the auditor typically asks for the full population of production changes in the period, picks a sample (size depends on the population and the auditor's methodology), and asks you to show for each sampled change: the request, the review by someone other than the author, test results, the approval, and that what was deployed matches what was approved.
Two practical consequences follow. First, the population must be complete and exportable: if changes can reach production by more than one route, every route needs a record. Second, any one sampled change without evidence becomes an exception in the report. It's cheaper to fix the process so that evidence is automatic than to reconstruct it under audit.
The SOC 2 CC8.1 page shows how the criterion maps to ISO 27001, PCI DSS and NIS2.
One process, every framework
In our data, change management requirements link across frameworks:
| Direction | Mapped | No mapping | ||
|---|---|---|---|---|
| Have SOC 2 → need NIS2 | 47 of 49 (96%) | 1 | 1 | report → |
| Have NIS2 → need SOC 2 | 37 of 61 (61%) | 0 | 24 | report → |
A pull-request-based process with protected branches and pipeline-only deployment satisfies SOC 2, ISO 27001, PCI DSS and NIS2 together. PCI DSS adds a few extras: separating pre-production from production (6.5.3), keeping live account data out of test (6.5.5) and confirming security requirements after significant changes (6.5.2).
See the Secure Development topic for related requirements and our post on reusing evidence across SOC 2, ISO 27001 and PCI DSS.
Questions
Do pull requests count as change approval for SOC 2?
Usually, if the repository enforces review by someone other than the author before merge, deployment is restricted to the approved code, and you can show this for a sample of changes across the period.
How should emergency changes be handled for audit?
With a defined emergency process: fix first if needed, then retrospective review and approval within a set time, and a record linking the change to the incident that justified it.
Data as of 2026-10-27: numbers in this post are computed from the current crosswalk and update when it changes. Crosswalk a published crosswalk (NIST, ENISA, CIS, PCI SSC) makes the link · Editorial ControlMapping's judgement where no crosswalk exists; the reason is shown · only shares a CSF 2.0 outcome: worth checking, not a mapping · No mapping in our data nothing mapped in our data; often new work, but check the coverage notes. Not compliance advice.
Related posts
Analysis · 2026-10-27APRA CPS 234 and ISO 27001: what your ISMS covers and what APRA addsAn ISO 27001 ISMS covers nearly every paragraph of APRA's CPS 234, yet APRA adds Board duties, third-party assurance and strict notification deadlines.
Analysis · 2026-10-27DORA vs NIS2: what a NIS2 programme already coversDORA and NIS2 share most of their security content, but DORA adds a register, contract terms and threat-led testing. Article by article, what carries over.
Analysis · 2026-10-13MFA requirements compared across 11 security frameworksWhich frameworks require MFA, for whom and how strictly: PCI DSS, CMMC, NIS2, Essential Eight, ISO 27001, SOC 2 and HIPAA compared side by side.