Your
Trusted
Get Fully AWS Funded
Cloud Migration
Cloud Migration
No. AWS supports several CIS AWS Foundations Benchmark versions, and its service setup documentation still describes v1.2 in the default-standards path. The v2.0.0 module release changes the module default, so existing and separately managed accounts need an explicit review.
Yes. AWS supports the versions concurrently and recommends enabling v5 before disabling the older version to prevent a security-check gap.
Not for the documented module transition. The v2.0.0 guidance uses a temporary enabled_standards list with both versions. Use moved blocks only when a genuine Terraform address refactor requires them.
Confirm v5 readiness and findings in every intended account and Region, verify AWS Config prerequisites, test downstream consumers, review changed or manual controls, and capture the approval or exception decisions.
Moving from CIS AWS Foundations Benchmark v1.2 to v5 in AWS Security Hub looks simple on a roadmap. One standard is old, another is current, and Terraform should make the change repeatable. The operational risk sits elsewhere: a standard can be enabled, a Terraform apply can finish cleanly, and the people who rely on findings can still lose continuity in the reporting they use every day.
That is why this should be treated as a staged migration, not as a version bump. The aim is to keep the old and new standards visible long enough to check what changed, verify that the new standard is actually producing findings, and make sure alerting and reporting still have the coverage the team expects.
The terraform-aws-monitoring v2.0.0 release changes the module default from CIS v1.2.0 to CIS v5.0.0. That is a module behaviour change. It does not mean that AWS has globally changed the default standards created by AWS Security Hub APIs. AWS Security Hub setup documentation still describes CIS v1.2 alongside AWS Foundational Security Best Practices as the service defaults when default standards are enabled.
The distinction matters in a mixed estate. A team can have accounts managed by this Terraform module, accounts using a different landing-zone pattern, and accounts where Security Hub was enabled manually. Those paths do not automatically converge when one module changes its default.
Version 2.0.0 makes CIS v5 the default in the Security Hub module. The release notes call this a breaking change for existing deployments and describe a transition period in which both CIS v1.2 and CIS v5 are enabled. The reason is practical: before removing v1.2, the new standard should be READY and should be producing findings.
There is an important detail worth calling out. The release documentation does not prescribe a Terraform moved block or a terraform state mv operation for this migration. A moved block is useful when Terraform resource addresses change. Here, the documented path is an explicit enabled_standards override that keeps both benchmark versions active while the new one is validated. Inventing a state migration would add risk without solving the coverage question.
The module README shows the transition with both CIS versions in the list:
enabled_standards = [
"aws-foundational-security-best-practices/v/1.0.0",
"cis-aws-foundations-benchmark/v/1.2.0",
"cis-aws-foundations-benchmark/v/5.0.0",
]
This is an intermediate state, not a permanent baseline. It gives the team an overlap window in which it can compare outputs and confirm downstream behaviour.
CIS v5 is not a relabelled copy of CIS v1.2. AWS publishes a control comparison because some controls are new, some older controls are retired, and others change how they are evaluated. Teams should expect the finding inventory to change. A dashboard that groups findings by control ID, for example, may need an update even when the underlying security objective remains relevant.
The CloudWatch-related controls are the most obvious operational example. In the v5 comparison, AWS marks several CloudWatch metric-filter and alarm checks as manual rather than Security Hub CSPM findings. If your escalation process depends on those checks, review the monitoring implementation and the evidence route separately. Their absence from the new finding stream is not proof that the requirement has disappeared.
AWS describes CIS v5 support as 40 automated checks. That is useful context, but it is not a coverage guarantee for an individual environment. The only useful question during this migration is narrower: which checks, alerts, reports, and evidence consumers do we rely on today, and how will each one behave once v1.2 is removed?
List where CIS v1.2 findings go after Security Hub. That often includes an event-driven alert path, a ticketing workflow, SIEM ingestion, monthly reporting, exception registers, and evidence retained for internal or external review. Record the Region, account, control IDs, severity handling, and owner for every consumer that matters. This is the baseline that makes a safe comparison possible.
Upgrade the module, then explicitly configure both CIS v1.2 and v5. Apply through the normal change process. AWS supports multiple CIS AWS Foundations Benchmark versions at the same time, and AWS recommends enabling v5 before disabling the older version to avoid a gap in security checks.
A successful Terraform apply is not the finish line. Confirm that the CIS v5 subscription is READY in every intended account and Region. Then check that it is producing findings, that AWS Config is recording the resources needed for the controls, and that the finding lifecycle is behaving as expected. Security Hub depends on AWS Config for control findings, so a standards migration can expose a pre-existing configuration gap that was previously hidden by the way reports were assembled.
Test the path that matters to operators. Use representative findings or controlled non-production scenarios to verify event rules, routing, enrichment, ticket creation, SIEM fields, dashboards, and reports. Do not limit the check to whether a finding exists in the Security Hub console. A finding that never reaches the responder or reporting workflow is operationally missing.
Use AWS's version comparison as a working checklist. For every v1.2 control that disappears or becomes manual, decide whether the intent is already covered elsewhere, needs a separate monitoring control, or should be recorded as an accepted exception. Give that decision an owner and keep the rationale with the change record.
Once v5 findings and all dependent workflows have been validated, remove CIS v1.2 from enabled_standards in a separate apply. Keeping removal separate from initial enablement makes the operational change easier to review and gives the team a clean checkpoint if an issue appears.
In an AWS Organization, the standard has to be enabled where the organisation expects coverage, not merely in the delegated administrator account. AWS recommends Organizations integration and central configuration for managing Security Hub standards and controls across accounts, organisational units, and Regions. Check the policy scope, enrolment of new accounts, opt-in Regions, and the ownership of exceptions before treating the migration as complete.
This is also the place to check for drift between Terraform and centrally managed Security Hub configuration. If a central configuration policy owns a setting, a module-level change may not have the effect the operator expects. Resolve the source of authority first; otherwise the deployment can look correct in code while the effective configuration differs in the account.
For FinTech teams, the migration is usually less about claiming compliance and more about preserving a reviewable control process. A reviewer may need to see what changed, when the new checks became active, how exceptions were handled, and whether the reporting route continued to work. A short overlap between standards is often far easier to explain than a clean-looking change that leaves a gap in the evidence trail.
The same logic applies to any software team with customers, auditors, or internal risk owners who consume security reporting. Treat the benchmark change as infrastructure change management: planned, observed, validated, and documented. It does not certify an environment or make an audit outcome certain.
Das Meta helps software teams manage reviewable security-infrastructure changes through Terraform, explicit migration steps, and operational validation. For a Security Hub migration, that means defining the overlap, testing the paths that consume findings, recording the decisions around changed controls, and only then removing the legacy standard.
If you are also tightening the operational layer around this work, these related reads may help: CloudWatch monitoring with Terraform for uptime checks and AWS RDS monitoring for FinTech teams.