What Is a SOC Report? SOC 1, SOC 2, and SOC 3 Explained

A SOC report (System and Organization Controls report) is an independent auditor's attestation report on a service organization's controls, issued by a licensed CPA firm under the AICPA's SSAE 18 attestation standard. It gives customers a third-party opinion on whether the controls a company claims to have are suitably designed, and in a Type 2 report, whether they operated effectively over an observation period. Customers request SOC reports during vendor due diligence, and increasingly as a condition of signing.

What is the difference between SOC 1, SOC 2, and SOC 3?

The three report types answer different questions for different readers. SOC 1 covers controls relevant to a customer's financial reporting, SOC 2 covers controls over security and related criteria, and SOC 3 is a shortened, public version of a SOC 2.

SOC 2 is the report software and services companies get asked for in the large majority of cases. SOC 1 applies when the service directly feeds a customer's financial statements. The companion comparison of SOC 1 vs SOC 2 works through which report fits which business.

Is a SOC report related to a Security Operations Center?

No. The acronym collides with an unrelated term, and the collision causes real confusion in sales conversations. A SOC report is an audit deliverable: System and Organization Controls, an AICPA attestation framework. A SOC in the operational sense is a Security Operations Center, the team and tooling that monitor for and respond to threats.

A company can run a 24/7 Security Operations Center and hold no SOC report, or hold a SOC 2 report and outsource all monitoring. When a customer asks about your SOC, confirm which one they mean before answering.

What is the difference between a Type 1 and a Type 2 report?

A Type 1 report attests that controls are suitably designed as of a single date. A Type 2 report attests that controls are suitably designed and operated effectively over an observation period, typically 3 to 12 months. Type 1 answers do the right controls exist; Type 2 answers have they been running. The distinction applies to both SOC 1 and SOC 2.

Type 2 carries more weight, and customer security reviews increasingly expect it. But Type 1 is often the right first move, for reasons that show up consistently in first-audit engagements:

The evidence bar for Type 1 is lower than teams assume. Because Type 1 evaluates design, the auditor confirms controls through policy and process documentation rather than months of operating evidence. In one first-audit engagement, the auditor's operational evidence requests came down to three items: quarterly vulnerability scan results, a risk assessment that explicitly included fraud scenarios (five to fifteen risk items is a typical range), and, with some flexibility, access reviews. Everything else was evaluated through the design of the documented controls. Teams commonly over-prepare because nobody tells them this.

Type 1 lets you fix issues before they become findings. When a Type 1 auditor identifies a problem, the company can remediate it, and once the auditor is satisfied, the issue does not appear in the report; the report is dated to the point when the auditor has confidence in all controls. Type 2 offers no such flexibility. A control that failed or lacked evidence during the observation period becomes a permanent finding, because the auditor is opining on a window of time that cannot be re-run.

Type 1 produces a report customers can see now. A Type 1 gives sales teams an auditor-validated document to hand to prospects while the Type 2 observation period runs, and the controls the Type 1 auditor validated become the baseline the Type 2 measures against.

For Type 2, evidence discipline becomes the whole game. Each recurring control needs three things: proof it is configured, proof it ran throughout the period, and proof findings were handled. A screenshot of a configured scanner without execution history, or scan logs without a remediation trail, gets returned by the auditor as incomplete.

What is SSAE 18, and what does attestation mean?

SSAE 18 (Statement on Standards for Attestation Engagements No. 18) is the AICPA standard that governs how CPA firms perform attestation engagements, including SOC audits. It took effect in 2017, replacing SSAE 16, which is why older vendor documentation still references SSAE 16 reports.

Attestation means a licensed practitioner examines an assertion made by management and issues a formal opinion on it. In a SOC 2 engagement, management asserts that its system description is accurate and its controls meet the Trust Services Criteria; the CPA firm tests that assertion and issues an opinion (unqualified when everything holds, qualified when exceptions are material). The deliverable is the report itself, containing the opinion, the management assertion, the system description, and, in SOC 1 and SOC 2, the controls tested and the results.

This is why a SOC report is an attestation rather than a certification. There is no certificate, no pass/fail stamp, and no accreditation body issuing a credential. ISO 27001 works differently: an accredited certification body issues a certificate against the standard. A SOC report is an auditor's professional opinion that readers evaluate for themselves, which is why customers ask to read the full report rather than accept a logo on a website.

Who needs a SOC report?

Any company that runs systems or processes on behalf of other businesses can be asked for one, and the ask usually arrives through the sales pipeline rather than from a regulator. Common triggers:

• A SaaS company selling to mid-market or enterprise buyers. Procurement and vendor risk teams request a SOC 2 as a standard step, and deals stall until it exists.
• A service provider whose processing affects customer financials. Payroll processors, billing platforms, fund administrators, and claims processors get asked for SOC 1 by their customers' finance teams and auditors.
• Hosting, managed services, and data center operators. Customers inherit these providers' controls and need the report to satisfy their own audits.
• Subprocessors of a company pursuing its own SOC 2. Vendor management controls push the requirement down the supply chain.

No law mandates a SOC report. The mandate is commercial: a security questionnaire, an MSA clause, or a procurement gate that will not clear without one. That is also what makes the report a revenue instrument rather than a compliance formality; companies that treat it that way scope it around what their customers ask for instead of what a template suggests.

How long does a SOC report take?

From a standing start, a first SOC 2 Type 1 commonly lands in two to four months, and a first Type 2 in six to twelve months, since the Type 2 opinion requires an observation period (three months at minimum, twelve for a mature report) plus fieldwork after the window closes. Readiness work, closing control gaps, and choosing an auditor drive the variation. The SOC 2 timeline and cost walkthrough breaks the sequence down step by step.

Budget expectations belong in the same conversation. Audit fees for a SOC 2 typically run in the low-to-mid five figures depending on scope, criteria beyond security, and firm; readiness support, tooling, and internal time are separate line items. The four factors that move the number are covered in the SOC 2 cost breakdown.

When is a SOC report the wrong ask?

A SOC report is sometimes requested by reflex when something else would serve better, cheaper, or faster. Three situations worth catching:

The requester means a Security Operations Center. RFPs written from templates sometimes ask do you have a SOC meaning 24/7 monitoring. Delivering an audit report answers a question nobody asked. Clarify before scoping anything.

A SOC 3 or a completed questionnaire would satisfy the customer. Early-stage prospects doing light diligence often need directional assurance, which a published SOC 3, a completed SIG or CAIQ questionnaire, or a security overview page can provide without an NDA workflow. Reserve the full SOC 2 exchange for buyers who require it.

The customer base is outside North America. ISO 27001 certification travels better in European and Asian markets, where buyers know the standard and may not recognize a SOC 2. Companies selling into both markets often need both eventually, but the first framework should follow the revenue. The comparison of ISO 27001 vs SOC 2 and which to pursue first maps that decision.

Where a SOC report fits in a security program

The report is the output; the security program is the asset. An effective program is built from roughly 19 security capabilities (access control, vulnerability management, risk management, incident response, vendor management, and the rest), and a SOC 2 audit is an examination of whether those capabilities exist and run. Companies that build the capabilities first find the audit evidence already exists as a byproduct: the access reviews, scan results, and risk assessments the auditor samples are the same artifacts the program produces in normal operation.

Done in that order, the deals that were waiting on the report close, and the next audit cycle starts from evidence that already exists.

Frequently Asked Questions

Is a SOC report the same as a certification?

No. A SOC report is an attestation: a CPA firm examines management's assertion about its controls and issues a professional opinion under SSAE 18. There is no certificate or accreditation body. ISO 27001, by contrast, is a certification issued by an accredited certification body against the standard.

What is SSAE 18?

SSAE 18 (Statement on Standards for Attestation Engagements No. 18) is the AICPA standard governing attestation engagements, including SOC 1 and SOC 2 audits. Effective since 2017, it replaced SSAE 16. When a vendor references an SSAE 18 audit, they mean a SOC engagement performed under this standard.

How much does a SOC report cost?

Audit fees for a SOC 2 typically fall in the low-to-mid five figures, varying with scope, Trust Services Criteria included, and the CPA firm. Readiness work, compliance tooling, and internal effort add to the total. SOC 1 pricing behaves similarly; SOC 3 is usually a low-cost add-on to a SOC 2 Type 2.

How long is a SOC report valid?

A SOC report never formally expires, but the market convention is 12 months. A Type 2 covers its observation period, and customers generally expect a report whose period ended within the past year. Companies on an annual audit cycle bridge the gap between reports with a short letter when asked.

What is the difference between SOC 1 and SOC 2?

SOC 1 covers controls relevant to customers' internal control over financial reporting and is read by finance teams and their auditors. SOC 2 covers controls against the Trust Services Criteria, starting with security, and is read by customer security and vendor risk teams. Many companies only ever need SOC 2.

Can a SOC report be shared publicly?

SOC 1 and SOC 2 reports are restricted-use documents, normally shared with customers and prospects under NDA because they contain system and control detail. SOC 3 exists for public distribution: it carries the auditor's opinion without test results, so companies can post it on their website.