SOC 2 Trust Services Criteria: CC6, CC7, CC8, A1 Explained

This is the criterion-by-criterion reference companion to our SOC 2 infrastructure checklist — read the checklist first if you want the ordered task list; read this when an auditor cites a specific criterion and you need to know what satisfies it. SOC 2 controls are written in auditor language, but almost every one resolves to a concrete infrastructure change you can ship in a sprint. The mapping that matters for a startup: CC6 (access) → SSO, MFA, and least-privilege IAM; CC7 (operations) → centralized logging, alerting, and incident runbooks; CC8 (change management) → reviewed pull requests and controlled deploys; A1 (availability) → automated backups, tested restores, and a DR plan. The criteria describe outcomes, not tools — the same mapping works on AWS, GCP, and Azure. Below is each area translated into the actual work.

How are SOC 2 controls actually organized?

SOC 2 audits test against the AICPA’s Trust Services Criteria — the 2017 framework, with points of focus revised in late 2022 to address things like patch management and vendor vulnerabilities (the criteria themselves didn’t change). The Security category is mandatory in every SOC 2 and contains the nine Common Criteria: CC1–CC5 cover governance (policies, risk assessment, monitoring of controls), while CC6 (logical and physical access), CC7 (system operations), CC8 (change management), and CC9 (risk mitigation) are where infrastructure work lives. Availability (A1), Confidentiality, Processing Integrity, and Privacy are optional add-on categories — most SaaS startups scope Security plus Availability, sometimes Confidentiality.

One nuance: your auditor tests your controls, not a fixed checklist — you (or your compliance platform) write the control language, and the criteria are what those controls must collectively satisfy. The mapping below is a strong default, not the only valid one.

What infrastructure changes satisfy CC6 access controls?

CC6 asks how you restrict logical and physical access, how you grant and revoke it, and how you prevent unauthorized access. For a cloud-native startup, physical access is mostly inherited from your cloud provider’s own SOC 2 — your work is the logical half. The three changes that clear most CC6 controls: SSO everywhere, MFA enforced at the identity provider, and least-privilege IAM roles instead of shared credentials.

CC6 asks for	The infrastructure change	Evidence the auditor sees
Restrict access to authorized users	SSO (Google Workspace, Okta, Entra ID) in front of cloud consoles and internal tools	IdP app list, IAM identity-provider config
Authenticate users appropriately	MFA enforced at the IdP; no long-lived cloud access keys	MFA enforcement policy, credential report
Least privilege	Role-based IAM (AWS IAM roles, GCP IAM, Azure RBAC), no wildcard admin for daily work	Role definitions in Terraform, access review records
Timely revocation	Offboarding through the IdP — one deactivation kills all downstream access	Offboarding tickets matched to deactivation timestamps
Protect data in transit and at rest	TLS on every endpoint; default encryption on databases, buckets, disks	Config screenshots or IaC, TLS scan output

The structural trick is centralizing identity: when every system hangs off the IdP, quarterly access reviews and offboarding evidence become one export instead of twelve — the single highest-leverage change on this whole mapping.

What does CC7 mean for monitoring and incident response?

CC7 covers system operations — how you detect and respond to anomalies, security events, and processing failures. In infrastructure terms that’s three deliverables: centralized logs with retention, alerting that pages a human, and written incident runbooks you’ve actually used. The 2022-revised points of focus also lean on patch management here, so this bucket includes a story for how vulnerable packages get updated.

CC7 asks for	The infrastructure change
Detect anomalies and security events	Centralized logging (CloudWatch, Cloud Logging, Azure Monitor, or a Grafana/Loki stack) with 90+ day retention as a common norm
Monitor infrastructure and capacity	Metrics and dashboards — Prometheus and Grafana or the cloud-native equivalent
Respond to incidents	On-call alerting (PagerDuty, Opsgenie, or even a paging Slack channel with escalation), plus a written incident-response runbook
Learn from incidents	Lightweight postmortems filed where the auditor can sample them
Manage vulnerabilities	Automated dependency updates, image scanning, a patch cadence you can describe

Auditors sample here: “show me an alert that fired in March and what happened next.” A monitoring stack that exists but never pages anyone fails the spirit of CC7 even if the dashboard looks great.

What does the Availability category (A1) require?

A1’s three criteria translate cleanly: A1.1 is capacity management (you monitor and plan for load — autoscaling groups or Kubernetes HPA plus capacity alerts), A1.2 is backup and recovery infrastructure (automated backups, environmental protections — again mostly inherited from the cloud provider — and recovery tooling), and A1.3 is testing your recovery plan. A1.3 is the one startups fail in practice: nightly RDS snapshots satisfy A1.2, but if you’ve never restored one, you have no evidence for A1.3. Schedule a restore test quarterly and record it — one ticket with screenshots is enough. If your infrastructure is in Terraform, your DR story gets dramatically shorter, because “rebuild the environment” is a command, not a wiki page.

Where do CC8 and the rest fit?

CC8 (change management) asks that changes are authorized, tested, and controlled — for a startup that’s branch protection, required PR review, CI checks, and deploys through a pipeline rather than SSH. If you already do infrastructure-as-code with reviewed applies, CC8 is largely done. CC9 (risk mitigation) and CC1–CC5 are mostly policy and process — your compliance platform’s templates carry the load there, and automating the evidence collection keeps them from becoming a quarterly fire drill.

What order should you do the work in?

Identity first (CC6), because everything else generates cleaner evidence once access is centralized; then logging and alerting (CC7), because retention windows mean the clock matters; then backups plus a restore test (A1); then formalize change management (CC8). That sequencing also fits how Type I and Type II audits differ — a Type II observation window rewards controls that have been running longest. For the full control-by-control gap assessment, run our SOC 2 infrastructure checklist against your cloud, and if you’d rather have the whole thing scoped, built, and evidenced in weeks instead of quarters, that’s exactly what our SOC 2 infrastructure package covers — see pricing for what an audit-prep engagement looks like.

This is engineering guidance, not legal or audit advice — confirm scoping decisions with your auditor.