A SAS 70 report was an auditor’s examination of the internal controls at a service organization, issued under Statement on Auditing Standards No. 70 and used from 1992 through 2011 by clients (and their auditors) to gain assurance over controls at outsourced providers like payroll processors, data centers, and loan servicers. The standard was retired on June 15, 2011, and replaced by Statement on Standards for Attestation Engagements No. 16 (SSAE 16), which introduced the System and Organization Controls reporting framework — the SOC 1, SOC 2, and SOC 3 reports vendors issue today.1Journal of Accountancy. Replacing SAS 70 If a vendor hands you something labeled a SAS 70 in 2026, it isn’t a current report. The standard has been dead for over a decade, and no auditor or regulator will accept it.
Why SAS 70 Was Retired
SAS 70 had a narrow lens. It focused almost exclusively on controls relevant to a user entity’s financial reporting. That single-report model fit the 1990s, when the typical outsourced service was a payroll bureau or a transaction processor whose work flowed directly into the client’s ledger. As organizations began outsourcing more complex technology functions — cloud hosting, data analytics, identity management — a financial-reporting-only audit could not address the security and operational risks that had come to matter most to clients.1Journal of Accountancy. Replacing SAS 70
The AICPA’s response was to split the old single-report model into distinct report types keyed to what the client actually needed assurance over. SSAE 16 created the SOC 1 report as the direct successor to SAS 70’s financial-reporting focus. Alongside it, the AICPA introduced SOC 2 and SOC 3 reports to cover the broader security, availability, and privacy concerns SAS 70 never addressed.2ISACA. Understanding the New SOC Reports
SSAE 16 also introduced a requirement conspicuously absent from SAS 70: service organization management must provide a written assertion about the fairness of the system description and the design (and, for Type 2 reports, the operating effectiveness) of the controls. Under SAS 70, management had no formal accountability for what went into the report. The assertion changed that.
The Standards That Replaced SAS 70
Three attestation standards have governed service organization reporting since SAS 70 was retired. Each built on the last.
SSAE 16 took effect for reports covering periods ending on or after June 15, 2011. It created SOC 1 and added the management assertion described above.
SSAE 18 superseded SSAE 16 for reports dated on or after May 1, 2017. It added two practical requirements: service organizations must implement a formal risk assessment process, and they must maintain a vendor management program covering any subservice organizations whose controls affect the services they deliver. Those changes forced service organizations to think systematically about risk rather than simply documenting whatever controls happened to exist. SSAE 18 remains the governing standard for SOC 1 engagements.
SSAE 21 took effect for reports dated on or after June 15, 2022, and applies to SOC 2 engagements. Its practical impact on how a SOC 2 looks or reads is minimal. It primarily updated terminology and clarified concepts to align with international standards rather than changing what auditors test or how reports are structured.
From a user’s perspective, the shift from SAS 70 to today’s framework matters less because of these version numbers and more because of what the AICPA split apart: financial-reporting controls now live in a SOC 1, and everything else lives in a SOC 2.
What to Ask for Instead: SOC 1 or SOC 2
The decision comes down to what the vendor does for you.
SOC 1
A SOC 1 report examines controls at a service organization that are relevant to a client’s internal control over financial reporting. Payroll processors, billing services, loan servicers, benefits administrators — any vendor whose work feeds directly into your financial statements.2ISACA. Understanding the New SOC Reports
The scope is intentionally narrow. A SOC 1 only tests controls that could materially affect the user entity’s financial statements. A third-party billing processor would have its controls over invoice generation and revenue recognition tested; its physical security practices or disaster recovery plans wouldn’t be in scope unless they directly affected financial data integrity.
SOC 1 reports are restricted-use documents. Only the service organization’s management, the user entity, and the user entity’s auditors can receive them. That restriction exists because the report’s value lies in how it integrates with the user entity’s own financial statement audit. User entity auditors rely on it to satisfy their obligations under PCAOB standards and Section 404(b) of the Sarbanes-Oxley Act.3Public Company Accounting Oversight Board. AS 2201 – An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements SOC 1 examinations are performed under AT-C section 320, the attestation standard the AICPA established specifically for service organization engagements related to financial reporting controls.4Association of International Certified Professional Accountants. Reporting on an Examination of Controls at a Service Organization Relevant to User Entities Internal Control Over Financial Reporting
If your legacy reason for holding a SAS 70 was financial statement audit support, SOC 1 is your direct replacement.
SOC 2
SOC 2 reports evaluate operational and security controls against the AICPA’s Trust Services Criteria. This is the report type most relevant to cloud providers, SaaS platforms, data centers, managed IT services, and any vendor handling sensitive data outside the financial reporting context.5Association of International Certified Professional Accountants. 2017 Trust Services Criteria (With Revised Points of Focus – 2022)
The Trust Services Criteria include five categories:
- Security — protection against unauthorized access, both physical and logical. This criterion is mandatory for every SOC 2 engagement and serves as the baseline the other criteria build on.
- Availability — whether systems are operational and accessible as committed. A hosting company or disaster recovery provider would typically include this.
- Processing Integrity — whether system processing is complete, accurate, and timely. Relevant for transaction processors and data analytics firms.
- Confidentiality — protection of information designated as confidential, such as trade secrets or intellectual property.
- Privacy — how personal information is collected, used, retained, and disclosed.
The service organization picks which of the four optional criteria to include alongside the mandatory Security criterion. A cloud infrastructure provider often audits against all five. A narrowly focused analytics firm might include only Security and Confidentiality. The selection should reflect the risks that actually matter to the client relationship.
SOC 2 reports are also restricted-use. The related SOC 3 exists for situations where a service organization wants to share assurance publicly: it contains the auditor’s opinion and management’s assertion but omits the detailed system description and test results, making it suitable for a website or a sales conversation.2ISACA. Understanding the New SOC Reports If a vendor’s marketing page references a SOC 3, that’s the condensed, public-facing version of their SOC 2.
Some Vendors Need Both
A benefits administration platform that processes payroll deductions (affecting your financial statements) and stores employee health records (a privacy and security concern) may warrant a SOC 1 for the financial controls and a SOC 2 for the data security controls. Don’t assume one report covers everything. Check the scope section to confirm what’s actually being tested.
Type 1 vs. Type 2
Both SOC 1 and SOC 2 reports come in two varieties, and the difference is one of the most commonly misunderstood aspects of the framework.
A Type 1 report evaluates whether controls are suitably designed and implemented as of a single date. The auditor looks at the control environment at one point in time and confirms the controls exist on paper and appear capable of achieving their objectives. What a Type 1 does not tell you is whether those controls actually worked consistently. A company could have beautifully designed controls that nobody follows, and the Type 1 wouldn’t catch it.
A Type 2 report covers operating effectiveness over a period, typically ranging from three to twelve months. The auditor performs detailed testing throughout that window, sampling transactions, reviewing logs, and confirming that controls functioned as described day after day. The AICPA does not mandate a specific minimum observation period, but in practice most auditors treat three months as the shortest credible window. First-time SOC examinations commonly start with a three-month period and extend to twelve months in subsequent years.
For any vendor relationship that touches your financial reporting or handles sensitive data on an ongoing basis, a Type 2 is what you want. Type 1 reports have their place, often as a stepping stone for organizations undergoing their first SOC examination, but they provide a limited snapshot rather than evidence that controls work reliably over time. Experienced auditors at user entities typically won’t accept a Type 1 as a long-term substitute.
If a Vendor Hands You a SAS 70 Today
Push back. SAS 70 has not been the applicable standard since June 15, 2011. A document labeled as a SAS 70 report is either mislabeled — some vendors continued using the name informally for a period after the transition — or genuinely stale, in which case it reflects an audit performed under a retired standard and carries no current assurance value.
Ask the vendor for their most recent SOC 1 or SOC 2 report, whichever fits the services they provide to you. Confirm two things when it arrives. First, that the report was issued by a licensed CPA firm — only a licensed CPA firm can perform a SOC examination and sign the report, and a document from a non-CPA consulting company is not a real SOC report regardless of what it looks like. Second, that the coverage period is current enough to support your reliance on the vendor for the period you care about. If the vendor cannot produce a current SOC report, that itself is information about the control environment you’re relying on.