Your nightly encryption-at-rest sweep reports zero violations — what must you know before that means anything?

## What a green sweep actually asserts A periodic compliance sweep enumerates live resources, evaluates a loaded set of rules against each one, and emits findings. When it prints `0 violations`, the honest reading is: *the rules that were loaded found nothing wrong in the resources that were enumerated*. Both halves are variables. Neither of them is visible in the number zero, which is why the number on its own carries almost no information. ## The two questions hiding behind the number **Which rules ran?** The enforcer does not carry its rules in its binary; it fetches a ruleset from somewhere at start-up or on a refresh interval. That fetch can return a stale copy, a copy that never contained the encryption-at-rest rule, a partially written bundle, or — in the interesting case — a complete ruleset that somebody else published. Every one of those outcomes yields zero violations. The pathological version is an empty ruleset: it evaluates nothing, finds nothing, and produces a flawless report. In this domain the failure mode that most resembles success is *no policy at all*. **What was enumerated?** A sweep over managed volumes and databases has to list accounts or subscriptions, then regions, then resource types, and page through each. A credential that quietly lost read access to one account, a region nobody added to the config, a resource type the enumerator does not know about, or a pagination bug that stops after the first page — each shrinks the denominator without touching the numerator. Zero findings across three resources and zero findings across thirty thousand render identically on the dashboard. ## Why this bites harder on a sweep than on a blocking gate A gate that blocks changes generates friction: people argue with it, so its liveness is continuously, if grumpily, confirmed. A periodic detective sweep has silence as its expected output. Nobody investigates a quiet control. That asymmetry is what makes a sweep worth attacking and worth instrumenting: you have to be able to distinguish *nothing is wrong* from *nothing was checked*. ## What the report has to carry - **Ruleset identity** — a digest computed over the rule content that was actually loaded, not the version string someone hoped was deployed. - **Rule inventory** — the list of rule ids evaluated in this run, and for each, how many resources it was evaluated against. A rule that evaluated zero resources is a completely different event from a rule that evaluated four thousand and found none non-compliant, yet both report zero violations. - **Scope enumerated** — accounts, regions and resource types with counts, so the denominator is on the page. - **Errors as a separate category** — unreachable accounts, expired credentials, throttled API calls. An enumeration failure is not compliance. If it is folded into the green count, losing access to an account looks exactly like cleaning it up. ## How to read it once you have it The useful signal is usually comparative rather than absolute. Per-rule evaluation counts that drop from thousands to zero, a rule id that vanishes from the inventory, a scope count that halves overnight — these are loud even while violations stay reassuringly at zero. Alerting on the *absence* of expected output is the habit that separates people who have operated a detective control from people who have only configured one. ## Language that keeps you honest The result of a sweep is not `compliant`. It is `no evidence of non-compliance was produced by ruleset <digest> over scope <S>`. That sentence is longer and less satisfying, and it is the one you can defend when somebody asks what the control actually established. It also makes the gaps obvious: change the ruleset and the claim changes; shrink the scope and the claim shrinks; lose the ruleset identity and there is no claim left at all, only a colour.