SOC 2 — published by the AICPA (American Institute of Certified Public Accountants) and formally established in 2011 — functions simultaneously as a control framework, an audit process, and a final report issued by a licensed CPA firm. This guide covers what SOC 2 actually is, how the five Trust Services Criteria work, the Type I vs. Type II distinction, who needs it, and how the audit process runs from first gap assessment to final report.
Key Takeaways
- Legally voluntary, SOC 2 is commercially required in most enterprise and government vendor relationships
- Security (Common Criteria) is the only mandatory criterion — the other four Trust Service Categories are optional
- Only licensed CPA firms can conduct SOC 2 audits and issue valid reports
- Type II is the standard most enterprise buyers and government agencies expect
- SOC 2 Security controls overlap directly with ISO 27001 and NIST 800-171
What Is SOC 2 Compliance?
SOC 2 stands for System and Organization Controls 2 — a cybersecurity attestation framework developed by the AICPA. The "System and Organization Controls" suite name was introduced in 2017, though the underlying guidance dates to 2011. The governing technical standard is SSAE No. 18, covering attestation engagements under AT-C Sections 105 and 205.
The framework produces a report, not a certificate. A SOC 2 report means an independent, licensed CPA has examined your organization's controls against the Trust Services Criteria and can attest to their design (Type I) or operating effectiveness (Type II). That distinction matters: Type I confirms the controls exist; Type II confirms they worked over time.
Why "Voluntary" Rarely Means Optional
No federal law mandates SOC 2 the way HIPAA mandates health data protections. In practice, though, enterprise procurement teams, government technology buyers, and vendor security questionnaires routinely require a current SOC 2 report as a precondition for doing business. Maryland's state IT contracts, for instance, explicitly require an annual SOC 2 Type II report covering the previous 12-month contract period from applicable contractors.
Who SOC 2 Is Designed For
SOC 2 applies primarily to U.S.-based service organizations whose systems touch customer data:
- SaaS vendors and cloud service providers
- Managed IT and managed security service providers (MSSPs)
- Data analytics, HR, and payroll processing firms
- Any organization that stores, processes, or transmits customer data on behalf of clients
The Five SOC 2 Trust Services Criteria
Every SOC 2 audit is evaluated against the Trust Services Criteria (TSC). Security is mandatory in every report. The remaining four criteria are selected based on the organization's services, data types, and customer requirements.
Security (Common Criteria)
Security evaluates whether information and systems are protected against unauthorized access, unauthorized disclosure, and damage that could compromise other objectives. It covers:
- Access management and logical controls
- Endpoint security and firewall configuration
- Risk assessments and security awareness training
- Incident response procedures
Every SOC 2 report includes Security. Auditors typically examine Security controls first before evaluating any optional criteria.
Availability
Availability evaluates whether systems are operational and accessible as agreed upon. Most relevant for cloud infrastructure providers and uptime-dependent services. Controls in scope include:
- Disaster recovery planning and failover procedures
- Service-level agreement (SLA) monitoring
- Capacity planning and performance thresholds
- Backup and recovery procedures
Processing Integrity
Processing Integrity verifies that system processing is complete, valid, accurate, timely, and authorized. Most relevant for financial services and data processing organizations. Controls in scope include:
- Data input and output validation
- Error detection and exception handling
- Quality assurance checkpoints
- Authorization controls for processing workflows
Confidentiality
Confidentiality evaluates whether information designated as confidential is protected throughout its lifecycle — covering customer data, contracts, and intellectual property. Controls in scope include:
- Data classification policies and access tiering
- Encryption at rest and in transit
- Secure disposal and data destruction procedures
- Confidentiality agreements and third-party controls
Privacy
Privacy focuses specifically on personally identifiable information (PII) and protected health information (PHI) — how it is collected, used, retained, disclosed, and disposed of. It overlaps with HIPAA, GDPR, and CCPA requirements and uniquely requires controls around breach notification and disclosure.
SOC 2 Type I vs. Type II: Which Report Do You Need?
| Type I | Type II | |
|---|---|---|
| What it evaluates | Control design at a point in time | Control design + operating effectiveness over a period |
| Question it answers | Are the right controls in place? | Did the controls work consistently? |
| Evidence period | None — single date only | Covers the full review period |
| Typical review period | N/A | 6–12 months (12 months most common in practice) |
| Assurance level | Lower | Higher |
Type I: A Starting Point, Not the Destination
A Type I report establishes that your controls are designed appropriately as of a specific date. It confirms the controls exist — not that they held up. Organizations new to SOC 2 or under short timelines sometimes pursue Type I.
The problem: many enterprise buyers are rejecting Type I reports outright. If your sales pipeline includes large commercial customers or government agencies, a Type I may not clear their vendor security review.
Type II: The Standard That Sticks
A Type II report evaluates both design and operating effectiveness over a defined review period. According to RSM's SOC reporting guidance, reports typically cover 12 months, with reports delivered 45–60 days after the period closes.
For most organizations, going straight to Type II is the right move. Even a shorter initial observation window beats spending time and budget on a Type I report that enterprise procurement teams will reject anyway.
Audit Outcomes
Every SOC 2 audit results in one of four opinions:
- Unmodified — controls met the criteria (the passing outcome)
- Qualified — controls mostly met criteria, but specific concerns were noted
- Adverse — controls did not meet the criteria
- Disclaimer of Opinion — insufficient evidence to form a conclusion
Every organization receives a report regardless of outcome.
Who Needs SOC 2 Compliance?
SOC 2 is built for service organizations whose customers need independent assurance over how their data is handled. The common categories:
- SaaS vendors whose enterprise customers want proof of data security controls
- Cloud service providers subject to uptime, availability, and security requirements
- MSSPs and IT service providers managing customer systems and sensitive data
- Data analytics and HR/payroll processors handling confidential or regulated data
Two categories on that list deserve closer attention for regulated-industry readers.
Defense Contractors and the DIB
Defense industrial base (DIB) companies pursuing CMMC certification sometimes assume SOC 2 isn't relevant to them — that's often incorrect. Enterprise and government technology buyers increasingly require SOC 2 Type II reports from their SaaS vendors and service providers as a parallel security signal alongside CMMC. A DoD prime contractor procuring a cloud-based project management or HR platform from a software vendor will often require that vendor to hold a current SOC 2 report.
CISA's vendor supply chain risk management template explicitly asks about third-party assessments such as SOC 2 Type II — though CISA notes the template is non-prescriptive. Security-conscious buyers treat SOC 2 as a qualification filter, regardless of whether it's mandated.
The Commercial Reality
SOC 2 is not a regulatory mandate. But the absence of a current report when a customer requests one effectively blocks contract renewals, stalls enterprise sales cycles, and disqualifies vendors from procurement decisions. That enforcement mechanism — buyer demand — is often more immediate than any regulatory deadline.
How SOC 2 Compliance Works: From Gap Assessment to Audit Report
Phase 1: Pre-Audit Readiness
Before engaging an external auditor, organizations need to:
- Scope the applicable Trust Services Criteria — determine which of the five categories apply to your services and customer commitments
- Document existing controls — catalogue what's already in place against the TSC requirements
- Identify and close gaps — implement controls that don't yet exist or don't meet the criteria
- Conduct a readiness assessment — validate that controls are in place and evidence is being collected before the auditor arrives
This pre-audit work doesn't produce a SOC 2 report. It produces the control documentation, evidence inventory, and operational records the auditor will actually test against.
Phase 2: The External Audit
Only a licensed CPA firm can conduct a SOC 2 audit and issue the report. Consultants, software vendors, and internal teams cannot issue a valid SOC 2 report regardless of their cybersecurity expertise.
During the audit, the CPA firm:
- Reviews the system description and management's assertion
- Collects evidence through documentation review, walkthroughs, and inquiry
- Tests operating effectiveness across the full observation period (for Type II)
- Evaluates exceptions and prepares the final restricted-use report
For Type II audits, evidence must cover the entire review period — not just the final weeks before the report closes.
Phase 3: Ongoing Compliance
That report isn't the finish line — it's the baseline for the next audit cycle.
SOC 2 is not a one-time event. Annual Type II audits require organizations to maintain continuous control operation throughout the year. Controls that lapse mid-period show up as exceptions in the next report.
Defense contractors running SOC 2 alongside CMMC or ISO 27001 face an additional layer of complexity: overlapping evidence requirements across frameworks. QMS Learning's Defense Cybersecurity Readiness pathway (covering CMMC, NIST 800-171, ISO 27001, and SOC 2) addresses exactly that — with a pilot cohort opening Q3 2026.
How SOC 2 Relates to ISO 27001, CMMC, and Other Frameworks
SOC 2 vs. ISO 27001
Both frameworks address information security controls and share significant control overlap. The AICPA publishes a formal mapping between the 2017 Trust Services Criteria and ISO 27001 requirements, enabling organizations to reuse control work across both.
Key differences:
- SOC 2 is a CPA-issued attestation report, primarily used by U.S.-based service organizations
- ISO 27001 is an internationally recognized certification issued by an accredited ISO certification body
Organizations pursuing both simultaneously can map overlapping controls and reduce total implementation effort. The frameworks are complementary, not redundant.
SOC 2 vs. SOC 1 and SOC 3
These aren't competing frameworks — they're parallel options within the AICPA's SOC suite:
- SOC 1 addresses controls relevant to user entities' internal control over financial reporting (ICFR) — used primarily by financial services companies
- SOC 2 addresses controls relevant to the Trust Services Criteria — security, availability, processing integrity, confidentiality, and privacy
- SOC 3 is a general-use summary of a SOC 2 examination — less detailed and publicly shareable, covering the same five categories
SOC 2 and CMMC/NIST 800-171
CMMC governs the DoD supply chain. SOC 2 governs customer data security attestation for service organizations. They are not interchangeable and satisfy different audiences.
Controls in NIST SP 800-171 and SOC 2 Security criteria do cover overlapping territory, including:
- Access control and identity management
- Incident response procedures
- Audit logging and monitoring
- Risk assessment practices
Organizations working through NIST 800-171 control families for CMMC readiness will find that evidence developed for one framework often supports the other — though no official DoD or NIST mapping guarantees that evidence from one satisfies the other.
Frequently Asked Questions
What are the 5 criteria for SOC 2?
The five Trust Services Criteria are: Security (Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory criterion included in every SOC 2 report. The remaining four are optional and selected based on the organization's services and customer requirements.
Is SOC 2 the same as ISO 27001?
No. Both address information security controls and share significant overlap, but SOC 2 is a U.S.-based CPA-issued attestation report while ISO 27001 is an internationally recognized certification issued by an accredited ISO body. Many organizations pursue both due to shared control requirements.
Is SOC 2 compliance mandatory?
SOC 2 is not legally mandated the way HIPAA or GDPR are. However, it is functionally required in many enterprise and government commercial relationships — customers and partners frequently require a current SOC 2 Type II report as a precondition for doing business.
What is SOC 2 compliance in the US?
SOC 2 is the primary cybersecurity attestation standard for U.S. service organizations, published by the AICPA and issued exclusively by licensed CPA firms. Unlike ISO 27001 — which is internationally recognized — SOC 2 is a distinctly American framework rooted in U.S. public accounting standards.
What is the difference between SOC 2 Type I and Type II?
Type I evaluates whether controls are designed appropriately at a single point in time. Type II evaluates both design and operating effectiveness over a defined review period — typically 12 months. Type II is the standard most enterprise and government customers require.
Who can perform a SOC 2 audit?
Only licensed CPA firms or individual Certified Public Accountants authorized to perform attestation engagements can conduct SOC 2 audits and issue SOC 2 reports. Consultants, software vendors, and internal teams cannot issue a valid SOC 2 report.
