8.2 The System and Organization Controls (SOC) Reporting Suite
Key Takeaways
- The AICPA SOC reporting suite encompasses five distinct engagement frameworks: SOC 1 (ICFR focus under AT-C 320), SOC 2 (Trust Services Criteria focus under AT-C 205), SOC 3 (general public summary under Trust Services Criteria), SOC for Cybersecurity (entity-wide risk management), and SOC for Supply Chain.
- SOC 1 engagements address controls impacting user entities' internal control over financial reporting (ICFR), whereas SOC 2 engagements evaluate technology and operational controls against the Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy).
- SOC 1 and SOC 2 reports are designated as restricted-use reports under AU-C 905 and AT-C 105, legally and ethically restricting their distribution solely to service organization management, user entities, and their independent user auditors.
- A SOC 3 report evaluates the exact same subject matter and criteria as a SOC 2 report but excludes detailed descriptions of control activities, test procedures, and test results, permitting unrestricted general public distribution for marketing and vendor assurance.
- SOC for Cybersecurity is an entity-wide engagement evaluating an organization's cybersecurity risk management program (utilizing Description Criteria and Control Criteria such as the TSC or NIST CSF) designed for general distribution to boards, investors, and business partners.
The System and Organization Controls (SOC) Reporting Suite
Quick Summary: The AICPA System and Organization Controls (SOC) suite comprises specialized attestation reports designed to provide transparency and assurance regarding outsourced business processes, IT infrastructure, and enterprise risk management. Service organizations, user entities, and independent auditors must differentiate between financial-reporting controls (SOC 1 / AT-C 320), operational and data security controls (SOC 2 / AT-C 205), public marketing summaries (SOC 3), and enterprise-wide assessments (SOC for Cybersecurity and SOC for Supply Chain). Rigorous distribution restrictions under AU-C 905 protect sensitive architectural and control details in SOC 1 and SOC 2 reports while enabling general distribution for SOC 3 and SOC for Cybersecurity.
1. Architectural Taxonomy of the SOC Reporting Family
In modern corporate ecosystems, enterprises outsource critical functions—including payroll, medical billing, loan servicing, cloud hosting, and software delivery—to specialized third-party service organizations. While outsourcing transfers operational execution, it does not transfer accountability. Corporate management and boards remain fully responsible for the governance, security, and financial accuracy of outsourced workflows.
To standardize third-party assurance, the AICPA developed the System and Organization Controls (SOC) framework (originally termed Service Organization Controls). Over time, the framework expanded beyond vendor service organizations to encompass enterprise-wide organizational resilience, giving rise to the modern suite:
AICPA SOC REPORTING SUITE
│
┌────────────────────────┬───────────┴───────────┬────────────────────────┐
▼ ▼ ▼ ▼
SOC 1 SOC 2 SOC 3 ORGANIZATIONAL SOC
(ICFR Relevance) (Trust Services) (Public Summary) │
AT-C 320 AT-C 205 AT-C 205 ┌─────────────┴─────────────┐
Restricted-Use Restricted-Use General Public ▼ ▼
User Auditors B2B Customers Marketing SOC for Cybersecurity SOC for Supply
(Enterprise-Wide) Chain (Ops)
2. Comprehensive SOC Suite Master Comparison Matrix
Understanding the exact distinctions across the SOC reporting suite is among the most heavily tested areas on the CPA ISC examination. Auditors must instantly match subject matters, governing standards, criteria, and distribution scopes:
| Dimension | SOC 1 | SOC 2 | SOC 3 | SOC for Cybersecurity | SOC for Supply Chain |
|---|---|---|---|---|---|
| Primary Purpose | Assist user entities' independent financial statement auditors in evaluating internal controls | Provide business customers with assurance over technology, security, and operational controls | Provide a high-level public marketing and trust seal without technical operational details | Evaluate an entity's enterprise-wide cybersecurity risk management program | Evaluate manufacturing, production, or logistics processes against operational disruption |
| Subject Matter | Controls at a service organization relevant to user entities' Internal Control over Financial Reporting (ICFR) | Controls relevant to one or more Trust Services Criteria (TSC): Security, Availability, Integrity, Confidentiality, Privacy | Same subject matter as SOC 2 (evaluated against Trust Services Criteria) | Management's description of its cybersecurity risk management program and effectiveness of controls | Management's description of its supply chain system and manufacturing/distribution controls |
| Governing Standard | SSAE 18 / AT-C 320 (incorporating AT-C 105 & AT-C 205) | SSAE 18 / AT-C 205 (incorporating AT-C 105) | SSAE 18 / AT-C 205 (incorporating AT-C 105) | SSAE 18 / AT-C 205 | SSAE 18 / AT-C 205 |
| Applicable Criteria | Management-developed Control Objectives relevant to user ICFR | AICPA Trust Services Criteria (TSP 100) | AICPA Trust Services Criteria (TSP 100) | Description Criteria + Control Criteria (e.g., TSC or NIST CSF) | Description Criteria for Supply Chain + Trust Services Criteria |
| Section IV (Test Results) Included? | Yes (Detailed control tests, sample sizes, and deviations) | Yes (Detailed control tests, test procedures, and test results) | No (Section IV is completely omitted) | No (Reports high-level control effectiveness; no granular test logs) | Optional / Dependent on user agreement |
| Intended Users | User entity management, user entity financial auditors, service organization management | Management of user entities, business partners, prospective clients, regulators | Existing and prospective customers, general public, marketing audiences | Board of directors, audit committees, investors, business partners, regulators | Customers, supply chain partners, logistics managers, regulators |
| Distribution Scope | Restricted-Use (AU-C 905 / AT-C 105) | Restricted-Use (AU-C 905 / AT-C 105) | General Public Distribution (Unrestricted) | General Distribution (Unrestricted) | Typically Restricted-Use to supply chain partners |
3. The ICFR Divide: SOC 1 vs. SOC 2 Demarcation
The fundamental dividing line between a SOC 1 and a SOC 2 engagement is financial statement relevance:
When is a SOC 1 Required?
A service organization requires a SOC 1 examination when its software, infrastructure, or operational services execute, record, process, or calculate transactions that flow directly into its client organizations' financial statements. If a failure or calculation error inside the service organization could cause a material misstatement on a customer's general ledger, balance sheet, or income statement, the service affects Internal Control over Financial Reporting (ICFR).
- Examples: Third-party payroll processors (e.g., calculating tax withholdings, issuing direct deposits, generating payroll journal vouchers); 401(k) recordkeepers and pension administrators (processing employee benefit contributions and investment allocations); credit card transaction clearinghouses; medical claims billing processors; loan and mortgage servicing platforms.
When is a SOC 2 Required?
A service organization requires a SOC 2 examination when its services provide technological, hosting, or operational processing where security, availability, confidentiality, or data privacy are critical, but the transactions do not directly affect customer balance sheets or general ledgers.
- Examples: B2B Software-as-a-Service (SaaS) platforms (e.g., project management, video conferencing, customer support ticketing); cloud infrastructure providers (IaaS/PaaS) hosting non-financial applications; data center colocation facilities; email and communication gateways.
THE ICFR RELEVANCE DECISION TREE
Does the outsourced service initiate, authorize, process,
record, or calculate transactions that flow into client
financial statements?
│
┌────────────────┴────────────────┐
▼ ▼
YES NO
│ │
Direct Financial Statement Operational / Technology
Relevance Services
│ │
▼ ▼
SOC 1 SOC 2
(AT-C 320) (AT-C 205)
Governed by ICFR Impact Governed by Trust Services
Supports Financial Audits Criteria (Security, etc.)
[!TIP] The Multi-Report Enterprise (Dual SOC 1 & SOC 2): Major enterprise cloud vendors—such as Amazon Web Services (AWS), Microsoft Azure, Workday, and SAP—commission both SOC 1 and SOC 2 examinations. An enterprise ERP vendor hosts general ledgers (requiring a SOC 1 for user financial auditors) while operating massive multi-tenant cloud data centers requiring assurance over security, availability, and confidential data storage (requiring a SOC 2 for chief information security officers).
4. Distribution Restrictions: Restricted-Use (AU-C 905) vs. General Public Distribution
A critical legal, professional, and ethical distinction within the SOC suite governs who is permitted to receive and read the report. Professional standards enforce strict rules under AU-C Section 905 (Alert That Restricts the Use of the Auditor's Written Communication) and AT-C Section 105.
Why SOC 1 and SOC 2 Reports are Strictly Restricted-Use
Both SOC 1 and SOC 2 reports contain a mandatory Restricted-Use Paragraph in the independent service auditor's report (Section I). The language explicitly restricts report distribution to specified parties: management of the service organization, current customers/user entities, and user entities' independent financial statement auditors.
Restricted-use is enforced for two paramount reasons:
- Technical Understanding Requirement: Intended users must possess an understanding of the relationship between service organization controls and user entity controls. A reader must evaluate Complementary User Entity Controls (CUECs) to understand how the system operates securely.
- Security & Vulnerability Exposure: Section III (system description) and Section IV (service auditor's test results) provide exhaustive architectural blueprints of the service organization's environment—including network topology diagrams, database versions, identity protocols, and granular control exceptions. If released publicly, malicious actors could analyze Section IV test exceptions to identify exploitable zero-day vulnerabilities in the vendor's perimeter.
The Purpose and Role of SOC 3 Reports
Because enterprise SaaS companies frequently encounter prospective clients who demand third-party assurance prior to signing commercial contracts, the AICPA established the SOC 3 report.
- A SOC 3 report evaluates the exact same subject matter and criteria as a SOC 2 report (the Trust Services Criteria).
- However, a SOC 3 report completely omits Section IV (the service auditor's detailed tests of controls and results) and presents only a high-level summary of the system description.
- Consequently, a SOC 3 report does not expose confidential technical blueprints and is classified as a General Distribution (General Use) document. SaaS vendors can post SOC 3 reports on public marketing websites, attach them to sales brochures, and distribute them freely to prospective buyers.
SOC 2 VS. SOC 3 STRUCTURAL ARCHITECTURE
SOC 2 TYPE 2 (Restricted Use) SOC 3 (General Public Use)
┌──────────────────────────────────────────────┐ ┌──────────────────────────────────────────────┐
│ Section I: Independent Service Auditor Report│ │ Section I: Independent Service Auditor Report│
│ (Contains AU-C 905 Restricted-Use Warning) │ │ (General public distribution permitted) │
├──────────────────────────────────────────────┤ ├──────────────────────────────────────────────┤
│ Section II: Management Assertion │ │ Section II: Management Assertion │
├──────────────────────────────────────────────┤ ├──────────────────────────────────────────────┤
│ Section III: Detailed System Description │ │ Section III: High-Level System Summary │
│ (Full network blueprints, CUECs, CSOCs) │ │ (Marketing-safe; no sensitive IP) │
├──────────────────────────────────────────────┤ └──────────────────────────────────────────────┘
│ Section IV: Auditor's Tests & Results │
│ (Granular testing procedures & exceptions) │ [SECTION IV IS COMPLETELY OMITTED]
└──────────────────────────────────────────────┘
5. Organizational SOC: SOC for Cybersecurity & SOC for Supply Chain
While SOC 1, 2, and 3 focus on third-party service organizations, modern board governance demands assurance over enterprise-wide operational posture. In response, the AICPA introduced the Organizational SOC family.
SOC for Cybersecurity
A SOC for Cybersecurity report is an enterprise-wide attestation examination designed to provide board directors, audit committees, investors, analysts, and business partners with independent assurance regarding an organization's cybersecurity risk management program.
- Not Limited to Service Organizations: Any organization (public corporation, private entity, non-profit, or government agency) can commission a SOC for Cybersecurity examination, regardless of whether it processes third-party data.
- Dual Criteria Architecture: The examination evaluates management's cybersecurity program against two distinct criteria sets:
- Description Criteria: Governs how management describes its cybersecurity governance, risk assessment, monitoring, and incident response mechanisms.
- Control Criteria: Governs the design and operating effectiveness of controls implemented to achieve cybersecurity objectives (typically the AICPA Trust Services Criteria or the NIST Cybersecurity Framework [CSF]).
- General Distribution: Unlike SOC 2, a SOC for Cybersecurity report is an unrestricted general-use report, enabling public companies to furnish the report to shareholders, credit rating agencies, and insurance underwriters.
SOC for Supply Chain
Global supply chain volatility, vendor counterfeiting, and geopolitical disruptions prompted the creation of the SOC for Supply Chain framework. Designed for manufacturers, producers, and logistics providers, this examination evaluates controls governing the operational integrity and resilience of manufacturing and distribution systems, mitigating risks of supply disruption, quality failure, or physical component tampering.
6. Practical Implementation Scenarios & Core Exam Traps
Practical Scenario 1: The SaaS Marketing Violation
A cloud-based healthcare CRM vendor receives an unmodified SOC 2 Type 2 report. To demonstrate its security posture to prospective buyers, the Vice President of Marketing posts the complete 90-page SOC 2 report on the company's public website behind a simple email-capture form.
- Auditor Evaluation: This action represents a severe violation of AICPA attestation standards and contractual non-disclosure agreements. The SOC 2 report contains restricted-use language under AU-C 905 and discloses detailed test procedures and infrastructure diagrams. Management must immediately take down the SOC 2 report and commission or publish a SOC 3 report, which is specifically engineered for general public marketing.
Practical Scenario 2: Misidentifying Financial Impact
A regional bank utilizes an outsourced vendor to shred physical records and recycle confidential paper waste. The bank's external financial statement audit team requests a SOC 1 Type 2 report from the shredding vendor.
- Auditor Evaluation: The financial statement audit team is mistaken. Physical document shredding is an operational security and compliance control (governed by SOC 2 Confidentiality or NAID certifications), not an internal control over financial reporting. The shredding vendor does not execute, calculate, or record financial transactions; therefore, a SOC 1 report under AT-C 320 is inapplicable.
Summary of Common Exam Traps
| Engagement / Rule | Correct CPA Understanding | Common Exam Distractor / Trap |
|---|---|---|
| SOC 1 Scope | Strictly limited to controls relevant to user entities' Internal Control over Financial Reporting (ICFR). | Believing SOC 1 covers general data privacy, HIPAA compliance, or physical environmental security. |
| SOC 2 vs. SOC 3 | Both evaluate the same criteria (Trust Services Criteria), but SOC 3 omits Section IV and is unrestricted for public use. | Believing SOC 3 is a "lower quality" review engagement or that SOC 3 tests fewer controls than SOC 2. |
| SOC for Cybersecurity | An enterprise-wide report for any entity (not just service vendors) designed for general distribution. | Believing SOC for Cybersecurity is restricted-use under AU-C 905 like a SOC 2 report. |
| Report Distribution | SOC 1 and SOC 2 contain explicit restricted-use paragraphs limiting distribution to existing customers and their auditors. | Asserting that service organizations can share SOC 2 Type 2 reports with any prospective bidder or public forum. |
A SaaS company hosts a cloud-based human resources document archiving system that does not process, calculate, or record payroll, compensation, or financial transactions. A customer's external financial statement auditor requests a SOC 1 Type 2 report. How should the SaaS company respond?
Which of the following statements accurately characterizes the distribution restrictions governing AICPA SOC reports?
A Fortune 500 manufacturing conglomerate wishes to obtain an independent attestation report evaluating the design and operational effectiveness of its enterprise-wide cybersecurity risk management program to share with its board of directors, institutional investors, and business partners. Which AICPA engagement is specifically designed for this purpose?