SOC 2 Guide: Type I, Type II and the Trust Services Criteria

A SOC 2 report is only as useful as its scope, its period and the exceptions buried in section 4, and both the companies that commission them and the customers that read them routinely miss all three. SOC 2 is an attestation engagement performed by a licensed CPA firm under AICPA standards, reporting on a service organisation's controls against the Trust Services Criteria. This guide covers Type 1 and Type 2 reports, the five categories and the nine common criteria series, how to scope the system and handle subservice organisations, complementary user entity controls, readiness, evidence, exceptions and bridge letters. It is written for security and compliance leads preparing a first or renewal report, and for the vendor risk teams who have to read other organisations' reports and decide whether to rely on them.

Key takeaways

• SOC 2 is an attestation, not a certification. A CPA firm gives an opinion on management's description and controls; there is no pass mark, no certificate and no SOC 2 "compliant" status issued by the AICPA.
• Type 2 is the report customers want. Type 1 covers design at a point in time; Type 2 covers design and operating effectiveness throughout a specified period, with the auditor's tests and results listed.
• Security is mandatory, the other four categories are chosen. The common criteria (CC1 to CC9) form the Security category; Availability, Processing Integrity, Confidentiality and Privacy add their own criteria when included.
• Scope decisions travel with the report. Carved-out subservice organisations, narrow system boundaries and complementary user entity controls all shift work back to the reader, and experienced customers notice.
• CC6 is an identity audit. Logical access testing covers provisioning, removal, least privilege and reviews, and auditors increasingly sample service accounts, API keys and other non-human identities, not only staff accounts.

What a SOC 2 report is, and how it differs from SOC 1 and SOC 3

The AICPA describes SOC as "a suite of service offerings CPAs may provide" so that users can "assess and address the risks associated with outsourcing services". The suite shares a vocabulary (service organisation, user entity, service auditor, subservice organisation) but each report answers a different question and has different distribution rules.

• SOC 1 vs SOC 2: if customers' auditors rely on you for financial reporting (payroll, billing, fund administration, claims processing), they need a SOC 1. If customers care about whether you protect their data and keep the service running, they need a SOC 2.
• SOC 2 vs SOC 3: the SOC 3 is a marketing and procurement convenience. It cannot replace the SOC 2 for a vendor risk assessment because it omits the control descriptions, tests and exceptions.

Type 1 vs Type 2

Decision guidance: a start-up facing its first enterprise deal usually commissions a Type 1 and starts the Type 2 period immediately afterwards, so the first Type 2 follows within a year. An organisation that already operates mature controls with retained evidence can go straight to a Type 2 and avoid paying for a report most buyers will discount. Periods of six to twelve months are common; some first Type 2 reports cover about three months, which buyers accept as a starting point but not as a steady state. Once reporting, keep periods back to back so there is no uncovered gap.

The Trust Services Criteria

The criteria are the AICPA's 2017 Trust Services Criteria, reissued with revised points of focus in 2022. The criteria did not change in 2022; the points of focus did. Points of focus help design and evaluate controls, and the TSC "does not require that every point of focus be met". The five categories are Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is always in scope and consists of the common criteria: the 17 COSO internal control principles plus IT-specific series.

• Availability: capacity, backups, recovery testing and environmental protections. Add it when contracts carry uptime commitments.
• Confidentiality: identification, protection and disposal of information designated as confidential. Common for B2B services holding customer business data.
• Processing Integrity: complete, valid, accurate and timely processing. Relevant to payment, payroll, data pipelines and calculation services.
• Privacy: notice, choice, collection, use, retention and disclosure of personal information. Many organisations cover privacy through a GDPR programme instead. See the GDPR Compliance Guide for Security Teams.

Scoping the system: boundaries, subservice organisations and CUECs

A SOC 2 reports on a system, not a company. Management writes the system description against the 2018 Description Criteria (DC Section 200): services provided, principal service commitments and system requirements, components (infrastructure, software, people, procedures, data), incidents, subservice organisations and complementary controls. The boundary you draw decides what the auditor tests and what the reader can rely on.

Subservice organisations: carve-out vs inclusive

• Carve-out method: the subservice organisation's controls (for example the cloud provider's data centre and hypervisor controls) are excluded from testing. The description lists the complementary subservice organisation controls (CSOCs) that management assumes the subservice organisation performs. The reader must then obtain and read the subservice organisation's own SOC report. This is the norm for hyperscale cloud providers.
• Inclusive method: the subservice organisation's relevant controls are described and tested within your report. It needs that organisation's cooperation and its own assertion, so it suits group companies or tightly contracted managed service providers.
• What carve-out still requires of you: monitoring the subservice organisation is your control. Auditors test that you obtain and review its SOC report, check its CUECs against your own controls and follow up its exceptions, typically under CC9.

Complementary user entity controls

CUECs are controls the service organisation assumes its customers operate for the criteria to be met. Typical examples: the customer removes leavers from its tenant, enforces MFA for its own users, manages its own API keys, restricts who can administer integrations and reviews its own audit logs. CUECs are not optional small print. If a customer does not perform them, the protection the report describes does not exist for that customer.

Narrowing scope and customer acceptance

Organisations narrow scope to cut cost: one product instead of the platform, or production but not the corporate network. That is legitimate when the description is honest, but experienced customers check three things: whether the product they buy sits inside the boundary, whether the corporate identity provider and endpoint fleet that administer production are included, and whether critical subservice organisations are carved out without evidence of monitoring. A report that leaves out the identity provider used to reach production is the scope gap buyers most often reject, because almost every control in CC6 depends on it.

Where identity fits: CC6 and non-human identities

The CC6 series is where most exceptions are found, and most CC6 tests are identity tests. CC6.1 covers logical access security over protected information assets; CC6.2 requires registering and authorising users before issuing credentials and removing credentials when access is no longer authorised; CC6.3 covers authorising, modifying and removing access based on roles, least privilege and segregation of duties; CC6.6 covers threats from outside the system boundary; CC6.7 covers restricting the transmission, movement and removal of information. "Users" in the auditor's population increasingly includes non-human accounts.

• Service accounts: auditors ask for the full population of service accounts in scope and test that each has an owner and appears in the access review. Orphaned or shared service accounts are a frequent exception. See the Service Account Security Guide.
• API keys and tokens: keys issued to integrations and CI/CD pipelines are credentials under CC6.2 and should follow the same issue, review and revoke lifecycle as user accounts. See the API Key Management Guide.
• Access reviews: reviews that only cover human users of the IdP leave database users, cloud IAM roles and SaaS admin accounts untested. See the Access Reviews Guide.

How to implement: readiness to first Type 2

1. Decide the report and scope (weeks 1 to 2): list the customer contracts and questionnaires that ask for SOC 2, choose categories (Security plus whatever contracts imply), draw the system boundary, and list subservice organisations with the method for each.
2. Run a readiness assessment (weeks 2 to 6): map existing controls to each criterion, identify gaps and decide who owns each control. A readiness assessment can be done by the audit firm or by a separate adviser; independence rules restrict the auditor from designing or operating your controls.
3. Remediate and write the description (weeks 6 to 16): fix gaps, write policies people actually follow, configure evidence retention (ticket workflows, log retention, review exports) and draft the system description including CUECs and CSOCs.
4. Pilot the evidence: run one month of every recurring control (access review, vulnerability triage, change approval, vendor review) and check the evidence would survive a sample request.
5. Type 1 or straight to period start: if sales pressure needs a report now, take a Type 1 at the period start date. Otherwise begin the Type 2 period.
6. Operate through the period: run controls on their stated frequency, keep a control calendar and review evidence monthly. If a control fails, document it, remediate and raise it with the auditor rather than hoping it is not sampled.
7. Fieldwork and report: the auditor requests populations, selects samples, inspects evidence and interviews control owners. Management reviews the draft, responds to exceptions and signs the assertion.
8. Roll forward: start the next period the day after the last one ends and issue bridge letters for the gap between the period end and the next report.

Rolling back a control change: if a new tool or process replaces a control mid-period (for example moving from manual access reviews to an IGA platform), keep the old control operating until the new one has run at least one full cycle, and tell the auditor so both can be tested for the portions of the period they covered.

Evidence, exceptions, opinions and bridge letters

• Populations must be complete: for a sampled control the auditor needs the complete population of events, and will test how that list was produced. Exports from the system of record, with the query used, beat screenshots of a filtered view.
• Configured is not operated: logging being enabled does not prove administrator activity was logged and reviewed. Keep evidence of the review.
• Exceptions: a deviation found in testing is listed in section 4 with management's response. One late leaver removal in a sample of 25 is common and rarely changes the opinion; a pattern across controls can.
• Opinion types: unmodified (clean), qualified (specific criteria not met or scope limited), adverse (pervasive failure) and disclaimer (insufficient evidence). Procurement teams often escalate a qualified opinion automatically.
• Bridge (gap) letters: a letter from service organisation management, not the auditor, stating that there have been no material changes to the system or controls since the period end. Readers should accept it for a short gap, typically up to three months, and ask for the next report beyond that.

Reading another organisation's SOC 2 report

1. Check the auditor is a licensed CPA firm, and the report type, period and date. The AICPA has warned that SOC services "should be thoroughly evaluated by service organizations and CPA firms", which applies to reports produced unusually quickly or cheaply.
2. Confirm the product and region you buy sit inside the system description, and list carved-out subservice organisations whose reports you also need.
3. Read the opinion, then every section 4 exception with management's response.
4. Copy the CUECs into your own control register with owners, and ask for a bridge letter if the period ended more than three months ago.

Measuring the programme

• Exceptions per report and per series: target zero repeat exceptions year on year; CC6 exceptions are the leading indicator.
• Leaver removal time: median and maximum hours from HR termination to account disablement, for humans and for the service accounts and keys they owned.
• Access review completion: percentage of in-scope systems, including non-human accounts, reviewed on schedule with revocations closed.
• Evidence readiness: percentage of recurring controls with evidence filed within five working days of the control date.
• Coverage gap days: days in the year not covered by a report period or a bridge letter, target zero.
• CUEC adoption: for consumers of SOC reports, percentage of critical suppliers whose CUECs are mapped to internal owners.

Monitor MFA gaps, dormant accounts and unrotated keys weekly rather than at fieldwork. See the Identity Security Metrics Guide.

Framework mapping

SOC 2 vs ISO 27001: SOC 2 is an attestation report on a defined system over a period, read mainly in North America; ISO/IEC 27001 is a certification of a management system, with a public certificate, recognised worldwide. SOC 2 tells a reader how specific controls performed; ISO 27001 tells a reader that a risk-based management system exists and is audited annually. Organisations selling globally often hold both and write controls once, mapped to each.

Common failure patterns

• Ignoring CUECs on the customer side: a provider's report assumes customers enforce MFA and manage their own credentials. The Snowflake breach showed what happens when customer accounts relied on passwords alone: infostealer credentials without MFA unlocked 165 customer data warehouses.
• Service accounts outside the access review: human accounts pass review while service accounts, with broad access and no owner, are never sampled. In the Okta support system breach, a service account credential saved in a personal Google profile exposed 134 customers.
• Not acting on a supplier's incident: carve-out puts supplier monitoring on you. After the Okta incident, the Cloudflare breach came through four credentials that had not been rotated.
• Third-party tokens missing from scope: OAuth integrations and their tokens sit between two systems and in neither report. The Salesloft Drift breach turned one chatbot integration's tokens into access to hundreds of Salesforce tenants.
• Policy written for the auditor: a quarterly review that the team cannot sustain produces exceptions in the second quarter. Write frequencies you will meet and automate evidence capture.

Practitioner checklist

• Confirm with sales and legal which customers need SOC 1, SOC 2 or SOC 3 before choosing the engagement.
• Include the identity provider, CI/CD and endpoint management used to administer production inside the system boundary.
• Choose carve-out or inclusive per subservice organisation and evidence your monitoring of each.
• Build an inventory of service accounts, API keys and integration tokens with owners, and include them in access reviews.
• Pilot every recurring control for a month before the Type 2 period starts.
• Keep complete, system-generated populations for every sampled control.
• Run back-to-back periods and issue bridge letters for gaps of up to three months.
• As a reader, log exceptions, carve-outs and CUECs from every critical supplier's report in your own risk register.

Standards and references

• AICPA and CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• AICPA and CIMA: SOC 2 Reporting on an Examination of Controls at a Service Organization
• AICPA and CIMA: System and Organization Controls, SOC Suite of Services
• US Department of Labor, ERISA Advisory Council: Appendix A, comparison of SOC examinations
• EY: AICPA revises guidance on applying its Trust Services Criteria and SOC 2 Description Criteria
• Linford and Co: SOC 2 Security Trust Services Criteria
• Linford and Co: Complementary User Entity Controls and SOC Reports
• Withum: SOC 2 vs SOC 3, what is the difference

Related NHI Mgmt Group resources: Service Account Security Guide · Access Reviews Guide · Third-Party Access Guide · Joiner-Mover-Leaver Guide · Secrets Management Guide