Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which change management artifacts evidence controlled change?
Updated
A pull request with an independent approval, a passing required check, and a deployment record authorised by someone other than the author satisfies the intent of most change-control criteria. What auditors add is the complete population and the emergency-change path.
Change-management evidence map, last verified 10 September 2026 against the AICPA Trust Services Criteria CC8.1, ISO/IEC 27001:2022 Annex A 8.32 change management with 8.29 security testing and 8.31 separation of environments, PCAOB AS 2201 as the auditing standard behind information-technology general controls in a financial-statement audit, and ITIL change-enablement practice as best practice rather than requirement. None of those requires a change advisory board, a ticketing tool, or a separate change ticket per commit. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: an engineering leader, platform lead, or compliance owner whose team ships through pull requests and continuous deployment, and who has been told that real change management requires a change advisory board and a ticket per change. It does not.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. Whether a SOX programme reaches your systems is a question for your finance leadership, your external auditor, and counsel. Last verified 10 September 2026.
The useful framing is control intent. Every change-control criterion is asking the same four questions: was the change authorised, was it tested, was somebody other than the author involved before it reached production, and can you show that for every change rather than the ones you chose to show. A modern engineering workflow answers all four with artifacts it already produces — provided the enforcement is real and the population is complete.
- The population is the whole control. One unreviewed direct push to the protected branch in the period undermines a year of well-behaved pull requests, because the control was evidently bypassable.
- Emergency change is not a loophole to hide; it is a control to evidence. A recorded exception with an authoriser and a retrospective is stronger than a claim that emergencies never happen.
- Infrastructure and configuration changes are changes. Teams evidence application code carefully and then apply a cloud change by hand in a console with no record.
- Data changes matter in a financial-reporting context. A direct production database update is a change, and in a SOX scope it is one of the most scrutinised kinds.
Change-lifecycle-to-evidence map
Read the first column as the lifecycle stage, the second as the artifact, the third as the control intent it satisfies, and the fourth as the common failure. Last verified 10 September 2026. Not legal advice.
| Lifecycle stage | Evidence artifact | Control intent it satisfies | Common failure |
|---|---|---|---|
| Change initiation and intent | The pull or merge request with its description, linked issue or ticket, and the author identity | The change has a stated purpose and an owner. AICPA TSC CC8.1; ISO/IEC 27001:2022 Annex A 8.32. | Empty descriptions, so the artifact records that something changed without recording why. |
| Peer review and approval | The approval record naming a reviewer who is not the author, with the timestamp, plus the configuration requiring it | Somebody competent and independent examined the change before it shipped. AICPA TSC CC8.1; Annex A 8.32. | Self-approval, or an approval configuration that administrators can bypass without a record. |
| Automated verification | Required check results per change — tests, static analysis, dependency and secret scanning — and the configuration making them mandatory | The change was tested before implementation. AICPA TSC CC8.1; Annex A 8.29. | Checks that are advisory in configuration but described as required in the control narrative. |
| Environment progression | Evidence the change ran in a non-production environment before production, and that environments are separated by credentials and configuration | Changes are validated outside production, and environments do not bleed. Annex A 8.31; AICPA TSC CC8.1. | A single environment, or shared credentials that make separation nominal. |
| Deployment authorisation | The deployment approval naming an approver other than the change author, with the environment protection configuration requiring it, and the deployment record | Release to production is authorised. AICPA TSC CC8.1; supports segregation-of-duties expectations in a financial-statement audit under PCAOB AS 2201. | Automatic deployment on merge described as approved because the merge was approved — defensible if the narrative says so honestly, a finding if it claims a separate approval that does not exist. |
| Deployment record | What was deployed, to where, when, by whom or by which pipeline, and the artifact digest or commit deployed | You can reconstruct the production state at any date in the period. AICPA TSC CC8.1 and CC7.2. | Deployment history expired by the platform's default retention before the audit began. |
| Segregation of duties | The record showing that no single person could author, approve, and release a change unobserved — or, where they could, the compensating detective control and its evidence | Concentration of privilege is limited or compensated. Central to PCAOB AS 2201 information-technology general controls; AICPA TSC CC8.1. | A small team where one person does everything, with no compensating monitoring recorded. Size is a legitimate constraint; silence about it is not. |
| Emergency and expedited change | The emergency-change record: what was changed, who authorised it, why the normal path was bypassed, and the retrospective review or follow-up change | Exceptions are authorised and reviewed rather than invisible. AICPA TSC CC8.1; Annex A 8.32; ITIL change-enablement practice as best practice. | Bypass events with no record, or an emergency path used so routinely that it is the normal path. |
| Infrastructure and configuration change | Infrastructure-as-code changes going through the same review path, plus cloud audit-log records of any manual change and its justification | All changes to the production environment are controlled, not only application code. Annex A 8.9 and 8.32. | Console changes by hand with no ticket, no review, and no follow-up codification. |
| Production data change | The record of any direct data modification: request, approval, script executed, executor, timestamp, and result | Data is not altered outside a controlled path. Heavily scrutinised in a SOX scope under PCAOB AS 2201; AICPA TSC CC8.1 and PI1 where processing integrity is in scope. | Ad hoc queries run against production by engineers with standing write access and no record. |
| Rollback and failure handling | Evidence that failed changes were rolled back or remediated, and the record of the decision | Failure is handled deliberately. AICPA TSC CC8.1 and A1.2. | A change failure rate nobody measures, so failed changes are indistinguishable from successful ones in the record. |
| Change to the control itself | The record of changes to branch protection, rulesets, approval settings, and pipeline gates, with who changed them and when | The control cannot be quietly weakened. AICPA TSC CC8.1 and CC7.2; Annex A 8.15. | Protection relaxed for a release and never restored, discovered only when the auditor asks for the configuration history. |
Mapping pull-request-based change to control intent
This is the translation table to hand an auditor who expects a change advisory board. The left column is the traditional control activity; the right column is the artifact your workflow already produces. Nothing in the AICPA criteria or ISO/IEC 27001 Annex A 8.32 requires the traditional form. Last verified 10 September 2026. Not legal advice.
| Traditional control activity | Modern equivalent artifact | What still has to be true |
|---|---|---|
| Change request raised and logged | Pull or merge request with description and linked issue | It states the purpose and identifies the author. An empty description is not a change request. |
| Change advisory board review | Peer review by a qualified reviewer who is not the author, enforced by configuration | The reviewer is independent and competent, and the requirement cannot be silently bypassed. A board is one way to achieve this; it is not the only way. |
| Test evidence signed off | Required automated checks with results attached to the change | The checks are actually required, and they test something relevant. A green pipeline with no meaningful tests satisfies nothing. |
| Implementation approval | Deployment approval through environment protection, by an approver other than the author | Somebody other than the author authorised production release, or the narrative honestly states that merge approval is the authorisation point. |
| Post-implementation review | Deployment outcome record, monitoring alerts, and rollback or follow-up change where it failed | Failure is visible and handled. Continuous deployment makes this easier, not optional. |
| Change log for the period | The exported population of merges and deployments to production for the period | It is complete. This is the artifact that turns individual well-behaved changes into an evidenced control. |
| Emergency change procedure | Recorded bypass or expedited path with authoriser, reason, and retrospective | It exists in writing, is used rarely, and each use is recorded. An unused documented path is fine; an undocumented used path is not. |
SOX ITGC rigour versus startup best practice
The gap between what a growth-stage company needs and what a public-company information-technology general control environment needs is real, and it is mostly about independence, formality, and completeness of population rather than about tooling. Label which regime you are in, because designing for the wrong one wastes money in one direction or fails in the other. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| PCAOB AS 2201: an audit of internal control over financial reporting, under which information-technology general controls over change management, access, and operations are tested for design and operating effectiveness. | Legal requirement in substance for issuers — Sarbanes-Oxley Act obligations, implemented through auditing standards, where the systems are relevant to financial reporting. | Does not apply to a private company with no issuer obligations, and does not extend to every system you run. Scope is determined with your external auditor, not from a checklist. |
| PCI DSS v4.0.1 Requirements 6.2 and 6.5 on secure development and managing changes to system components. | Legal requirement in the contractual sense, for entities in scope through card-brand and acquirer agreements. | Does not apply outside cardholder-data scope, and does not name a tool or a board. |
| AICPA TSC CC8.1: changes are authorised, designed, developed, configured, documented, tested, approved, and implemented. | Attestation criteria, applying because you sought a SOC 2 report or a contract requires one. | Does not name a change advisory board, a ticketing system, or a separate ticket per commit. A pull-request workflow satisfies the intent when enforcement and population hold. |
| ISO/IEC 27001:2022 Annex A 8.32 change management, with 8.29 and 8.31. | Certification requirement where you seek or hold certification. | Does not prescribe a form. Your own documented procedure is the standard you are audited against. |
| ITIL change-enablement practice — change types, authorities, and models. | Industry best practice — a service-management framework, not a standard you are certified against as an organisation. | Not a requirement anywhere on this page. Borrow its vocabulary if it helps you talk to auditors; do not adopt its ceremony because you think a criterion demands it. |
| For a small team: enforce independent review and a production deployment approval, keep the full merge and deployment population, and record every emergency change. | ShipReady Metrics recommendation, and common industry best practice for growth-stage companies. | Not a substitute for a SOX-scoped control environment if your systems are in that scope. It is the honest minimum that satisfies most SOC 2 and ISO/IEC 27001 change expectations. |
| Where one person must be able to author, approve, and deploy — a genuine constraint in a very small team — record the constraint and a compensating detective control such as independent review of the deployment log. | ShipReady Metrics recommendation. | Does not make the segregation-of-duties concern disappear. It converts an unmitigated weakness into a disclosed, compensated one, which is what an auditor can work with. |
Checklist
A question list for the change side of your evidence set. Not a determination that any framework or regime applies to you. Last verified 10 September 2026. Not legal advice.
- Can we export every change that reached production in the period as one complete population?
- Is independent review enforced by configuration on every repository in scope, and can administrators bypass it without a record?
- Are the checks we describe as required actually required, and do they test something meaningful?
- Is there a production deployment authorisation by someone other than the author — and if not, does our control narrative say so honestly?
- Do deployment records survive long enough to cover the audit period?
- Can any single person author, approve, and deploy a change unobserved, and if so is there a recorded compensating control?
- Is there a written emergency-change path, and is every use of it recorded with an authoriser, a reason, and a retrospective?
- Do infrastructure and configuration changes go through the same path, and are manual console changes recorded and later codified?
- Are direct production data changes recorded with a request, an approval, the script, the executor, and the result?
- Do we know when branch protection, rulesets, or pipeline gates were changed, and by whom?
- Do we measure change failure and record how failed changes were handled?
What to do now
Ordered so the findings that most often appear close first. None of these steps is a legal determination, and none files anything with an auditor.
- Export the complete population of merges and production deployments for the current period today. Population completeness is what converts good habits into an evidenced control.
- Make independent review unbypassable in configuration, and check the bypass list on every repository in scope. Then try to bypass it once, to confirm.
- Add a production deployment approval by someone other than the author. If your team is too small, say so in the narrative and add independent review of the deployment log instead.
- Write the emergency-change path down, including who may authorise it and what the retrospective must cover, before you next need it.
- Bring infrastructure into the same path. Where a console change is unavoidable, require a recorded justification and a follow-up change that codifies it.
- Close standing production data write access, and route necessary data changes through a recorded, approved script execution.
- Track configuration changes to the controls themselves, so relaxations get restored rather than forgotten.
- Re-verify the cited criteria annually against the primary sources below, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not approve or gate your changes, does not configure branch protection or rulesets, does not deploy anything, and does not file anything with an auditor.
Delivery Health computes DORA posture — deployment frequency, lead time for changes, change failure rate, and time to restore — from connected sources including GitHub Actions runs. That is delivery posture, useful for spotting a change failure rate that moved or a pipeline that stopped deploying. It is not a change-management control opinion, not an attestation, and not an incident-response runbook.
The GitHub App is read-only, with Contents, Metadata, Pull requests, Actions, Administration, alert-feed, and organisation Members scopes. It reads pull requests and Actions runs; it does not merge, deploy, or change protection. GitLab ingest covers security findings with the same read-only posture.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. That is a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, and not an auditor's opinion. The obligation map lists frameworks your organisation marked in-scope, which is not a legal opinion that a framework applies.
Primary sources (last verified 10 September 2026)
Each source is labelled by the kind of authority it carries.
AICPA Trust Services Criteria CC7.2, CC8.1 and the processing-integrity criteria are professional attestation criteria. ISO/IEC 27001:2022 Annex A 8.9, 8.15, 8.29, 8.31 and 8.32 are certification requirements. PCAOB AS 2201 is the auditing standard under which information-technology general controls are tested in an audit of internal control over financial reporting, reaching issuers through Sarbanes-Oxley Act obligations. PCI DSS v4.0.1 Requirements 6.2 and 6.5 bind entities in scope through card-brand and acquirer contracts. ITIL change-enablement practice is industry best practice, not a standard you are certified against. Not a complete list, and not legal advice.
The CI/CD page in this cluster covers the pipeline artifacts in depth, the GitHub and GitLab pages give the platform paths, and the IAM page covers the access side of segregation of duties.
Frequently asked questions
Is this legal advice?
No. It is an operational mapping of change activity to evidence, with each source labelled by the kind of authority it carries. Whether SOC 2, ISO/IEC 27001, PCI DSS, or a Sarbanes-Oxley programme reaches your systems is a question for counsel, your finance leadership, and your external auditor. This page does not determine YOUR obligations and does not file anything with an auditor.
Do we need a change advisory board?
No source on this page requires one. AICPA TSC CC8.1 requires that changes be authorised, tested, approved, and documented; ISO/IEC 27001 Annex A 8.32 requires change management according to your own procedure. A pull-request workflow with enforced independent review, required checks, and a production deployment approval satisfies that intent — provided the enforcement is real and you can produce the complete population.
Is continuous deployment compatible with change control?
Yes, and often it evidences better than a manual process, because every change leaves a machine-readable record. The two things to get right are enforcement — review and checks that cannot be silently bypassed — and honesty in the narrative about where authorisation happens. If merge approval is the authorisation point because deployment is automatic, say that rather than implying a separate approval step exists.
Our team is too small for segregation of duties. What do we do?
Record the constraint and add a compensating detective control, such as independent review of the deployment and audit logs by someone who cannot deploy, on a stated cadence with the review recorded. Auditors work with disclosed, compensated limitations routinely. What fails is a control narrative that claims separation the team size makes impossible.
Does ShipReady Metrics evidence our change management?
Only as posture. Delivery Health computes DORA metrics — deployment frequency, lead time, change failure rate, and time to restore — from connected sources including GitHub Actions runs. That is not a change-management control opinion. Change approval and configuration artifacts are handled as manual evidence rows, where a named human accepting a row renders it met and rejecting it renders it a gap, with a timestamp.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.