CIS AWS Benchmark v1.3.0

Deprecated Framework

This framework has been superseded by CIS AWS Benchmark v1.4.0 and later versions. Organizations should migrate to newer versions for updated security controls and best practices.

Best for: Organizations that adopted CIS AWS Foundations Benchmark v1.3.0 before v1.4.0, v1.5.0, v2.0.0, and v3.0.0 shipped and have not yet migrated. Some audit firms still reference v1.3.0 findings in active engagements. Teams running AWS infrastructure with a compliance program pinned to this version should treat it as a waypoint toward v3.0.0. No revenue or size thresholds apply; CIS benchmarks cover any AWS account holder working toward a hardened baseline.

Mandatory?	Voluntary security baseline
Who validates?	Self-assessment or third-party
Renewal	No fixed cycle
Scope	AWS cloud environments; two levels (L1/L2)

🏛 Center for Internet Security (CIS) · CIS AWS Benchmark v1.3.0 (superseded) Official source →

Get Started

module "..." {
  source  = "cisv130.compliance.tf/terraform-aws-modules/<module>/aws"
  version = "<version>"
}

What Compliance.tf Covers vs. What You Handle

What Compliance.tf automates

IAM Credential Hygiene: Runs 6 controls against the IAM credential report: root access key existence, access key age (90-day threshold), unused access keys (45 days), unused console access (45 days), MFA enrollment, and stale credential status.
IAM Policy Least Privilege: Seven controls scan the full IAM policy surface for Action:*/Resource:* statements, direct user policy attachments, inline policies, and overly broad sts:AssumeRole grants. Covers managed, custom, attached, and unattached policies.
S3 Public Access and Encryption: Four controls covering the account-level public access block, per-bucket public write restrictions, default encryption settings, and server access logging, evaluated against current bucket and account configuration.
EBS Encryption at Rest: Two controls check EBS encryption state across all regions in the account: one scoped to attached volumes, one covering all volumes regardless of attachment status.
CloudTrail and CloudWatch Integration: One control confirming that CloudTrail trails have active CloudWatch Logs integration. Checks that log delivery is current, not stale.

What you handle

IAM Credential Hygiene: Defining an operational process to disable or remove flagged credentials. Documenting exceptions for service accounts. Configuring automated remediation (Lambda, SSM) if you want drift correction between scans.
IAM Policy Least Privilege: Refactoring policies that fail requires understanding application-level permission needs, not just removing wildcards. Maintain a policy review cadence as new services and features are adopted.
S3 Public Access and Encryption: KMS key policy configuration if using SSE-KMS. Deciding where S3 access logs land and setting retention periods. Handling legitimate exceptions for public-read buckets (e.g., static websites) requires documented risk acceptance.
EBS Encryption at Rest: Enable the account-level EBS encryption default in each region. Migrate existing unencrypted volumes by snapshot-and-replace. Select and manage the KMS key used for encryption.
CloudTrail and CloudWatch Integration: CloudWatch metric filters and alarms for specific API events (CIS Section 4 controls) are outside what this control covers. Set log group retention periods and manage cross-account log aggregation if you operate an AWS Organization.

Controls by Category

EBS Encryption (Section 2) (2 controls)

Volumes created before the account-level encryption default was enabled are the most common gap here. Auditors check both the default setting and whether any currently attached volumes are unencrypted. Fixing unencrypted volumes requires a snapshot-and-replace, which means downtime for non-root volumes.

Attached EBS volumes should have encryption enabled

compliance.tf module EBS volumes should have encryption at rest enabled

compliance.tf module

Logging and Monitoring (Section 3) (1 control)

At minimum, one multi-region CloudTrail trail must deliver events to a CloudWatch Logs log group with an active retention policy. Auditors confirm log delivery is current, not stale. A missing CloudWatch integration means no real-time alerting on management plane activity, which is a straightforward finding to document and difficult to argue around.

CloudTrail trails should be integrated with CloudWatch logs

S3 Bucket Security (Section 2) (4 controls)

The account-level S3 public access block is the first thing checked; individual bucket policies get spot-checked for public write ACLs after that. Default encryption (SSE-S3 or SSE-KMS) must be enabled on every bucket, and server access logging is required but frequently missed on buckets provisioned by third-party tooling or automated deployments.

S3 buckets should have default encryption enabled

compliance.tf module S3 buckets should have logging enabled

compliance.tf module S3 buckets should prohibit public write access

compliance.tf module S3 public access should be blocked at account level

compliance.tf module

CIS AWS Benchmark v3.0.0 — 🟢 High overlap (65%)

CIS v3.0.0 is the current version and supersedes v1.3.0. Many v1.3.0 controls carry forward, but v3.0.0 adds requirements around Organizations-level settings, SSO, and updated networking controls. Migrating from v1.3.0 means picking up roughly 15 to 20 new controls.

CIS AWS Benchmark v1.4.0 — 🟢 High overlap (90%)

The immediate successor to v1.3.0. Most controls are identical, with minor wording changes and a few additions around Access Analyzer and account-level settings. If you pass v1.4.0, you pass nearly all of v1.3.0.

AWS Foundational Security Best Practices — 🟡 Medium overlap (55%)

AWS Foundational Security Best Practices (FSBP) partially overlaps with CIS v1.3.0 on S3, EBS, IAM, and CloudTrail, but is organized by AWS service rather than security domain. FSBP also includes service-specific controls for RDS, Lambda, and others that CIS v1.3.0 Level 1 does not address.

Frequently Asked Questions

CIS v1.3.0 is deprecated. Should I still run it?

Only if an existing audit engagement or internal policy explicitly references v1.3.0. Otherwise, migrate to v3.0.0. Running both versions in parallel during a transition is reasonable since the v1.3.0 benchmark executes in seconds and surfaces regressions while you adopt the newer control set.

What changed between v1.3.0 and the latest CIS AWS benchmark?

v1.4.0 added controls for IAM Access Analyzer and tightened credential rotation windows. v2.0.0 restructured sections and introduced AWS Organizations and Security Hub requirements. v3.0.0 added SSO, account-level defaults, and additional networking controls. The IAM and S3 controls from v1.3.0 largely survived but some were reworded or renumbered.

Does CIS require a formal certification or third-party audit?

No. CIS benchmarks are self-assessed and there is no CIS-issued certificate. Organizations run the benchmark, remediate findings, and present results to their own auditors or governance boards. Some audit firms conducting SOC 2 and ISO 27001 assessments accept CIS benchmark reports as evidence of baseline hardening.

How do I handle controls that flag legitimate exceptions, like a public S3 bucket for a static website?

Document each exception with a risk owner, business justification, and compensating controls (e.g., CloudFront OAI, WAF). Suppress the specific finding in Powerpipe using control filters or resource exclusions, and tag the resource so future scans carry the exception context. Do not globally disable the control.

How long does a full v1.3.0 benchmark run take?

Under 2 minutes for a single AWS account with moderate resource counts (under 500 IAM users, under 1,000 S3 buckets). IAM credential report generation is usually the bottleneck. Multi-account runs via AWS Organizations scale linearly with account count.