SOC 2 checklist for a first audit

The full checklist is on this page. Work top to bottom and every item names the artifact an auditor will ask you to produce.

Last reviewed 2026-08-16Written by Jacob Masse, TrazTech Inc.

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, because the artifact is what the audit actually turns on. Work it in order, since 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.

1. Scope and planning

Written system description naming the product, environments and data in scope. Artifact: a one page document, dated.
Explicit list of what is out of scope and why. Artifact: same document.
Decision on Trust Services Criteria, with the reason for each one beyond security. Artifact: written decision, ideally minuted.
Decision on Type 1 or Type 2 and the intended observation window dates. Artifact: written plan.
Named owner for the program, with time allocated. Artifact: a role description or a management approval.
Current organization chart and a list of everyone with production access. Artifact: export from your identity provider.

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.

Information security policy, approved by management. Artifact: signed or otherwise recorded approval.
Access control policy covering provisioning, review and revocation.
Change management policy covering review, testing and approval of code and infrastructure changes.
Incident response policy with severity levels, roles and notification duties.
Business continuity and backup policy, including restore expectations.
Vendor and third-party management policy with a review cadence.
Data classification and retention policy naming how long you keep what.
Risk assessment policy describing how often you assess and who reviews it.
Acceptable use policy covering company devices and accounts.
Secure development policy covering code review, dependencies and secrets.
Human resources security policy covering hiring, training and offboarding.
Annual review of every policy above, with the date recorded. Artifact: version history.
Employee acknowledgement at hire and annually. Artifact: timestamped records for every person.

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 realistically 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.

3. Access control

Single sign-on in front of every system that supports it. Artifact: application list from the identity provider.
Multi-factor authentication enforced for all staff, with no standing exceptions. Artifact: policy configuration screenshot and an enforcement report.
Unique named accounts, no shared logins. Artifact: user list.
Documented approval for every grant of production access. Artifact: ticket or email trail per grant.
Access reviews at your stated cadence, covering production, cloud accounts, code repositories and the identity provider. Artifact: the review record showing reviewer, date, and any access removed.
Privileged access limited to a defined small group, with a list of who and why.
Password requirements enforced by configuration rather than by policy text alone.
Secrets stored in a managed secret store, not in code or in shared documents.
Offboarding removes all access within your stated time limit. Artifact: a completed checklist per departure with timestamps.

4. Change management

All production changes go through version control. Artifact: repository history.
Peer review required before merge, enforced by branch protection rather than by convention. Artifact: branch protection settings plus a sample of merged pull requests.
Automated tests run in the pipeline before deployment. Artifact: pipeline configuration and a sample of runs.
Separation between the person who writes a change and the person who approves it, or a documented compensating control if your team is too small.
Infrastructure changes managed the same way as application changes.
Documented rollback approach, and evidence of a real rollback if one happened.
Emergency change process, with the after-the-fact approval recorded when it is used.

5. Infrastructure and monitoring

Encryption in transit for all external traffic. Artifact: configuration and a scan result.
Encryption at rest for databases, object storage and backups. Artifact: cloud configuration screenshots.
Centralized logging with retention that exceeds your observation window. Artifact: retention configuration.
Alerting on defined security events, routed to a person who is actually on call. Artifact: alert rules and a sample of alerts that fired.
Vulnerability scanning on a stated cadence, with findings tracked to closure. Artifact: scan reports and the remediation tickets.
Dependency scanning in the pipeline. Artifact: tool configuration and sample output.
Patch management with a defined timeline by severity. Artifact: a sample of patches applied inside the stated window.
Endpoint protection and disk encryption on every company device. Artifact: device inventory with compliance status.
Network controls: security groups reviewed, no unintended public exposure. Artifact: configuration review record.
Independent penetration test with a remediation plan for the findings. Artifact: the report and evidence of fixes.

6. Vendors and subprocessors

Vendor register listing every third party that touches customer data, what it does, and the data it sees. Artifact: the register itself, dated.
Risk rating per vendor, with a stated basis. Artifact: the register.
Security review of critical vendors, usually their SOC 2 or ISO 27001 report. Artifact: the report on file plus a note of what you reviewed in it.
Signed agreements with data protection terms for anyone processing personal information on your behalf. Under PIPEDA accountability stays with you when data moves to a processor, so the contract matters legally and not only for the audit.
Annual re-review of vendors at your stated cadence. Artifact: dated review records.
Offboarding process for vendors, including data return or deletion.

7. People

Background checks for new hires where lawful and proportionate. Artifact: completion record per hire after your start date.
Signed confidentiality agreements for employees and contractors. Artifact: signed copies.
Security awareness training at hire and annually, with completion tracked. Artifact: per-person completion records with dates.
Role-based training for engineers on secure development, if your policy commits to it.
Documented onboarding checklist covering account creation, device issue and training.
Documented offboarding checklist covering access removal, device return and final acknowledgement.

8. Incidents, risk and resilience

Incident log that exists before you need it, including the incidents you decided were minor. Artifact: the log.
At least one incident response exercise inside the observation window. Artifact: tabletop notes with attendees and date.
Documented customer and regulator notification duties. If personal information is involved, PIPEDA requires reporting breaches that create a real risk of significant harm, and keeping a record of every breach for 24 months regardless.
Backups configured, with the schedule and retention documented.
A tested restore, not just a configured backup. Artifact: restore test record with date and result.
Business continuity or disaster recovery plan with stated recovery objectives.
Annual risk assessment identifying risks, owners and treatment decisions. Artifact: the assessment document, reviewed by management.
Management review of the security program at a stated cadence. Artifact: meeting notes.

9. Evidence readiness

A control list mapping each item above to the evidence that proves it and the person who owns it.
A folder structure by control, with a date-first naming convention.
Recurring calendar entries for every periodic control, with a named owner rather than a group.
Screenshots that show the date, the system and the account in frame.
Exports preferred over screenshots wherever the system can produce one.
A population list for anything sampled, such as all hires, all terminations, all changes in the period. Auditors sample from your list, so the list has to be complete.
Evidence in place from day one of the window, not from the day you remembered.

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

Every item above either complete or on a written plan with a date.
A readiness assessment or an internal equivalent, confirming an auditor would accept what you have.
Audit firm engaged and fieldwork dates booked. Canadian firms are often booked a quarter ahead, so this happens before the window closes rather than after.
System description drafted, since it is your text in the final report.
A named internal point of contact for auditor requests, with time reserved during fieldwork.

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 is the whole thing and it stays on this page. If a printable version with an owner column, a status column and an evidence column per item is useful, tell us where to send it.

Send me the tracker

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.