SSAE No. 18 is the AICPA attestation standard that governs how auditors examine and report on an organization's controls, and SOC 2 is the report issued under that standard. SOC 2 evaluates controls across security, availability, processing integrity, confidentiality, and privacy. A Type I report confirms those controls are designed properly at a single point in time, while a Type II report confirms they actually worked over time, which is why most customers ask for Type II.
TL;DR:
- Security is mandatory, while Availability, Processing Integrity, Confidentiality, and Privacy depend on scope; assign each selected criterion to a named control owner before auditing.
- Type II testing commonly covers 12 months, and the signed report arrives weeks after the period closes; Type I checks design on one date.
- Check for carved out subservice vendors, verify their separate attestation, and review complementary user entity controls to identify responsibilities outside the report.
- Refresh evidence quarterly and automate recurring log or backup collection, but readiness tools cannot replace effective controls or an independent auditor’s testing.
Table of Contents
- What SSAE 18 and SOC 2 actually are
- Trust Services Criteria: what each one actually tests
- SOC 1 vs SOC 2 vs SOC 3, and Type I vs Type II
- The SOC 2 audit process and a realistic timeline
- Scope decisions that change what a SOC 2 report actually covers
- Practical readiness: where automation actually helps
- Why SOC 2 works best as an ongoing habit, not a yearly scramble
- A faster path to SOC 2 readiness and questionnaire response
- FAQ
- Sources
What SSAE 18 and SOC 2 actually are
SSAE No. 18 sits inside the AICPA's attestation standards, organized under the AT-C sections, and it defines the rules an independent auditor must follow when examining and reporting on a company's controls. SOC 2 is the specific report that results from applying those rules to nonfinancial controls, as confirmed in Microsoft's compliance documentation, which notes that a SOC 2 Type 2 attestation is performed under SSAE No. 18 and the Trust Services Criteria.
Customers, procurement teams, and partners ask for SOC 2 because it gives them independent evidence that a vendor's controls hold up, without requiring them to run their own audit. In SaaS and cloud environments, a current SOC 2 report has become a baseline expectation before a deal moves forward.
A few things to keep straight about scope and purpose:
- SSAE 18 is the governing standard; SOC 2 is the report produced under it.
- SOC 2 covers operational and security controls, not financial statement controls.
- Buyers typically request the report, read the auditor's opinion, and review any noted exceptions before relying on it.
We cover this relationship in more depth in our piece on SOC 2 and SSAE 18 for teams that want the full history.
Trust Services Criteria: what each one actually tests
SOC 2 is built around five Trust Services Criteria, and an organization chooses which ones apply to its engagement based on what its service actually promises customers. Security is mandatory; the other four are optional depending on scope.
- Security: access controls, authentication, and monitoring that prevent unauthorized use; auditors often check multi-factor authentication logs and access review records.
- Availability: uptime commitments backed by backup and disaster recovery testing; auditors look for documented recovery time objectives and recent test results.
- Processing integrity: data processed completely, accurately, and on time; auditors request validation rules and reconciliation logs.
- Confidentiality: protection of sensitive data through encryption and classification; auditors ask for data handling policies and encryption key management records.
- Privacy: how personal data is collected, used, retained, and disclosed; auditors review notice and consent language and retention schedules.
Most organizations start with Security and Availability, then add Confidentiality or Privacy once a customer contract specifically requires it.
Pro Tip: Map each criterion to a named control owner before the audit starts, so evidence requests go to the right person on day one.
SOC 1 vs SOC 2 vs SOC 3, and Type I vs Type II
The three SOC report types answer different questions, and mixing them up is one of the most common mistakes compliance teams make when responding to a customer request.
- SOC 1 examines controls relevant to a client's financial reporting, used mainly by payroll processors, payment platforms, and similar financial-adjacent services.
- SOC 2 examines controls against the Trust Services Criteria and is the report most technology buyers request.
- SOC 3 is a public-facing summary of a SOC 2 report, written for general distribution without the detailed testing narrative.
Within SOC 2, Type I confirms controls are designed correctly as of one date, while Type II confirms those controls operated effectively across an audit period, commonly a rolling 12-month window, as described in Microsoft's SOC 2 Type 2 overview. Most enterprise buyers prefer Type II because a point-in-time snapshot does not prove consistency. Our comparison of SOC 1, SOC 2, and SOC 3 goes deeper into when each report fits.
The SOC 2 audit process and a realistic timeline
The path to a finished SOC 2 report runs through several distinct phases, each with its own owner. Scoping determines which Trust Services Criteria apply and who inside the organization is accountable for each control. Readiness assessment, often led by an internal compliance lead or an outside consultant, identifies gaps before the formal audit begins. Remediation closes those gaps, and then the independent auditor performs the actual testing, culminating in a signed report.
For Type II specifically, the audit period itself typically runs for several months, and the final report is usually delivered a few weeks after the period closes. Auditors will request:
- Access logs and authentication records tied to specific control claims.
- Change management tickets showing who approved and deployed production changes.
- Written policies covering incident response, data retention, and vendor management.
Pro Tip: Freeze major configuration changes to logging retention or alert thresholds during the audit period. A mid-period change can make an otherwise effective control look inconsistent.
Our guide on choosing SOC 2 auditors walks through what to expect from the firm you hire.
Scope decisions that change what a SOC 2 report actually covers
A subservice organization is any third-party vendor whose own controls support the service being audited, such as a cloud hosting provider or a background check vendor. The audited organization has to decide whether to include that vendor's controls directly in the report, called the inclusive method, or exclude them and rely on the vendor's own separate report, called the carve-out method.
When a report uses the carve-out method, it will list complementary user entity controls, meaning actions the customer or the audited organization itself must perform for the overall control environment to work as described. A reader who skips this section can walk away thinking a control is fully covered when it actually depends on something happening outside the report's boundary.
- Check whether subservice organizations are included or carved out before relying on a stated control.
- Read the complementary user entity controls section line by line, since it defines your own responsibilities.
- A carve-out report is not weaker, but it does require you to verify the subservice provider's own attestation separately.
Practical readiness: where automation actually helps
Most of the friction in SOC 2 preparation comes from gathering and repeating evidence, not from designing the controls themselves. Automation tools help by centralizing evidence collection, mapping stored documentation to specific Trust Services Criteria, and generating consistent answers when the same control gets asked about across multiple customer questionnaires.
- Centralizing policies, prior audit answers, and control evidence in one searchable knowledge base cuts the time spent hunting through old emails and shared drives.
- Integrations with ticketing systems, cloud platforms, and document stores (Confluence, Notion, Google Drive, SharePoint) shorten the evidence-gathering cycle because logs and records stay current automatically rather than being manually exported each time.
- Automation accelerates readiness and keeps answers consistent, but it does not replace the auditor's independent testing or the underlying work of designing effective controls.
Pro Tip: Treat your questionnaire answer library as living documentation. Every time an auditor or customer asks a new question, add the answer back into the knowledge base so the next request takes minutes instead of days.
Why SOC 2 works best as an ongoing habit, not a yearly scramble
We think the biggest misconception about SOC 2 is treating it as a once-a-year project instead of a continuous operating discipline. Controls that only get attention the month before an audit tend to show gaps precisely where auditors look hardest: access reviews, change logs, and incident records.
A better rhythm is simple. Schedule a quarterly evidence refresh so nothing goes stale between audits. Automate the evidence pulls that repeat every cycle, like access logs or backup confirmations. And revisit your scope regularly, since customer expectations shift as your product and market change, and last year's Trust Services Criteria selection may no longer match what buyers are asking for.
— Gaspard
A faster path to SOC 2 readiness and questionnaire response
Getting SOC 2 ready involves a lot of repetitive work: pulling the same evidence, answering variations of the same question, and keeping documentation current across every customer request that lands in your inbox. We built our Questionnaire Automation Tool to take that repetition off your team's plate, using proprietary AI models to pull accurate answers from your existing knowledge base rather than starting from a blank document every time.
- The platform maps stored evidence and prior answers directly to the control areas customers ask about, so responses stay consistent across teams.
- Integrations with third-party risk management platforms, plus tools like Slack, Microsoft Teams, and ServiceNow, help keep evidence current without manual re-entry.
- Our Trust Center gives customers a self-serve place to find your SOC 2 report and related documentation, cutting down one-off requests.
If your team handles detailed due-diligence questionnaires alongside SOC 2 evidence requests, our Fiduciary-Grade DDQ Automation is built for that heavier format. For teams planning a broader SaaS rollout around audit season, SzopaLabs's SaaS deployment checklist is a useful planning reference. When you are ready to see how automation fits into your own readiness cycle, visit Skypher to get started.
FAQ
What is SSAE SOC 2?
SSAE SOC 2 refers to a SOC 2 report issued under the AICPA's SSAE No. 18 attestation standard. The standard sets the rules auditors follow, while SOC 2 is the resulting report covering security, availability, processing integrity, confidentiality, and privacy controls.
What is the difference between SOC 1, SOC 2, and SSAE 18?
SOC 1 covers controls relevant to financial reporting, while SOC 2 covers the Trust Services Criteria, and both are issued under the SSAE 18 attestation standard. SSAE 18 is the governing framework, and SOC 1 and SOC 2 are two different reports produced within that framework for different purposes.
What is a SOC 2 Type 2 standard?
A SOC 2 Type 2 report tests whether an organization's controls were not just designed properly but actually operated effectively over a defined period, typically examined under SSAE No. 18. This distinguishes it from Type I, which only confirms design at a single point in time.
What is the difference between SSAE 16 and SOC 2 Type 2?
SSAE 16 was an earlier attestation standard that has since been replaced by SSAE No. 18, which is the current standard referenced in SOC 2 reports. SOC 2 Type 2 is the report itself, now issued under SSAE 18 rather than the older SSAE 16 framework.
How does SOC 2 relate to frameworks like ISO 27001 or HIPAA?
SOC 2 and other common frameworks or standards often overlap in the controls they require, so many organizations map evidence once and reuse it across multiple compliance obligations. None of these frameworks replace the others, since each serves a different audience and regulatory purpose.