Most first SOC 2 evidence is a screenshot. A screenshot of the MFA setting, a screenshot of the branch protection page, a screenshot of the offboarding checklist with every box ticked. Auditors accept them because the alternative is nothing. They also know what a screenshot proves.

It proves that a screen looked a certain way when someone captured it. It does not show what the setting was the day before, who changed it, who approved the change, or whether the same setting holds now.

What an auditor does with a screenshot#

An auditor testing a control needs to reach a conclusion about the control's operation over the observation period. The AICPA's Trust Services Criteria set the control objectives; the auditor decides what evidence is sufficient. The auditor also considers the reliability of the evidence itself, including whether it came from the system or from the person being audited.

A screenshot has three weaknesses under that lens.

It is a point in time. The control is tested across months. A capture from March says nothing about June.

It has no before. A passing state shows the end of the work. A failing control that someone fixed on the morning of the capture looks identical to a control that was never broken, and the auditor has no way to tell which.

It trusts the person who took it. The auditor sees an image supplied by the company. Cropping, timing, and the choice of which screen to show are all decisions made by the party being tested.

What a read-back records#

A read-back is a record the system produces about itself after a change, captured as data. A useful one holds five things:

The before state. What the setting was before anyone touched it, read from the system.
The change. What was done, by which identity, at what time.
The approver and reason. For a sensitive change, the named person who approved it and the reason they gave.
The after state. What the system reports once the change is made, read from the system a second time rather than assumed from the success response of the write call.
The test result. The control test, re-run after the change, with the result attached.

Take a concrete case: requiring MFA for all users in Google Workspace. The before state shows enforcement off for two organizational units. The change enables it, run by a named service identity, approved by the founder with the reason "required for CC6.1 before the audit window opens." The after state is a fresh read of the enforcement setting for every unit. The re-run test passes. An auditor can read that sequence as a story with a beginning, a decision, and an end.

The second read matters because a write call returning success does not establish the setting. Provider APIs apply some changes asynchronously, and other changes get overridden by a policy at a higher level of the hierarchy. Google's documentation on 2-step verification enforcement describes enforcement by organizational unit and group, which is exactly the kind of layering a one-time screenshot can hide.

What the auditor can verify without trusting a summary#

Given read-back records, an auditor can do the following without asking anyone to vouch for them:

Compare the before and after state and see what changed.
Match the change timestamp to the approval timestamp and confirm the approval came first.
Read the approver's name and reason, then ask that person about it.
Pull the current state from the system directly and compare it to the recorded after state.
Confirm that the record was not rewritten after the fact.

The last item is about the history of the record. If each entry carries a hash of the entry before it, an edit to an old entry breaks every hash after it. Pair that with an append-only history, where corrections are new entries and nothing is overwritten, and a record of March reads the same in September as it did in March. The auditor can recompute the hashes themselves.

Where screenshots still belong#

Some controls have no API to read back. A signed policy acknowledgment, a photograph of a physical lock, a written vendor review are all fine as documents. Use them for what they are, and date and attribute them. For configuration in systems that expose an API, such as Workspace, GitHub, AWS, GCP, and identity providers, a screenshot is the weakest evidence available for something that can be read directly.

How Deixic keeps the record#

When Deixic fixes a failing control, it records the state before the change, makes the fix within your written policy, waits for a named approver and a reason on sensitive changes, and reads the result back from the system. It attaches that evidence to the test, re-runs the test, and writes a receipt holding the before and after state, the approver and reason, and the read-backs. Receipts are signed and hash-linked, so a later edit shows. Your own agents, such as Claude Code or Codex, read the same records over MCP, which means an engineer can ask what changed last quarter and get the record the auditor will see.

Before your next audit, pick one control and ask what you would hand over today. If the answer is an image, ask what it would not show.