SOC 2 Type II Controls Engineers Actually Implement

Enterprise buyers now ask for SOC 2 Type II before they'll sign anything, and most vendors still treat that report like a paperwork problem. It is a paperwork problem in name only, not in reality. It's a set of technical controls that engineers have to build, wire up, and keep running for months at a stretch. Platforms like Vanta, Drata, and Sprinto will track your evidence and remind you what's overdue, but none of them will configure your IAM policies or write your Terraform. That part sits with engineering, full stop, and this piece walks through what each control category actually asks an engineer to do.

How the Trust Services Criteria map to engineering work

SOC 2 rests on five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Only Security, sometimes called the Common Criteria, is mandatory. Everyone gets audited against it. Everything else is a scope call your sales team and your engineering team need to make together, because each addition costs real build time down the line.

Security alone splits into nine sections, CC1 through CC9, with somewhere around 64 individual control points underneath them. Availability adds 3 more, and each additional criterion, Confidentiality, Processing Integrity, and Privacy, layers on further control points, multiplying the workload for whoever has to satisfy them. That jump matters. A startup that tacks on Privacy without a clear customer reason has just multiplied its own workload in a way most founders don't notice until the audit is already underway.

Most teams get the call wrong: they add scope to look thorough, when the actual move for an early-stage SaaS company is Security plus exactly one addition, and nothing more. Add Confidentiality if you're handling sensitive customer IP. Add Availability if your contracts carry real uptime SLAs. Skip Privacy and Processing Integrity unless a signed contract specifically demands them. Anything beyond that one addition is time spent building evidence nobody asked for.

Two sections carry most of the engineering weight. CC6, Logical and Physical Access Controls, is the largest single section with 8 control points. CC7, System Operations, covers incident response and vulnerability management across 5 points. Between them, these two sections eat most of a team's compliance hours.

The 2024 AICPA guidance sharpened what auditors expect to see, namely network and data flow diagrams that match the real infrastructure, an actual inventory of physical and virtual assets, and segregation of duties enforced inside the change process rather than described in a wiki page nobody reads. The framework itself didn't change. What changed is how hard auditors push on evidence: continuous risk assessment, closer vendor scrutiny, zero-trust access patterns, and reports with more granular detail than they carried a few years back.

Scoping the boundary before writing a single line of Terraform

The single most expensive mistake in a first SOC 2 audit is scoping too wide. Pulling every AWS account, every environment, and every internal tool into scope adds weeks of control work and months of evidence collection for systems that never touch customer data to begin with.

Run every system through four questions. Does it store, process, or transmit customer data? Does it affect the availability of anything customer-facing? Does it hold production credentials? Could a compromise of this system lead to a customer data breach? One yes and it's in scope, no exceptions, no "well, technically."

For most companies, the right boundary lands on the production AWS account, the production cluster, and the production database. Staging, dev, and internal tooling sit outside, but that only holds if it's proven outside through technical controls, not a sentence in a policy doc claiming separation exists.

Network segmentation is that proof. Without it, an auditor has no reason to believe your out-of-scope dev environment can't reach production. The usual mechanism is a network access control rule that blocks inbound traffic from non-production IP ranges into the production VPC, paired with the deliberate absence of VPC peering between environments, documented as its own control. A Terraform block like aws_network_acl.deny_non_production, with a comment noting there's no peering path, is exactly the kind of artifact an auditor wants, because it shows intent rather than accident.

If staging can query the production database, staging is in scope, no matter what the architecture diagram says. The diagram doesn't enforce anything. The firewall rule does.

Access controls: the 8-point CC6 section in practice

CC6 rests on four pillars, and each one turns into concrete infrastructure work.

Role-based access control comes first: documented roles like Developer, Support Engineer, and Finance, each with a written list of what that role can actually touch. Least privilege comes next, and auditors will pull your IAM console and compare the permissions written down against what's actually granted. Those two lists rarely match on the first pass. Then MFA, required on every system that touches production, no exceptions carved out for "internal tools." And segregation of duties: the engineer who wrote the code can't also be the only person who approves it going to production.

Quarterly access reviews are the baseline cadence for anyone with privileged or production access. Auditors want records, not memory, including who was in the reviewed population, who did the review, what got decided, the date it happened, and proof that anything flagged for removal actually got removed.

Four gaps appear repeatedly across these audits. Shared credentials show up as one root AWS password passed between co-founders, a shared service account key sitting in CI/CD, and a database password living in a .env file half the team has a copy of. No MFA on CI/CD systems: GitHub accounts without it, Jenkins reachable with just a username and password, ArgoCD with no SSO tied in. Manual deployments: someone logging into a production box remotely, kubectl apply run straight from a laptop, database migrations typed by hand. And no logging retention policy, where logs rotate out after a short window and nothing's centralized anywhere.

IBM's Cost of a Data Breach report found that 97% of AI-related breaches happened at organizations without proper AI access controls in place. That number says something uncomfortable: the riskiest companies aren't running the most complicated stacks. They skipped the fundamentals, and the fundamentals are what CC6 exists to force.

Encryption falls under CC6.7, and the bar itself isn't complicated: AES-256 at rest, TLS 1.2 or higher in transit. Where teams actually fail is key management, not encryption. Keys sitting next to the data they're supposed to protect, or a rotation policy that exists on paper but hasn't run in two years. The fix is a managed KMS (AWS, GCP, and Azure all offer one) with automated annual rotation and a written policy that matches what's actually configured, not what someone meant to configure.

Change management as a control: what CC8.1 requires from engineers

CC8.1 says every infrastructure change needs to go through a defined, authorized process. An auditor isn't checking whether the change was good. They're checking whether the process that governed it can be reconstructed after the fact, and those are two very different questions.

A Terraform pull request with a peer reviewer and a CI/CD apply log answers that second question about as cleanly as it can be answered. A change made straight in the AWS console, with no commit anywhere, breaks the chain entirely, even when the change itself was harmless. One direct console edit is enough to create a finding, so running through CloudTrail logs before the audit window opens, hunting for anything that bypassed the pipeline, pays for itself.

Getting infrastructure-as-code to function as an actual control means locking down three things. Remote state first: Terraform state sitting on someone's laptop is a finding waiting to happen, so state belongs in S3, versioned, with access limited to the CI/CD role and nobody's personal credentials. Drift detection second: owning Terraform doesn't mean you're drift-free, so a scheduled terraform plan in CI that raises an alert on any non-empty diff gives auditors something concrete to point to. Third, policy as code: rules like "no public S3 buckets" or "disk encryption required" written as code and enforced inside the pipeline, so a SOC 2 requirement fails a build automatically instead of relying on someone to remember it.

Checkov, built by Bridgecrew and now part of Palo Alto Networks' Prisma Cloud, ships with over a thousand built-in checks mapped against CIS benchmarks, NIST, HIPAA, PCI DSS, and SOC 2 itself. Wiring it into CI catches a bad configuration before it ever reaches production, which is a far cheaper place to catch it than during fieldwork six months later.

The chain that actually works: Checkov in CI stops misconfigurations before they ship, Security Hub watches what does ship, and Vanta, Drata, or Sprinto turns all of it into a continuous record an auditor can review. Gartner's Hype Cycle for Cloud Security projected that more than 99% of cloud breaches through 2025 would trace back to preventable misconfigurations, and found that 74% of organizations had a storage bucket exposed to the public at some point. CC8.1 exists to force exactly the discipline that closes that gap.

Logging, monitoring, and patch management: the CC7 controls that run continuously

CC7.1 and CC7.2 cover what has to get logged and how those logs stay protected. Authentication events, authorization changes, privilege grants and revocations, resource usage: all of it needs to land somewhere centralized. Log integrity gets tested as its own control, not treated as an afterthought: clocks synced through NTP, logs hashed or written to an immutable, write-once store, strict limits on who can modify or delete anything. Collection, storage, and analysis should sit with different roles, because one role holding the power to write and delete logs defeats the entire point of keeping them.

CC7.3 covers patch management, and auditors don't stop at a policy document. They pick specific CVEs published during the audit window and confirm each one got patched inside the stated SLA. The usual tiers: critical within 30 days, high within 60, medium within 90. Vulnerability scanning across endpoints and production, using something like Qualys, Tenable, or Wiz, is what generates the evidence trail auditors actually pull from. Container environments that sign images through Docker Content Trust or Sigstore satisfy the "only approved software runs" requirement at the infrastructure layer, a cleaner answer than trying to prove the same thing through process alone.

CC7.4 and CC7.5 cover incident response, and a plan that's never run through a tabletop exercise isn't a plan, functionally speaking. Auditors ask for dated tabletop records with named participants and documented findings, plus post-incident reviews for anything that actually happened during the observation window. NIST SP 800-61 is the template most teams build from.

IBM's 2025 report put the global average breach cost at a substantial figure, down thanks largely to automated detection. But breaches involving AI tools still cost companies in one country an average of $10.22 million. That gap is roughly the distance between a team running formal controls and a team improvising.

Platforms that run inside the customer's own cloud account, instead of a shared multi-tenant environment, make CC7's continuous monitoring dramatically easier to pull off. CloudTrail, GuardDuty, Security Hub, and Config all operate natively at the account boundary, and their output already looks like audit evidence without anyone reformatting it.

What auditors sample and why the evidence format matters more than teams expect

Two mistakes account for most first-time audit exceptions. Access reviews that genuinely happened but were never saved anywhere an auditor could find them. And change approvals that lived entirely in a Slack thread instead of a ticketing system with a paper trail.

Evidence that survives an audit is self-explanatory, time-stamped, and versioned. Someone with zero context should be able to open it and immediately know what happened, when, who signed off, and what came of it. If that takes an explanation from the person who filed it, the evidence has already failed.

Watch the observation period trap closely. If branch protection got turned on July 1st but the audit window started January 1st, that's a six-month gap an auditor will flag without hesitation. Observation windows vary, and the length matters: any gap between the window start and when a control was actually implemented is a gap an auditor will flag.

Each control domain has its own expected evidence shape. Access controls need review records (who was reviewed, who reviewed them, the decision, the date, proof of remediation), MFA screenshots, RBAC mappings, and IAM policy exports. Change management needs pull requests with approval trails, CI/CD apply logs, Terraform state, AWS Config compliance history, and CloudTrail, together forming a continuous record that changes stayed authorized all year. Logging and monitoring need centralized log samples, proof of NTP sync, alert records, and incident timelines. Vendor management needs due diligence questionnaires, signed contracts, risk scores, and copies of vendor SOC 2 reports on file.

Segregation of duties gets tested directly, never assumed from a policy statement. Auditors check that the engineer who wrote a piece of code wasn't also the sole approver who shipped it. Any change missing an approval trail becomes a finding on the spot, no matter how small the change was.

The fix is process: a ticketing system with an enforced workflow, automated testing wired into CI/CD, and a CMDB or IaC state that tracks configuration as a byproduct of normal engineering. In 2025, 58% of organizations ran four or more audits, and 35% ran more than six. Evidence collection has stopped being a once-a-year fire drill. It runs all year, the same way a monitoring dashboard does.

AI and ML workloads introduce control gaps the standard framework doesn't explicitly name

By 2026, auditors examining AI startups are pushing hard on CC9.2, and infrastructure controls alone won't satisfy them anymore. They want risk mitigation for how a model behaves over time, since drift, retraining cycles, and dependence on third-party LLM providers create risk that a firewall rule or an IAM policy was never built to touch.

Four areas appear consistently in these audits. Model drift monitoring: defined thresholds, alerts when performance moves outside them, a set review cadence, treated with the same seriousness as uptime monitoring on a production API. Training data provenance: where the data came from, who approved using it, how it's protected, with a record an auditor can trace back to source. Retraining and model change management, tracking model versions with the same rigor a deploy pipeline tracks a code release, so a model swap with no review trail counts as an unauthorized production change, the same as an unreviewed database migration. And oversight of third-party LLM providers, since a vendor's model behavior becomes an inherited risk the moment it's built into a customer-facing product.

None of this replaces CC6 or CC7. It sits on top of them, because access controls and change management still govern the infrastructure a model runs on. AI just adds a layer the original framework never had to name, written as it was before model behavior itself became something worth auditing.