SOC 2 Compliance Checklist: What IT Managers Need to Know

SOC 2 has become the de facto trust credential for B2B SaaS companies, IT service providers, and cloud platforms in 2026. Enterprise clients request it during procurement, security questionnaires ask for it, and deals stall without it. If you manage IT for an organization that sells to mid-market or enterprise buyers, the question is no longer whether you need SOC 2 — it's how to get there without losing a year to confusion about where to start.

The genuine complexity is real: five Trust Service Criteria, 32 Common Criteria across nine control categories, an observation period measured in months, and a set of documentation and operational requirements that many IT teams underestimate when they first hear "we need SOC 2." The framework is rigorous by design — it is built to produce evidence that verifiable controls are operating continuously, not a snapshot of security posture assembled before an auditor arrives.

This guide delivers a practical, phase-by-phase SOC 2 readiness checklist covering everything from initial scoping through audit completion and ongoing compliance — including all 32 Common Criteria, required policies, the Type I vs Type II decision, and the recurring tasks that keep your report current year after year.

What Is SOC 2?

SOC 2 (Service and Organization Controls 2) is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) that evaluates whether a service organization's controls related to security, availability, processing integrity, confidentiality, and privacy are suitably designed and/or operating effectively. It applies to any organization that stores, processes, or transmits customer data on behalf of other businesses — cloud platforms, SaaS providers, IT managed service providers, data processors, and similar service organizations.

A SOC 2 report is produced by a licensed CPA firm after a formal audit. It describes the organization's systems and controls and provides the auditor's opinion on whether those controls meet the Trust Services Criteria. It is not a certification — it is an audit report with an opinion. Enterprise buyers request SOC 2 reports (usually Type II) as evidence that a vendor takes security seriously and has verifiable controls in place. Only licensed CPA firms can issue SOC 2 reports; security consulting companies that are not licensed CPAs cannot.

Enterprise security questionnaires routinely ask for SOC 2 reports. Sales cycles for mid-market and enterprise SaaS deals routinely stall on "send us your SOC 2." Cyber insurance underwriters use it as a risk indicator. Regulated industries — financial services, healthcare — may require it as a vendor qualification criterion. For any IT services organization selling to mid-market or enterprise buyers, SOC 2 Type II has moved from a differentiator to a table-stakes requirement.

SOC 2 Type I vs Type II — Which Do You Need?

The Type I / Type II question is the first question almost every IT manager asks, and the answer directly determines your timeline and budget.

A SOC 2 Type I report evaluates whether your security controls are suitably designed as of a specific date. The auditor examines your policies, procedures, and control configurations and forms an opinion on whether, in theory, those controls would operate to meet the Trust Services Criteria. Type I can typically be completed in 2–4 months from the start of readiness work. It is the faster, lower-cost option — external audit fees typically range from $7,500 to $25,000. Type I is a useful bridge when you need a report quickly to unblock a deal, or as a validated first step before committing to a Type II observation period.

A SOC 2 Type II report evaluates whether your controls were actually operating effectively over a defined observation period — typically 6 to 12 months. The auditor tests evidence that controls ran as described during the observation window: access reviews were conducted, vulnerability scans were run, change management was followed. This is what enterprise buyers almost universally require. External audit fees for Type II average $20,000 to $45,000; total all-in investment including readiness and tooling is typically $30,000 to $80,000.

If you have 9–12 months before the requirement becomes urgent and your controls are already largely in place, go straight to Type II. If you need a report quickly to unblock a deal and have no prior audit history, Type I first is a reasonable bridge — then immediately begin the Type II observation period. Do not confuse the Type I/Type II decision with the criteria selection decision — both types are available across all five Trust Service Criteria.

The Five Trust Service Criteria

SOC 2 is organized around five Trust Service Criteria (TSC). Only one is mandatory; the remaining four are selected based on what your service promises and what your clients require.

Security (CC1–CC9) — Required

The Security criterion is the only mandatory criterion in every SOC 2 engagement. It is also called the Common Criteria because the 32 criteria it contains — organized in nine categories CC1 through CC9 — must be satisfied regardless of which additional criteria are included. The Security criterion addresses how the organization protects its systems against unauthorized access, disclosure of information, damage, misuse, and alteration. Every SOC 2 audit begins and ends with Security.

Availability (A Series) — Optional

Addresses whether the system is available for operation and use as committed or agreed. This criterion is highly relevant for SaaS companies with uptime SLAs, hosting providers, and any organization whose clients depend on continuous access to their services. Requires documented uptime targets, incident management procedures, and evidence of meeting availability commitments over the audit period.

Processing Integrity (PI Series) — Optional

Addresses whether system processing is complete, valid, accurate, timely, and authorized. Most relevant for financial processing platforms, payroll systems, and any service where data processing accuracy is contractually critical. If your service makes commitments about data accuracy or completeness, this criterion is worth including.

Confidentiality (C Series) — Optional

Addresses whether information designated as confidential is protected as committed or agreed. Relevant for organizations handling trade secrets, proprietary data, or contractually confidential client information with defined retention and disposal requirements. If your client agreements include confidentiality obligations for specific data types, this criterion gives buyers documented evidence those obligations are backed by controls.

Privacy (P Series) — Optional

Addresses the collection, use, retention, disclosure, and disposal of personal information in accordance with the organization's privacy notice and AICPA Privacy Management Framework principles. Relevant for organizations processing significant volumes of personal data — particularly relevant given GDPR and US state privacy law overlap. Adding Privacy increases audit scope substantially, and most organizations address privacy obligations through their Security and Confidentiality criteria rather than adding the full Privacy TSC.

For most IT managers beginning their first SOC 2: start with Security only. Add Availability if you have uptime SLAs that clients hold you to. Consider Confidentiality if clients have contractual data protection requirements for specific information types. Adding criteria increases audit scope, evidence burden, and cost — expand deliberately, not aspirationally.

The 32 Common Criteria — A Practical Reference

All 32 Common Criteria apply to the Security TSC — the mandatory criterion in every SOC 2 engagement. They are organized in nine categories, CC1 through CC9, and collectively cover how the organization's controls are designed, implemented, and operated to protect systems and data. Every SOC 2 audit begins here.

CC1 — Control Environment (5 criteria)

The control environment criteria address the foundational governance layer: the organization's commitment to integrity and ethical values, its board oversight of the internal control system, the organizational structure and assignment of authority and responsibility, competence standards for personnel, and accountability through performance measures. Auditors are evaluating whether security is embedded in organizational values and governance — not just in technology. A strong control environment is what makes every other control credible. Deficiencies here — a lack of documented accountability, absent board oversight, no formal competence standards — undermine the credibility of every technical control downstream.

CC2 — Communication and Information (3 criteria)

Covers how the organization obtains and uses relevant information, communicates internally about security responsibilities, and communicates with external parties about its security program. This includes the security policy framework, security awareness training communications, and disclosure of security incidents to appropriate parties. The evidence auditors look for: a current policy library that staff have acknowledged, security awareness training with completion records, and documented procedures for communicating material security events to clients and regulators.

CC3 — Risk Assessment (4 criteria)

Addresses the organization's risk identification, analysis, and response process. The organization must define its risk tolerance, systematically identify risks to achieving its security objectives, analyze those risks, and decide how to respond — accept, mitigate, transfer, or avoid. This is the analytical foundation of the entire security program. Many SOC 2 failures trace back to a risk assessment that is too superficial to credibly justify control selection. Auditors want a documented methodology, a risk register with prioritized findings, and evidence of management review and sign-off.

CC4 — Monitoring Activities (2 criteria)

Covers the organization's ongoing and periodic evaluation of its controls — both internal monitoring (are controls working as designed?) and evaluation of results, including how deficiencies are escalated and remediated. This is where your vulnerability management program, internal audit function, and management review processes live in the framework. Evidence includes: vulnerability scan results with remediation tracking, internal audit reports, management review meeting records, and documented remediation of identified deficiencies.

CC5 — Control Activities (3 criteria)

Addresses how the organization selects and develops controls to mitigate risks identified in CC3. This includes both general controls — organization-wide policies governing expected behavior — and technology-specific controls built into systems and applications. It also covers the policies and procedures that govern control activities across all levels of the organization. The link between CC3 (risk assessment) and CC5 (control activities) is what auditors are testing: your controls should be traceable to identified risks, not arbitrary.

CC6 — Logical and Physical Access (8 criteria)

The largest category and the one most IT managers spend the most time on. CC6 covers the full access management lifecycle across eight criteria: restricting logical access to authorized users only (CC6.1), provisioning access based on job function and need (CC6.2), removing access when no longer needed (CC6.3), preventing unauthorized physical access to facilities and infrastructure (CC6.4), using encryption to protect data in transit and at rest (CC6.7), controlling infrastructure components and network segmentation (CC6.6, CC6.8), and managing internal and external threats to the system (CC6.5). CC6 maps directly to the technical controls most IT teams already have in place — MFA, least privilege, access reviews, encryption, network segmentation — but requires documented evidence that each control is consistently operating, not just deployed.

CC7 — System Operations (5 criteria)

Covers operational security monitoring across five criteria: detecting and remediating vulnerabilities (CC7.1), monitoring system components for anomalous behavior (CC7.2), managing security incidents through defined response procedures (CC7.3), recovering from incidents to restore normal operations (CC7.4), and identifying and communicating security incidents to the appropriate parties (CC7.5). This is where your vulnerability management program, SIEM, and incident response procedures translate into SOC 2 evidence. Auditors will test that vulnerability scans ran on schedule, that anomalous events were investigated, and that incidents were handled according to your documented IR plan.

CC8 — Change Management (1 criterion)

A single criterion — CC8.1 — covering the full change management lifecycle: how changes to infrastructure, data, software, and procedures are authorized, reviewed, tested, and approved before deployment to production. The one criterion covers the entire change pipeline: request, approval, testing, deployment, and post-deployment review. Despite being a single criterion, CC8.1 is one of the most commonly cited sources of audit exceptions, because organizations frequently have undocumented or bypassed change management processes for "small" changes that are treated as exempt from the formal procedure.

CC9 — Risk Mitigation (2 criteria)

Addresses risk mitigation through two criteria: vendor and business partner management (CC9.1) and insurance and other risk transfer mechanisms (CC9.2). CC9.1 is particularly important for organizations with significant sub-processor relationships — SaaS tools, cloud providers, infrastructure vendors. Auditors will test whether you have a documented vendor risk management process, whether high-risk vendors have been assessed, and whether contractual security requirements are included in vendor agreements. CC9.1 is an area where many first-time SOC 2 engagements find their most significant gaps.

SOC 2 Readiness Checklist

SOC 2 readiness is a sequential project. The phases below represent the typical progression from no audit history to a completed Type II report.

Mandatory Policies and Documentation for SOC 2

SOC 2 does not publish a required policy list, but auditors expect documented policies covering all applicable criteria. The policies below are expected in virtually every SOC 2 engagement covering the Security TSC. Each policy must be actively followed — not just filed. The test is not "does the document exist?" but "is the control operating as the document describes?"

Every policy must have a named owner, a version number, a review date, and evidence of staff acknowledgement. Policies that exist as PDF files in a shared drive but are never reviewed and never referenced in operational practice will be identified as control deficiencies during testing. Auditors will interview staff and check whether policy commitments are reflected in actual operational behavior — the policy and the practice must match.

The SOC 2 Audit Process

Understanding the audit process sequence helps IT managers set realistic expectations and prepare the right evidence at the right time.

Auditor engagement. Issue an engagement letter defining scope, criteria, audit period, deliverables, and fees. At this point, confirm the observation period start date for Type II. Any controls implemented after this date count toward the audit period; anything before does not form part of the tested period. This date matters — controls need to be operating from day one of the observation window, not retrofitted at the end.

Kickoff and evidence request. The auditor provides a Population and Evidence Request (PER) — a detailed list of the evidence they will need. Evidence requests typically cover: policy documents, system configurations, access review records, change management logs, incident records, vulnerability scan results, and training completion data. Organize evidence early and assign clear internal ownership for each category. Delays in evidence collection are the most common cause of audit timeline overruns.

Fieldwork (Type II). The auditor samples evidence from throughout the observation period. For each control, they typically test 25 samples for a 12-month period. This means a quarterly access review must have been conducted all four quarters — not just the most recent one. Missing evidence for any sample period creates an exception. The fieldwork phase typically takes 4–8 weeks. During fieldwork, auditors conduct interviews with key personnel — IT leads, compliance owners, engineering managers — to validate that documented controls reflect operational reality.

Management representation letter. Before the report is issued, you sign a management representation letter confirming that you have provided all relevant information and are not aware of material errors or omissions in the evidence provided. This is a legal representation — treat it seriously and confirm the completeness of your evidence before signing.

Report issuance. The auditor issues a draft report for management review before finalizing. Review it carefully — clarify any factual inaccuracies about your system description. Management responses to exceptions can be included in the final report; a well-written corrective action plan in response to an exception is significantly better than silence. The final report is typically issued 2–4 weeks after fieldwork concludes.

Report sharing. SOC 2 reports are confidential — they contain detailed descriptions of your security controls that could be useful to an attacker. Share under NDA with prospective clients, existing clients, and compliance questionnaire reviewers on a need-to-know basis.

SOC 2 Timeline and Cost — What to Expect

Vague timeline guidance is unhelpful when you are trying to plan a SOC 2 project against a sales pipeline or a procurement deadline. The numbers below represent typical ranges for a focused-scope engagement covering the Security TSC.

External audit fees: Type I only: $7,500–$25,000. Type II (12-month period): $20,000–$45,000. Total all-in Type II investment (including readiness, tooling, staff time): $30,000–$80,000.

GRC automation tools: Vanta approximately $12,000–$20,000/year for SaaS companies. Drata and Secureframe in a similar range. These tools reduce staff time for evidence collection significantly but add to annual recurring cost.

What drives cost up: wide scope, multiple Trust Service Criteria, large number of in-scope systems, high volume of sub-processors, lack of existing automation (manual evidence collection is expensive), first-time audit without prior controls, and complex infrastructure environments. What reduces cost: narrow initial scope, strong existing controls documentation, GRC automation for evidence collection, and staff time invested in evidence organization prior to fieldwork.

Common SOC 2 Audit Failures — and How to Avoid Them

Ongoing SOC 2 Compliance: The Recurring Tasks

SOC 2 Type II is not a once-a-year event — it is a continuous evidence collection operation. The observation period is typically 12 months, and auditors sample evidence from throughout that period. Any month without evidence for a recurring control creates a potential exception. The most common root cause of SOC 2 audit exceptions is not missing controls — it is existing controls that were not executed consistently or were not documented when they were executed.

The evidence column is what matters. Auditors sample this evidence for each control across the full observation period. Recurring task management — structured checklists that trigger automatically, assign to the right person, and capture completion timestamps — is the operational infrastructure that makes continuous SOC 2 compliance practical at team scale. For a deeper guide on building recurring compliance checklists for IT teams, see the companion article.

GRC Tools That Accelerate SOC 2

The largest operational burden of SOC 2 is evidence collection — gathering, organizing, and maintaining proof that each control is operating. Done manually, this requires dedicated staff time throughout the observation period. GRC (Governance, Risk, Compliance) automation tools address this by integrating with your existing tooling — cloud infrastructure, identity providers, HR systems, code repositories — and continuously pulling evidence.

Vanta integrates with AWS, GCP, Azure, GitHub, Okta, and dozens of other platforms; continuously monitors controls and flags deviations; provides an auditor portal for direct evidence access; and automates the bulk of CC6 and CC7 evidence collection. Strong for SaaS companies with primarily cloud infrastructure. Pricing approximately $12,000–$20,000 per year for a focused-scope engagement.

Drata offers a similar integration footprint to Vanta with strong automated control monitoring and a compliance dashboard showing current control pass/fail status. Well-regarded for organizations pursuing multiple frameworks simultaneously — SOC 2 plus ISO 27001 plus HIPAA — as the evidence collection infrastructure can serve multiple audits from the same integration layer.

Secureframe is competitive with Vanta and Drata; known for strong auditor relationships and streamlined audit workflows. Supports multi-framework compliance and has some tiers accessible for smaller organizations beginning their first SOC 2 engagement.

What GRC tools do not replace: they automate evidence collection for technical controls, but they do not write your policies, conduct your access reviews, run your penetration tests, or replace human judgment on risk treatment decisions. The recurring operational tasks still require people to execute them — GRC tools make the evidence capture easier, not the work itself. For teams operating on tighter budgets, well-structured recurring checklist workflows that assign tasks, enforce completion, and produce timestamped records provide the evidence infrastructure at a fraction of the cost of a full GRC platform.

How SOC 2 Compares to ISO 27001

SOC 2 and ISO 27001 are the two dominant security assurance frameworks for B2B technology organizations. They serve similar purposes but differ in origin, geography, output type, and what buyers typically require.

For US-focused companies selling to enterprise B2B clients, SOC 2 is typically the priority. For companies with significant European operations or clients, or companies selling to large enterprises with ISO 27001-certified supply chain requirements, ISO 27001 is the priority — or both. The two frameworks have significant control overlap: an organization with a strong SOC 2 Type II program has addressed a large proportion of ISO 27001's requirements. Pursuing both sequentially — SOC 2 Type II first, ISO 27001 second — is more efficient than building them independently. See the ISO 27001 compliance checklist for the ISO 27001 parallel.

Free SOC 2 Compliance Checklist Templates

Maintaining SOC 2 compliance between audits requires executing controls on schedule and documenting the results. CheckFlow's compliance templates structure the recurring frameworks that organisations run alongside SOC 2 — each one assigns tasks to the right people and captures a timestamped, audit-ready completion record for every run. Click any card to view the full template.

ISO 27001 Compliance Checklist

A systematic approach to information security management system (ISMS) compliance — covering asset inventory, risk assessment, security control implementation, and the statement of applicability.

ISO Compliance Checklist

A structured framework for managing ISO quality management system compliance — covering documented process requirements, policy controls, evidence collection, and the ongoing monitoring and review cycle.

FISMA Compliance Checklist

A structured process for Federal Information Security Modernization Act compliance — covering system categorisation, security control selection and implementation, risk assessment, and continuous monitoring.

FedRAMP Compliance Checklist

A structured approach to Federal Risk and Authorization Management Program authorisation — covering the security control baseline, System Security Plan development, assessment preparation, and continuous monitoring.

HIPAA Compliance Audit Checklist

A comprehensive HIPAA compliance framework covering Privacy Rule, Security Rule, and Breach Notification Rule requirements — including administrative, physical, and technical safeguards for PHI.

ICD-705 Fixed Facility Checklist

A compliance framework for organisations managing Sensitive Compartmented Information Facilities (SCIFs) — covering the construction, accreditation, and operational security requirements of ICD 705.

Frequently Asked Questions