SOC 2 Trust Services Criteria Deep Dive (2025): CC6 Logical Access Controls, CC7 System Operations, CC8 Change Management, CC9 Vendor Risk, and Auditor Evidence Requirements
A SOC 2 checklist tells you what to do. This guide tells you what auditors actually examine — the specific AICPA criterion language, the evidence samples auditors pull, and the patterns that most commonly produce exceptions. Understanding what drives audit findings is the fastest way to get from "we have controls" to "we have a clean Type 2 report."
Security Category (CC1-CC9) — Common Criteria Overview
| Criterion | Name | Primary Focus | Most Common Findings |
|---|---|---|---|
| CC1 | Control Environment | Board oversight, ethical values, org structure, HR policies | Missing information security policy signed by management, no board security reporting |
| CC2 | Communication & Information | Internal/external communication of security commitments, policies | Policies not communicated to all employees; no formal security awareness training records |
| CC3 | Risk Assessment | Formal risk register, fraud risk, risk tolerance | No documented risk assessment process or risk register for the audit period |
| CC4 | Monitoring Activities | Ongoing monitoring, deficiency reporting | No quarterly/annual security metrics reviewed by management |
| CC5 | Control Activities | Policies, segregation of duties, IT general controls | Single engineer can commit and deploy without approval (SoD failure) |
| CC6 | Logical & Physical Access | MFA, provisioning, deprovisioning, vendor access, encryption | Terminated employee with access >7 days; MFA not enforced; stale vendor credentials |
| CC7 | System Operations | Vulnerability management, SIEM, incident management | No incident register; vulnerability scans not on schedule; critical CVEs not remediated in SLA |
| CC8 | Change Management | PR review, testing, deployment authorization, emergency changes | Direct commits to production without review; emergency changes not retroactively documented |
| CC9 | Risk Mitigation | Business continuity, vendor management, subservice organization review | DR plan never tested; no vendor inventory; AWS SOC 2 not reviewed for CUECs |
Contract Risk — $97
Scan Your Vendor Agreement or Security Policy for SOC 2 Compliance Gaps
Upload your vendor security agreement, data processing agreement, or information security policy. BizLegal AI reviews the document for SOC 2 vendor management requirements (CC9.2 — vendor due diligence, right to audit, breach notification SLAs), complementary user entity controls (CUECs) that your organization must implement for subservice organization reliance, access control requirements for vendor access (CC6.6), confidentiality and data handling obligations, and data deletion/return at contract end provisions that impact SOC 2 Confidentiality criteria (C1.2).
Scan Your Vendor Agreement →Frequently Asked Questions
What are the five SOC 2 Trust Services Categories, and what does each cover?
SOC 2 attestation is issued by a licensed CPA firm under the American Institute of CPAs (AICPA) Statement on Standards for Attestation Engagements 18 (SSAE 18). The AICPA's Trust Services Criteria (TSC) — published in the updated 2017 revision (effective for reports with periods ending on or after September 30, 2018) — define the criteria that an auditor evaluates. The TSC is organized into five Trust Services Categories (formerly Trust Service Principles): Category 1 — Security (CC series, Common Criteria): Security is the only mandatory category for any SOC 2 examination. It is expressed through 9 sub-categories of "Common Criteria" (CC1-CC9) covering: control environment, communication and information, risk assessment, monitoring, logical and physical access controls, system operations, change management, risk mitigation, and vendor/supply chain management. The Security criteria use the COSO Internal Control — Integrated Framework (2013) as their structural foundation. The 9 CC sub-categories: CC1 — Control Environment (organizational culture, tone at the top, board oversight, HR policies — the foundational criteria that auditors evaluate first as they determine whether all other controls will function). CC2 — Communication and Information (internal communication of policies, board reporting, external communication to customers and users about the system). CC3 — Risk Assessment (risk identification, fraud risk assessment, risk tolerance, risk change management). CC4 — Monitoring Activities (continuous monitoring, reporting of deficiencies, internal audit if applicable). CC5 — Control Activities (policies and procedures that implement risk responses, segregation of duties, technology control activities). CC6 — Logical and Physical Access Controls (most heavily tested category for cloud/SaaS companies — credential management, MFA, access provisioning/deprovisioning, privileged access, vendor access, remote access, network security). CC7 — System Operations (system event logging, anomaly detection, incident management, backup and recovery). CC8 — Change Management (change authorization, code review, testing environments, emergency changes, development standards). CC9 — Risk Mitigation (business interruption risk, vendor/supply chain risk, insurance, business continuity). Category 2 — Availability (A1 series): covers system availability to meet commitments to users. Required for service providers whose customers depend on uptime (cloud infrastructure, communication platforms, fintech payment rails). A1 criteria: A1.1 — capacity planning to meet availability commitments; A1.2 — environmental protections (physical controls protecting system availability); A1.3 — backup and recovery procedures tested against defined recovery time objectives (RTO) and recovery point objectives (RPO). Category 3 — Processing Integrity (PI series): covers completeness, accuracy, timeliness, and authorization of system processing. Required for service providers where data processing quality is central to the customer relationship (payment processors, data transformation services, analytics platforms). PI criteria include: PI1.1-PI1.5 covering that inputs are complete and accurate, processing errors are detected and corrected, outputs are complete and accurate, and data is retained as required. Category 4 — Confidentiality (C1 series): covers how the service provider handles confidential information (information that is designated as confidential by an agreement or understood to be confidential). Confidentiality (C1) is distinct from Privacy (P1-P8): confidentiality covers business confidential information (trade secrets, financial data, IP); privacy covers personal information about natural persons. C1.1 — confidential information is identified and maintained. C1.2 — confidential information is disposed of when no longer required by the commitment. Category 5 — Privacy (P1-P8 series): covers personal information about natural persons throughout its lifecycle (notice, choice and consent, collection, use/retention/disposal, access, disclosure to third parties, quality, monitoring and enforcement). Privacy is the only Trust Services Category that overlaps significantly with GDPR and CCPA compliance. P1.1 through P8.1 track the AICPA Generally Accepted Privacy Principles (GAPP). For most SaaS B2B companies: a typical SOC 2 report covers Security (mandatory) plus Availability (almost always included for cloud products) plus Confidentiality (included when handling sensitive customer data). Processing Integrity is added for payment processors and data transformation companies. Privacy is added when the service processes personal information of end users (not just enterprise customer employees).
What does CC6 (Logical and Physical Access Controls) cover, and what evidence do SOC 2 auditors collect for each CC6 sub-criterion?
CC6 is the most operationally demanding cluster of Security criteria for cloud and SaaS companies. It contains 10 numbered criteria (CC6.1 through CC6.10) that auditors evaluate through a combination of inquiry (interviews with management and staff), observation (live observation of procedures), inspection (review of documentation, logs, tickets, and records), and re-performance (independently executing the control to verify it functions). CC6.1 — Logical access security measures restrict access to the system: implemented by: role-based access control (RBAC) for all production systems; access provisioning process tied to HR onboarding and defined job functions; access request and approval workflow; inventory of all access granted; principle of least privilege for all roles. Auditor evidence: user access listing for all production systems (extract from IAM system), sample access requests and approvals, HR roster cross-referenced to access list, role definitions. CC6.2 — New internal and external users are registered and granted access based on authorization: implemented by: formal access provisioning procedure; access request form requiring manager/system owner approval; access provisioning only after approval is documented. Auditor evidence: sample of access requests for new hires (10-25 samples), access provisioning tickets, evidence that access was granted only after documented approval. CC6.3 — Internal and external users' access to information assets is removed on a timely basis when no longer needed (access deprovisioning): implemented by: HR/IT offboarding checklist requiring access revocation at or before last day of employment; periodic access reviews (typically quarterly) to identify and remove access for employees who changed roles; automated deprovisioning triggers where feasible. Auditor evidence: termination access revocation log for sample of terminated employees, evidence of access removal within defined SLA (e.g., same-day for voluntary departures, immediate for involuntary), quarterly access review evidence showing stale access identified and removed. Deprovisioning is the most common finding in SOC 2 audits — companies consistently fail to timely remove access for terminated employees, particularly for third-party SaaS tools that are not tied into the HR system. CC6.4 — Access to the information assets is restricted through the use of access control software and operating procedures: logical network segmentation, firewall rules, VPN requirements for administrative access to production systems. CC6.5 — Logical access controls restrict access to data and processes based on defined authorization requirements: encryption of data in transit (TLS 1.2+) and at rest, database access controls, API authentication. CC6.6 — Logical access to the system is removed when no longer authorized: covers vendor/third-party access — access for contractors, consultants, and integration vendors must be provisioned, documented, and removed when the relationship ends or the access is no longer needed. Vendor access is a common finding: companies routinely fail to remove vendor SSH keys or API credentials after projects end. CC6.7 — Logical access controls restrict the ability to transmit, move, copy, or print electronic protected information: data loss prevention (DLP) controls, download restrictions, copy-paste controls in certain environments. CC6.8 — Controls support the use of the entity's policies for the management of passwords and other authenticators: MFA enforcement for all users with access to production systems, password policy (length, complexity, rotation schedule, no password reuse), SSO integration with all production systems. MFA is now effectively required for SOC 2 — auditors will find CC6.8 deficiency if MFA is not enabled on any system containing production data or production access. CC6.9 — The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software: anti-malware controls, endpoint detection and response (EDR) deployed on all endpoints, code scanning in CI/CD pipeline (SAST, DAST, dependency vulnerability scanning), vulnerability management program. CC6.10 — The entity implements procedures to prevent and detect unauthorized physical access to information assets: physical access controls for server rooms and data centers (card access, visitor logs, CCTV) — for cloud-native companies, this is satisfied by SOC 2 Type 2 reports from AWS/GCP/Azure (subservice organization carve-out). Evidence collection timeline: auditors typically collect evidence for the full audit period (12 months for Type 2). For access provisioning (CC6.2) and deprovisioning (CC6.3), auditors will select a sample of access events during the period — typically 25-40 samples. If any samples show unauthorized access or late deprovisioning, the auditor will expand sampling. A single finding of a terminated employee with access 30+ days after termination typically results in an exception. Companies with 1-2 exceptions on CC6.3 typically receive a qualified opinion (exception noted) rather than a clean report. Three or more similar exceptions pattern as a control deficiency.
What does CC7 (System Operations) cover, and how does SOC 2 treat incident management and anomaly detection?
CC7 covers how the organization operates its system on a day-to-day basis — detecting, responding to, and recovering from operational issues. It contains 5 numbered criteria (CC7.1 through CC7.5). CC7.1 — Detection of vulnerabilities and other events: implemented by: vulnerability scanning on a defined schedule (at minimum quarterly external, monthly internal for Type 2); penetration testing (annually or after significant changes); CVE monitoring and patch management program; intrusion detection system (IDS) or intrusion prevention system (IPS) monitoring network traffic; anomaly detection tools (AWS GuardDuty, Azure Sentinel, CloudTrail alerts). Auditor evidence: vulnerability scan reports for the audit period (showing all scans completed per the policy), evidence of remediation for critical/high vulnerabilities within the defined SLA, penetration test report from the audit period (plus evidence of remediation of findings), IDS/IPS alert logs. Common finding: companies set a policy for quarterly vulnerability scans but fail to run them on schedule, or run scans but fail to remediate critical vulnerabilities within the defined timeline (e.g., policy says 30 days for critical CVEs; evidence shows 60-90 days elapsed). CC7.2 — The entity monitors system components and the operation of those components for anomalies: implemented by: centralized logging (SIEM) — all production logs aggregated to a central system with defined retention (90+ days online, 1 year archive); alert rules for security-relevant events (failed login attempts above threshold, privilege escalation, access to sensitive data outside normal patterns, after-hours administrative access); dashboards monitoring system health metrics. Auditor evidence: SIEM configuration showing key alert rules, sample of security alerts triggered during the period showing alerts were investigated and resolved, evidence of monitoring coverage (all production systems send logs to SIEM). CC7.3 — The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its commitments and system requirements and, if so, takes actions to prevent or address such failures: incident classification and escalation procedure; defined incident severity levels (P1/P2/P3/P4 or Critical/High/Medium/Low); incident response runbooks for common incident types (data breach, ransomware, DDoS, account compromise); post-incident review process for high-severity incidents. CC7.4 — The entity responds to identified security incidents by executing a defined incident response program: incident response plan (IRP) that defines roles, communication procedures, escalation paths, and notification obligations; incident tracking in a ticketing system (Jira, PagerDuty, etc.); evidence of incidents detected, classified, responded to, and closed during the period. Auditor evidence: incident register for the audit period (all incidents logged, classified, and closed), sample of incident tickets showing proper classification and timely response, evidence that security team was notified for security incidents, evidence of notification to customers or regulators where required (breach notification obligations). Companies with no incident register, or with incidents tracked only in email threads, frequently receive findings on CC7.4. CC7.5 — The entity identifies, develops, and implements activities to recover from identified security incidents: incident recovery procedures; root cause analysis for significant incidents; lessons learned and control improvement following incidents. For cloud-native companies: backup procedures (automated snapshots, defined retention, tested restores) are evaluated primarily under Availability A1.3, but recovery from security incidents is also a CC7.5 concern. What CC7 looks like for a typical SaaS company: a well-functioning CC7 program for a 50-person SaaS company includes: SIEM with all production AWS/GCP logs centralized (CloudTrail, VPC Flow Logs, App logs), alert rules for the OWASP Top 10 attack patterns plus internal anomalies, weekly vulnerability scan with a 30-day SLA for critical CVEs, an annual penetration test from a named vendor, and an incident response plan signed by the CISO/CTO with quarterly tabletop exercises. The incident register tracks every Severity 2+ incident with timestamps for detection, classification, response, and resolution.
What does CC8 (Change Management) require, and what is the evidence for a clean change management program?
CC8 covers how the organization manages changes to the production environment — infrastructure changes, application code changes, and configuration changes. It contains 1 primary criterion (CC8.1) with multiple sub-points and supplemental criteria. CC8.1 — Changes to the entity's processing environment are authorized, developed, tested, approved, and implemented per the entity's defined change management procedures. This breaks into several distinct program elements: Change authorization: all changes to production must be authorized before deployment. The authorization model varies by company size: for small startups, a pull request approval by a second engineer; for larger companies, a formal change advisory board (CAB) or change request process with manager/CTO approval. Auditor evidence: pull request history showing all production deployments reviewed and approved by an authorized reviewer; evidence that no unauthorized direct commits to production code or configuration occurred during the period. Development and testing standards: code developed in a separate environment (development, staging/QA) from production; testing requirements before production deployment (unit tests, integration tests, staging deployment). Segregation of environments: access to production deployment must be controlled separately from development access. A developer who can write code AND deploy it to production without a second approval is a segregation of duties finding. For very small startups, "compensating controls" (detailed audit logs, post-deployment review) may substitute for full segregation. Code review: formal code review (pull request review by at least one additional developer) for all production changes. Automated pipeline: the preferred structure is a CI/CD pipeline that enforces: automated testing must pass before merge, branch protection rules preventing direct commits to main, required reviewers for production deployments. Emergency changes: a documented emergency change procedure for urgent production fixes that cannot wait for normal change management. Emergency changes are applied with limited controls but must be retroactively reviewed and approved after deployment. Auditor evidence: emergency change log for the period showing all emergency changes documented, applied, and retroactively reviewed. Auditor evidence for CC8 overall: a sample of production deployments (code changes, infrastructure changes, configuration changes) from the audit period — typically 25-40 samples. For each sample: evidence that a pull request or change request was created; evidence of code review (specific reviewer identified); evidence that automated tests passed (CI/CD pipeline logs); evidence of approval before deployment; and evidence that the deployment was executed in accordance with the approved change. Database schema migration controls: schema migrations are changes and must go through change management. Common finding: companies with robust code change management but ad-hoc database schema changes that do not go through the same approval process. Configuration management: infrastructure-as-code (IaC) changes (Terraform, CloudFormation) must go through change management. Companies that manually make changes to AWS Security Groups or IAM policies through the console rather than through reviewed and approved IaC receive findings. CC8 supplemental criteria often examined: (a) Rollback capability — can the company quickly roll back a bad production deployment? (b) Release notes or change communication — are customers notified of changes that affect their experience? (c) Post-implementation reviews for significant changes. What clean CC8 evidence looks like: a 100-engineer company in a 12-month audit period might have 500+ production deployments. Auditors will sample 25-40; each sample shows a GitHub PR with specific reviewer approval, green CI check, and production deployment via the CI/CD pipeline (no manual deployments). Emergency change log shows 3 emergency changes during the year, each with a retroactive review completed within 48 hours. Database migrations all tracked in Flyway or Liquibase with the same PR approval workflow.
What is the SOC 2 Type 1 vs Type 2 distinction, and how long does a Type 2 audit take to prepare for?
The Type 1 vs Type 2 distinction is the most fundamental question for a company beginning its SOC 2 journey, and the answer determines scope, cost, timeline, and the commercial value of the resulting report. SOC 2 Type 1 report: a Type 1 report attests that the service organization's description of its system is "fairly presented" and that its controls are "suitably designed" to meet the applicable Trust Services Criteria — as of a single point in time (a specific date, e.g., "as of March 31, 2025"). Type 1 demonstrates design, not operation. The auditor reviews whether controls are in place and correctly designed as of the report date — not whether they have been operating effectively over time. Type 1 is appropriate for: (a) companies preparing their first SOC 2 that want a starting point (some enterprise customers accept Type 1 as a preliminary report while the company prepares for Type 2); (b) companies that have recently implemented controls and need a report before a full 12-month period has elapsed. Type 1 limitations: enterprise customers — particularly those in financial services, healthcare, and government — will generally require Type 2 before entering significant contracts. Type 1 is rarely sufficient as a long-term enterprise sales enabler. SOC 2 Type 2 report: a Type 2 report attests that the controls are "suitably designed" AND have been "operating effectively" over a specified review period. The minimum review period is 6 months; the standard industry expectation is 12 months. The Type 2 audit period typically runs from a specific start date (e.g., October 1, 2024) through a specific end date (September 30, 2025) — a rolling 12-month window. Type 2 commercial value: a clean (unqualified) Type 2 report is the gold standard for enterprise B2B sales. It is sufficient for most enterprise procurement security questionnaire requirements, satisfies most customer security review requirements for contracts under $1M ARR, and is required for HIPAA covered entities and business associates before entering into business associate agreements with major health systems. SOC 2 preparation timeline (realistic): for a company starting from scratch (no prior SOC 2 program): Months 1-3 (Readiness Assessment): engage a SOC 2 consultant or use a compliance automation platform (Vanta, Drata, Thoropass, SecureFrame) to perform a readiness assessment. Identify all gaps between current controls and TSC requirements. Prioritize gap remediation based on audit risk. Months 3-6 (Gap Remediation): implement missing controls: MFA everywhere, quarterly access reviews, formal vulnerability management program, centralized logging (SIEM), incident response plan, change management PR workflow enforcement, vendor management policy, business continuity and disaster recovery (BCDR) plan. Months 6-12 (Evidence Accumulation): operate all controls consistently for the full audit period. Maintain evidence: quarterly access review records, vulnerability scan reports, penetration test report, incident register, change management logs. Month 12 (Audit Fieldwork): CPA firm conducts fieldwork over 4-8 weeks. Requests samples for each criterion. Company compiles and provides evidence. Month 13-14 (Report Issuance): CPA firm issues the Type 2 report. Total timeline from "starting from scratch" to "Type 2 report in hand": 14-18 months. Cost of SOC 2: readiness assessment and gap remediation: $20,000-$75,000 (consulting fees or compliance platform annual subscription $15,000-$30,000/year for Vanta/Drata plus consulting for gap work). Type 2 audit fees from CPA firm: $15,000-$40,000 for a small SaaS company (25-100 employees, Security + Availability criteria); $40,000-$100,000+ for larger companies or more criteria. Compliance automation platforms (Vanta, Drata, Thoropass): these platforms automate evidence collection by integrating directly with AWS, GCP, GitHub, Okta, Jira, and other tools, continuously monitoring control status, and generating audit-ready evidence packages. They significantly reduce the manual evidence collection burden but do not replace the need for a licensed CPA firm to conduct the actual audit.
What are CC9 (Risk Mitigation) and vendor management requirements under SOC 2, and what does a compliant third-party risk program look like?
CC9 is the most frequently overlooked cluster of SOC 2 criteria among startups. It covers how the organization manages risks that originate outside its direct control — primarily from third-party vendors, subservice organizations, and business interruption events. CC9.1 — The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions: business continuity planning (BCP) and disaster recovery planning (DRP) to address risks of system unavailability. Business continuity plan elements: (a) recovery time objective (RTO) — maximum acceptable downtime (e.g., 4 hours for critical systems); (b) recovery point objective (RPO) — maximum acceptable data loss (e.g., 1 hour of transactions); (c) identification of critical systems and their recovery dependencies; (d) alternative processing procedures (can the company operate manually while systems are restored?); (e) contact trees for staff, vendors, and customer communication. Disaster recovery plan elements: (a) backup procedures (automated snapshots, offsite replication, cross-region replication in cloud environments); (b) restoration procedures (steps to restore from backup, tested and documented); (c) recovery testing — DR tests must actually be executed and documented; a plan that has never been tested is not evidence of an operating DR control. Auditor evidence: BCP/DRP documentation, evidence of DR test conducted during the audit period (test results, test date, participants, outcome), RTO/RPO metrics from the DR test. Common finding: companies with BCP/DRP documentation but no evidence of annual testing consistently receive CC9.1 exceptions. CC9.2 — The entity assesses and manages risks associated with vendors and business partners (vendor management / third-party risk): this is the most commercially significant CC9 criterion for cloud-native companies because virtually every SaaS product is built on a stack of third-party subservice organizations (AWS/GCP/Azure as IaaS, Stripe for payments, Twilio for communications, Salesforce for CRM, etc.). The vendor management program must address: (a) Vendor inventory: a maintained list of all vendors who access company systems, process company data, or provide services integral to the product. (b) Vendor due diligence at onboarding: security review before engaging a new vendor who will access company systems or process company/customer data. Due diligence elements: obtaining the vendor's SOC 2 Type 2 report (if available), security questionnaire, privacy policy review (if they process personal data), data processing agreement (DPA), contractual security requirements (right to audit, breach notification). (c) Ongoing vendor monitoring: annual re-assessment of significant vendors; review of updated SOC 2 reports when issued. (d) Subservice organization risk: for subservice organizations (vendors whose services are integral to the SOC 2 system description — typically IaaS providers), the company must either include the subservice organization's controls in its own audit scope ("carved-in" approach, extremely rare) or use the "carve-out" method (exclude the subservice organization's controls from scope) and rely on the subservice organization's own SOC 2 report. For the carve-out method: the company's SOC 2 report will reference the subservice organizations (e.g., AWS, Stripe, etc.) and state that the company relies on the subservice organization's controls for the carved-out functions. The company must demonstrate it reviews the subservice organization's SOC 2 report annually, reviews the complementary user entity controls (CUECs) that the subservice organization places on its users, and verifies it has implemented the CUECs. Auditor evidence for CC9.2: vendor inventory (list of all significant vendors), sample of vendor onboarding due diligence documentation (security questionnaire responses, DPAs, SOC 2 reviews), evidence of annual vendor re-assessment for existing vendors, copies of AWS/Stripe/other subservice organization SOC 2 reports reviewed during the audit period, evidence that CUECs from those SOC 2 reports were reviewed and implemented. What a compliant third-party risk program looks like in practice: quarterly vendor inventory review, a vendor risk tiering system (Tier 1: production data access; Tier 2: system access without data access; Tier 3: no system access), security questionnaires for all Tier 1 vendors at onboarding with annual refresh, DPA requirement for all vendors processing personal data, a documented policy specifying when a SOC 2 report vs. a questionnaire is required, and a tracked list of all subservice organization SOC 2 reports reviewed each year with evidence of CUEC implementation review.