Change tickets and pull requests as SOC 2 evidence

Change management is the one control where the evidence already exists. The work is proving your population of changes is complete and that approval came before deployment.

Last reviewed 2026-09-01Written by Jacob Masse, TrazTech Inc.

A production change is evidenced by four things in a fixed order: a record of what was being changed, a review or approval by someone other than the author, a test result, and a deployment record. The order is the control. A pull request approved two hours after the commit shipped is not something you can explain away. The timestamps sit in the same system the auditor is reading.

How does an auditor sample production changes?

They ask for every change deployed to production during the window, as one list, exported from the system that deploys. Not the release notes, not a summary, the raw list. From that they select somewhere between fifteen and forty items depending on volume and firm methodology, and for each one they ask for the full trail.

The population is where this control fails. If you deploy from a CI pipeline, the pipeline's run history is the population and it is complete by construction. If anyone can also deploy from a laptop, or apply a console change directly, or run a migration by hand, then the pipeline history is not the population and you have a completeness problem you need to solve before fieldwork rather than during it.

What does a pull request have to show?

Almost nothing extra, if branch protection is doing its job. What auditors look for in a sampled pull request, in the order they check it:

1. A description that identifies what is changing. One word titles get a follow-up question about whether the reviewer knew what they approved.
2. An approval from a named account that is not the author.
3. An approval timestamp that precedes the merge timestamp.
4. A passing check run attached to the merged commit, not to an earlier one.
5. A merge into the branch that actually deploys to production.
6. A deployment record linking that commit to a production release with a date.

Then they test the guardrail rather than the instance. Send them the branch protection settings screenshot showing required reviews and required status checks, and the list of accounts able to bypass it. A short bypass list with named people is fine. An empty setting with a cultural norm that everyone gets a review is not, because the auditor cannot test culture.

Separation of duties

The author of a change is not the person who approves it. In a two or three engineer company this sometimes cannot hold, so document the compensating control instead of pretending.

Compensating control

A stated, evidenced alternative when the ideal control is impossible. For solo merges, a weekly review of merged commits by a second person, recorded with a date and a name.

Emergency change

A change deployed outside the normal path to restore service. Legitimate, expected, and only a problem when the after-the-fact approval never happens.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

How do you evidence infrastructure and console changes?

Infrastructure managed as code is straightforward: it becomes an application change with a plan output attached. The trouble is the change someone made in the cloud console at eleven at night, which produces no pull request and no ticket and shows up only in the cloud provider's own audit trail.

Two workable answers. Either turn off console write access for everyone except a break-glass account, so the pipeline genuinely is the population, or accept console changes and reconcile them: export the cloud audit trail for write events each month, match every one to a ticket, and file the reconciliation. The second is more work. An auditor who sees a monthly reconciliation with a couple of documented exceptions trusts the population more than one who is told console access does not exist and then finds an event saying otherwise.

Why does a change ticket get rejected as evidence?

Four failures, all visible in the timestamps rather than in the content.

• The ticket was closed after the fix went live. Worse, the ticket was created after. The tracker records both moments and the auditor reads them, so a change record assembled during audit prep is obvious on sight.
• The approval is the author. A single-contributor repository with self-approved merges and no documented compensating control fails on design, not on evidence.
• A screenshot of a merged pull request cropped to hide the timeline. Export the pull request or send the link with read access instead. Cropping the part that carries the timestamps reads as concealment even when it was laziness.
• The population is the release notes. Release notes are written for customers and omit the changes nobody wanted to announce. The population is a system export, every time.

The general rules on what an auditor accepts are on the evidence collection page, the evidence tracker lists change management alongside the rest of your controls with a named owner per row, and the checklist covers the branch protection and pipeline settings that make this evidence produce itself. If you are still deciding whether you are testing design or operation, Type 1 against Type 2 changes how much of this history you need.

Common questions