SSAE 18, or Statement on Standards for Attestation Engagements No. 18, is the AICPA professional standard that governs how CPAs examine and report on controls at service organizations. It took effect on May 1, 2017, replacing the older SSAE 16, and remains the current attestation framework as of 2026.1AICPA & CIMA. AICPA SSAEs – Currently Effective When a vendor hands you a SOC report, that report is the deliverable from an SSAE 18 engagement: a CPA firm tested the vendor’s controls and documented what it found. When your customers or regulators ask you to produce one, they want independent proof that your controls work.
What SSAE 18 Requires
SSAE 18 did more than rename its predecessor. It introduced obligations that service organizations still stumble over. Two matter most.
Every service organization undergoing a SOC examination now needs a formal risk assessment process, documented and updated at least annually. And the standard requires organizations to identify and manage their subservice providers, meaning the third parties your vendor relies on to deliver its services. Before SSAE 18, many service organizations treated their own vendors as invisible. The standard forced that dependency into the open.
SSAE 18 also broadened what can be examined. Engagements can now cover compliance with specific laws, regulations, or contractual arrangements, which brought organizations into the SOC ecosystem that previously fell outside it.
The SOC Reports SSAE 18 Produces
SSAE 18 governs several distinct SOC engagements, each aimed at a different audience and a different set of controls. Picking the wrong report type is one of the most common mistakes organizations make, usually because someone on the sales team heard “we need a SOC” without specifying which one.
SOC 1: Financial Reporting Controls
A SOC 1 report examines controls at a service organization that are relevant to user entities’ internal control over financial reporting.2AICPA & CIMA. SOC 1 – SOC for Service Organizations: ICFR The audience is financial statement auditors. If your company outsources payroll, loan servicing, or claims administration, the auditor signing off on your financials needs to know the vendor’s systems won’t introduce errors into your books.
A SOC 1 tells you nothing about cybersecurity posture, data privacy, or uptime. Requesting one when you actually need assurance about data security wastes everyone’s time.
SOC 2: Trust Services Criteria
A SOC 2 report examines controls against one or more of five Trust Services Criteria set by the AICPA: Security, Availability, Processing Integrity, Confidentiality, and Privacy.3AICPA & CIMA. 2017 Trust Services Criteria (With Revised Points of Focus – 2022) Security is included in every SOC 2. The service organization selects additional criteria based on the services it provides. A cloud hosting company typically includes Availability; a data analytics firm handling personal records adds Confidentiality and Privacy.
SOC 2 is the report most organizations are asked for when customers want evidence that their data is protected. It is a restricted-use report, meaning it can only be shared with the service organization, user entities, and their auditors. You cannot post a SOC 2 on your website or hand it to just anyone who asks.
SOC 3: General-Use Report
A SOC 3 report covers the same Trust Services Criteria as a SOC 2 but strips out the detailed control descriptions and test results. Because it omits that operational detail, the AICPA classifies it as a general-use report that can be freely distributed.4AICPA & CIMA. SOC 3 – SOC for Service Organizations Organizations use SOC 3 reports for marketing.
A SOC 3 is not a substitute for a SOC 2 in vendor due diligence. If a vendor offers you a SOC 3 when you asked for a SOC 2, press on it. The SOC 3 confirms the auditor’s conclusion but gives you none of the detail you need to evaluate whether the controls cover the risks you care about.
SOC for Cybersecurity
The AICPA also developed a SOC for Cybersecurity engagement, which examines an organization’s enterprise-wide cybersecurity risk management program.5AICPA & CIMA. SOC for Cybersecurity The distinction from SOC 2 matters. A SOC 2 examines controls within a service organization’s system as they relate to the services provided to customers. A SOC for Cybersecurity examines the entity’s overall program for managing cybersecurity risk across the entire organization.6Department of Labor (DOL) – EBSA. Comparison of SOC 1, SOC 2, and SOC for Cybersecurity Examinations The intended audience is broader, including boards, investors, analysts, and business partners rather than only user entities and their auditors.
Type 1 Versus Type 2
Both SOC 1 and SOC 2 engagements come in two flavors, and the difference between them is the single most important factor in how much weight you should give the report.
A Type 1 report evaluates whether controls are suitably designed as of a single date. The auditor looks at the control environment on, say, March 31 and determines whether the controls as designed could reasonably achieve their objectives. Think of it as checking the blueprints. The controls look right on paper, but nobody has verified they work day after day. Type 1 reports are common for organizations going through their first SOC engagement, because the organization hasn’t yet accumulated enough operating history for a Type 2.
A Type 2 report tests both the design and the operating effectiveness of controls over a period of time, typically six to twelve months. The auditor samples transactions, inspects logs, and confirms that controls actually functioned throughout the review period. A control that’s beautifully designed but bypassed every Friday afternoon will show up as an exception in a Type 2.
If a vendor offers you a Type 1 when a Type 2 exists, ask why. If a Type 2 report covers fewer than six months, scrutinize the sample sizes. A three-month window gives the auditor a small population to test, which weakens the conclusions. Most mature vendor risk programs require a Type 2 with at least a six-month review period.
How to Read a SOC Report
SOC reports follow a standardized structure. Knowing where to look saves you from reading 150 pages when only 20 of them matter to your risk assessment.
Management’s Assertion
The report opens with a statement from the service organization’s management. Management represents that the system description is accurate, the controls were suitably designed, and, for a Type 2, the controls operated effectively throughout the review period. This section establishes accountability.
The Auditor’s Opinion
The auditor’s opinion drives every downstream decision. It falls into one of three categories:
- Unqualified (clean) opinion: Controls were suitably designed and, for Type 2, operated effectively. No material issues. This is what you want to see.
- Qualified opinion: The auditor found significant issues, but they weren’t pervasive enough to undermine the entire control environment. Read the details carefully. The specific failures may or may not affect the services you receive.
- Adverse opinion: Controls were materially ineffective or the system description was not fairly presented. This is a serious finding that should trigger an immediate reassessment of the vendor relationship.
An adverse opinion is rare precisely because it’s devastating. Most service organizations that anticipate serious findings will delay their audit and remediate rather than receive one.
System Description
The Description of the Service Organization’s System details what services are provided, the infrastructure and software involved, the people and processes supporting those services, and the control objectives or Trust Services Criteria in scope. Your first job as a reader is to confirm that this description matches the services you’re buying. If your vendor runs your payment processing but the SOC report only covers their data hosting environment, the report doesn’t cover your risk.
Tests of Operating Effectiveness
For Type 2 reports, the auditor lists each control activity, describes the test performed, identifies the population and sample size, and reports the results, including any exceptions. An exception is a specific instance where a control didn’t work as designed. A single exception in a sample of 200 transactions might be acceptable; five exceptions in a sample of 25 is a different story. Always correlate exceptions back to the auditor’s overall opinion to gauge severity.
Complementary User Entity Controls
Buried within the system description is a section many organizations skim past and shouldn’t: the Complementary User Entity Controls, or CUECs, sometimes called User Control Considerations. These are the controls you, the customer, must implement for the vendor’s controls to function as intended. The vendor’s clean opinion assumes you’re holding up your end.
Common examples include:
- Disabling employee access to the vendor’s platform when someone leaves your organization. The vendor has no way to know someone quit on Friday.
- Formally approving changes a managed service provider makes to your environment before implementation.
- Using industry-standard encryption when transmitting sensitive data to the vendor rather than relying on the vendor to secure the transmission.
- Keeping your own antivirus definitions and security patches current, unless your contract specifically shifts that to the vendor.
- Maintaining your own contingency plan. The vendor’s disaster recovery plan covers their operations, not yours.
Failing to implement CUECs can completely undermine the assurance a clean SOC report provides. If the auditor’s opinion is predicated on you reviewing access logs monthly and you never do, the gap is yours, not the vendor’s. Every CUEC should be assigned to an internal owner with documented evidence of compliance.
Subservice Organizations
Most service organizations rely on their own vendors: cloud infrastructure providers, payment processors, data center operators. SSAE 18 requires disclosure of those relationships, but the level of detail depends on the reporting method chosen.
Under the carve-out method, the subservice organization’s controls are excluded from the SOC report’s scope. The service organization acknowledges the dependency and describes how it monitors the subservice provider, typically by reviewing that provider’s own SOC report and conducting periodic assessments. To get complete assurance over the full service chain, you’ll need to obtain the subservice organization’s SOC report separately.
Under the inclusive method, the subservice organization’s controls are included in the service organization’s SOC report and tested by the auditor as part of the same engagement. This gives you a single comprehensive report but requires significantly more coordination between the two organizations.
The carve-out method is far more common, which means you’ll often receive a SOC report that explicitly carves out the cloud provider hosting the data you care about. When you see a carve-out, request the subservice organization’s SOC report and verify it covers the relevant controls.
Bridge Letters Between Audit Periods
A SOC report is generally considered current for 12 months from its issuance date. Audit timelines don’t always align with your fiscal year-end or your risk review schedule, which creates gaps. If a vendor’s SOC 2 covers January through December and your fiscal year ends in March, you have a three-month gap with no assurance.
The common solution is a bridge letter, sometimes called a gap letter. Management represents that no material changes have occurred to the control environment since the SOC report period ended. The bridge letter is not an AICPA-mandated document. It’s an industry practice, and there’s no formal standard governing its content or format, though most include a statement about whether material control changes occurred, a reminder about CUECs, and a disclaimer that the letter doesn’t replace the actual SOC report. Bridge letters typically cover no more than three months.
A bridge letter is better than nothing, but it’s management’s word, not an auditor’s tested opinion. If a vendor can only offer a bridge letter covering six or more months, that’s a gap too large to rely on a management assertion alone. Push for an updated SOC report or conduct your own supplemental assessment.
Cost and Timeline for the Service Organization
Organizations pursuing their first SOC report are often surprised by the total investment, which goes well beyond the auditor’s invoice. Expect three cost layers: preparation, the audit, and ongoing tooling.
A readiness assessment, where a CPA firm or consultant evaluates your current controls against the applicable criteria and identifies gaps, typically runs from $5,000 to $25,000 depending on size and complexity. Remediation follows, and the cost varies based on how many gaps exist. Organizations that have never formalized their controls may need security monitoring tools, identity management platforms, and documented policies, which can add tens of thousands of dollars.
The audit fee itself ranges from roughly $12,000 to $20,000 for small and midsize organizations for a SOC 2 Type 2 engagement, scaling to $30,000 to $100,000 or more for large or complex environments. Type 2 engagements cost 30 to 50 percent more than Type 1 because of the longer observation period and more extensive testing. First-year total costs, including audit fees, readiness work, tooling, and internal staff time, can range from $25,000 for a small startup to more than $200,000 for a large enterprise.
Internal labor is the cost most organizations underestimate. Security, IT, finance, and legal staff typically spend 10 to 30 percent of their time on the engagement during peak phases. Year-two costs drop significantly because the heavy lifting of documenting controls and closing gaps is behind you, but SOC compliance is not a one-time project. Expect an annual Type 2 engagement to maintain current assurance.
From the decision to pursue a SOC report to holding the final document, the process takes six to twelve months for a Type 2 engagement. Readiness assessment runs four to sixteen weeks. Gap remediation runs another four to sixteen weeks and is the most variable phase. The Type 2 observation period runs three to twelve months, with most organizations choosing a six- or twelve-month window. Report generation takes two to six weeks after the observation period closes.