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

Audits rarely go wrong on policy documents. They go wrong on artifacts: the specific screenshot, log excerpt, or approval record proving that a control operated for the sample the auditor picked. Policies get written once. Artifacts have to exist for every month of the observation window, for every control, for every sample.

This checklist covers what auditors request, organized by the Common Criteria domain where the request lands. Alongside each item is how the evidence gets collected when Vera, the compliance agent behind Screenata, is doing the work: which items come from scans, which need a capture from a screen an API cannot read, and which need a person to confirm something only a person knows.

Work the checklist before the audit opens, and the difference between a calm cycle and a scramble is mostly a scheduling question.

What SOC 2 Auditors Actually Ask For

Populations

A complete list of every occurrence of an event during the period: every employee hired, every employee terminated, every change deployed to production, every access request approved, every incident opened.

Populations must be complete, and auditors test that. A list of 40 deployments when your repository shows 300 merges is a finding before anyone looks at a single sample.

Samples

A selection drawn from the population that the auditor will test in detail. Sample sizes depend on population frequency and the auditor's methodology. Populations in the hundreds commonly draw 25 to 40 items; weekly events draw 5 to 10. Your auditor decides, and asking early saves a round trip.

Artifacts

The documents, logs, screenshots, and approvals proving the control operated correctly for each sampled item. This is where the hours go, because every sample needs its own proof, produced from a specific point in time you may have to reconstruct months later.

Where teams get caught

Two failures repeat across audits. The first is a population with a hole in it, usually because one system was never connected and its events never got counted. The second is an artifact that exists but cannot be dated, because someone captured it during audit prep for an event that happened in month three.

Both are avoidable, and both are avoided the same way: collect continuously rather than retroactively.

Where a Dashboard Stops and Vera Picks Up

Connecting a GRC platform to your stack automates the population half of the problem well. It does less for the artifact half, because integrations read records and a large share of SOC 2 artifacts live in interfaces that expose no compliance API.

Evidence type	What an API-based platform gives you	What Vera does
Infrastructure configuration	Automated through provider APIs	Automated, plus the drift is flagged in the daily briefing
Policy acknowledgments	Automated	Automated, with reminders and escalation for the stragglers
Application UI settings	Flagged as needing manual evidence	Captured through the browser extension with metadata attached
Internal admin panels	No integration exists	Captured against a defined path, on a schedule
Visual workflow proof	Out of scope	Captured step by step as the workflow runs
Attestations	A task assigned to a person	Chased in Slack or Teams, reminded at 24h, escalated at 48h
Evidence packaging	You assemble and upload	Assembled, signed, and staged for your review

Proving CC6.1 usually needs a screen showing that a Viewer role cannot see the destructive action in your internal dashboard. No integration can read that, because you built the dashboard. Across a full program, that category of evidence runs about 9% of the total, and it consumes a wildly disproportionate share of the calendar when it is done by hand.

Here is how the whole mix breaks down when Vera runs it:

How Vera collects it	Share
API scans across 30+ native providers and 489 checks	~70%
Automated screenshots of application and console UI	~9%
Guided collection along a defined path	~9%
Inbox ingestion of forwarded emails and Slack file drops	~5%
Dashboard uploads by hand	0%

The balance is attestation.

The SOC 2 Evidence Preparation Checklist

Work through this by domain. Each item lists the artifact an auditor typically requests and how it gets collected.

1. Logical Access Evidence (CC6)

The most heavily sampled domain in almost every SOC 2 audit.

[ ] CC6.1, role and permission configuration
- Artifact: the roles and permissions view in your application and internal tools, showing which accounts hold administrative rights.
- Collection: identity provider groups come from the scan. The application's own role model needs a capture along a defined path.
[ ] CC6.1, access denial verification
- Artifact: a restricted user attempting a privileged action and receiving a denial, with the response visible.
- Collection: captured as a test run with a dedicated low-privilege account, paired with the audit log entry recording the denial.
[ ] CC6.2, access authorization before provisioning
- Artifact: for each sampled new hire, the request and manager approval timestamped before the account was created.
- Collection: ticket and account records from integrations, with a capture of the resulting permissions to show the role granted matches the role approved.
[ ] CC6.2, user access reviews
- Artifact: the reviewed user list from each key system, with the system owner's sign-off.
- Collection: Vera schedules and orchestrates the review, captures the lists, and chases each reviewer for sign-off. The access decisions stay with the reviewer.
[ ] CC6.3, deprovisioning
- Artifact: termination record plus confirmed revocation across every system, including any with a direct local login.
- Collection: identity provider events from the scan, plus captures of the downstream systems that federate nothing.
[ ] CC6.6, MFA and session controls
- Artifact: MFA enforcement shown as required rather than available, and session timeout configuration, scoped to named groups.
- Collection: scanned where an API exposes it, captured where it lives only in a settings screen.
[ ] CC6.7, restrictions on data movement
- Artifact: encryption in transit settings, and restrictions on bulk export or download features.
- Collection: cloud settings from the scan; application export restrictions from a capture.
[ ] CC6.8, unauthorized software prevention
- Artifact: endpoint protection coverage against the full device fleet, and dependency scanning enforcement in the build pipeline.
- Collection: scanned from the endpoint and repository integrations.

2. Change Management Evidence (CC8)

For software companies this is the most scrutinized section after access.

[ ] CC8.1, change approval
- Artifact: for each sampled change, the pull request showing peer review approval, passing checks, and a merger who is not the author.
- Collection: the full population and per-change records come from the repository integration.
[ ] CC8.1, enforced approval gates
- Artifact: the branch protection configuration showing that review is required and self-approval and force pushes are blocked.
- Collection: captured from the settings screen. This is the item auditors request second, after you send the approved pull request, and having it ready removes a round trip.
[ ] CC8.1, emergency changes
- Artifact: the post-implementation review or approval thread for each hotfix that bypassed the normal path.
- Collection: ingested when someone forwards the thread or drops it in Slack, classified against the change it belongs to.
[ ] CC8.1, environment separation
- Artifact: proof that developers do not hold write access to production data stores.
- Collection: cloud IAM from the scan, with a capture of the denial if your architecture makes the API view ambiguous.

3. System Operations Evidence (CC7)

[ ] CC7.1, vulnerability scanning
- Artifact: scan results showing dates, findings, severities, and remediation status.
- Collection: pulled from the scanner integration weekly, with the dashboard state captured when the auditor wants the view rather than the export.
[ ] CC7.2, monitoring and alerting
- Artifact: the alerting configuration and evidence that alerts reached a human.
- Collection: monitoring configuration from the scan, notification records from the integration.
[ ] CC7.4, incident response
- Artifact: for each sampled incident, the ticket, the investigation record, the resolution, and the post-mortem.
- Collection: ticket lifecycle from the integration; the investigation dashboard state from a capture; the post-mortem ingested from Slack or email.
[ ] CC7.5, recovery
- Artifact: evidence that service was restored and the cause addressed.
- Collection: resolution records plus the remediation ticket Vera opened and re-verified after a person applied the fix.

4. Availability Evidence (A1)

[ ] A1.2, backup configuration
- Artifact: backup frequency, retention, and encryption settings for each production data store.
- Collection: scanned from the cloud provider.
[ ] A1.2, restoration testing
- Artifact: the log or screen from an actual restoration test, with its date.
- Collection: captured during the test itself, which happens once or twice a year and is easy to forget until an auditor asks.

5. Vendor Risk Evidence (CC9)

[ ] CC9.2, vendor assessments
- Artifact: completed questionnaires or SOC 2 reports from critical vendors, with your reviewer's sign-off.
- Collection: vendors are discovered from your code and cloud usage and risk-tiered. Reports get ingested when forwarded to the workspace address. The review sign-off is an attestation Vera chases. She does not email your vendors on your behalf.

6. Governance and People Evidence (CC1, CC2, CC5)

[ ] CC1.4, security training completion
- Artifact: completion records for the period, covering the full employee population.
- Collection: tracked in the employee portal, with Vera reminding the people who have not finished.
[ ] CC1.4, background checks
- Artifact: confirmation for each sampled hire.
- Collection: an attestation from whoever owns hiring, captured with their identity and timestamp.
[ ] CC2.2, policy acknowledgments
- Artifact: signed acknowledgments covering every employee, dated within the period.
- Collection: automated, with reminders and escalation for the ones who have not signed.
[ ] CC5.2, risk assessment
- Artifact: the current risk register with owners, treatments, and a review date inside the period.
- Collection: refreshed annually on Vera's schedule, with the owners chased for their updates.

How to Work the Checklist Without a Fire Drill

Step 1: Split it by who can answer

Every item falls into one of three buckets: an API can answer it, a screen can answer it, or only a person can answer it. Sorting the list this way takes an hour and it reframes the work, because roughly 70% of the list turns out to be the first bucket and requires no human at all.

Step 2: Connect the integrations first

Connect your cloud providers, identity provider, repositories, endpoint tooling, and ticketing before anything else. That closes most of the population problem in an afternoon and reveals which systems have no integration, which is exactly the list you need for the next step.

Step 3: Define capture paths for what is left

For each remaining item, write down the path a reviewer would walk and the state that proves the control held. This is usually five to twelve tests, not fifty. Vera captures against that definition, which keeps this quarter comparable to the last.

Step 4: Hand the attestations to Vera

Everything in the third bucket becomes a delegation. Vera DMs the person who knows, reminds at 24 hours, escalates at 48, and captures the answer with its responder identity and timestamp. This is the category that quietly eats a compliance owner's week, because chasing colleagues is unpleasant and easy to postpone.

Step 5: Schedule instead of sprinting

Attach each item to the cadence its control requires and let evidence accumulate. Type II tests whether controls operated throughout the window, and evidence dated in the final three weeks answers a question nobody asked.

Worked Example: CC6.1 Logical Access

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

The manual version: log in as an admin, screenshot the roles page, log out, log in as a Viewer, navigate to a restricted area, screenshot the denial, paste both into a document, type in the dates, write an explanation, export a PDF, and upload it to the control. Around 40 minutes, repeated quarterly, and it depends on someone remembering the Viewer account password.

How Vera runs it: the quarterly access test comes up on her schedule and appears in the morning briefing. The test runs against the defined path with a dedicated low-privilege account, capturing the roles view, the denial, and the corresponding audit log entry. Each capture carries a DOM snapshot, an NTP-synced timestamp, the tester identity, and the URL. The vision model drafts the description for each and scores whether it demonstrates the control. She pairs the captures with the identity provider evidence already collected by scan, assembles a signed pack, and stages it for your review. You approve, and it files.

Worked Example: CC8.1 Change Management

What the control requires: changes are authorized, tested, and approved before deployment.

The repository integration holds the full population of merged changes with authors, reviewers, approval timestamps, and check results. When the auditor samples five, the records already exist.

The capture covers what the records leave open: the branch protection settings proving review was required rather than customary. One screen, refreshed when the configuration changes, that closes the follow-up thread before it starts.

What a Finished Evidence Pack Contains

The artifact your auditor opens holds a cover page with the control ID, date, environment, and result; a summary of the objective and outcome; the test procedure and pass criteria; the captures with their descriptions and timestamps; and an appendix carrying the per-file SHA-256 hashes, the signature, an RFC 3161 timestamp from an independent authority, and the claim chain from policy sentence to testable claim to control test to artifact.

An auditor can verify it with the free Open Attest CLI without holding a Screenata account, because the format is published as an open spec.

What Vera Redacts Before Anything Is Filed

Customer names and email addresses in user lists, API keys and tokens visible in settings screens, payment identifiers, and personal data belonging to records that are not the subject of the test all get masked at capture time.

Compliance markers stay visible: role labels, permission toggles, timestamps, status indicators, and the URL. Evidence packs travel to auditors and sometimes to prospects through a trust center, so this matters more than it seems while you are collecting.

A Week in Vera's Compliance Cadence

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 across connected providers.
Quarterly: access review cycle scheduled and orchestrated, with reviewers chased for sign-off.
Annually: risk assessment refresh.

A checklist worked this way is never fully outstanding, because most of it closed itself while you were doing other work.

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 change management pack supports CC8.1 and its equivalents in both.

Vera collects against a shared canonical control catalog, so one artifact 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 Happens After You Certify

The next observation window opens the day the current one closes. Vera keeps running the same cadence, and packs regenerate as evidence ages out. When the next audit begins, the evidence for the period exists already, so the prep is a review pass rather than a rebuild.

What This Costs

Collecting application-level artifacts by hand runs 40 to 80 hours per audit cycle for a typical program, and the hours come from whoever understands the systems best.

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

Check Your Readiness Before You Start

Before working through this checklist, find out where your gaps actually are. Our free SOC 2 Readiness Assessment gives you a readiness score across access controls, change management, and monitoring, so you can prioritize the evidence that matters most for your audit.

Frequently Asked Questions

How many samples do I need?

Your auditor decides, based on population size and frequency. Populations in the hundreds commonly draw 25 to 40 items; weekly events draw 5 to 10. Ask during the kickoff call rather than guessing, because the answer changes how much artifact work the period requires.

Can I use screenshots from last year?

No. For a Type II report, evidence must be generated inside the observation window. Anything from outside it is not evidence of the period under audit, which is the strongest practical argument for collecting continuously.

Do auditors accept AI-generated screenshots?

In most cases, yes, when the evidence is verifiable. The capture timestamp, DOM snapshot, tester identity, file hash, and independent timestamp token are what earn acceptance. Packs are badged as produced by "Vera (AI)" so the auditor knows what generated the artifact.

Does Vera log into my systems and capture evidence unattended?

She captures along a defined path through the browser extension, with a person driving or with a guided flow she walks alongside you, and she prompts the right person in Slack when a scheduled capture is due. She does not hold production credentials and log in on her own.

What happens if I miss a piece of evidence?

The auditor records an exception for that sample. Enough exceptions produce a qualified opinion, which is the outcome you were trying to avoid by getting audited. Continuous collection is the defense, because the evidence exists before anyone knows which samples will be picked.

Can I keep Drata or Vanta while doing this?

Yes. Finished packs export to the matching control in an existing audit workspace, which helps when an auditor is already working inside one. For teams starting fresh, Vera covers what a platform plus a consultant would otherwise split between them.

Key Takeaways

Audits are decided by artifacts. Policy documents are necessary and rarely where a cycle goes wrong.

Sort the checklist by who can answer each item. Roughly 70% is answerable by a scan, about 9% needs a capture from a screen no API can read, and the rest needs a person, which is the part Vera chases in Slack.

Capture the enforcement, not only the configuration. The approved pull request and the branch protection screen together close what either one alone leaves open.

Populations must be complete and artifacts must be dated inside the observation window. Both fail the same way, by collecting retroactively.

Evidence accumulated on a schedule turns audit prep into a review pass. Evidence gathered during audit prep turns it into a month you lose.

Learn More About SOC 2 Compliance Automation

For a complete guide to automating the compliance process, see our guide on automating SOC 2 evidence collection, including how artifact collection fits alongside population monitoring. You may also find these relevant:

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