The Trust Services Criteria, Decoded: What SOC 2 Actually Asks of You

"We need a SOC 2 report" is usually the first sentence in a compliance project and the last thing anyone fully explains. Underneath that single acronym sits a structured, COSO-aligned framework of criteria, points of focus, and category-specific requirements that your auditor will test line by line — not once, but continuously, for the entire period your Type II report covers.

If you're heading toward your first SOC 2 examination, or trying to understand why your existing one takes months to prepare for every year, this post breaks down what the AICPA's Trust Services Criteria (TSC) actually contain, how the five trust services categories fit together, and how continuous security platforms like Trusteed turn the criteria from an annual scramble into an always-current evidence stream.

---

What the Trust Services Criteria Actually Are

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.

---

The Five Trust Services Categories

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.

---

Inside the Common Criteria: CC1 Through CC9

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.

---

Why CC4 and CC7 Are the Hardest to Satisfy Manually

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.

---

How Trusteed Maps to the Trust Services Criteria

This is the exact gap that Trusteed's continuous CTEM platform is built to close — generating the kind of ongoing, evidence-backed operation that CC4, CC6, CC7, and CC8 actually require, rather than a compliance artifact assembled after the fact.

CC4 and CC7: Continuous Monitoring, Not Periodic Snapshots

Trusteed's vulnerability scanner runs daily auto-scans and triggers additional checks the moment an asset or configuration changes — directly satisfying CC7.1's "periodic basis and after significant changes" language with evidence that spans your entire audit period, not a scan scheduled the week before fieldwork. Every finding is timestamped, prioritized by exploitability and business context, and tracked through to remediation — producing exactly the "action taken to remediate identified deficiencies in a timely manner" evidence CC7.1 demands. This same continuous scanning activity is the "ongoing and separate evaluation" CC4.1 explicitly names as satisfying its monitoring requirement.

CC6: Access, Boundary Protection, and Malicious Code Controls

CC6's eight sub-criteria map closely to what Trusteed's cloud security and vulnerability scanning platform continuously verifies: IAM policy misconfigurations that violate least-privilege (CC6.1, CC6.3), boundary protection gaps like overly permissive security groups (CC6.6), encryption enforcement for data at rest and in transit (CC6.1, CC6.7), and detection of unauthorized changes to software and configuration (CC6.8). Where CC6 asks whether access is "restricted... based on roles, responsibilities... giving consideration to the concepts of least privilege and segregation of duties," Trusteed's continuous cloud configuration checks generate the evidence that answers it — automatically, every day, not just at audit time.

CC7.4 and Incident Response Evidence

For the incident handling and communication requirements in CC7.4, Trusteed's finding-to-ticket workflow — auto-generating tickets with evidence, remediation guidance, and severity in Jira, ServiceNow, or your existing tools — creates the documented containment, remediation, and communication trail CC7.4's points of focus require, tied directly to the underlying technical finding rather than a manually reconstructed narrative.

CC8: Change Management Evidence Through Testing and Verification

CC8.1 asks whether changes are tested before implementation and whether patches are managed on a timely basis. Trusteed's DAST and vulnerability re-testing capability — triggering scans on deploy and automatically verifying that remediated findings are actually fixed — produces direct evidence of both: pre-deployment testing coverage and timely patch verification, closing the loop that CC8.1's "manages patch changes" point of focus requires.

CC9.2: Vendor and Third-Party Risk

CC9.2's extensive vendor risk requirements — identifying vulnerabilities arising from vendor relationships and assessing third-party risk on a periodic basis — extend naturally to your own external attack surface. Trusteed's asset discovery surfaces third-party integrations, vendor-connected infrastructure, and supply-chain-adjacent exposures that a manual vendor questionnaire process typically misses.

Auditor-Ready Evidence Across the Full Period

Because Trusteed's scanning, monitoring, and remediation-tracking operate continuously rather than on a pre-audit schedule, the evidence it generates naturally spans your entire Type II examination period. Instead of assembling documentation retroactively — trying to reconstruct what your environment looked like six months ago — you export a continuous evidence trail that already exists, mapped to the specific criteria it satisfies, ready for your auditor's testing.

---

A Practical Path Through the TSC

If you're scoping a SOC 2 engagement or trying to make an existing one less painful, here's where to focus.

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.

---

Compliance That Matches How the Criteria Actually Read

The Trust Services Criteria were never designed to be satisfied by a folder of screenshots assembled the week before an auditor arrives. Read closely, CC4 and CC7 explicitly demand ongoing, continuous evaluation — vulnerability scanning after every significant change, monitoring for anomalies, timely remediation, evidence spanning the full examination period.

A continuous security platform doesn't change what the TSC asks for. It changes whether you can actually produce evidence that matches the standard the criteria were written to — evidence that exists because your security operations generate it every day, not because someone spent three weeks in March reconstructing what happened in September.

---

Ready to generate SOC 2 evidence continuously instead of retroactively? Start scanning for free or talk to an expert to see how Trusteed maps continuous security operations to the AICPA Trust Services Criteria.

---

This post was published on the Trusteed Blog. Trusteed provides always-on agentic CTEM — continuous vulnerability scanning, cloud configuration monitoring, and automated remediation verification — helping organizations generate SOC 2, ISO 27001, and HIPAA evidence continuously rather than assembling it retroactively before each audit.