The Trust Services Criteria, Decoded: What SOC 2 Actually Asks of You
The AICPA Trust Services Criteria organize SOC 2 into 5 categories and 9 Common Criteria series. CC4 and CC7 explicitly require ongoing vulnerability scans and monitoring — not a pre-audit snapshot.
The Trust Services Criteria, Decoded: What SOC 2 Actually Asks of You
TL;DR
The AICPA's 2017 Trust Services Criteria (with Revised Points of Focus — 2022) is the control catalog your auditor tests against in a SOC 2, SOC 3, or SOC for Cybersecurity engagement. It is outcomes-based rather than a checklist of specific controls, and it is built on the COSO Internal Control — Integrated Framework. A SOC 2 can cover one or more of five categories, and Security is the only one built entirely from the Common Criteria. CC4 and CC7 explicitly name vulnerability scans, security assessments, and penetration testing as ongoing evaluations, and CC7.1 requires scans on a periodic basis and after significant changes, with timely remediation. That means evidence has to span the full Type II period, typically 6 to 12 months, not a snapshot taken the week before fieldwork.
What this is
The 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with Revised Points of Focus — 2022) is the control catalog developed by the AICPA's Assurance Services Executive Committee for use in SOC 2, SOC 3, and SOC for Cybersecurity engagements. When your enterprise customers, your procurement team, or your board asks for "a SOC 2 report," this is the criteria set your auditor is testing your controls against.
Two things about the TSC surprise people who are new to it.
First, it isn't a checklist of specific controls — it's an outcomes-based framework. Unlike NIST 800-53 or a prescriptive framework that tells you exactly which controls to implement, the TSC states what outcome your controls need to achieve and leaves the specific implementation to you. That flexibility is deliberate: the AICPA recognizes there's no single set of controls that mitigates every organization's unique risks. It also means your auditor exercises judgment in evaluating whether your specific implementation satisfies the criterion's intent — which makes clear, well-organized evidence even more important than in a prescriptive framework.
Second, the TSC is built directly on the COSO Internal Control – Integrated Framework. The criteria align to COSO's 17 principles, organized into five components: Control Environment, Information and Communication, Risk Assessment, Monitoring Activities, and Control Activities. On top of the COSO principles, the TSC adds supplemental criteria specific to technology and security — organized into four areas: Logical and Physical Access Controls, System Operations, Change Management, and Risk Mitigation.
Why it matters
A SOC 2 engagement can cover one or more of five categories, and your customer contracts or your own risk assessment typically determine which ones apply.
Security — Information and systems are protected against unauthorized access, unauthorized disclosure, and damage that could compromise availability, integrity, confidentiality, or privacy. Security is the only category built entirely from the Common Criteria — no additional category-specific criteria are needed. In practice, security is included in nearly every SOC 2 engagement, because it's the baseline concern of virtually every customer evaluating a vendor.
Availability — Information and systems are available for operation and use to meet the entity's objectives. This doesn't set a minimum uptime percentage or address system functionality — it addresses whether the system includes controls supporting accessibility for operation, monitoring, and maintenance.
Processing Integrity — System processing is complete, valid, accurate, timely, and authorized. This category matters most for systems that transform data or execute transactions — payment processing, order fulfillment, data pipelines — where errors, omissions, or unauthorized manipulation would materially affect the entity's commitments to customers.
Confidentiality — Information designated as confidential is protected according to the entity's objectives, from collection through final disposition. Confidentiality differs from privacy in scope: it covers any sensitive information (trade secrets, proprietary data, contractual commitments), not just personal information about individuals.
Privacy — Personal information is collected, used, retained, disclosed, and disposed of according to the entity's privacy objectives, organized around eight sub-areas: notice, choice and consent, collection, use/retention/disposal, access, disclosure and notification, quality, and monitoring and enforcement.
Every category you include requires the Common Criteria plus the category-specific criteria for that category. If you're only pursuing Security — the most common starting point — you need the Common Criteria and nothing more.
How it works
The Common Criteria are where most of the operational, testable substance of a SOC 2 examination lives. They're organized into nine series, and understanding what each one demands is the fastest way to understand what your auditor will actually test.
CC1 — Control Environment
Maps to COSO Principles 1–5: commitment to integrity and ethical values, board independence and oversight, organizational structure and reporting lines, commitment to competence, and accountability for internal control responsibilities. This is where governance-level evidence lives — code of conduct, board composition, org charts, performance management tied to security responsibilities.
CC2 — Information and Communication
Maps to COSO Principles 13–15: the entity generates and uses quality information, communicates internal control responsibilities internally, and communicates with external parties about matters affecting internal control. The technology-specific points of focus here are significant — asset management, information classification, and (at the system level) communicating system boundaries and objectives to relevant personnel.
CC3 — Risk Assessment
Maps to COSO Principles 6–9: specifying objectives clearly enough to assess risk, identifying and analyzing risk across the entity, considering fraud risk, and identifying changes that could significantly affect internal control. The TSC-specific points of focus add identifying threats to objectives, vulnerabilities in system components, and — critically — analyzing threats and vulnerabilities arising from vendors and business partners.
CC4 — Monitoring Activities
Maps to COSO Principles 16–17: selecting and performing ongoing and separate evaluations of internal control, and evaluating and communicating deficiencies to responsible parties in a timely manner. This is where vulnerability scans, security assessments, and penetration testing are explicitly named as examples of ongoing and separate evaluations. CC4 is not a suggestion to test your controls occasionally — it requires an established practice of assessing whether controls are present and functioning, with deficiencies tracked to remediation.
CC5 — Control Activities
Maps to COSO Principles 10–12: selecting and developing control activities that mitigate risk, developing general controls over technology, and deploying control activities through policies and procedures. This is the connective tissue between risk assessment and actual technical implementation.
CC6 — Logical and Physical Access Controls
This is the largest and most technically dense series in the entire TSC — eight sub-criteria (CC6.1 through CC6.8) covering: implementing logical access security software and architectures; registering and authorizing new users prior to granting access, and removing credentials when access is no longer needed; authorizing, modifying, and removing access based on least privilege and segregation of duties; restricting physical access to facilities and protected information assets; discontinuing access to physical assets only after data has been rendered unrecoverable; protecting against threats from outside system boundaries (boundary protection, firewalls, IDS/IPS); protecting data in transit through encryption and secure channels; and preventing, detecting, and remediating unauthorized or malicious software.
If your organization is going to invest engineering effort anywhere first, CC6 is where the ROI is highest — it maps almost one-to-one to identity and access management, network segmentation, encryption, and endpoint protection capabilities that a security platform can continuously monitor and evidence.
CC7 — System Operations
Covers detecting configuration changes that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities (CC7.1 — explicitly naming vulnerability scans "on a periodic basis and after significant changes"); monitoring system components for anomalies indicative of malicious acts (CC7.2); evaluating security events to determine whether they constitute incidents (CC7.3); executing incident response — containment, remediation, communication (CC7.4); and recovering from identified security incidents (CC7.5).
CC7 is where your vulnerability management program, your SIEM/detection capability, and your incident response process all converge — and where the evidence trail needs to show not just that tools exist, but that they're actively producing findings, that findings are triaged, and that incidents are resolved through a defined process.
CC8 — Change Management
A single, comprehensive criterion (CC8.1) covering the full change lifecycle: authorizing, designing, developing or acquiring, configuring, documenting, testing, approving, and implementing changes to infrastructure, data, software, and procedures. Points of focus explicitly call out patch management, baseline configuration, emergency change procedures, and segregation of duties in deployment (preventing a single individual from both developing and deploying a change unilaterally).
CC9 — Risk Mitigation
Covers risk mitigation activities for business disruption (CC9.1) and — significantly expanded in scope — assessing and managing risks associated with vendors and business partners (CC9.2). CC9.2 requires establishing requirements for vendor engagements, identifying vulnerabilities arising from vendor relationships, tiering and periodically assessing vendor risk, and having defined procedures for addressing issues and terminating vendor relationships when necessary. Third-party and supply chain risk is not a footnote in the TSC — it's a full criterion with extensive points of focus.
Two criteria series deserve special attention because they explicitly demand continuous, ongoing activity — not point-in-time documentation.
CC4.1's points of focus name "vulnerability scans, security assessment, penetration testing, and third-party assessments" as examples of the ongoing and separate evaluations required to determine whether controls are "present and functioning." CC7.1 requires detection and monitoring procedures to identify configuration changes that introduce new vulnerabilities and susceptibility to newly discovered vulnerabilities — with vulnerability scans performed "on a periodic basis and after significant changes are made to the environment," with action taken to remediate identified deficiencies in a timely manner.
Read that requirement carefully: it's not "scan once before the audit." It's continuous detection, triggered by change, with a documented remediation timeline — for the entire period your Type II report covers, which is typically 6 to 12 months.
A spreadsheet-and-screenshot approach to evidence collection cannot satisfy this. By the time your team manually compiles a scan report for the auditor, the environment has already changed, and the evidence reflects a moment that's weeks or months in the past. Your auditor, testing operating effectiveness across the full period, needs evidence that spans the whole window — not a snapshot from the week before fieldwork began.
Detection and response
The hypothesis to test is whether your evidence actually spans the full Type II period for CC4 and CC7, rather than reflecting a single pre-audit moment.
The evidence that confirms or rejects it is the criteria text itself. CC4.1 names vulnerability scans, security assessment, penetration testing, and third-party assessments as examples of ongoing and separate evaluations. CC7.1 requires vulnerability scans on a periodic basis and after significant changes, with action taken to remediate identified deficiencies in a timely manner. If your evidence set contains only a scan report compiled the week before fieldwork, it does not match what those criteria describe, and the operating effectiveness test across the full period will not be satisfied by it.
What to do
- Start with Security only, unless your customers require more. The Common Criteria alone satisfy the Security category — no additional category-specific criteria needed. Most first-time SOC 2 engagements should scope to Security and expand to Availability, Confidentiality, or Privacy only when a specific customer contract or business need requires it.
- Prioritize CC6 and CC7 for technical implementation. These two series carry the highest volume of testable, technical points of focus, and they're the ones most directly satisfiable by continuous security tooling rather than policy documents alone.
- Treat CC4's "ongoing and separate evaluations" as a literal requirement, not a suggestion. Your auditor will look for evidence of vulnerability scanning, security assessment, and (where applicable) penetration testing as a demonstrated practice — not a one-time event.
- Build CC9.2 vendor risk assessment into your onboarding process, not as an annual retrospective exercise. New vendor relationships should trigger a risk assessment at the time they're established.
- Automate evidence collection as a byproduct of operations, not a parallel documentation effort. The single biggest driver of SOC 2 preparation cost is manually reconstructing evidence after the fact. Every scan, every configuration check, and every remediation your security tooling performs should generate evidence automatically, mapped to the criterion it satisfies.
FAQ
Is the TSC a checklist of controls? No. It isn't a checklist of specific controls — it's an outcomes-based framework. Unlike NIST 800-53 or a prescriptive framework that tells you exactly which controls to implement, the TSC states what outcome your controls need to achieve and leaves the specific implementation to you. Your auditor exercises judgment in evaluating whether your specific implementation satisfies the criterion's intent.
What is the TSC built on? The TSC is built directly on the COSO Internal Control – Integrated Framework. The criteria align to COSO's 17 principles, organized into five components: Control Environment, Information and Communication, Risk Assessment, Monitoring Activities, and Control Activities. On top of the COSO principles, the TSC adds supplemental criteria specific to technology and security, organized into four areas: Logical and Physical Access Controls, System Operations, Change Management, and Risk Mitigation.
Which categories can a SOC 2 cover, and which one needs only the Common Criteria? A SOC 2 engagement can cover one or more of five categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only category built entirely from the Common Criteria — no additional category-specific criteria are needed. Every other category you include requires the Common Criteria plus the category-specific criteria for that category.
What do CC4 and CC7 actually require? CC4 maps to COSO Principles 16–17 and covers selecting and performing ongoing and separate evaluations of internal control, and evaluating and communicating deficiencies to responsible parties in a timely manner. Its points of focus explicitly name vulnerability scans, security assessments, and penetration testing. CC7 covers system operations: detecting configuration changes that introduce new vulnerabilities and susceptibilities to newly discovered vulnerabilities (CC7.1), monitoring for anomalies (CC7.2), evaluating security events (CC7.3), incident response (CC7.4), and recovery (CC7.5). CC7.1 requires vulnerability scans on a periodic basis and after significant changes, with timely remediation.
How long does the evidence need to cover? For the entire period your Type II report covers, which is typically 6 to 12 months. CC4 and CC7 demand continuous, ongoing activity rather than point-in-time documentation, so a snapshot from the week before fieldwork began does not span the window your auditor tests.
What does CC9.2 require for vendors? CC9.2 requires establishing requirements for vendor engagements, identifying vulnerabilities arising from vendor relationships, tiering and periodically assessing vendor risk, and having defined procedures for addressing issues and terminating vendor relationships when necessary. Third-party and supply chain risk is a full criterion with extensive points of focus, not a footnote.
What does CC8.1 cover? CC8.1 is a single, comprehensive criterion covering the full change lifecycle: authorizing, designing, developing or acquiring, configuring, documenting, testing, approving, and implementing changes to infrastructure, data, software, and procedures. Points of focus explicitly call out patch management, baseline configuration, emergency change procedures, and segregation of duties in deployment.