SOC 2 Compliance Guide: Requirements, Trust Service Criteria, and Audit Preparation

SOC 2 has become the default trust signal for SaaS companies selling to enterprises. If your prospects are asking for your SOC 2 report during procurement, you already know why it matters. If they haven't asked yet, they will.

This guide covers what SOC 2 actually requires, how to prepare, and how to avoid the common pitfalls that delay audits and increase costs.

What SOC 2 Is (and Isn't)

SOC 2 is a compliance framework developed by the AICPA (American Institute of Certified Public Accountants) for service organizations that handle customer data. It evaluates your controls against the Trust Service Criteria.

What SOC 2 is not:

• It's not a certification — it's an attestation report issued by a CPA firm
• It's not prescriptive — it doesn't tell you exactly which controls to implement
• It's not one-size-fits-all — you choose which criteria apply to your business

This flexibility is both its strength and its challenge. SOC 2 tells you what to achieve, not how to achieve it.

The Five Trust Service Criteria

Security (Common Criteria) — Required

Every SOC 2 report includes Security. It covers protection of information and systems against unauthorized access, both logical and physical.

Key control areas:

• Access control and authentication
• Network and infrastructure security
• Change management
• Incident response
• Risk assessment and management
• Vendor management

Availability — Recommended for SaaS

Evaluates whether systems are operational and accessible as committed (e.g., SLAs, uptime guarantees).

Key control areas:

• Capacity planning and monitoring
• Disaster recovery and business continuity
• Backup and restoration procedures
• Performance monitoring and alerting

Processing Integrity

Ensures that system processing is complete, valid, accurate, timely, and authorized. Relevant for companies where data accuracy is core to the service.

Key control areas:

• Input validation and processing controls
• Output accuracy verification
• Error handling and correction procedures

Confidentiality

Protects information designated as confidential (trade secrets, intellectual property, client data under NDA).

Key control areas:

• Data classification and handling
• Encryption in transit and at rest
• Confidential data disposal
• Access restrictions to confidential information

Privacy

Addresses the collection, use, retention, disclosure, and disposal of personal information in accordance with privacy commitments.

Key control areas:

• Privacy notice and consent management
• Data subject access and deletion requests
• Personal data retention and disposal
• Cross-border data transfer controls

Type I vs. Type II: Which Do You Need?

Aspect	Type I	Type II
What it tests	Control design and implementation	Control design and operating effectiveness
Time scope	Point in time (single date)	Period of time (3-12 months)
Evidence required	Controls exist and are properly designed	Controls operated consistently over the period
Timeline	2-4 months	6-12 months (including observation period)
Customer acceptance	Acceptable for early-stage deals	Required by most enterprise buyers

When to use Type I: You need a SOC 2 report quickly to close a deal and plan to upgrade to Type II. It proves your controls exist but doesn't prove they work consistently.

When to use Type II: You're selling to enterprises with mature security review processes. Type II is the standard expectation and demonstrates sustained control effectiveness.

Most companies do a Type I first to establish a baseline, then transition to Type II with a 6-month observation window.

SOC 2 Control Domains in Practice

While SOC 2 doesn't prescribe specific controls, the Common Criteria map to practical control areas. Here's what auditors typically evaluate:

CC1: Control Environment

• Information security policies documented and communicated
• Organizational structure and reporting lines defined
• Board/leadership oversight of security program
• Code of conduct and ethics policies

CC2: Communication and Information

• Security awareness training program
• Internal communication of security policies
• External communication (privacy notice, terms of service)
• Incident notification procedures

CC3: Risk Assessment

• Formal risk assessment process
• Risk register with identified threats and vulnerabilities
• Risk treatment decisions documented
• Regular risk reassessment cadence

CC4: Monitoring Activities

• Continuous monitoring of control effectiveness
• Internal audit or self-assessment program
• Exception tracking and remediation
• Penetration testing and vulnerability scanning

CC5: Control Activities

• Logical access controls (SSO, MFA, RBAC)
• Physical access controls (if applicable)
• Change management procedures
• Data backup and recovery

CC6: Logical and Physical Access

• User provisioning and deprovisioning
• Least-privilege access enforcement
• Multi-factor authentication
• Access reviews (quarterly recommended)

CC7: System Operations

• Infrastructure monitoring and alerting
• Incident detection and response
• Patch management
• Capacity planning

CC8: Change Management

• Change request and approval process
• Testing before deployment
• Rollback procedures
• Segregation of duties in deployments

CC9: Risk Mitigation

• Vendor risk assessment and management
• Business continuity planning
• Insurance and risk transfer
• Control testing and validation

SOC 2 Preparation Timeline

Month 1-2: Readiness Assessment

• Map existing controls to Trust Service Criteria
• Identify gaps and create a remediation plan
• Select and engage an audit firm
• Choose your Trust Service Criteria scope
• Set up evidence collection processes

Month 2-3: Remediation and Implementation

• Implement missing controls (MFA, access reviews, encryption)
• Write or update security policies
• Configure monitoring, alerting, and logging
• Establish incident response procedures
• Train employees on security policies

Month 4-9: Observation Period (Type II)

• Controls must operate consistently throughout this period
• Collect evidence continuously (access review records, change tickets, incident reports)
• Address any control failures immediately and document remediation
• Conduct at least one tabletop incident response exercise

Month 9-10: Audit Fieldwork

• Auditor reviews evidence, tests controls, and interviews staff
• Address any questions or additional evidence requests
• Review draft report for accuracy

Month 10: Report Issuance

• Receive final SOC 2 report
• Address any exceptions or observations
• Share report with customers under NDA

Common SOC 2 Mistakes

Starting evidence collection too late. The observation period requires continuous proof that controls work. If you start collecting evidence in month 4 of a 6-month window, you'll have gaps.

Choosing too many criteria. Including all five criteria when you only need Security and Availability adds scope, cost, and audit complexity without proportional value. Let customer requirements drive your scope.

Treating policies as decorations. Writing security policies that no one follows guarantees audit exceptions. Policies must reflect actual practice, and staff must be trained on them.

Ignoring vendor risk. Your SOC 2 scope includes third-party services that process customer data. Auditors will ask how you assess and monitor vendor security. Have a vendor management process in place.

No access reviews. Quarterly user access reviews are one of the most commonly tested controls. If you can't prove you regularly review and revoke unnecessary access, expect an exception.

SOC 2 and Other Frameworks

SOC 2 doesn't exist in isolation. Many controls overlap with other frameworks:

SOC 2 Area	ISO 27001 Overlap	NIST CSF Overlap
Access Control	A.9 Access Control	PR.AC
Risk Assessment	Clause 6.1	ID.RA
Incident Response	A.16 Incident Management	RS.RP
Change Management	A.14 System Development	PR.IP
Monitoring	Clause 9 Performance Evaluation	DE.CM

A GRC platform with multi-framework mapping lets you implement controls once and satisfy multiple frameworks simultaneously, reducing duplicate effort across SOC 2, ISO 27001, and NIST CSF programs.