Menu
On this page
- SOC 1 vs SOC 2 at a glance
- How do you choose between SOC 1, SOC 2, and SOC 3?
- What does a SOC 1 report cover?
- What does a SOC 2 report cover?
- Can the same control appear in both reports?
- Do Type 1 and Type 2 apply to both SOC 1 and SOC 2?
- What should a buyer review in any SOC report?
- How do common service scenarios change the choice?
- Common questions about SOC 1 and SOC 2
SOC 1 and SOC 2 answer different customer questions. SOC 1 examines controls relevant to a user entity’s internal control over financial reporting (ICFR). SOC 2 examines controls against selected AICPA Trust Services Criteria (TSC). If a service affects a customer’s financial statements, start with SOC 1. If the customer needs evidence about security, availability, processing integrity, confidentiality, or privacy, start with SOC 2. Some service organizations need both.
The AICPA’s SOC 1 overview explains the ICFR focus. The AICPA’s current Trust Services Criteria define the framework used for SOC 2.
SOC 1 vs SOC 2 at a glance
SOC 1 addresses controls that may affect a customer’s financial reporting. SOC 2 addresses controls relevant to selected Trust Services Criteria. The correct report follows the customer’s risk and the service commitment, not the company’s industry label or the software used to deliver the service.
| Question | SOC 1 | SOC 2 |
|---|---|---|
| What risk does it address? | Risk that the service could affect a customer’s financial reporting | Risk concerning the security or operation of a service and the information it handles |
| Primary readers | User entities, their finance teams, and the CPAs auditing their financial statements | Customers, prospects, security teams, procurement, and risk teams |
| Evaluation framework | Controls relevant to the user entity’s ICFR | AICPA Trust Services Criteria selected for the engagement |
| Typical service context | Payroll, payment, claims, accounting, or other services that feed a customer’s financial reporting | SaaS, cloud, data, managed-service, or other services where customers need operational and information-security assurance |
| Can it replace the other report? | Not when the customer needs the other report’s assurance | Not when the customer’s financial auditor needs ICFR assurance |
These are different report families. Type 1 and Type 2 describe the examination period and operating-effectiveness work; they do not turn a SOC 1 into a SOC 2 or the reverse.
How do you choose between SOC 1, SOC 2, and SOC 3?
Choose SOC 1 when the service can affect a customer’s financial reporting. Choose SOC 2 when customers need detailed assurance about selected Trust Services Criteria. Consider SOC 3 when the same SOC 2 subject matter needs a public, general-use report with less operational detail.
| Customer request or service fact | Report to investigate first | What to confirm before signing |
|---|---|---|
| Your service processes transactions, calculations, or records that feed a customer’s financial statements | SOC 1 | Which user-entity financial reporting objectives and controls are in scope |
| Customers need detailed evidence about security, uptime, data handling, or processing | SOC 2 | Which TSC categories and customer commitments the report will cover |
| You want a public summary of the SOC 2 subject matter | SOC 3 | Whether the customer needs the restricted detail in a SOC 2 report instead |
| The service affects financial reporting and also stores or operates on customer data | SOC 1 and SOC 2 may both be relevant | Whether the auditor can coordinate overlapping control work without treating the reports as interchangeable |
The AICPA’s SOC 3 overview describes SOC 3 as addressing the same Trust Services Criteria subject matter as SOC 2, with less detail for general use. For a dedicated comparison, see SOC 2 vs SOC 3 report differences. A report is evidence for a defined scope; it is not a universal security, privacy, or regulatory approval.
What does a SOC 1 report cover?
A SOC 1 report covers controls at a service organization that are relevant to a user entity’s internal control over financial reporting. The scope depends on the service, the financial reporting processes it supports, and the objectives described in the engagement.
A SOC 1 can be relevant when a service organization performs or supports work such as:
- payroll calculations and related records;
- payment, claims, or revenue-processing workflows;
- accounting or financial data processing; or
- hosted applications that are part of a customer’s financial reporting process.
The label “FinTech” does not decide the report. A financial-technology company that only provides secure collaboration software may have a SOC 2 request. A less obviously financial vendor may need SOC 1 if its output feeds a customer’s financial statements. Ask the customer’s financial auditor or controller which process and control objectives they need addressed.
What does a SOC 2 report cover?
SOC 2 evaluates controls against the AICPA Trust Services Criteria selected for the engagement. Security is required. Availability, Processing Integrity, Confidentiality, and Privacy are added when they match the service’s commitments, customer requirements, or information flows.
| Trust Services Criterion | What it covers | When it may belong in scope |
|---|---|---|
| Security (CC1–CC9) | Protection against unauthorized access, use, or modification | Every SOC 2 report |
| Availability (A1.1–A1.3) | Whether the system is available for operation and use as committed | The service makes uptime, resilience, or recovery commitments |
| Processing Integrity (PI1.1–PI1.5) | Complete, valid, accurate, timely, and authorized processing | Customers rely on the service to process important transactions or data |
| Confidentiality (C1.1–C1.2) | Protection and secure disposal of information designated confidential | Customers entrust the service with confidential business information |
| Privacy (P1–P8) | Personal information across notice, collection, use, retention, access, disclosure, and disposal | The service collects, uses, or stores personal information and the commitment is material |
Use the maintained SOC 2 Trust Services Criteria scope guide when you are deciding which optional categories match your customer promises. SOC 2 is an attestation report, not a certification; What Is SOC 2 Compliance? explains the terminology.
Can the same control appear in both reports?
Yes. A control can support different objectives in different engagements. For example, an access review may be relevant to the integrity of a financial-processing application in a SOC 1 engagement and to unauthorized-access risk in a SOC 2 engagement. The control name is not the conclusion; the objective, system boundary, evidence, and auditor’s testing are.
That distinction matters when a buyer says “we already have SOC 2, so SOC 1 is covered.” Some control activities may overlap, but a SOC 2 opinion does not provide the ICFR opinion a customer’s financial auditor may need. Ask the auditor to map the overlapping activities to each report’s objectives.
Do Type 1 and Type 2 apply to both SOC 1 and SOC 2?
Type 1 evaluates whether controls are suitably designed at a specified date. Type 2 evaluates that design and whether the controls operated effectively throughout a specified period. The period is defined in the report and engagement; there is no universal AICPA-mandated six- or twelve-month window.
| Report type | What the auditor evaluates | Evidence the reader receives |
|---|---|---|
| Type 1 | Suitability of control design at a specified date | Policies, system description, configurations, and other design evidence as of that date |
| Type 2 | Suitability of design plus operating effectiveness over a specified period | Design evidence plus records showing the controls operated during the covered period |
The same Type 1/Type 2 distinction applies to SOC 1 and SOC 2. Before choosing, get the customer’s requirement in writing: report family, type, selected criteria or ICFR objectives, and acceptable coverage period. The maintained SOC 2 Type 1 vs Type 2 comparison covers the report-type decision in detail.
What should a buyer review in any SOC report?
Start with the system boundary and the auditor’s opinion. Then check the covered period, exceptions, customer responsibilities, and subservice-organization method. These sections tell a buyer what the report actually says, what it excludes, and which controls still belong to the customer.
| Report section | Question to ask |
|---|---|
| System description and scope | Does the described service, product, environment, and data flow match what we are buying? |
| Criteria or ICFR objectives | Does the report address the risk our team is responsible for evaluating? |
| Auditor’s opinion | Is the opinion unqualified, qualified, adverse, or disclaimed, and why? |
| Tests and exceptions | Were any controls not designed or not operated as described during the period? |
| Complementary user entity controls (CUECs) | What controls must our organization operate for the service provider’s controls to work as intended? |
| Subservice organizations | Which providers are included, and is the method inclusive or carve-out? What evidence do we need from carved-out providers? |
| Report period and bridge letter | If the report ended before the review date, what changed after the period and what bridge evidence is available? |
The AICPA SOC 2 report walkthrough discusses these reader-facing sections, including CUECs, subservice organizations, opinions, and bridge letters.
How do common service scenarios change the choice?
The service promise is more useful than the industry label.
| Scenario | Likely starting point | Scope question that still needs an answer |
|---|---|---|
| Payroll or payment processing | SOC 1, possibly SOC 2 | Which outputs affect the customer’s financial reporting, and which security or availability commitments matter too? |
| B2B SaaS storing customer business data | SOC 2 | Do customers need only Security, or also Availability, Confidentiality, Privacy, or Processing Integrity? |
| Healthcare software handling protected health information | SOC 2 may be relevant | What does the service contract and data flow require, and what separate HIPAA obligations and business-associate terms apply? |
| Financial service platform handling both transactions and sensitive data | SOC 1 and SOC 2 may be relevant | Can each report’s scope be mapped to the distinct finance and security questions? |
SOC 2 does not establish HIPAA compliance by itself. A healthcare service must assess its status and obligations under HIPAA and its business-associate arrangements; see HHS guidance on business associates.
Common questions about SOC 1 and SOC 2
Can SOC 2 replace SOC 1?
Not when a customer’s financial auditor needs assurance over controls relevant to ICFR. The reports can share control activities, but they answer different questions and produce different opinions.
Is SOC 2 a certification?
No. SOC 2 is an attestation report issued by an independent CPA firm. “SOC 2 certified” is common marketing language, but it is not the precise description of the service.
Can a company have both reports?
Yes. A service organization may need SOC 1 for controls relevant to customer financial reporting and SOC 2 for security or operational commitments. Confirm each audience’s requirements before assuming one engagement covers both.
What is the practical difference between SOC 2 and SOC 3?
Both address Trust Services Criteria subject matter. SOC 2 is the detailed report shared with intended users; SOC 3 is designed for general use and omits much of the operational detail.
Should a SaaS company automatically choose SOC 2?
Usually the customer request points toward SOC 2, but the service model decides. If the SaaS product produces or changes records that feed a customer’s financial statements, ask whether SOC 1 is also needed.
The right starting point is the risk your customer needs you to address. From there, define the system, report family, criteria or ICFR objectives, and report type with the CPA firm and the requesting customer.