Key Facts: The SOC Framework at a Glance #
| Fact | Detail | Source |
|---|---|---|
| Governing body | American Institute of Certified Public Accountants (AICPA) | AICPA SOC Suite of Services [1] |
| SOC framework origin | Replaced SAS 70 in 2011; currently governed under SSAE 18 (AT-C Sections 205 and 320) | AICPA Attestation Standards [2] |
| SOC reports issued annually (estimated) | Over 60,000 SOC 1 and SOC 2 reports combined in North America | AICPA Peer Review Program [1] |
| SOC 1 audit standard | AT-C Section 320 — Reporting on an Examination of Controls at a Service Organization Relevant to User Entities’ Internal Control Over Financial Reporting | SSAE 18 [2] |
| SOC 2 audit standard | AT-C Section 205 — Examination Engagements (using Trust Services Criteria) | SSAE 18 [2] |
| Enterprise buyers requiring SOC reports | 83% of B2B buyers require SOC 2 or equivalent compliance evidence before signing vendor contracts | Coalfire State of Compliance Report 2024 [3] |
| Trust Services Criteria categories (SOC 2/3) | 5: Security (mandatory), Availability, Processing Integrity, Confidentiality, Privacy | AICPA TSP Section 100 [4] |
Avoid Costly Alignment Mistakes: SOC 1, SOC 2, and SOC 3 are three distinct reports under a single framework — but they evaluate different things, serve different audiences, and answer different questions. Confusing them leads to wasted effort, misaligned audits, and reports that do not satisfy the stakeholders they were intended for.
The confusion is understandable. All three are issued by CPA firms, all three are governed by the AICPA, and all three involve rigorous examination of controls. But the similarities end there. A SOC 1 report does nothing to satisfy an enterprise customer asking about your data security. A SOC 2 report does nothing to satisfy an auditor asking about your impact on financial reporting. And a SOC 3 report, while publicly shareable, does not provide the detail that procurement teams need for vendor due diligence.
This guide explains each report type clearly, compares them across every dimension that matters, and provides practical guidance for determining which reports your organization needs. If you need help navigating the SOC landscape, nank.ai provides Compliance-As-A-Service that supports SOC 2 engagements from scoping through audit delivery.
What Is the SOC Framework and Where Did It Come From? #
The AICPA and SSAE 18 #
The SOC (System and Organization Controls) framework is developed and maintained by the American Institute of Certified Public Accountants (AICPA). It replaced the legacy SAS 70 (Statement on Auditing Standards No. 70) in 2011, which had been used for decades as the primary mechanism for evaluating service organization controls.
The current SOC framework operates under SSAE 18 (Statement on Standards for Attestation Engagements No. 18), which defines the professional standards that CPA firms must follow when performing SOC examinations:
- AT-C Section 320 governs SOC 1 engagements (controls relevant to financial reporting)
- AT-C Section 205 governs SOC 2 and SOC 3 engagements (controls relevant to Trust Services Criteria)
Why Three Report Types? #
The AICPA created three report types because different stakeholders need different assurance:
| Stakeholder Need | SOC Report |
|---|---|
| “Does this service provider’s controls affect our financial statements? Are those controls adequate?” | SOC 1 |
| “Does this service provider protect our data? Are their security, availability, and privacy controls effective?” | SOC 2 |
| “Can this service provider publicly demonstrate that an independent auditor evaluated their controls?” | SOC 3 |
What Is SOC 1? #
Definition and Purpose #
SOC 1 is an attestation report that evaluates a service organization’s internal controls over financial reporting (ICFR) — specifically, controls that are relevant to the user entities’ financial statements.
The key phrase is “relevant to financial reporting.” SOC 1 exists because many organizations outsource functions that directly affect their financial records — payroll, transaction processing, claims management, revenue recognition, financial hosting. When an organization outsources these functions, their external auditors need assurance that the service provider’s controls do not create material misstatement risk in the user entity’s financial statements.
What SOC 1 Evaluates #
| Control Area | Examples |
|---|---|
| Transaction processing | Completeness and accuracy of financial transactions processed on behalf of clients |
| Authorization controls | Proper authorization of transactions and adjustments |
| Data integrity | Accuracy of financial data input, processing, and output |
| Reconciliation | Procedures for reconciling processed transactions to source data |
| Logical access | Access controls over systems that process financial data |
| Change management | Controls over changes to applications that process financial transactions |
| Physical security | Physical access controls to facilities housing financial processing systems |
| Backup and recovery | Backup and recovery controls for financial data |
Important distinction: SOC 1 does not use the Trust Services Criteria. It uses control objectives that the service organization defines based on the financial processes it performs for clients. These control objectives are specific to the service — a payroll processor has different control objectives than a loan servicer.
Who Needs SOC 1? #
| Organization Type | Why SOC 1 |
|---|---|
| Payroll processors | Process salary, tax, and benefit transactions that appear in clients’ financial statements |
| Payment processors | Handle payment transactions that affect clients’ revenue and expense records |
| Loan servicers | Manage loan portfolios, interest calculations, and payment application affecting financial reporting |
| Claims processors | Process insurance claims that affect reserve calculations and expense recognition |
| Investment custodians | Hold and report on investment assets reflected in clients’ balance sheets |
| Financial hosting providers | Host financial applications (ERP, accounting systems) where controls affect data integrity |
| Benefit administrators | Manage pension, 401(k), and benefit calculations affecting liability reporting |
| Trust and escrow services | Hold and manage funds reflected in clients’ financial reporting |
SOC 1 Report Types #
| Dimension | SOC 1 Type I | SOC 1 Type II |
|---|---|---|
| What is evaluated | Control design at a point in time | Control design AND operating effectiveness over a period |
| Time frame | Single date | 6–12 months |
| Auditor tests | Design suitability only | Design suitability + tests of operating effectiveness with samples |
| Report content | Auditor opinion, system description, control objectives, controls listed | Auditor opinion, system description, control objectives, controls listed, tests performed, results |
| Typical use | First-time engagement; interim assurance | Standard requirement for user entity auditors |
What Is SOC 2? #
Definition and Purpose #
SOC 2 is an attestation report that evaluates a service organization’s controls relevant to security, availability, processing integrity, confidentiality, and privacy — the five Trust Services Criteria (TSC) defined by the AICPA.
Unlike SOC 1, SOC 2 is not concerned with financial reporting. It is concerned with whether the service organization protects the data and systems that customers entrust to it. SOC 2 has become the de facto standard for technology vendor assurance in North America.
What SOC 2 Evaluates #
| Criterion | Focus | Required? |
|---|---|---|
| Security (Common Criteria) | Protection against unauthorized access, disclosure, and damage to systems | Yes — always required |
| Availability | Systems are available for operation and use as committed | Optional |
| Processing Integrity | System processing is complete, valid, accurate, timely, and authorized | Optional |
| Confidentiality | Confidential information is protected as committed | Optional |
| Privacy | Personal information is managed per privacy commitments | Optional |
Who Needs SOC 2? #
| Organization Type | Why SOC 2 |
|---|---|
| SaaS companies | Store and process customer data; enterprise buyers demand SOC 2 |
| Cloud service providers | Host customer infrastructure and data |
| Managed service providers | Operate customer IT environments |
| Data analytics companies | Process customer data for insights |
| Healthtech companies | Handle health-related data (supports HIPAA alignment) |
| Fintech companies | Process financial data (may need SOC 1 too) |
| HR technology providers | Process employee personal data |
| DevOps & CI/CD platforms | Handle customer source code and deployment processes |
| Communication platforms | Manage customer communications and data |
SOC 2 Report Types #
| Dimension | SOC 2 Type I | SOC 2 Type II |
|---|---|---|
| What is evaluated | Control design at a point in time | Control design AND operating effectiveness over a period |
| Time frame | Single date | 6–12 months |
| Auditor tests | Design suitability only | Design suitability + tests of operating effectiveness with samples across the period |
| Report content | Auditor opinion, system description, criteria, controls, design evaluation | Auditor opinion, system description, criteria, controls, tests of design, tests of operating effectiveness, results, exceptions |
| Typical use | First-time engagement; interim assurance while building toward Type II | Standard requirement for enterprise buyers |
What Is SOC 3? #
Definition and Purpose #
SOC 3 is a general-use report that provides the same level of audit assurance as a SOC 2 Type II report but in a summary format suitable for public distribution. It contains the auditor’s opinion on whether the organization’s controls meet the Trust Services Criteria — but without the detailed system description, specific control descriptions, test procedures, or test results.
SOC 3 exists to solve a specific problem: SOC 2 reports contain sensitive information about your control environment and cannot be shared publicly. But organizations need a way to publicly signal that they have undergone an independent examination. SOC 3 fills that gap.
What SOC 3 Contains vs. What It Omits #
| Report Section | SOC 2 Type II | SOC 3 |
|---|---|---|
| Auditor’s opinion | Included | Included |
| Management’s assertion | Included | Included |
| System description | Detailed (infrastructure, software, people, procedures, data) | Omitted |
| Control descriptions | Detailed for each criterion | Omitted |
| Test procedures | Described for each control tested | Omitted |
| Test results | Included (pass/fail, exceptions noted) | Omitted |
| Exceptions and findings | Detailed with management responses | Omitted |
- SOC 3 provides no detail for security-conscious buyers to evaluate. It says “the auditor’s opinion is unqualified” but not what was tested or how.
- It cannot replace SOC 2 in enterprise procurement. Buyers conducting thorough vendor due diligence will request the full SOC 2 Type II report.
- There is no SOC 3 Type I — the report only exists as a Type II equivalent because a public opinion on point-in-time design provides limited assurance.
How Do SOC 1, SOC 2, and SOC 3 Compare? The Complete Side-by-Side #
Core Comparison #
| Dimension | SOC 1 | SOC 2 | SOC 3 |
|---|---|---|---|
| Full name | System and Organization Controls 1 | System and Organization Controls 2 | System and Organization Controls 3 |
| What it evaluates | Internal controls over financial reporting (ICFR) | Controls for security, availability, processing integrity, confidentiality, privacy | Same as SOC 2 |
| Criteria framework | Control objectives defined by the service organization | Trust Services Criteria (5 categories; Security mandatory) | Trust Services Criteria (same as SOC 2) |
| Audit standard | AT-C Section 320 | AT-C Section 205 | AT-C Section 205 |
| Primary audience | User entity auditors, management, clients | Customers, prospects, partners, regulators | General public, prospects, marketing |
| Report types | Type I and Type II | Type I and Type II | Type II equivalent only |
| Distribution | Restricted use (under NDA) | Restricted use (under NDA) | General use (public) |
| Report detail | High (system description, control objectives, controls, tests, results) | Highest (system description, criteria, controls, tests, results, exceptions) | Low (auditor opinion only) |
| Who performs it | Licensed CPA firm | Licensed CPA firm | Licensed CPA firm (same engagement as SOC 2) |
| Renewal cadence | Annual | Annual | Annual (with SOC 2) |
| Standalone engagement? | Yes | Yes | No — produced alongside SOC 2 Type II |
| Primary geographic recognition | North America | North America (growing globally) | North America |
Detailed Criteria Comparison #
| Dimension | SOC 1 | SOC 2 | SOC 3 |
|---|---|---|---|
| Security controls | Only if relevant to ICFR (logical access, change management) | Mandatory — full Common Criteria (CC1–CC9) | Same as SOC 2 |
| Availability | Not addressed unless affects financial processing | Optional criterion | Same as SOC 2 |
| Processing integrity | Addressed via ICFR control objectives (completeness, accuracy) | Optional criterion | Same as SOC 2 |
| Confidentiality | Not specifically addressed | Optional criterion | Same as SOC 2 |
| Privacy | Not specifically addressed | Optional criterion | Same as SOC 2 |
| Financial reporting controls | Core focus — transaction authorization, completeness, accuracy, reconciliation | Not addressed | Not addressed |
| Risk assessment | Implied through control design | Explicit requirement (CC3) | Same as SOC 2 |
| CUECs | Standard inclusion | Sometimes included | Not detailed |
| Subservice organizations | Addressed (inclusive or carve-out method) | Addressed (inclusive or carve-out method) | Not detailed |
Cost and Effort Comparison #
| Dimension | SOC 1 | SOC 2 | SOC 3 |
|---|---|---|---|
| Implementation effort | Moderate — focused on financial processing controls | Moderate to high — broader control scope across TSC | No incremental implementation (uses SOC 2 controls) |
| Documentation | Control objectives, system description, policies for financial controls | Policies across all TSC, system description, risk assessment | No additional documentation |
| Audit cost (Type II, mid-market) | $20,000–$60,000 | $20,000–$60,000 | $3,000–$8,000 incremental when added to SOC 2 |
| Internal effort | 200–500 hours | 300–800 hours | Minimal (same evidence as SOC 2) |
| Timeline (first Type II) | 8–14 months | 8–16 months | Produced with SOC 2 — no additional timeline |
When Does an Organization Need Each Report? #
Decision Framework #
| Question | If Yes | If No |
|---|---|---|
| Does your service directly affect clients’ financial statements? | SOC 1 is likely required | SOC 1 is not needed |
| Do you process, store, or transmit customer data? | SOC 2 is likely required | SOC 2 may not be needed |
| Are your clients’ external auditors asking for assurance over your controls? | SOC 1 (if the question is about ICFR) | — |
| Are enterprise customers asking for security assurance? | SOC 2 Type II | — |
| Do you want to publicly display your compliance status? | Add SOC 3 to your SOC 2 engagement | SOC 3 is not needed |
| Does your service both affect financial reporting AND handle sensitive data? | Both SOC 1 and SOC 2 | Choose one based on primary need |
Scenario-Based Examples #
Scenario 1: Cloud Payroll Processor #
Service: Processes payroll, tax calculations, and benefit deductions for employer clients.
Reports needed: SOC 1 and SOC 2
Rationale: SOC 1 covers payroll transactions that directly affect client financial statements (salary expense, tax liabilities). SOC 2 covers sensitive employee personal data protection (SSNs, banking details).
Scenario 2: SaaS Project Management Platform #
Service: Cloud-based project management and collaboration tool storing project data, documents, and communications.
Reports needed: SOC 2 (and optionally SOC 3)
Rationale: SOC 2 satisfies enterprise buyer data protection requirements. SOC 1 is not needed (no financial statement impact). SOC 3 provides website credibility.
Scenario 3: Investment Fund Administrator #
Service: Calculates net asset values (NAV), processes investor transactions, and produces financial reports for investment funds.
Reports needed: SOC 1
Rationale: NAV calculations and investor transactions directly affect fund financial statements. Fund auditors require SOC 1.
Scenario 4: Cloud Infrastructure Provider #
Service: Provides IaaS hosting for customer applications and data.
Reports needed: SOC 2 (and optionally SOC 3)
Rationale: Customers require assurance that infrastructure is secure (Security & Availability criteria). SOC 1 is only needed if clients host core financial processing systems requiring ICFR coverage.
Scenario 5: Healthcare Claims Processing Company #
Service: Processes medical insurance claims, adjudicates coverage, and calculates payment amounts for insurers.
Reports needed: SOC 1 and SOC 2
Rationale: Claims adjudication directly affects insurers’ financial statements (claims reserves, liabilities). SOC 2 covers Protected Health Information (PHI) and supports HIPAA alignment.
Scenario 6: Marketing Analytics SaaS #
Service: Collects and analyzes marketing campaign data with analytics dashboards.
Reports needed: SOC 2 (and optionally SOC 3)
Rationale: Protects ingested customer marketing data. No financial reporting impact exists.
How Do the Audit Processes Differ? #
SOC 1 Audit Process #
- Step 1Define control objectives: Identify objectives specific to user entities’ financial reporting.
- Step 2Design and implement controls: Build controls that address each custom objective.
- Step 3Prepare the system description: Document the system, services, and operational controls.
- Step 4Identify CUECs: Document complementary user entity controls assumed to be in place.
- Step 5Engage a CPA firm: Select a licensed firm with ICFR competence.
- Step 6Type I or Type II examination: Undergo testing of design (Type I) or operating effectiveness (Type II).
- Step 7Report issuance: Receive the restricted-use SOC 1 report.
SOC 2 Audit Process #
- Step 1Define scope & select TSC: Security is mandatory; add Availability, Processing Integrity, Confidentiality, Privacy as needed.
- Step 2Conduct gap assessment: Evaluate current posture against Trust Services Criteria.
- Step 3Implement controls & policies: Deploy technical and procedural safeguards across selected criteria.
- Step 4Collect evidence over observation period: 6–12 months of operational proof for Type II.
- Step 5Conduct readiness assessment: Run a pre-audit dress rehearsal to catch issues early.
- Step 6Engage a CPA firm: Select a firm with information security and TSC expertise.
- Step 7Fieldwork examination: Undergo sampling, interviews, inspection, and walkthroughs.
- Step 8Report issuance: Receive the restricted-use SOC 2 report.
SOC 3 Audit Process #
What Are the Subservice Organization Considerations? #
All SOC reports must address third-party subservice organizations (such as AWS, Azure, GCP):
- Inclusive Method: Subservice controls are included in the system description and tested directly during your audit.
- Carve-Out Method: Subservice controls are excluded from scope; the system description describes provider functions, and customers rely on the vendor’s standalone SOC report (most common approach).
What Are the Common Misconceptions? #
- “SOC 2 is an upgraded version of SOC 1”: False. They evaluate completely different control objectives (ICFR vs. Data Protection).
- “SOC 3 is a lower-quality SOC 2”: False. The underlying audit rigor is identical; only the confidential detail is omitted for public release.
- “We have SOC 1, so we don’t need SOC 2”: False. SOC 1 provides zero assurance on data security or breach response.
- “SOC reports are certifications”: False. They are CPA attestation reports, not certified seals or public registry listings.
- “We can share our SOC 2 report publicly”: False. SOC 2 distribution is restricted under NDA. Use SOC 3 for public marketing.
- “Any auditor can perform a SOC examination”: False. Only licensed CPA firms governed by the AICPA can issue SOC reports.
Frequently Asked Questions #
What is the fundamental difference between SOC 1, SOC 2, and SOC 3? #
SOC 1 evaluates controls relevant to a user entity’s financial reporting — it is designed for service organizations whose services affect their clients’ financial statements. SOC 2 evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy — it is designed for technology and service organizations handling customer data. SOC 3 covers the same scope as SOC 2 but produces a general-use summary report suitable for public distribution, whereas SOC 1 and SOC 2 reports are restricted-use documents shared only under NDA.
Does my organization need SOC 1 or SOC 2? #
If your service directly affects your clients’ financial statements or financial reporting processes — for example, payroll processing, payment processing, loan servicing, claims processing — you likely need SOC 1. If your service involves storing, processing, or transmitting customer data but does not directly impact financial reporting — for example, SaaS platforms, cloud hosting, managed IT services — you likely need SOC 2. Some organizations need both if their service touches financial reporting and handles sensitive customer data.
Can SOC 3 replace SOC 2? #
No. SOC 3 is not a replacement for SOC 2 — it is a complementary report produced from the same audit engagement. SOC 3 contains only the auditor’s opinion without the detailed system description, control descriptions, or test results. Enterprise buyers require the full SOC 2 Type II report for vendor due diligence. SOC 3 is useful for public-facing assurance but does not satisfy detailed procurement requirements.
What are the Type I and Type II distinctions across SOC reports? #
Both SOC 1 and SOC 2 offer Type I and Type II reports. Type I evaluates whether controls are suitably designed at a specific point in time. Type II evaluates whether controls are suitably designed and operating effectively over a defined period (typically 6 to 12 months). SOC 3 is only available as a Type II equivalent — there is no SOC 3 Type I.
Who performs SOC 1, SOC 2, and SOC 3 audits? #
All three SOC reports must be issued by a licensed CPA firm. This is a requirement of the AICPA. Non-CPA security consultants, IT auditors, or compliance firms cannot issue SOC reports. SOC 1 auditors need ICFR expertise, while SOC 2 and SOC 3 auditors need Trust Services Criteria and information security expertise.
Can an organization pursue SOC 1 and SOC 2 simultaneously? #
Yes. Organizations whose services both affect client financial reporting and handle sensitive data often pursue both. There is control overlap (logical access, change management, incident management), so coordinating both engagements with the same CPA firm reduces duplication. A CaaS platform like nank.ai maps shared controls across both engagements to minimize redundant work.
Navigate the SOC Landscape with Clarity #
Choosing the right SOC report — or combination of reports — depends on what your service does, who is asking for assurance, and what question they need answered. SOC 1 for financial reporting controls. SOC 2 for data security and operational controls. SOC 3 for public-facing assurance.
Contact nank.ai today for a free compliance readiness assessment.
Source References #
[1] American Institute of Certified Public Accountants (AICPA). SOC Suite of Services Overview. AICPA, 2024. https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/socforserviceorganizations
[2] American Institute of Certified Public Accountants (AICPA). Statement on Standards for Attestation Engagements No. 18 (SSAE 18) — AT-C Sections 205 and 320. AICPA, 2016 (updated 2022). https://www.aicpa.org/research/standards/auditattest/ssae
[3] Coalfire. The State of Compliance Report 2024. Coalfire, 2024. https://www.coalfire.com/research/state-of-compliance
[4] American Institute of Certified Public Accountants (AICPA). TSP Section 100: 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy. AICPA, 2017 (updated 2022). https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/trustdataintegritytaskforce
[5] American Institute of Certified Public Accountants (AICPA). SOC 1 — SOC for Service Organizations: ICFR. AICPA. https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/aaborforattestandssae16.html
[6] American Institute of Certified Public Accountants (AICPA). SOC 3 — SOC for Service Organizations: Trust Services Criteria for General Use Report. AICPA. https://www.aicpa.org/interestareas/frc/assuranceadvisoryservices/soc3
Keywords: SOC 1 vs SOC 2 vs SOC 3, difference between SOC 1 and SOC 2, SOC 2 vs SOC 3, SOC report types, what is SOC 1, what is SOC 2, what is SOC 3, SSAE 18, Trust Services Criteria, ICFR, service organization controls, SOC 1 Type II, SOC 2 Type II, SOC 3 report, compliance as a service, nank.ai
