# Evidence Map: Which SOC 2 Controls Your Terraform Already Proves

Canonical: https://kaansystems.com/library/soc2-evidence-map
Topic: Platform · Published: 2026-10-29 · Updated: 2026-10-29
Summary: If your platform runs through Terraform and a gated pipeline, a good share of SOC 2 evidence already exists in your repo. This Evidence Map shows which controls it supports, what artifact to hand over, and where code stops and policy has to take over.

## Key takeaways

- Infrastructure-as-code with a gated pipeline produces evidence as a side effect: change records, policy scans, configuration baselines and drift reports.
- Change management (CC8.1) is the control Terraform supports most directly: every merged pull request records the proposal, review, plan and apply.
- Logical access, boundary protection, encryption and backup controls can be shown from code, provided the code is what's actually running.
- Code can't prove people controls: training, background checks, vendor reviews, risk assessments and incident response still need policy and records.
- Kaan is not an auditor. An independent CPA firm decides what evidence is sufficient; the map shows where your evidence already lives.

**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](/library/click-ops-to-terraform).

## 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:

1. **The pull request.** Who proposed the change, who reviewed it, the discussion, and the linked ticket if you use one.
2. **The plan and apply logs.** Exactly what changed, when, and by which pipeline identity.
3. **Policy scan results.** Checkov, tfsec or OPA output attached to each pull request, showing what was checked before merge.
4. **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](/library/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:

1. An engineer opens a pull request that tightens a security group rule.
2. CI runs `terraform plan` and posts the diff to the pull request. Policy checks run and pass.
3. A second engineer reviews the plan, not just the code, and approves.
4. Branch protection allows the merge only after the approval and the passing checks.
5. The pipeline applies using a federated, short-lived identity. The apply log records what changed and when.
6. 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](/library/infrastructure-drift-detection) covers how to make that check useful rather than noisy.

[Book a call →](https://cal.com/benrubert/30min?utm_source=library&utm_medium=article&utm_campaign=soc2-evidence-map&utm_content=middle)

## 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](/library/soc2-for-startups-complete-guide).

## What to do with the map

Use it to answer three questions about your own environment:

1. **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.
2. **Where is the exception path?** Who can still change production outside the pipeline, and how would you know?
3. **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](/library/reading-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](https://cal.com/benrubert/30min?utm_source=library&utm_medium=article&utm_campaign=soc2-evidence-map&utm_content=close).

**Related reading:** [Evidence pipelines 101](/library/evidence-pipelines-101) · [Detecting infrastructure drift](/library/infrastructure-drift-detection) · [Reading an enterprise security questionnaire](/library/reading-security-questionnaire) · [SOC 2 for startups](/library/soc2-for-startups-complete-guide)

## Frequently asked questions

**Q: Does Terraform make us SOC 2 compliant?**

No. SOC 2 is an attestation issued by an independent CPA firm, and many controls are about people, policy and process. Terraform and a gated pipeline make a large set of technical controls easier to evidence, because the configuration and its change history live in the repo.

**Q: Which SOC 2 control does infrastructure-as-code help with most?**

Change management, CC8.1. When every infrastructure change goes through a pull request with a posted plan, a required review and a pipeline apply, each change has its own record of who proposed it, who approved it and what changed.

**Q: Can an auditor accept a Terraform file as evidence?**

That's the auditor's call. Code shows intended configuration; pair it with proof that the code is what's running, such as a clean scheduled plan or drift report, and with the pipeline history showing how it got there.

**Q: What can't Terraform prove for SOC 2?**

Security awareness training, hiring and background checks, vendor management, risk assessment, board oversight, and the human side of incident response. Those need policies, records and owners.

Template: "One-page SOC 2 Evidence Map (Terraform + CI/CD)" — branded PDF at https://kaansystems.com/templates/soc2-evidence-map.pdf

Source: https://kaansystems.com/library/soc2-evidence-map · Work with Kaan Systems: https://kaansystems.com/contact