SOC 2 compliance for Terraform: mapping IaC to the Trust Services Criteria
Last reviewed: 2026-07-03 · 10 min read
14× AWS Certified · AWS Golden Jacket · AWS Community Builder · Ex-AWS Ambassador · KubeCon 2024 Speaker
Last reviewed: 2026-07-03
Of SOC 2’s nine Common Criteria, three are meaningfully expressible in Terraform: CC6 (Logical and Physical Access Controls), CC7 (System Operations / monitoring), and CC8 (Change Management). The rest — control environment, communication, risk assessment, risk mitigation — are organizational and procedural, and no amount of Terraform scanning will evaluate them. This guide maps each Terraform-expressible criterion to concrete HCL patterns, explains what scanners catch and miss per criterion, and is explicit about what static analysis cannot prove for an audit.
Which SOC 2 criteria Terraform can actually express
SOC 2’s Security category (the Common Criteria, required in every SOC 2 report) spans CC1 through CC9. Most teams researching “Terraform SOC 2 compliance” are really asking about the subset of those criteria that show up as infrastructure configuration rather than policy documents or governance process. That subset is CC6, CC7, and CC8 — covered in detail below. CC1–CC5 and CC9 matter for the audit but live in your control environment, risk register, and org chart, not your .tf files.
Logical and Physical Access Controls
Controls that restrict system access to authorized users and processes — identity, network boundary, and encryption controls.
Terraform patterns
aws_iam_policy / aws_iam_role least-privilege scoping, aws_security_group ingress rules, aws_s3_bucket_public_access_block, KMS encryption resources (enable_key_rotation, storage_encrypted), MFA enforcement via aws_iam_account_password_policy.
What scanners catch
Whether a specific attribute is set — encryption enabled, a security group rule open to 0.0.0.0/0, a wildcard IAM action on a single policy document.
What scanners miss
The effective permission set across multiple attached policies and trust relationships; whether a KMS key policy meaningfully restricts the account root; whether a "restricted" security group is still reachable through a peered VPC or a NAT path.
System Operations
Detection and monitoring controls — how the organization identifies anomalies and security events in the operating environment.
Terraform patterns
aws_cloudtrail (multi-region, log file validation), aws_guardduty_detector, aws_cloudwatch_metric_alarm, aws_flow_log, aws_config_configuration_recorder.
What scanners catch
Presence or absence of the monitoring resource block itself — is CloudTrail declared, is GuardDuty enabled, does a flow log exist for the VPC.
What scanners miss
Whether an alarm actually routes anywhere a human will see it (an SNS topic wired to zero subscriptions passes every static check), and whether log retention windows are long enough to cover the audit observation period.
Change Management
Controls over how changes to infrastructure and systems are authorized, tested, and deployed.
Terraform patterns
Remote state backend with locking (aws_dynamodb_table for state lock), branch-protected Terraform repositories, CI-gated terraform plan/apply pipelines.
What scanners catch
Little to nothing directly — this is primarily a process control. A scanner can confirm a state-locking table exists in Terraform, but not that your team actually requires PR review before merge.
What scanners miss
The entire human process layer: whether plans are actually reviewed, whether applies happen out-of-band from the pipeline, whether an emergency-change exception process exists and is followed.
What static analysis cannot prove for a SOC 2 audit
Being honest about this ceiling matters more than the mapping above. A Terraform review — whether it’s a rule-based scan or a contextual architectural pass — evaluates declared design, not observed operation. It can confirm that encryption is configured, that a security group is scoped correctly, that CloudTrail is declared with log file validation on. It cannot confirm that the deployed environment still matches that declaration six months later (drift), that nobody applied an emergency change outside the pipeline, or that the access review process CC6 also requires actually happened on schedule.
SOC 2 Type II compliance specifically requires evidence that controls operated effectively over an observation period — typically six to twelve months. That evidence is continuous: access logs, alert response records, change tickets. A point-in-time Terraform review supports the Type I design question and gives you a documented starting point for Type II evidence collection, but it is not itself that evidence.
This is the structural gap between two different tool categories. Compliance automation platforms collect runtime evidence — polling cloud APIs, capturing access logs, tracking policy acknowledgment — to prove controls operated over time. Terraform-level analysis answers a different, earlier question: is the control designed correctly before it’s ever deployed. Neither replaces the other, and conflating them is how teams end up surprised mid-audit.
How ArchGuard maps findings to SOC 2
Every finding in an ArchGuard report is tagged with the relevant control references from CIS AWS Foundations Benchmark v3.0, NIST 800-53, SOC 2, and PCI DSS — including the CC6/CC7/CC8 mapping described above where applicable. That turns a technical finding (“this S3 bucket lacks a lifecycle policy restricting public access”) into something your compliance lead or auditor can file directly against a specific criterion, instead of re-deriving the mapping by hand for every finding in the report.
Findings validated against your scanner output — see how ArchGuard triages Checkov and tfsec findings — carry the same compliance tags, so the SOC 2-relevant subset of your existing scanner output becomes audit-ready without a separate mapping exercise.
Frequently asked questions
Does using Terraform automatically satisfy SOC 2 requirements?↓
No. Terraform makes controls declarative and reviewable, which helps evidence collection, but SOC 2 compliance is a certification decision made by an accredited auditor after evaluating both design and — for Type II — operating effectiveness over an observation period. Terraform code shows what you intended to deploy; it doesn't prove what actually ran, for how long, or that nobody applied an out-of-band change.
What is the difference between SOC 2 Type I and Type II for IaC review?↓
Type I evaluates whether controls are designed correctly at a point in time — this is what a Terraform-level review can meaningfully support. Type II evaluates whether those controls operated effectively over a period (typically 6–12 months) — that requires continuous evidence (logs, access reviews, change records) that a one-time code review cannot produce on its own.
Which SOC 2 criteria can a Terraform scanner not evaluate at all?↓
CC1 (control environment — governance, tone at the top), CC2 (communication), CC3 (risk assessment process), and CC9 (risk mitigation policy) are organizational and procedural. They may be documented in runbooks or policies, but they are not expressed in infrastructure code and no static analysis tool — rule-based or contextual — can evaluate them from Terraform alone.
Can ArchGuard replace a SOC 2 audit or a compliance automation platform?↓
No. ArchGuard produces a technical evidence layer — it tells you which SOC 2-relevant controls your Terraform satisfies by design and which gaps exist, before an auditor or a runtime evidence-collection platform ever looks at your environment. The certification decision remains the auditor's, and operating-effectiveness evidence over time is a separate, ongoing exercise.
Updates and corrections
Last reviewed: 2026-07-03. SOC 2 Trust Services Criteria language is sourced from the AICPA TSC 2017 (revised 2022) framework. If you spot an outdated detail, email hello@archguard.io and we’ll correct it.
Get your Terraform mapped to SOC 2 before the audit
ArchGuard reviews your Terraform, validates your scanner findings, and maps every result to CIS, NIST 800-53, SOC 2, and PCI DSS — branded PDF in under 30 minutes.
See pricing