SOC 1 vs SOC 2: What's the Difference and Which Report Does Your Company Need?

The difference between SOC 1 and SOC 2 comes down to purpose. A SOC 1 report covers the controls at a service organization that can change the numbers in its customers' financial statements. A SOC 2 report covers the controls that protect the customers' data, evaluated against the AICPA's Trust Services Criteria. Neither report stands in for the other, which is what makes SOC 1 vs SOC 2 a decision rather than a formality.

The confusion has a reason: both reports come from the same standards body, and the same CPA firm can perform either one. The request arrives as "a SOC report" with no number attached, sent by a customer's auditor, procurement team or security team. Choosing wrong can cost an examination cycle: a SOC 2 report handed to a customer's financial auditor, in the words of the AICPA's interpretation of AU-C section 402, "is unlikely to achieve the intent of the requirements in AU-C section 402" (1).

Payroll processors, claims administrators, SaaS platforms and data centers all field that request, and the right answer differs for each. Two questions decide it: who is asking, and what your service does for them.

What SOC Reports Are

The phrase "a SOC report" covers three different reports. SOC stands for System and Organization Controls: the AICPA's SOC communications guidelines say that in 2017 the AICPA introduced the term "to refer to the suite of services practitioners may provide relating to system-level controls of a service organization or system- or entity-level controls of other organizations" (2).

Every SOC examination ends the same way: an independent CPA tests controls against defined criteria and issues an opinion the organization can hand to the people who rely on those controls. Three reports cover service organizations:

• SOC 1, on the controls relevant to customers' internal control over financial reporting. Restricted use.
• SOC 2, on the controls relevant to security, availability, processing integrity, confidentiality or privacy. Restricted use.
• SOC 3, the general-use report on the same Trust Services Criteria as a SOC 2, without the detail.

SOC 1 and SOC 2 Difference at a Glance

The table below sets out the SOC 1 and SOC 2 report differences on 8 dimensions, side by side.

Table 1. SOC 1 vs SOC 2 on 8 dimensions

Dimension	SOC 1	SOC 2
Who usually asks (practice)	The customer's finance function or its auditor	The customer's security, procurement or vendor risk teams
Who reads it	User entities and their financial statement auditors (user auditors)	Intended users named in the report, which may include current and prospective user entities and business partners as well as regulators and the practitioners serving those users
What it examines	Controls at a service organization "likely to be relevant to user entities' internal control over financial reporting"	Controls "over the security, availability, or processing integrity of a system or the confidentiality or privacy of the information processed by the system"
Who typically needs it	Organizations whose service can change numbers in a customer's financial reporting: payroll, claims and benefits administration, loan servicing, transaction processing	Organizations that store, process or transmit customer data: SaaS, cloud and hosting providers, managed service providers
Criteria the controls are tested against	Control objectives that the service organization's management defines for its own services	The AICPA's Trust Services Criteria (5 criteria categories), fixed for every SOC 2
Governing standard	AT-C section 320 (SSAE No. 18)	AT-C section 105 and AT-C section 205 (SSAE No. 18, as amended)
Report types	Type 1 (as of a date) and Type 2 (over a period)	Type 1 and Type 2, same mechanics
Distribution	Restricted use: management, user entities and their user auditors	Restricted use: intended users named in the report; SOC 3 is the general-use report on the same criteria

Sources: SOC 1 page (3), AU-C section 9402 (1), 2017 Trust Services Criteria (4), AT-C sections 105, 205 and 320 (5), DC section 200 (6), SOC 3 page (7); read September 2026.

Note. The first and fourth rows describe common practice, not a rule.

What Is a SOC 1 Report?

A SOC 1 is written above all for the auditor of the customer's financial statements. The AICPA's SOC 1 page defines it as "an examination of controls at a service organization that are likely to be relevant to user entities' internal control over financial reporting" (3). A user entity is a company that uses the service organization; a user auditor is the CPA who audits that company's financial statements.

• Who it is written for. SOC 1 reports, in the AICPA's words, "are specifically intended to meet the needs of entities that use service organizations (user entities) and the CPAs that audit the user entities' financial statements (user auditors), in evaluating the effect of the controls at the service organization on the user entities' financial statements" (3).
• Why it exists. When payroll, claims processing or loan servicing is outsourced, transactions that reach the customer's financial reporting run through someone else's systems, and the auditing standards tell the user auditor to consider the service organization's controls.
• Which standard sends the auditor looking. Your customer's auditor is required to consider your controls, which is why the request lands on you at all. Under AICPA standards that duty sits in AU-C section 402 (8); for audits of public companies it sits in PCAOB AS 2601 (9). AT-C section 320 states that a report prepared under it "may provide appropriate evidence under AU-C section 402" (5).
• What it is tested against. Management writes the key control objectives, defined in AT-C section 320 as "the aim or purpose of specified controls at the service organization" (5), and the service auditor tests whether the controls achieve them. A payroll provider's objectives might cover the authorization of payment files, the accuracy of pay calculations and the completeness of amounts withheld and remitted. The objectives span business processes and the IT general controls behind them, but only where those financial controls matter to the customer's financial data.
• Who typically needs one. In practice the list runs to payroll processors, benefit plan recordkeepers and trustees, claims administrators, loan servicers, mortgage servicers and platforms that process transactions on a customer's behalf. The AICPA runs a resource center for employee benefit plan auditors because "most employee benefit plans use service organizations (e.g., bank trustees, insurance companies or benefits administrators) to process transactions and maintain plan records" (8).
• Who may read it. Restricted use: under AT-C section 320 the report is "intended only for use by management of the service organization, user entities of the service organization ... and their user auditors" (5).

If the request reached you from a security or procurement team rather than from an auditor, the next section is the one you need.

What Is a SOC 2 Report?

A SOC 2 answers the other side of the customer's organization: the teams that review how you handle their data. The AICPA's interpretation of AU-C section 402 describes a SOC 2 engagement as "an examination of controls over the security, availability, or processing integrity of a system or the confidentiality or privacy of the information processed by the system" (1). Its intended users "include user entities of the system during some or all of the period covered by the report and practitioners providing services to such user entities".

• Tested against fixed criteria. A SOC 2 is not tested against objectives the provider writes for itself. The current edition is the 2017 Trust Services Criteria with revised points of focus (2022), which the AICPA publishes "for use in attestation or consulting engagements to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy of information and systems" (4).
• Who typically needs one. In practice the report is asked of cloud service providers, SaaS companies, data centers, managed service providers and other IT service providers that store, process or transmit customer data, and potential customers ask for it before they hand over client data to cloud providers and platforms.
• What triggers the request. A prospective customer's information security or vendor risk review needs evidence of your data protection: that the organization's security controls protect data as promised. A SOC 2 report is the document that shows the reviewer your information security practices and data protection.

The 5 Trust Services Criteria

Which categories your report covers is yours to choose, and it is the main scoping decision in a SOC 2. Security is the category whose criteria stand on their own: in the AICPA's words, "no additional control activity criteria are needed" (4), so a report can cover security alone. The other 4 are added when your service commitments, or a customer's contract, put them in scope.

The Trust Services Criteria document defines the 5 categories as follows (4), and the last 2 are the data protection pair:

• Security. "Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity's ability to achieve its objectives."
• Availability. "Information and systems are available for operation and use to meet the entity's objectives."
• Processing integrity. "System processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives."
• Confidentiality. "Information designated as confidential is protected to meet the entity's objectives."
• Privacy. "Personal information is collected, used, retained, disclosed, and disposed of to meet the entity's objectives."

The five criteria are not five separate checklists. The document splits them in two (4):

• "criteria common to all five of the trust services categories (common criteria)"
• "additional specific criteria for the availability, processing integrity, confidentiality, and privacy categories"

Table 2. The 9 common criteria series in every SOC 2

Common criteria series	What it covers
CC1	Control environment
CC2	Communication and information
CC3	Risk assessment
CC4	Monitoring of controls
CC5	Control activities
CC6	Logical and physical access
CC7	System operations
CC8	Change management
CC9	Risk mitigation

Source: TSP section 100 .07 and its criteria table (4); read September 2026.

The relevant Trust Services Criteria for each category in scope are listed in the report itself, which is where a customer checks what your report covers.

See what a SOC 2 report contains, section by section

A separate guide on this blog explains what a SOC 2 report is, including its lifecycle and the roles involved. The comparison of SOC 2 vs ISO 27001 covers how the attestation report differs from a certified information security management system.

What Is the Difference Between SOC 1 and SOC 2 Compliance?

Both reports come out of the same attestation discipline: management describes its system and asserts that its controls work; an independent CPA firm then tests that assertion and issues an opinion. So what is the difference between SOC 1 and SOC 2 compliance in practice? It runs through 5 dimensions.

Purpose and Scope

Scope follows purpose. A SOC 1 reaches only the services, and the financial controls behind them, that could affect the customer's financial reporting; a SOC 2 reaches the system the provider uses to deliver the services in scope, with a broader range of operational controls measured against the trust services categories it covers.

Control Objectives vs the Trust Services Criteria

In a SOC 1, management writes the control objectives and the auditor tests whether the controls in the description achieve them, so the objectives differ from one provider to the next.

In a SOC 2, the criteria are fixed by the AICPA and the provider identifies the controls that meet each relevant criterion. That is why the security controls in two SOC 2 reports can be read side by side, while the financial reporting controls in two SOC 1 reports cannot.

Who Reads the Report

The reader is different in each case, and who reads it is the first of the two questions that decide the request:

• SOC 1: the user auditor, with the customer's finance and internal audit functions.
• SOC 2: security, procurement and vendor risk teams, business partners and prospective customers, all of whom want assurance that the system controls protect data they have handed over or are about to hand over.

The Governing Standard

Both examinations run under the AICPA's attestation standards, codified as the AT-C sections of SSAE No. 18, as amended, which "recodifies and supersedes" SSAE Nos. 10 to 17 with named exceptions (10) and is effective for practitioners' reports dated on or after May 1, 2017 (5).

• SOC 1: AT-C section 320, Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting.
• SOC 2: AT-C section 105 and AT-C section 205 (Assertion-Based Examination Engagements). Section 205 was reissued and retitled by SSAE No. 21 (11), effective for reports dated on or after June 15, 2022 (5).
• When the customer or its auditor is outside the United States: ask which standard they need. The international counterpart of SOC 1 is ISAE 3402, the IAASB standard for "controls at a service organization ... likely to be relevant to user entities' internal control, as it relates to financial reporting" (12).

What the Auditor Tests

The control areas overlap more than the purposes suggest; what differs is which internal controls are in scope and what they are measured against. The table pairs typical SOC 1 control objectives with the Trust Services Criteria series a SOC 2 tests in the same area.

Table 3. Control areas in a SOC 1 and a SOC 2

Control area	SOC 1: tested against a control objective, for example	SOC 2: tested against the Trust Services Criteria
Logical access	Access to the financial application and its data is restricted to authorized personnel	CC6 series, logical and physical access controls over the whole system
Change management	Changes to transaction processing logic are authorized, tested and approved before release	CC8 series, change management for infrastructure, software and data
Transaction processing	Transactions are processed completely, accurately and on time; reconciliations and error handling are performed	PI1 series, processing integrity of data processing, only when that category is in scope
Monitoring and incidents	Processing exceptions are identified and resolved	CC7 series, system operations: detection, monitoring and incident response
Risk and vendors	Only where a subservice organization affects the control objectives	CC3 series, risk assessment and risk management processes; CC9.2, "assesses and manages risks associated with vendors and business partners"
Availability and recovery	Usually outside scope unless it affects financial reporting	A1 series, additional criteria for availability, when that category is in scope

Sources: TSP section 100 (4), AT-C section 320 .08 (5); read September 2026.

Note. The SOC 1 column shows typical control objectives for illustration; each service organization defines its own.

SOC 1 vs SOC 2 Report: What Each Report Contains

The difference between SOC 1 and SOC 2 reports is visible on the page, not only in the scope. Both follow the structure the attestation standards set, from the auditor's opinion to the tests behind it, and the table shows what each of the 5 parts holds in each report.

Table 4. What each part of a SOC report contains

Part of the report	SOC 1	SOC 2
Service auditor's report (the opinion)	Whether the description fairly presents the system, whether the controls were suitably designed to achieve the stated objectives and, in a Type 2, whether they operated effectively throughout the period	Whether the description is presented in accordance with the description criteria, whether the controls were suitably designed to provide reasonable assurance that the service commitments and system requirements would be achieved if controls operated effectively, based on the applicable Trust Services Criteria and, in a Type 2, whether they operated effectively
Management's written assertion	Required; AT-C section 320 directs the service auditor to request it. It covers the description and the objectives	Required under AT-C section 205. It covers the description criteria and the Trust Services Criteria in scope
Management's description of the system	Prepared to the description requirements in AT-C section 320, organized around the services and the control objectives	Prepared against the AICPA's 2018 Description Criteria (DC section 200, with revised implementation guidance, 2022); it may be organized by the system components "infrastructure, software, people, procedures, and data"
Tests of controls and results (Type 2 only)	Each control objective, the service organization's controls, the testing procedures performed and "any identified deviations in the operation of controls", with the extent of testing and the number of items tested for each deviation	Each relevant Trust Services Criteria item in scope, the controls, the tests performed and the deviations found
Restricted-use paragraph	The report is "intended solely for the information and use of management of the service organization, user entities of the service organization's system ... and the auditors who audit and report on such user entities' financial statements"	Intended users named in the report, including "user entities of the system during some or all of the period"

Sources: DC section 200 (6), AT-C sections 105, 205 and 320 (5), AU-C section 9402 (1); read September 2026.

How to Read a SOC Report

Whether you are handing your own report to a customer or reviewing a vendor's, this is the order to read it in.

What to check about the report itself

1. Which report, and which Type. A SOC 2 is not designed to address financial reporting controls; a Type 1 says nothing about how controls operated over time.
2. The date or the period, and how recent it is. A Type 1 is as of a specified date, a Type 2 covers a period the report names.
3. What is in scope. Which services and which system; for a SOC 2, which trust services categories; for a SOC 1, which control objectives. A report scoped to one service or one category says nothing about the rest.
4. The system behind the service. The SOC 2 description may be organized by the components "infrastructure, software, people, procedures, and data," which is where the applications, platforms and staff in scope are named.

What to check about the controls

5. The opinion, and whether it is modified. AT-C section 205 defines a modified opinion as "a qualified opinion, an adverse opinion, or a disclaimer of opinion" (5): qualified when a material problem is not pervasive or evidence on one point was unavailable, adverse when the problems are "both material and pervasive," a disclaimer when the auditor could not obtain enough evidence to opine at all. Anything other than an unmodified opinion changes what the report is worth.
6. The deviations. In a Type 2 the tests section lists each deviation, the extent of testing that found it and the number of items tested. A management response, where the service organization adds one, is unaudited.
7. Complementary user entity controls. Defined in AT-C section 320 as controls management "assumes ... will be implemented by user entities and are necessary to achieve the control objectives" (5): they are obligations on the customer, not on the provider.
8. Subservice organizations. Under the carve-out method the cloud host or data center behind the service is named in the description, but its controls sit outside the examination, so its own SOC report is the next thing to ask for. Under the inclusive method they are covered.
9. Who may use the report. Both reports carry a restricted-use paragraph naming who the report is for.

SOC 1 Type 1 vs Type 2: Point in Time or Period of Time

Type 1 and Type 2 are not part of the SOC 1 vs SOC 2 distinction: both reports come in both types, and the Type can matter more to the reader than the report number.

The attestation standards define a Type 1 as a report on management's description of the system and "the suitability of the design of controls" as of a specified date, and a Type 2 as a report on the description and "the suitability of the design and operating effectiveness of controls" throughout a stated period (5).

A SOC 1 Type 2 report (also written as a Type II report) is the version a user auditor relies on: it is the only version of a SOC 1 that says the controls operated. The table shows a SOC 1; a SOC 2 Type 1 and Type 2 differ the same way, with the Trust Services Criteria in place of the control objectives.

Table 5. SOC 1 Type 1 vs Type 2

	SOC 1 Type 1	SOC 1 Type 2
What the opinion covers	The description fairly presents the system as of a specified date, and the controls were suitably designed to achieve the objectives as of that date	The description fairly presents the system throughout the specified period, and the controls were suitably designed and operated effectively throughout the period
Date or period	As of one date	Throughout a period; AT-C section 320 refers only to "the specified period" and sets no minimum or maximum length
What the user auditor gets	An understanding of the system and of control design, with no evidence that the controls operated	Evidence of operating effectiveness for the period, which the user auditor can rely on
Tests of controls section	Not included	Included, with the deviations identified
When to choose it (practice)	A first report, newly implemented controls or a customer that needs something before a period can be completed	Ongoing assurance, and any customer or user auditor that requires evidence the controls operated

Sources: AT-C section 320 .07 and .08 (5); read September 2026.

Note. The last row describes common practice, not a rule.

The observation period is set with the service auditor and stated in the report; in practice it is planned around the customers' own audit calendars.

What the choice costs you is calendar, not scope: a Type 1 can be issued once the controls are designed and implemented, while a Type 2 cannot be issued until the period it covers has ended. That is the trade to put in front of the customer, and the question to ask them is whether a Type 1 covers this cycle.

SOC 1 Type 2 vs SOC 2 Type 2: Same Type, Different Controls

Put a SOC 1 Type 2 next to a SOC 2 Type 2 and the mechanics are identical: a period, an opinion on design and operating effectiveness, a tests section with every deviation listed. Only the yardstick changes, management's objectives in one and the Trust Services Criteria in the other, so the effort of running the period is the same in both and the evidence largely is too.

Which Type to Start With

In practice, the common first path is a readiness assessment, then a Type 1 while the controls settle, then a Type 2 once a period can be covered. Going straight to a Type 2 makes sense when the customers asking will accept nothing less, provided the controls are already operating. A Type 2 tests whether the controls operated effectively throughout the period, and controls that did not can lead to a modified opinion (5).

SOC 2 Type 1 or Type 2: which one do you need?

The guide to SOC 2 Type 1 vs Type 2 covers the testing periods, sampling and the phrases buyers use in questionnaires when they ask for one or the other.

Do You Need SOC 1 or SOC 2? How to Decide

The SOC 1 versus SOC 2 choice comes down to two questions: who is asking, and what your service does for them. A request that names no team leaves the first one open, so start by asking for it.

Send this back when the request does not say who is asking. Two lines close the ambiguity faster than any internal debate:

"Which team needs the report: your finance or audit function, or your security and vendor review team?"

"Would a Type 1 report, covering our controls as of a date, work for this cycle, or do you need a Type 2 covering a period?"

Question 2 of the test below is the one you can answer today, without waiting for the reply.

1. Who is asking? A request from a customer's finance function, its internal audit team or its financial auditors points to SOC 1: those readers need the evidence that AU-C section 402 and PCAOB AS 2601 tell auditors to look for on the financial data your service touches (1, 9). A request from a customer's information security team, procurement or the people who run its vendor management programs points to SOC 2: those readers are evaluating your data security and how you protect client data.
2. What do you do for them? If your service processes transactions or holds balances that appear in the customer's financial reporting, you are a service organization in the AT-C section 320 sense (5), and a SOC 1 is in play. If you store, process or transmit the customer's data, whatever the data processing looks like, a SOC 2 is in play, and data security is what their reviewer will ask about.

When both answers point the same way, whether you need SOC 1 or SOC 2 is settled. When they disagree, or different customers ask for different reports, that is the signal to plan for both. When you are unsure, start with what the service does for the customer: transactions or balances that reach its financial statements point to SOC 1, and a service that only holds customer data is in SOC 2 territory, where the organization's security posture is what a vendor review tests.

What Do You Say Before You Have a Report?

Not having one yet is an ordinary position for a first request. A first report runs in this order:

1. A readiness assessment, if you choose one.
2. For a Type 2, the observation period.
3. The examination and the report.

While that runs, this is what to tell the customer:

• Say where you are. Name the report you expect to pursue and the Type.
• Ask what covers this cycle. A Type 1 covers your controls as of a date and can be issued once they are designed and implemented, so ask whether that satisfies the review while a Type 2 period runs.
• Commit only to the date you control. In practice you fix the period start with the service auditor, while the report date depends on the examination that follows the period.
• Keep the review moving in the meantime. In practice a customer's security questionnaire and your policy set carry the relationship while the first examination is under way. Neither is an AICPA artifact, and neither is a substitute for the report.

Table 6. Which report customers ask for, by type of service

Type of service	Report customers usually ask for	Why
Payroll and benefits administration	SOC 1	The service processes transactions and maintains records that appear in the customer's financial statements; the AICPA runs a resource center for the benefit plan auditors who use these reports (8)
Loan servicing and claims administration	SOC 1	Balances and claims flow into the customer's financial reporting
Payment processing and fintech platforms	Often both	Transactions feed the customers' books (SOC 1) and the platform holds customer and payment data (SOC 2)
SaaS and cloud platforms	SOC 2	The service stores, processes or transmits customer data; the request comes from security and procurement, not from auditors
Managed service and hosting providers	SOC 2	The provider operates the systems the customer's data lives on; availability is often in scope
Healthcare technology vendors	SOC 2	Buyers want independent evidence of the controls over sensitive data; a HIPAA obligation is a legal requirement, not an attestation report

Note. Illustrative mapping by CyberCrest: the customer's request and whether your service affects its financial reporting decide, not the industry label.

Three misconceptions to rule out before deciding:

• A SOC 2 does not replace a SOC 1. The AICPA's interpretation of AU-C section 402 states that a SOC 1 "is the preferred report for use in an audit of a user entity's financial statements" and that a SOC 2 report "is not specifically designed to address controls at a service organization relevant to a user entity's ICFR and therefore is unlikely to achieve the intent of the requirements in AU-C section 402" (1).
• The numbers are not a sequence. A SOC 1 is not a prerequisite for a SOC 2, and a SOC 2 is not the advanced version of a SOC 1.
• Neither report is better. Each answers its own reader.

When You Need Both a SOC 1 and SOC 2 Audit

A platform that runs its customers' payroll or processes their payments and also stores their employee or customer data gets asked for a SOC 1 by the customers' auditors and for a SOC 2 by their security teams. A provider whose customer base splits between finance-led and security-led buyers ends up in the same place.

• There is no combined report. A SOC 1 and SOC 2 audit means two examinations with two opinions, one under AT-C section 320 and one under AT-C sections 105 and 205 (5), each with its own description, assertion and restricted-use paragraph.
• The control activities overlap. Logical access, change management, system monitoring, incident response, risk management and vendor management appear in both, tested against the objectives in one and the Trust Services Criteria in the other.
• Plan the two engagements together. In practice the evidence for a shared control can be collected once and used in both engagements, and one CPA firm can scope both SOC audits, test the common controls a single time and align the two periods.

Raise the joint plan with the CPA firm before the first period starts.

How to Prepare for a SOC 1 vs SOC 2 Audit

Preparing for a SOC 1 vs SOC 2 audit follows one arc, whichever report you end up with: SOC audits differ in what they test, not in how a service organization gets ready for them. The work is front-loaded, and it is management's before it is the auditor's.

• Decide the report and the Type. Use the two questions above, then settle Type 1 or Type 2 with the customers who will read the report.
• Scope the system. Name the services and the system boundary; for a SOC 2, the trust services categories in scope; for a SOC 1, the control objectives that map to the financial processes you perform for customers.
• Run a readiness assessment. It is optional but the usual start: compare the controls you have against what the report requires, then implement controls where the gaps are, before the service auditor finds them.
• Formalize policies and owners. Effective internal controls need a documented policy and a named owner who can produce the evidence for each business process in scope.
• Select a licensed CPA firm. SOC reports are issued by certified public accountants under standards the AICPA promulgates (13). AICPA members in US public practice must "practice as partners or employees of firms enrolled in an approved practice-monitoring program" (14), and the AICPA's Peer Review Program Q&A lists SOC 1 and SOC 2 examinations among the engagements selected for review (15), so ask a prospective firm about its peer review standing and its SOC experience.
• Set the period and collect evidence through it. For a Type 2, decide the period before it starts and keep evidence as the controls operate; controls that operate but leave no evidence test as if they did not run.
• Write the description and the assertion. Both are management's responsibility. The SOC 2 description follows DC section 200 (6); the SOC 1 description follows the requirements in AT-C section 320 (5).

After the First Report

SOC audits repeat on a cycle. A Type 2 report covers a period, so in practice user auditors and vendor reviews expect one whose period is recent, and the gap between the end of one period and the issue of the next report has to be covered.

In practice the gap is covered by a bridge letter: a short statement issued by the service organization's management, not by the service auditor, saying whether any material changes to the control environment have occurred since the period ended. It is not an AICPA report and carries no auditor opinion, so readers treat it as a placeholder until the next report arrives.

Check the SOC 2 control requirements before you scope

The guide to SOC 2 compliance requirements lists the core control domains and the evidence auditors expect, and the breakdown of SOC 2 certification cost covers what drives the budget for a first and a repeat report.

SOC 1 vs SOC 2 vs SOC 3

SOC 3 is the third service-organization report: the general-use report on the same Trust Services Criteria, issued without the detail of a SOC 2. As the AICPA's SOC 3 page puts it, "like SOC 2, SOC 3 reports address controls relevant to security, availability, processing integrity, confidential and privacy. However, they do not provide the same level of detail. Therefore, they are considered general use reports and can be freely distributed" (7).

Table 7. SOC 1, SOC 2 and SOC 3 compared

	SOC 1	SOC 2	SOC 3
Controls covered	Relevant to user entities' internal control over financial reporting	Relevant to security, availability, processing integrity, confidentiality or privacy	The same categories as SOC 2
Criteria	Management's control objectives	Trust Services Criteria	Trust Services Criteria
Detail	Full description, controls and tests (Type 2)	Full description, controls and tests (Type 2)	Less detail than a SOC 2
Readers	User entities and user auditors	Intended users named in the report	Anyone
Distribution	Restricted use	Restricted use	General use, freely distributed

Sources: SOC 1 and SOC 3 pages (3, 7), AT-C section 320 (5), AU-C section 9402 (1); read September 2026.

If someone in your company wants a report to publish on the website, SOC 3 is the one to ask the service auditor for: SOC 1 and SOC 2 both stay restricted. The AICPA's suite also runs beyond service organizations, in SOC for Cybersecurity and SOC for Supply Chain (16, 17), but neither is what a customer means by "a SOC report."

SOC 2 or SOC 3: which report can you share publicly?

For the choice between the two trust services reports, read the comparison of SOC 2 vs SOC 3.

Conclusion

Each report answers a different reader. A SOC 1 exists so a customer's auditor can rely on your controls over the numbers that reach its financial reporting. A SOC 2 exists so a customer's security and procurement teams can rely on your controls over their data. The reader, together with what your service does for the customer, settles the choice. Both are AICPA attestation reports issued by CPA firms, both come as a Type 1 or a Type 2 and both are restricted-use documents.

• Send the two questions back when the request names no team: which team needs the report, and whether a Type 1 covers this cycle.
• For a SOC 2, scope security first. The other 4 categories join when your service commitments or a customer contract put them in scope.
• Agree the period start date in advance with the service auditor, and start the period only once the controls operate.

Scope the Right SOC Report Before the Period Starts

We help service organizations work out which report their customers need, scope the system with its criteria or objectives and close the gaps before SOC audits begin. Our SOC 2 compliance consulting services cover readiness, gap assessment and assessment support from a licensed CPA firm registered with the AICPA. The same scoping conversation settles whether a SOC 1, a SOC 2 or both belong on your roadmap.

Book a call about the requests your customers are sending you.

Sources

1. AICPA & CIMA. Interpretation No. 1 of AU-C Section 402, AU-C section 9402. https://assets.ctfassets.net/rb9cdnjh59cm/5QTUvULhbLtFkJESmJsRNv/41eaf369ac9aefb45c3063d6635f447f/92317096_au-c-9402-no-1.pdf
2. AICPA & CIMA. AICPA System and Organization Controls communications guidelines. https://www.aicpa-cima.com/resources/article/aicpa-system-and-organization-controls-communications-guidelines
3. AICPA & CIMA. SOC 1: SOC for Service Organizations: ICFR. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-1
4. AICPA & CIMA. 2017 Trust Services Criteria (With Revised Points of Focus, 2022). https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022
5. AICPA & CIMA. AICPA SSAEs, currently effective (AT-C sections, including AT-C 105, 205 and 320). https://www.aicpa-cima.com/resources/download/aicpa-ssaes-currently-effective
6. AICPA & CIMA. 2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022), DC section 200. https://assets.ctfassets.net/rb9cdnjh59cm/1vCduR1U2OnhIvFFaDBjMv/836050054707e9afb65adeb30d2e95d8/92317096_dc_section_200_clean_version.pdf
7. AICPA & CIMA. SOC 3: SOC for Service Organizations: Trust Services Criteria for General Use Report. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-3
8. AICPA & CIMA. Employee benefit plans: SOC 1 reports and service organizations resource center. https://www.aicpa-cima.com/resources/toolkit/ebp-soc-1-reports-and-service-organizations
9. PCAOB. AS 2601: Consideration of an Entity's Use of a Service Organization. https://pcaobus.org/oversight/standards/auditing-standards/details/AS2601
10. AICPA & CIMA. AICPA Statement on Standards for Attestation Engagements No. 18. https://www.aicpa-cima.com/resources/download/aicpa-statement-on-standards-for-attestation-engagements-no-18
11. AICPA & CIMA. AICPA Statement on Standards for Attestation Engagements No. 21. https://www.aicpa-cima.com/resources/download/aicpa-statement-on-standards-for-attestation-engagements-no-21
12. IAASB. Staff Overview: ISAE 3402, Assurance Reports on Controls at a Service Organization. https://www.iaasb.org/publications/staff-overview-international-standard-assurance-engagements-isae-3402-assurance-reports-controls
13. AICPA & CIMA. System and Organization Controls: SOC Suite of Services. https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
14. AICPA & CIMA. See common peer review deficiencies from SOC 1 and SOC 2 engagements. https://www.aicpa-cima.com/resources/download/see-common-peer-review-deficiencies-from-soc-1-r-and-soc-2-r-engagements
15. AICPA & CIMA. Questions and Answers About the AICPA Peer Review Program. https://www.aicpa-cima.com/resources/download/questions-and-answers-about-the-aicpa-peer-review-program
16. AICPA & CIMA. SOC for Cybersecurity. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-for-cybersecurity
17. AICPA & CIMA. SOC for Supply Chain. https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-soc-for-supply-chain