Manual SOC 2 Controls: How to Handle Evidence That Automation Misses

If you have deployed a GRC platform like Drata or Vanta, you have likely encountered the "90% automated" reality. These tools connect to AWS, GitHub, and Okta via API, instantly marking infrastructure and policy controls as passing. But when you get to the application layer—your custom admin panels, internal tools, and specific workflow configurations—the automation stops.

SOC 2 audits still require evidence for these systems. Auditors need screenshots and documentation proving that your custom application logic works as described. Because traditional automation relies on pre-built API integrations, it cannot see inside your proprietary software. This leaves compliance managers scrambling to manually capture screenshots for User Access Reviews (CC6.1), Change Management (CC8.1), and other application-level controls right before the audit window closes.

This article breaks down exactly which controls usually fall into this manual gap, how to document them correctly so auditors don't reject them, and how new agentic approaches are solving this problem.

What SOC 2 Controls Cannot Be Automated by APIs?

The "manual gap" in SOC 2 usually sits at the application layer. While APIs can easily query AWS to see if a database is encrypted, they cannot query your custom back-office portal to see if a "Delete User" button is restricted to admins.

In general, controls fall into three categories of automation potential:

Layer	Examples	Automation Status
Infrastructure	AWS, Azure, GCP, Cloudflare	Fully Automated. GRC tools query APIs to verify encryption, backups, and security groups.
SaaS / IT	Okta, Google Workspace, Slack, GitHub	Mostly Automated. APIs verify MFA settings and user lists. Some specific configurations may need screenshots.
Application	Custom Admin Panels, Internal Tools, Billing Portals	Manual. No standard API exists. Evidence requires logging in, navigating the UI, and taking a screenshot.

Most teams underestimate the volume of evidence required for that third category. It isn't just one or two screenshots; it's often a screenshot for every new hire's role assignment, every sampled change request, and every quarterly access review for systems that don't support SCIM provisioning.

Which Specific Controls Require Manual Screenshots?

Based on data from hundreds of SOC 2 audits, these are the specific Trust Services Criteria (TSC) where automation typically fails and manual evidence collection becomes necessary.

CC6.1: Logical Access (The User Access Review)

If your application supports role-based access control (RBAC) but doesn't integrate with an Identity Provider (IdP) for provisioning, you likely have to manually prove that access was reviewed.

• The Manual Task: Exporting a user list from your database or admin panel, formatting it into a spreadsheet, and taking screenshots of the "Users" page to prove the export is accurate (Completeness and Accuracy).
• The Evidence: A screenshot of the user list inside the application, showing roles and permissions, timestamped to match the review period.

CC8.1: Change Management (The "Hotfix" Problem)

While GitHub integrations cover standard pull requests, they often miss emergency changes, hotfixes, or configuration changes made directly in a UI (like toggling a feature flag in LaunchDarkly or an internal settings page).

• The Manual Task: Taking screenshots of the ticket, the approval comment, and the deployment verification if the link between them isn't strictly enforced in code.
• The Evidence: A screenshot of the specific ticket showing "Approved" status and a timestamp prior to the deployment timestamp.

CC5.1: Risk Assessment

There is no API for a risk assessment meeting.

• The Manual Task: documenting the meeting minutes, the attendees, and the resulting risk register.
• The Evidence: A signed PDF of the risk assessment methodology and results, often accompanied by a screenshot of the calendar invite to prove the meeting occurred.

Custom Business Logic Controls

If you have a control that says "Customers cannot export data without 2FA," an auditor needs to see that setting.

• The Manual Task: Logging in as a user, attempting the action, and capturing the error message or the settings configuration screen.

How Do You Standardize Manual Evidence Collection?

If you are stuck collecting this evidence manually, you need to ensure it passes the "re-performance" standard. An auditor must be able to look at your evidence and reach the same conclusion you did without asking clarifying questions.

Poorly formatted screenshots are the number one cause of audit delays (and "Information Provided by Entity" or IPE findings).

Use this checklist for every manual screenshot:

1. Include the System Clock: Never crop out the bottom right corner of your screen. The date and time must be visible to prove the evidence existed during the audit period.
2. Show the URL Bar: Auditors need to verify the screenshot comes from the production environment (admin.yourcompany.com), not localhost or staging.
3. Capture the Whole Context: Don't just screenshot a toggle that says "On." Screenshot the whole page so the auditor sees "Multi-Factor Authentication Settings > Enforce for All Users > On."
4. Naming Convention: Do not upload files named Screen Shot 2026-02-20 at 10.00.00.png. Use a standard format like: [Control_ID]_[Description]_[Date].png.
   • Example: CC6.1_Admin_Panel_User_List_2026-02-20.png

Where Traditional SOC 2 Automation Stops

It is important to understand why tools like Drata, Vanta, and Secureframe cannot automate these controls. It isn't a flaw in their software; it's a limitation of API-based architecture.

Feature	GRC Platforms (API-Based)	Manual / Agentic Evidence (UI-Based)
Data Source	JSON data from APIs (AWS, Okta, GitHub).	Visual interface (what a human sees on screen).
Coverage	Standardized SaaS and Cloud Infrastructure.	Custom applications, legacy tools, on-prem software.
Audit Method	Inspection: "The API says encryption is true."	Observation: "I can see the 'Encrypted' badge on the screen."
Limitation	Cannot interact with custom UIs or workflows.	Requires navigating clicks, logins, and visual verification.

Traditional automation stops at the API. If your evidence requires a human to look at a screen, click a button, or interpret a visual layout, API tools cannot capture it. This is why you end up with a "hybrid" audit: 90% of controls are green in your dashboard, and the remaining 10% live in a chaotic Google Drive folder of manual screenshots.

How Can AI Agents Automate These Manual Controls?

The solution to the manual gap is not "more APIs"—it's AI agents.

New compliance tools use "computer-use" agents (similar to how a human uses a browser) to automate the collection of visual evidence. Instead of an engineer spending four hours taking screenshots of user lists, an AI agent:

1. Logs in to the application using a dedicated audit service account.
2. Navigates to the specific URL (e.g., /admin/users).
3. Captures a full-page screenshot, ensuring the URL and system time are visible.
4. Validates the image to ensure the necessary data (like a specific column header) is present.
5. Uploads the evidence directly to your GRC platform or audit folder with the correct naming convention.

This approach treats evidence collection like an integration test. You define the steps once ("Go to admin panel > Click Users > Filter by Admin > Screenshot"), and the agent runs it weekly, monthly, or on-demand.

For compliance managers, this eliminates the monthly "screenshot tax" on engineering teams. For auditors, it provides higher-quality evidence because the screenshots are generated consistently, with cryptographic timestamps, and without the risk of human error or convenient cropping.

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 integrate these manual workflows into your broader audit strategy.

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.