SOC 2 checklist for a first audit
Work top to bottom. Every item names the artifact an auditor will ask you to produce.
This is a SOC 2 checklist for a first Type 2 audit against the security criterion, written as tasks rather than control numbers. Each item says what you have to do and what artifact proves you did it. Work it in order. The early sections produce decisions the later ones depend on.
It assumes a company of roughly ten to fifty people running a cloud application. If your environment is more complicated, treat this as the floor. The preparation guide explains the reasoning behind each block, and the timeline shows when each has to be finished by.
Before section one, decide what is in the audit at all. Everything below is scoped against that decision, and no tool on this site can make it for you. The scope and system description page is the half hour that saves the argument in month five.
The boxes work, and so does printing this
Every box below ticks and stays ticked. State is kept in this browser on this device and nothing is sent anywhere, so it survives a reload but not a different machine. A browser set to block site data will tick without remembering. Each section carries its own count and reset. To work on paper, print the page: the boxes come out empty.
1. Scope and planning
0 of 6 done ·
What an auditor looks for in scope
Evidence that passes. A dated system description that names the product, the environments (production and anything that feeds it), the cloud accounts, the data types and the people with access. The auditor reads it first and tests everything else against it, so vague words like "our platform" get questions.
How long. One to two weeks of part-time work for a single-product company. The criteria and window decisions can be made in a single meeting once the facts are on the table.
Common mistakes. Scoping the whole company instead of the system customers rely on, adding Availability or Confidentiality because a template listed them, and choosing a window start date before the controls actually run.
Canadian note. If customer personal information is in scope, write down where it is stored and processed. Canadian buyers increasingly ask about data residency, and Quebec customers may need a privacy impact assessment for transfers outside Quebec under Law 25.
2. Policies
Every policy needs a version, an approval date, a named approver and evidence that staff acknowledged it. A policy nobody has read is a finding waiting to happen. The policy checklist tool works out which of these you actually need from your criteria and the data you hold, and the policy templates page covers how to edit a downloaded set without committing yourself to somebody else's cadences.
0 of 13 done ·
What an auditor looks for in policies
Evidence that passes. Each policy with a version number, an approval date, the approver by name, and a record showing every person in scope acknowledged it. An e-signature log or an HR system export both work; an email saying "please read these" does not.
How long. Two to four weeks to adapt and approve a full set, most of it waiting on reviews. Acknowledgement collection takes another week if you chase it.
Common mistakes. Committing to cadences you will not keep, leaving another company name in a downloaded template, and approving policies after the window has started so the first weeks have no approved policy behind them.
Canadian note. Your privacy and retention policies should reflect PIPEDA and, where you have Quebec customers or staff, Law 25: a named person responsible for personal information, a published governance policy and a breach register.
Write down what you will really do
Every commitment in a policy becomes a control an auditor tests. A template that promises quarterly access reviews when you will manage two a year has created an exception on your own report. Set the cadence you will keep, evidence it consistently, and raise it later once the habit exists.
Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.
3. Access control
0 of 9 done ·
What an auditor looks for in access control
Evidence that passes. System-generated exports: the identity provider user list, the MFA enforcement setting, ticket trails for access grants and the completed review records. Auditors sample grants and terminations from your population, so every one needs its record.
How long. SSO and MFA enforcement usually take one to three weeks. The first formal access review takes a day; the discipline of repeating it is what the Type 2 tests.
Common mistakes. Service accounts and break-glass accounts nobody listed, a review that says "no changes" without showing who was reviewed, and departures whose access removal happened days after the stated limit.
Canadian note. No province adds specific access rules for a SOC 2, but under PIPEDA you are expected to limit access to personal information to people who need it, so the same evidence answers a privacy regulator as well.
4. Change management
0 of 7 done ·
What an auditor looks for in change management
Evidence that passes. Branch protection settings, a full list of production deployments in the window, and for a sample of them the pull request showing review, approval and passing tests. Infrastructure changes need the same trail, usually through infrastructure as code.
How long. A week or two to switch on branch protection and pipeline checks. The evidence then builds itself if every change goes through the pipeline.
Common mistakes. Admins who can bypass branch protection and do, console changes to production that never touched version control, and emergency fixes with no after-the-fact approval.
Small teams. If only two engineers exist, document a compensating control such as a post-deployment review by a founder, and follow it every time. Auditors accept a small team; they do not accept an undocumented exception.
5. Infrastructure and monitoring
0 of 10 done ·
What an auditor looks for in infrastructure
Evidence that passes. Cloud configuration exports for encryption and logging, alert rules with samples that fired and were handled, vulnerability scan reports with tickets closed inside your stated timelines, and a device inventory showing disk encryption and endpoint protection.
How long. Two to six weeks depending on how much is already configured. A penetration test takes one to three weeks to book and run, plus time to fix and retest.
Common mistakes. Log retention shorter than the observation window, alerts sent to a channel nobody watches, and patch timelines in the policy that the ticket history shows you never met.
Canadian note. Check where your logs are stored. Logs often contain personal information, and some Canadian public sector and health buyers ask for logs to stay in Canada too.
6. Vendors and subprocessors
0 of 6 done ·
What an auditor looks for in vendor management
Evidence that passes. A dated vendor register with a risk rating per vendor, the SOC 2 or ISO 27001 report on file for critical vendors with a note of what you checked (period, exceptions, complementary user entity controls), and signed data protection terms.
How long. One to two weeks to build the register and collect reports. Annual re-review is a day or two once the register exists.
Common mistakes. Collecting vendor reports without reading them, missing the complementary user entity controls your own report now depends on, and leaving small tools with customer data off the register.
Canadian note. Under PIPEDA you remain accountable for personal information you pass to a vendor, including one outside Canada. Law 25 adds a written privacy assessment before personal information leaves Quebec, and Bill C-36, introduced June 15, 2026 and at second reading, would add a similar duty federally.
7. People
0 of 6 done ·
What an auditor looks for in people controls
Evidence that passes. For every hire and departure in the window: the signed confidentiality agreement, the background check record where your policy requires one, the training completion with a date, and the completed onboarding or offboarding checklist.
How long. A few days to set up the checklists and a training tool. The work then happens per person, so it scales with hiring.
Common mistakes. Contractors treated differently from employees without saying so in the policy, training completed after the deadline your policy states, and offboarding records that exist for some departures and not others.
Canadian note. Background checks in Canada need consent and have to be proportionate to the role. Criminal record checks for every role can be challenged under provincial human rights law, so write the policy to match what you actually check and why.
8. Incidents, risk and resilience
0 of 8 done ·
What an auditor looks for in incidents, risk and resilience
Evidence that passes. An incident log with entries in the window (even minor ones), tabletop exercise notes with attendees and lessons, a restore test record showing what was restored and how long it took, and a risk assessment reviewed by management with owners and treatment decisions.
How long. A tabletop takes half a day to prepare and two hours to run. A first risk assessment is usually a week of part-time work. A restore test is a day.
Common mistakes. An empty incident log, which reads as nobody looking rather than nothing happening; backups that were never restored; and a risk assessment that lists threats without owners or decisions.
Canadian note. PIPEDA requires reporting a breach of security safeguards that creates a real risk of significant harm to the Privacy Commissioner and to affected people, and keeping a record of every breach for 24 months. Quebec requires notifying the Commission d'accès à l'information and keeping a breach register. Your plan should name who decides and how fast.
9. Evidence readiness
0 of 7 done ·
What an auditor looks for in evidence
Evidence that passes. Exports and screenshots that show the date, the system and the account, stored by control with a consistent name, plus a complete population list for anything sampled. Most auditors now accept read-only access to a compliance platform in place of folders.
How long. Setting up the structure takes a day. The ongoing cost is the recurring tasks, usually a few hours a month for a small company once the rhythm is set.
Common mistakes. Evidence created in a rush at the end of the window, screenshots with no date visible, and populations built by hand that miss people, which forces the auditor to widen the sample.
Tip. Put every periodic control on a shared calendar with one named owner. Most Type 2 exceptions at small companies are a quarterly task that nobody did in one quarter.
The evidence collection page covers what auditors accept, what they reject, and how to keep the workload from becoming somebody's whole job.
10. Before the auditor starts
0 of 5 done ·
What an auditor looks for before fieldwork
Evidence that passes. A signed engagement letter, booked fieldwork dates, a draft system description and a named contact who can answer requests the same day.
How long. Fieldwork for a small Type 2 usually runs two to four weeks, and the report arrives four to eight weeks after the window ends.
Common mistakes. Booking the auditor after the window closes, which pushes the report out by months, and letting the system description be written by someone who does not know the system.
Canadian note. SOC 2 reports are issued by licensed CPA firms under AICPA standards. Canadian firms can issue them, and the CPA Canada equivalent standard is CSAE 3416 for SOC 1-style work. Confirm the firm's licensing and peer review before you sign.
When you reach that point, GetSOC2 covers how to compare Canadian audit firms and what the fees look like.
Want this as a formatted tracker
The checklist above stays on this page. The evidence tracker builds the working version from your criteria and your observation window, with an owner column, a cadence and the artifact that satisfies each row.
Build my evidence trackerBefore working through any of it, put a number on the hours. Ten to sixteen a week during preparation, falling to three to five through the window, is what how much time SOC 2 actually takes you sets out. A checklist with no funded owner never gets finished.
Common questions
Is this checklist enough to pass a SOC 2 audit?
It covers the security criterion for a straightforward cloud application, which is what a first audit usually is. It is not a substitute for your auditor's control list, which will be mapped to the criteria in their own format. Use this to get ready and then reconcile it against the request list the firm sends you.
How many controls does SOC 2 have?
There is no fixed number. SOC 2 defines criteria, not controls, and you choose the controls that meet them. A first audit against security alone typically ends up with somewhere between sixty and a hundred controls depending on how finely you split them. Two companies with identical security can produce very different control counts.
What do we do about separation of duties in a small team?
Document a compensating control and be honest about it. In a three engineer company, the person writing a change sometimes has to approve it. What auditors want to see is that the situation is recognized, that a second person reviews after the fact, and that the exception is not silent. A stated compensating control is treated very differently from a gap you did not mention.
Which items on this list take the longest?
Anything with a cycle inside the observation window: access reviews, training completion, vendor reviews and the penetration test with its remediation. Log retention also has to be extended before the window opens, because retention cannot be applied to logs already deleted. Start those first and leave the point-in-time items such as a tabletop or a restore test for later.
Do we need every policy on the list?
You need the coverage, not the file count. Combining access control, acceptable use and password requirements into one document is fine. What fails is missing a topic entirely, most often vendor management, data retention or risk assessment, which small companies tend to leave out because no one has asked for them before.