Is a SOC 2 report mandatory, and who needs one?
No law reviewed here requires a SOC 2 report by name. When a customer, bank or contract asks for one, the request almost always comes from a vendor review, a contract clause or a regulator's third-party risk expectations. The decision to pursue a SOC 2 belongs to your organization, and the answer depends on who the buyer is and what their own rules require of them. Start by asking the requester which report they need, which trust services categories they expect, and whether they want a Type 1 or a Type 2 opinion.
Only an independent CPA firm can issue a SOC 2 report. Your organization owns its controls and its system description, and an implementation partner or consultant can help prepare systems and evidence, but none of them can sign the attestation. Several frameworks point buyers toward reviewing assurance reports from their providers. The 2023 US interagency guidance on third-party relationships says a bank may consider a third party's SOC reports during due diligence and may specify in contracts which audit reports it is entitled to receive. The FTC's Safeguards Rule expects covered financial companies to monitor and periodically reassess their service providers. The EU's DORA technical standards list independent audit reports among the assurance a financial entity may use on an ICT provider, and NIS2 supplier contracts may include audit reports where appropriate. None of these name SOC 2 as mandatory; they describe what a buyer may ask for.
Ask each requester for the clause, regulation or questionnaire that drives the request, and for the exact report and period they will accept. If a SOC 2 is not the right report, a SOC 1 may apply when your service affects the customer's financial reporting. Confirm the scope and the restricted-use terms before you commit time or budget.
Which customers and regulators actually ask for SOC 2
No statute in this group names SOC 2 as mandatory. The requests come from buyers and supervisors who must assess their providers, and each one reaches a SOC 2 report through a different route. The cards below separate those routes so you can see which one applies to your contracts.
Enterprise vendor reviews
Most SOC 2 requests come from customers running their own third-party risk reviews before signing or renewing. Their security questionnaires often ask for the current report, the period it covers and the exceptions noted. Check whether the customer wants a Type 1 or Type 2 report, and whether it expects a bridge letter if the latest period has ended.
US bank third-party guidance
The 2023 interagency guidance on third-party relationships says a bank may review a provider's SOC reports and independent certifications during due diligence. It also suggests contracts specify the audit reports the bank is entitled to receive and how often. Ask your bank customer which report types and frequency their contract requires before the first review.
Federal Reserve community bank proposal
The Federal Reserve's proposed guide for community banks, published in September 2026, suggests reviewing SOC 2 and ISO reports when assessing a cybersecurity vendor. It also lists SSAE 18 SOC reports among assessments a bank may rely on for operational resilience. This is a proposal, not final guidance, so confirm its status with your bank customer before building a contract around it.
FTC Safeguards Rule oversight
Financial companies covered by the FTC Safeguards Rule must select providers with suitable safeguards, set security expectations in contracts, monitor the provider's work and reassess providers periodically. A SOC 2 report is one way to gather that evidence, but the rule does not name it. Agree in the contract which report you will provide and how the customer can verify ongoing controls.
EU financial entities under DORA
Under DORA, financial entities must assess their ICT third-party providers and must write contract terms covering audit rights and audit reports where appropriate. Delegated Regulation (EU) 2024/1773 says the assurance used may include independent audit reports and appropriate third-party certifications, and more than one kind is often used. A SOC 2 can serve as one input, but it rarely replaces the financial entity's own audit rights.
NIS2 supplier contracts
Entities under NIS2 must write supplier contracts that cover, where appropriate, incident notification, audit rights or audit reports, vulnerability handling and exit obligations. Implementing Regulation (EU) 2024/2690 sets these expectations for digital infrastructure and digital provider entities. Ask each EU customer which audit reports they accept, because a SOC 2 is a US attestation that may need supplementing for EU-specific terms.
Where the requirement comes from: law, regulator guidance or contract
A statutory mandate and a contractual or supervisory expectation are different things, and the first step is to establish which one applies to you. No law named in this section requires a SOC 2 report by name. The FTC Safeguards Rule requires covered financial institutions to select service providers with appropriate skills, set security expectations in contracts, monitor the provider's work and reassess providers periodically. It leaves the method of oversight to the financial institution, so a SOC 2 is one way to evidence that oversight, not the obligation itself. Read the rule's own text and your contract clauses before assuming a report is required.
US bank guidance works the same way. The 2023 interagency guidance on third-party relationships says a bank may consider reviewing a provider's SOC reports and independent certifications during due diligence, and it suggests contracts specify the types and frequency of audit reports the bank is entitled to receive. The Federal Reserve's 2026 proposed guide for community banks, which is still a proposal, also lists SSAE 18 SOC reports among assessments a bank may rely on. Each of these texts makes a report an option the bank may use. Your task is to find the clause in the bank's contract or due diligence questionnaire that names a SOC report, the report type it asks for, and the frequency it expects.
EU rules follow the same pattern. Article 6 of Delegated Regulation (EU) 2024/1773 requires a financial entity's policy to specify the assurance it uses on an ICT provider. It lists the entity's own audits, independent audit reports, the provider's internal audit reports and appropriate third-party certifications as options, and it expects more than one to be used where appropriate. An independent audit report is therefore one assurance option, and a SOC 2 is only one form of that option. Check which entity you are in the supervised chain, which article your customer relies on, and whether the customer accepts an ISO report, a provider audit or a SOC 2 in its place. Also remember that a customer requesting a report does not transfer its own responsibility for the risk.
When a SOC 2 is the right report and when a SOC 1 is
A SOC 1 report addresses controls relevant to user entities' internal control over financial reporting. The question it answers is whether a service provider's controls could affect the numbers a customer reports to its own auditors. A provider that processes payroll transactions, runs billing that feeds the general ledger, or hosts financial close systems may fall into this group, because errors in its controls can flow directly into the customer's financial statements. In that case, the customer's external auditor will usually want a SOC 1 because it is written for that auditor's work on the customer's controls.
- Test question: Ask whether a failure in your service could misstate a customer's financial statements without anyone noticing.
- Typical services: Payment processing, payroll calculation, invoicing and ledger feeds.
- Who reads it: The customer's financial statement auditor and internal audit team.
- Scope difference: A SOC 1 concentrates on the controls that affect financial reporting, not on general security posture.
- Requesting party: A customer that requests a service auditor's report to assess risk remains responsible for that risk.
Confirm with your largest customers' finance and audit teams which report they expect before you commit to a report type.
A SOC 2 report addresses controls relevant to security, availability, processing integrity, confidentiality or privacy. Most software and cloud providers are asked for this report because customers want evidence that the provider protects their data and keeps the service running, not because the service touches their accounts. Vendor risk teams, banks applying third-party risk guidance and procurement reviewers usually request a SOC 2 for these reasons. The report is restricted, so it is shared under agreement with the intended users.
- Security is always in scope: Every SOC 2 covers the common criteria, and other categories are added when customers need them.
- Vendor reviews: Procurement and third-party risk teams use the report as independent evidence during due diligence.
- Bank expectations: US banking guidance says a bank may review a third party's SOC reports during due diligence.
- Restricted use: The provider shares the SOC 2 under NDA with customers and intended recipients.
- Type choice: A Type 1 shows design at a point in time, while a Type 2 covers operating effectiveness over a period.
Check which categories your customers' vendor questionnaires actually name before you add categories to scope.
A SOC 3 report covers the same trust services categories as a SOC 2 but in less detail. It is a general use report that can be freely distributed, so it suits public-facing needs such as a website trust page, marketing material or prospects who want a summary before signing an NDA. It does not replace a SOC 2 for a customer's vendor review, because a reviewer will usually need the detailed system description and the testing results that the SOC 2 contains.
- Distribution: A SOC 3 can be posted publicly, while a SOC 2 is shared only with intended users.
- Detail: A SOC 3 omits the detailed test procedures and results found in a SOC 2.
- Early-stage use: Prospects may accept a SOC 3 while the full SOC 2 is under NDA review.
- Not a substitute: Due diligence teams normally ask for the full SOC 2 report.
- Shared criteria: Both reports use the same categories, so the scope decisions you make for a SOC 2 also shape the SOC 3.
Ask prospects whether a summary is enough for their first review or whether they need the restricted report under NDA.
What a SOC 2 report does and does not prove to a buyer
A SOC 2 report is an attestation report issued by a licensed CPA firm. It is not a certificate, and no one can truthfully sell a SOC 2 certification. The report describes the service organization's system and states the auditor's opinion on whether controls were suitably designed (Type 1) or operated effectively over a period (Type 2) against the Trust Services Criteria. It shows that an independent examiner tested the controls the organization chose to describe. It does not show that the organization is secure, that no incident occurred, or that every risk a customer cares about is covered. The organization owns its controls and its system description, and an implementation partner or consultant can prepare systems and evidence, but only the CPA firm issues the report.
Read the report's scope and use restrictions before you rely on it. A SOC 2 report is generally restricted, so the service organization shares it under a non-disclosure agreement with intended users such as customers, prospects and regulators. A SOC 3 is the general-use alternative with less detail. Check the period covered, the categories and systems in scope, any carved-out subservice organizations, and every exception in the auditor's section. A bridge letter is a different document: it is a statement from the service organization's management, not the CPA firm, covering the gap between the end of the last examination period and a later date. Ask what it says, who signed it, and confirm that it does not replace a current report.
Reliance on a SOC 2 report does not transfer your duties. A bank, fintech or other regulated customer still has to assess the risk of the vendor relationship, decide which complementary user entity controls apply to its own environment, and monitor the provider over time. Confirm that your contract entitles you to the report and to periodic updates, and build your own review of exceptions and subservice organizations into your third-party risk process. Before you accept a report as evidence, have your team confirm the scope and period with the vendor and, where needed, with the CPA firm that issued it.
What to confirm with the customer before starting a SOC 2
This sequence turns a vague request for a SOC 2 report into a written requirement the team can scope against, so the examination covers what the customer actually needs and nothing it does not. Each step ends with a document or answer that goes into the project file.
Pull the exact clause or questionnaire item
Ask the procurement or security contact for the contract clause, security addendum or questionnaire line that mentions SOC 2, and copy its wording verbatim into the project file. Many requests say only "SOC 2 report" without stating a type, period or scope, and the exact wording determines what must be delivered. Done when the team holds the quoted text and knows which document and section it came from.
Ask which report type is acceptable
Confirm in writing whether the customer accepts a Type 1 report, which covers the system description and control design as of a date, or requires a Type 2 report, which adds an opinion on operating effectiveness over a period. The answer decides whether an observation window must run before the report can be delivered. Done when the customer has named the acceptable type or types in writing.
Confirm the trust services categories in scope
Ask which of the five trust services categories (security, availability, processing integrity, confidentiality and privacy) the customer expects to see. Security is always covered by the common criteria, while the other four add criteria only when they are included. Done when the customer has listed the categories it relies on, with reasons tied to the service it buys.
Confirm the systems and services in scope
Identify which products, environments, locations and subservice providers the customer's data touches, and ask whether the customer needs the report to cover the specific service it uses. This determines the system boundary that the system description must describe. Done when the team has a written list of in-scope services and a note on any cloud or hosting providers the customer expects to appear in the report.
Check whether a SOC 3 or bridge letter will satisfy the request
Ask whether a SOC 3 report, which covers the same categories in less detail and can be freely distributed, is enough, or whether the customer needs the restricted SOC 2 report. If the most recent Type 2 period has ended, ask whether a bridge letter from management covering the gap is acceptable. Done when the customer has confirmed in writing which document will close the request.
Confirm the deadline and delivery format
Ask by what date the report or interim document must be delivered, and whether the customer will accept a report in progress, a readiness statement or an agreed timeline if the examination is not complete. Confirm the delivery method and who is authorized to receive the report under the restrictions that apply. Done when the deadline, format and recipient are recorded and the team can check them against a realistic examination schedule.
Record the written requirement and scope against it
Consolidate the answers into a single requirement note listing the clause, report type, categories, systems, acceptable interim documents and deadline, then have the customer and the internal owner confirm it by email. This note becomes the scoping input for the readiness work and for any quote from an examination firm or implementation partner. Done when the signed-off note is filed and every later scoping decision can be traced back to it.
Frequently asked questions about SOC 2 requirements
Is SOC 2 required by law in the United States?
No federal or state law names SOC 2 as a mandatory requirement, and the AICPA does not regulate who must hold one. The obligation usually comes from a contract, a customer's vendor review, or a regulated customer's duty to oversee its providers. US banks, for example, may review a third party's SOC reports during due diligence under the 2023 interagency guidance on third-party relationships, and the FTC Safeguards Rule requires covered financial companies to monitor their service providers. Those duties do not name SOC 2 specifically, so the first step is to ask the customer which evidence it must collect. The cost and timeline pages explain what a report involves once you know the answer.
Do EU customers require SOC 2 or can they accept other evidence?
EU rules generally do not name SOC 2. Under DORA and its delegated regulation, a financial entity chooses the assurance it relies on for an ICT provider, which may include its own audits, independent audit reports, the provider's internal audit reports and appropriate third-party certifications, often using more than one. NIS2 supplier contracts similarly cover audit rights or audit reports where appropriate. A SOC 2 report can therefore be one accepted input, but an ISO/IEC 27001 certificate, an audit right or a customer audit may satisfy the same question. Confirm the acceptable evidence with each customer in writing.
Can we self-certify SOC 2 compliance?
No. A SOC 2 is an examination performed by an independent CPA firm, which issues an attestation report with opinions as of a date or over a period. A company can run its own controls and assess itself, but it cannot issue a SOC 2 report or certificate, and claims of being SOC 2 certified on the strength of internal checks should be treated with suspicion. Your organization owns its controls and its system description, while the CPA firm forms the opinion. Implementation partners can prepare systems and evidence, but they do not issue reports. The auditor selection page explains how to verify a firm's license and standing.
What if our customer only asks for a SOC 3 report?
A SOC 3 report covers the same trust services categories as a SOC 2 in less detail, and it is a general use report that can be freely distributed, often published on a website. A SOC 2 report is restricted to intended users, so customers under a contract usually receive the full report under an NDA. Ask the customer what it will do with the report. If it needs a public summary for marketing or procurement pages, a SOC 3 may meet that need, but a bank or a regulated customer reviewing controls will usually still ask for the SOC 2. The SOC 2 vs SOC 3 page compares the two in detail.
Who in our team must be involved?
Several roles must own parts of the work because management, not the auditor or a consultant, is responsible for the system description, the controls and the written representations the examination relies on. Typically that means an executive sponsor, a security or compliance lead, engineering leads for infrastructure and software delivery, HR for joiner and leaver records, and the operators who produce access reviews and incident records. Legal usually reviews contract and NDA terms for report sharing. Expect the work to span several functions rather than sit with one person. The readiness and auditor pages set out what each role typically handles.
Does a customer's SOC 2 request mean we must have a Type 2 report?
Not always. Many customers first ask for a Type 1 report, which covers the system description and control design as of a date, while a Type 2 report adds an opinion on operating effectiveness over an observation period. Regulated customers and banks more often expect Type 2 evidence because it shows controls working over time. The contract wording decides what is required, so read the exact report type and period it names. The Type 1 vs Type 2 page explains what each report contains and what customers can rely on.
How do we know if our customer is actually asking for SOC 2 or SOC 1?
Check whether the service affects the customer's internal control over financial reporting. SOC 1 reports address that subject, while SOC 2 reports address controls relevant to security, availability, processing integrity, confidentiality or privacy. Most software and cloud vendors receive SOC 2 requests, but a payroll or financial processing provider may be asked for a SOC 1. Ask the customer's vendor management team which report and which criteria it needs, and get the answer in the contract. The SOC 2 vs SOC 1 and SOC 3 page covers how to decide.
How DeployOpen works on this
Once your organization confirms that a customer, contract or regulator requires a SOC 2 report, DeployOpen helps prepare the systems and evidence that the independent CPA firm will examine. We build and document the controls in your own infrastructure, and we do not issue reports or attestations.
How we scope
- Written scope agreed before work starts, covering systems, environments and the controls to be prepared
- Clear split of responsibilities: your organization owns its controls, DeployOpen prepares systems and evidence
- Identification of which SOC 2 categories and subservice providers your CPA firm will expect to see in scope
How we build
- Self-hosted open-source platforms deployed in your own cloud accounts, data centers or air-gapped networks
- Access, logging, change and backup configurations mapped to the relevant Trust Services Criteria
- Evidence collection set up so records such as access reviews and configuration baselines can be produced on request
How we hand over
- Written documentation of system configurations, control designs and the evidence each control produces
- Walkthrough of the evidence sources so your team and your CPA firm can trace each control to its records
- Clear list of items your organization still owns, such as policies, approvals and management's assertion
How we support
- Fixed-scope engagements with deliverables and timelines agreed in writing before work begins
- Ongoing support, upgrades and continuous testing available as a retainer for recurring programs
- Questions about the report itself, its opinion or its timing should be directed to your independent CPA firm
