- SSAE 18 is the AICPA auditing standard that governs how SOC 1 and SOC 2 reports are produced and what service organizations must demonstrate to pass enterprise vendor reviews
- It introduced three requirements compliance teams still navigate today: formal vendor management programs, mandatory annual risk assessments, and subservice organization disclosures across all SOC engagements
- Both Type I (point-in-time design) and Type II (sustained operating effectiveness over six to twelve months) reports are issued under SSAE 18.
- Genuine SSAE 18 readiness requires moving from annual audit preparation to continuous compliance, with automated evidence collection, vendor oversight workflows, and cross-team accountability built into daily operations
Enterprise buyers no longer accept a policy document or a checkbox audit from eighteen months ago as proof of trust. If you handle client data, process transactions, or provide outsourced services, you are increasingly measured against a more demanding question: not just whether controls exist, but whether they operated consistently and whether you can prove it.
According to Verizon's 2025 Data Breach Investigations Report, the share of breaches involving a third party doubled in a single year, reaching 30%.
This article is for compliance managers, GRC leads, infosec leaders, and founders navigating SOC 2 vendor reviews, whether you are producing your first report or evaluating a vendor's. SSAE 18, published by the AICPA in 2016, is the standard that formalized how service organizations are held accountable for those relationships. It is also the foundation on which every SOC 2 report your customers request is built. You may also hear about SSAE 21 and SSAE 22. Those are later amendments, and this article addresses them, but SSAE 18 is still the core standard your auditor follows.
What is SSAE 18?
SSAE 18, or the Statement on Standards for Attestation Engagements No. 18, is the auditing standard the American Institute of Certified Public Accountants (AICPA) published in April 2016, with most provisions effective May 1, 2017. It governs how independent CPAs examine and report on a service organization's controls, and it replaced SSAE 16.
The standard is issued by the AICPA's Auditing Standards Board (ASB), the body responsible for attestation standards in the United States. If your customers are asking for SOC 2 reports, SSAE 18 is the standard the audit is conducted under.
SSAE 18 did not arrive without precedent. It replaced SSAE 16, which had itself superseded SAS 70, consolidating a fragmented set of prior attestation standards into one clarified framework.
Evolution of AICPA attestation standards
| Standard | Published | Effective date | What it did |
|---|---|---|---|
| SAS 70 | April 1992 | 1992 | Introduced service auditor examinations for financial reporting controls |
| SSAE 16 | April 2010 | June 15, 2011 | Replaced SAS 70, aligned with international standard ISAE 3402, and introduced SOC 1 reports |
| SSAE 18 | April 2016 | May 1, 2017 | Consolidated prior attestation standards, formalized vendor oversight and risk assessment requirements |
| SSAE 21 / SSAE 22 | Later amendments | — | Delta amendments to SSAE 18, including focus-area updates. SSAE 18 remains the baseline standard |
Here is a point that trips up first-timers: you do not need to track SSAE 21 separately. The PDFs for SSAE 18, 21, and 22 all exist, but the main standard is SSAE 18 with delta changes layered on top. Your auditor follows the current version. You focus on your controls and continuous compliance.
Under SSAE 18, both SOC 1 and SOC 2 reports are issued. SOC 1 addresses controls over financial reporting; SOC 2 evaluates controls relevant to security, availability, processing integrity, confidentiality, and privacy. The standard provides the rules of engagement auditors follow for either report type, so findings are consistent and comparable across organizations.
What changed from SSAE 16 to SSAE 18
SSAE 18 was not a cosmetic update. Several operational changes distinguished it from its predecessor in ways compliance teams still feel today.
- Service organizations were required to maintain a formal third-party vendor management program: documented, scoped, and backed by traceable evidence.
- An annual risk assessment became mandatory, not merely encouraged, with a recurring, documented process reviewable by auditors.
- Subservice organization disclosures, previously required only in SOC 2 reports, became mandatory across all SOC engagements.
- The Management Assertion Letter had to be signed, and its language was modified. Top management now states in writing, on company letterhead, that they follow what SSAE 18 requires for the described system, then hands that signed letter to the audit firm before the engagement proceeds.
- The definition of Complementary User Entity Controls (CUECs) was narrowed to include only the controls a user organization must implement to meet management’s stated objectives.
SSAE 18 also expanded what attestation engagements could cover, moving beyond financial controls to include compliance with laws, contractual arrangements, and agreed-upon procedures.
SSAE 16 vs. SSAE 18 requirements comparison
| Requirement | SSAE 16 | SSAE 18 |
|---|---|---|
| Third-party vendor management | Informal or discretionary | Formal program required |
| Risk assessment | Encouraged | Annual, documented, reportable |
| Subservice org disclosures | SOC 2 only | All SOC reports |
| Engagement scope | Primarily financial | Expanded to compliance, contractual, and agreed-upon procedures |
| Operating expectation | Largely point-in-time | Ongoing oversight expected |
| Management Assertion Letter | Required | Signed, with modified language |
| CUEC definition | Broader | Narrowed to controls needed for management's objectives |
What is an SSAE 18 report?
An SSAE 18 report is any attestation report produced by an independent CPA firm under the SSAE 18 standard. In practice, that means a SOC 1, SOC 2, or SOC 3. Enterprise buyers most often request a SOC 2 Type II because it proves sustained control performance, which is what their own vendor risk programs require.
Within SOC 1 and SOC 2 engagements, two report structures exist:
- Type I evaluates whether controls are suitably designed at a specific point in time.
- Type II assesses whether those controls operated effectively over a defined review period, typically six to twelve months.
Enterprise buyers almost always request Type II because it reflects sustained control performance, not a point-in-time snapshot.
A closer look at SOC 3. A SOC 3 is best understood as SOC 2 “lite.” Where a SOC 2 report can run 50 to 80 pages for a SaaS company and names specifics (the exact firewall, the antivirus product, the cloud provider), a SOC 3 states only that those controls exist in general terms. That makes it safe to publish. You can put a SOC 3 on your website or send it to a prospect you have not signed an NDA with.
One catch: you cannot get a SOC 3 on its own. It is derived from a SOC 2 Type II. If you only hold a SOC 2 Type I, or if your SOC 2 Type II carries a qualification, a SOC 3 cannot be issued.
There are also SOC 2+ variants, combining the SOC 2 criteria with an additional framework such as HIPAA or HITRUST. These are common in healthcare and fintech, where a buyer wants one report covering both information security and a sector-specific obligation. Audit firms holding both a CPA license and HITRUST Authorized External Assessor status can issue the combined report in a single engagement.
SOC report comparison by focus and target audience
| Report | Focus | Who requests it |
|---|---|---|
| SOC 1 | Financial reporting controls | Financial auditors, enterprise finance teams |
| SOC 2 | Security and operational controls | Security teams, procurement, enterprise buyers |
| SOC 3 | Public assurance summary | General public, website visitors |
| SOC 2+ | SOC 2 criteria plus a framework (HIPAA, HITRUST) | Healthcare and fintech buyers with sector obligations |
Is SSAE 18 the same as SOC 2?
No. SSAE 18 is the auditing standard. SOC 2 is a report produced under that standard. SSAE 18 tells auditors how to conduct the engagement; SOC 2 tells stakeholders whether your security controls hold up. The same relationship applies across the SOC family: SSAE 18 is the rulebook, and SOC 1, SOC 2, and SOC 3 are the outputs.
The relationship mirrors GAAP and a financial statement: one is the rulebook, the other is the output. The standard itself is lengthy. Reading it is your auditor’s job, not yours.
Most SaaS companies pursuing SOC 2 are already operating within the SSAE 18 ecosystem, whether they use that language or not. When a customer asks for your SOC 2, they are asking for a report produced under SSAE 18.
SSAE 18 vs. SOC 2 distinction
| SSAE 18 | SOC 2 | |
|---|---|---|
| What it is | Auditing standard | Report type |
| Set by | AICPA | AICPA |
| Purpose | Governs how audits are conducted | Communicates control effectiveness to stakeholders |
| Who uses it | Auditors | Buyers, procurement teams, enterprise customers |
| Output | Framework and guidance | Type I or Type II report |
Key SSAE 18 requirements modern companies cannot ignore
Enterprise buyers now ask pointed questions during procurement: who has access to their data, how vendors are monitored, and what happens between audits. The requirements below are what give your answers teeth.
1. Vendor oversight and subservice organization management
Under SSAE 18, vendor oversight is a documented, auditable obligation, not a procurement formality. Service organizations must maintain an updated inventory of subservice organizations, including cloud infrastructure providers, identity providers, payroll processors, ticketing systems, and development platforms.
You must also choose a disclosure method for each vendor. The carve-out method excludes a subservice organization’s controls from your report scope, so the auditor does not test them. The inclusive method folds those controls into your scope, so they are tested alongside yours. The choice directly affects your audit scope and the evidence you are responsible for producing.
Document Complementary Subservice Organization Controls (CSOCs) as well. These define how a subservice organization’s controls interact with your own.
Review vendor SOC reports throughout the year, not only at onboarding. A tool that was never inventoried and a vendor whose certification lapses mid-period are the same problem: an undisclosed gap in your report.
Carve-out vs. inclusive disclosure methods in SOC 2
| Disclosure method | What the auditor does | What it means for your evidence |
|---|---|---|
| Carve-out | Excludes the subservice org's controls from scope | You disclose the vendor and document CSOCs, but the vendor's controls are not tested in your report |
| Inclusive | Includes and tests the subservice org's controls | Broader scope; you help gather evidence for the vendor's controls as well as your own |
2. Internal controls that operate continuously
In an SSAE 18 audit, a control that existed for ten months but lapsed in the eleventh shows up as an exception in a Type II report. Auditors test consistency across the full review period, not just at assessment time. Controls that must operate without interruption include access management, change management, system monitoring and logging, incident response, and evidence retention.
3. Ongoing evidence collection
Manual screenshots become unreliable at scale. System-generated evidence is more defensible: it is timestamped, consistent, and difficult to reconstruct after the fact. An auditor who senses that evidence was fabricated or backfilled can issue an adverse opinion, the worst possible SOC report outcome.
Auditors increasingly expect specific evidence types: MFA enforcement logs, GitHub branch protection records, AWS configuration monitoring outputs, and HR offboarding and access revocation logs.
A full trail that cannot be edited gives both the auditor and your leadership confidence that controls operated when the record says they did. Even brief gaps create exceptions.
4. Accountability across teams
SSAE 18 reaches further than the compliance team. Engineering, IT, security, HR, procurement, and leadership all own pieces of the control environment. A change management process sits with engineering. Offboarding logs come from HR. MFA enforcement is an IT function. When compliance is treated as a siloed task rather than a cross-organizational discipline, gaps appear exactly where ownership is unclear.
5. The annual risk assessment
SSAE 18 made the risk assessment a standalone, recurring obligation, and auditors check that you actually did it. A good-enough assessment identifies your threats, assigns probability and impact ratings, and covers the full length and breadth of the scoped system. The common failure is scope gaps: a product company documents physical and logical access for its local data center, but forgets to assess the cloud where the product is actually hosted. That omission is a miss the audit firm will catch.
You do not need to over-engineer it. ISO 31000 is a useful, non-certifiable guidance standard: rate risks by probability and impact, calculate a risk value, set a risk appetite, and mitigate anything above your accepted threshold. Overdoing it will not get you penalized. Underdoing it will surface as a finding.
6. A qualified CPA firm
This is the requirement most first-timers never hear about. SOC 1 and SOC 2 are attestation engagements, and an independent CPA cannot sign off on a SOC 2 report on their own.
Attestation engagements must be carried out by AICPA firms enrolled in the peer review program, a recurring quality check a firm must undergo, typically within a three-year cycle.
Selecting a firm that is enrolled and current on its peer review is not optional. It is what makes your report legitimate in the eyes of enterprise buyers. How to evaluate and choose the right firm is covered in the auditor selection section below.
Is SSAE 18 mandatory, and who actually needs it?
Nowhere in U.S. law does a regulation mandate that service organizations undergo SSAE 18 attestation. The mandate comes from somewhere else entirely.
Organizations selling to enterprise buyers, operating in regulated industries, or handling sensitive client data will find SSAE 18 readiness effectively required. Enterprise procurement teams routinely condition vendor approval on a SOC 2 Type II report, and those reports are issued under SSAE 18. For these organizations, an SSAE 18 audit is not optional in any practical sense.
Organizations most commonly in scope include:
- SaaS providers handling customer data
- Cloud service and infrastructure providers
- Fintech and payment processing platforms
- Healthcare vendors and health data processors
- Payroll and HR technology providers
- Managed service providers
- Enterprise technology vendors with B2B sales motions
You likely need SSAE 18 readiness if:
- Enterprise customers are requesting SOC reports as part of vendor approval
- You handle financial transactions, health data, or personal information on behalf of clients
- You operate in a regulated industry or sell into one
- You are scaling toward a Series B raise or an enterprise market segment
- Your deals are stalling at the security review stage
What SSAE 18 means for internal auditors and compliance teams
Before the CPA firm arrives, the internal audit does the work that determines whether the engagement goes smoothly or surfaces surprises. Their job is to make sure the organization’s controls align with SSAE 18 requirements before external attestation begins. The distinction matters: internal audit prepares, the CPA firm attests.
What internal auditors specifically test is broad. They check policy coverage, evidence completeness across the full observation period, cross-functional control ownership gaps, and the logs that show vendor SOC reports were actually reviewed. The scale of external scrutiny they are preparing for is easy to underestimate.
For a single SOC 2 report, an audit firm builds a full stack of work papers, often more than 500 documents, covering control testing matrices, sampling papers, exception logs, and management representation letters. Access control alone (CC 6.1, one of the longest and most heavily weighted criteria) can carry a large share of that testing.
Automation changes what the internal audit actually does. Before GRC platforms, auditors spent the weeks before an assessment reconstructing quarterly access reviews from screen recordings and email threads, then hoping the evidence held up. Now the evidence is already there: timestamped, logged, and uneditable. The internal auditor’s job shifts from evidence chaser to exception monitor, watching for flags as they appear and remediating before the CPA firm ever sees them.
Internal audit vs. external CPA firm roles in SOC 2
| Internal audit | External CPA firm |
|---|---|
| Prepares the organization before the engagement | Attests to control design and effectiveness |
| Tests policy coverage and evidence completeness | Samples evidence and issues the opinion |
| Identifies cross-functional ownership gaps | Builds 500+ work papers and the report |
| Reviews vendor SOC report logs internally | Verifies subservice org disclosures |
| Fixes issues before the audit window closes | Documents exceptions and qualifications |
For teams building this muscle, an internal audit checklist and a working knowledge of audit evidence types make the difference between a smooth compliance audit and a scramble.
How to evaluate a vendor’s SSAE 18 report in 30 minutes

Receiving a vendor’s SOC 2 report and knowing what to look for are two different skills. The seven steps below are sequenced so you can move through a 200-page report in under 30 minutes, spending the most time where the risk is highest.
1. Check the scope and system description. Section III describes the system that the report actually covers. Confirm it includes the products, infrastructure, and locations you rely on. A report that covers a vendor’s data center but not the cloud where your data lives is not covering your risk.
2. Check the audit period. Is the report fresh or stale? If the observation period does not align with your current needs, ask the vendor for a bridge letter, which states that a new audit is underway and a report is coming.
3. Verify the auditor. Identify the service auditor, then check their peer review status on the AICPA peer review website. Confirm they are enrolled and that their most recent review passed.
4. Read the auditor’s opinion, the single most important page in the report. The opinion is unqualified, qualified, adverse, or carries a disclaimer.
5. Distinguish exceptions from qualifications. An exception on one control within a criteria is not the same as a qualification on the full criteria. A single hardening-standards gap under CC 6.1 may be an exception while the rest of the criteria passes. A qualification means the whole criteria failed, and the opinion page will say which one.
6. Review the Complementary User Entity Controls (CUECs). These are the controls the vendor expects you to implement on your side. If a vendor relies on AWS IAM, for example, you are responsible for configuring named users, no generic accounts, and MFA. Skipping CUECs is where buyers create false confidence.
7. Review the subservice organizations. Are your cloud providers disclosed? Are there gaps between what the vendor claims and what the report scopes?
SOC 2 opinion types and recommended action steps
| Opinion type | What it means | What to do |
|---|---|---|
| Unqualified | Controls were suitably designed and operating effectively | Proceed; review exceptions if any |
| Qualified | One or more full criteria were not satisfied | Investigate the named criteria; assess your exposure |
| Adverse | The auditor believes evidence was fabricated | Do not rely on the report; escalate |
| Disclaimer | The auditor could not reach a conclusion (often missing samples) | Ask why; request clarification or a bridge letter |
For a deeper walkthrough, see our guide to reviewing a vendor's SOC 2 report and how to fold this into ongoing vendor risk management and third-party risk programs.
How to choose a qualified SSAE 18 auditor
There are four broad categories of audit firms, and the differences matter more than the logo. Big 4 firms bring name recognition and deep benches, but high fees. Boutique firms practice like a Big 4 at a smaller scale, with fewer clients and lower turnover. Small CPA firms vary widely in quality; one may be excellent and another weak. Independent auditors cannot sign off on SOC 2 attestation engagements at all because attestation work must be carried out by AICPA firms enrolled in the peer review program.
The most important check is peer review. Go to the firm’s website, confirm the CPA license, and check whether they are enrolled in the AICPA peer review program. If they are enrolled, find out whether the review has happened and whether it passed, failed, or passed conditionally. A reputable firm will share the report either way, along with any areas of concern. If a firm is enrolled but its peer review is overdue, treat that as a signal to investigate before you engage.
Look at the individual auditor too, not just the firm. Ask who will actually run your engagement and whether they understand information security. Credentials like CISA, CISSP, or ISO 27001 lead auditor signal technical competency alongside the CPA license. An auditor who cannot follow your controls is a challenge even when your compliance is sound.
Match firm size to your own. Pricing varies widely across the four categories, and a compliance automation platform typically reduces engagement costs because the firm spends fewer hours in the audit. Our breakdown of the pros and cons of boutique vs. Big 4 and our guide to running a smooth SOC 2 audit go deeper on the tradeoffs.
Auditor selection evaluation checklist and flags
| What to check | Where to check it | Green flag/Red flag |
|---|---|---|
| CPA license | Firm website, state board | Valid and current/Expired or absent |
| Peer review enrollment | AICPA peer review website | Enrolled and current/Not enrolled or overdue |
| Peer review result | Requested from the firm | Pass, shared willingly/Refusal to share |
| Auditor credentials | Ask for the named auditor's profile | CISA/CISSP/ISO 27001 lead auditor/No security background |
| Fit to your size and stack | Reference checks | Works with similar, tech-forward companies/Only enterprise or only tiny clients |
The biggest SSAE 18 challenges for SaaS companies
Meeting SSAE 18 requirements on paper is one thing. Sustaining them operationally across a full audit period is another. These are the challenges compliance leads most commonly encounter.
1. Vendor sprawl
Most SaaS companies accumulate tools faster than they document them. By the time an audit window opens, the vendor inventory is outdated, approvals are informal, and several tools processing client data have never been reviewed. Without a centralized vendor management process, you will not satisfy SSAE 18's oversight requirements. Not because you lack controls, but because you cannot prove they existed.
2. Manual evidence collection at scale
Screenshots and spreadsheets hold up for a Type I report. They break under a twelve-month Type II review period. Logs go missing, evidence gets reconstructed after the fact, and teams spend the weeks before an audit doing work that should have happened continuously. Auditors can detect retroactively reconstructed evidence, and an auditor who suspects fabrication can issue an adverse opinion, the worst outcome a SOC report can carry.
3. Controls drift between audits
Permissions change when someone joins or leaves. Infrastructure evolves with new deployments. Controls in place in January may look different by September. Readiness is not a project; it is a living system, and most compliance programs are not built to treat it that way.
4. Cross-functional ownership gaps
Who owns the MFA enforcement log? When the answer is unclear for that question and a dozen like it, the gaps surface in auditor findings. Engineering pushback, compliance fatigue, and dependency bottlenecks are symptoms of a program without defined ownership.
5. The Type I to Type II gap
A Type I tells you your controls are designed correctly. A Type II tells you they held up for twelve months. Those are not the same problem, and the gap between them is where most compliance programs break. Many organizations pass a Type I easily, then discover that sustaining those controls without drift across a full review period demands a fundamentally different approach.
6. Shadow AI and untracked tooling
An AI tool that quietly processes client data outside your documented environment is, in SSAE 18 terms, an undisclosed subservice organization. Most compliance programs were not built to catch these, and untracked tools are treated by auditors as gaps. As AI adoption accelerates, this is the fastest-growing blind spot in vendor oversight.
7. Cybersecurity exposure during the audit period
Protecting sensitive client data from active attack is part of sustaining SSAE 18 compliance, not separate from it. A breach or misconfiguration inside the observation window becomes an exception in the report and, potentially, an incident your customer discovers first.
The through-line across all seven is that they are solved by moving from periodic scrambling to continuous compliance, where an automation layer flags compliance drift before it becomes a finding.
Benefits of SSAE 18 for modern organizations
Closing those gaps does more than satisfy an auditor. Organizations that operationalize SSAE 18 requirements build a posture that accelerates deals, reduces audit costs, and surfaces problems before they compound.
1. Faster enterprise trust
A clean Type II report answers most vendor questionnaire questions before they are asked. That is not a compliance checkbox. For B2B companies competing on enterprise accounts, it is a sales asset.
2. Better operational visibility
Point-in-time audits give you a verdict. Continuous compliance gives you a dashboard. Issues surface earlier, get resolved before they compound, and rarely reach an auditor as findings.
3. Stronger third-party risk management
SSAE 18’s vendor oversight requirement forces a discipline most programs lack: a live inventory, renewal tracking, and documented CSOC reviews. When a vendor’s SOC report lapses mid-period, you catch it before the auditor does.
4. Cleaner audits
Fewer exceptions. Faster completion. Lower CPA fees. The report reflects how the organization actually operates, not a sprint performance.
5. Multi-framework efficiency
Controls built for SSAE 18 compliance overlap substantially with ISO 27001 and other frameworks, so expanding to a new requirement rarely means starting over. Reusing that shared work is where the overlap between SOC 2 and ISO 27001 turns compliance into leverage rather than duplicated effort.
How modern SaaS companies operationalize SSAE 18 readiness
The gap between knowing what SSAE 18 requires and building a program that delivers it continuously is where most compliance teams struggle. The organizations that close that gap are not doing more auditing. They are doing less scrambling, because readiness is built into daily operations.
From audit preparation to continuous compliance
The shift from annual preparation to continuous compliance is not philosophical. It is architectural. It requires:
- Automated evidence collection mapped to control frameworks, running year-round rather than being activated before audit windows.
- Vendor oversight workflows with renewal tracking and CSOC documentation, so no vendor report lapses without a flag.
- Centralized controls with defined cross-team ownership, so the right person is accountable for the right evidence at all times.
- Audit-ready evidence packaging that does not require reconstruction at assessment time.
The control area that most often drifts between audit cycles is access reviews. Because access changes every time someone joins, moves teams, or leaves, and because the industry expects reviews quarterly, this is where gaps open quietly. Business continuity testing runs a close second. The best umbrellas are bought before it rains. A strong posture means that if a client says they are coming to assess you next week, you are already ready.
Ron Buell, CTO of Sounding Board, described the shift after moving off a consultant-led process:

Automated SOC 2 control monitoring and evidence collection
| Control area | Trigger signal | Evidence collected | Decision |
|---|---|---|---|
| Access management | IAM role change | System logs and review approvals | Approve if MFA is enrolled; escalate if not |
| Change management | Production deployment | Change ticket and peer review log | Approve or flag |
| Vendor oversight | SOC report renewal date | Vendor report and CSOC review | Renew or escalate |
| MFA enforcement | New user provisioned | Enrollment confirmation log | Log as compliant or open a remediation ticket |
| Incident response | Alert triggered | Ticket and resolution log | Close or escalate |
| HR offboarding | Employee termination | Access revocation log | Verify or flag |
This checklist tells you what needs to be true before an SSAE 18 audit begins. Scrut helps you keep it true year-round.
How Scrut helps in SSAE 18
Scrut is an AI-powered GRC platform that maps directly to what SSAE 18 mandates, so readiness is maintained continuously rather than assembled before each audit. It addresses what the standard requires:
- Vendor oversight tracking with renewal reminders and CSOC documentation, addressing SSAE 18’s formal vendor management requirement.
- Annual risk assessment workflows that keep your threat, probability, and impact ratings current and scoped, addressing the mandatory risk assessment obligation.
- Subservice organization disclosure support, so every cloud provider and processor is inventoried and disclosed rather than surfacing as an audit gap.
The result is compliance automation and continuous vendor risk management that produce audit-ready documentation without a reconstruction sprint.
Matt Black, Director of Information Security at Contentstack, put the outcome plainly:

See how Scrut works and get a personalized quote.
SSAE 18 is the attestation standard issued by the AICPA that defines how independent auditors assess and report on a service organization's internal controls. Effective May 1, 2017, it underpins all SOC 1 and SOC 2 reports that enterprise buyers request from their vendors.
No, they serve different functions. SSAE 18 is the standard auditors follow when conducting an engagement. SOC 2 is the report that results from it. One sets the rules; the other documents the outcome.
The full name is Statement on Standards for Attestation Engagements No. 18. It was issued by the AICPA's Auditing Standards Board in April 2016 and became effective on May 1, 2017, consolidating and superseding all prior SSAE standards into a single clarified framework.
No law requires it. However, service organizations selling to enterprise clients, handling sensitive data, or operating in regulated industries will find it commercially unavoidable. Enterprise buyers routinely require SOC 2 Type II reports as a condition of vendor approval, and those reports are conducted under SSAE 18.
SSAE 18 replaced SSAE 16, effective May 1, 2017. It consolidated prior attestation standards into a single framework and introduced stronger requirements around vendor oversight and risk assessment.

Megha Thakkar is a technical content writer with about a decade of experience in cybersecurity and compliance. She writes extensively on SOC 2, ISO 27001, GDPR, and security operations, helping organizations translate complex requirements into clear, audit-ready decisions. Her work, tailored for CISOs and executive leaders, is frequently cited in U.S. government and NIST publications.

Team Scrut is a collective of compliance, security, and risk practitioners sharing practical guidance on building audit-ready, scalable programs. We write about SOC 2, ISO 27001, continuous compliance, third-party risk, cloud security, and GRC automation, blending regulatory depth with operator experience to help fast-growing companies strengthen trust, streamline audits, and stay ahead of evolving security demands.

%20(1).png)























