Security Hub shows the CIS AWS Foundations Benchmark at 100% in the account you checked. Then your SOC 2 auditor asks about the other accounts, and about the monitoring recommendations Security Hub doesn't score at all.
If you're the CTO or platform lead in that meeting, you've hit a scope problem. The benchmark is written for one account, but you run it across an organization: every account, every Region, including accounts that don't exist yet. And CIS is at v7.1.0 while Security Hub evaluates v5.0.0.
I build multi-account AWS foundations that pass CIS in Security Hub, and the fix starts by sorting each control by where it lives: set once for the organization, or repeated per account. Then come manual reviews, drift and exceptions.
- Version: enable CIS v5.0.0 in Security Hub CSPM and track the gap to v7.1.0 by hand.
- Org-wide: set root credentials, the organization trail, guardrails and Security Hub once, from the management account or delegated administrators.
- Per account: push the rest through CloudFormation StackSets so new accounts arrive compliant.
Which CIS AWS Foundations Benchmark version should you target?
Target v5.0.0, the newest version Security Hub can score. CIS lists v7.1.0 as current. v7.0.0 came in April 2026, and a later CIS update added v7.1.0 with wider AWS Organizations and IAM coverage and a new Amazon Bedrock section.
Security Hub CSPM (Cloud Security Posture Management) supports v5.0.0, v3.0.0, v1.4.0 and v1.2.0. AWS recommends v5.0.0, added on October 16, 2025, and holds CIS certification for Level 1 and Level 2 on v5.0.0. Level 1 covers baseline settings with little usability impact; Level 2 adds stricter settings for higher-risk environments.
Your automated evidence therefore covers v5.0.0. Recommendations added after v5.0.0 are yours to assess with the CIS PDF or a scanner such as Prowler. I'd record that delta as a manual review item and tell the auditor which version your evidence covers.
Upgrading? Enable v5.0.0 before disabling the old version; both can run side by side.
What Security Hub checks for CIS, and what you still review by hand
A green score proves the automated subset, not the full CIS AWS benchmark. The v5.0.0 standard runs 40 controls, and AWS says many unsupported requirements "can be evaluated only by manually reviewing the state of your AWS resources."
Most of those controls run on AWS Config service-linked rules, so Config resource recording must be on in every account and Region where Security Hub CSPM runs. Enable both Security Hub and Security Hub CSPM and CSPM creates a service-linked recorder; with CSPM alone, recording is your job.
The biggest manual block is monitoring. In v5.0.0 and v3.0.0, AWS marks CloudWatch.1 to CloudWatch.14 and Macie.1 as manual checks it doesn't support. The CloudWatch controls expect a metric filter and alarm for:
- Root user activity, unauthorized API calls, and console sign-in without MFA
- IAM policy, CloudTrail and AWS Config configuration changes
- Console authentication failures and disabled or scheduled-for-deletion KMS keys
- S3 bucket policy changes
- Security group, network ACL, network gateway, route table and VPC changes
Keep a dated review record for these. A 100% screenshot won't answer questions about root sign-in alerting.
Which CIS controls do you set once, and which in every account?
Some controls you configure once and every account inherits. Others repeat per account or Region, and that half is where drift starts.
| CIS v5.0.0 requirement | Security Hub control | Scope | How to apply it |
|---|---|---|---|
| 3.1, 3.2, 3.4, 3.5 Trail, validation, bucket logging, KMS | CloudTrail.1, .4, .7, .2 | Org, once | Organization trail |
| 1.3, 1.4, 1.5 Root keys and MFA | IAM.4, IAM.9, IAM.6 | Org, once; management account by hand | Centralized root access |
| 2.1.4 S3 Block Public Access | S3.1, S3.8 | Org, once (S3.1); every bucket (S3.8) | Organizations S3 policy; bucket settings for S3.8 |
| 1.19 External access analyzer | IAM.28 | Every account and Region | Account analyzer through StackSets |
| 5.1.1 EBS default encryption | EC2.7 | Every account and Region | StackSets |
| 1.7, 1.8 Password policy | IAM.15, IAM.16 | Every account | StackSets |
| 3.3 AWS Config recording | Config.1 | Every account and Region | Service-linked recorder or StackSets |
| 5.5, 3.7 Default security group, flow logs | EC2.2, EC2.6 | Every VPC | StackSets for defaults, IaC per VPC |
| 1.2 Security contact, 1.16 support role | Account.1, IAM.18 | Every account | Account Management API; StackSets for the role |
| Security Hub CSPM and the CIS standard | n/a | Org, once | Central configuration policy |
Excalidraw diagram loading.
Set once for the organization
New accounts inherit them, members can't modify the organization trail, and an Organizations S3 policy overrides account-level settings. S3.1 checks the account-level Block Public Access setting, so confirm it reads the inherited one: run aws s3control get-public-access-block --account-id <member-account-id> in one member account, or set it per account until you have. S3.8 reads each bucket's own setting, which new buckets have on by default, so check older ones.
Repeat in every account and Region
EBS default encryption is Region-specific and isn't an EC2 declarative policy attribute, so each account needs it in each Region you use. IAM.28 ignores analyzers whose zone of trust is the organization, so add an account analyzer per Region or disable IAM.28 in members as a recorded exception. Anything in this half needs a deployment mechanism that runs when an account joins.
How do you remove root credentials from every member account?
Turn on centralized root access and delete member root credentials instead of guarding them. Launched in November 2024, it has two parts. Root credentials management lets you delete member root passwords, access keys and MFA devices, after which members can't sign in as root or recover the password. Privileged root actions give the management account or IAM delegated administrator sts:AssumeRoot sessions scoped to one task, for at most 15 minutes. Enable both from the management account:
aws organizations enable-aws-service-access --service-principal iam.amazonaws.com
aws iam enable-organizations-root-credentials-management
aws iam enable-organizations-root-sessions
Skip trusted access and IAM rejects the second command with ServiceAccessNotEnabledException. Afterwards, accounts you create in Organizations start with no root credentials.
IAM.4 checks for root access keys, which removal deletes. After removal, check how IAM.6 and IAM.9 report in one member account before you show the score to an auditor.
The management account is excluded. Its root keeps a password, MFA has been mandatory there since May 2024, and a hardware MFA device covers IAM.6.
Does one organization trail cover the CIS logging controls?
Yes, and you don't need a second trail per account. An organization trail comes from the management account or a CloudTrail delegated administrator, is multi-Region when created in the console, and appears in every member as a copy members can't change. The v5.0.0 trail controls are CloudTrail.1 (multi-Region, read and write management events), CloudTrail.2 (SSE-KMS), CloudTrail.4 (log file validation) and CloudTrail.7 (access logging on the log bucket).
Expect NO_DATA (nothing to evaluate) instead of PASSED in some member findings. CloudTrail.7 gives NO_DATA everywhere except the account holding the log bucket. Enable v1.4.0 or v1.2.0 too and the CloudWatch alarm controls do the same, because Security Hub only generates their findings for the account that owns the trail. The owner's findings are visible in the delegated administrator through cross-Region aggregation. Treat NO_DATA in members as expected.
If you build the monitoring alarms anyway, build them once. An organization trail can deliver to CloudWatch Logs, but the log group and its role must live in the account that configures delivery: the management account, or a delegated administrator using the CLI or API. If v1.4.0 checks will score them, keep the SNS topic in that account and match the CIS filter patterns exactly, because extra terms fail the check.
Where does break-glass access live once root is gone?
AWS's multi-account design principles put break-glass access in the management account, for an IdP outage or compromise, an IAM Identity Center failure, or losing the people who run it. Alert on every use and split it between two people: one holds the password, the other the hardware MFA key. My root user hygiene for the management account checklist covers the rest.
When Identity Center is down but the IdP is up, emergency access federates straight from the IdP into an emergency operations account with an empty emergency group and pre-built roles. Test it periodically.
For CIS, a break-glass IAM user falls under IAM.5 (MFA), IAM.3 (key rotation), IAM.2 (no attached user policies) and IAM.22, which flags credentials unused for 45 days. A dormant emergency user trips IAM.22 unless exercised or suppressed with a documented note. I'd use the federated role wherever the IdP is up, next to IAM Identity Center, and keep IAM users for the management account only. SEC03-BP03 asks for a documented process per failure mode, which is what the auditor reads.
How do you keep CIS from drifting as you add accounts?
Four mechanisms give every table row an owner that isn't a person.
Security Hub CSPM central configuration handles enablement. A delegated administrator, never the management account, creates configuration policies in a home Region, links other Regions, and targets the root, OUs or accounts. One trap: change or remove that administrator through the Organizations APIs and central configuration stops and its policies are deleted.
StackSets with service-managed permissions handle the per-account half. With automatic deployment, an account joining a target OU gets the baseline in every listed Region. StackSets skip the management account, and each of up to 5 delegated administrators can deploy anywhere, so keep that list short.
Service control policies (SCPs) stop anyone switching the evidence off:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ProtectOrganizationTrail",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"cloudtrail:UpdateTrail",
"cloudtrail:PutEventSelectors"
],
"Resource": "arn:aws:cloudtrail:*:111111111111:trail/organization-trail"
},
{
"Sid": "ProtectConfigRecorder",
"Effect": "Deny",
"Action": [
"config:StopConfigurationRecorder",
"config:DeleteConfigurationRecorder",
"config:DeleteDeliveryChannel"
],
"Resource": "*"
}
]
}
Members can't change the organization trail anyway, so the first statement, with your management account ID, guards against a CloudTrail delegated administrator; SCPs never reach the management account. I'd keep the deny unconditional: a pipeline exemption widens who can stop logging, so trail and recorder changes go through detaching the SCP in a reviewed change. Run it through the IAM policy validator before you attach it, and see these SCP examples for every OU for the rest.
Organizations S3 policies and EC2 declarative policies cover settings SCPs can't, such as S3 Block Public Access and snapshot and AMI public sharing. New accounts inherit both, and declarative policies enforce in the service control plane, so account admins can't override them.
Our AWS CDK Landing Zone wires these four together. A service-managed StackSet targets the root OU, so every joining account gets EBS default encryption, account-level S3 Block Public Access, rule-free default security groups, no default VPC and an 18-character password policy with 90-day expiry, in every configured Region. From the security account it enables centralized root access, an organization access analyzer per Region, and Security Hub central configuration with CIS v5.0.0 and AWS Foundational Security Best Practices. Root SCPs deny creating IAM users and access keys. Standards, disabled controls and automation rules live in one config file and change through a pull request.
In Security Hub it scores 100% on the CIS AWS Foundations Benchmark, with three S3 controls (S3.20, S3.22, S3.23) disabled as recorded exceptions in that config file, and 96% on AWS Foundational Security Best Practices. Those scores apply to the foundation layer; existing workload infrastructure may need separate remediation.
Which CIS exceptions will an auditor accept?
Some findings you'll choose not to fix, and Security Hub CSPM gives you two tools that mean different things. Disable a control that doesn't apply to your organization: no checks run, nothing is charged, and AWS recommends this over suppression. Suppress a finding when the control applies but you accept the risk on one resource; it stays visible as SUPPRESSED.
Automation rules do the suppressing. You create them only in the administrator account, they apply to new and updated findings, and each can set the workflow status and add a Note with Text and UpdatedBy. They replace the EventBridge and Lambda auto-suppression pattern AWS now marks as out of date.
My recommendation, not AWS guidance: keep disabled controls and suppression rules in code. Each exception then carries a pull request, an approver and a ticket ID in the Note, which is the shape of what SOC 2 auditors expect as evidence.
Where to start with the CIS AWS Foundations Benchmark
The CIS AWS Foundations Benchmark is per account on paper and per organization in practice:
- Enable v5.0.0 in Security Hub CSPM and document the v7.1.0 delta as a manual review.
- Set root credentials, the organization trail, S3 and EC2 policies, and Security Hub enablement once.
- Push EBS encryption, password policy, Config recording and default security groups through StackSets.
- Keep the monitoring section and every exception as a reviewed record.
This week, enable central configuration from a delegated administrator and compare CIS scores across accounts. The red ones show which half of the table you're missing. If an audit is close, put the foundation in place before your SOC 2 window opens, then look at the security practices beyond the benchmark.
Next step