Which SOC report do customers actually need: SOC 2, SOC 1 or SOC 3?
When a customer, bank or contract asks for a SOC report, most technology vendors are being asked for a SOC 2, which is restricted use and built on the trust services criteria. A SOC 1 covers services that affect a customer's internal control over financial reporting, and a SOC 3 is a short general use summary that anyone can receive. The right answer depends on what the customer's auditor or risk team will test, so ask for that before you choose a report. Ask who will read the report, which controls they need to rely on, and whether they need the full detail or a public summary.
Only an independent CPA firm can issue any of these reports. Your organization owns its controls and decides the scope, and an implementation partner can prepare systems, policies and evidence, but none of them can issue an opinion. Confirm the report type in writing with the customer before scoping, because a SOC 1 examination tests different controls and asks for a different system description than a SOC 2. Also confirm whether they want a Type 1 or a Type 2 report, since the AICPA treats both SOC 1 and SOC 2 as available in either form. Ask the customer to name the specific controls their auditor will test so you can judge whether the examination you plan will answer that question.
A useful test is to read the AICPA's SOC 3 overview alongside the customer's request. If they need to rely on your controls in detail, a SOC 2 is usually the answer. If they only need proof that a examination exists and covers the categories they care about, a SOC 3 may satisfy the request, but many customers still require the SOC 2 itself under a restricted use agreement. Record the decision, the report type and the named reader in your vendor file so the scope and cost discussion starts from the right requirement.
How SOC 1, SOC 2 and SOC 3 differ on subject, criteria and readers
This table compares the subject matter, criteria, readership and contents of SOC 1, SOC 2 and SOC 3, and whether each comes as a Type 1 or Type 2 report. Read it by first asking which financial reporting or trust question your customer is asking, then checking who is allowed to receive the report.
| Feature | SOC 1 | SOC 2 | SOC 3 |
|---|---|---|---|
| Subject matter | Controls at a service organization likely to be relevant to user entities' internal control over financial reporting | Controls relevant to security, availability, processing integrity, confidentiality or privacy | Same categories as SOC 2, covered in less detail |
| Criteria used | Control objectives set for financial reporting relevance | AICPA 2017 Trust Services Criteria | AICPA 2017 Trust Services Criteria, summarized |
| Intended readers | Management, user entities and their financial statement auditors | Restricted use, generally for management, customers and their vendor reviewers | General use, freely distributed to anyone |
| Who may receive it | Service organization management, user entities and user auditors only | Use is generally restricted; confirm the recipient list with your CPA firm | Anyone, including the public and prospective customers |
| Typical report contents | Service organization's description and control testing results for financial reporting controls | Management's description of the system, control testing and detailed results, with the auditor's report | Management's assertion, system boundaries, principal service commitments and system requirements, and the auditor's report |
| Type 1 or Type 2 available | Yes, both Type 1 and Type 2 | Yes, both Type 1 and Type 2 | Issued as a general use report; confirm with your CPA firm which period it covers |
| Usual question it answers | Can we rely on this vendor's controls for our financial statements? | Are this vendor's security and related controls designed and operating as described? | Can I show a public summary of our SOC 2 examination without sharing the full report? |
When a SOC 1 report is the right answer
A SOC 1 report is the right answer when the service organization's controls feed into a customer's financial statements. SOC 1 is an examination of controls at a service organization that are likely to be relevant to user entities' internal control over financial reporting. It is written for the user entities themselves and for the CPAs who audit their financial statements, not for prospective buyers reviewing security. Consider an illustrative payroll platform that calculates pay, withholding and benefit deductions for a customer's employees. If a calculation error or an unauthorized change to pay rules could misstate the customer's payroll expense or liabilities, the customer's financial statement auditor has a direct interest in the platform's controls over those calculations and changes, and a SOC 1 is the report that addresses that interest. A billing platform that issues invoices and records revenue for a customer raises the same question.
A SOC 2 does not replace a SOC 1 in that situation. A SOC 2 reports on controls relevant to the security, availability, processing integrity, confidentiality or privacy categories, and its use is generally restricted to the parties named in it. Those categories answer a different question from whether a customer's financial reporting controls operate as intended. Where the customer's auditor needs financial reporting controls tested, a SOC 2 may be useful background but will not supply the evidence that auditor is looking for. The customer's auditor usually decides which report is needed, so the decision belongs in conversation with the customer's audit team rather than being settled by the vendor alone.
Before committing to either report, confirm three things in writing with the customer: whether their financial statement auditor has asked for a SOC 1, which control objectives that auditor expects to see covered, and whether the service touches financial data in a way that would make a SOC 1 scope meaningful. The AICPA's communications guidelines for System and Organization Controls are a useful reference when wording these requests. If the answer is a SOC 1, a SOC 2 may still be requested for security reviews, and the two reports can be planned together, but each must be scoped to its own purpose.
Which report each reader needs
A SaaS company selling to enterprise customers usually shares a SOC 2 report, because the customer's vendor review is about security, availability, confidentiality and, where in scope, privacy controls over the service. The SOC 2 is restricted in use, so it is typically shared under an NDA rather than posted publicly. Customers will normally ask for the most recent Type 2 report and, if the period has ended, a bridge letter covering the gap.
- Request the scope first: Confirm which categories the customer expects beyond security, since a report that omits a category they need may not answer their question.
- Check the system description: Confirm the services, infrastructure and locations match the product the customer buys.
- Read the opinion and exceptions: Look for qualified opinions and any noted exceptions, and ask how management responded.
- Confirm the period: A Type 2 report covers a stated observation period, so check the dates against the contract.
- Check subservice organizations: Note whether cloud providers are included or carved out, and whether complementary user entity controls assign duties to the customer.
Before you send anything, confirm in writing with the customer which report type and period their vendor process accepts.
When a vendor's service affects a customer's internal control over financial reporting, the customer's financial statement auditors may need a SOC 1 instead of a SOC 2. A SOC 1 is an examination of controls relevant to user entities' financial reporting and is intended for user entities and the CPAs who audit their financial statements. Use is restricted to the service organization's management, user entities and their user auditors.
- Request a SOC 1 when finance asks: Payroll, billing, payment processing and ledger-related services are typical cases where the customer's auditor asks for a SOC 1.
- Ask which type is needed: SOC 1 reports also come as Type 1 or Type 2, so confirm whether the auditor needs control design at a date or operating effectiveness over a period.
- Check the control objectives: Confirm that the control objectives in the report cover the processes the customer's auditor is testing.
- Review user entity controls: Identify the controls the customer must operate themselves and confirm they have owners.
- Confirm the auditor's needs: Ask the customer's audit team which report, period and bridge arrangement they accept.
A SOC 2 may still be requested alongside a SOC 1 for security questions, so confirm whether one report or both are required.
A company that wants to show prospects a public signal of its controls usually publishes a SOC 3 report. SOC 3 reports cover the same categories as SOC 2 in less detail, and the AICPA describes them as general use reports that can be freely distributed. A SOC 3 suits a public website, a trust center or a marketing page where a SOC 2 report would be inappropriate to post.
- Expect less detail: A SOC 3 includes management's assertion, a description of the system boundaries, principal service commitments and system requirements, and the service auditor's report, but not the detailed test results.
- Check the categories: Confirm the categories in the SOC 3 match those in the underlying SOC 2 examination.
- Check the date and period: Confirm the period the report covers and whether it is still current for the claims you make.
- Avoid overstating the report: Do not describe a SOC 3 as a certificate or as proof of full compliance, since it is an attestation report from a CPA firm.
- Use the AICPA guidance: Follow the AICPA's communications guidelines when referring to the report in marketing.
A public SOC 3 rarely answers a customer's detailed vendor review, so most companies offer both a SOC 3 and a SOC 2 under NDA.
A procurement or third-party risk team reviewing a vendor should first establish what the contract and its regulator require. Procurement teams generally ask for a SOC 2 for technology services that handle customer data, and for a SOC 1 where the service touches financial reporting. A SOC 3 may satisfy a quick public check, but it rarely satisfies a detailed review. Confirm the requirement in writing with the business owner and, where relevant, the vendor's compliance team.
- Confirm the report type: Ask whether the review requires a SOC 2, a SOC 1, a SOC 3 or a combination, and why.
- Confirm the report is from a CPA firm: A SOC report is issued by an independent CPA firm, so the vendor cannot certify itself.
- Check the period and bridge letter: Confirm the observation period ends recently enough for your review, and request a bridge letter for any gap.
- Review exceptions and complementary controls: Record any exceptions and the controls your organization must operate.
- Map the report to your risk: Confirm which criteria cover the data and services you will use.
The report is only useful if the scope matches the service you are buying, so check the system description before you accept it.
Common mistakes when a customer asks for a SOC report
Most mismatches between what a customer asks for and what a service organization delivers come from confusing report types, audiences and scope. Each mistake below is easy to make in a vendor review and expensive to correct later. Check the report type, its audience and its scope before sending anything.
Asking for a SOC 3 instead of a SOC 2
A SOC 3 covers the same categories as a SOC 2 in less detail, and it is a general use report that can be freely distributed. Customers who need the control descriptions, the testing performed and the exceptions must ask for the full SOC 2 report, which is generally restricted to the parties named in its use terms. Ask the vendor for the full report under an NDA, and reserve the SOC 3 for public-facing trust pages.
Assuming a SOC 2 covers financial reporting
A SOC 2 reports on controls relevant to security, availability, processing integrity, confidentiality or privacy. It does not examine controls over financial reporting. If a service affects a customer's internal control over financial reporting, the customer's auditor usually needs a SOC 1 instead. Check which controls the service's financial impact depends on before deciding which report to request.
Treating a SOC 2 as a certificate
A SOC 2 is a CPA's attestation report that expresses opinions as of a specific date (Type 1) or over a period of time (Type 2). No one certifies a company as SOC 2 compliant, and a certificate with that wording should prompt questions. Ask for the signed report, the auditor's name, the report period and the opinion, then confirm the CPA firm's license with the relevant state board.
Accepting a SOC 3 seal as proof of audit
Badges and seals on a website show that a company published a SOC 3 or chose to display the AICPA logo, but they do not prove the audit's scope, period or results. A seal can appear on a page while the underlying examination is out of date or covers a different system. Request the report itself, read the opinion and the system boundaries, and compare them with the services you are buying.
Requesting a Type 1 when a Type 2 is needed
A Type 1 report describes the system and the design of controls at one point in time. A Type 2 report adds an opinion on operating effectiveness over an observation period, which is what most vendor reviews are trying to learn. If your review asks whether controls worked, a Type 1 does not answer that question. Ask for the Type 2 covering the most recent period, and if it is not yet available, ask what bridging information the vendor will provide.
Skipping the check on scope
A report only supports the services listed in its system description and the locations, subservice organizations and trust services categories it covers. A customer buying a product module, a region or a hosted feature that the report excludes is not covered by it. Read the system description and the carve-out or inclusive treatment of cloud providers before you rely on the opinion, and confirm the service you purchase appears there.
Questions buyers ask about SOC 1, SOC 2 and SOC 3
Can a SOC 3 report replace a SOC 2 report for a customer?
Usually not. A SOC 3 covers the same trust services categories as a SOC 2 but in less detail, and it is a general use report that can be freely distributed. Customers doing vendor due diligence typically want the detailed SOC 2, including the system description, the tested controls and any exceptions, which is why its use is generally restricted. A SOC 3 suits a public trust page or a prospect who only needs assurance that an examination exists. Ask the customer which report their vendor review requires before sending anything.
Can a SOC 2 report replace a SOC 1 report?
Only when the customer's question is about security, availability, processing integrity, confidentiality or privacy. A SOC 1 examines controls relevant to a service organization's effect on the customer's internal control over financial reporting, and it is intended for user entities and the CPAs who audit their financial statements. If your service feeds into a customer's financial statements, for example billing, payroll or ledger processing, their auditor may ask for a SOC 1 instead. Confirm with the customer's finance or audit team which report their auditors accept.
Do SOC 1 and SOC 2 reports both come as Type 1 or Type 2?
Yes. Both SOC 1 and SOC 2 are available as a Type 1 report, which covers the system description and the design of controls as of a date, or as a Type 2 report, which adds an opinion on operating effectiveness over a period. The type describes the depth of testing over time, not the topic of the report. Customers reviewing a Type 1 should understand that it does not show controls working over a period. Ask which type your customer's review requires before scheduling the examination.
Who can issue a SOC 1, SOC 2 or SOC 3 report?
Only an independent CPA firm can issue any of these reports, because they are attestation reports, not certificates. The organization owns its controls and the description of its system, and it provides management's assertion and written representations to the CPA firm. DeployOpen does not issue audit reports, attestations or certifications. An implementation partner can prepare systems, controls and evidence for the examination, but the report itself comes from the CPA firm. Verify the firm's licensing and peer review status before engaging it.
What does a customer need to do to receive a restricted SOC 2 report under NDA?
Typically the customer signs a non-disclosure agreement with the service organization and states the business purpose for which it needs the report. The service organization then shares the full SOC 2 report under that agreement, usually through a secure portal. Customers should expect to review the system description, the trust services criteria tested, the auditor's opinion and any exceptions. Check the report's stated restrictions and its period, because a report that is months old may need a bridge letter covering the gap. Your legal and procurement teams should confirm the exact terms.
What does a SOC 2 cost and how long does it take to get the right report?
Cost and time depend on the report type, the categories in scope, the size and complexity of the system, the readiness work already done and the CPA firm's fee. A Type 2 report needs an observation period in addition to fieldwork, so it takes longer than a Type 1. Fees are paid to the CPA firm for the examination, while readiness, remediation and tooling are separate costs, often one-time or recurring. Ask any firm for a written scope and engagement letter before committing. For detailed breakdowns, read the SOC 2 cost and SOC 2 timeline pages, and the SOC 2 Type 1 vs Type 2 page for the difference in duration.
SOC for Cybersecurity and SOC for Supply Chain
The AICPA's SOC suite includes two examinations that are often confused with SOC 2: SOC for Cybersecurity and SOC for Supply Chain. Both are separate engagements with their own subject matter and their own reports, and neither is a renamed or lighter version of SOC 2. The reason for the confusion is the 2017 change in terminology. The AICPA redefined SOC as system and organization controls, replacing service organization controls, so the umbrella name now covers SOC 1, SOC 2, SOC 3 and these newer examinations, and the word "SOC" alone no longer tells a reader which report they are holding.
Before accepting a request, confirm with the requester which report name they mean and what they will do with it. A customer who writes "send us your SOC report" may want a SOC 2 Type 2, a SOC 1 for financial reporting controls, or, less commonly, one of the other examinations. Ask the requester to name the report, the trust services categories or subject matter they need covered, the period they want tested, and whether they need a restricted or general use report. Get that answer in writing before you scope the work, because the CPA firm will scope the engagement from the same description. Do not assume that a SOC for Cybersecurity report satisfies a request for SOC 2, or that a SOC 2 satisfies a request for a supply chain examination. Each depends on its own criteria and its own system or subject description.
Treat a substitution as a decision for the requester, not for your team. If the customer's vendor review accepts only SOC 2, or only a specific report type, a different examination will not close the item, however reputable the CPA firm. If you are unsure which examination fits, your CPA firm can explain its scope and criteria in the engagement letter, and the requester's own third-party risk or procurement team should confirm what they accept. Recording that confirmation keeps the question from resurfacing at renewal.
How to answer a SOC report request in four steps
This sequence turns a vague request for a SOC report into a written set of requirements, so the report you share matches what the requester actually needs to rely on.
Confirm the report type and audience in writing
Ask the requester to state in writing which SOC report they need (SOC 1, SOC 2, or SOC 3), why they need it, and who will read it, such as their risk team, their auditors or the public. Ask whether their own auditors or regulators name a specific report. Your compliance lead or account owner records the answer. The step is done when the requester has replied in writing and you have filed that reply with the request. A SOC 1 request for a service that affects customers' financial reporting points to a different report from a SOC 2 request about security controls, so this written answer decides the rest of the work.
Confirm the report period and Type
Ask whether the requester needs a Type 1 report, which covers the design of controls as of a date, or a Type 2 report, which adds an opinion on operating effectiveness over a period. For a Type 2, ask for the exact period they need covered and whether a later bridge letter from management is acceptable for the gap. Record the Type, the period start and end, and the reason for each in the same written requirement. Your compliance lead should check that the period has already occurred or is scheduled with your CPA firm, because a report cannot cover a period that has not yet run. The step is done when the Type and period are confirmed in writing.
Agree the categories and systems in scope
For a SOC 2, confirm which Trust Services categories beyond security the requester expects, such as availability, confidentiality, processing integrity or privacy, and which products, services, locations and subservice organizations fall within the report. For a SOC 1, confirm which services and controls relate to the customer's internal control over financial reporting. Your compliance lead compares these answers with what the report will actually cover and flags any gap before anything is promised. The output is a short scope statement that both sides have accepted in writing. If the requester asks for something the report cannot cover, state that in writing rather than letting them assume it.
Share the right report under the right terms
A SOC 2 report is generally restricted, so share it only after the requester signs a non-disclosure agreement that limits its use to the purposes you agreed. Send the report issued by the independent CPA firm, not a summary or a statement written by your team. If the requester only needs a general-use document and the AICPA's conditions for a SOC 3 are met, publish or send the SOC 3 instead, which can be freely distributed. Keep a record of who received which report, the date, and the NDA reference. The step is done when the report has been delivered under the agreed terms and the delivery is logged for your next audit cycle.
What may change in the attestation standards
The AICPA Auditing Standards Board exposed proposed revisions to its baseline attestation standards in February 2026. According to the Journal of Accountancy, if the revisions are adopted, they would apply to engagements beginning on or after June 15, 2029. The standards in question sit beneath the examinations that issue SOC 1 and SOC 2 reports, so the proposal matters to anyone who expects a report to be issued in the coming years. It is a proposal, not an adopted rule, and its final form may differ from the exposure draft.
Do not plan around the proposal until your CPA firm has confirmed in writing how it would affect your engagement. Ask the firm whether any change would alter the wording of the service auditor's report, the description of the system, the written representations management must sign, or the timing of fieldwork. Ask also whether a change would apply to a report already in progress or only to engagements that start after the effective date. A firm that is reviewing the proposal in detail will be able to tell you which of your controls and evidence would need to change.
For a SOC 1 or SOC 2 that is already planned, the practical step is to keep your system description, control matrix and management representations current so that any later change is a documentation update rather than a rebuild. Check the AICPA's pages on the proposal and ask your firm to confirm the status before each engagement letter is signed. Treat the 2029 date as the outer limit of what the proposal says, and confirm the current status of the standards with your auditor rather than relying on any secondhand summary.
