SOC 2 Trust Services Criteria explained for GRC practitioners

The AICPA Trust Services Criteria, updated in 2017 with ongoing incremental guidance, form the evaluation framework for SOC 2 examinations. Criteria are organized into categories: Security (mandatory), Availability, Processing Integrity, Confidentiality, and Privacy. Every SOC 2 examination includes Security, which encompasses the Common Criteria labeled CC1 through CC9.

Common Criteria address control environment, communication, risk assessment, monitoring, control activities, logical and physical access, system operations, change management, and risk mitigation. Additional criteria categories layer domain-specific requirements onto the Common Criteria foundation when selected.

GRC practitioners should treat the TSC as the authoritative mapping layer between business risks and auditor expectations. Controls you implement must trace to specific criterion points of focus, not generic security best practices disconnected from the framework.

CC1 Control Environment establishes tone at the top, organizational structure, and accountability. Auditors expect board or leadership oversight of security, defined roles, and competence requirements for personnel handling customer data. CC2 Communication covers internal and external security communication, including policy distribution and customer-facing security commitments.

CC3 Risk Assessment requires identification and analysis of risks to achieving service commitments. CC4 Monitoring Activities expects ongoing evaluation of control effectiveness, including internal assessments and remediation tracking. CC5 Control Activities is where most technical controls live: approvals, reconciliations, verifications, and segregation of duties.

CC6 Logical and Physical Access is the most evidence-intensive area for SaaS companies: authentication, authorization, provisioning, deprovisioning, and physical data center controls delegated to cloud providers with documented shared responsibility. CC7 System Operations covers intrusion detection, incident response, and capacity management. CC8 Change Management addresses development and infrastructure changes. CC9 Risk Mitigation covers vendor management and business continuity.

• CC1-CC2: governance, roles, communication
• CC3-CC4: risk assessment and monitoring
• CC5-CC6: control activities and access
• CC7-CC9: operations, change, vendors, continuity

Security is non-optional in every SOC 2 report. It wraps the Common Criteria with category-specific points of focus emphasizing protection against unauthorized access, disclosure, and damage to systems. Your system description must explain how Security criteria apply to your architecture.

Implementations vary by company size but consistently require MFA, encryption in transit and at rest, vulnerability management, security event logging, and incident response. The Security category does not replace Common Criteria; it contextualizes them for the security domain.

When customers ask only for Security, confirm they do not implicitly expect Privacy or Confidentiality based on data types processed. Personal data handling often triggers Privacy criteria expectations even when contracts say Security only.

Availability applies when you commit to uptime SLAs in customer contracts. It adds requirements for performance monitoring, backup, recovery testing, and environmental protections. Include it if your product promise includes specific availability percentages.

Processing Integrity applies when your system performs transaction processing, calculations, or data transformations where completeness and accuracy are part of the service commitment. ETL platforms, payment processors, and billing engines commonly select this category.

Confidentiality applies when you handle information designated confidential by customers or regulation, beyond general personal data. Trade secrets, unreleased financial data, and protected health information often trigger Confidentiality criteria. Privacy applies when you collect, use, retain, disclose, and dispose of personal information according to your privacy notice and applicable regulations.

Build a matrix with criterion identifiers as rows and your control activities as columns. Each control should map to one primary criterion and optionally secondary criteria where overlap exists. Avoid orphan controls that auditors cannot trace to a point of focus.

Points of focus within each criterion provide auditor guidance, not a mandatory checklist. However, failing to address a point of focus without rationale invites questions during fieldwork. Document deliberate exclusions where a point of focus is not applicable to your environment.

Maintain the mapping as a living artifact. When engineering changes authentication providers or HR changes onboarding workflow, update the matrix and verify criterion coverage before the next audit cycle. Structured GRC tooling accelerates this by linking evidence artifacts directly to criterion IDs.

Lead discussions with criterion references, not tool names. Saying we satisfy CC6.6 through quarterly access reviews with ticket evidence is clearer than saying we use a specific SaaS product for compliance.

Prepare a criteria scoping memo for your auditor documenting which categories are in scope, which points of focus were considered not applicable, and the rationale for each exclusion. This memo reduces back-and-forth during planning.

Review AICPA guidance updates annually. Criteria interpretations evolve through TSP sections and industry working groups. Staying current prevents designing controls against outdated assumptions that auditors no longer accept.

Embed criterion IDs into ticket templates and change records so evidence self-documents over time. When a deployment ticket includes CC8.1 reference tags, auditors trace change management coverage without custom explanations each cycle.

Train new hires on the criteria relevant to their role during security onboarding. Engineers responsible for production access should understand CC6 expectations; support staff handling customer data should understand Privacy points of focus if that category is in scope.

Measure control health with the same rigor as production metrics. Track access review completion rates, mean time to deprovision terminated users, and percentage of changes with documented approvals. These operational metrics predict audit outcomes before fieldwork begins.