On this page

A SOC 2 Type 2 report (also written SOC 2 Type II) is an independent CPA firm’s opinion on whether a company’s controls, measured against the AICPA Trust Services Criteria, were suitably designed and operated effectively over a defined period. The AICPA sets no minimum length for that period, which is commonly 3, 6, or 12 months. It is an attestation report, not a certification: there is no certificate, only the separate AICPA display logo. Buyers usually receive the full report under NDA.

What Is Inside a SOC 2 Type 2 Report?

A Type 2 report has four parts and an optional fifth that the auditor did not examine. The table shows who wrote each part and what to check first. Order varies by report, so use the contents page instead of assuming a section number.

What it holdsWho wrote itCheck first
Independent service auditor’s reportThe opinion, the period covered, the scope, and what management and the auditor are each responsible forThe CPA firmOpinion type, period dates, and the signing firm
Management’s assertionThe company’s statement that its system description is fair and its controls were suitably designed and, in a Type 2, operated effectively over the periodCompany managementThat it names the same system and period as the auditor’s report
System descriptionServices, infrastructure, software, people, procedures, data, subservice organizations, any criteria scoped out, and the controls the company expects its customers to runCompany managementWhether the product you use is in scope, and which subservice providers are carved out
Controls, tests, and resultsEach control, the criterion it supports, the test the auditor ran, and the result, including exceptionsControls: management. Tests and results: the CPA firmExceptions, and whether the testing looks tailored to the company
Other information (optional, unaudited)Management’s responses to exceptions, remediation plans, other contextCompany managementTreat it as the company’s own statement. The opinion does not cover it

Order and format. The AICPA’s illustrative Type 2 report notes that its description criteria (DC 200) are not specific about the format of a system description, and real reports differ in order. Sprinto, a compliance vendor, reported that of eight company reports it reviewed in September 2026, five opened with the auditor’s report and three with management’s assertion.

Period dates. A Type 2 states when its period starts and ends, and the opinion speaks only to that period. A report that closed months ago says nothing about the months since, which is the gap a bridge letter is meant to cover (see the validity question below).

Carve-outs, CSOCs, and CUECs. The system description names the subservice organizations the company relies on, such as a cloud host or data center. When the report carves one out, the auditor did not test that provider’s controls, and the report should list the complementary subservice organization controls (CSOCs) the company expects the provider to run. Complementary user entity controls (CUECs) point the same idea at you: they are the controls the company expects its customers to operate.

Length. Reports vary with scope, criteria, and the number of controls. Sprinto reported that nine reports it reviewed in September 2026, eight company reports and the AICPA illustrative report, ran 31 to 84 pages, with a median of 52.

New to SOC 2? Start with What is SOC 2 compliance? or our SOC 2 compliance guide, which follows an audit from scope to report.

What Each Part Tells You

The Auditor’s Report and the Four Opinions

The auditor’s report is the CPA firm’s verdict. It ends in one of four opinions:

  • Unmodified (also called unqualified or clean): the system was described fairly and the controls were suitably designed and operated throughout the period. A clean opinion can still sit beside exceptions in the test results.
  • Qualified: issues with one or more specific controls. Read which ones fell short and whether you rely on them.
  • Adverse: material problems. The controls as tested did not do what the system description says they do.
  • Disclaimer of opinion: the auditor could not gather enough evidence to form an opinion.

Our guide to SOC 2 exceptions and qualified opinions explains how to weigh each one.

Management’s Assertion and the System Description

Management’s assertion is a short, signed statement from the company’s leadership. It is the company’s claim, and the auditor’s report is the independent opinion on that claim.

The system description sets the boundary of everything else, and a boundary narrower than the product you buy matters. If your team depends on a vendor’s mobile app but the audit covers only their web platform, the report says nothing about the app. A suspiciously narrow description can be as revealing as a long list of exceptions.

The description is also where the CUECs sit, the security tasks the vendor says are your job.

Think of CUECs as the security instructions that come with a new product. If a vendor says, “You are responsible for enforcing strong user passwords,” and you don’t, then any breach from a weak password is on you, even if their SOC 2 report is perfect.

Our guide to complementary user entity controls shows how to review them. To see where each part appears in a real document, use a SOC 2 report example.

Controls, Tests, and Results

The bulk of the report is a table with a row for every control the auditor tested. Each row gives the control (for example, “New user access is formally approved before being granted”), how the auditor tested it (for example, “Inspected a sample of 25 new hire access request tickets to verify manager approval”), and the result.

A failed test is an exception, documented in the same row. A few minor exceptions with credible management responses are usually acceptable. A pattern of failures, especially in access control or change management, is not. Management’s responses often sit in the optional other-information section, which the auditor did not examine.

Does the Testing Look Tailored, and Who Signed It?

The AICPA’s Peer Review Board has named a specific quality risk in SOC 2 work: engagements that are not designed around the service organization’s own risks, which produce identical reports, risk assessments, sample sizes, and testing procedures. Its May 2026 reviewer alert, covered in the Journal of Accountancy, tells peer reviewers to look at how a firm uses third-party SOC platforms, whether engagement timelines are reasonable, and whether engagements are tailored to each client.

That guidance tells peer reviewers where to look. It does not make any individual report defective, and a reader cannot apply it to one report in isolation. Two practical checks follow from it.

If you hold two reports from the same firm, control descriptions, test procedures, and sample sizes that look identical across companies with different systems may be worth a question to the vendor or the auditor.

You can also look up the signer. The AICPA Peer Review Public File lists a firm’s most recent accepted review. Our guide to AICPA peer review and SOC 2 auditor quality explains how to find and read it, and the SOC 2 auditor directory shows each listed firm’s peer-review result where one is on record.

What a Type 2 Report Proves

A Type 2 report shows that an independent CPA firm tested a company’s controls over a period and gave an opinion, which is stronger evidence than a policy document or a questionnaire answer. It covers only the system, criteria, and period stated in the report, so a clean opinion does not mean the company is secure everywhere.

Is SOC 2 Type 2 a Certification?

No. SOC 2 Type 2 is an attestation report, not a certification. A CPA firm examines the controls and issues an opinion; there is no pass/fail badge, and the AICPA does not “certify” anyone. People say “SOC 2 Type 2 certification” loosely, but the deliverable is always a report.

That matters when a buyer asks for proof. An ISO 27001 certificate is a short document confirming a passing audit; a Type 2 report contains the auditor’s opinion, the system description, and the test results for every control. You hand over the full report, usually under NDA, not a logo or a certificate number. For the longer explanation, see whether SOC 2 is a certification.

Why Enterprise Buyers Ask for Type 2

Enterprise RFPs for B2B SaaS commonly ask for a SOC 2 report, and large procurement teams commonly require Type 2 specifically. A recent report often answers security questionnaires directly, which can shorten due diligence, because it gives independent answers to three questions: can I trust you with my sensitive data, are your practices consistent or only documented for audit day, and do you protect information over time.

SOC 2 Type 1 vs Type 2 in Four Rows

A Type 1 report covers control design at one date. A Type 2 report adds testing of whether the controls operated across a period.

SOC 2 Type 1SOC 2 Type 2
Period coveredA single dateA defined period
What the auditor testsWhether controls are suitably designedDesign, plus whether the controls operated effectively
EvidencePolicies, configurations, system descriptionsThe same, plus records that controls ran during the period, such as logs, tickets, and approvals
Often chosen whenA customer accepts a design checkpointA customer asks for proof that controls operated over time

For a Type 2, the auditor asks for evidence that a firewall was configured and unchanged throughout the period, which goes beyond whether one exists. The hard part is proving a control worked on a random Tuesday three months ago. A Type 1 report shows you have a plan; a Type 2 report gives evidence that the plan operated. The full comparison, including fees and when to choose each, is in our SOC 2 Type 1 vs Type 2 guide.

Breaking Down the Five Trust Services Criteria

At the core of every SOC 2 report are the Trust Services Criteria (TSC), five principles the AICPA created to evaluate how a company protects customer data. Security is mandatory; the other four are selected based on what the service does and what the company has promised customers. For the individual controls a Type 2 auditor tests inside each criterion, see our SOC 2 Type 2 controls reference.

Because only Security is mandatory in SOC 2, a company can scope its report to the criteria its customers care about instead of a fixed list. The number of control points in a report varies widely by scope and by which criteria are selected. According to CBIZ’s 2024 SOC Benchmark Study, Availability appears in 75.3% of reports and Confidentiality in 64.4%, the two most commonly added criteria beyond the mandatory Security baseline.

The Mandatory Foundation: Security

The Security criterion is required in every SOC 2 audit. It is often called the “Common Criteria,” and it asks whether the system is protected against unauthorized access, use, or modification. It covers access controls (only authorized users can reach systems and data centers, through both logical and physical controls), firewalls and intrusion detection, two-factor authentication (2FA) to keep stolen credentials from causing a breach, and vulnerability management, meaning finding and patching security holes before they get exploited.

It also covers change management, the formal process for pushing changes to production systems, where auditors want to see that uncontrolled code deployments are not introducing new security holes. And it covers system operations monitoring: how the company monitors infrastructure for anomalous behavior and what happens when it detects an incident.

Choosing Your Additional Criteria

Beyond Security, the company chooses which other criteria to include based on its business and the commitments it has made to customers. For more, see our guide to the five Trust Services Criteria categories. The other four:

  • Availability: For services that commit to specific uptime SLAs (99.9% uptime or better), this criterion tests whether the system is available as agreed. Auditors look for tested disaster recovery plans, live monitoring dashboards, and proof of backup and redundancy systems. Cloud providers and other SaaS vendors that commit to uptime often include it.

  • Processing Integrity: This applies to any platform that performs calculations or handles transactions. It looks at whether system processing is complete, valid, accurate, and timely. A fintech app processing payments or a payroll platform calculating employee wages needs it to show calculations are complete and accurate. Auditors scrutinize data input validation, output checks, QA procedures, and error correction workflows.

  • Confidentiality: This criterion is about protecting information that has been specifically designated as confidential. A service that handles intellectual property, sensitive M&A documents, or legal contracts needs it. A virtual data room used during mergers and acquisitions is a good candidate, since its purpose is safeguarding highly sensitive corporate documents. Key controls include data encryption at rest and in transit, strict access policies based on the principle of least privilege, Non-Disclosure Agreements (NDAs), and secure data disposal.

  • Privacy: Privacy sounds like Confidentiality but covers Personally Identifiable Information (PII): how it is collected, used, retained, and destroyed. The controls for Privacy draw on frameworks like GDPR and CCPA and focus on the clarity of privacy notices, the process for honoring user data requests, and data retention policies. Any company handling customer health records, social security numbers, or other personal data (like a HealthTech platform) should consider including it.

Adding criteria you don’t need wastes time and money, but leaving out one that your customers expect can make your report look weak. Choose criteria that mirror the promises you make in your contracts and marketing.

How to Read a SOC 2 Type 2 Report

Find the auditor’s report in the contents page and read the opinion type and period first. Then confirm the system description covers the product you use, and check the exceptions and the CUECs that fall to you. Our guide to the SOC 2 audit report walks through reviewing a report you have received, and the parts above are what it will point you to. If your company is the one being reviewed, SOC 2 report red flags covers what lowers a reviewer’s trust and how to avoid it.

Getting a SOC 2 Type 2 Report

Getting a Type 2 report takes four steps: a readiness assessment to find and close control gaps, an observation period while the controls run and generate evidence, fieldwork by a licensed CPA firm, and the report itself. The firm agrees the observation period with you.

Each step has its own guide:

SOC 2 Type 2 Questions, Answered

How Long Is a SOC 2 Type 2 Report Good For?

A SOC 2 report has no expiry date. Many buyers treat it as current for about 12 months after the end of its period, then ask for the next one. Schellman calls 12 months the general rule of thumb and says each customer decides.

Many companies are examined every year for this reason. Consistent, yearly reports show an ongoing security program, not a one-time project.

There’s also a practical gap to manage. Most reports cover a fixed period (say, January through December), but a prospect may ask for assurance in March, after the report period ended but before the next one is issued. To cover that gap, you provide a bridge letter (also called a gap letter): a short, management-signed statement confirming no significant control changes occurred since the report period closed. Bridge letters typically span up to three months and are not audited, so buyers treat them as a stopgap, not a substitute for a fresh report. See our guide to the SOC 2 bridge letter for a template and how long buyers will accept one.

Can You Fail a SOC 2 Audit?

Technically, you don’t “pass” or “fail” a SOC 2 audit. It’s not a test with a score. The auditor issues one of the four opinions described above, and only an unmodified opinion is the outcome you are aiming for. A thorough readiness assessment is the best way to reach it: it finds and fixes problems before the auditor does. For what each outcome does to your deals and the way back, see what happens if you fail a SOC 2 audit.

What Happens If the Auditor Finds an Issue?

An exception does not mean you’ve failed. The auditor documents it in the test results, and your management can add a response explaining what happened, the impact, and the steps taken to fix it. Customers’ reviewers judge each exception on its own facts: which control it affects, how many sampled items failed, the cause, and evidence that the fix now operates. Telling a reviewer that exceptions are normal does not help your case. Those specifics do. SOC 2 exceptions and qualified opinions explains how auditors and reviewers weigh them.

How Is SOC 2 Different from ISO 27001?

SOC 2 and ISO 27001 have different scopes and philosophies.

  • SOC 2 is a CPA attestation against the AICPA’s Trust Services Criteria. It tests specific controls and their operational effectiveness over a period.
  • ISO 27001 is a certification of your Information Security Management System (ISMS). It validates how you manage risk across the organization and is more globally recognized.

Think of it this way: ISO 27001 certifies your system for managing security, while a SOC 2 Type 2 report attests to the actual performance of your security controls.

Does Every SaaS Company Need a SOC 2 Report?

Early-stage companies can often handle security questionnaires directly. But once you start selling to mid-market or enterprise buyers, a SOC 2 Type 2 report becomes a prerequisite. These buyers require independent proof of security. Not having one is frequently an outright disqualifier.

Who Can Issue a SOC 2 Report?

Only a licensed CPA firm (or a non-US equivalent) can issue a SOC 2 report. The firm has to be licensed to practice public accountancy and follow the AICPA’s attestation standards (AT-C 105 and AT-C 205) when planning and performing the engagement. Consultants, readiness firms, and compliance automation vendors can help you prepare, but they cannot sign the report itself; that opinion always comes from an independent CPA firm or its non-US equivalent.

Is SOC 2 Legally Required?

No. SOC 2 is not a law or a regulatory mandate, and no government body requires it. It has become a de facto business requirement because enterprise customers write it into procurement and vendor-risk contracts, particularly for SaaS and cloud vendors selling into mid-market or enterprise accounts. If a customer contract requires it, that requirement is contractual, not legal.

What Is SOC 2 in Simple Terms?

In plain terms, SOC 2 is an independent audit that checks whether a company actually does what it says it does to protect customer data. A CPA firm tests real controls, like access logs, backups, and monitoring, against the AICPA Trust Services Criteria, then issues an opinion. A SOC 2 Type 2 (SOC 2 Type II) report is the version that checks this over months, not just on one day.


Finding the right auditor matters as much as preparing your controls. At SOC2Auditors, we replace endless sales calls with a matching process. Get transparent pricing, timelines, and verified reviews to choose an audit firm for your company. Find your SOC 2 auditor at https://soc2auditors.org.