LEARN. PRACTICE. GROW.1. Identify who configures the service
Security Hub CSPM supports central management through the delegated administrator with Organizations integration. Policy defines whether the service, standards, and controls are enabled and can parameterize certain controls. Creating policy does not apply it: target association is required. Distinguish the stored definition from configuration that actually reached accounts. A centrally managed account receives these settings through central administration within the relevant scope. A self-managed account retains its own management. This lesson concerns these CSPM mechanisms; it does not treat Security Hub V2 aggregation APIs as equivalent. Before a change, record the administrative account, home Region, targets, and validation owners. That inventory avoids asking a local team to make a change belonging in central policy.
2. Resolve inheritance and exceptions
Directly applied configuration takes precedence over inheritance, including when that direct application is self-managed. Moving an account into a production OU is insufficient to prove it received that OU policy. Check effective association and document exceptions with an owner and review. A target can use only one configuration policy at a time, and that policy describes a complete set. Do not mentally combine controls from two policies as selective layers. The local exercise resolves a fictional hierarchy: it first looks for applied configuration at the node, then walks upward to the nearest configured parent. This is only a precedence model; it does not prove real association success or service operation in every Region.
3. Plan regional scope changes
A policy applies to the home Region and linked Regions, with documented exceptions for global-resource controls and regional availability. It does not provide an arbitrary selector for a subset of those Regions. An opt-in Region needs account enablement. Removing a linked Region ends central application there but preserves existing settings. Changing or removing the home Region has greater impact: policies and associations are deleted while accounts retain configuration. The change plan should preserve intended settings, rebuild management, and include tests. Do not describe a regional change as merely moving the dashboard. Coordinate security and RUN to identify who manages each scope afterward and what evidence confirms transition.
4. Confirm application and evaluation capability
PENDING is an in-progress state, and FAILED does not mean everything was rolled back. Some settings can apply even when association fails. Inspect results and messages to locate the problematic account, Region, or setting. Check prerequisites, including AWS Config recording of relevant resources. Even SUCCESS does not indefinitely guarantee finding generation: a standard can enter incomplete enablement. Define acceptance in two layers, intended association and operational evaluation. For new controls, deliberately choose between an enable list and an exclusion list; the latter enables the remainder, including new releases within enabled standards. That choice affects change management and needs an owner tracking what becomes evaluated.
5. Distinguish workflow from technical effect
Workflow state belongs to the individual finding. Marking RESOLVED does not reconfigure the resource or prevent new findings for the same issue. When compliance changes from PASSED to FAILED, a resolved finding can automatically return to NEW. The team should interpret that transition as renewed investigation need, not automatic proof of faulty duplication. Suppressions also need justification and scope. When evaluating a control, the service ignores archived or suppressed findings; changing finding treatment can therefore alter an indicator without changing the resource. Keep treatment-decision evidence separate from remediation evidence. At handover, identify who tracks regressions and how the team validates the effect of a claimed correction.
6. Explain the score to the sponsor
The score depends on which controls enter calculation. No data is excluded; it is not converted into Passed. Under the detailed summary-score calculation rule, each unique control counts once across standards. A report summing repeated occurrences changes the denominator. To compare periods, also present coverage, suppression, and changes in standards or Regions. If the percentage rose after losing data, do not translate it into an equivalent exposure reduction. Show which resources were actually remediated and which checks lost evidence. This lesson connects four stages: policy intent, scope association, evaluation execution, and result interpretation. Each stage has a different owner and proof needed for a credible production handover.
# Original fictional precedence model, not Security Hub configuration.
# No credentials, network calls, or AWS changes.
parents = {"account": "prod", "prod": "root", "root": None}
def effective(node, applied):
while node is not None:
if node in applied:
return applied[node]
node = parents[node]
return "unconfigured"
assert effective("account", {"root": "baseline"}) == "baseline"
assert effective("account", {"root": "baseline", "prod": "strict"}) == "strict"
assert effective("account", {"prod": "strict", "account": "self-managed"}) == "self-managed"
assert effective("account", {"prod": "self-managed"}) == "self-managed"
assert effective("account", {}) == "unconfigured"
print("five precedence cases passed; association success was not evaluated")
An account retains self-managed behavior despite entering the production OU; the team identifies the exception before declaring harmonization.
Common pitfalls
OU as inheritance proof; SUCCESS as permanent health; RESOLVED as remediation; No data as Passed.
Related topics: Telemetry and investigation · Governance and evidence
A defined policy and a high score need evidence of application and evaluation across intended scope.
Reference: Security Hub CSPM central configuration · SCS-C03