SOC 2 · Last updated 31 July 2026 · 9 min read

The SOC 2 evidence checklist, by cadence

Thirty artifacts, grouped by how often you have to produce them rather than by control area, because the calendar is what actually breaks.

A SOC 2 evidence checklist is the list of artifacts your controls have to produce, on a schedule you set, so the evidence already exists when the auditor asks. The list is below, grouped by how often each item has to be produced rather than by control area.

Five groups. Continuous, monthly, quarterly, annual, and event driven. Thirty artifacts, each with the format that can be tested, the system it comes from, and the role that owns it.

Grouping is the whole point of this page. A list organized by control area tells you what an auditor will ask about. A list organized by cadence tells you what goes in your calendar, and the calendar is what breaks. Nobody schedules a criterion. They schedule a Monday.

Two documents do two different jobs here. The SOC 2 PBC list is the auditor’s numbered request and how each item has to come back. This page is the production schedule that makes those requests already answered before they arrive. Same artifacts. Different index.

Scope, before the tables. Polara G.R.C. scopes Security only, and that is not configurable by the customer. A Security only examination does not test availability commitments, so the backup and recovery rows are here because recovering from a security incident sits inside the common criteria,¹ not because availability is in scope.

What every artifact has to carry

Four properties decide whether a file is evidence or just a file. They are the same four for all thirty rows, and they are worth fixing once at the source rather than thirty times under deadline.

A date: The artifact states when it was produced, inside the artifact rather than in the file name. A period is tested by comparing dates, so anything undated cannot be placed inside one.
Its scope: Which environment, which account, which population. A capture cropped to a single toggle shows the toggle and says nothing about what it applies to.
Its source: The tool that generated it, visible on the face of the artifact. A listing you typed into a spreadsheet evidences your typing, and the system it describes is exactly what it leaves out.
Completeness: Populations go out whole. Selecting the sample is the auditor’s job under the attestation standards,² so a list you filtered first is no longer a population.

The checklist, by cadence

Five tables follow. Owners are roles rather than names, and on a team of six they collapse onto two people, which is normal and covered in SOC 2 for a small team. Read down the group that matches a meeting you already hold, and give every row one named human before you close the tab.

Continuous: the system produces it whether you remember or not

Nothing in this group is a task. These artifacts exist because software is running. Your job is two things, and both are settings rather than work: retention long enough to cover the whole period, and the ability to export that whole period in one operation. Check both now.

No.	Artifact	Format that can be tested	Source system	Owner
1	Production user listing with role and grant date	System export with the tool name and generation date on it	Identity provider, cloud console	Identity provider administrator
2	Multi factor authentication enforcement	Export or full window capture showing the policy and the group it applies to	Identity provider	Identity provider administrator
3	Change population: every merge and release to production	Export carrying change identifier, author, approver and merge timestamp	Source control, build pipeline	Engineering lead
4	Who is allowed to merge and who is allowed to release	Exported permission listing per repository and per environment	Source control, deploy tooling	Engineering lead
5	Console and application audit logs	The retention setting, plus a query returning a real record from the oldest date you claim to hold	Cloud provider, log platform	Platform owner
6	Alert rules and the alerts they actually fired	Rule configuration plus alert instances with timestamps and the response recorded against each	Monitoring tool, on call tool	On call owner
7	Backup job history, successes and failures both	Job report covering the full period with failed runs left in	Managed database, backup tool	Platform owner
8	Endpoint state: disk encryption, screen lock, patch level	Fleet report listing every enrolled device, and the unenrolled ones you know of	Device management tool	Operations owner

Monthly: two reconciliations and a scan

Your human resources system knows who works here. Your identity provider knows who can log in. Those two lists agree or they do not, and the month you let them drift is the month a sample lands on.

No.	Artifact	Format that can be tested	Source system	Owner
9	Joiner and leaver reconciliation	Both exports plus the differences, with a written explanation on every line	Human resources system, identity provider	Onboarding owner
10	Vulnerability scan of the production environment	Unmodified scanner report showing the target range, the scan date and findings by severity	Scanner	Security owner
11	Open findings against your own remediation window	Ticket export carrying a discovery date and a closure date on every row	Ticket system	Security owner
12	Access requests against the access that was actually granted	The approved ticket, paired with the directory record it produced	Ticket system, identity provider	Identity provider administrator

Quarterly: the reviews, and what the reviews changed

A review produces two artifacts and only one of them is the review. The second is the change it caused. Removals, revocations, ownership moves: capture those with dates, because the change record is what shows the review had teeth. A review that touched nothing is a document.

No.	Artifact	Format that can be tested	Source system	Owner
13	User access review across every in scope system	The review record naming who performed it and when, per system	Identity provider, cloud console, database	Identity provider administrator
14	Every removal the review produced	Tickets or console records dated after the review, closing each item it raised	Ticket system, identity provider	Identity provider administrator
15	Privileged and service account review	The account listing with a named human owner and a written justification each	Cloud console, secrets manager	Platform owner
16	Restore test from backup	Test record naming who ran it, what was restored, how long it took, and whether it matched	Backup tool, ticket system	Platform owner
17	Log coverage check: in scope systems against actual log sources	The two lists side by side with every gap named and dated	Log platform, system inventory	Platform owner

Annual: the group that expires quietly

These rows go stale without anything appearing to break. A policy approved two years ago is still a perfectly good policy and still a finding, because the control is the review rather than the document. Run the whole annual set as one block, in a month that is not your busiest, and date every output.

No.	Artifact	Format that can be tested	Source system	Owner
18	Policy set reviewed, re approved and dated	Each policy carrying a version, an approval date and the approver	Document store	Policy owner
19	Risk assessment	The register with each risk scored, the treatment chosen, and the date worked	Risk register	Founder or security owner
20	Security awareness training completion	Completion report listing every current employee with a completion date	Training platform	Human resources owner
21	Incident response exercise	The agenda, the attendee list, the date, and the findings it produced	Document store, ticket system	Incident owner
22	Recovery plan test	Test record with the scenario, the outcome, and the plan version it tested	Document store	Platform owner
23	Vendor assurance: the current report for each vendor that holds your data	The report itself plus a dated note saying who read it and what they concluded	Vendor register	Procurement owner
24	Penetration test, if your own policy commits to one	The report plus the remediation tickets it produced, with closure dates	Testing vendor, ticket system	Security owner

Event driven: the cadence you cannot put in a calendar

These six have no scheduled date because the event sets the date. That is what makes them the easiest group to lose. One rule covers all of them: produce the artifact on the day it happens, never at period end, because the timestamp is the thing being tested.

No.	Trigger	Artifact and the format that can be tested	Source system	Owner
25	Someone starts	Screening record carrying the person and the date, a per person policy acknowledgment, and a ticket for each access grant	Screening provider, document store, ticket system	Human resources owner
26	Someone leaves	Offboarding ticket plus a deprovisioning log line or directory record carrying the time of revocation, per system	Ticket system, identity provider	Identity provider administrator
27	Someone changes role	The request, plus the directory records before and after, showing what was removed	Ticket system, identity provider	Identity provider administrator
28	An incident is declared	Incident record carrying detection time, timeline, root cause, resolution and who was told at what point	Incident tool, ticket system	Incident owner
29	A vendor is onboarded	Risk assessment dated before the contract or before the first flow of data	Vendor register	Procurement owner
30	An emergency change ships	The retroactive approval and the written reason it could not wait	Ticket system, source control	Engineering lead

8Rows that need no human action, only retention and export

16Rows that are a recurring task somebody has to own

6Rows where the event picks the date for you

You choose the frequency, then it binds you

Nothing in the criteria hands you a schedule.¹ You write the frequency into your own policies, and from that moment the examination tests you against the document you wrote. Write quarterly and you owe four. Write monthly and you owe twelve. The policy set is where those numbers get committed, which makes policy drafting an operational decision rather than a writing exercise.

So the advice is unromantic. Pick the longest interval you can defend, write that one down, then hit it every time. A monthly control missed twice reads worse than a quarterly control met four times, because the first one is a control that does not operate as described and the second is a control that does.

The retention trap

Continuous artifacts are the cheapest rows on this list and the ones most likely to be unrecoverable. Logs, alert history and backup job records are all governed by a retention setting somebody picked at install time, usually a default. If that window is shorter than your observation period, the evidence for the early months is already gone and no amount of effort later reproduces it. Go and read the three settings today.

Why cadence matters more for a Type 2

For a Type 1 the report describes your controls at a single date,³ so this list is a state you establish. A Type 2 covers a window, and the arithmetic inside that window is unforgiving. Over a 3-month observation window an annual control fires zero times and a quarterly control fires about once. One instance. One chance to get the artifact right.

That is the practical case for shortening cadences before the window opens rather than during it. How long the observation period has to be covers the tradeoff between a shorter window and the number of times each control gets to demonstrate itself.

Working the list backwards

Start at the annual group, because those artifacts take the longest to produce and cannot be back dated. Then the quarterly reviews, which need a real system listing before they can start. Then the event driven six, which are pure discipline. The continuous rows are last and are mostly a settings check.

Put one name on every row. A row owned by a team is owned by nobody, and it will be the one still open in week three.
Fix retention before anything else. Logs, alerts and backup history are the only rows where waiting destroys the evidence permanently.
Match your policies to your calendar, not the reverse. Change the document to the cadence you will actually hold, before the period opens rather than after.
File each artifact the day it is produced, named with its date and the control it supports. The alternative is reconstructing nine months of history in the week the request list arrives.
Send exports, not transcriptions. If a system can generate the listing, the system generates it. Your spreadsheet is a summary of evidence and the export is the evidence.

What Polara G.R.C. does with this list

The platform collects what it can reach, maps each artifact to the criteria it supports, and assembles the package the examination reads from. Someone at your company still confirms each artifact is what it claims to be. That assertion is about your system, so it stays yours.

Where this sits in what you pay

Type 1 is $4,000 one time, and that covers the first examination and the engagement fee for the independent partner auditor. Continuous collection for a Type 2 runs on a subscription at $600 per month on a 12-month term. Each examination is $5,000, and it can be requested once the subscription is active and the 3-month observation window has completed.

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

Questions

What evidence is required for a SOC 2 audit?

Artifacts your systems and your people produce in the ordinary course of running the company: user listings from your identity provider, the population of changes deployed to production, vulnerability scan reports, backup job history, access review records, training completion, incident records, and vendor assessments. The examination tests those artifacts against the controls you described, so the requirement is not a fixed catalog. It is whatever makes each control you claim visible and dated.

How often do you need to collect SOC 2 evidence?

At the frequency your own policies state. Some artifacts are produced continuously by systems and only need retention long enough to cover the period. Others are tasks on a monthly, quarterly or annual cycle, and a few are triggered by an event such as a hire, a departure or an incident. A Type 2 examination samples from the instances that occurred inside the period, so a control that fires quarterly gives the auditor very few instances to select from.

What is the difference between an evidence checklist and a PBC list?

A prepared-by-client list is the numbered request an auditor sends you, organized by control area, and it arrives once the examination is underway. An evidence checklist is your own operating schedule, organized by how often each artifact has to be produced. One is the demand and the other is the supply. If the checklist is running, the request list is mostly already answered when it lands.

Do screenshots count as SOC 2 evidence?

They count when they carry a date, the scope they apply to, and a visible source. A capture of a whole configuration page showing the policy, the group it applies to, the tool and the clock is testable. A crop of one toggle is not, because nothing in it says which environment it belongs to or when it was taken. Where a system export exists, send the export instead.

How far back does SOC 2 evidence need to go?

For a Type 1 the report describes controls at a single date, so evidence establishes the state of the system on that date. For a Type 2 it has to cover the entire observation period without gaps, which is why log and backup retention settings matter more than they look. A retention window shorter than your period deletes evidence you are going to be asked for.

Sources

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.
Statements on Standards for Attestation Engagements AICPA. The attestation standards a SOC 2 examination is performed under. Checked 1 August 2026.
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.

$4,000 one time for SOC 2 Type 1, with the first examination and the auditor engagement fee included. audit-ready starting at about a week.

Get started