Which SOC 2 controls can your Terraform prove? If your infrastructure runs through Terraform and a gated CI/CD pipeline, your repo already holds evidence for change management (CC8.1), much of logical access and boundary protection (CC6), configuration monitoring (CC7), and parts of availability (A1). It can’t prove the people and policy controls. The Evidence Map below shows which is which.
One note before the map: Kaan Systems is not an auditor. An independent CPA firm audits SOC 2 and decides what evidence is sufficient. What we can do is show you where your evidence already lives, and where it doesn’t.
Why evidence becomes a platform problem
The first SOC 2 audit often turns into a screenshot hunt. Someone opens the console, captures the security group rules, the encryption settings and the IAM policies, pastes them into a folder and hopes nothing changed afterward. Then the auditor asks for a sample of changes from the observation period, and the hunt starts again.
Screenshots show a moment. Auditors care about a period. That’s the gap infrastructure-as-code closes: when configuration lives in code and changes go through a pipeline, the record covers the whole period by default.
This isn’t a reason to adopt Terraform. Faster environments, safer changes and fewer surprises are. Evidence is the outcome you get for free once the platform is in code. If you’re not there yet, start with from click-ops to code.
The four artifacts that do most of the work
Nearly every row in the map comes back to four artifacts a well-run Terraform setup produces:
- The pull request. Who proposed the change, who reviewed it, the discussion, and the linked ticket if you use one.
- The plan and apply logs. Exactly what changed, when, and by which pipeline identity.
- Policy scan results. Checkov, tfsec or OPA output attached to each pull request, showing what was checked before merge.
- Scheduled drift reports. Proof that what’s running still matches the code, between changes.
Branch protection ties them together. If the default branch requires a review and a passing pipeline, and only the pipeline can apply, then the pull request history is your change log. We go deeper on capturing and storing these in evidence pipelines 101.
The Template
The Evidence Map
One-page SOC 2 Evidence Map for a platform that already runs through Terraform and a gated pipeline. Trace each control to the artifact the repo produces. “Strong for configuration” means the code shows intent; a clean drift report is what shows that intent is running. An auditor decides whether that is sufficient.
| SOC 2 area | What the auditor wants to see | Where it lives in Terraform and CI/CD | Coverage |
|---|---|---|---|
| CC8.1 Change management | Changes are authorized, tested, approved and implemented in a controlled way | PR history with required review, posted plan, pipeline apply logs, branch protection settings | Strong |
| CC6.1 Logical access | Access to infrastructure is restricted; encryption protects data | IAM roles and policies in code; KMS or Key Vault keys and encryption settings on storage and databases | Strong for configuration |
| CC6.2 / CC6.3 Granting and removing access | Access is approved, role-based and removed when no longer needed | Group and role membership in code (if managed there); PR history of grants and removals | Partial: identity provider and HR offboarding records still needed |
| CC6.6 Boundary protection | Network access from outside is restricted | VPC/VNet design, security groups, firewall rules, private endpoints, WAF in code | Strong |
| CC6.7 Data in transmission | Data is protected in transit | TLS policies on load balancers, cert-manager or managed certificates, HTTPS-only settings | Strong for configuration |
| CC6.8 Unauthorized software | Changes to software are controlled | Pinned images and versions, pipeline-only deploys, image scanning in CI | Partial |
| CC7.1 Detecting configuration changes | Configuration changes and vulnerabilities are detected | Scheduled drift reports, policy-as-code scans, config monitoring enabled in code | Strong |
| CC7.2 Monitoring | System components are monitored for anomalies | Audit logging (CloudTrail, Activity Log, Cloud Audit Logs), alerting and log retention in code | Partial: someone still has to respond |
| A1.2 Backup and recovery infrastructure | Backups and recovery infrastructure exist | Backup policies, retention, replication and snapshot schedules in code | Strong for configuration |
| A1.3 Recovery testing | Recovery plans are tested | Ability to rebuild an environment from code; DR test runbooks and results | Partial: the test itself must happen and be recorded |
| CC1–CC5, CC9 Governance, risk, people, vendors | Oversight, risk assessment, training, vendor management | Not in Terraform | None: policy and records |
“Strong for configuration” is an important qualifier. Code shows what you intended. A clean drift report shows that intent is what’s running. Auditors will want both, and how much they accept is their decision.
Tracing one control: CC8.1, end to end
Here’s what a single infrastructure change looks like as evidence when the pipeline is set up well:
- An engineer opens a pull request that tightens a security group rule.
- CI runs
terraform planand posts the diff to the pull request. Policy checks run and pass. - A second engineer reviews the plan, not just the code, and approves.
- Branch protection allows the merge only after the approval and the passing checks.
- The pipeline applies using a federated, short-lived identity. The apply log records what changed and when.
- The next scheduled drift check comes back clean, showing production matches the merged code.
When the auditor samples changes from the observation period, each sample is a link to a pull request. No screenshots, no reconstruction from memory.
The weak spot is the exception path. If engineers can still change production from the console, the auditor will ask how those changes are controlled. A documented break-glass process, plus drift detection that catches anything done outside the pipeline, is what closes that gap. Our article on detecting infrastructure drift without drowning in alerts covers how to make that check useful rather than noisy.
Where code stops
Being honest about the limits matters, because overclaiming is how teams get surprised mid-audit. Terraform does not prove:
- That employees completed security training or background checks
- That vendors were reviewed
- That a risk assessment happened and leadership acted on it
- That someone actually responded to an alert, or that an incident was handled according to your plan
- That a quarterly access review happened, unless you export and sign off on it
Some of these can be helped by automation, such as exporting access lists from code every quarter for a reviewer to sign. But the control is the human review, not the export. For the wider picture, see our SOC 2 for startups readiness guide.
What to do with the map
Use it to answer three questions about your own environment:
- Which rows are “Strong” in theory but not in practice? For example, IAM is in code, but half the roles were created in the console.
- Where is the exception path? Who can still change production outside the pipeline, and how would you know?
- Which rows need a person, not a pipeline? Assign an owner to each.
The answers also help with enterprise security questionnaires, which ask many of the same questions in different words. Reading an enterprise security questionnaire shows how to map those questions back to evidence you already have.
Get your own Evidence Map
Every Terraform & Platform Assessment includes a one-page Evidence Map for your environment: which SOC 2 and HIPAA controls your infrastructure-as-code and pipelines already support, and which they don’t. It comes alongside a findings report ranked P0/P1/P2, cost quick wins and a 90-day roadmap. It takes 7 business days with read-only access, and is credited 100% toward a retainer signed within 60 days. Book a call to get started.
If you want the evidence to keep flowing after that, our Compliance Evidence add-on keeps policy scans, change records, drift reports and access-review exports flowing into Vanta, Drata, Secureframe or an evidence bucket every month. Your auditor still decides what’s sufficient; we make sure the evidence is there when they ask. Book a 15-minute call to talk through fit — we don’t publish add-on pricing. Book the Terraform & Platform Assessment.
Related reading: Evidence pipelines 101 · Detecting infrastructure drift · Reading an enterprise security questionnaire · SOC 2 for startups