SSAE 18, formally the Statement on Standards for Attestation Engagements No. 18, is the professional standard that governs how CPAs examine and report on controls at service organizations. The AICPA issued it to replace SSAE 16, and it has been effective since May 1, 2017.1AICPA & CIMA. AICPA SSAEs – Currently Effective The deliverable that comes out of an SSAE 18 engagement is a Service Organization Control (SOC) report. If a vendor hands you one, a CPA firm tested that vendor’s controls and documented what it found. If a customer or regulator is asking you to produce one, they want independent proof that your controls actually work.
What SSAE 18 Requires of Service Organizations
SSAE 18 did more than rename its predecessor. Two requirements still trip organizations up years into the standard.
First, every service organization undergoing a SOC examination must have a formal risk assessment process, documented and updated at least annually. Second, the organization has to identify and manage its subservice providers, meaning the third parties the vendor itself relies on to deliver services to you. Before SSAE 18, many service organizations treated their own vendors as invisible. The standard forced that dependency into the open.
The standard also broadened the scope of what can be examined beyond traditional financial controls. Engagements can cover compliance with specific laws, regulations, or contractual arrangements, which opened SOC reporting to organizations that previously sat outside the ecosystem.
The SOC Report Types SSAE 18 Governs
SSAE 18 supports several distinct SOC engagements, each aimed at a different audience and a different set of controls. Choosing the wrong report type is one of the most common mistakes organizations make, usually because someone heard “we need a SOC” without specifying which one.
SOC 1: Financial Reporting Controls
A SOC 1 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 processing, 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 the vendor’s cybersecurity posture, data privacy practices, or system uptime. Requesting one when you actually need assurance about data security wastes everyone’s time.
SOC 2: Trust Services Criteria
A SOC 2 examines controls relevant to one or more of the five Trust Services Criteria established 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 what it does. A cloud hosting company typically includes Availability; a data analytics firm handling personal records usually 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 anyone who asks.
SOC 3: General-Use Report
A SOC 3 covers the same Trust Services Criteria as a SOC 2 but strips out the detailed control descriptions and test results. Because it omits that sensitive 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 3s for marketing, posting them on websites or including them in sales materials.
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 actually 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 audience is broader too: boards, investors, analysts, and business partners rather than just user entities and their auditors.
Type 1 Versus Type 2
Both SOC 1 and SOC 2 come in two flavors, and the difference is the single most important factor in how much weight you should give a report.
A Type 1 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 no one has verified they work day after day. Type 1 reports are common for first-time engagements, because the organization has not yet accumulated enough operating history for a Type 2.
A Type 2 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 were not just designed well but actually functioned throughout the review period. This is where the real assurance lives. A control that is 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 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 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. Management is putting its name on the line, not just the auditor.
Independent Service Auditor’s Report
This section drives every downstream decision. The auditor’s opinion falls into one of three categories.
An unqualified, or clean, opinion means controls were suitably designed and (for Type 2) operated effectively, with no material issues. This is what you want to see. A qualified opinion means the auditor found significant issues that were not pervasive enough to undermine the entire control environment; read the details carefully, because the specific failures may or may not affect the services you receive. An adverse opinion means controls were materially ineffective or the system description was not fairly presented, and should trigger an immediate reassessment of the vendor relationship.
Adverse opinions are rare precisely because they are devastating. Most organizations that anticipate serious findings delay the audit and remediate rather than receive one. If you encounter an adverse opinion, the vendor either did not know how bad things were or could not fix them in time. Neither explanation is reassuring.
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 this description matches the services you are actually buying. If your vendor runs your payment processing but the SOC report only covers their data hosting environment, the report does not cover your risk.
Tests of Operating Effectiveness (Type 2 Only)
For Type 2 reports, the auditor lists each control activity, describes the test performed, identifies the population and sample size, and reports results including any exceptions. An exception is a specific instance where a control did not 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 in the system description is a section many organizations skim and shouldn’t: 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 are holding up your end.
Common examples include disabling access when an employee leaves your organization, formally approving changes a managed service provider makes to your environment, encrypting sensitive data in transit to the vendor, keeping your own antivirus definitions and security patches current, and maintaining your own contingency plan rather than relying on the vendor’s disaster recovery for your operations.
Failing to implement CUECs can completely undermine the assurance a clean SOC report provides. If the auditor’s opinion depends on you reviewing access logs monthly and you never do, the vendor’s controls have a gap, and it is your fault, not theirs. Every CUEC should be assigned to an internal owner with documented evidence of compliance.
How Subservice Organizations Appear in the Report
Most service organizations rely on their own vendors: cloud infrastructure providers, payment processors, data center operators. SSAE 18 requires the service organization to disclose these 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. The practical effect is that you will need to obtain and review the subservice organization’s SOC report separately to have complete assurance over the full service chain.
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 providers.
The carve-out method is far more common. You will often receive a SOC report that explicitly carves out the cloud provider hosting the data you care about. When you see a carve-out, your next step is to request the subservice organization’s SOC report and verify it covers the relevant controls.
Keeping Assurance Current Between Reports
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. It is a letter from the service organization’s management representing 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 is an industry practice. There is 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 does not replace the actual SOC report. Bridge letters typically cover no more than three months.
A bridge letter is better than nothing, but it is management’s word, not an auditor’s tested opinion. If a vendor can only offer a bridge letter covering six or more months, that gap is too large to rely on a management assertion alone. Push for an updated SOC report or conduct your own supplemental assessment.
If You’re Pursuing a SOC Report Yourself
Organizations going through their first SOC engagement are often surprised by what it costs and how long it takes.
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 wildly based on how many gaps exist. Organizations that have never formalized their controls may need to invest in 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, 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 over $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, but SOC compliance is not a one-time project. You will pay for an annual Type 2 every year to maintain current assurance.
The end-to-end timeline for a Type 2 runs six to twelve months. Readiness assessments take four to sixteen weeks depending on organization size. Gap remediation takes another four to sixteen weeks and is the most variable phase; mature control environments move quickly, while organizations lacking basic security controls can spend months here. The Type 2 observation period itself runs three to twelve months, with six or twelve months being typical. Report generation takes two to six weeks after the observation period closes, as the auditor compiles findings, drafts the report, and shares it with management for review before issuing the final version.