What Screenshots Are Acceptable for SOC 2 CC6 Controls

SOC 2 audits require specific evidence in the form of screenshots to prove that CC6 logical access controls are functioning as intended. While many GRC tools automate infrastructure checks, application-level evidence for logical access often remains a manual burden. To be acceptable to an auditor, SOC 2 screenshots must capture the full context of a control test, including system timestamps, the tester’s identity, and the specific configuration or state being verified. This article details exactly what makes a screenshot auditor-ready and how to automate SOC 2 evidence collection for the CC6 series.

Why Do SOC 2 CC6 Controls Require Screenshots?

The CC6 series (Logical and Physical Access Controls) focuses on how an organization restricts access to its systems and data. While infrastructure-level controls (like AWS IAM policies) can often be verified via API, application-level controls—such as role-based access within your proprietary SaaS or manual user provisioning workflows—cannot be "seen" by standard API connectors.

For these controls, auditors rely on visual evidence. A screenshot serves as a point-in-time "receipt" that a specific security configuration was active or a specific process was followed. However, simply hitting "Print Screen" is rarely enough. If a screenshot lacks context, auditors will reject it, leading to "evidence rework" that can add weeks to your audit timeline.

What Makes a SOC 2 Screenshot Acceptable to Auditors?

An acceptable SOC 2 screenshot must be sufficient, reliable, and relevant. In the context of CC6 controls, this means the image must prove that the control was operating effectively during the audit window.

1. Verifiable Metadata and Context

Auditors look for "the four corners" of the screen. An acceptable screenshot should ideally include:

System Clock: The date and time must be visible (usually the taskbar clock) to prove the evidence was captured during the relevant period.
URL Bar: For web applications, the URL proves which environment (Production vs. Staging) is being displayed.
User Identity: The screenshot should show who is logged in (e.g., a profile icon or "Logged in as...") to verify the tester’s authority.
Full Window: Cropped images are often viewed with suspicion as they may hide conflicting information.

2. Clear Mapping to the Control Objective

The screenshot must directly address the requirement of the specific CC6 control. For example, if you are proving CC6.1 (Access Revision), a screenshot of a user list is insufficient unless it specifically highlights the "Last Audit Date" or the specific permissions assigned to a user.

3. Integrity and Chain of Custody

Auditors increasingly prefer evidence generated by automated tools rather than manual captures. Automated tools like Screenata provide a "chain of custody" by attaching cryptographic hashes and original metadata to the image, proving it hasn't been tampered with or "Photoshopped."

Breakdown: Acceptable Screenshots for CC6 Sub-Controls

The CC6 series contains several sub-points. Below is a breakdown of the specific screenshots required for the most common application-level access controls.

CC6.1 – Logical Access Security Software

Objective: To verify that access to protected information assets is restricted.

Acceptable Screenshot: A view of your application’s "Roles and Permissions" dashboard showing that only a limited number of "Super Admins" exist.
What to include: The full list of users, their assigned roles, and the specific permissions associated with those roles.

CC6.2 – User Provisioning and Deprovisioning

Objective: To prove that new users are authorized and departed users are removed.

Acceptable Screenshot: A side-by-side view (or a sequence) showing a Jira ticket requesting access and the corresponding user account active in the application.
What to include: Timestamp of the request and the timestamp of the account creation.

CC6.3 – Access Removal for Terminated Employees

Objective: To ensure access is revoked immediately upon termination.

Acceptable Screenshot: A screenshot of the "Disabled" or "Deactivated" status for a specific user in your HRIS (like Rippling) and the corresponding "User Not Found" or "Inactive" status in your production database or application UI.
What to include: The deactivation date clearly visible in both systems.

CC6.7 – Boundary Protection (Firewalls/WAF)

Objective: To prove that the network perimeter is secured.

Acceptable Screenshot: A view of the Web Application Firewall (WAF) configuration showing active "Deny" rules for known malicious IP ranges.
What to include: The "Enabled" status and the date the rules were last updated.

Where Traditional SOC 2 Automation Stops for CC6 Controls

Most GRC platforms like Drata and Vanta are excellent at monitoring the "API-accessible" portions of SOC 2. However, they hit a wall when it comes to the user interface (UI) of your own application.

Control Type	GRC Platform (API-Based)	Screenata (UI-Based Automation)
Cloud Infrastructure (AWS/GCP)	✅ Fully Automated	✅ Supported
SaaS Tools (GitHub/Okta)	✅ Fully Automated	✅ Supported
Internal Admin Panels	❌ Manual Screenshots Required	✅ Automated AI Capture
Proprietary App Workflows	❌ Manual Documentation	✅ Automated AI Capture
Custom Access Reviews	❌ Manual Spreadsheets	✅ Automated PDF Evidence Packs

Traditional tools cannot "log in" to your product and verify that a specific toggle switch for MFA is turned on for all users. This creates the "20% manual gap" where teams spend 40–80 hours per quarter manually taking screenshots and pasting them into Word documents.

How to Automate SOC 2 CC6 Evidence Collection

To eliminate the manual work of screenshot collection, companies are turning to AI-driven evidence automation. Here is how the automated workflow works for a CC6 control test:

Step 1: Define the Workflow

Identify the manual path an auditor would take to verify a control. For example: Log in to Admin Panel -> Navigate to User Settings -> Filter by 'Admin' -> Capture Result.

Step 2: Record with an Evidence Agent

Using a tool like Screenata, you perform the workflow once. The AI agent records the session, but unlike a standard screen recorder, it extracts the underlying metadata (DOM elements, URLs, timestamps).

Step 3: Automated Evidence Generation

The system automatically captures the necessary screenshots at each critical step. It then applies automated PII redaction to blur sensitive data (like customer emails) that should not be in an audit report, while keeping the compliance markers visible.

Step 4: Export Auditor-Ready Packs

The final output is a structured Evidence Pack—a PDF that includes the control ID (e.g., CC6.1), the test objective, the timestamped screenshots, and a digital signature. This pack is then pushed directly into your GRC platform (Drata, Vanta, etc.).

Comparison: Manual Screenshots vs. Automated Evidence Packs

Feature	Manual Screenshot (Snipping Tool)	Automated Evidence (Screenata)
Metadata	Often missing or cropped	NTP-synced, hard-coded in PDF
Redaction	Manual blurring in Paint/Preview	AI-powered automatic PII blurring
Consistency	Varies by employee	Standardized auditor-approved format
Audit Defense	Hard to prove "point-in-time"	Cryptographic proof of capture time
Time Spent	15-30 mins per control	< 2 mins per control

Frequently Asked Questions

Do auditors accept AI-generated SOC 2 evidence?

Yes. Auditors accept automated evidence as long as it is accurate, verifiable, and complete. In fact, many auditors prefer automated evidence because it reduces the risk of human error and manipulation associated with manual screenshots.

Can I just use a screen recording (Loom) instead of screenshots?

While some auditors accept video, many find it difficult to review. A structured PDF evidence pack with specific screenshots is preferred because it allows the auditor to quickly verify the control without watching a 5-minute video for every test.

How many screenshots are enough for a SOC 2 CC6 control?

It depends on the complexity of the control. For a simple setting, one screenshot is enough. For a process (like user provisioning), you typically need a "Before/After" sequence or a "Request/Approval/Action" sequence (3-4 screenshots).

Does Screenata replace Drata or Vanta?

No. Screenata complements them. Drata and Vanta are the "Operating Systems" for your compliance. Screenata is the "Visual Sensor" that captures the 20% of evidence (application screenshots) that they cannot reach via API.

Key Takeaways for CC6 Screenshot Compliance

✅ Metadata is mandatory: Never crop out the system clock or URL bar.
✅ Application controls are the bottleneck: Focus automation efforts on the UI-based controls that APIs can't see.
✅ Standardization wins audits: Use a consistent format for all evidence to reduce auditor questions.
✅ Automate the "Last Mile": Use AI agents to capture, redact, and package screenshots, reducing manual prep time by 92%.
✅ Integrate your stack: Ensure your screenshot evidence flows directly into your GRC platform to maintain a single source of truth.

Learn More About SOC 2 Evidence Automation

For a complete strategy on reducing audit preparation time, see our guide on automating SOC 2 evidence collection, including how to bridge the gap between infrastructure monitoring and application-level control verification.