SOC 2 Evidence by Application Type: SaaS Panels, Internal Tools, and Production Environments

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—specifically across SaaS panels and internal tools—often remains manual. AI tools now automate SOC 2 evidence collection by capturing screenshots, validating them, and assembling audit-ready reports, but you first need to understand that not all evidence is created equal.

A screenshot of an AWS IAM policy serves a different purpose than a screenshot of your Django admin panel's user list. Treating them the same usually leads to rejected evidence and follow-up requests.

This guide breaks down the specific evidence requirements for the three main environments auditors scrutinize: your customer-facing SaaS application, your internal back-office tools, and your production infrastructure.

Why "One-Size-Fits-All" Evidence Fails SOC 2 Audits

Most compliance teams try to apply a single standard for evidence collection across their entire stack. They assume that if a JSON export works for AWS, it should work for their SaaS user list.

In practice, auditors distinguish between configuration evidence and behavioral evidence.

• Configuration Evidence (Infrastructure): Proves a setting is enabled (e.g., "Encryption is set to TRUE"). APIs handle this well.
• Behavioral Evidence (Applications): Proves how the system actually functions for a human user (e.g., "When I click 'Delete', does the system actually prevent me from deleting this record?").

If you rely solely on API dumps for application-level controls, auditors often push back. They want to see the UI state that confirms the configuration is active and enforced in the interface your team actually uses.

Category 1: SaaS Application Panels (Customer-Facing)

This category covers the application you sell to customers. Auditors focus heavily here because this is where your customer data lives and where access controls (CC6.1) are most visible.

What Auditors Look For

For your SaaS application, the auditor wants to verify Logical Access and Data Separation. They need to see that you can't accidentally see data from Tenant A while logged in as Tenant B, and that permissions are enforced correctly.

Required Evidence Types

Control Area	Specific Evidence Required	Why It Matters
User Access (CC6.1)	Screenshot of the "User Management" or "Team Settings" page showing roles (Admin, Editor, Viewer).	Proves RBAC is implemented in the UI, not just the database.
Onboarding (CC6.2)	Screenshot of the "Invite User" flow, specifically the modal where roles are assigned.	Proves that new users don't default to Admin privileges.
Authentication (CC6.1)	Screenshot of the login screen showing SSO options or MFA enforcement.	Verifies that the login security settings are visible to the end user.
Data Separation (CC6.7)	Screenshot showing a tenant-specific view (e.g., "Organization ID" in the URL bar matching the data on screen).	Visually confirms multi-tenancy controls.

Common Pitfall: Providing a raw database dump of the users table. Auditors often reject this because a database row doesn't prove that the application enforces the role. They want to see the UI that your support team or customers interact with.

Category 2: Internal Tools & Admin Panels (The "Hidden" Risk)

This is the category that causes the most panic during audit week. Internal tools—like Retool dashboards, Django/Rails admin panels, or custom "God Mode" back-office apps—rarely have polished APIs for compliance tools to hook into.

Why This Matters

Internal tools often have "superadmin" privileges that bypass standard application logic. If a support agent can delete a user via a Retool dashboard, that dashboard is in scope for SOC 2.

Required Evidence Types

1. Access Lists: A screenshot of the internal tool's user list. Auditors check if terminated employees still have access here, even if they were removed from Okta.
2. Change Logs: If you deploy changes to your internal tools, you need evidence of those deployments. Since these tools often bypass standard CI/CD pipelines, this evidence is frequently missing.
3. Permission Matrices: Screenshots showing what a "Support Agent" sees vs. what a "Super Admin" sees.

The Automation Gap: Because these are custom, proprietary interfaces, standard GRC integrations (Drata, Vanta) cannot connect to them. You cannot "connect" Drata to your custom React admin panel. This evidence is almost exclusively collected via manual screenshots or AI agents that can navigate the UI.

Category 3: Production Infrastructure (AWS/GCP/Azure)

This is the environment most compliance managers are familiar with. It is the easiest to automate because cloud providers offer standardized APIs.

What Auditors Look For

Auditors verify Security Configurations (CC6.8) and Change Management (CC8.1).

Required Evidence Types (That APIs Might Miss)

While your GRC platform will pull most of this, auditors often request specific screenshots to validate the API data or cover edge cases:

• Root User MFA: A screenshot of the AWS console showing the root user has MFA enabled. APIs can report this, but auditors frequently ask for visual confirmation for the root account specifically.
• Billing/Budget Alerts: Evidence that you are alerted on anomalies (often mapped to CC7.1 - Detection).
• Encryption Settings for Legacy Buckets: Sometimes API scanners miss specific legacy configurations; a screenshot of the S3 bucket settings tab resolves the query quickly.

Anatomy of an Audit-Ready Screenshot

Regardless of the system type, every piece of visual evidence must meet the Completeness and Accuracy (C&A) standard. If your screenshot lacks these elements, the auditor cannot rely on it.

1. System Date and Time: The screenshot must show the OS clock or the application's timestamp. If you crop the taskbar, the evidence is invalid because the auditor cannot verify when it was taken.
2. URL / Unique Identifier: For web apps, the URL bar must be visible. It proves where the evidence came from (e.g., admin.yourcompany.com vs. staging.yourcompany.com).
3. User Context: The top-right corner usually shows "Logged in as [User]". This proves the permissions being viewed belong to a specific identity.
4. No Cropping of Columns: If you take a screenshot of a user list, do not crop out the "Role" or "Status" columns. The auditor needs to see the full context.

Where Traditional SOC 2 Automation Stops

Most teams start their SOC 2 journey with a GRC platform, expecting it to automate everything. They quickly realize that while infrastructure is covered, application and internal tool evidence remains manual.

Feature	GRC Platforms (Drata/Vanta)	AI Compliance Officer (Screenata)
Infrastructure Evidence	Automated (via API)	Automated (via API/Screenshot)
Policy Management	Automated	Automated (AI-generated policies + reviews)
SaaS UI Evidence	Manual (Upload screenshot)	Automated (AI Agent captures UI)
Internal Tool Evidence	Manual (Upload screenshot)	Automated (AI Agent captures UI)
Compliance Guidance	Basic checklists	AI-driven readiness scoring + control mapping
Workflow Validation	Manual	Automated (Video/Screenshots)

Traditional automation relies on integrations. If an integration doesn't exist (like for your custom admin panel), the automation stops. This forces engineering teams to spend hours every quarter manually capturing screenshots of user lists, permission settings, and change logs.

Automating the "Un-automatable" with AI

To close the gap on SaaS panels and internal tools, modern compliance programs use AI agents. These agents act like a human auditor: they log into the application, navigate to the required settings pages, and capture screenshots with all necessary metadata (timestamps, URLs) intact.

This approach works for any web-based interface, regardless of whether it has an API. By defining the workflow once (e.g., "Go to Settings > Users > Take Screenshot"), you ensure that evidence for your custom applications is collected consistently for every audit period, without pulling engineers away from product work.

Learn More About SOC 2 Compliance Automation

For a complete guide to automating SOC 2 compliance, see our guide on automating SOC 2 evidence collection, including how to capture application-level evidence that traditional GRC tools miss. You may also find these relevant:

• Do You Actually Need a vCISO for SOC 2? - Why AI is replacing the $10k/month consultant
• The Bootstrapped Founder's Guide to SOC 2 - How to get SOC 2 done without a massive budget