SOC 2 Compliance: What It Is, How It Works, and What Auditors Check

SOC 2 Compliance: What It Is, How It Works, and What Auditors Check

TL;DR

• SOC 2 is an attestation standard from the AICPA, not a certification. A licensed CPA firm examines your controls and issues a report — there is no badge or registry.
• The current framework is the 2017 Trust Services Criteria (with 2022 revisions), which defines five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Only Security is mandatory.
• Type 1 reports cover whether controls are designed correctly at a specific date. Type 2 reports cover whether controls operated effectively over a defined period, typically six to twelve months. Enterprise buyers almost always require Type 2.
• SOC 2 engagements are governed by SSAE No. 18 under AT-C sections 105 and 205 (for examinations). Every statistic, policy, and control must be supported with evidence the auditor can test.
• The most common audit failures are incomplete access reviews, no documented incident response activity during the observation period, and change management gaps.

Who this is for

This guide is for startup CTOs, engineering leads, and compliance owners at B2B SaaS companies preparing for a first SOC 2 engagement or planning a renewal. It covers the mechanics of SOC 2 from the AICPA's published standards, explains what auditors actually test, and identifies where teams consistently fall short. If you have already completed a Type 1 and are moving to a Type 2, the audit process and common failures sections apply directly.

What SOC 2 is

SOC 2 — System and Organization Controls 2 — is an examination standard developed and maintained by the AICPA. It is governed under Statements on Standards for Attestation Engagements No. 18 (SSAE 18), which became effective May 1, 2017, and updated AT-C sections 105, 205, and 315 of the AICPA attestation standards.

The framework evaluates controls at a service organization that protect customer data across one or more of five Trust Services Criteria. A licensed CPA firm issues the report. AICPA itself does not certify organizations or maintain a registry of "SOC 2 certified" companies — the report is the product of the auditor's examination, not a certificate from a standards body.

SOC 2 is not a fixed control list. The framework gives you the criteria, and you design controls that satisfy them in your environment. This differs from ISO 27001:2022, which includes Annex A with 93 specific controls, or PCI DSS v4.0, which mandates explicit requirements. The flexibility in SOC 2 is both practical and risky: teams with no prior audit experience frequently miss controls that auditors expect to see.

The completed report is shared with prospects and customers under NDA. It contains the auditor's opinion, a description of your system, and detailed test results. There are four possible opinion types:

• Unqualified opinion — controls were designed correctly and operated effectively throughout the period. This is the target.
• Qualified opinion — controls were effective except for specific named exceptions. The exceptions appear in the report.
• Adverse opinion — controls were not effective. This is rare in practice; most issues are caught and corrected before the report is issued.
• Disclaimer of opinion — the auditor could not form an opinion, usually due to scope limitations.

AT-C 205 vs AT-C 315

SOC 2 Type 1 and Type 2 reports are examination engagements performed under AT-C section 205. AT-C section 105 provides the overarching concepts that apply to all attestation engagements, including independence requirements, evidence standards, and documentation obligations. AT-C section 315 governs agreed-upon procedures engagements, which are a distinct product (not a SOC 2 report) where the auditor performs only the specific tests you request and reports factual findings without an opinion.

Type 1 vs Type 2: what each report actually says

A Type 1 report includes two things: a description of your system as of a specific date, and the auditor's opinion on whether your controls are suitably designed to meet the selected Trust Services Criteria. It is a point-in-time snapshot. The auditor tests design, not actual operation.

A Type 2 report covers the same system description, but the auditor's opinion also addresses whether the controls operated effectively over a defined period. The auditor samples evidence across the observation window — access review records, change tickets, incident logs, vendor review documentation — and tests whether controls functioned consistently.

The observation period is not mandated to a specific minimum by the Trust Services Criteria, but most CPA firms require at least six months to draw meaningful conclusions. Twelve months is the most common period for ongoing surveillance audits. A shorter period (three to six months) is generally accepted only for a first-time engagement when the organization can demonstrate mature controls.

Which do you need? Most US enterprise procurement teams require a Type 2 report before signing. A Type 1 is useful when you need something to share quickly — for example, to get a deal moving while your Type 2 observation window runs. Some smaller buyers accept a Type 1 with a documented commitment to complete a Type 2. If you do not know what a prospect requires, ask explicitly before starting work.

The five Trust Services Criteria

The 2017 Trust Services Criteria (with 2022 revisions) organize all SOC 2 controls around five categories. The AICPA's 2022 revision updated the points of focus within existing criteria but did not add or remove criteria.

Security (mandatory)

Security, also called the Common Criteria (CC series), is required for every SOC 2 report. It covers logical and physical access controls, system operations, change management, risk mitigation, and monitoring. The criteria are organized into nine CC categories (CC1 through CC9) addressing the control environment, communication, risk assessment, monitoring, control activities, logical access, system operations, change management, and risk mitigation.

Every SOC 2 engagement must address the Security criterion. The other four are optional.

Availability (optional)

Availability covers whether systems are available for operation and use as committed or agreed. Controls include uptime monitoring, performance metrics, capacity planning, and disaster recovery testing. Select this criterion if your customers have contractual uptime requirements or SLAs, or if your service is infrastructure-dependent (hosting, cloud services, data pipelines).

Processing Integrity (optional)

Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized. Controls include input validation, error handling, job scheduling, and output reconciliation. Most B2B SaaS platforms skip this criterion unless they process financial transactions, healthcare claims, payroll, or other data where processing accuracy is the primary customer concern.

Confidentiality (optional)

Confidentiality covers information designated as confidential by the customer — intellectual property, trade secrets, source code, business plans. Controls include data classification, encryption, access restrictions, and disposal procedures. Select this if your contracts include confidentiality obligations for specific data categories beyond what the Security criterion already addresses.

Privacy (optional)

Privacy covers the collection, use, retention, disclosure, and disposal of personal information as described in your privacy notice. This criterion maps closely to the AICPA's Generally Accepted Privacy Principles (GAPP). Most B2B SaaS companies skip it and address personal data obligations through GDPR, CCPA, or contractual DPAs instead. Select Privacy if your service collects personal data directly from end users and your customers request assurance around those practices.

What auditors actually test

The SOC 2 framework does not provide a fixed control list — it provides criteria and points of focus. What auditors test depends on how you have described your system and which controls you have documented. The table below shows the control categories auditors examine in Security criterion engagements and the evidence types they typically request.

The auditor will sample evidence across the observation period for a Type 2 engagement. This means controls must operate consistently throughout the window — not just at the end. A quarterly access review that happened in months one and three of a six-month window, but not month five, will produce a finding.

Compliance automation platforms (Vanta, Drata, Secureframe, Sprinto, and others) automate continuous evidence collection by integrating with your AWS, Google Workspace, GitHub, Okta, and HR systems. They flag gaps in real time rather than during audit fieldwork. For current pricing on these platforms, check each vendor's pricing page directly, as rates change.

How the audit process works

A SOC 2 engagement runs in four phases.

Phase 1: Readiness. Before the audit period begins, most organizations work through a gap assessment — either internally, using a readiness platform, or with an external consultant. The goal is to identify which controls are missing or undocumented before the observation window starts. Any control that was not operating during the window cannot be retroactively added.

Phase 2: Type 1 (optional). If you are doing a Type 1 before a Type 2, the auditor will review your system description and assess control design at a specific date. This phase typically runs three to eight weeks depending on scope and auditor availability.

Phase 3: Observation window (Type 2 only). The observation period runs for a set number of months, typically six to twelve. During this time, controls must operate consistently. The auditor is not actively watching — they will request evidence samples after the window closes. You are responsible for generating and retaining that evidence.

Phase 4: Audit fieldwork. After the observation window closes, the auditor requests a sample of evidence from across the period (not just the most recent month), tests whether controls operated as described, and issues a draft report. You have the opportunity to review the draft and correct factual errors before the final report is issued. Exceptions that cannot be corrected are disclosed in the final report.

How to pick an auditor. Any licensed CPA firm with attestation experience can perform a SOC 2 examination. The AICPA Peer Review Program requires participating firms to have their audit quality reviewed periodically — ask any prospective auditor for their most recent peer review report and whether they have SOC 2-specific attestation experience. The AICPA explicitly warns against firms that offer to both write your policies and then audit them: independence requirements prohibit firms from auditing their own consulting work. Use one firm for advisory and a separate firm for the examination.

Common failures and how to avoid them

Most SOC 2 findings come from a small number of recurring gaps. These are the issues audit teams encounter regularly, based on the control categories the Trust Services Criteria require.

Incomplete access reviews. SOC 2 expects periodic reviews in which managers confirm their team's access is still appropriate. If you cannot produce evidence of those reviews for every quarter in the observation window, the auditor will note the gap. Set a recurring calendar task, generate a report from your identity provider or access management tool, and save the output with a date stamp.

Starting the observation window before controls are ready. The observation window records history. If your change management controls, access reviews, or vendor reviews were not in place at the start of the window, the auditor will see gaps from day one. Do the readiness work, confirm controls are operating, then start the clock.

Merging code without a review trail. Branch protection rules and pull request requirements are auditable. If your engineers can push directly to main, or if pull requests are routinely merged by the author without a second reviewer, change management controls will fail. Implement branch protection and code review requirements before the observation period begins.

No documented incident response activity. The auditor expects evidence that your incident response process was exercised during the observation window. If no real incidents occurred, a tabletop exercise with a written record satisfies this control. Without it, the IR plan is just a document with no evidence of operation.

Vendor management gaps. Auditors check that you maintain a subprocessor inventory, that you have reviewed each vendor's security posture (typically by reviewing their SOC 2 report or equivalent), and that you have signed agreements (DPA, BAA, SCC) where required. This work is often left until late in the readiness process. Start it early — getting signed DPAs from vendors can take weeks.

Treating policies as the evidence. A written access control policy is not evidence that access controls operated. Evidence is logs, screenshots, exports, and records. Every policy statement needs a corresponding evidence artifact.

SOC 2 vs ISO 27001

SOC 2 is a CPA-attested report primarily used in North American enterprise sales. ISO 27001:2022 is an internationally recognized certification issued by accredited registrars after a conformity audit. The two differ in governance, scope, and market expectations:

Controls overlap substantially. If you complete SOC 2 first, most of the foundational work — written policies, access reviews, risk register, incident response plan, vendor management — carries over to ISO 27001. The incremental work for ISO 27001 after SOC 2 is primarily the formal information security management system (ISMS) structure and Statement of Applicability documentation required by the ISO standard.

If your buyers are primarily in the US, start with SOC 2. If you are selling to European enterprise or to organizations that specifically require ISO certification, prioritize ISO 27001 or pursue both in parallel. See our full comparison: SOC 2 vs ISO 27001.

SOC 2 readiness in seven steps

A practical sequence for B2B SaaS startups and SMBs:

1. Define scope. Pick the Trust Services Criteria relevant to your service (Security is required; add Availability if you have uptime commitments, Confidentiality if customer contracts require it).
2. Assign an owner. One person is accountable: CTO, head of security, or compliance lead. Distributed ownership without a single accountable person consistently delays readiness.
3. Choose a readiness platform. Vanta, Drata, Secureframe, and Sprinto all integrate with common cloud and HR systems and pre-map controls to the Trust Services Criteria. Check current pricing directly on each vendor's site before deciding.
4. Choose an auditor. Request fixed-fee proposals from at least three CPA firms with SaaS attestation experience. Confirm they hold an active AICPA peer review. Do not use the same firm for both advisory and examination.
5. Close gaps. Address what the readiness platform flags. Most gaps are policy documentation and access review procedures, not infrastructure changes.
6. Start the observation window. Once controls are confirmed operating, begin the clock. For a first-time Type 2, a six-month window is the most common choice.
7. Complete fieldwork. Provide the auditor with evidence packages, respond to follow-up questions, review the draft report for factual accuracy, and receive the final report.

Mini-FAQ

Is SOC 2 required by law?

No. SOC 2 is not a regulatory requirement. It is a market expectation in B2B software sales. Enterprise procurement teams frequently include SOC 2 in vendor security requirements, which makes it functionally necessary for companies selling to enterprise buyers — but it is not mandated by any statute or regulation.

How long is a SOC 2 report valid?

A SOC 2 Type 2 report covers a specific observation period. Buyers generally accept a report for twelve months from the end of that period before requesting an updated report. There is no AICPA-mandated expiration date, but twelve months is the de facto market standard.

Can a small startup get SOC 2?

Yes. SOC 2 applies to any size of organization. Compliance automation platforms lower the operational burden for small teams by providing pre-built policy templates and automated evidence collection. Many pre-Series A companies start with a Type 1 to unblock deals quickly and run the Type 2 observation window in parallel.

What does an unqualified opinion mean?

An unqualified opinion is the outcome where the auditor found no material exceptions: controls were suitably designed and operated effectively throughout the observation period. It is the standard target for every SOC 2 engagement. A qualified opinion, by contrast, means the auditor identified specific exceptions and describes them in the report.

Do I need SOC 2 if I am not a US company?

SOC 2 is a US framework but is recognized by enterprise buyers globally. Non-US companies frequently pursue SOC 2 to sell into the US market and pair it with ISO 27001 for European customer requirements. Neither framework is exclusive to a geography; buyer demand determines which report you need.

What is the difference between SOC 2 and SOC 1?

SOC 1 (governed by AT-C section 320) addresses internal controls over financial reporting. It is used by organizations whose operations affect a customer's financial statements — payroll processors, loan servicers, transfer agents. SOC 2 addresses controls over security, availability, processing integrity, confidentiality, and privacy. The two reports serve different audiences and cannot substitute for each other.

Sources

1. AICPA & CIMA. "SOC Suite of Services." Accessed 2026-05-12. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services

1. AICPA. "2017 Trust Services Criteria (With Revised Points of Focus — 2022)." Published September 30, 2023. Accessed 2026-05-12. https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022

1. AICPA. "SSAE No. 18 — Attestation Standards: Clarification and Recodification." Accessed 2026-05-12. https://www.aicpa-cima.com/resources/article/ssae-no-18

1. AICPA. "Generally Accepted Privacy Principles (GAPP)." Accessed 2026-05-12. https://www.aicpa-cima.com/resources/article/generally-accepted-privacy-principles

1. AICPA. "Peer Review Overview." Accessed 2026-05-12. https://www.aicpa-cima.com/professional-insights/article/peer-review-overview

1. ISO. "ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection." Accessed 2026-05-12. https://www.iso.org/standard/82875.html

1. A-LIGN. "SOC 2 Examination." Accessed 2026-05-12. https://www.a-lign.com/soc-2

Sources used

1. AICPA — accessed 2026-05-12
2. 2017 Trust Services Criteria (with 2022 revisions) — accessed 2026-05-12
3. SSAE No. 18 — accessed 2026-05-12
4. ISO 27001:2022 — accessed 2026-05-12
5. PCI DSS v4.0 — accessed 2026-05-12
6. AICPA's Generally Accepted Privacy Principles (GAPP) — accessed 2026-05-12
7. AICPA Peer Review Program — accessed 2026-05-12
8. https://www.a-lign.com/soc-2 — accessed 2026-05-12

Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.