SOC 2 Compliance Checklist for IT Teams (PDF + Excel)

A SOC 2 compliance checklist lists the controls an auditor expects to test, and the proof that they ran. This one has 69 controls in 12 areas. Each control is tagged with the Trust Services Criteria it supports and comes with the evidence auditors sample. The PDF and Excel versions add an owner and a frequency to each control.

It is written for the people who carry most of the work: IT managers, sysadmins, engineering leads and MSPs at SaaS and service companies. The endpoint and offboarding sections go further than most checklists, because that is where IT teams often pick up Type 2 exceptions.

Download the checklist as a printable PDF and an Excel tracker with a dashboard and an evidence log, or work through it below.

Download the SOC 2 checklist (PDF + Excel)

TL;DR

What SOC 2 actually requires

If you already know the Trust Services Criteria and the difference between Type 1 and Type 2, skip to the checklist.

SOC 2 is an examination of a service organization's controls, performed by a licensed CPA firm under the AICPA attestation standards. The result is a report your customers read during security review. There is no SOC 2 certificate, and no list of mandatory controls. For the full background, see our guide to SOC 2 compliance.

The report is built on the 2017 Trust Services Criteria, with revised points of focus from 2022. The criteria cover five categories:

• Security, the common criteria CC1 to CC9. Always in scope.
• Availability (A1), if you commit to uptime or recovery.
• Confidentiality (C1), if you hold data you promised to keep confidential.
• Processing Integrity (PI1), if customers rely on your processing being complete and accurate.
• Privacy (P1 to P8), if you collect personal information under your own privacy notice.

Many first reports cover Security alone, or Security plus Availability and Confidentiality. Ask your largest customers what they need before you add more.

Type 1 vs Type 2: which report, and when

A Type 1 report tests whether your controls are designed well as of a single date. A Type 2 report tests whether they worked over a period, usually 3 to 12 months. Enterprise buyers usually ask for a Type 2. Our comparison of SOC 2 Type 1 vs Type 2 goes deeper.

The cost and time figures above are estimates from audit firms and compliance vendors, not AICPA rules. Your own staff time is often the larger cost.

Reports do not expire, but buyers expect a fresh one. The AICPA sets no expiry date. In practice, customers expect a new Type 2 every 12 months, and a period that ended more than 6 to 12 months ago starts to look stale. A management-signed bridge letter covers the gap between the end of your last period and today.

Start here: a three-phase plan

Split the work by the observation window, because the auditor tests from day one:

• Readiness: in place and running before the window opens.
• Before the window: documented and tested, so it runs cleanly once the window starts.
• During the window: run, evidenced and fixed when something slips.

In the Excel tracker, filter the Phase column to see each list. Give every item a named owner and a due date before you start.

SOC 2 controls list: what the criteria actually ask for

There is no official SOC 2 controls list. The AICPA publishes criteria, and each company designs its own controls to meet them. The auditor then tests those controls. That is why two SOC 2 reports can contain very different control lists.

Security, the common criteria, is always in scope. It has 33 criteria in nine series:

The optional categories add more: Availability (A1, 3 criteria), Confidentiality (C1, 2 criteria), Processing integrity (PI1, 5 criteria), Privacy (P1-P8, 18 criteria). All five together come to 61 criteria. The checklist below turns them into 69 practical controls, each tagged with the criteria it supports.

SOC 2 policies

Auditors start with your policies, because each one is a promise they will test. A first report needs a set of written policies and plans. These are the ones IT usually owns, with a free template for each:

Edit every template to match what you actually do. A policy you adopt but don't follow becomes an exception.

The SOC 2 compliance checklist, by area

Here is the full checklist. Start with the items marked "readiness". Core controls support the common criteria, which are always in scope. Recommended controls are not named in the criteria, but they make a criterion much easier to evidence. "If in scope" applies only when you add that category.

Scope and governance (6 controls)

Scope decides how much work everything else takes. Keep the boundary tight: the product customers buy, and the people and systems that run it.

Risk assessment (4 controls)

The risk assessment is where auditors start. It should explain why you chose the controls in the rest of this list.

Policies and people (7 controls)

Policies tell the auditor what you promised to do. Every line you adopt from a template becomes something they test, so cut what you will not run.

Identity and access (9 controls)

Identity is a common source of IT exceptions: access that outlived a leaver, and reviews that slipped. Pair this section with our IT offboarding checklist.

Endpoints and devices (11 controls)

Most SOC 2 checklists barely mention devices, yet laptops are a common source of Type 2 exceptions. The criteria do not name products. They ask that devices be inventoried, protected and controlled (CC6.1, CC6.7, CC6.8, CC7.1), and auditors test that across the window.

The inventory is the population. Auditors sample from your device list. A laptop missing from it is a laptop nobody can prove was encrypted, so enroll devices before first use and reconcile the list against HR and purchasing.

Personal devices are allowed if your policy says what they need and you can show they meet it. Most teams either keep customer data off personal devices or require a work profile and a passcode. If you allow contractors' own laptops, write down how you check them.

Vulnerabilities and patching (4 controls)

The 2022 points of focus added patch management to change management (CC8.1). Show a written timeline and reports that meet it. See our guide to patch management.

Change management (4 controls)

Change management covers code and infrastructure, and also the configuration of your devices and tools.

Logging and monitoring (4 controls)

Monitoring covers both security events and the controls themselves. A control that silently stopped running is an exception waiting to be found.

Incident response (5 controls)

Write the plan before you need it, and test it once a year. Our data breach response plan template is a starting point.

Backup and continuity (4 controls)

Recovery from incidents is part of the common criteria (CC7.5), and continuity planning sits in CC9.1. Auditors expect backup, restore testing and capacity monitoring evidence if Availability is in scope. See our disaster recovery plan template.

Vendors (4 controls)

Your cloud provider and key SaaS tools are part of your system. Most reports carve them out and rely on their own SOC 2 reports, so read those reports and run the controls they expect from you.

Audit readiness (7 controls)

These items turn a working program into a report. Start the auditor conversation early: it shapes the window and the evidence format.

Offboarding that passes a Type 2 sample

Auditors pull every leaver in the window from HR, then compare the date and time access was removed with your policy window. One late removal is an exception. Work through the same six steps every time, and keep the timestamps:

1. HR records the leaver with the date and time.
2. Disable the identity in your identity provider, which ends single sign-on and MFA.
3. Remove apps outside single sign-on one by one.
4. Get the device back and wipe or unenroll it.
5. Rotate keys and shared secrets the person could reach.
6. Keep the evidence: removal timestamps next to the HR date.

If an auditor finds a leaver with access after the window, check apps outside single sign-on first. Shared accounts and tools bought on a credit card are where access survives.

Evidence over the window

A Type 2 auditor does not look at your systems on one day. They pull the full population for each control (every leaver, every change, every month of patching) and test a sample. A typical request list runs from 40 to 140 items.

Generate device reports on a schedule, not on request. A screenshot proves one moment; twelve dated monthly reports prove a control ran. The Excel tracker has an evidence log for exactly this.

What happens in a SOC 2 audit

A SOC 2 audit is an examination by a licensed CPA firm under the AICPA attestation standards. For a Type 2, it runs roughly in this order:

1. Scoping and kickoff. You and the CPA firm agree on the system, the categories in scope, the report type and the period. Ask for their evidence request list now.
2. The request list. The firm sends a list of what it needs, often called the PBC (provided by client) list: policies, populations, configurations and samples.
3. Populations and samples. For each control that runs repeatedly, you hand over the full population (every new hire, every leaver, every change in the period). The auditor picks a sample and asks for the evidence for each one.
4. Fieldwork. Walkthroughs, inspection of evidence and follow-up questions. For a Type 2, this usually takes a few weeks after the period ends.
5. Management's assertion and the system description. You write the description of your system and sign management's assertion: that the description is fairly presented and the controls were suitably designed and, for a Type 2, operated effectively.
6. The opinion and the report. The auditor issues an opinion: unqualified (clean), qualified, adverse, or a disclaimer. Exceptions found in testing are listed even in a clean report, and you can add a management response.

SOC 2 audit checklist for the week before fieldwork:

• Every policy approved, dated and published to staff.
• Populations ready to export: new hires, leavers, access changes, code and configuration changes, incidents, vendors.
• Monthly device reports for the whole period: inventory, encryption, OS versions and patching.
• Quarterly access review sign-offs, with what was removed.
• The risk assessment, vendor reviews and the last incident response test.
• One owner for the auditor's questions, and a shared folder that mirrors the request list.

Most delays come from evidence that can't be produced for a sampled date. Collect it as you go, using the evidence log in the Excel tracker.

Common mistakes that create exceptions

• Adopting template policies you don't follow. The auditor tests what the policy says, not what you meant.
• Treating a compliance tool as the control. Tools collect evidence. The controls are still yours to run.
• Offboarding that stops at single sign-on. Tools outside your identity provider are where former staff keep access.
• Quarterly reviews that slip to "when we get to it". Put them on a calendar with a named owner.
• Calling it a certification. Say "we have a SOC 2 Type 2 report", and share it under NDA.

For MSPs and IT providers

If you manage IT for clients, two questions come up. First, clients going through their own SOC 2 will treat you as a vendor: expect security questionnaires and requests for your report (CC9.2). Second, if you pursue your own report, your management tools and client access are in scope. Keep each client's devices, admins and evidence separate, so you can answer one client's auditor without exposing another. See trio.so for MSPs.

What changed in 2026

What did change is scrutiny. The AICPA guided peer reviewers to look harder at SOC 2 engagements, and buyers now ask which firm signed a report. Choose a licensed CPA firm enrolled in peer review.

Get the PDF and Excel tracker

How trio.so helps with the endpoint controls

trio.so covers many of the device controls in this checklist from one console:

• Inventory: hardware, software and OS versions for every enrolled device, including Linux (DEV-01, VULN-04).
• Encryption: enforce BitLocker on Windows and FileVault on Mac, and see encryption status for every device (DEV-03).
• Passcodes and screen lock: on Windows, macOS, iOS and Android (DEV-04).
• Patching: enforce OS updates on Windows, macOS, iOS and Android, with vulnerability findings scored by CVSS, EPSS and CISA KEV (VULN-01, VULN-02).
• Configuration: firewall and USB rules on Mac and Windows, app allow and block lists, and compliance checks against a baseline (DEV-06 to DEV-08).
• Lost and returned devices: lock lost Macs, iPhones and Android devices, locate phones, and wipe or unenroll company-owned devices (DEV-10, DEV-11).
• Records: an admin event log that shows who changed what, and when, with export (CHG-04).

SOC 2 stays your program: the policies, reviews, vendor checks and the audit are yours to run. What trio.so gives you is control of many of the device settings this checklist asks for, plus the device reports that show they are working. Learn more about compliance automation.

Start free trial Book a demo

14 day free trial. No credit card required.

Sources. Last reviewed October 2026. This article is guidance; your auditor decides what evidence satisfies each criterion.

• AICPA & CIMA: 2017 Trust Services Criteria, revised points of focus (2022)
• AICPA & CIMA: SOC 2 overview
• AICPA & CIMA: SOC 2 Description Criteria (DC 200)
• AICPA & CIMA: SOC 2 guide (October 2022 edition)
• Journal of Accountancy: Auditing Standards Board proposes attestation changes, Feb 2026
• Journal of Accountancy: AICPA guides peer reviewers to address SOC 2 risks, May 2026