What Counts as Enough SOC 2 Evidence? Screenshots, Exports, and Review Records

You have a CSV of users, a screenshot of MFA settings, and a ticket marked complete. Is that enough for the access control your auditor is testing?

It depends on the control, the system and period in scope, and what the records establish. A screenshot can show a configuration. An export can list users. Neither, by itself, proves that an owner reviewed access and removed permissions that were no longer needed.

The useful starting point is the auditor's evidence request and your actual control description. Agree what you need to demonstrate before your team spends a quarter collecting the wrong artifacts.

Start with the control and the period

For each request, record the control, the system boundary, the date or observation period, and the action you need to demonstrate. Then identify where the original records live and who can explain them.

For a Type I examination, the evidence must support the controls as of the specified date. For Type II, it must support their operation during the specified period. A current settings screenshot cannot establish how a review operated several months earlier. The AICPA discusses the role of professional judgment in evidence timing.

Worked example: a user access review

Assume your approved control requires the production system owner to review access quarterly. This is an example of a company control, not a universal SOC 2 frequency rule.

Record	What it helps establish	What it does not establish alone
User export with roles and system identifiers	The access population presented for review	Whether an owner reviewed it or whether the export includes every relevant account
Export method, filters, and extraction time	How the population was obtained and what it covers	Whether the access was appropriate
Dated review record identifying the reviewer and decisions	Who reviewed which accounts, and what they decided	Whether requested removals actually happened
Removal tickets plus system audit events or follow-up records	Execution of the decisions and when access changed	Whether other accounts were omitted from the review

A practical submission links these records together. For example, the review ticket references the original export, records keep/remove decisions, and links removal tasks to system events. Explain exclusions such as service accounts separately. Preserve the version that was reviewed rather than overwriting it with today's user list.

Worked example: change approval

Suppose the auditor selects a deployment for testing. Keep the deployment identifier, the linked pull request or change ticket, the review and test records, and the approval and deployment times.

A screenshot showing that branch protection is enabled today explains the current configuration. The historical pull request and deployment records help establish what happened for the selected change. For an emergency change, include the emergency process and the approvals or follow-up review it calls for. State any deviation rather than editing the record to make it look complete.

Worked example: vulnerability remediation

Keep the original finding with its asset and severity, the assigned remediation ticket, and the change or configuration record used to address it. Attach the retest or rescan result and its date. If management accepted a remaining risk, retain the authorized decision, rationale, restrictions, and next review date.

The scan report alone identifies a problem. Marking a ticket closed alone does not establish that it was fixed. The linked records let the auditor follow the finding through to the outcome.

What should a screenshot show?

A useful screenshot includes the relevant setting or result and enough context to identify the source system and environment. Record the capture date, collector, and purpose alongside it. Include the URL or system identifier when useful, but redact secrets, session tokens, and unrelated personal data.

A visible desktop clock can provide context, but it is not independent proof of when a historical control operated. A full URL, visible avatar, or uncropped desktop is not a universal acceptance rule. Ask your auditor which supporting metadata or source records they need for your situation.

Keep originals and label any redacted copies. A capture of a success banner can support an action, but it may need the resulting configuration or system event to explain what changed.

Are CSVs and logs acceptable?

Exports, logs, tickets, policies, and screenshots can all contribute evidence. Vanta's audit overview lists several of these formats. An export's usefulness depends on its source, completeness, accuracy, and relevance to the request.

Keep the system name, extraction method, date range, filters, and original file. If a query excludes inactive accounts or contractors, say so. Ask whether the auditor needs a walkthrough, system totals, or other corroboration to evaluate completeness. Adding a screenshot does not automatically validate an incomplete export.

How many samples do you need?

Do not budget around a universal table that says quarterly controls need two screenshots or daily controls need 25. The auditor determines the testing approach based on the engagement, control, risk, population, and evidence available. They may test a sample or the whole population.

Your job is to preserve a complete population and the underlying records, including unsuccessful or late instances. If there were no events, such as no employee departures, document how you established that. Do not invent an instance or select only successful examples.

For a quarterly access review, keep every scheduled review and its outcome even if the auditor later tests fewer instances. The quarterly evidence checklist helps organize that work.

Clarify expectations before collecting at scale

Send one representative example and ask:

We propose to support [control] for [system and period] with [population source], [review record], and [remediation records]. Which information do you need to evaluate completeness and accuracy? What is missing from this example, and how should we preserve records for your testing?

Keep the reply with your evidence plan. Clarification helps your team collect useful records; it does not bind the auditor to accept later submissions or transfer management's responsibility to the auditor.

Automate collection and keep review decisions visible

Use integrations for accessible source records and browser capture for settings or workflows that need visual context. Check failures, expired access, pagination, changed interfaces, and the periods each collection covers. A successful automation run can still return an incomplete population.

Screenata helps collect and organize artifacts against compliance tests. Control owners still perform the underlying reviews and decisions. Signing or timestamping an artifact supports integrity after capture; it does not prove that the control was effective or that the source was complete.

Start with the bootstrapped founder's guide for preparation choices, or what SOC 2 help a small team needs if the team needs help deciding what to do next.