What SOC 2 Auditors Actually Look For in Application Evidence

SOC 2 audits still require screenshots, application evidence, and clear documentation that auditors can review. While many tools automate infrastructure checks via API, evidence collection for application workflows—like user access reviews, change management tickets, and admin panel settings—often remains manual. To automate SOC 2 evidence collection successfully, you first need to understand exactly what an auditor is looking for when they inspect a screenshot.

If you have ever spent a week scrambling to retake 50 screenshots because an auditor couldn't see the system clock, you know that the content of the evidence is only half the battle. The context is what validates it.

What Is IPE and Why Do Auditors Obsess Over It?

Auditors operate under strict standards regarding "Information Produced by the Entity" (IPE). In plain English, IPE is any information your company generates that is used to support a control.

When you hand an auditor a screenshot of a user list or a change ticket, you are providing IPE. The auditor cannot simply trust that the image is real. They are required to validate two things:

1. Completeness: Does this evidence represent the entire population? (e.g., Did you show all 50 users, or just the first page of 10?)
2. Accuracy: Is the information correct, unaltered, and attributable to a specific point in time?

If your evidence fails the IPE test, the auditor cannot use it. This is why "mark-backs"—requests to resubmit evidence—happen. It’s rarely because your security is bad; it’s usually because your evidence didn't prove your security was good.

What Specifically Must Be Visible in a SOC 2 Screenshot?

A valid evidence artifact is not just a picture of a setting. It is a visual record of a system state at a specific moment. To pass an IPE check, every screenshot should ideally contain the following "visual anchors."

1. The Full Browser Context (URL Bar)

Cropping a screenshot to "make it look clean" is a rookie mistake. Auditors need to see the URL bar to verify the source system.

• Good: https://admin.yourcompany.com/users is visible.
• Bad: A cropped image of a table with no surrounding browser frame.

2. A Time Anchor

For SOC 2 Type II audits, the timing of the evidence is critical. The auditor must verify that the control was operating during the audit period.

• Good: The operating system clock (Windows/Mac taskbar) is visible in the corner, or the application has a visible "Generated at: YYYY-MM-DD HH:MM:SS" timestamp.
• Bad: A clean screenshot of a settings page with no date reference.

3. Identity Context

Who took the screenshot? Or, whose view are we looking at?

• Good: The user avatar or profile name is visible in the top right corner (e.g., "Logged in as: Admin").
• Bad: A generic view where it’s unclear if the viewer has admin privileges or read-only access.

4. Pagination and Filtering Indicators

This is the most common reason for rejection regarding "Completeness."

• Good: The footer shows "Showing 1-50 of 50 records" or "Page 1 of 1".
• Bad: A list of users that cuts off at the bottom without indicating if there are more rows.

How Do You Prove "Completeness and Accuracy" (C&A)?

Completeness and Accuracy (C&A) is the specific validation procedure auditors perform on IPE. Here is how it plays out for common evidence types.

The "Export to CSV" Trap

Practitioners often export a user list to CSV/Excel and send that to the auditor. Auditors generally reject raw CSVs. Why? Because a CSV is easily editable. You could have deleted a row before sending it.

To get a CSV accepted, you must provide a "source screenshot" alongside it.

1. Take a screenshot of the admin panel showing the query parameters and the "Total Records: 245" count.
2. Export the CSV.
3. Ensure the CSV has exactly 245 rows.
4. Submit both. The screenshot proves the Completeness (the count), and the CSV provides the detailed Accuracy.

The "Settings" Toggle

When proving a configuration (like "MFA is Enforced"), a simple screenshot of the toggle isn't enough. You need to show who that setting applies to.

• Rejection Risk: Showing a global setting that might be overridden by a group-level exception.
• Fix: Capture the "Exceptions" tab or the specific group policy settings to prove the rule is universal.

What Evidence Do Auditors Require for Specific Controls?

Different SOC 2 criteria require different visual proof. Here is what auditors look for in the most evidence-heavy controls.

CC6.1: Logical Access (User Access Reviews)

For User Access Reviews (UAR), you need to prove that you reviewed access, not just that access exists.

• Required Evidence: A ticket or document showing the list of users, the reviewer's name, the date of review, and a specific "Keep" or "Remove" decision for each user.
• Common Fail: Sending a Slack screenshot saying "I checked the users, looks good." This lacks the detail of who was checked.

CC8.1: Change Management

This is often the most tedious control. For a sampled change (e.g., Pull Request #402), the auditor needs a chain of evidence:

1. The Ticket: Jira/Linear issue describing the change.
2. The Code Review: GitHub/GitLab PR showing approval by someone other than the author (Segregation of Duties).
3. The CI/CD Log: Proof that the tests passed.
4. The Deployment: Evidence that this specific commit hash was deployed to production.

If you provide a screenshot of the PR but not the deployment timestamp, you haven't proven the change went live safely.

Where Traditional SOC 2 Automation Stops

Most GRC platforms (like Drata, Vanta, or Secureframe) rely on API integrations to collect evidence. This works perfectly for structured data from AWS, Google Cloud, or Okta. They can query the API and say "MFA is on."

However, APIs have limitations when it comes to application-level evidence:

Evidence Type	API Automation (Drata/Vanta)	Application Evidence Gap
Cloud Infrastructure	Excellent. Pulls configs directly from AWS/Azure.	None.
SaaS Admin Panels	Limited. Only works if the SaaS has a public API that the GRC tool integrates with.	High. Custom settings in niche SaaS tools must be screenshotted manually.
Internal Tools	None. GRC tools cannot connect to your proprietary back-office admin panel.	High. You must manually screenshot your own internal user management screens.
Visual Workflows	None. APIs capture state ("Ticket is Closed"), not process.	Medium. Auditors often want to see the comments or attachments in a ticket, which APIs miss.

This gap is where teams lose time. You might have 80% of your controls automated by Drata, but the remaining 20%—the application-level screenshots—require 90% of your manual effort.

How Can You Automate Evidence Collection for Application Controls?

To close the gap between API limitations and auditor expectations, teams are moving toward browser-based automation. This involves using tools that can navigate web interfaces, interact with elements, and capture screenshots just like a human would.

Tools like Screenata automate this by running "agents" that:

1. Log into the application (SaaS or internal).
2. Navigate to the required settings or list page.
3. Capture a full-viewport screenshot (including URL and system time).
4. Extract the metadata (text on page) to verify C&A.
5. Package it into a PDF that auditors accept.

By automating the visual capture, you ensure that every piece of evidence has the correct timestamp, URL context, and scope—eliminating the risk of rejection due to formatting errors.

Learn More About SOC 2 Compliance Automation

For a complete guide to automating SOC 2 evidence collection, see our guide on automating SOC 2 evidence collection, including how to handle the manual gaps that APIs leave behind.

Not sure if you even need a compliance consultant? Read Do You Actually Need a vCISO for SOC 2? Probably Not Anymore or The Bootstrapped Founder's Guide to SOC 2.

For more on this topic, see SOC 2 Screenshot Evidence: What Auditors Accept, What Gets Rejected, and How Many You Need.

For more on this topic, see SOC 2 Type 2 Quarterly Evidence Checklist: What to Collect and When.