SOC 2 Attestation Types and Report Structure

1. Orienting to SOC 2 Attestations

In the previous modules, you learned what SOC 2 is and how the Trust Services Criteria (TSC) work. Now we focus on two practical questions:

1. What kind of SOC 2 attestation is this? (Type I vs Type II)
2. What is actually inside a SOC 2 report, and who is it for?

This matters because:

• Security teams at customers use SOC 2 to evaluate your controls.
• Sales and legal teams use SOC 2 to answer due diligence questionnaires.
• Auditors and regulators use SOC 2 to gain assurance about outsourced services.

As of today (December 2025), SOC 2 continues to be governed by the AICPA Attestation Standards (AT-C sections 105 & 205) and the 2017 Trust Services Criteria (with updates issued over time via AICPA points of focus and guidance). The basic structure of SOC 2 reports and the distinction between Type I and Type II have remained stable.

In this module you will:

• Distinguish SOC 2 Type I vs Type II and when each is appropriate.
• Walk through the main sections of a SOC 2 report.
• Understand who may use a SOC 2 report and why it is restricted-use.
• Contrast SOC 2 with SOC 3, which is designed for public distribution.

2. SOC 2 Type I vs Type II: Core Difference

The key difference between Type I and Type II is:

> Type I = a point in time

> Type II = over a period of time

More precisely:

• SOC 2 Type I
• Scope: Design of controls relevant to selected Trust Services Criteria.
• Time: As of a specific date (e.g., "as of June 30, 2025").
• Question answered: "Were the controls suitably designed on that date?"
• No opinion on whether controls operated effectively over time.

• SOC 2 Type II
• Scope: Design and operating effectiveness of controls.
• Time: Over a period of time, commonly 3–12 months, with 6–12 months most typical in practice.
• Question answered: "Were the controls suitably designed and did they operate effectively throughout the period?"
• Includes tests of controls and results for that period.

Both are attestation engagements performed by an independent CPA firm following AICPA standards, but they offer different levels of assurance.

Think of it like this:

• Type I is like a snapshot – a photograph of your control environment on one day.
• Type II is like a video – showing whether controls worked over time.

3. Practical Scenarios: When Type I vs Type II?

Consider these real-world situations:

Scenario A: Early-stage SaaS startup

• The company just implemented new security controls (SSO, logging, change management) 2 months ago.
• A big prospect asks for SOC 2.
• The startup has no 6–12 month history of operating those controls.

Most realistic path:

• Start with a SOC 2 Type I to show that controls are designed properly as of a specific date.
• After 6–12 months of operating those controls, move to a Type II.

---

Scenario B: Mature cloud provider

• Has had a SOC 2 Type II for the last 3 years.
• Customers are large financial institutions.
• They require evidence that controls consistently operate over time.

Most realistic path:

• Maintain annual SOC 2 Type II reports covering rolling 12-month periods.
• Type I would be considered insufficient for most of their customers.

---

Scenario C: Company changing hosting model

• A company is moving from on-premises data centers to a major cloud provider.
• Controls are being redesigned.

Possible approach:

• Obtain a Type I report for the new environment once controls are fully designed and implemented.
• Then obtain a Type II report once there is enough operating history.

In practice, customers usually prefer Type II because it demonstrates that controls were not only designed well but also worked in real life over time.

4. Thought Exercise: Choosing the Right Type

Imagine you are the security lead for a SaaS company that provides an HR platform.

Facts:

• You launched 8 months ago.
• You implemented most security controls 6 months ago.
• You have decent logging and access management, but some processes are still being refined.
• A new enterprise customer asks for “SOC 2 Type II, last 12 months”.

Questions to think about (write down brief answers):

1. Can you honestly support a 12-month Type II period right now? Why or why not?
2. What kind of SOC 2 engagement might you pursue this year to satisfy the customer as much as possible?
3. What internal steps would you take over the next 6–12 months to be ready for a strong Type II later (think: documentation, evidence collection, monitoring)?

After you answer, compare your reasoning to this checklist:

• The period for Type II must match actual control operation history.
• You may negotiate with the customer for a shorter period Type II (e.g., 6 months) or Type I now, Type II later.
• Preparing for Type II often requires:
• Clear policies and procedures.
• Consistent evidence collection (tickets, logs, approvals).
• Regular internal reviews of control performance.

5. Intended Users and Restricted Use

A SOC 2 report is not a public document. It is a restricted-use report under AICPA standards.

Intended users typically include:

• Management of the service organization (the company being audited).
• User entities (your customers) and their auditors.
• Sometimes regulators or business partners under NDA.

Why restricted?

• The report contains detailed descriptions of systems and controls, sometimes including:
• Network architecture and data flows.
• Types of monitoring tools and configurations.
• Incident response practices.
• It often includes control exceptions (failures) and how they were handled.
• Misinterpretation risk: People without the right background might misread technical findings.

SOC 2 reports therefore include a restricted-use paragraph stating that the report is intended only for specified parties and not for general distribution or unauthorized users.

6. Core Sections of a SOC 2 Report

Most SOC 2 reports follow a standard structure. The exact layout can vary by firm, but the core sections are:

1. Independent Service Auditor’s Report (Opinion Letter)

• Written by the CPA firm.
• States what was examined (system, TSC, Type I or II, and period).
• Provides the auditor’s opinion, e.g.:
• Unmodified (clean) opinion – controls were suitably designed (and operating effectively, for Type II), in all material respects.
• Qualified opinion – some significant exceptions.
• Adverse or disclaimer – rare, serious issues or insufficient evidence.
• Includes the restricted-use language.

1. Management’s Assertion

• A statement from management that:
• The system description is fairly presented.
• Controls were suitably designed (Type I & II).
• Controls operated effectively throughout the period (Type II only).
• Management takes responsibility for the system and controls.

1. System Description (sometimes called Description of the System)

• Prepared by the service organization’s management.
• Describes, at a high but meaningful level:
• Services provided.
• System boundaries (in-scope components, data flows).
• Infrastructure, software, people, procedures, and data.
• Control environment and risk assessment processes.
• Subservice organizations (e.g., cloud providers) and whether they are carve-out or inclusive.

1. Controls, Tests of Controls, and Results (Type II only)

• A table listing each control, the auditor’s test procedure, and the results.
• Example columns:
• Control ID and description.
• Trust Services Criteria reference (e.g., CC6.1).
• Test performed (inspection, observation, re-performance, inquiry).
• Results (no exceptions / exceptions noted).

1. Complementary User Entity Controls (CUECs)

• Controls that customers are expected to operate for overall objectives to be met.
• Example: “User entities are responsible for managing user access within their own SSO/IdP.”

1. Complementary Subservice Organization Controls (CSOCs) (if applicable)

• Controls the subservice organization (like a cloud provider) is expected to operate.
• Important when using a carve-out method.

Not every report labels sections identically, but these elements are consistently present in SOC 2 reports issued under current AICPA guidance.

7. Visual Walkthrough: How Different Audiences Read a SOC 2

Imagine the SOC 2 report as a book with several chapters. Different readers care about different chapters.

1. Independent Service Auditor’s Report (Opinion Letter)

• Who cares most?
• Customer CFOs, internal auditors, and external auditors.
• What they look for:
• Is the opinion unmodified (clean)?
• What period is covered (e.g., 1 Oct 2024 – 30 Sep 2025)?
• Which Trust Services Categories are in scope (Security only? Security + Availability?)

2. Management’s Assertion

• Who cares most?
• Auditors and compliance officers.
• What they look for:
• Exact wording of management’s claims.
• Confirmation that management accepts responsibility for controls.

3. System Description

• Who cares most?
• Security engineers, architects, risk analysts.
• What they look for:
• Architecture: What is in scope? Which data centers or cloud regions?
• Data flows: How data moves between users, applications, and storage.
• Subservice organizations: Which third parties are relied on (AWS, Azure, payment processors)?

4. Controls, Tests, and Results (Type II)

• Who cares most?
• Customer security teams and auditors.
• What they look for:
• Specific controls that match their risk concerns (e.g., logical access, vulnerability management).
• Any exceptions and management’s responses or remediation.

5. CUECs & CSOCs

• Who cares most?
• Customer security/compliance teams.
• What they look for:
• What they must do on their side to rely on the report.
• How responsibilities are split between the service organization and its subservice providers.

If you visualize it:

• The front of the report (opinion, assertion) is about high-level assurance.
• The middle (system description) is about understanding the environment.
• The back (tests and CUECs) is about detailed evidence and shared responsibility.

8. Quick Check: Type I vs Type II

Test your understanding of the difference between SOC 2 Type I and Type II.

9. SOC 2 vs SOC 3: Public vs Restricted

You will often see companies advertise: “We have a SOC 2 Type II and a SOC 3 report.” These are related but different.

SOC 2

• Level of detail: High – includes system description, detailed controls, tests, and results.
• Use: Restricted – for customers, their auditors, management, and certain other specified parties.
• Trust Services Criteria: Based on the same TSC (Security, Availability, etc.).

SOC 3

• Level of detail: Summary – no detailed control tests or exceptions.
• Use: Designed for general distribution – can be posted on a website, shared in marketing materials.
• Content: High-level description of the system and the auditor’s general conclusion on meeting the TSC.

Think of it this way:

• SOC 2 is the detailed medical record – private, for professionals.
• SOC 3 is the clean bill of health certificate – public, for anyone to see.

As of 2025, organizations commonly:

• Use SOC 2 to satisfy vendor risk assessments and audits.
• Use SOC 3 as a marketing and trust signal on their website, often alongside a SOC 2 under NDA for serious prospects.

10. Quick Check: SOC 2 vs SOC 3

Decide which statement about SOC 3 is accurate.

11. Flashcards: Key Terms Review

Flip these cards (mentally or on paper) to reinforce the main concepts from this module.

12. Apply It: Reading a SOC 2 Like a Practitioner

Imagine you are given a SOC 2 Type II report for a cloud-based CRM vendor you want to use. You have 10–15 minutes to do an initial review.

Task: Draft a short checklist (5–8 bullets) of what you would scan for in each of these sections:

1. Independent Service Auditor’s Report

• What do you need to confirm about the opinion and period?
• How will you verify which Trust Services Categories are covered?

1. System Description

• What details about data location, subservice organizations, and system boundaries are crucial for your risk assessment?

1. Controls, Tests, and Results

• How will you identify high-risk controls (e.g., access, change management, incident response)?
• How will you evaluate the significance of any exceptions?

1. CUECs

• What responsibilities do you (as the customer) need to accept and implement in your own environment?

Write your checklist now. Then compare it against this mini-reference:

• Opinion: unmodified vs qualified; period aligns with your planned usage.
• Scope: includes the Trust Services Categories relevant to your risk (e.g., Security + Availability for uptime-critical apps).
• System: data location, key third parties, in-scope regions and services.
• Controls: coverage of identity & access management, logging/monitoring, change management, backup/recovery, incident response.
• Exceptions: frequency, severity, and whether remediation steps are described.
• CUECs: configurations you must set (e.g., SSO, MFA), processes you must operate (e.g., user access reviews).