SOC 2 compliance: Type I and Type II explained

A prospect asks for your SOC 2 report. You send it. They come back with follow-up questions.

That's the reality of SOC 2 compliance for most organizations. The report satisfies the checkbox in a vendor questionnaire, but it rarely ends the conversation on its own. That's not a failure of the framework. It's a sign that most people on both sides of that exchange don't fully understand what SOC 2 actually evaluates, what it proves, and what it doesn't.

This article breaks down what SOC 2 compliance means, how Type I and Type II reports differ, and what it takes to get and stay compliant.

What is SOC 2?

System and Organization Controls (SOC) is a voluntary auditing framework developed by the American Institute of Certified Public Accountants (AICPA) to evaluate how well service providers protect client data. There are three report types:

• SOC 1 focuses on internal controls over financial reporting.
• SOC 2 focuses on controls pertaining to the five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy.
• SOC 3 is a simplified version of SOC 2 intended for a broader audience and can be shared publicly.

SOC 2 is not a certification. It is an attestation report produced by a licensed CPA firm that describes how well your organization's controls meet a defined set of criteria, either at a specific point in time or over a defined period. Whether that report is useful to a customer depends on how it was scoped, which criteria were included, and whether the controls it describes are being enforced.

SOC 2 is scope-specific. Your organization's management defines which systems, services, and teams are in scope and which Trust Services Criteria apply at the outset. All audits must also satisfy the Common Criteria, nine operational and governance requirements that apply regardless of which Trust Services Criteria are selected. The Trust Services Criteria define what you're protecting; the Common Criteria define how your organization operates to protect it.

The five Trust Services Criteria:

• Security: Protecting information from unauthorized access through firewalls, intrusion detection, and multi-factor authentication.
• Confidentiality: Protecting sensitive data by limiting access, storage, and use through encryption and access controls.
• Processing Integrity: Verifying data is complete, valid, and accurate.
• Availability: Ensuring employees and customers can rely on you to house their data, ensure uptime, Service Level Agreements (SLAs), and have plans for disaster recovery and incident handling.
• Privacy: Safeguarding Personally Identifiable Information (PII) from unauthorized access via access controls, encryption, and multi-factor authentication.

The Common Criteria:

• CC1 Control Environment: Clearly defined roles and responsibilities focusing on ethical values and accountability.
• CC2 Communication and Information: Policies on internal and external information and communications.
• CC3 Risk Assessment: Processes on how to identify and manage potential risks.
• CC4 Monitoring Controls: Controls must be continuously evaluated to confirm operational integrity.
• CC5 Control Activities: Policies and procedures that are implemented to mitigate identified risks.
• CC6 Logical and Physical Access: Policies for system, data, and physical access.
• CC7 Systems Operations: Policies on daily operational security, monitoring, system activity, identifying risks, and responding to incidents.
• CC8 Change Management: Processes for approving, testing, and making updates to infrastructure or software.
• CC9 Risk Mitigation: Processes for managing risks associated with third party vendors and business partners.

The difference between SOC 2 Type I and Type II reports

The core difference is what each report proves. Type I evaluates whether your controls are designed correctly at a single point in time. Type II evaluates whether those controls actually worked consistently over an observation period of three to twelve months.

SOC 2 Type I

Type I is the faster path, typically completed in one to three months, and is well-suited for startups, organizations early in their compliance journey, or situations where a deal has a hard deadline. Many organizations pursue Type I first as a deliberate stepping-stone to Type II, using the audit process to identify gaps before committing to the longer observation period.

SOC 2 Type II

Type II carries more weight with enterprise buyers and customers in regulated industries, who often require it as a condition of doing business. The observation period runs three to twelve months, with a total timeline of six to fifteen months from start to final report. Most organizations treat Type II as the target state.

Who needs SOC 2 compliance?

SOC 2 is not legally required, but for many organizations it functions as such in practice. Enterprise buyers, particularly in financial services, healthcare, and regulated industries, routinely require a SOC 2 report as a condition of vendor onboarding. Without it, deals stall or don't start.

Any organization that handles customer data stands to benefit: SaaS providers, cloud service providers, MSPs, and technology vendors are the most common candidates. If your customers are asking for it, that's your answer.

SOC 2 compliance requirements explained

SOC 2 requirements are based on the Trust Services Criteria and designed to help organizations protect customer data. Organizations may implement controls based on their specific environments and business needs, but most audits focus on access control, incident response, and data protection.

Documentation

Auditors will require documented proof, including an assertion from management, that not only are policies in place, but they are followed. Additional information regarding infrastructure, software, processes, and procedures is also needed.

Some policies and documentation that an auditor can ask for:

• Acceptable use policy
• Access control policy
• Business continuity plan
• Change management policy
• Confidentiality policy
• Code of conduct policy
• Data classification policy
• Disaster recovery policy
• Encryption policy
• Incident response plan
• Information security policy
• Logging and monitoring policy
• Physical security policy
• Password policy
• Remote access policy
• Vendor management policy

Complementary User Entity Controls (CUECs)

SOC 2 reports may include Complementary User Entity Controls (CUECs), which specify what controls the customer is responsible for implementing on their end. Examples include physical management, user provisioning, and authentication.

Readiness assessment

A readiness assessment is an optional trial run by an experienced auditor to identify gaps before the formal audit. The same firm can perform both.

How to obtain SOC 2 compliance

SOC 2 compliance is obtained by passing an audit which must be performed by a licensed CPA or CPA firm. They will evaluate controls against the AICPA’s Trust Services Criteria.

There are five types of testing methods used during the audit:

1. Inquiry
   
   • The auditor asks questions about controls that can't be directly observed. For example, management may be asked whether visitors are escorted by an employee, something the auditor can't verify just by being on site.
2. Observation
   
   • Operations are tested firsthand, such as observing onboarding procedures or physical access controls.
3. Examination or Inspection of Evidence
   
   • The auditor reviews documentation and records including manuals, visitor logs, and system databases to verify that controls are being applied.
4. Re-performance
   
   • The auditor manually executes a control to verify it works as intended. For example, if a system is supposed to automatically flag duplicate payments, the auditor may run the same calculation by hand to confirm that the output is accurate.
5. Computer Assisted Audit Technique (CAAT)
   
   • Software is used to analyze large volumes of data rather than a sample. For example, instead of spot-checking a handful of access logs, a CAAT test can review every login event across the entire audit period.

Once testing is complete, the report typically takes several weeks to finalize and is issued by the CPA firm.

SOC 2 compliance is not a one-time audit. Reports are valid for 12 months, and continuous monitoring is necessary to prevent compliance drift. When controls change between reporting periods, management may issue a bridge letter explaining those changes to the previous report's users.

SOC 2 compliance challenges

Although the framework is flexible, achieving SOC 2 compliance is a time-consuming and complex process.  

Multi-department collaboration is required, and the process involves technical security practices carried out by your IT department or information security team, physical security maintained by your building management, and onboarding practices and staff policies that involve the HR department.  

Common challenges include evidence collection, inconsistency in enforcement, and managing security as you scale.

The timeline from beginning the process and getting the final report can take several months to up to a year.

How Zero Trust architecture supports SOC 2 compliance

Zero Trust architecture helps organizations strengthen their SOC 2 compliance efforts through continuous enforcement of strict access controls and identity verifications. Implementing Zero Trust does not automatically guarantee SOC 2 compliance, but it helps build a stronger security foundation and supports many of the operational requirements evaluated during an audit.  

SOC 2 tells customers what your controls looked like during the audit period. What it can’t do is guarantee those controls are consistently running after the auditor leaves. Attestation is periodic. Attacks aren’t.

This is why ThreatLocker recommends pairing SOC2 governance with technical enforcement. With Application Allowlisting, Privileged Access Management, Data Storage Access Control, and Centralized Configuration Management, the controls your auditor reviewed are the same controls enforced on every device, every day.

FAQs

Is SOC 2 compliance required by law?

No, but it functions as a requirement in practice for many organizations. Enterprise buyers in financial services, healthcare, and regulated industries routinely require a SOC 2 report before onboarding a vendor. If your customers are asking for it, the distinction between legal requirement and contractual requirement doesn't matter much.

How much does SOC 2 compliance cost?

Costs vary significantly based on scope, organization size, and audit firm. Most organizations spend between $30,000 and $150,000 for a first-time Type II audit including preparation. Type I is less expensive due to the shorter scope. Compliance automation tools can reduce costs by streamlining evidence collection.

What is the difference between SOC 2 and ISO 27001?

SOC 2 is primarily US-centric and produces an attestation report valid for 12 months. ISO 27001 is a globally recognized certification valid for three years, with annual surveillance audits. SOC 2 is more common in US enterprise sales cycles while ISO 27001 carries more weight internationally. Many organizations pursue both, and there is significant control overlap between the two.

What is the difference between SOC 2 and NIST CSF?

NIST CSF is a voluntary cybersecurity framework with no audit, report, or certification output. It gives organizations a structured way to assess and improve their security posture across six core functions: Identify, Protect, Detect, Respond, Recover, and Govern (added in 2024). SOC 2 produces a formal attestation report issued by a licensed CPA firm that third parties can rely on. The two frameworks have significant control overlap. Many organizations use NIST CSF to build and mature their security program, then pursue SOC 2 to produce the external-facing documentation that customers require.

Does SOC 2 require a third-party auditor?

Yes. SOC 2 reports must be issued by a licensed CPA or CPA firm. You cannot self-certify. A readiness assessment beforehand is not required but is strongly recommended for first-time audits.