SOC 2 is the gold standard of security assurance for technology and cloud companies. Enterprise customers demand it. Investors evaluate it. And building a SOC 2 program requires mastering the Trust Services Criteria from both auditor and organizational perspectives.
SOC 2 (Service Organization Control 2) is an attestation report issued by a licensed CPA firm confirming that a service organization has implemented controls that meet the AICPA's Trust Services Criteria. Unlike SOC 1 (financial controls), SOC 2 focuses on security, availability, processing integrity, confidentiality, and privacy — the properties technology customers care about when entrusting you with their data.
Type I: Point-in-time assessment — confirms that controls are suitably designed as of a specific date. Issued faster (3–6 months to prepare). Less assurance. Often used as a stepping stone. Type II: Period-of-time assessment (minimum 6 months, typically 12) — confirms controls operated effectively throughout the period. Higher assurance. Required by most enterprise customers. The 12-month Type II report is the industry standard.
Security (CC): Always required — the foundation of every SOC 2. Addresses logical and physical access controls, change management, risk assessment, and incident response. Availability (A): System availability per SLA. Processing Integrity (PI): Complete, valid, accurate, timely processing. Confidentiality (C): Protection of confidential information. Privacy (P): Personal information lifecycle management. Criteria beyond Security are added when customer commitments or regulatory requirements demand them.
The Security Trust Services Criterion is organized into 9 Common Criteria categories with 64 points of focus:
The organizational culture and governance that supports effective internal controls. Covers: commitment to integrity and ethical values, board oversight, organizational structure, commitment to competence, and accountability. This is the COSO framework's "tone at the top" translated into SOC 2 requirements.
Information produced by the organization is identified, captured, and communicated in a form that supports control achievement. Includes: internal and external communications of security responsibilities, security policies available to all relevant parties.
The entity specifies objectives with sufficient clarity to enable identification of risks. Risk assessment includes cyber risks, fraud risks, and risks from vendor changes. The organization responds to changes affecting the control environment.
Ongoing and separate evaluations are selected, developed, and performed. Deficiencies are evaluated and communicated in a timely manner. Internal audit, security monitoring, and management review all contribute to CC4.
Control activities are selected and developed that contribute to achieving objectives. Technology controls are selected, developed, and implemented. Policies and procedures are established to support deployment of control activities.
The most heavily tested criteria in most SOC 2 audits. Covers: user provisioning/deprovisioning, authentication (MFA), access review, least privilege, physical access controls, encryption, and change management authorization.
Vulnerability and malware management, infrastructure monitoring, backup and recovery, incident detection and response. Demonstrates the organization detects and responds to threats before they cause harm.
Changes to infrastructure, data, software, and procedures are managed consistently and in accordance with a change management process. Prevents change-introduced vulnerabilities and unauthorized modifications.
Vendor and business partner management. Risk mitigation activities for business disruptions. Covers TPRM requirements within SOC 2 — vendor security questionnaires, contractual requirements, ongoing monitoring.
A readiness assessment identifies gaps before the formal audit — avoiding "qualified" findings in the actual report:
Define which Trust Services Criteria apply. Identify system components in scope (applications, infrastructure, data flows). Determine the audit period.
For each CC/TSC requirement, identify which existing controls address it. Document control owner, evidence type, and current implementation status (full/partial/none).
For each gap: What is the finding? What is the risk? What is the remediation? Who owns remediation? What is the target date?
For each control, identify whether evidence is available and in audit-ready format. Evidence gaps are as damaging as control gaps — a good control with no evidence will fail the audit.
Execute the remediation plan before the audit period begins. Changes made during the audit period (especially early in a Type II) may not generate enough operating evidence.
Conduct an internal mock audit 60 days before the formal audit. Identify remaining gaps. Provide management responses to simulated findings. Prepare the organization for auditor questions.
SOC 2 reports frequently reference User Entity Controls (UECs) — controls the customer (you) must implement for the service provider's controls to be effective:
Example: Your cloud provider's SOC 2 may say "User Entity is responsible for managing user access to the application." Even if the provider has great access controls, if you provision access incorrectly, the joint system is not secure.
When your customers review your SOC 2, they will look for UECs they must satisfy. Document your complementary user entity controls — evidence that you are meeting your side of the shared responsibility model.
If your system relies on subservice organizations (AWS, Salesforce, etc.), they can be included (inclusive method — tested by your auditor) or carved out (exclusive method — rely on their own SOC 2 reports). Most organizations use the carve-out method.
You are a GRC analyst preparing a SaaS startup for its first SOC 2 Type II audit. Complete each assessment step — mapping controls to Trust Service Criteria, identifying gaps, and documenting User Entity Controls (UECs) that customers must implement on their side.