CIS AWS Benchmark tool: which controls CloudArq checks
The Center for Internet Security's AWS Foundations Benchmark is the de-facto baseline for cloud security. This page explains what it covers, how CloudArq aligns with v1.5, and which specific controls we scan on every audit run.
Updated 2026-04-19 · ~6 minute read
What is the CIS AWS Benchmark?
A free, community-maintained checklist of AWS security settings that, if implemented, reduce the most common attack vectors. The Center for Internet Security (cisecurity.org) publishes it annually. Version 1.5 (2022) is still the most-cited and the version CloudArq aligns to; version 3.0 (late 2024) adds controls for Organizations and Lambda that CloudArq does not yet scan.
Every AWS-focused compliance framework (SOC 2, HIPAA, PCI DSS, NIST 800-53) is more demanding than CIS, but every one of them treats CIS as the entry ticket. If you fail the Benchmark, you won't pass any of them. If you pass it, you're ready for the harder frameworks — which is why the SOC 2 checklist starts by assuming CIS is done.
How CloudArq aligns
The baseline CloudArq aligns to, and coverage is tiered. Max runs every control marked checked below (19 of 26); Pro runs 18 of them — AWS Config is Max-only. Starter runs 8: the root-account, IAM-credential, public-S3 and open-port controls most likely to block an audit. The CloudTrail and VPC-flow-log controls need Pro or above.
7 controls are on the roadmap rather than implemented: root-account usage detection, password-reuse prevention, two CloudWatch metric-filter alarms (console sign-in without MFA, IAM policy changes), the default-security-group control, CloudTrail-to-CloudWatch Logs integration, and VPC-peering route review. They're flagged with roadmap in the table below.
19 of 26 representative controls checked
A representative subset of the CIS AWS Benchmark — full coverage in the Max tier. See cisecurity.org for the complete spec.
| ID | Section | Title | Severity | ◆ CloudArq |
|---|---|---|---|---|
| 1.4 | IAM | Ensure no root account access key exists | high | Checked |
| 1.5 | IAM | Ensure MFA is enabled for the root account | high | Checked |
| 1.7 | IAM | Eliminate use of the root account for administrative tasks | high | Roadmap |
| 1.8 | IAM | Ensure IAM password policy requires ≥ 14 characters | medium | Checked |
| 1.9 | IAM | Ensure IAM password policy prevents password reuse | medium | Roadmap |
| 1.10 | IAM | Ensure MFA is enabled for all IAM users with a console password | high | Checked |
| 1.12 | IAM | Ensure credentials unused for 90 days or greater are disabled | medium | Checked |
| 1.14 | IAM | Ensure access keys are rotated every 90 days or less | medium | Checked |
| 1.20 | IAM | Ensure that IAM Access Analyser is enabled for all regions | medium | Checked |
| 3.1 | Logging | Ensure CloudTrail is enabled in all regions | high | Checked |
| 3.2 | Logging | Ensure CloudTrail log-file validation is enabled | medium | Checked |
| 3.3 | Logging | Ensure the S3 bucket used for CloudTrail logs is not publicly accessible | high | Checked |
| 3.4 | Logging | Ensure CloudTrail trails are integrated with CloudWatch Logs | medium | Roadmap |
| 3.5 | Logging | Ensure AWS Config is enabled in all regions | medium | Checked |
| 3.7 | Logging | Ensure CloudTrail logs are encrypted at rest using KMS-managed keys | medium | Checked |
| 3.8 | Logging | Ensure rotation for customer-created KMS keys is enabled | medium | Checked |
| 3.9 | Logging | Ensure VPC flow logging is enabled in all VPCs | medium | Checked |
| 4.1 | Monitoring | Ensure a log metric filter + alarm for unauthorized API calls exists | medium | Checked |
| 4.2 | Monitoring | Ensure a log metric filter + alarm for Management-Console sign-in without MFA | medium | Roadmap |
| 4.3 | Monitoring | Ensure a log metric filter + alarm for root-account usage | high | Checked |
| 4.4 | Monitoring | Ensure a log metric filter + alarm for IAM policy changes | medium | Roadmap |
| 5.1 | Networking | Ensure no network ACL allows unrestricted ingress from 0.0.0.0/0 | high | Checked |
| 5.2 | Networking | Ensure no security group allows ingress from 0.0.0.0/0 to port 22 | high | Checked |
| 5.3 | Networking | Ensure no security group allows ingress from 0.0.0.0/0 to port 3389 | high | Checked |
| 5.4 | Networking | Ensure the default security group of every VPC restricts all traffic | medium | Roadmap |
| 5.5 | Networking | Ensure routing tables for VPC peering are least-access | medium | Roadmap |
A scan, filtered to CIS
Same finding carries its SOC 2, HIPAA, PCI-DSS, NIST 800-53, and ISO 27001 mappings alongside the CIS ID.
How to read the output
Each CloudArq finding carries the CIS control ID it satisfies in its metadata. From the compliance-gaps page you can filter by framework (CIS) and sort by severity; every row shows the AWS CLI command or Terraform block to fix the gap. The same finding carries its mapping for SOC 2, HIPAA, PCI-DSS, NIST 800-53, and ISO 27001 — useful when you're preparing for more than one audit.
Frequently asked
- 01Which CIS AWS Benchmark version does CloudArq align to?
- CloudArq aligns to the CIS AWS Foundations Benchmark v1.5 (2022), the most-cited version. Several v1.5 controls it already checks — KMS key rotation, for example — also appear in v3.0 (2024), but CloudArq does not yet scan the controls v3.0 adds beyond v1.5. Coverage is tiered: Max runs every v1.5 control CloudArq implements, Pro runs all of them except the AWS Config control, and Starter runs the root-account, IAM-credential, public-S3 and open-port subset.
- 02Does passing the CIS Benchmark satisfy SOC 2 as well?
- No. CIS is the entry ticket, not the finish line. Every AWS-focused framework (SOC 2, HIPAA, PCI DSS, NIST 800-53) is more demanding than CIS but treats it as a prerequisite. Passing CIS means you are ready to work on the harder frameworks, not that you have passed them.
- 03Do you check every control in the CIS AWS Benchmark?
- No. The table on this page is a representative subset, and the controls CloudArq does not check today are labelled roadmap rather than presented as covered. Those are root-account usage detection, password-reuse prevention, the CloudWatch metric-filter alarms for console sign-in without MFA and for IAM policy changes, the default-security-group control, CloudTrail-to-CloudWatch-Logs integration, and VPC-peering route review.
- 04Does CloudArq need write access to run the benchmark?
- No. CloudArq connects through a read-only IAM role secured with an ExternalId, never stores your credentials or data, and only reads configuration. The audit is detection plus a guided fix — never auto-fix.