What SOC 2 Evidence Do Auditors Require for Application Controls?

SOC 2 application evidence must support the control your auditor is testing. It can include configuration exports, screenshots, access reviews, change records, logs, and walkthroughs. The useful question is whether the evidence identifies the right system, scope, date or period, and actual operation of the control. Screenshots are one format; they are not universally required or sufficient.

The AICPA Trust Services Criteria provide the criteria for evaluating controls. Your control design and audit scope determine what the auditor tests. Agree the request list and acceptable formats with the audit team before collecting a large archive.

Match application evidence to the control

Cloud-provider evidence can show infrastructure settings without showing how your own product grants access or approves a change. Conversely, a screenshot of your admin panel cannot establish how every production change operated over a reporting period. Identify the assertion first, then collect records that support it.

These are illustrative mappings, not a mandatory checklist for every company.

Area	Relevant criterion	Example evidence
Logical access	CC6.1	Application roles, permission configuration, and a walkthrough showing enforced access boundaries
Access lifecycle	CC6.2 and CC6.3	Authorized access requests, user populations, completed reviews, and removal records, as applicable to the control
Monitoring	CC7.2	Configured monitoring, detected events, and records of investigation or follow-up
Change management	CC8.1	Authorized change, tests, approval, deployment record, and emergency-change exceptions

CC7.2 concerns monitoring for anomalies. CC8.1 concerns changes. Vulnerability-related controls may involve CC7.1 and other criteria depending on the design; do not label a vulnerability dashboard as change-management evidence merely because it came from an application.

Distinguish configuration from operation

A configuration screenshot can show that required reviews were enabled at capture time. It does not prove that every in-scope deployment followed that rule, or that the setting remained enabled throughout a Type II period.

For operating evidence, preserve the relevant population of events, such as production changes, access grants, or departures. Record how you produced it, including the source system, query or filters, timezone, and period. Reconcile it to another relevant source where possible. The auditor determines the testing approach and any sample; there is no universal number of screenshots or PRs to collect.

For recurring controls, follow the frequency in your approved control description. A quarterly access review needs records of the reviews that were due. Do not replace missing reviews with screenshots taken at the end of the year.

Worked example of an application access review

Suppose your control says an owner reviews privileged production access quarterly. The following is a fictional example of the evidence chain.

1. Export the privileged-access population from the production application, including direct grants, group-derived roles, and service identities in scope. Record the export time and filters.
2. Reconcile the export to the administrative role inventory. Investigate missing users or roles before calling the list complete.
3. Have the designated reviewer record a decision for each identity and the business reason for retained access.
4. Link removals or role changes to tickets and completion records. Identify outstanding exceptions, owners, and due dates.
5. Preserve the dated review approval and the supporting export together.

A screenshot of the user table may help explain the UI. The export, review decisions, and completed remediation show what the reviewer actually did. If your application cannot export inherited permissions, document that limit and agree an alternative completeness check with the auditor.

Worked example of a production change

For a selected routine release, link the change request to the pull request, successful tests for the released commit, the designated approval, and the deployment record. The commit identifier and timestamps should let a reviewer follow the sequence.

If approval preceded a later code change, show how the final commit met your review rules. If the release used an emergency exception, provide the authorization and follow-up required by your emergency-change procedure. A retrospective review does not erase a missed requirement.

The CC8.1 change-management answer includes an example record set and guidance on emergency changes.

Choose formats that preserve context

Use an export or API response when it provides complete, readable records. Use screenshots for UI-only settings, a walkthrough, or context that an export omits. You may need both. Ask the auditor what they need to establish the reliability and completeness of a system-generated report.

For each artifact, retain:

• The system and environment, including whether it is production or a test tenant.
• The capture date or covered period, timezone, and collector.
• The control or request it supports and an explanation of what it establishes.
• Source identifiers, filters, and relevant linked records.
• Known limitations, redactions, and any unresolved exception.

Keep originals and control access to sensitive evidence. A capture timestamp or signed manifest can help establish provenance, but it does not establish that the population is complete or the control is effective. Avoid editing an artifact to hide a control failure.

For screenshot-specific collection and rejection examples, see the evidence format guide. For scheduling recurring work, use the Type II evidence checklist.

Check a small evidence set before scaling collection

Bring one configuration artifact, one population export, and one completed operating example to your auditor. Ask whether the scope, source reliability, completeness checks, and level of detail fit the planned tests. Record the answer in your evidence tracker so the team uses the same approach.

Screenata helps collect and organize evidence for review. Your team remains responsible for the underlying controls, and the auditor evaluates the evidence. Use the SOC 2 readiness assessment to identify where that evidence chain is incomplete.