CIS Compliant Terraform Modules
Enforced Before terraform apply

Level 1 and Level 2 Benchmark recommendations for AWS, enforced at the module level. Identity controls, logging, monitoring, and storage security in every Terraform resource.

CIS Benchmarks are a prescriptive baseline when you want concrete security recommendations without a specific industry mandate. Many teams start here and map upward to SOC 2 or NIST when audits come.

99

Controls

9

Recommendations

34

AWS Modules

No credit card or AWS account needed to start.

From the team behind terraform-aws-modules. 2B+ provisions worldwide.

IAM · CloudWatch Logs · CloudTrail · VPC · S3 · RDSSOC 2 Type II CertifiedAvailable on AWS Marketplace

Three Steps to CIS Compliant Infrastructure

For terraform-aws-modules users, migration is a one-line change. Same workflow, same interface. Bringing your own modules? We can make those compliant too. Join the beta.

1

Change One Line

main.tf
module "s3" {
- source = "registry.terraform.io/..."
+ source = "cis.compliance.tf/..."
 
  bucket = "awesome-docs"
}
2

Run Terraform Commands

terminal
$ terraform init
Initializing modules...
- module.s3 in cis.compliance.tf/...
Terraform has been successfully initialized!
$ terraform apply
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
3

Compliance Enforced

2.1.1 · S3 Default Encryption
2.1.2 · S3 SSL Requests Only
2.1.4 · S3 Public Access Blocked
3.1 · CloudTrail Enabled
3.4 · CloudTrail Log Validation
3.7 · CloudTrail KMS Encryption
2.2 · Security Contact Registered
2.4 · Root MFA Enabled

Every compliance requirement you define is enforced automatically. Nothing to scan, nothing to remediate.

Controls Enforced for CIS

99 controls across 9 recommendations and AWS services

Enforced (27)Detected (70)
  • AWS accounts should have security contact information provided
  • AWS accounts should have current contact information
  • EC2 instances should have IAM profile attached
  • Public EC2 instances should have IAM profile attached
  • EC2 instances should use IAM instance roles for AWS resource access
  • IAM Access Analyzer should be enabled for all regions
  • IAM Access Analyzer should be enabled without findings
  • IAM password policies should have minimum length set to 14 or greater
  • IAM password policies should prevent password reuse
  • IAM password policies should have strong configurations with minimum length of 8 or greater
  • IAM password policies should have strong configurations
  • AWS accounts should have IAM SAML providers
  • IAM groups, users, and roles should not have any inline policies
  • IAM policies should not allow full administrative privileges
  • IAM policies should not allow full '*' administrative privileges
  • IAM policy should not have statements with admin access
  • IAM root user should not be used for administrative and daily tasks
  • IAM root user should have MFA enabled for console access
  • IAM root user hardware MFA should be enabled
  • IAM root user MFA should be enabled
  • IAM root user should not have access keys
  • IAM SSL/TLS certificates should not be expired
  • IAM support roles should be created to manage incidents with AWS Support
  • IAM user access keys should be rotated at least every 90 days
  • IAM users with access keys unused for 45 days or greater should be disabled
  • IAM users should have access keys and passwords assigned at setup
  • IAM users with console access unused for 45 days or greater should be disabled
  • IAM users should have restricted access to AWSCloudShellFullAccess
  • IAM user MFA should be enabled
  • IAM user should not have any inline or attached policies
  • IAM policies should be attached only to groups or roles
  • IAM users should not have active access keys that have never been used
  • IAM users should have only one active access key
  • IAM user credentials that have not been used in 90 days should be disabled
  • IAM administrator users should have MFA enabled

Additional Controls

2 additional controls enforced for CIS

Enforced (0)Detected (2)

CIS Scope: What We Handle vs. What You Own

compliance.tf handles the infrastructure configuration layer for CIS. Here is what it covers and what stays with your team.

compliance.tf Enforces for CIS

  • CIS Benchmark Level 1 and Level 2 infrastructure controls
  • CIS AWS Foundations Benchmark v6.0 recommendation mapping
  • Deployment-time evidence generation via AWS-native tools
  • Upstream module updates (terraform-aws-modules kept in sync)
  • Exception management with audit trail
  • Control documentation and benchmark mapping matrices

Your Team Still Handles for CIS

  • Network monitoring and VPC flow log analysis
  • Malware defense and endpoint protection
  • Data recovery testing and validation procedures
  • Security awareness and skills training
  • Audit log monitoring and alerting configuration
  • Account and identity management policies
  • Penetration testing and vulnerability assessments

compliance.tf enforces the CIS Benchmark recommendations that map to AWS resource configuration. Operational recommendations around monitoring, alerting, and access review processes remain your team's responsibility.

Operational Rules (lifecycle blocks, tagging, instance restrictions) are also applied alongside CIS compliance controls.

CIS Audit Evidence — Built Into Your Workflow

Your auditor does not need to trust compliance.tf. Evidence comes from AWS-native tools they already accept.

Evidence your auditor already trusts

Every compliance.tf module enforces controls at deploy time. When AWS Config, Security Hub, or Audit Manager evaluates your resources, they report clean findings because the controls are built into the modules, not bolted on after the fact.

  • AWS Config rules validate resource configuration continuously
  • Security Hub aggregates findings across accounts and regions
  • Audit Manager generates assessment reports mapped to CIS
  • Downloadable control mapping matrices for your auditor
evidence.json
{
  "framework": "CIS",
  "clause": "2.1.1",
  "control": "s3_bucket_default_encryption_enabled",
  "status": "COMPLIANT",
  "source": "AWS Config",
  "resource": "arn:aws:s3:::awesome-docs",
  "evaluated": "2026-03-04T10:30:00Z"
}

Prevention vs. Detection for CIS

compliance.tf prevents non-compliant deployments. Scanning tools detect them after the fact. Most mature programs use both.

DimensionIaC Scanning
Checkov / Trivy / Prowler
Compliance.tf
Prevents non-compliant configs before terraform applyNo (post-plan scan)Yes
Maps controls to framework clause IDsPartialYes
Produces auditor-accepted evidence (AWS-native)Scan reports onlyYes
Exception management with audit trailSuppression rulesYes
Same interface as terraform-aws-modulesN/AYes
Keeps pace with upstream module updatesN/AYes
Catches runtime drift / console changesYesNo
Covers non-Terraform resourcesYesNo
Internal engineering timeMediumLow

We recommend keeping scanning tools active alongside compliance.tf for defense in depth. The scanner validates what compliance.tf already enforces.

CIS Compliance Questions

Which CIS Benchmark version is supported?

compliance.tf maps controls to CIS Amazon Web Services Foundations Benchmark v6.0, the latest version. We also maintain mappings for v5.0 and v1.4.0 for teams that reference older benchmark versions. The module registry subdomain cis.compliance.tf serves the v6.0.0 mappings by default; use cisv140.compliance.tf for v1.4.0-specific modules.

Does this cover Level 1 and Level 2?

Yes, compliance.tf enforces both Level 1 (essential security) and Level 2 (defense-in-depth) recommendations where they map to infrastructure configuration. Some Level 2 recommendations are operational (monitoring review processes, log analysis) and remain your team's responsibility.

How is this different from Checkov, Trivy, or Prowler?

Those tools are detective controls. They scan infrastructure after you write it and report findings you fix manually. compliance.tf is a preventive control. The modules themselves cannot produce non-compliant resources. There is nothing to scan, nothing to remediate. Most teams keep their scanners running alongside compliance.tf for defense in depth.

Can I adopt this gradually, or is it all-or-nothing?

Fully incremental. Start with one module in one environment. Your existing modules continue working untouched. If you use Terragrunt or Terramate to orchestrate your runs, nothing changes — you’re only swapping the module source line. There is no global policy agent to deploy, no wrapper binary, no sidecar. Each module source line is independent.

Will my auditor accept this as evidence?

Your auditor does not need to trust compliance.tf directly. Evidence comes from AWS-native tools they already accept: AWS Config, Security Hub, and Audit Manager. We enforce controls at deploy time so those AWS tools always report clean findings.

What if I want to switch back or compliance.tf shuts down?

Our modules are standard Terraform. They work with Terraform, OpenTofu, Terragrunt, Terramate, and any tool that speaks the Terraform module protocol. Every module is a drop-in replacement for its upstream terraform-aws-modules equivalent with the same variables and outputs. Change your module source line back, run terraform init. Your infrastructure does not change. No lock-in, no proprietary state.

Start Deploying CIS-Compliant Infrastructure

$1,000/year for all 34 modules, all frameworks. 30-day free trial.

No credit card required. Switch back at any time.

Stay Informed About New Features

Join the mailing list for releases, new modules, and roadmap updates. No spam. Unsubscribe anytime.

Not convinced yet or dying for a feature we don't have? Send us an email — we really want to hear your feedback!