SOC 2 Audit: A Complete Guide for Service Organizations

A SOC 2 audit is an independent examination, performed by a licensed CPA firm, that evaluates whether a service organization’s internal controls meet the AICPA’s Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. The resulting report gives customers, partners, and enterprise procurement teams documented evidence that the vendor handles their data with appropriate safeguards. Security is the only required category; the remaining four are in scope only if the service organization’s commitments or customer contracts call for them.

Why SOC 2 Compliance Matters for Your Business

Vendor security reviews used to be a back-office formality. Today, they are a gating requirement in enterprise sales cycles. More than 70 percent of enterprise buyers now require SOC 2 reports before awarding contracts to technology vendors, cloud providers, and data processors. Without a current report, a SaaS company or managed service provider can find itself eliminated from consideration before a single meeting takes place.

Beyond unlocking deals, SOC 2 compliance creates internal discipline. Preparing for an audit forces a service organization to document its control environment, close gaps, and assign ownership over security processes that might otherwise be informal. The result is a stronger security posture, not just a piece of paper.

Who Needs a SOC 2 Audit?

SOC 2 is relevant to any organization that processes, stores, or transmits customer data on behalf of other businesses. Common situations include:

• SaaS companies serving mid-market or enterprise clients
• Cloud infrastructure and managed hosting providers
• Data analytics platforms handling customer records
• Fintech, health-tech, and legal-tech companies with regulated data flows
• Business process outsourcers and payroll administrators

If customers are sending you security questionnaires or adding attestation requirements to vendor contracts, a SOC 2 engagement is almost certainly on the horizon.

The Standards Behind a SOC 2 Audit

A SOC 2 audit is an attestation engagement, not a financial statement audit. It is governed by AICPA attestation standards, specifically AT-C Section 105 (Concepts Common to All Attestation Engagements) and AT-C Section 205 (Examination Engagements) under SSAE 18 (Statement on Standards for Attestation Engagements No. 18). AT-C Section 320 governs SOC 1 rather than SOC 2. Firms should also be aware that SSAE 23, issued in June 2024 and effective for engagements beginning on or after December 15, 2025, amends AT-C Section 105 to align the attestation standards with the AICPA’s updated quality-management standards.

The control criteria themselves come from the AICPA 2017 Trust Services Criteria (with revised points of focus, 2022), issued in 2017 and updated with revised points of focus in 2022. These criteria define exactly what controls an auditor tests and how management describes its system.

Only a licensed CPA firm can issue a SOC 2 report. Cybersecurity consultants and compliance platforms can help prepare, but they cannot sign the opinion. The CPA firm must be independent from the service organization and is subject to AICPA peer review every three years, which examines the firm’s own quality management.

The Five Trust Services Criteria

The AICPA structures SOC 2 examinations around five categories of criteria. Security is mandatory for every engagement. The others are added when the service organization’s system description, contractual commitments, or applicable laws make them relevant.

Security (Common Criteria)

Security is the foundation of every SOC 2 report. The Common Criteria cover logical and physical access controls, risk assessment, change management, system monitoring, and incident response. Controls in this category map to the safeguards most enterprises care about first: who can access the system, how access is provisioned and removed, and how threats are detected.

Availability

Availability criteria address whether the system is available for operation and use as committed. This category is relevant for cloud infrastructure providers, payment processors, or any service where uptime SLAs are a contractual obligation. Controls typically include redundancy architecture, disaster recovery planning, capacity monitoring, and incident response timelines.

Processing Integrity

Processing integrity covers whether the system processes data in a complete, valid, accurate, timely, and authorized manner. It is most relevant to platforms that execute transactions, calculate results, or transform data on behalf of customers, such as payroll processors, financial data aggregators, or insurance claims systems.

Confidentiality

Confidentiality criteria apply when the service organization commits to protecting information designated as confidential. Common examples include trade secrets, contracts, business forecasts, and pricing data shared by customers. Controls include encryption, access restrictions, and data-handling procedures.

Privacy

Privacy criteria address the collection, use, retention, disclosure, and disposal of personal information in accordance with the organization’s privacy notice and applicable laws. This category is distinct from security: a system can be secure but still handle personal data in ways that violate privacy commitments. Organizations subject to GDPR, CCPA, or HIPAA often scope in privacy, though those frameworks carry their own separate requirements beyond what a SOC 2 report addresses.

SOC 2 Type I vs. Type II: What Is the Difference?

A SOC 2 compliance audit can produce one of two report types. Understanding the difference matters because customers and procurement teams increasingly distinguish between them.

Type I

A Type I report evaluates whether controls are suitably designed to meet the Trust Services Criteria at a single point in time. The auditor is answering: do the right controls exist? A Type I engagement typically takes three to six months from kickoff to final report. It is a reasonable starting point for an organization just entering the compliance process, or when a deal deadline requires a report faster than a Type II timeline allows.

Type II

A Type II report evaluates both the design and the operating effectiveness of controls over a defined period, usually six to twelve months. The auditor tests whether controls actually functioned as intended throughout that window, not just on the report date. Type II reports take six to fifteen months from kickoff to issuance.

Most enterprise buyers expect a Type II report. A Type I may satisfy an initial vendor questionnaire, but ongoing vendor management programs generally require an annual Type II renewal. Organizations that start with Type I typically commit to achieving Type II within a year.

What Happens During a SOC 2 Audit

The engagement follows a predictable sequence, though the timeline varies based on report type and the maturity of the organization’s controls.

1. Scoping. The service organization and the CPA firm agree on which Trust Services Criteria categories apply, which systems and processes are in scope, and the audit period for a Type II report.

2. Readiness assessment (optional but common). Many organizations conduct a gap assessment before the formal audit begins. This is not part of the attestation itself, but it surfaces control deficiencies while there is still time to remediate them without those gaps appearing in the final report.

3. System description. Management prepares a written description of its system, covering the services provided, the infrastructure, software, people, procedures, and data involved, and how controls address the applicable Trust Services Criteria. The auditor evaluates whether this description is fairly presented.

4. Control testing. The CPA firm tests controls through inquiry, observation, inspection of documentation, and re-performance. For a Type II report, testing spans the full observation period to assess operating effectiveness.

5. Report issuance. The final report contains the auditor’s opinion, management’s system description, management’s assertion about controls, the auditor’s description of tests performed, and the results of those tests. A Type II report also includes a statement about whether any exceptions (control failures) were noted during the period.

Reading a SOC 2 Report: What to Look For

When you receive a SOC 2 report from a vendor, or when your customers review yours, a few elements deserve close attention.

Opinion type. An unqualified opinion means the auditor found no material issues. A qualified or adverse opinion, or a disclaimer of opinion, signals significant problems. These are uncommon but not unheard of.

Exceptions. Even an unqualified Type II report can contain exceptions: instances where a specific control did not operate effectively during the period. One or two minor exceptions in an otherwise clean report are common and not necessarily a red flag. A pattern of exceptions in access controls or change management warrants deeper questions.

Complementary user entity controls (CUECs). Most SOC 2 reports include a section on controls that customers (user entities) are expected to implement for the service to operate securely. If your organization relies on a vendor’s SOC 2 report, verify that your own controls satisfy the listed CUECs.

Report coverage period. SOC 2 reports expire. A Type II report is generally considered current for twelve months from the period end date. If a vendor’s most recent report covers a period that ended eighteen months ago, that is a gap worth addressing in your vendor assessment.

How to Prepare for a SOC 2 Compliance Audit

Preparation is where most of the work happens. Organizations that invest in readiness before engaging an auditor experience fewer surprises and shorter remediation cycles.

Start by documenting every control that addresses the Trust Services Criteria categories in scope. Many organizations discover that good security practices are already in place but are not documented in a way an auditor can test. Formalizing policies, procedures, and evidence-collection routines is often the single biggest preparation step.

Next, close identified gaps before the observation period begins (for Type II). Common deficiencies include inconsistent access reviews, undocumented change management procedures, missing vendor risk assessments, and gaps in security training records.

Working with a CPA firm experienced in SOC reporting, like Modus’s SOC reporting practice, can help service organizations scope their engagement correctly from the start. Overly broad scoping drives up cost and complexity without adding assurance value; under-scoping leaves gaps that customers will notice. Modus uses a structured, AI-assisted workpaper process that reduces evidence-gathering burden on client teams, which is meaningful when an organization is simultaneously running its business and preparing for a multi-month audit observation period.

For a broader look at how attestation engagements fit into the assurance spectrum, see Modus’s audit and assurance services overview.

SOC 2 vs. Other SOC Reports

SOC 2 is not the only report in the SOC framework. The distinctions matter when a customer or regulator specifies which type they need.

SOC 1 reports on controls relevant to user entities’ financial reporting. They are required when a service organization processes transactions that flow into customer financial statements, such as payroll processors or loan servicers. SOC 1 is governed by SSAE 18 AT-C Section 320 and follows its own criteria set.

SOC 3 is a public-facing version of a SOC 2 report. It contains the auditor’s opinion and management’s assertion but omits the detailed control descriptions and test results. Organizations use SOC 3 reports on their websites as a high-level signal to the market.

SOC for Cybersecurity is a separate framework that allows organizations to report on their enterprise-wide cybersecurity risk management program, not just controls over a specific service.

If you are unsure which report type applies to your situation, the answer usually depends on what your customers are asking for and whether the service you provide affects their financial reporting.

Related reading: SOC Report Types: SOC 1 vs. SOC 2 vs. SOC 3 Explained

Frequently Asked Questions

What is a SOC 2 audit?

A SOC 2 audit is an independent examination, conducted by a licensed CPA firm under AICPA attestation standards, that evaluates whether a service organization’s internal controls meet the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. The resulting report documents the auditor’s findings for use by customers, business partners, and enterprise procurement teams.

How long does a SOC 2 audit take?

A Type I report typically takes three to six months from kickoff to issuance, including preparation time. A Type II report takes six to fifteen months because the auditor must observe controls operating over a defined period, usually six to twelve months, before issuing an opinion.

What is the difference between SOC 2 Type I and Type II?

A Type I report evaluates whether controls are suitably designed at a single point in time. A Type II report evaluates both design and operating effectiveness over a defined observation period. Most enterprise customers require Type II because it provides evidence that controls actually worked, not just that they existed on paper.

Who can perform a SOC 2 audit?

Only a licensed CPA firm can issue a SOC 2 report. The firm must be independent from the service organization and subject to AICPA peer review. Cybersecurity consultants and compliance automation platforms can assist with preparation and readiness, but they cannot sign the auditor’s opinion.

How much does a SOC 2 audit cost?

Costs vary based on report type, scope, and the complexity of the organization’s control environment. Type I engagements typically range from $7,500 to $60,000. Type II engagements typically range from $12,000 to $100,000. Preparation and readiness work, if done separately, adds to the total investment.

How often does a SOC 2 report need to be renewed?

SOC 2 Type II reports are generally considered current for twelve months from the period end date. Most organizations undergo an annual audit cycle to maintain a current report, which is what enterprise customers and vendor management programs expect. A lapsed report can create friction in renewals and new sales cycles.