SOC 2 Type 2 for SaaS: Trust Services Criteria, Observation Periods, and Reading the Report

Enterprise buyers send SaaS vendors a security questionnaire, and one of the first lines asks for a current SOC 2 Type 2 report. A SOC 2 report is not a certificate. It is an attestation report in which a CPA firm gives an opinion on your controls, measured against criteria published by the American Institute of CPAs (AICPA). The report is long, it lists every exception the auditor found, and the buyer's security team will read it.

This guide covers what the criteria require, how the Type 1 and Type 2 periods work, the parts of a report that confuse both sellers and buyers (bridge letters, subservice organizations, complementary user entity controls, qualified opinions), and what audits cost according to a firm that performs them. For the controls themselves, see our SaaS security best practices guide. If you are the buyer reviewing a vendor's report, our SaaS vendor management guide covers where the review fits in the vendor lifecycle.

What the Trust Services Criteria cover

SOC 2 examinations use the AICPA's 2017 Trust Services Criteria (with revised points of focus, 2022). There are five categories:

The criteria are outcome statements. They do not tell you which controls to run. Each criterion comes with points of focus, which are examples of what an auditor may look for. The September 2022 revision updated those points of focus to reflect changes in technology and business practice, and the AICPA states that it did not change the criteria themselves. So a report issued in 2026 against the "2017 TSC" is current.

Most SaaS companies start with security alone and add availability and confidentiality when customer contracts promise uptime or confidential handling. Privacy is the most work and is usually added only when you deal with individuals directly rather than through business customers. The AICPA also publishes a mapping of the criteria to NIST SP 800-53, which helps if you already run a NIST-based program.

Type 1 and Type 2

A Type 1 report gives an opinion on whether your system description is fair and your controls are suitably designed as of a single date. A Type 2 report adds an opinion on whether the controls operated effectively throughout a period, and it includes the auditor's tests and results for each control.

The AICPA does not set a minimum period. Linford & Co says Type 2 reports typically cover six to twelve months, with a new report each year or half-year so customers have continuous coverage. A first Type 2 can cover a shorter window, which gets a report into buyers' hands sooner, but some security teams discount a report that covers only a few months.

Illustration of a first-time timeline for a SaaS company starting in January (the dates are ours, not a standard):

A Type 1 is optional. It gives sales something to share while the observation period runs, but it costs a second engagement, and buyers who asked for a Type 2 will still ask for it.

Controls must run for the whole period. If quarterly access reviews are one of your controls and one quarter's review was skipped, the auditor records an exception. Controls that run automatically (branch protection that blocks unreviewed merges, provisioning through an identity provider, alerts that open tickets) are easier to evidence than a spreadsheet someone has to remember to update.

Bridge letters

Report periods rarely line up with each customer's fiscal year. Linford's example: a report covering October 1 to September 30 leaves a customer with a calendar year three months short. To cover that gap, the vendor's management writes a bridge letter (also called a gap letter) on its own letterhead, stating that there have been no material changes to the system or its controls since the report period ended.

The auditor does not sign a bridge letter and gives no assurance on it. Linford notes that the AICPA's SOC guidance does not cover bridge letters, so there is no required format. If you are the buyer, treat a bridge letter as a management representation and ask when the next report will be issued. A bridge letter covering more than a few months usually means the vendor let its report lapse.

SOC 2, SOC 3, and ISO 27001

The AICPA describes SOC 3 as covering the same criteria as SOC 2, in a general use report that can be freely distributed. A SOC 3 omits the test results, so a buyer's security team will still ask for the SOC 2.

ISO 27001 certifies a management system rather than reporting on tests of individual controls, and it runs on a three-year certificate cycle with surveillance audits in between. The 2013 edition is no longer valid: the transition to ISO/IEC 27001:2022 closed on October 31, 2025, as SGS explains. Check the edition on any ISO certificate a vendor sends you. Many SaaS companies selling to both US and European enterprises end up with both a SOC 2 and ISO 27001, and a shared control set can serve both.

Subservice organizations: carve-out or inclusive

Almost every SaaS company relies on other providers to run its service: a cloud host, a payment processor, an email delivery service. In SOC 2 terms, a provider that performs controls you depend on is a subservice organization, and the report has to treat it one of two ways.

• Carve-out method: the report describes the subservice organization and the controls you expect it to perform, but the auditor does not test those controls. You are expected to monitor the provider, usually by reviewing its own SOC 2 report.
• Inclusive method: the provider's controls are described and tested as part of your report. This gives the reader a fuller picture but needs the provider's cooperation.

Carve-out is the norm for the large cloud providers, which publish their own SOC reports and do not take part in their customers' audits. Linford describes a fintech client that planned an inclusive report, found its provider would not support testing, and had to switch to carve-out partway through and strengthen its own monitoring.

For a buyer, carve-out means the vendor's report says nothing about whether AWS or Azure ran its controls. You need the provider's report as well, or at least evidence that your vendor reviewed it and followed up on any exceptions.

Complementary user entity controls

Every SOC 2 report lists complementary user entity controls (CUECs): things the customer must do for the vendor's controls to work. Typical examples in a SaaS report:

• The customer manages its own users' access and removes leavers promptly.
• The customer enables multi-factor authentication or single sign-on where the product supports it.
• The customer reviews audit logs and notifies the vendor of suspected security incidents.
• The customer protects API keys and credentials it is issued.

A buyer who skips this section can end up assuming the vendor covers something the report explicitly assigns to the customer. Linford's guidance on reviewing reports recommends that user entity management read the CUECs and map them to its own controls. A vendor writing the report should keep the list short and specific; a long list of vague CUECs reads as the vendor pushing its risk onto customers.

Exceptions and qualified opinions

A Type 2 report shows each control, the auditor's test, and the result. "No exceptions noted" is the goal. An exception means the test found a deviation, for example two of 25 sampled terminated employees kept access for longer than the policy allows. Management can add a response, which is unaudited.

The auditor's opinion can take four forms:

Linford says qualified opinions are quite common, often in a company's first examination or after staff turnover leaves a control unperformed. It compares a qualification to a significant deficiency or material weakness disclosure rather than to a going concern warning. A qualified opinion on availability matters less if you are buying a reporting tool that holds no production data. A qualification on logical access (CC6) at a vendor that will hold customer records matters a great deal.

What a SOC 2 costs

Fee estimates online come mostly from compliance software vendors and firms selling SOC 2 services. Linford & Co, which performs SOC audits itself, says SOC audit fees typically range from $20,000 to $150,000 with a median around $30,000, and that Big Four fees start in the low six figures. Its range covers SOC 1 and SOC 2 work. It lists scope, report type, the services provided, company size, number of locations, and the number of subservice providers as the main fee drivers, and it warns that a quote given without scoping questions tends to rise once the audit starts.

The audit fee is only part of the first-year cost. Budget separately for:

• readiness work, either internal time or a consultant (the firm that helps you prepare should not be the firm that audits you);
• a compliance automation platform, if you use one, which is a separate subscription from the audit;
• a penetration test, which most auditors and buyers expect to see;
• tools you may be missing, such as endpoint management, centralized logging, or a background check provider;
• engineering and management time during readiness and fieldwork.

Adding availability, processing integrity, or confidentiality usually adds modestly to the fee. Privacy adds the most.

Scoping decisions that save work

• Define the system as the production environment and the people and tools that can change it. Internal tools with no access to customer data can often stay out.
• Isolate production accounts from development and sandbox accounts so the auditor's population of changes and users is smaller.
• Choose criteria based on what your contracts already promise. Adding a category because a competitor has it means evidence you will have to produce every year.
• Pick your report period end date with your largest customers' year-ends in mind to reduce bridge letter requests.
• Put your data classification in order before the observation period starts; confidentiality criteria are hard to meet if you cannot say where confidential data lives. Our cloud data governance guide covers classification.

A buyer's checklist for reading a vendor's SOC 2

1. Is it a Type 2, and does the period end within the last 12 months? If not, is there a bridge letter, and when is the next report due?
2. Which criteria are in scope, and do they match what you are buying? A security-only report says nothing about availability commitments.
3. Does the system description cover the product and region you will use?
4. Which subservice organizations are carved out, and have you seen their reports?
5. Which CUECs apply to you, and who on your team owns each one?
6. What type of opinion was issued, and what exceptions appear in the test results?
7. Did management respond to the exceptions, and does the response describe a fix with a date?

Regulated buyers often have additional requirements on top of SOC 2; our AI regulatory compliance guide covers some of the newer ones.

This article is general information, not legal, audit, or security advice. Audit fees and standards are as of September 2026. Engage a licensed CPA firm for a SOC 2 examination and confirm current AICPA guidance before scoping one.