SOC 2 evidence should be a byproduct, not a project

Teams usually meet SOC 2 the same way: an auditor sends a request list, engineering stops for six weeks, screenshots get collected into a shared drive, and the report gets issued. Then next year the same six weeks happen again, because nothing about how the system runs actually changed.

The alternative is not more tooling. It is designing controls so that operating the system correctly is what generates the evidence.

The screenshot smell

If a control's evidence is a screenshot, the control is probably not automated. Screenshots prove a state existed at the moment someone pressed a key - which is exactly the assurance an auditor is least interested in and exactly the work your engineers resent most.

Compare two ways of satisfying "access is reviewed quarterly":

• Screenshot approach - someone opens IAM, exports a user list to a spreadsheet, emails it to managers, collects replies, and files the thread.
• Byproduct approach - group membership is defined in Terraform, changes go through pull requests with named approvers, and the quarterly review is a report generated from git history.

The second one is less work and stronger evidence, because it covers the whole period rather than a moment.

Controls that generate their own trail

A few patterns cover most of the common request list:

Change management. If production changes only through CI, and CI only runs on merged pull requests, then your change log is your git log. Branch protection with required reviews turns "changes are authorized" into a queryable fact. The control to actually enforce is that no human has standing deploy credentials.

Access provisioning and removal. Identity in code, group membership in code, and an offboarding pipeline that revokes at the identity provider. The evidence is the merge commit that removed the user, timestamped and attributed.

Infrastructure configuration. Encryption at rest, logging enabled, public access blocked - these should be enforced by policy-as-code that fails a plan, not by a checklist. AWS Config rules, OPA policies, or provider-level guardrails all produce a continuous compliance record as a side effect of preventing the misconfiguration.

Vulnerability management. A scanner that opens tickets with SLAs produces a closure record. A scanner that emails a PDF produces an inbox.

Scope is the highest-leverage decision

The cheapest way to satisfy a control is to have it not apply. Before automating anything, reduce what is in scope:

• Segment production from everything else so that development environments are out of scope entirely.
• Push data you do not need out of scope - if you never store it, no control governs it.
• Consolidate to fewer systems that do more, rather than many systems each needing their own evidence path.

We have seen scope reduction cut an evidence burden roughly in half before a single automation was written.

What good looks like at audit time

The tell is what happens when the auditor asks for a population. If the answer is "give me a day to pull that together," evidence is still being reconstructed. If the answer is a query someone runs on the call, the control is genuinely operating - and the annual audit stops being a project that consumes a quarter of your engineering capacity.