What Screenshots Are Acceptable for SOC 2 CC6 Controls

A screenshot becomes acceptable SOC 2 evidence when an auditor can answer four questions from the file itself: what system is this, who was logged in, when was it captured, and does the state on screen demonstrate the control. Miss any one and the capture comes back with a follow-up request, which is how audit timelines slip by weeks.

The CC6 series is where this matters most, because logical access controls live partly in infrastructure that APIs can read and partly inside your own product's UI, where they cannot. At Screenata that second half belongs to Vera, the agent who runs your compliance program. She captures the screens with the context attached, drafts the narrative that explains what each one proves, and files them as signed artifacts tied to the control test that requested them.

This guide covers what makes a CC6 screenshot acceptable, the specific evidence each sub-control needs, what auditors reject, and how the capture works when an agent does it.

Why CC6 Controls Need Visual Evidence

What the CC6 series covers

CC6, Logical and Physical Access Controls, asks how you restrict access to systems and data: who can reach what, how access is granted and removed, how boundaries are enforced, and how you know any of it is true.

Some of that is infrastructure. Your cloud IAM policies, your identity provider's group memberships, your repository permissions, and your endpoint posture are all readable through APIs, and Vera pulls them on a schedule without anyone taking a picture.

Where APIs stop

The rest lives in interfaces. Role-based access inside your own product has no compliance API, because you built the product and nobody wrote an integration for it. Internal admin panels have the same problem. So do the settings screens of smaller tools in your stack that never shipped an audit endpoint.

For those, an auditor accepts a visual record: a point-in-time receipt that a specific configuration was active or a specific denial actually occurred.

What a rejected capture costs

Rejection is rarely dramatic. The auditor sends a note asking for the same screen with the URL bar visible, or asking who was logged in when it was taken. Somebody has to reproduce the state, capture it again, and re-explain it, often weeks after the original test. Each round trip adds days, and a handful of them across a sample list adds a month to an audit that was supposed to close.

What Makes a SOC 2 Screenshot Acceptable

Verifiable context on the screen

Auditors look at the edges of the image as much as the middle. A capture should show:

The system clock or an embedded capture timestamp, proving the evidence dates inside the observation window.
The URL, proving which environment is displayed. Production and staging look identical in a cropped screenshot, and only one of them counts.
The logged-in identity, usually a profile menu or an account label, proving who performed the test and with what authority.
The full window, because a cropped image invites the question of what sat outside the crop.

A clear tie to the control objective

The capture has to demonstrate the control rather than relate to it. A screenshot of a user list does not prove access is restricted; it proves a user list exists. What proves the control is the list filtered to administrative roles showing a small, named set, paired with a denial screen showing a non-administrative role being turned away.

Chain of custody

Auditors increasingly prefer evidence produced by a tool over evidence produced by a person with a snipping tool, for a straightforward reason: a tool can attach proof that the file has not changed. A per-file SHA-256 hash, a signature, and an independent RFC 3161 timestamp answer the tampering question before it is asked.

Timing inside the observation window

For a Type II report, evidence must be generated during the period under audit. A capture from before the window opened is not evidence of anything the report covers, no matter how good it looks. Evidence clustered in the final weeks tells the auditor the control operated for those weeks.

Where Screenshots Sit in Vera's Evidence Mix

Screenshots carry more weight in CC6 than anywhere else in SOC 2, and they are still a minority of the total program:

How Vera collects it	Share	What it covers
API scans	~70%	Cloud IAM, identity provider groups, repository permissions, endpoint posture
Automated screenshots	~9%	Application roles, admin panels, consoles without compliance APIs
Guided collection	~9%	Controls that need a specific path walked in order
Inbox ingestion	~5%	Forwarded emails and Slack file drops, classified on arrival
Dashboard uploads	0%	Nothing here. Uploading files by hand is the work being replaced

The balance is attestation: the confirmations only a person can give, which Vera chases in Slack or Teams.

Acceptable Screenshots, Control by Control

CC6.1, restricting logical access

What the control asks: that access to protected information assets is restricted to authorized users.

What to capture: your application's roles and permissions view, filtered to administrative roles, showing how few accounts hold them. Pair it with a denial test: a user holding a restricted role attempting an administrative action and being refused.

What to include: the full role list with the permissions each role carries, the account holding each administrative role, the URL, and the denial response with its error message. The API-side evidence Vera already holds, meaning the identity provider group memberships, sits alongside it in the same pack.

CC6.2, authorizing access before it is granted

What the control asks: that new access is registered and authorized before credentials are issued.

What to capture: the request and its approval, then the resulting account. A ticket showing the requested role and the manager's approval, then the account as it exists in the application with the permissions actually assigned.

What to include: the approval timestamp and the account creation timestamp, in that order. An account created before the approval is an exception, and comparing two timestamps is the first thing an auditor does with this pair.

CC6.3, removing access when it is no longer needed

What the control asks: that access is modified or revoked when a role changes or someone leaves.

What to capture: the deactivation in your HR system or identity provider, and the corresponding inactive state in every downstream system where access was granted directly rather than federated.

What to include: the deactivation date visible in both systems. The gap auditors probe here is the account disabled centrally that kept a local login somewhere, and the only proof it is gone is a screen from that specific system.

CC6.6, protecting against external threats

What the control asks: that you restrict access from outside your system boundaries.

What to capture: MFA enforcement state for administrative accounts, session timeout configuration, and IP or network restrictions where they apply.

What to include: the setting shown as enabled and the scope it applies to. A screen showing MFA is available proves less than a screen showing MFA is required for every account in a named group.

CC6.7, restricting the movement of information

What the control asks: that data transmission and removal are restricted to authorized users and processes.

What to capture: encryption settings for data in transit, restrictions on export or download features in your application, and the configuration governing who can extract data in bulk.

What to include: the enabled state, the roles the restriction applies to, and the date the configuration was last changed.

CC6.8, preventing unauthorized software

What the control asks: that you detect and prevent unauthorized or malicious software.

What to capture: the endpoint protection console showing coverage across the device fleet, and the dependency scanning configuration in your build pipeline.

What to include: the count of covered devices against the total, and the enforcement setting rather than the alerting setting.

What Auditors Reject and Why

Cropped captures

An image cropped to the interesting part removes the URL, the clock, and the account indicator at once. It is the single most common cause of rework, and it usually happens because someone was trying to keep an unrelated customer name out of the frame. Redaction solves that without removing the context.

Captures with no verifiable date

A file modification date is not a capture date, and a date typed into a caption is an assertion rather than evidence. What holds up is a timestamp embedded at capture and bound to the file by a signature.

Screens from staging

Staging and production render identically. An auditor who cannot see the hostname assumes the worst, and the capture gets redone against production, usually at the worst possible time.

Screens with no actor

A permissions page proves what the configuration was. It does not prove who was looking at it or whether they had the authority to. For denial tests especially, the identity of the account being denied is the entire point.

Screens that show a setting without its effect

A toggle set to "restricted" shows an intention. The refusal that follows when someone tries the restricted action shows the control. Auditors testing operating effectiveness want the second one, and the strongest CC6 packs contain both.

How Vera Captures CC6 Evidence

Step 1: Define the path

For each CC6 test that needs visual proof, the path a reviewer would walk gets written down: the starting screen, each step, and the state that proves the control held. That definition is what makes this quarter's capture comparable to last quarter's.

Step 2: Capture with context attached

Capture happens through the Screenata browser extension while the test runs. Each capture carries the image plus a DOM snapshot recording that the elements existed on the page as shown, the URL and page title, an NTP-synced timestamp, the identity of whoever performed the test, and the browser and system context.

The DOM snapshot is the part that answers the tampering question directly. An image can be edited; an image with the underlying HTML captured alongside it is considerably harder to fake, and auditors who have seen a doctored screenshot know the difference matters.

Step 3: Vision scoring and narrative

A vision model reads the capture the way a reviewer would: role labels, permission indicators, error messages, status banners, and denial states. It scores whether the capture demonstrates the control rather than merely relating to it, and drafts the description that sits under the image in the pack. Low-confidence captures get flagged for your review instead of being written up confidently.

Step 4: Redaction

Customer names, email addresses in user lists, API keys visible in settings, and personal data belonging to records that are not the subject of the test get masked at capture time. Compliance markers stay visible: role labels, permission toggles, timestamps, status indicators, and the URL. The capture still proves the control without handing over your customer list.

Step 5: Signing, review, and filing

Vera hashes each file, signs the bundle, and attaches an RFC 3161 timestamp from an independent authority. The pack carries the claim chain from policy sentence to testable claim to control test to artifact, which an auditor can verify with the free Open Attest CLI without a Screenata account.

Nothing is filed until a person approves it. Vera assembles and stages; you review the captures, the drafted descriptions, and the control mapping, then approve.

Manual Captures Compared to Agent-Captured Evidence

	Manual capture	Vera's capture
Timestamp	File metadata or typed into a caption	NTP-synced, embedded, bound by signature
Environment proof	Present only if the URL bar was in frame	URL and page title recorded with every capture
Actor	Usually absent	Tester identity travels with the capture
Tamper evidence	None	DOM snapshot, SHA-256 hash, RFC 3161 timestamp
Redaction	Blurred by hand afterward	Applied at capture, compliance markers preserved
Consistency	Varies by person and by quarter	Same structure every cycle
Control mapping	Added during write-up, if remembered	Attached at capture, because the test triggered it
Time per control	15 to 30 minutes	A few minutes of review

The Attestation Layer CC6 Depends On

Several CC6 requirements have no screen at all. Whether the quarterly access review was genuinely performed rather than rubber-stamped. Whether a departing employee's hardware came back. Whether the manager who approved an access request understood what they were approving.

Vera DMs the person who knows, in Slack or Teams. No answer in 24 hours brings a reminder. At 48 hours she escalates. The response is captured as an attestation carrying the responder's identity and timestamp, and it joins the pack for the control it supports.

She coordinates the review and collects the evidence. She does not decide who should have access; that judgment stays with the reviewer, and the record shows who made it.

A Week in Vera's Compliance Cadence

CC6 evidence accumulates on a schedule rather than in an audit-week sprint.

Daily, 6:00 AM: evidence freshness check across the control matrix. Anything aging out gets queued for recapture.
Daily, 6:15 AM: readiness snapshot showing which controls have current evidence.
Daily, 6:30 AM: Slack briefing covering what she collected, what she needs from a person, and what is overdue.
Weekly, Monday: cloud and repository scans, which refresh most of the CC6 infrastructure evidence automatically.
Quarterly: access review cycle scheduled and orchestrated, with Vera chasing the reviewers.
Annually: risk assessment refresh.

Evidence collected this way covers the full observation window, which is exactly what a Type II report is testing.

Collect Once, Map Across Frameworks

An MFA enforcement capture supports SOC 2 CC6.1, the ISO 27001 Annex A access control requirements, and the HIPAA authentication safeguard at 164.312(d). A deprovisioning capture supports CC6.3 and its equivalents in both.

Vera collects against a shared canonical control catalog, so one capture attaches to every control it satisfies. The second framework costs a fraction of the first, because most of the evidence already exists and only the gaps need new collection.

What This Costs

Collecting CC6 application evidence by hand runs 40 to 80 hours per audit cycle for a typical program, and those hours come from the person who understands the access model, usually a founder or the engineer who built it.

The traditional path totals $59,000 to $160,000 in cash for year one to a SOC 2 Type II across a GRC platform, a fractional consultant, and the auditor. Screenata is $5,988 a year ($499/mo) per framework, which puts the first year at $13,000 to $21,000 including the audit fee.

Frequently Asked Questions

Do auditors accept AI-generated SOC 2 evidence?

In most cases, yes, when the evidence is verifiable. What earns acceptance is the metadata: the capture timestamp, the DOM snapshot, the tester identity, the file hash, and the independent timestamp token. Packs produced by Vera are badged as "Vera (AI)" so the auditor knows what generated them, and several auditors prefer automated captures because they remove the manual step where mistakes and edits happen.

Can I use a screen recording instead of screenshots?

Some auditors accept video, and most find it slow to review. A structured pack with specific captures lets an auditor confirm the control in seconds rather than scrubbing a five-minute recording for every sampled test. Where a sequence genuinely matters, a series of captures with timestamps carries the same information in a reviewable form.

How many screenshots does a CC6 control need?

For a static setting, one that shows the configuration and its scope. For a process such as provisioning, a sequence of three or four covering request, approval, action, and verification. The useful test is whether a reader who does not know your product could follow what happened.

Does Vera log into my application by herself?

She captures the test as it runs, through the browser extension, with a person driving or with a guided path she walks alongside you. She does not hold production credentials and log in unattended.

Does Screenata replace Drata or Vanta?

For teams starting fresh, Vera covers the work a GRC platform plus a consultant would otherwise split: policy generation grounded in your real systems, evidence collection across scans and captures and attestations, control mapping, and audit prep. Teams already mid-cycle with an existing platform can keep it and export finished packs to the matching control there.

What if evidence falls outside the observation window?

It does not count for that report. This is the strongest argument for continuous collection: evidence gathered on a cadence lands inside the window by construction, while evidence gathered during audit prep clusters at the end of it.

Key Takeaways

An acceptable CC6 screenshot answers four questions from the file itself: what system, who was logged in, when, and what state proves the control held. Cropping away the URL bar or the clock is the most common reason a capture comes back.

Show the effect, not only the setting. A permissions page paired with a denial screen proves the control operates; a permissions page alone proves it was configured.

Application-level access controls are the part APIs cannot read, which is why CC6 leans on captures more than any other criteria family. Even so, screenshots are about 9% of the evidence in a SOC 2 program.

Verifiability is what auditors are actually judging. A DOM snapshot, an NTP-synced timestamp, a tester identity, a file hash, and an independent timestamp token turn an image into evidence.

Evidence collected on a cadence covers the observation window. Evidence collected during audit prep covers audit prep, and auditors write that up.

Learn More About SOC 2 Compliance Automation

For a complete strategy on reducing audit preparation time, see our guide on automating SOC 2 evidence collection, including how application-level control verification fits alongside infrastructure monitoring.

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.