Your SOC2 evidence binder should be a side effect, not a project

AI delivery governance is the control layer between the agents that write your software and the systems that run it, and one of its least glamorous consequences is the one compliance teams feel most. If every change is proposed as a pull request, checked against versioned policy before anyone sees it, and merged by a named person, the change-management evidence is written while the work happens. The audit binder stops being a project.

The project nobody budgets for

Ask a platform team what an audit cycle costs and the answer is rarely the auditor's invoice. It is the weeks before fieldwork, when people who would otherwise be shipping go looking for proof of things they already did.

The evidence almost always exists. The change was reviewed — in a pull request, or a chat thread, or a call. It was approved — by someone, in a ticket, probably. It was tested — the pipeline ran, though the run has since aged out of the CI provider's retention. What does not exist is that evidence in one place, in a shape an auditor can sample. So the project is reassembly: matching tickets to commits, commits to approvals, approvals to the people who were allowed to give them, and screenshotting each join before the next system forgets it.

That work is real, it is skilled, and it produces nothing new. It reconstructs a history the process never bothered to write down.

Collection versus generation

There are two ways to fix that, and they are not competitors.

Evidence collection connects to the systems you already run and pulls proof out of them on a schedule: access reviews from your identity provider, configuration from your cloud account, pipeline history from your CI. It is genuinely valuable, and if you run SOC2 seriously you probably already own a platform that does it.

But collection has a ceiling it cannot raise by itself. It can only collect what the process produced. If a change went to production without a review, no collector will find the review. If the approval happened in a hallway, the best a collector can do is record that the ticket was closed.

Evidence generation works on the other side of that ceiling. It changes the process so that a change cannot happen without leaving the record behind. The proof is not gathered afterward; it is a by-product of the only path a change is allowed to take.

The argument of this post is narrow: most compliance spending has gone to the first category, and the bottleneck is increasingly the second. That is especially true now that a growing share of changes are drafted by AI agents, because an agent's work leaves exactly as much evidence as the process around it insists on — and no more.

Keep your evidence platform. In TruStacks it is one of the tool categories you declare in your environment profile, and when the SOC2 specialist suggests where an auditor's artifact comes from, it points at the tools you told it you run. What generation does is give that platform better material to collect.

What an auditor asks about a change

SOC2's change-management criterion, CC8.1, is about authorized changes: that changes to systems are authorized, tested, and approved before they are implemented. In practice an auditor samples changes from the period and traces each one back. Strip the vocabulary away and they are asking four questions about every sampled change:

1. What changed, and why?
2. What was it checked against before it shipped?
3. Who approved it, and were they someone other than the author?
4. Could the check have been bent to let this one through?

The fourth question is the one teams struggle with most, because the honest answer is usually in principle, yes. Someone with the right access could have disabled a required check for an afternoon, and nothing would record that they did.

What each change leaves behind

Here is where the answer to each question lives when changes ship the way our crew ships them. Note the right-hand column: most of the record lives in systems you already own.

The pull request is the anchor, so here is its shape. The section headings are the ones the product writes; the contents are an illustration rather than a real customer's change, and the rule ids are real rules from our constitution.

## Summary

Add a CI workflow and a Dockerfile for checkout-service.

## Blast radius

New files only. No existing workflow or deployment is modified.

## Rollback

Revert this pull request. Nothing outside these files depends on them.

## Rule citations

- `practice.workflow_pins_action_versions`
- `practice.workflow_has_test_step`
- `practice.dockerfile_runs_as_nonroot`

## EnvironmentProfile entries used

- `ci_cd_platform.github_actions`

None of that was written for the auditor. It was written for the reviewer, who needs to know what they are approving and how to undo it. The point is that the reviewer and the auditor need the same record, so producing it once, for the reviewer, at the moment of the change, covers both.

The binder becomes a query

Once the record is generated rather than reconstructed, assembling the binder is a matter of asking for it.

In the product you pick a time window, optionally narrow it to an audit boundary — the services that are actually in scope, so evidence from outside the boundary cannot leak into the report — and ask for the SOC2 family. The report maps recorded events onto six controls where delivery evidence is strongest: CC5.1, CC6.1, CC6.8, CC7.1, CC8.1, and CC9.1. It exports as structured JSON or as a PDF with a SHA-256 checksum. Record the checksum when you generate the report, and anyone can later confirm the file they hold has not changed since. The PDF is not signed yet, so the checksum is only as trustworthy as the place you kept it.

One detail in that report is worth calling out, because it is the kind of thing a vendor is tempted to blur. The merge itself is not a TruStacks event. It happens in your git provider, under your people's accounts, and the CC8.1 section of the report says so and tells the auditor to verify it in your git history. We could have tried to mirror that record into our own system. We think it is stronger where it is: in a system you control, that we cannot edit.

The same logic applies to how long you keep things. The durable record of who approved what lives in your git provider for as long as you keep it there. Our event log is not built to be that durable record: the Beta retention policy for the events behind the report is 30 days. The purge is not switched on yet, but plan as though it were. So export a window at least monthly, keep each export with the rest of your evidence, and treat the exports, not our log, as what you hand over.

Readiness, before the auditor arrives

Two more pieces help before fieldwork rather than during it.

The SOC2 specialist agent reads your declared stack and returns findings mapped to specific Common Criteria control ids, one finding per control, each with up to three evidence hints: the artifact an auditor will ask for, and where in your stack it comes from. It is built to leave a hint out when it has no confident pointer, rather than pad the finding with generic advice. Its findings are a starting point for your compliance lead, not a verdict.

The maturity score on every gap analysis is computed by code, not by a model, and it is deliberately hard to flatter. Each row is verified (you declared it and we observed it), claimed (you declared it and we cannot check — half credit), disputed (you declared it and what we observed contradicts it — no credit), or missing. Gold starts at 90%, which means attestation alone cannot reach it. That score measures delivery practice against the policy in force, not SOC2 readiness as a whole, and we label it that way.

What this does not do

Generation narrows the evidence problem. It does not abolish it, and a post about audit evidence that overclaimed would be its own kind of finding.

• It does not form an audit opinion. The report presents evidence. Your auditor decides what it demonstrates.
• It covers the changes that go through it. A change pushed by hand outside the governed path leaves exactly the evidence it always did.
• It covers change management, not SOC2. Governance, HR, vendor risk, and most of the Common Criteria live elsewhere, and so does the platform you use to collect them.
• It does not make us your auditor's subject. TruStacks does not hold its own SOC2 report yet. The SOC2 specialist helps with yours, which is a different thing, and we will not blur the two.

What it does do is move the expensive part of the audit — proving that each change was checked and approved — from a project at the end of the period to a by-product of every day in it.

Agents propose. Policy decides. Humans approve. And the binder writes itself in the gap between the second and the third.

Every product claim above is in our facts registry with the date it was last checked against the product. CC8.1 is paraphrased from the AICPA's Trust Services Criteria; read the criteria themselves, and your auditor's reading of them, before relying on any vendor's summary — including this one. If you want to see an evidence report generated from your own changes, talk to us.