CIS Benchmark

The CIS AWS Foundations Benchmark is a set of security configuration best practices published by the Center for Internet Security. It provides a prescriptive checklist covering IAM, logging, monitoring, networking, and storage security.

Versions

• v7.0: latest version (published March 2026)
• v5.0: latest version supported by Security Hub automated checks (also supports v3.0, v1.4, v1.2)

Key Control Areas

• IAM: password policies, MFA, access key rotation, root account lockdown
• Logging: CloudTrail enabled in all regions, log file validation, S3 access logging
• Monitoring: CloudWatch alarms for unauthorized API calls, console sign-in without MFA
• Networking: restrict default security groups, enable VPC Flow Logs

Each requirement in the benchmark is written as a concrete, checkable statement, for example that IAM user access keys must be rotated every 90 days or less, that the IAM password policy must require at least 14 characters, or that VPC flow logging must be enabled in all VPCs. That prescriptiveness is the benchmark's whole value: it converts "be secure" into a list you can audit, automate, and argue about item by item.

How It Goes Wrong in Practice

The classic CIS failure is mistaking a Security Hub score for benchmark compliance. When you enable a CIS standard in Security Hub, you get automated checks for the controls Security Hub can evaluate, and a percentage that looks like a grade. But a meaningful share of CIS requirements is explicitly marked "not supported, manual check" in Security Hub's own documentation: in versions 3.0.0 and 5.0.0 this includes the entire family of CloudWatch log-metric-filter-and-alarm requirements, such as alarms on root account usage, IAM policy changes, and CloudTrail configuration changes. A team that enables the standard, remediates its way to a green dashboard, and reports "CIS compliant" upward has silently skipped every requirement that needs manual verification. The second recurring failure is regional blindness: Security Hub standards operate per region, so enabling CIS in eu-west-1 says nothing about resources or logging posture in regions your team never opens but attackers happily use. The third is version confusion, where an auditor asks about the current benchmark while automation was configured years ago against v1.2.0 and never revisited, leaving newer requirements like IMDSv2 enforcement or Access Analyzer enablement (both present in v3.0.0 and v5.0.0 mappings) completely untracked.

Practical Check: What Standards Are Actually Enabled?

Ask Security Hub what it is really checking:

aws securityhub get-enabled-standards

The output lists each enabled standard's ARN and status. For CIS v5.0.0 the standard ARN has the form arn:aws:securityhub:region::standards/cis-aws-foundations-benchmark/v/5.0.0, so you can see at a glance which benchmark version each region is evaluating. Run it in every active region. If you find an old version enabled, turn on the newer version first and disable the old one afterward, which avoids a gap in checks during the transition; Security Hub explicitly supports running multiple CIS versions at the same time.

Frequently Asked Questions

Which CIS versions does Security Hub support?
Security Hub supports CIS AWS Foundations Benchmark versions 5.0.0, 3.0.0, 1.4.0, and 1.2.0, and AWS recommends v5.0.0 to stay current. Security Hub holds CIS Security Software Certification for v5.0.0, v3.0.0, and v1.2.0 at both Level 1 and Level 2.

What is the difference between Level 1 and Level 2?
CIS profiles its recommendations into two levels. Level 1 covers foundational hygiene that is broadly applicable with little service disruption; Level 2 adds stricter controls for environments with higher security requirements, at the cost of more operational friction. Most organizations start by driving Level 1 to completion and adopt Level 2 controls selectively.

Does passing the automated checks make me CIS compliant?
No. Automated checks cover the requirements Security Hub can evaluate through AWS Config; requirements marked as manual checks, including most of the alarm-related monitoring controls in recent versions, must be verified and evidenced by you. Full benchmark compliance is the automated results plus documented manual verification.

Is the CIS benchmark a legal or regulatory requirement?
Not by itself, but it is widely referenced. Auditors and frameworks frequently accept it as the concrete definition of "hardened AWS configuration", and cyber-insurance questionnaires increasingly borrow its controls. Treating it as your account-hardening baseline is the pragmatic move even when no regulation forces it: the controls are specific, the tooling to check them already exists, and every finding maps to a concrete remediation you can hand to an engineer.