Best practices for using Security Hub CSPM policies

Following these best practices helps you deploy and maintain Security Hub CSPM policies successfully across your organization. These guidelines cover Security Hub CSPM policy management and enforcement within AWS Organizations, including its complete-governance model, Region-specific configurations, and inheritance behavior.

Policy design principles

Establish clear principles for your policy structure before you create Security Hub CSPM policies. Keep policies simple. Start with a broad baseline at the organization root, and refine it through child policies or Region-specific configurations only where an OU or Region needs a different configuration.

Before you write a policy, understand how Security Hub CSPM resolves it:

• A policy governs Security Hub CSPM completely in each Region it enables. The policy disables any standard that it doesn't list as enabled. Control parameters that the policy doesn't specify use their default values.

• A Region-specific configuration fully replaces the default configuration for that Region. It isn't merged with the default. List every standard, control setting, and parameter that you want in that Region.

• A Region that appears in neither enable_in_regions nor disable_in_regions is unmanaged, not disabled. The policy leaves existing settings in that Region unchanged.

• default_control_association_status also determines whether Security Hub CSPM automatically enables new controls in enabled standards. Choose ENABLED if you want new controls to be enabled as Security Hub CSPM releases them. Choose DISABLED if you want to opt in to each control explicitly.

• Use empty Region lists deliberately. You can leave enable_in_regions empty when you only need to disable Security Hub CSPM in specific Regions, or leave disable_in_regions empty to keep Regions outside your enable list ungoverned.

Region management strategies

Use ALL_SUPPORTED in enable_in_regions when you want your coverage to include future Regions automatically. Use explicit Region lists when you need precise control, for example to keep development Regions ungoverned.

Favor a clear default configuration plus a small number of Region-specific configurations over many one-off Regional blocks. Add a Region-specific configuration only when a Region needs a different set of standards, controls, or parameters.

Security Hub CSPM policies don't have a home Region. Controls that evaluate global resources, such as many IAM controls, produce the same findings in every Region where they're enabled. To avoid duplicate findings and AWS Config costs, enable these controls in one Region by using a Region-specific configuration. Then disable them in the default configuration. For an example of this configuration, see Security Hub CSPM policy syntax and examples.

Document your Region-specific requirements, particularly for:

• Compliance-mandated Regions that require specific standards

• Regions where you aggregate findings

• Opt-in Regions with special considerations

• Regions where Security Hub CSPM must remain disabled

Policy inheritance planning

Plan your inheritance structure so that you keep effective control while allowing the flexibility you need. Document which OUs can modify inherited policies and which changes they can make. To enforce a baseline that child policies can't change, restrict inheritance operators at the parent level with @@operators_allowed_for_child_policies. For example, set ["@@none"] on disable_in_regions to prevent child policies from disabling Security Hub CSPM.

Delegated administrator strategy

Designate a dedicated security or compliance account as the Security Hub CSPM delegated administrator rather than operating from the management account. Before you attach Security Hub CSPM policies, designate the delegated administrator and attach the delegation policy. Security Hub CSPM uses the delegated administrator to automatically associate governed accounts as members in each Region. This gives you one place to review findings and keeps administration separate from the management account.

Avoid attaching a policy that disables Security Hub CSPM to the delegated administrator account. If a policy disables Security Hub CSPM for the delegated administrator in a Region, Security Hub CSPM removes its member associations and its administrator designation in that Region.

Migrating from central configuration

If you use Security Hub CSPM central configuration, migrate by using the import tool in the Security Hub console. The tool creates and attaches equivalent Security Hub CSPM policies for your existing configuration policies and associations. Attaching any Security Hub CSPM policy outside the tool disables central configuration for your entire organization. Accounts that central configuration previously governed might then have no policy.

Communicate and train

Tell account owners that the organization policy now drives their Security Hub CSPM configuration. Explain three points: they can't change policy-managed settings from their accounts, a policy can change which standards and controls are active in their accounts, and ungoverned Regions keep their existing settings. Clear communication helps account owners understand the findings they receive and the controls that apply to them.

Monitoring and validation

After you attach or modify a policy, run DescribeEffectivePolicy for representative accounts to confirm that the policy resolves as intended. A Region-specific configuration fully replaces the default, so DescribeEffectivePolicy is the most reliable way to catch a Region that unexpectedly lost a standard or control. Confirm that new accounts inherit the intended configuration. Review policy attachments periodically, and after any organizational change, to make sure coverage matches your structure and requirements.

Troubleshooting strategies

Use the following strategies when you troubleshoot Security Hub CSPM policies:

• Disable takes precedence over enable. If a Region appears in both Region lists, the policy disables it. The same applies to a control that appears in both control lists.

• A Region-specific configuration fully replaces the default. If a standard or control seems to be missing in one Region, check whether a Region-specific configuration omitted it.

• A Region in neither Region list is ungoverned, not disabled. If a Region shows no policy effect, confirm whether you intended to govern it.

• Enforcement is eventually consistent. A policy change applies asynchronously, and Security Hub CSPM periodically corrects drift. Allow time before you conclude that a change didn't take effect.

• Trace the inheritance chain from the root down to understand how parent and child policies combine into each account's effective policy, and validate the result with DescribeEffectivePolicy.