SOC 2 Evidence Preparation Checklist: How to Automate Screenshots Before an Audit

SOC 2 audits require comprehensive evidence documentation, including system configurations, logs, and application-level screenshots. While many organizations use GRC platforms to automate infrastructure evidence, auditors still demand manual screenshots for application workflows, access reviews, and change management processes. Automating SOC 2 evidence collection ensures that your documentation is consistent, timestamped, and ready for auditor review without the last-minute scramble.

What Evidence Do SOC 2 Auditors Actually Require?

Auditors do not just take your word that a control is working; they require tangible proof. For a SOC 2 Type II audit, this evidence generally falls into three categories:

Populations: Complete lists of all occurrences of a specific event (e.g., a list of all employees hired during the audit period, or all code changes deployed to production).
Samples: A random selection from those populations that the auditor will test in detail (e.g., selecting 5 new hires to verify onboarding tickets).
Artifacts (The "Evidence"): The specific documents, logs, or screenshots that prove the control operated correctly for the selected samples.

The Automation Reality: Most modern teams use tools like Drata or Vanta to collect evidence for populations (via API integrations with HRIS or GitHub). However, the artifacts—specifically for application-level controls like internal admin panel access or custom change approval workflows—often require manual screenshots.

Where Traditional SOC 2 Automation Stops

It is a common misconception that connecting a GRC platform to your tech stack automates 100% of your evidence collection. In reality, these tools rely on APIs, which leaves a significant "manual gap" regarding visual evidence.

Feature	GRC Platforms (Drata/Vanta)	Evidence Automation Tools (Screenata)
Infrastructure Configs	✅ Automated (via API)	✅ Automated
Policy Acknowledgement	✅ Automated	✅ Automated
Application UI Settings	❌ Manual Screenshots Required	✅ Automated Screenshot Capture
Visual Workflow Proof	❌ Not Supported	✅ Automated Recording
Internal Admin Panels	❌ No Integration	✅ Computer-Vision Capture

For example, proving CC6.1 (Logical Access) often requires a screenshot showing that a "Viewer" role cannot see the "Delete Database" button in your internal dashboard. An API integration cannot capture this UI state; an AI automation tool can.

The Ultimate SOC 2 Evidence Preparation Checklist

Use this checklist to prepare your evidence artifacts before the audit begins. We have categorized these by the Common Criteria (CC) domains where manual screenshots are most frequently requested.

1. Logical Access Evidence (CC6)

Auditors focus heavily on who has access to your systems and how that access is managed.

[ ] CC6.1 - Role-Based Access Control (RBAC) Settings
- Evidence: Screenshots of the permission settings page in your application and internal tools.
- Automation: Record a workflow of an admin navigating to the "Roles & Permissions" settings to capture the configuration.
[ ] CC6.1 - Access Denial Verification
- Evidence: Screenshot showing a non-admin user attempting to access a restricted page (e.g., /admin) and receiving a "403 Forbidden" or "Access Denied" error.
- Automation: Use an AI agent to log in as a standard user and attempt restricted actions, capturing the denial screen automatically.
[ ] CC6.2 - User Access Reviews (UAR)
- Evidence: Screenshots or exports of the user list from key systems (if not integrated via API), signed off by the system owner.
- Automation: Schedule an automated capture of the user list page on the last day of every quarter.
[ ] CC6.2 - New Hire Provisioning
- Evidence: For selected samples: Screenshots of the IT ticket (Jira/Asana) showing approval before access was granted.
- Automation: Link evidence capture to ticket closure events.
[ ] CC6.3 - Least Privilege Verification
- Evidence: Screenshots of admin accounts showing MFA is enforced and API keys are rotated.

2. Change Management Evidence (CC8)

For software companies, this is often the most scrutinized section.

[ ] CC8.1 - Change Approval
- Evidence: For selected samples: Screenshots of the Pull Request (PR) showing peer review approval, passing CI/CD checks, and no self-merging.
- Automation: While GitHub APIs handle some of this, auditors often request a PDF export of the PR conversation and checks for high-risk changes.
[ ] CC8.1 - Emergency Changes (Hotfixes)
- Evidence: Screenshots of the post-implementation review ticket or Slack approval thread for emergency fixes.
- Automation: Capture the Slack thread or ticket immediately upon resolution.
[ ] CC8.1 - Separation of Environments
- Evidence: Screenshots showing that developers do not have write access to the Production database.
- Automation: Record a developer attempting to write to the Prod DB and getting rejected.

3. System Operations & Availability (CC7)

Evidence that you monitor and maintain the system health.

[ ] CC7.1 - Vulnerability Scanning
- Evidence: Screenshots of the vulnerability scan dashboard (e.g., AWS Inspector, Tenable) showing scan dates and remediation status.
- Automation: Schedule weekly captures of the "Vulnerabilities" dashboard view.
[ ] CC7.2 - Incident Response
- Evidence: For selected samples: Screenshots of the incident ticket, post-mortem document, and evidence of root cause analysis.
- Automation: Automatically compile incident artifacts into a PDF pack when an incident is marked "Resolved."
[ ] CC7.4 - Backups and Restoration
- Evidence: Screenshots of backup configuration settings (frequency, retention) and a screenshot of a successful restoration test log.
- Automation: Record the annual restoration test process step-by-step.

4. Vendor Risk Management (CC9)

[ ] CC9.2 - Vendor Assessments
- Evidence: Completed security questionnaires or SOC 2 reports from critical vendors, reviewed and signed by your security lead.
- Automation: Centralize vendor reports and capture the review sign-off screen.

How to Automate Screenshot Collection for the "Manual 20%"

Collecting the screenshots listed above manually takes 40–80 hours per audit cycle. Using an automated evidence collection tool like Screenata reduces this to minutes.

Step 1: Map Controls to Workflows

Identify the controls from the checklist above that require UI evidence (e.g., CC6.1 RBAC).

Step 2: Record the Test Once

Use the Screenata browser extension to perform the test action (e.g., log in as a viewer, try to access admin settings). The tool records the steps, captures the screenshots, and logs the metadata (URL, timestamp, user).

Step 3: Schedule Continuous Capture

Set the workflow to run automatically (e.g., weekly or quarterly). The AI agent will replay the interaction, capturing fresh evidence without human intervention.

Step 4: Generate Evidence Packs

Export the artifacts as audit-ready PDF packs that include the screenshots, the control description, and the chain of custody metadata.

Example: Automating CC6.1 (Logical Access) Evidence

Control Requirement: The entity restricts access to confidential data to authorized users.

Manual Process:

Log in as Admin.
Take screenshot of user roles.
Log out.
Log in as "Viewer."
Navigate to "Settings."
Take screenshot of "Access Denied."
Paste into Word doc, add date, add explanation.

Automated Process (Screenata):

Trigger: Scheduled "Quarterly Access Test."
AI Action: Agent performs login sequence and navigation.
Capture: Agent detects "Access Denied" state and captures DOM + Screenshot.
Output: Generates CC6.1_Access_Test_Q1.pdf and uploads to Drata/Vanta.

Frequently Asked Questions

How many samples do I need for SOC 2 evidence?

Sample sizes vary by auditor and population frequency. A common rule of thumb for populations > 250 items (like daily backups) is a sample of 25-40. For weekly items (like change advisory meetings), a sample of 5-10 is common. Always confirm with your auditor.

Can I use screenshots from last year?

No. For a SOC 2 Type II audit, evidence must be generated within the audit period (the 6-12 month window you are being audited on). Evidence from outside this window is invalid.

Do auditors accept AI-generated screenshots?

Yes, provided the evidence is verifiable. Tools like Screenata include metadata (timestamps, source URLs, DOM snapshots) that prove the authenticity of the capture, making them more reliable than manually pasted screenshots in a Word document.

What if I miss a piece of evidence?

If you fail to provide evidence for a sample, the auditor may mark it as a "Exception." If exceptions are frequent, you may receive a "Qualified Opinion" (a failing grade). Automation helps prevent this by ensuring evidence is collected continuously, not just at the end.

Key Takeaways

✅ Audit Readiness: Successful audits depend on the quality of your artifacts, not just your policy documents.
✅ The Manual Gap: GRC tools handle API integrations, but application-level controls (CC6, CC8) still require screenshot evidence.
✅ Checklist Discipline: Organize your evidence by Common Criteria domain (CC6, CC7, CC8) to ensure nothing is missed.
✅ Automate Everything: Replace manual screenshotting with AI workflow recording to ensure consistency and reduce prep time by 90%.
✅ Verify Dates: Ensure all evidence timestamps fall strictly within your audit observation window.

Learn More About SOC 2 Evidence Automation

For a complete guide to automating the collection process, see our guide on automating SOC 2 evidence collection, including how to close the gap between GRC tools and auditor requirements.