SOC 2 Compliance Checklist: Every Essential Task

A SOC 2 compliance checklist is the working sequence for earning a System and Organization Controls 2 report and keeping it current: nine steps, from setting your objective through the audit to continuous monitoring. The 2017 Trust Services Criteria, still current in September 2026, make Security the only mandatory category. Each step below names the evidence that satisfies it and why auditors send it back.

That second half is where first audits lose weeks. The control works and the policy exists, and the proof still comes back because it has no timestamp, was rebuilt after the period closed, or reads as a template instead of a description of your company.

What is a SOC 2 compliance checklist?

A SOC 2 compliance checklist acts as a guide for getting from no controls to a signed SOC 2 report, and keeping it. There is no official version per se. The American Institute of Certified Public Accountants (AICPA) publishes the Trust Services Criteria and the description criteria (what a system description must contain), and every checklist is an interpretation of those.

The criteria in force are still the 2017 Trust Services Criteria with revised points of focus from 2022, with no newer edition as of September 2026; points of focus are the AICPA’s guidance on what each criterion looks for. The report itself is an attestation, an independent certified public accountant (CPA) firm’s opinion on how your controls meet the SOC 2 requirements, and it’s the end point of the wider SOC 2 compliance program.

Who should own the SOC 2 checklist?

Ideally, one person should own the checklist. It is usually a compliance manager, IT manager, head of engineering, security lead, or a founder wearing the compliance hat. That person runs the program and coordinates the auditor. Evidence comes from across the company, so every item needs its own named owner, a frequency, and a known place where its proof lives.

Most of that evidence comes from six areas of your business. Here’s who usually owns each one and what they hand over:

Area	Typical owner	What they provide
Scope, report type, auditor	Security lead or founder	Scope statement, criteria, engagement letter
Cloud and production	Engineering or DevOps	Configuration, logging, backup and vulnerability evidence
Code and change management	Engineering	Pull request approvals, deployment records
Identity and access	IT or security	Multi-factor authentication (MFA) coverage, access reviews, offboarding records
People	HR	Background checks, policy acknowledgments, training records
Vendors	Security or procurement	Vendor inventory, reviews, contracts, vendor SOC 2 reports

What are the 9 steps in a SOC 2 compliance checklist?

You set your objective, choose Type 1 or Type 2, define scope, assess risk, close gaps, implement and test controls, run a readiness review, complete the audit, and monitor continuously. These are pretty much the 9 steps involved in achieving SOC 2 compliance.

Now, let’s look at each step, understand what it involves, and the most common reason the auditor sends it back:

#	Step	What satisfies it	Why it commonly gets sent back
1	Set your objective	A one-sentence reason the team can see	NA
2	Choose Type 1 or Type 2	A signed engagement letter naming type, criteria and period	NA
3	Define your scope	A system description plus a scope statement naming exclusions	Reads as a template, or leaves out a system in your own architecture diagram
4	Run a risk assessment	A risk register with scores, rationale, owner, treatment and review date	Scores with no rationale, or no review inside the period
5	Run a gap analysis	A remediation register tying each gap to a criterion, owner, date and closure evidence	The auditor doesn’t test the register itself; a gap left open here usually becomes an audit exception
6	Implement and test controls	Dated evidence per control from the system of record	Undated screenshots, backup logs instead of restore tests, settings with no named users
7	Run a readiness review	A control matrix and a readiness assessment with findings and closures	The auditor doesn’t test it; skip it and the auditor finds your exceptions before you do
8	Complete the audit	Full population lists plus the samples the auditor picks	An issue closed past your own remediation deadline with no written explanation
9	Monitor continuously	Evidence that accumulates as controls run, filed by control	A control that passes in month one and drifts in month three

Steps 3, 4, 6, and 9 produce the records the auditor examines. Steps 1, 2, 5, and 7 are decisions and internal reviews the auditor doesn’t test, and step 8 is the audit itself.

1. Set your objective

Decide why you’re doing the SOC 2 audit. That will shape the rest of the process. A buyer who needs a report this quarter will point you to a Type 1 and a tight scope; a board that wants a lasting program will likely ask for a Type 2 report and continuous monitoring.

Consider who is asking, what they expect to see, and how soon they need it, then write the reason in one sentence where your project team can see it. If nobody is asking yet, you have the rare chance to do this properly before a deal sets the timeline.

2. Choose Type 1 or Type 2

A Type 1 report gives an opinion on whether your controls were suitably designed as of a single date. A Type 2 adds an opinion on whether they operated effectively throughout a period, the observation window, as the Journal of Accountancy sets out. Procurement teams usually ask for the Type 2 by name, because it’s the one that shows your controls kept working over time.

Let’s look at how the two reports differ:

What’s compared	Type 1	Type 2
The opinion covers	Suitability of design as of a date	Design plus operating effectiveness throughout a period
Recurring controls such as access reviews	The process exists and is designed to meet the criteria	Every run your policy promises happened inside the window
Best fit	A named deal needs a report this quarter	Buyers want proof your controls held up over time

Type 1 isn’t a prerequisite, and your Type 2 window can open the day after a Type 1 report date. If you are doing both, that means two engagements and two fees. Better to ask your CPA firm what a Type 1 costs if you also buy the Type 2, and weigh whether a Type 1 is worth doing at all.

In our conversations with buyers, the choice often comes down to whether they have customers in waiting. Teams with an enterprise deal waiting on a report take a Type 1 first and keep the Type 2 as the goal. While some teams without that pressure go straight to a Type 2 to avoid paying for two audit rounds and set a longer observation window.

3. Define your scope

Your report covers the system you describe, which is rarely your whole company, so defining your SOC 2 scope comes first. Four boundaries decide where the line falls:

• Criteria: Security always, plus the optional criteria your commitments call for, covered in the criteria section below.
• Assets: Tag production cloud accounts, repositories, customer-data stores, identity providers, logging, build pipelines, and backup systems as in or out, so you can quickly rule in or out a vulnerability on a non-production asset.
• Contracts: Review your security addenda, service level agreements (SLAs), questionnaire answers, and trust center claims. If a contract promises uptime and Availability is out of scope, be ready to explain how you govern it outside the report.
• Vendors: For each critical vendor, keep the owner, risk tier, review dates, and its SOC 2 report, and document the complementary user entity controls (CUECs) its report says you must run.

If you run several products, you can scope the report to one. Shared company processes still apply because they support the in-scope product: access provisioning, change management, onboarding and offboarding, and vendor oversight. One report can also cover several products if the system description names each one.

Contractors generally count, because scope tends to follow access more than employment status, and staging environments are usually in scope if they hold customer data.

Write the result down in two documents. The scope statement lists the criteria, the in-scope systems, and each exclusion with its reason. The system description is the part of the report that describes your system, and the AICPA’s description criteria (DC 200) set what it must cover, including your services, your commitments to customers, the system’s components, subservice organizations, and CUECs.

You need to ensure you get the audit’s scope, purpose, and criteria right. This will make the later steps straightforward because you’ll always collect evidence for the right systems.

4. Run an internal risk assessment

A SOC 2 risk assessment lists what could go wrong in the system you scoped in step 3. It scores each risk and records what you’ll do about it. You keep it in a risk register, either a spreadsheet or the risk module of a compliance platform. Auditors ask for it early, because criteria CC3.2 to CC3.4 test whether you identify risks, consider fraud, and reassess risks when something changes.

Build the list from four sources:

• Your asset inventory: For each in-scope asset from step 3, ask what would happen if its data leaked, was altered, or became unavailable. A production database alone gives you several risks: a leaked backup, a compromised admin account, data lost in a failed migration.
• People and fraud: CC3.3 asks you to consider fraud, so include insider risks, such as an engineer who can approve their own changes to production or an employee who leaves with a copy of customer data.
• Vendors: Add a risk for each critical vendor, such as a cloud host outage or a subprocessor breach.
• Changes: CC3.4 asks you to reassess when something significant changes, such as a new product, an acquisition, a new cloud provider, or a new AI feature.

Next, choose a scoring method and write it into the register. Most SOC 2 teams use the first of these three methods; the other two suit specific needs:

Method	How it scores a risk	Best suited to
Qualitative matrix	Rates likelihood and impact on a scale, often 1 to 5, and multiplies them for a score out of 25	Most first SOC 2 programs, because it’s quick and auditors know it well
Semi-quantitative	Uses the same scale, but ties each value to a defined range, such as likelihood 4 meaning “about once a year” and impact 4 meaning “$100,000 to $500,000 in losses”	Teams that want different reviewers to score the same risk the same way
Quantitative	Estimates in dollars how often a loss is likely and how much it would cost, using a model such as Factor Analysis of Information Risk (FAIR)	Teams that need to justify security spending to a board or finance lead

NIST Special Publication 800-30 Rev. 1 describes all three approaches. The AICPA doesn’t require any one in particular; auditors check that you apply the one you chose consistently.

For each risk, record the score and the reasoning behind it, the control that reduces the risk, an owner, the treatment decision (reduce, share, accept, or avoid), and a review date. A register where every risk scores 3 and is accepted with no reasoning is the version auditors push back on.

5. Perform gap analysis and remediation

Compare your current controls, policies and evidence against the criteria you scoped, using the 18-item controls table in step 6 as your starting list. Record each gap in a remediation register, either a spreadsheet or your compliance platform’s issue tracker, with the criterion, the fix, the owner, a due date and the artifact that will prove it’s closed.

Count a control as a gap if it’s written down but not run every time, or if nobody checks that it ran. These are harder to spot than missing controls, because the policy exists and the process usually works.

For a gap like this, the fix is a named owner and a record for every run, such as a completed onboarding checklist for each new hire, so you can show the control operated each time.

Add dates to every closure. Without dates, a gap you closed before the window opened looks the same as one still open inside it.

6. Implement controls and test them

Put in place what the gap analysis found, then test that each control works the way your policy says it does. If the policy says access reviews happen quarterly, you need to show the completed quarterly review reports. For a Type 2, the auditor tests operations across the whole window, so a documented process counts for little without evidence that it ran.

Here’s what decides whether a working control also passes: how often it runs, how deep it goes, and whether its owner can prove it with dated evidence.

The Trust Services Criteria don’t specify cadences. CC7.1 expects you to find vulnerabilities, and your policy sets how often you scan and test, so that’s the cadence the auditor tests against.

Deadlines for fixing vulnerabilities work the same way. Your vulnerability management policy sets how many days each severity level has to be fixed, and the auditor checks every finding in the period against that deadline. Set deadlines your team already meets, with shorter ones for internet-facing systems.

On depth, removing someone from Okta or Microsoft Entra ID ends their single sign-on (SSO) access, and auditors may still ask how you review access inside critical applications, databases and cloud consoles.

Many findings at this step come from people and integrations: an endpoint agent uninstalled months ago, an employee back from leave who never finished training, a departed engineer’s account kept alive because it owns a shared calendar. Evidence commonly comes back for three reasons:

• Screenshots with no timestamp: Auditors routinely ask for a dated export instead.
• Backup logs where restore evidence was asked for: A backup log shows a copy exists; a restore record shows you got the data back, which is what the Availability criteria at A1.2 and A1.3 are about.
• Settings with no examples: An auditor who can see MFA is enforced will often ask you to show it for named users, which is ordinary sampling: the auditor picks a few examples from the full list and tests those.

SOC 2 controls checklist: 18 items with evidence

These 18 items follow the Security common criteria, CC1 to CC9, so they double as a folder structure for your evidence. Codes are at series level; your auditor maps each item to sub-criteria, which the SOC 2 controls list sets out one by one.

Go through the table below row by row. If you can’t produce the evidence in the fourth column for the whole period, that control is a gap:

#	Control item	Criteria	Evidence that proves it	Commonly pushed back when	Owner
1	Approve and publish security policies	CC1, CC2, CC5	Versioned, approved policies; acknowledgment log	Approved mid-period, overdue for review, or new hires with no acknowledgment	Security lead
2	Document roles and leadership oversight	CC1	Dated org chart, job descriptions, leadership minutes	Minutes show a meeting, not what was reviewed or decided	Leadership, HR
3	Screen people before access	CC1	Background check confirmation per hire	Contractors skipped, or check finished after access was granted	HR
4	Train everyone on security	CC1, CC2	Training export with person, module and date	Late new hires, self-reported completion, people on leave never handled	HR
5	Track control health and fix deficiencies	CC4	Deficiency log with detection, owner and fix dates	A failure with no record of who noticed it or how it was fixed	Security lead
6	Approve access before granting it	CC6	Access tickets matched to each system’s user list	A user with no ticket, a late approval, or self-approval	IT
7	Remove access when people leave	CC6	Leaver list matched to deprovisioning timestamps	Removal later than policy allows, or a leaver active outside SSO	IT, HR
8	Review access, including admins	CC6	Dated review per system with per-user decisions	A single “no changes” sign-off, or admin and service accounts left out	System owners
9	Enforce MFA	CC6	Identity provider export showing coverage; exceptions list	A settings screenshot with no user coverage, or undocumented break-glass (emergency admin) accounts	IT
10	Encrypt data in transit and at rest	CC6	Dated configuration exports per data store	Evidence for one database when the inventory lists several	Engineering
11	Manage endpoints	CC6, CC7	Endpoint detection and response (EDR) or device report per device	Device count doesn’t match headcount, or encryption off	IT
12	Cover physical access or document who does	CC6	Badge logs, or a carve-out (the data center’s controls are left to its own report) plus your review of that SOC 2 report	Carve-out claimed, provider report never reviewed	Security lead
13	Find and fix vulnerabilities	CC7	Scans across the period, remediation tickets, pen test follow-up	Critical findings past your deadline with no approved exception	Engineering
14	Log, monitor and respond to alerts	CC7	Logging config, alert rules, triaged alert samples	Alerts nobody looked at, or logs kept shorter than policy says	Engineering
15	Run and test incident response	CC7	Plan, incident tickets or a no-incident record, tabletop exercise (a walk-through of a mock incident)	Plan never tested, or incidents handled in chat with no ticket	Security lead
16	Back up and prove you can restore	CC7, CC9; A1 if in scope	Backup logs, restore tests, disaster recovery (DR) test report	Backups configured, no restore ever tested	Engineering
17	Control changes to production	CC8	Pull requests approved by a non-author, branch protection (rules that block unreviewed merges), deploy logs	Self-approved merges, direct pushes to main, unreviewed emergency changes	Engineering
18	Manage vendors	CC9	Tiered inventory, reviewed vendor reports, CUEC mapping	Vendor reports collected, never reviewed	Security, procurement

8. Complete the audit

An independent CPA firm tests your controls, samples your evidence and issues the report. Choose the SOC 2 audit firm on AICPA peer review (the AICPA’s periodic check on a CPA firm’s audit quality) as well as price: a firm newly enrolled in the AICPA Peer Review Program ordinarily has 18 months to complete its first review, so enrollment alone doesn’t show that anyone has checked its work. Ask for the current peer review report and state license number before you sign.

That check matters more in 2026. The Journal of Accountancy carried a warning on February 1, 2026, that tool vendors promising fast, cheap reports may pressure CPA firms to check the box. On May 14, 2026, it reported a Peer Review Board alert telling reviewers to compare a firm’s SOC 2 engagements for identical risk assessments, control designs, sample sizes, and testing procedures.

If a firm offers you a pre-written risk assessment or control set, treat that as a warning sign.

A small side quest worth doing: before you sign, ask the firm which evidence formats it accepts from your platform’s exports.

Some requests need documents your team produces by hand, such as background-check reports, performance reviews, and the DR test report. Some auditors also ask for a live screen-share of the source system. When the auditor asks about a population (every instance of something in the period, such as every new hire), provide the full list; the auditor picks the samples and sets the sample size.

The common push-back here is an issue closed after your policy’s deadline with no written explanation. If your policy says high-severity issues close in 30 days, a miss becomes a testing exception, the auditor’s record of a control that didn’t work as described, and it needs a management response.

You can’t fail a SOC 2 audit the way you fail an exam, but a report can carry a qualified opinion (the auditor has a reservation about some controls), an adverse opinion (the problems are serious and widespread), or a disclaimer (the auditor couldn’t gather enough evidence to form an opinion). A buyer reads any of those as a failure, because each one says the auditor couldn’t fully rely on your controls.

9. Establish continuous monitoring

The report covers a fixed period, while the system behind it keeps changing: people leave, vendors get added, and evidence goes stale. From the second cycle, teams usually move to a 12-month window. Continuous compliance means seeing a failure when it happens: which control drifted, when, who owns the fix, and whether to log it as an exception.

To run it, keep one list of every control with its owner, frequency, and where its evidence is filed, and review failures on a fixed cadence, such as monthly, so you is each drift or log it as an exception while the window is still open.

Worth knowing: plan the second audit while you prepare the first. If you want continuous coverage, your next observation period starts the day after the last one ends, so you’re already weeks into year two when your first report arrives.

What evidence counts inside the observation window?

For a Type 2, operating evidence dated outside your observation window doesn’t count, and that applies both ways: work finished after the window closes is as invisible to the auditor as work done before it opens.

Point-in-time records are the exception. A background check done when someone joined years ago isn’t tested again, because the auditor samples people hired during the window.

The rule applies to controls tested over the period, such as access reviews, change approvals, monitoring, training, and incident handling. Teams call the window the observation period, audit period, or evidence collection period, and all three refer to the same dates.

The principle comes from the attestation standards SOC 2 engagements follow (AT-C sections 105 and 205), which ask the auditor to obtain sufficient appropriate evidence. A record created when the control ran is harder to dispute than one rebuilt afterward, so auditors ask for dated, system-generated records.

Two traps often catch teams off guard. The first is something like a fix made the week after the period ends: the auditor never sees it, so the exception stands.

The second trap is an annual control, such as management review, risk assessment, vendor review, or DR testing, that shows as passing while its last run sits before your dates. If it doesn’t run again inside the window, the auditor has no operating evidence for it, and your choices are to rerun it inside the window or lengthen the period until it falls inside, which moves your report date.

So before you fix your window dates, check that every periodic control has produced evidence inside them, and check again before the window closes. For tools you can’t integrate, manual exports still work as SOC 2 evidence if they carry the same attributes.

How do you choose your Trust Services Criteria?

Security is mandatory in every SOC 2 report and is the first of the five Trust Services Criteria. Availability, Confidentiality, Processing Integrity and Privacy are optional; add each one when a buyer, a contract or your own published commitments call for it. Each criterion you add expands the evidence you hold for the whole window, so choose by commitment.

Here’s when each criterion belongs in your report and what it adds to the evidence you collect:

Criterion	When to add it	What it adds	Commonly sent back when
Security, mandatory	Always	CC1 to CC9: control environment; communication and information; risk assessment; monitoring activities; control activities; logical and physical access; system operations; change management; risk mitigation, covering business disruption and vendors	See the 18-item table in step 6
Availability, A1	You’ve committed to uptime or an SLA	Capacity monitoring, recovery plans with recovery time and recovery point targets (how fast you’re back, and how much data you can lose), restore and DR tests	Uptime promised but never measured, or recovery targets never tested
Confidentiality, C1	You hold information under non-disclosure agreements (NDAs) or confidentiality terms	Data classification, protected stores, disposal on schedule	No classification scheme, or disposal with no deletion records
Processing Integrity, PI1	Accuracy is the product: payments, payroll, tax or billing	Processing specifications, input controls, reconciliation	Outputs never reconciled, or errors with no correction record
Privacy, P1 to P8	You handle personal information and have made commitments about it	Notice, consent, collection, retention, access, disclosure, quality, monitoring	A privacy notice that doesn’t match what you collect

Encrypting personal data and enforcing MFA are Security controls under CC6, so they don’t bring Privacy into scope. The AICPA’s criteria apply Confidentiality to many kinds of sensitive information and Privacy only to personal information.

Can you run a SOC 2 checklist manually, or do you need a platform?

You can run it manually when three things are true: someone’s job is compliance, your stack is small enough that pulling evidence by hand takes a day instead of a week, and you aren’t planning a second framework. A spreadsheet handles steps 1 to 5 well. It struggles with steps 6 and 9, where evidence builds up over months.

The two approaches split at the stages where evidence has to be collected on a schedule:

Checklist stage	Spreadsheet	Compliance platform
Steps 1 to 5: objective, report type, scope, risk and gap registers	Works; these are documents	Works; adds mapping to criteria
Steps 6 and 9: operating evidence and drift	Records what you did, can’t notice a control that stops passing	Checks controls as they run and flags drift
Where it fails	Evidence rebuilt by hand just before the auditor starts testing	An auditor who won’t accept platform exports

What should SOC 2 automation do?

Good SOC 2 automation runs the program between audits. Look for scoping and control mapping with named owners, continuous monitoring that flags stale evidence and drift, remediation routed to the right owner with the trail kept, and evidence in a format your audit firm has agreed to accept. To judge a SOC 2 automation tool, change the system underneath a piece of evidence during a trial and see whether the tool notices.

Can one checklist cover both SOC 2 and ISO 27001?

Partly. Access control, change management, risk assessment, vendor management, incident response, and security training appear in both, so your SOC 2 controls and their evidence carry over. What doesn’t carry over is the information security management system (ISMS) that ISO 27001 requires around them: a Statement of Applicability (the list of ISO controls you apply, and why), an internal audit under clause 9.2, and a management review under clause 9.3.

If a buyer has asked for both, understand the overlap between SOC 2 and ISO 27001 before you fix your scope.

How does Sprinto help you run SOC 2 continuously?

Sprinto is an Autonomous Trust Platform that checks your controls against your connected stack, shows what’s passing and what has drifted, and alerts you while there’s still time to fix it. The repetitive work runs without you. The decisions that require judgment, including which CPA firm audits you, stay with you and your team.

Here’s more on how Sprinto helps you run the checklist:

• Continuous monitoring: Checks run continuously against your connected stack, so a control that passes in month one and drifts in month three is flagged in month three, not during the audit.
• Evidence organized by control: Evidence from your connected systems is checked for completeness and freshness and filed against your controls, so the library is assembled when your window closes, and you can preview what your auditor will see before the audit starts.
• Support through your first audit: An industry expert works alongside your team from onboarding through your first audit on one framework.
• Your auditor, your contract: Choose from the audit partner network or bring your own firm, and pay the audit fee to the CPA firm directly, with no markup. Sprinto does not share revenue with audit firms.