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. | Artifact | Testable format | Where it comes from | Owner |
|---|---|---|---|---|
| 1 | Production user list with role and grant date | System export showing the tool and the generation date | Identity provider, cloud console | Identity admin |
| 2 | Multi factor authentication enforcement | Export or full window capture of the policy and the group it covers | Identity provider | Identity admin |
| 3 | Every merge and release to production | Export with change ID, author, approver and merge time | Source control, CI pipeline | Engineering lead |
| 4 | Who can merge and who can release | Permission export per repository and per environment | Source control, deploy tooling | Engineering lead |
| 5 | Console and application audit logs | The retention setting, plus a query that returns a record from the oldest date you claim | Cloud provider, log platform | Platform owner |
| 6 | Alert rules and the alerts that fired | Rule config plus timestamped alerts with the response logged on each | Monitoring, on call tool | On call owner |
| 7 | Backup job history, failures included | Job report for the whole period with failed runs left in | Managed database, backup tool | Platform owner |
| 8 | Endpoint state: encryption, screen lock, patches | Fleet report of enrolled devices, plus any known unenrolled ones | Device management | Operations 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 artifact | Testable format | Where it comes from | Owner |
|---|---|---|---|---|
| 9 | A hire: screening record, signed policy acknowledgment, and a ticket per access grant | Each record carries the person and the date | Screening provider, document store, ticket system | People owner |
| 10 | A departure: offboarding ticket and revocation record per system | Directory record or log line with the revocation time | Ticket system, identity provider | Identity admin |
| 11 | A role change: the request and what was removed | Directory records before and after the change | Ticket system, identity provider | Identity admin |
| 12 | An incident: the incident record | Detection time, timeline, root cause, fix, and who was told when | Incident tool, ticket system | Incident owner |
| 13 | A new vendor: its risk assessment | Dated before the contract or the first data flow | Vendor register | Procurement owner |
| 14 | An emergency change: the after-the-fact approval | Approval plus the written reason it could not wait | Ticket system, source control | Engineering 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. | Artifact | Testable format | Where it comes from | Owner |
|---|---|---|---|---|
| 15 | Joiner and leaver reconciliation | Both exports, the differences, and a note explaining each line | HR system, identity provider | People owner |
| 16 | Production vulnerability scan | Unedited scanner report with target range, date and findings by severity | Scanner | Security owner |
| 17 | Open findings against your remediation window | Ticket export with found and closed dates on every row | Ticket system | Security owner |
| 18 | Access requests matched to access granted | The approved ticket beside the directory record it created | Ticket system, identity provider | Identity 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. | Artifact | Testable format | Where it comes from | Owner |
|---|---|---|---|---|
| 19 | User access review for each in-scope system | Record naming the reviewer and the date, per system | Identity provider, cloud console, database | Identity admin |
| 20 | Every removal the review caused | Tickets or console records dated after the review | Ticket system, identity provider | Identity admin |
| 21 | Privileged and service account review | Account list with a named owner and a reason for each | Cloud console, secrets manager | Platform owner |
| 22 | Restore test from backup | Who ran it, what was restored, how long it took, whether it matched | Backup tool, ticket system | Platform owner |
| 23 | Log coverage check | In-scope systems beside actual log sources, gaps named and dated | Log platform, system inventory | Platform 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. | Artifact | Testable format | Where it comes from | Owner |
|---|---|---|---|---|
| 24 | Policies reviewed and re-approved | Each with a version, approval date and approver | Document store | Policy owner |
| 25 | Risk assessment | Register with scores, chosen treatment and the date worked | Risk register | Founder or security owner |
| 26 | Security awareness training | Completion report for every current employee, with dates | Training platform | People owner |
| 27 | Incident response exercise | Agenda, attendees, date and resulting actions | Document store, ticket system | Incident owner |
| 28 | Recovery plan test | Scenario, outcome and the plan version tested | Document store | Platform owner |
| 29 | Current report for each vendor holding your data | The report plus a dated note on who read it and what they concluded | Vendor register | Procurement owner |
| 30 | Penetration test, if your policy commits to one | The report plus remediation tickets with close dates | Testing vendor, ticket system | Security 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.
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.
- 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.
- Fix retention first. Logs, alerts and backup history are the only rows where waiting destroys evidence for good.
- Match policy to calendar. Change the document to the cadence you will really keep, before the period opens.
- 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.
- 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?
How often should SOC 2 evidence be collected?
Is an evidence checklist the same as a PBC list?
Are screenshots acceptable SOC 2 evidence?
How far back does SOC 2 evidence have to reach?
Sources
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 assessmentcybersoftware is not a CPA firm. SOC 2 examinations are performed by independent licensed U.S. CPA firms.