Passing because there was nothing to check

Business Challenge

#43 built the account these findings land in, and #74 was about what a GuardDuty severity does and does not encode. This is the same question asked of the number executives actually look at.

The definition is plain, and narrower than its presentation: “Security scores represent the proportion of Passed controls to enabled controls.”

Controls, not resources. A control is Passed when “all findings have a compliance status of PASSED” — which turns the whole thing on what counts as a finding, and on what happens when there are none.

1Having no resources is a pass

Stated directly: “If you don't have resources corresponding to a control, Security Hub CSPM produces a PASSED finding at the account level.”

So an account with no S3 buckets passes every S3 control. An account with no RDS instances passes every RDS control. That is defensible as a design — there is genuinely nothing misconfigured — and it means a score is partly a measure of how little an account contains.

The sharper case is the one next to it: “If you have a resource corresponding to a control but then delete the resource, Security Hub CSPM creates a NOT_AVAILABLE finding and archives it immediately. After 18 hours, you receive a PASSED finding because you no longer have resources corresponding to the control.”

Delete the failing bucket and the control goes green in under a day. Not because anything was remediated — because the subject of the finding stopped existing.

Fix

Read a Passed control as "nothing here is failing" rather than "this is configured correctly". For a standard you care about, track resource counts alongside the score.

2Suppressing findings raises the score, and AWS says so

Control status is computed from a filtered population: “When determining control status, Security Hub CSPM ignores findings that have a RecordState of ARCHIVED and findings that have a Workflow.Status of SUPPRESSED.”

The scoring page spells out the consequence without euphemism: “Security Hub CSPM ignores archived and suppressed findings when calculating control status. This can impact security scores. For example, if you suppress all failed findings for a control, its status becomes Passed, which can in turn improve your security scores.”

And there is a second, quieter route to the same place. A control has status No data if “all of its findings are SUPPRESSED”, and “Controls with a status of No data are excluded from the score calculation.” Suppress everything and the control leaves the denominator entirely.

#74 found the same instinct costing something different in GuardDuty, where suppressed findings stop acting as signals for attack sequences. Same action, two unrelated consequences, neither visible from the dashboard that prompted it.

Fix

Treat suppression as a score change, and review suppressed findings on the same cadence as failing ones.

3The summary score is described two ways, and they do not agree

Near the top of the scoring page: “The summary security score is the average of the standard security scores.”

In the worked example lower down, after establishing that “Security Hub CSPM counts each control only once across standards”: “If we assume the number of unique enabled controls is 515, and the number of unique passed controls is 357, the summary score is 69%. This score is calculated by dividing the number of unique passed controls by the number of unique enabled controls.”

The example's own five standard scores are 88, 22, 15, 74 and 62. Their average is 52%. The division gives 69%. Seventeen points apart, on the same page, from the same numbers.

The deduplication method is the one the example demonstrates and the one consistent with counting each control once, so that is the behaviour to reconcile against. But if you have ever tried to explain why a summary score does not look like the average of the standards above it, this is why the explanation was hard to find.

Fix

Reconcile against unique passed over unique enabled controls, not against the mean of the standard scores.

Architecture

Two roll-ups: findings into a control status, control statuses into a score. Each one drops a population.

Diagram: how Security Hub CSPM turns control findings into a control status and control statuses into a security score, and which populations each step drops. The Compliance.Status field of a control finding takes four values. PASSED indicates the control passed the security check for the finding and automatically sets the workflow status to RESOLVED. FAILED indicates the control did not pass. WARNING indicates Security Hub cannot determine whether the resource is in a passed or failed state, for example when AWS Config resource recording is not turned on for the corresponding resource type. NOT_AVAILABLE indicates the check cannot be completed because a server failed, the resource was deleted, or the AWS Config evaluation result was NOT_APPLICABLE, in which case the finding is automatically archived. Three routes produce a pass without anything being remediated: if you have no resources corresponding to a control, Security Hub produces a PASSED finding at the account level; if you delete a resource corresponding to a control, Security Hub creates a NOT_AVAILABLE finding, archives it immediately, and after eighteen hours produces a PASSED finding because you no longer have resources corresponding to the control; and because control status ignores findings whose record state is ARCHIVED or whose workflow status is SUPPRESSED, suppressing all failed findings for a control makes its status Passed. Control status takes five values: Passed when all findings are PASSED; Failed when at least one finding is FAILED; Unknown when at least one finding is WARNING or NOT_AVAILABLE and none is FAILED; No data when there are no findings, including when a control is newly enabled, when all of its findings are suppressed, or when it is unavailable in the current Region; and Disabled when the control is disabled in the current account and Region, though its findings may retain a compliance status for up to twenty-four hours after disablement. The score is the proportion of Passed controls to enabled controls, where enabled controls for scoring purposes are those with status Passed, Failed or Unknown, and controls with status No data are excluded from the calculation. A panel records that the scoring page describes the summary score two incompatible ways: near the top it states the summary security score is the average of the standard security scores, while the worked example divides unique passed controls by unique enabled controls after noting that each control is counted only once across standards. On the page's own example the five standard scores of 88, 22, 15, 74 and 62 average to about 52 percent while the stated division of 357 by 515 gives 69 percent, a gap of seventeen points, and the deduplication method is the one the example demonstrates. A further panel records the asymmetry across accounts and Regions: if the status of a control is Failed in even one member account its status is Failed in the administrator account, and if it is Failed in even one linked Region its status is Failed in the aggregation Region, so failure propagates upward while a pass can arise from local absence. A closing panel notes the operational dependencies: AWS Config resource recording must be configured for control status and scores to appear, scores are generated only for standards enabled when the Summary or Security standards console pages are visited, first generation happens within thirty minutes and thereafter statuses and scores update every twenty-four hours based on the previous twenty-four hours of findings, enabling a new aggregation Region or updating linked Regions resets existing scores, and turning on consolidated control findings can take up to twenty-four hours to be reflected. — Findings roll into a control status; control statuses roll into a score. Each step excludes a population.

Compliance status, and what each value actually means

Value	AWS's definition	Consequence
`PASSED`	“the control passed the security check for the finding”	Also “automatically sets the Security Hub CSPM `Workflow.Status` to `RESOLVED`”
`FAILED`	“the control didn't pass the security check”	One of these makes the whole control Failed
`WARNING`	“can't determine whether the resource is in a `PASSED` or `FAILED` state”	Named cause: “AWS Config resource recording isn't turned on for the corresponding resource type”
`NOT_AVAILABLE`	“a server failed, the resource was deleted, or the result of the AWS Config evaluation was `NOT_APPLICABLE`”	If `NOT_APPLICABLE`, Security Hub “automatically archives the finding”

WARNING deserves attention because its named cause is a configuration gap on your side rather than a problem with the resource. A resource type that AWS Config is not recording produces findings Security Hub cannot evaluate — and those roll up to control status Unknown, which counts as an enabled control in the score's denominator and not in its numerator. Incomplete Config coverage is therefore a score penalty that reads like a security finding.

The two exclusions, and which direction each moves the number

“For purposes of score calculation, enabled controls include controls with a status of Passed, Failed, and Unknown. Controls with a status of No data are excluded from the score calculation.”

So No data leaves the calculation entirely, and a control reaches No data by three routes: it is newly enabled and has not produced findings yet, all of its findings are SUPPRESSED, or it is “unavailable in the current AWS Region”.

Disabled is removed from the calculation too, and AWS says so rather than leaving it to be inferred — disabling a control for a standard “also removes the control from calculations of the security score for each of those standards.”

That has a subtlety worth holding onto, because it interacts with the deduplication rule: “If the control is enabled in other standards… Security Hub CSPM also includes the control when it calculates the security score for each of the other standards, which affects your summary security score.” So a per-standard disablement raises that standard's score and leaves the summary untouched, provided the control is enabled somewhere else. Two numbers move differently from one action.

With one timing detail worth knowing during an audit: “the findings of a disabled control may have a value for compliance status for up to 24 hours after disablement”, while the findings themselves “are archived automatically, typically within 3–5 days on a best-effort basis”.

Failure propagates upward; passing does not have to

Two statements with the same shape: “If the status of a control is Failed in even one member account, its status is Failed in the administrator account and impacts the administrator account scores,” and “If the status of a control is Failed in even one linked Region, its status is Failed in the aggregation Region.”

That is the right design — an administrator's score should not hide a member's failure. The asymmetry is what it means in reverse: a control reads Passed at the top when every account and Region below is Passed, and any of those may be passing because it has no corresponding resources. An organisation-wide green is an aggregate of local silences as much as local successes.

Why This Architecture Holds Up

The score is honest about being a control ratio; it is the reading that adds meaning

Nothing above is undocumented or surprising to the people who built it. “the proportion of Passed controls to enabled controls” is an accurate description of exactly what is computed. Every behaviour in this post follows from that sentence plus the definitions of the statuses.

The trouble starts when the number is used as a proxy for something it does not measure. Two accounts at 88% can differ by every resource they contain. A number that rises when you delete a resource, rises when you suppress a finding, and rises when you disable a control is not tracking risk; it is tracking the ratio it says it tracks.

Deduplication across standards is the part worth understanding

“When calculating the summary security score, Security Hub CSPM counts each control only once across standards. For example, if you have enabled a control that applies to three enabled standards, it only counts as one enabled control for scoring purposes.”

In AWS's example the standards total 528 enabled controls while the unique count is assumed to be 515, so the overlap between standards is real but modest. The practical consequence is that enabling an additional standard whose controls you already have enabled elsewhere changes the summary score very little, while enabling one with genuinely new controls can move it sharply — in whichever direction those new controls happen to evaluate.

Disabling a control is not a durable decision

The intent of disablement is reasonable — AWS frames it as noise reduction: “To reduce finding noise, it can be helpful to disable controls that aren't relevant to your environment.” What it is not is a setting that survives a standards change.

“When you disable a standard, Security Hub CSPM doesn't track which controls were disabled for the standard. Consequently, if you later re-enable the same standard, all the controls that apply to it are automatically enabled.”

And more broadly: “Disabling a control isn't a permanent action. Suppose you disable a control, and then enable a standard that includes the control. The control is then enabled for that standard.”

So a carefully curated set of disablements is undone by enabling a standard that happens to include those controls — and the score moves without anybody editing a control. If your disablements encode real decisions about what is irrelevant to your environment, they belong in something that can reapply them, because Security Hub is explicit that it is not remembering them for you.

Disabling across all standards also reaches outside Security Hub: “Security Hub CSPM removes any related AWS Config rules that it created for the control.” Per-standard disablement does not, where the control remains enabled elsewhere — it “retains the associated AWS Config rule, if applicable”.

Two operations reset or delay the number, and both are routine

“enabling a new aggregation Region or updating linked Regions resets existing security scores. It can take up to 24 hours for Security Hub CSPM to generate new security scores that include data from the updated Regions.” And separately, “If you turn on consolidated control findings, it can take up to 24 hours for your security scores to update.”

So a Region change during a compliance window produces a score that is reset rather than low, and the two look identical on a dashboard. Worth knowing before somebody explains a dip to an auditor.

Everything here depends on AWS Config, in two places

“You must have AWS Config resource recording configured for the control status to appear”, and for scores, “AWS Config resource recording must be configured for the scores to appear.”

Partial Config coverage therefore has two distinct effects rather than one. Resource types that are not recorded produce WARNING findings and Unknown controls, which depress the score; and the controls affected are the ones you have least visibility into, so the score drops precisely where you know least.

The cadence is slower than people assume

First generation is prompt — “within 30 minutes of your first visit to the Summary or Security standards page”, and only “for standards that are enabled when you visit those pages”. After that, “Security Hub CSPM updates control statuses every 24 hours based on the findings from the previous 24 hours” and scores likewise.

So a remediation does not show up the same afternoon, and a score shown to a meeting is a snapshot of the preceding day. The timestamp is on the control details page for exactly this reason.

Key Architecture Decisions

Decision	Choice	Reasoning
What the score is used for	Trend on one account over time, not comparison between accounts	It is a control ratio, and two accounts at the same score can hold entirely different resources.
Reading a Passed control	"Nothing here is failing", not "this is configured correctly"	No corresponding resources produces a `PASSED` finding at the account level.
Suppression	Treat it as a score change and review on a cadence	Suppressing all failed findings for a control makes its status Passed; suppressing all findings makes it No data and removes it from the ratio.
Reconciling a summary score	Unique passed over unique enabled controls	That is the method the worked example demonstrates; the mean of standard scores gives a different answer.
AWS Config coverage	Record every resource type the enabled standards evaluate	Unrecorded types yield `WARNING` and Unknown, which count against the score.
A sudden score drop	Check for a Region or aggregation change first	Those reset scores, and a reset looks like a decline for up to 24 hours.
Expecting remediation to show	Allow a day	Statuses and scores update every 24 hours from the previous 24 hours of findings.
Organisation-level reporting	Report failures by account, not the administrator's score	Failure propagates upward, so the administrator score tells you something failed somewhere, not where.
Disabling a control	Record why, and keep the set in code that can reapply it	Disabling removes the control from the score with no change to the environment — and re-enabling a standard re-enables every control that applies to it, because Security Hub doesn't track which were disabled.
Per-standard vs all-standards disablement	Know which you are doing	Per-standard removes it from that standard's score only, and the control still affects the summary via other standards; all-standards also removes the AWS Config rules Security Hub created.

The audit worth running

For each enabled standard, list controls by status and count the No data ones. Each is a control that is neither passing nor failing and is not in the ratio, and the three causes — newly enabled, fully suppressed, unavailable in this Region — need different responses.

Then count Unknown controls and check AWS Config recording for the resource types they evaluate. That population is the gap between what the standard intends to check and what it was able to check, and it is the one that makes a score look worse than the environment is.

Closing Thought

The sentence to keep is the one AWS leads with: the score is “the proportion of Passed controls to enabled controls”. Everything surprising here is a faithful consequence of that, plus the fact that a control with nothing to evaluate passes. Deleting a resource, suppressing a finding and disabling a control all move the number the same way because all three reduce the quantity of evaluated failure, which is what the ratio counts.

That makes it a good operational trend line and a poor comparative metric. Within one account over time, with the resource population roughly stable, a rising score means something. Across accounts, or across a quarter in which somebody decommissioned a workload, it mostly reports how much there was to check.

Which is the block's recurring shape once more. #72 was a resource accumulating against a ceiling. #73 was a schedule quietly not running. #74 was a detection capability quietly reduced. This one is a metric quietly measuring something adjacent to what it is read as measuring — documented, intended, and invisible from the dashboard that displays it.

Next in this series

Security & Identity — IAM Access Analyzer unused access findings: what counts as unused, why the tracking period is not a sliding window in the way people assume, and how an analyzer's findings differ from the last-accessed data in the console.

AWS Architecture Series #75 — Passing because there was nothing to check