SOC 2 checklist: what to prove before the audit

•SOC 27 November 2026·8 min read

A SOC 2 checklist is useful only if every checked item points to a real control, an owner and evidence from the period a CPA firm will examine. A policy marked complete does not prove it was followed. A screenshot captured at the end of a Type 2 period does not prove how a monthly review ran earlier. Use the tasks below as a working register, then let your selected CPA firm confirm the scope and samples for your engagement.

Use the AICPA Trust Services Criteria linked below to map each assigned task to the control your organisation operates. Your system description, risks, commitments and selected categories determine the evidence to collect.

How should you use this SOC 2 checklist?

Name one person to own the register and one operator for each control. Record the criterion, the control you actually perform, its frequency, the evidence source and the reviewer. Mark a task complete only after opening an example record. If a task cannot be evidenced, write the gap and its owner instead of colouring it green.

Start by asking the buyer what assurance it needs. A Type 1 report addresses control design at a point in time. A Type 2 report also examines operation over a defined period. The AICPA resource library describes the SOC 2 examination and publishes illustrative reports. If the request names a Type 2 report, begin collecting repeated evidence before you promise a delivery date.

Scope the system before collecting evidence

Write a one-page boundary: the service customers buy, the production environment that delivers it, data categories, relevant people, supporting vendors and excluded systems. Compare that boundary with your sales promises and contracts. If the buyer uses a hosted product, a report whose description covers only the corporate office will not answer the question. Review the boundary with the CPA firm before building a large evidence folder.

Select the Trust Services Categories that fit the commitment. Security is the common foundation; Availability, Processing Integrity, Confidentiality and Privacy depend on what you promise and what the buyer requests. The AICPA criteria explain these categories. Do not include an optional category solely because its name looks reassuring: it widens the work your firm must examine.

Which access records matter most?

The AICPA criterion CC6.1 addresses logical access security over protected information assets. That does not reduce to an MFA screenshot. Your control design may include an asset inventory, roles, authentication, privileged access restrictions and a review process. For each control you claim, be ready to show its configuration and evidence that people used it as stated.

Build complete populations before selecting a few attractive examples. Export all in-scope joiners and leavers for the period, and all scheduled access reviews. Compare those lists with the source systems, then let the CPA firm decide its sample. A missing leaver, an unreviewed service account or a review performed after its stated cadence belongs in the exception log. Changing a policy after the fact does not make the earlier control operate.

How do change and incident controls become evidence?

Trace one ordinary production change from request through review, testing, approval and deployment. Then trace an emergency change. If your team uses branch protection, preserve the setting and the actual pull request or release records from the period. The criterion is not satisfied merely because the repository currently has a review rule. A bypass during an incident needs a documented exception path.

For operations, show how you detect a security event and who responds. Keep the alert configuration, the on-call ownership and records of a real event or a test, where one exists. Avoid fabricating an incident just to fill a folder. A tabletop can show how the process was tested if no relevant incident occurred. The result should include what the team changed after learning from the test.

The risk assessment should connect these operational controls to actual threats. Record the service risk, its owner, how it was assessed and the treatment decision. A vulnerability list with no assigned action is a list, not a completed risk process. If remediation extends beyond the period, keep the open issue visible and discuss it with the auditor rather than describing the control as fully effective.

How do you prove a control ran throughout the period?

Make an evidence calendar. A control that says monthly should produce a record for each expected month within the examined window. A control that runs at an event should be checked against the full event population. Maintain both the underlying record and the reviewer decision. This helps distinguish an empty month with no event from an event nobody processed.

Do not replace a failed record with a later successful one. Mark the original exception, document its cause and show the corrective action. If the control was never designed to produce the record you need, change it prospectively and discuss the affected period with the CPA firm. Our SOC 2 Type 2 guide goes deeper on observation windows, sample populations and exceptions.

What should be ready for the CPA firm?

The audit handoff begins with a defensible system description and management assertion, not a folder of random screenshots. Give the firm the service boundary, selected categories, relevant policies, control list, owner list, evidence populations, exceptions and subservice organisation details. Agree which version of each document is current. Give reviewers a path to the original record so they can ask follow-up questions without losing its context.

Ask the prospective firm how it will sample controls and what it expects from management. Engage it early enough to test the scope before the period is mostly over. A CPA firm issues the SOC 2 report after its examination. Evidr helps teams prepare the evidence for that process. Our SOC 2 audit guide covers choosing a firm, understanding sampling and preparing for fieldwork.

Where can software help, and where should you keep it simple?

Software helps when evidence lives in several systems and owners need one traceable review queue. Evidr describes evidence upload, AI-assisted review, control mapping, version history and approval on its product pages. It also offers scoped read-only auditor access to approved material. Use a real control to test whether a reviewer can find the source, period, owner and decision. A dashboard score alone does not answer those questions.

Evidr is useful when several systems and owners feed a traceable review queue. Start with one control and test whether its source, period, owner and decision remain visible. Management sets scope, performs access reviews and repairs missed approvals; a CPA firm performs the independent SOC 2 examination. Check the current plan and usage terms against the repeated work the platform would remove.

The strongest final test is simple: choose a control at random, pick an occurrence in the middle of the period and ask its owner to show the original record and review decision. If that takes a frantic search, the next task on this checklist is to improve the evidence process, not to add more check marks.