SOC 2 evidence checklist: 30 artifacts on a schedule

Thirty artifacts, sorted by when you produce them. Your calendar is what slips, not the criteria.

This SOC 2 evidence checklist lists thirty artifacts your controls need to produce, sorted by how often each one is due. Run it as a schedule and the evidence already exists when the auditor asks. Each row names a format that can be tested, the system it comes from, and the role that owns it.

The groups are always on, event driven, monthly, quarterly and yearly. We start with the ones that need no human effort.

How to use this list

A list sorted by control area tells you what an auditor will ask about. A list sorted by cadence tells you what goes on your calendar. Calendars are where evidence programs fail. You do not schedule a criterion. You schedule a Tuesday.

This is not the same document as the auditor’s request. The SOC 2 PBC list is the numbered demand that arrives once fieldwork begins. This checklist is the supply side, the routine that means those requests are already answered. The artifacts overlap. The index is different.

A note on scope. We scope Security only, and that is not a customer setting. Security does not test availability commitments, so the backup and restore rows are here because recovering from a security incident falls inside the common criteria,1 not because availability is in scope.

The checklist in five cadences

Owners are roles, not names. On a team of six they collapse onto two people, which is normal and covered in SOC 2 for a small team. Pick the group that matches a meeting you already hold, and put one named person on every row before you close this page.

Always on: settings, not tasks

These exist because software is running. Nobody has to remember them. Your two jobs are settings: keep retention longer than the whole period, and make sure the whole period exports in one pull. Check both this week.

No.ArtifactTestable formatWhere it comes fromOwner
1Production user list with role and grant dateSystem export showing the tool and the generation dateIdentity provider, cloud consoleIdentity admin
2Multi factor authentication enforcementExport or full window capture of the policy and the group it coversIdentity providerIdentity admin
3Every merge and release to productionExport with change ID, author, approver and merge timeSource control, CI pipelineEngineering lead
4Who can merge and who can releasePermission export per repository and per environmentSource control, deploy toolingEngineering lead
5Console and application audit logsThe retention setting, plus a query that returns a record from the oldest date you claimCloud provider, log platformPlatform owner
6Alert rules and the alerts that firedRule config plus timestamped alerts with the response logged on eachMonitoring, on call toolOn call owner
7Backup job history, failures includedJob report for the whole period with failed runs left inManaged database, backup toolPlatform owner
8Endpoint state: encryption, screen lock, patchesFleet report of enrolled devices, plus any known unenrolled onesDevice managementOperations owner

Triggered by an event: capture it the same day

No calendar date applies here, because the event picks it. That makes this group the easiest to lose. Produce the record on the day it happens and never at period end, since the timestamp is exactly what gets tested.

No.Trigger and artifactTestable formatWhere it comes fromOwner
9A hire: screening record, signed policy acknowledgment, and a ticket per access grantEach record carries the person and the dateScreening provider, document store, ticket systemPeople owner
10A departure: offboarding ticket and revocation record per systemDirectory record or log line with the revocation timeTicket system, identity providerIdentity admin
11A role change: the request and what was removedDirectory records before and after the changeTicket system, identity providerIdentity admin
12An incident: the incident recordDetection time, timeline, root cause, fix, and who was told whenIncident tool, ticket systemIncident owner
13A new vendor: its risk assessmentDated before the contract or the first data flowVendor registerProcurement owner
14An emergency change: the after-the-fact approvalApproval plus the written reason it could not waitTicket system, source controlEngineering lead

Monthly: reconcile and scan

Your HR system knows who works for you and your identity provider knows who can sign in. Those lists either match or they drift, and a drifted month is exactly the kind a sample can land on.

No.ArtifactTestable formatWhere it comes fromOwner
15Joiner and leaver reconciliationBoth exports, the differences, and a note explaining each lineHR system, identity providerPeople owner
16Production vulnerability scanUnedited scanner report with target range, date and findings by severityScannerSecurity owner
17Open findings against your remediation windowTicket export with found and closed dates on every rowTicket systemSecurity owner
18Access requests matched to access grantedThe approved ticket beside the directory record it createdTicket system, identity providerIdentity admin

Quarterly: reviews and what they changed

A review leaves two records. One is the review itself. The other is what it changed, such as removals, revocations and new owners, each with a date. The second record is the proof the review did something.

No.ArtifactTestable formatWhere it comes fromOwner
19User access review for each in-scope systemRecord naming the reviewer and the date, per systemIdentity provider, cloud console, databaseIdentity admin
20Every removal the review causedTickets or console records dated after the reviewTicket system, identity providerIdentity admin
21Privileged and service account reviewAccount list with a named owner and a reason for eachCloud console, secrets managerPlatform owner
22Restore test from backupWho ran it, what was restored, how long it took, whether it matchedBackup tool, ticket systemPlatform owner
23Log coverage checkIn-scope systems beside actual log sources, gaps named and datedLog platform, system inventoryPlatform owner

Yearly: the set that goes stale without warning

Nothing visibly breaks when these age. A policy approved two years ago still reads fine and is still a finding, because the review is the control. Run the whole yearly set together in a quiet month and date every output.

No.ArtifactTestable formatWhere it comes fromOwner
24Policies reviewed and re-approvedEach with a version, approval date and approverDocument storePolicy owner
25Risk assessmentRegister with scores, chosen treatment and the date workedRisk registerFounder or security owner
26Security awareness trainingCompletion report for every current employee, with datesTraining platformPeople owner
27Incident response exerciseAgenda, attendees, date and resulting actionsDocument store, ticket systemIncident owner
28Recovery plan testScenario, outcome and the plan version testedDocument storePlatform owner
29Current report for each vendor holding your dataThe report plus a dated note on who read it and what they concludedVendor registerProcurement owner
30Penetration test, if your policy commits to oneThe report plus remediation tickets with close datesTesting vendor, ticket systemSecurity owner
8Rows that only need retention and an export
6Rows whose date is set by an event
16Rows that are a recurring task with an owner

Four tests every artifact must pass

A file becomes evidence when it passes four tests. They apply to all thirty rows, so fix them once at the source instead of thirty times under a deadline.

Dated
The date sits inside the artifact, not just in the filename. A period is tested by comparing dates, so an undated file cannot be placed in it.
Scoped
It shows which environment, account or population it covers. A crop of one toggle shows the toggle and nothing about where it applies.
Sourced
The generating tool is visible on the artifact. A list you retyped into a spreadsheet proves your typing, not the system.
Complete
Populations go out whole. Choosing the sample is the auditor’s job under the attestation standards,2 and a list you filtered first is not a population anymore.

Your policy sets the schedule you are tested on

The criteria do not hand you a schedule.1 You write frequencies into your own policies, and from then on the examination holds you to them. Write quarterly and you owe four. Write monthly and you owe twelve. That makes drafting your policy set an operating decision, not a writing exercise.

So pick the longest interval you can defend, write it down, and hit it every time. A monthly control missed twice reads worse than a quarterly control met four times. The first does not operate as described. The second does.

Check retention before anything else

The always-on rows cost the least and are the easiest to lose for good. Logs, alert history and backup job records all follow a retention setting someone picked at install, often the default. If that window is shorter than your observation period, the early months are already gone and no later effort brings them back. Look at those three settings today.

Type 1 versus Type 2: why cadence counts

A Type 1 describes your controls on one date,3 so this list is a state you set up once. A Type 2 covers a window, and the math inside it is strict. Across a 3-month observation window, a yearly control may not fire at all and a quarterly control fires about once. One instance means one chance to get it right.

That argues for shortening cadences before the window opens, not during it. How long the observation period has to be weighs a shorter window against how many times each control gets to show itself. Our SOC 2 readiness assessment page explains how to find the rows you cannot yet produce.

Order of work

Work the list backward from the slowest items. Yearly artifacts take longest and cannot be backdated. Quarterly reviews need a real system list first. Event rows are discipline. The always-on rows come last and are mostly a settings check.

  1. Name one owner per row. A row owned by a team is owned by nobody, and it will be the one still open in week three.
  2. Fix retention first. Logs, alerts and backup history are the only rows where waiting destroys evidence for good.
  3. Match policy to calendar. Change the document to the cadence you will really keep, before the period opens.
  4. File each artifact the day it exists, named with its date and the control it supports, so nobody rebuilds nine months of history in the week the request arrives.
  5. Send exports, not transcriptions. If the system can generate the list, let it. Your spreadsheet summarizes evidence. The export is the evidence.

Cost: platform, consultant, or yourself

Evidence collection is the job compliance platforms are built to automate, and it is a core part of what their contracts pay for. Here is what the outside routes cost, according to sources that track them.

  • Vendr reports a median annual contract value of $20,000 for Vanta, based on purchases completed through its marketplace. Source, checked 2026-07-30.
  • Vendr reports a median annual contract value of $24,601 for Drata, based on purchases completed through its marketplace. Source, checked 2026-07-30.
  • Comp AI states that a vCISO or compliance consultant might charge $150 to $400 an hour, which can total $20,000 to $50,000 for a full SOC 2 prep engagement. Source, checked 2026-07-30.

You can run much of this list yourself. The always-on rows are settings. The event rows are habits. The recurring rows are calendar entries with an owner. What a tool adds is collection from systems it can reach, mapping to criteria, and a package the examination reads from. Someone at your company still confirms each artifact is what it claims to be, because that statement is about your system.

Our software does that collection for $199 a month, cancel any time, or $2,189 a year, pay for eleven months, get twelve. Audits go through our preferred pricing program, and we negotiate the fee on your behalf, and the price shows in your account before you book. Audits unlock after four paid months on monthly, or right away on yearly, and a Type 2 also waits for the 3-month observation window to finish. cybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.

Your next step

Find out which of the thirty rows you can already produce. The free readiness assessment takes about 15 minutes, asks about each control, and separates what needs building from what only needs evidence. When you know the size of the gap, compare the plans.

Questions

What counts as evidence for SOC 2?
Records your systems and people produce while running the company: user lists from the identity provider, the list of production changes, scan reports, backup history, access reviews, training completions, incident records and vendor assessments. There is no fixed catalog. Evidence is whatever shows each control you describe, with a date on it.
How often should SOC 2 evidence be collected?
As often as your own policies say. Some records are generated continuously and just need enough retention. Others are monthly, quarterly or yearly tasks, and some are triggered by events like a hire, a departure or an incident. A Type 2 samples from what happened inside the period, so rare controls give the auditor very little to test.
Is an evidence checklist the same as a PBC list?
No. The PBC list is the numbered request an auditor sends once the examination starts, sorted by control area. An evidence checklist is your own production schedule, sorted by frequency. Keep the checklist running and most of the PBC list is answered when it arrives.
Are screenshots acceptable SOC 2 evidence?
Yes, if they show a date, the scope and the source. A full window capture that shows the setting, the group it applies to, the tool and the clock can be tested. A tight crop of one toggle cannot. If the system offers an export, send the export.
How far back does SOC 2 evidence have to reach?
A Type 1 looks at one date, so evidence shows the system on that date. A Type 2 covers the whole observation period with no gaps, which is why log and backup retention matter. A retention window shorter than the period deletes evidence you will be asked for.

Sources

  1. TSP Section 100, Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy AICPA. The criteria themselves, including the common criteria every SOC 2 report covers. Checked 1 August 2026.
  2. Statements on Standards for Attestation Engagements AICPA. The attestation standards a SOC 2 examination is performed under. Checked 1 August 2026.
  3. SOC 2 Report AICPA. What a SOC 2 report is and who may issue one. Checked 1 August 2026.

Get audit-ready without a compliance team

The readiness assessment is free, with no payment and no card. When you are ready, the software is $199 a month, cancel any time, and audits go through our preferred pricing program. You can be audit-ready starting at about a week.

Start with a free readiness assessment

cybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.