A SAS 70 report was the Statement on Auditing Standards No. 70 audit that service organizations used from 1992 through 2011 to show clients their internal controls had been examined by an independent CPA firm. It was officially replaced on June 15, 2011, by Statement on Standards for Attestation Engagements No. 16 (SSAE 16), which created the System and Organization Controls (SOC) report framework still in use today.1Journal of Accountancy. Replacing SAS 70 If a vendor hands you something labeled a SAS 70 report in 2026, that standard has been retired for more than a decade, and no auditor or regulator will accept it. You should be asking for a SOC 1 or SOC 2 report instead.
What SAS 70 Was
SAS 70 had a narrow lens. It focused almost exclusively on controls at a service organization that were relevant to a client’s financial reporting. One report, one purpose: give the client’s financial statement auditors something to lean on when the client had outsourced a function that touched the books, such as payroll, loan servicing, or benefits administration.1Journal of Accountancy. Replacing SAS 70
That single-report model worked in the 1990s. It stopped working as organizations began outsourcing complex technology functions. Cloud hosting, data analytics, identity management — a financial-reporting-only audit couldn’t address the security and operational risks that mattered most to the people reviewing a vendor. SAS 70 also placed no formal accountability on service organization management for what went into the report. Management didn’t have to assert anything.
What Replaced SAS 70
The AICPA split the old single-report model into distinct report types. SSAE 16 created SOC 1 as the direct successor to SAS 70’s financial reporting focus, and the AICPA introduced SOC 2 and SOC 3 reports alongside it to cover the broader security, availability, and privacy concerns SAS 70 never addressed.2ISACA. Understanding the New SOC Reports
SSAE 16 also added something SAS 70 lacked: service organization management now has to 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. That shifted accountability onto the organization being audited rather than leaving everything on the auditor.
The standards have moved forward twice since then. SSAE 18 superseded SSAE 16 for reports dated on or after May 1, 2017, adding two practical requirements: a formal risk assessment process, and a vendor management program covering any subservice organizations whose controls affect the services being delivered. SSAE 21 then took effect for reports dated on or after June 15, 2022. It applies to SOC 2 engagements; SOC 1 engagements continue under SSAE 18. The impact of SSAE 21 on SOC 2 reports is minimal — mostly terminology updates to align with international standards.
From a user’s perspective, the current state is simple. Service organizations issue SOC 1 reports under SSAE 18 and SOC 2 reports under SSAE 21. Both are the modern descendants of what SAS 70 used to do, split into two tracks that match what clients actually need to evaluate.
SOC 1 or SOC 2: Which One You Should Ask For
The decision between requesting a SOC 1 or a SOC 2 from a vendor comes down to what the vendor does for you.
A SOC 1 examines controls at a service organization that are relevant to a client’s internal control over financial reporting (ICFR). 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’s controls over invoice generation and revenue recognition would be in scope; its physical security practices or disaster recovery plans would not, unless they directly affected financial data integrity.
SOC 1 reports are restricted to the service organization’s management, the user entity, and the user entity’s auditors. 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, which requires an assessment of internal controls over financial reporting for public companies.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.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
A SOC 2 evaluates operational and security controls based on the AICPA’s Trust Services Criteria. This is the right report for 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. Mandatory for every SOC 2 engagement; it serves as the baseline the other criteria build on.
- Availability: whether systems are operational and accessible as committed. Typically included by hosting companies and disaster recovery providers.
- 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. Relevant when the vendor handles trade secrets, intellectual property, or other restricted data.
- Privacy: how personal information is collected, used, retained, and disclosed. Important when the vendor processes data subject to privacy regulations.
The service organization chooses which of the four optional criteria to include alongside the mandatory Security criterion. A cloud infrastructure provider typically audits against all five. A narrowly focused data analytics firm might only include Security and Confidentiality. Check the scope section of any SOC 2 you receive to confirm what was actually tested.
Some vendors need both. A benefits administration platform that processes payroll deductions and stores employee health records 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.
SOC 2 reports are also restricted-use. The related SOC 3 report exists for public distribution. It contains the auditor’s opinion and management’s assertion but omits the detailed system description and test results, which makes it suitable for a vendor to post on a website or share with prospects.2ISACA. Understanding the New SOC Reports If a vendor’s marketing page references a SOC 3, that is the condensed, public-facing version of their SOC 2.
Type 1 or Type 2: What to Accept
Both SOC 1 and SOC 2 reports come in two varieties, and the difference matters.
A Type 1 report evaluates whether controls are suitably designed and implemented as of a single date. The auditor 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 a Type 1 would not catch it.
A Type 2 report covers operating effectiveness over a period, typically three to twelve months. The auditor samples transactions, reviews logs, and confirms that controls functioned as described throughout the window. 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 examinations commonly start at three months and extend to twelve in subsequent years.
For any vendor you rely on for ongoing operations, a Type 2 is what you want. Accept a Type 1 only as an interim measure from a vendor that is new to the SOC process and has committed to delivering a Type 2 within a defined timeframe.
How to Read the Report When You Get It
The auditor’s opinion is the section that matters most. Read it first.
- Unqualified (clean) opinion: the auditor found the system description to be fairly presented and the controls to be suitably designed and, for Type 2 reports, operating effectively. No material exceptions.
- Qualified opinion: the auditor found misstatements or control failures that are material but not pervasive. Something went wrong without undermining the entire control environment. Read the exceptions section carefully to understand the specific issues.
- Adverse opinion: the auditor found problems that are both material and pervasive. The controls fundamentally failed. Treat this as a serious finding that should trigger a risk reassessment of the vendor relationship.
- Disclaimer of opinion: the auditor could not obtain enough evidence to form a conclusion. This usually signals scope limitations. Treat it with the same caution as an adverse opinion.
A qualified opinion does not automatically mean dropping the vendor. It means digging into the specific exceptions, understanding whether they affect your operations, and confirming the vendor has a remediation plan. An unqualified opinion is not a blank check either, because the report assumes you are performing your share of the controls.
Complementary User Entity Controls
Every SOC report includes a section listing Complementary User Entity Controls (CUECs) — controls the service organization assumes you have in place on your end. The two sets work together. If you are not performing your half, the assurance the report provides is incomplete, even if the service organization received a clean opinion.
Common CUECs include restricting access credentials to authorized personnel, reviewing user access lists periodically, maintaining your own backup procedures, and promptly notifying the service organization of terminated employees. Routine on paper, often ignored in practice. Your internal audit or compliance team should map every listed CUEC to an active control within your organization and escalate anything that is not being performed.
Subservice Organizations
Most service organizations rely on other vendors downstream. A payroll processor might use a cloud hosting provider; a data center might use a third-party security monitoring firm. These are called subservice organizations, and the SOC report will handle them in one of two ways.
Under the carve-out method, the subservice organization’s controls are excluded from the SOC report’s scope. The report describes what services the subservice organization provides but does not test their controls. This is the more common approach because it is simpler and cheaper. The tradeoff is that you need to independently assess the subservice organization, often by requesting its own SOC report. Under SSAE 18, a service organization using the carve-out method must describe its monitoring controls over the subservice organization, so check whether those monitoring controls look robust.
Under the inclusive method, the subservice organization’s controls are included in the scope and tested alongside the primary service organization’s. This gives broader assurance in a single document but requires cooperation from the subservice organization and costs more.
Bridge Letters
A SOC report covers a specific observation period. If that period ends before your fiscal year ends, you have a gap. A bridge letter (sometimes called a gap letter) addresses it. The letter is a written representation from the service organization’s management, not the auditor, stating that there have been no material changes to the control environment since the SOC report’s coverage period ended. It is on the service organization’s letterhead and signed by management.
A bridge letter does not carry the same weight as an audited SOC report, but it provides some comfort for the gap period. The practical limit is about 90 days. Beyond that, most user entity auditors will not consider the bridge letter reliable enough to rely on. If the gap exceeds three months, you may need to ask the service organization to adjust its audit period or perform your own testing of the vendor’s controls.
Red Flags
Only a licensed CPA firm can perform a SOC examination and sign the report. This is a requirement of the AICPA attestation standards under which SOC engagements are conducted. If a vendor presents a “SOC report” issued by a non-CPA firm or a consulting company, it is not a real SOC report regardless of what it looks like.
And if a vendor hands you a SAS 70 report today, treat it the same way. The standard was retired in 2011. A current SAS 70 is either a very old report the vendor never replaced, or a document the vendor is mislabeling. Ask for the current SOC 1 or SOC 2 report that matches the service they provide, and confirm it was issued by a CPA firm within the past twelve months with a bridge letter covering any gap through your reporting date.