The AICPA Trust Service Criteria are sometimes treated as abstract compliance requirements — policy statements to be documented and satisfied on paper. CC6.1 requires that logical access is restricted to authorized users. CC7.2 requires that environmental threats are monitored. These read like governance language, not engineering requirements.
But every TSC maps to observable, testable state in your production systems. The mapping between a criterion and its observable evidence is not theoretical — it's a set of specific API calls, configuration checks, and log queries against systems you're already running. This piece walks through the most operationally significant mappings for a cloud-native SaaS company using AWS, GitHub, and Okta as their primary infrastructure layer.
CC6.x: Logical and Physical Access Controls
The CC6 family covers logical access — who has access to what, under what conditions, and how that access is authorized and de-provisioned. For most SaaS companies, this is the highest-density control category in terms of evidence volume and the area where drift is most common.
CC6.1 — Logical access to systems restricted to authorized users — maps primarily to your identity provider and the downstream systems it governs. In Okta terms, the observable state includes: the complete user list, which users are active versus suspended, which groups each user belongs to, and which applications are assigned to each group. In AWS, the observable state is the set of IAM users, roles, and policies — specifically, which principals have access to which resources across each account in scope. In GitHub, it's organization membership and team assignment, including which teams have write or admin access to which repositories.
The test against CC6.1 is whether every active user in each system can be traced to an active employee or authorized service account, and whether every privileged assignment can be traced to an approved authorization workflow. Drift — a user who left the company three months ago but still has active GitHub access, or a role with admin privileges that was attached during a one-time incident response and never removed — is the failure mode this criterion is designed to catch.
CC6.3 — Access removal upon termination or role change — has a temporal component that makes it distinctly harder to evidence than CC6.1. It's not enough to show that terminated users don't currently have access. The criterion requires evidence that access was revoked promptly upon termination. This means the evidence needs to include timestamps: when did the user leave, and when was their access removed? For Okta, the observable evidence is the user's deactivation timestamp relative to the HR offboarding event. For AWS and GitHub, it's the policy detachment or membership removal timestamp.
CC6.6 — Transmission of data between systems — covers data in transit protections. For a SaaS company, the observable evidence includes TLS configuration for all external endpoints (verifiable via certificate inspection), internal service communication encryption configuration (visible in AWS security group rules, ALB listener configurations, and service mesh policies), and evidence that unencrypted transmission protocols are not in use. API gateway configurations and CloudFront distributions are primary evidence sources.
CC7.x: System Operations and Monitoring
The CC7 family covers operational security — how you detect and respond to threats, how you monitor system behavior, and how you manage vulnerabilities. This is where your security tooling generates most of its evidence.
CC7.1 — Detection of vulnerabilities and threats — maps to your vulnerability scanning program. The observable evidence is not just a current scan result — it's a record demonstrating that scanning occurred throughout the observation period, that vulnerabilities were identified, and that remediation followed within policy timelines. For a team using AWS Inspector or a third-party vulnerability scanner, the evidence is the scan execution log covering the 12-month observation period, the vulnerability findings, and the corresponding remediation tickets showing closure dates.
CC7.2 — Environmental threats are monitored — maps to your security monitoring configuration. AWS GuardDuty findings, CloudTrail log retention and alerting configuration, and your SIEM or log aggregation setup are the primary evidence sources. The test is whether your monitoring configuration was active and generating alerts throughout the observation period, and whether identified threats were triaged and responded to.
CC7.4 — Security incidents are identified and responded to — maps to your incident response record. The observable evidence is the incident log: tickets, Slack threads or similar records, and resolution documentation. The criterion doesn't require that you had zero incidents — it requires that you had a process, that incidents were identified through that process, and that they were responded to in a documented way. For most compliance auditors, the absence of any security incidents in a 12-month record is more concerning than a well-documented incident log, because it suggests the monitoring program may not be generating actionable signal.
CC8.x: Change Management
CC8.1 — Changes to infrastructure are authorized, tested, and deployed through a defined process — is where the mapping between compliance and engineering workflow is most direct. The observable evidence for this criterion is your deployment pipeline configuration and your change ticket record. For a team using GitHub with branch protection rules, required reviewers, and Jira or Linear for change tracking, the evidence is: that every production deployment was associated with a reviewed and approved change ticket, that the branch protection configuration was active throughout the observation period (visible in GitHub API), and that emergency changes were documented with appropriate post-hoc approval.
A practical note on CC8.1 evidence: the most common gap we see is not in the change management process itself but in the linkage between deployment events and change tickets. Teams often have both the deployment records and the change tickets, but no automated link between them. Demonstrating the link manually — identifying the deployment timestamp, finding the corresponding change ticket, showing the approval — scales poorly when an auditor asks for a sample of 30-50 changes from across the 12-month observation period.
A1.x and C1.x: Availability and Confidentiality
A1.1 — Performance and availability monitoring — maps to your uptime monitoring and SLA record. For AWS-hosted services, the observable evidence is CloudWatch metrics, alarms, and dashboards showing availability metrics over the observation period, incident records for any availability events, and evidence that capacity planning and load testing occurred. Third-party uptime monitoring records (if you use an external synthetic monitoring service) provide an independent corroboration of availability claims.
C1.1 — Confidentiality of customer data — maps to multiple layers: encryption at rest configuration for all data stores (S3 bucket encryption policies, RDS encryption settings, Snowflake or other warehouse encryption configuration), network-level isolation (VPC configuration, security groups restricting database access), and access logging for systems containing customer data. For companies subject to GDPR or CCPA alongside SOC 2, this criterion also intersects with data classification and retention policies that need to be demonstrably implemented, not just documented.
The mapping exercise in practice
For a team beginning the process of building a production-connected control evidence program, the practical starting point is a control-to-system matrix: for each in-scope TSC criterion, identify the primary system(s) that hold observable evidence for that criterion, the specific data fields or API endpoints needed, and the expected state (what does "passing" look like for each test).
This exercise typically surfaces several categories of gaps. Some controls are adequately monitored but the evidence isn't being retained in a format that's easy to produce for an auditor. Some controls are genuinely not being tested — nobody is regularly checking whether all GitHub organization members are current employees, for example, because that check requires cross-referencing the GitHub API against an HR system. And some controls exist on paper (the policy says changes must be linked to approved tickets) but the observable evidence shows the process isn't being followed consistently.
The distinction that matters here is between policy compliance and control state. Your policy says what should be true. Your observable production state shows what is actually true. SOC 2 Type II auditors are evaluating the latter — and a well-constructed control mapping exercise shows you the gap between the two before your auditor does.
We're not suggesting that the mapping exercise is a substitute for engaging a qualified auditor or GRC consultant to scope your SOC 2 program. The AICPA Trust Service Criteria have nuances that require professional interpretation, and the right scoping decisions for your specific business and service commitments require judgment that goes beyond a technical systems mapping. The production-level mapping described here is one layer of your overall program — specifically, the layer that determines whether your controls are operationally real, not just documented as policies.