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.
27
Mapped Controls
18 enforced by modules
9
Recommendations
35
AWS Modules
No credit card or AWS account needed to start.
From the maintainer of terraform-aws-modules - 2B+ downloads.
IAM · CloudWatch Logs · CloudTrail · VPC · S3 · RDS|SOC 2 Type II report|Available 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
3.1 · S3 MFA Delete
3 · S3 Public Access Blocked
3 · S3 Public Read Blocked
3.2 · RDS Encryption at Rest
3.2 · RDS Public Access Blocked
3.3 · EFS Encryption at Rest
4 · KMS Key Rotation
2 · EC2 IAM Role Attached
Controls with module coverage are enforced automatically. Enforced controls ship as compliant defaults; mapped controls without module coverage stay visible for your team.
Controls Mapped for CIS
27 controls mapped, 18 enforced by modules, across 9 recommendations
Enforced: the module configures this by default. Detected: mapped for visibility and evidence, not set by the module.
Enforced (18)Detected (83)
2 Identity and Access Management
- 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 365 days
- 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 should have MFA enabled
- 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 credentials unused for 45 days or more should be disabled
- IAM user credentials that have not been used in 90 days should be disabled
- IAM administrator users should have MFA enabled
3 Storage
- CloudTrail trail S3 buckets should have MFA delete enabled
- EFS file systems should have encryption at rest enabled
- EFS file systems should be encrypted with CMK
- Macie should be enabled
- RDS DB clusters should have automatic minor version upgrade enabled
- RDS DB clusters should be configured for multiple Availability Zones
- RDS DB instance automatic minor version upgrade should be enabled
- RDS DB instance encryption at rest should be enabled
- RDS DB instances should have multiple AZ enabled
- RDS DB instances should not use public subnet
- RDS DB instances should prohibit public access
- S3 buckets should enforce SSL
- S3 buckets should have MFA delete enabled
- S3 buckets should prohibit public read access
- S3 public access should be blocked at account level
- S3 public access should be blocked at bucket level
- S3 public access should be blocked at account and bucket levels
3.1 Simple Storage Service (S3)
- S3 buckets should enforce SSL
- S3 buckets should have MFA delete enabled
- S3 buckets should be discovered, classified, and secured by Macie
- S3 public access should be blocked at account and bucket levels
3.2 Relational Database Service (RDS)
- RDS DB instance automatic minor version upgrade should be enabled
- RDS DB instance encryption at rest should be enabled
- RDS DB instances should have multiple AZ enabled
- RDS DB instances should prohibit public access
3.3 Elastic File System (EFS)
- EFS file systems should have encryption at rest enabled
4 Logging
- CloudTrail trails should be enabled in all regions
- CloudTrail trails should have at least one multi-region trail present in an account
- S3 buckets should log S3 data events in CloudTrail
- CloudTrail S3 buckets should have access logging enabled
- S3 buckets should have object-level read event logging enabled in CloudTrail
- S3 buckets should have object-level write event logging enabled in CloudTrail
- CloudTrail trails should have at least one enabled trail present in a region
- CloudTrail trails should have at least one trail enabled in the AWS account
- CloudTrail trails should have logs encrypted using a customer managed KMS key
- CloudTrail trails should have log file validation enabled
- Config configuration recorders should not fail to deliver logs
- AWS Config should be enabled in all regions
- KMS CMK rotation should be enabled
- S3 buckets should have object logging enabled
- VPC flow logs should be enabled
5 Monitoring
- CloudWatch log metric filters should be configured for S3 bucket policy changes
- CloudWatch log metric filters should be configured for CloudTrail configuration changes
- CloudWatch log metric filters should be configured for AWS Config configuration changes
- CloudWatch log metric filters should be configured for AWS Management Console authentication failures
- CloudWatch log metric filters should be configured for AWS Management Console sign-in without MFA
- CloudWatch log metric filters should be configured for disabling or scheduled deletion of customer managed keys
- CloudWatch log metric filters should be configured for IAM policy changes
- CloudWatch log metric filters should be configured for changes to Network Access Control Lists (NACL)
- CloudWatch log metric filters should be configured for changes to network gateways
- CloudWatch log metric filters should monitor AWS Organizations changes
- CloudWatch log metric filters should be configured for usage of root account
- CloudWatch log metric filters should be configured for route table changes
- CloudWatch log metric filters should be configured for security group changes
- CloudWatch log metric filters should be configured for unauthorized API calls
- CloudWatch log metric filters should be configured for VPC changes
- Security Hub should be enabled for an AWS account
6 Networking
- Attached EBS volumes should have encryption enabled
- EBS volumes should have encryption at rest enabled
- EC2 instances should use IMDSv2
- VPC default security group should not allow inbound and outbound traffic
- Network ACLs should not allow ingress from 0.0.0.0/0 to port 22 or port 3389
- VPCs peering connection route tables should have least privilege
- VPC security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports
- VPC security groups should not allow ingress from 0.0.0.0/0 to remote server administration ports (IPv4)
- VPC security groups should not allow ingress from ::/0 to remote server administration ports
- VPC security groups should restrict ingress CIFS access from 0.0.0.0/0 and ::/0
- VPC security groups should restrict ingress access on ports 20, 21, 22, 3306, 3389, 4333 from 0.0.0.0/0
- VPC security groups should not allow ingress from 0.0.0.0/0 to port 3389
- VPC security groups should restrict ingress SSH access from 0.0.0.0/0
6.1 Elastic Compute Cloud (EC2)
- EBS encryption by default should be enabled
- VPC security groups should restrict ingress CIFS access from 0.0.0.0/0 and ::/0
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 Benchmark v6.0.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 before terraform apply. 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": "3.1",
"control": "s3_bucket_enforces_ssl",
"status": "COMPLIANT",
"source": "AWS Config",
"resource": "arn:aws:s3:::awesome-docs",
"evaluated": "2026-08-14T10: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.
| Dimension | IaC Scanning Checkov / Trivy / Prowler | Compliance.tf |
|---|---|---|
| Prevents non-compliant configs before terraform apply | No (post-plan scan) | Yes |
| Maps controls to framework clause IDs | Partial | Yes |
| Produces auditor-accepted evidence (AWS-native) | Scan reports only | Yes |
| Exception management with audit trail | Suppression rules | Yes |
| Same interface as terraform-aws-modules | N/A | Yes |
| Keeps pace with upstream module updates | N/A | Yes |
| Catches runtime drift / console changes | Yes | No |
| Covers non-Terraform resources | Yes | No |
| Internal engineering time | Medium | Low |
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 AWS Benchmark v6.0.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 Level 1 (essential security) and Level 2 (defense-in-depth) recommendations that map to resource 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 cannot silently produce non-compliant resources - every exception is an explicit parameter in your code, visible in review. Compliant defaults ship up front instead of findings to remediate later.
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 before terraform apply, so those tools report the enforced controls as passing.
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 35 modules, all frameworks. 30-day free trial.
No credit card required. Switch back at any time.
Or browse the CIS registry first - no signup needed: cis.compliance.tf
Stay Informed About New Features
Join the mailing list for releases, new modules, and roadmap updates. No spam. Unsubscribe anytime.
Not convinced yet, or missing a feature you need? Send us an email - we really want to hear your feedback!