How do you build the applicability set for an encryption-at-rest control across cloud accounts?
answer
- start from the thing that cannot hide
- the tool's own findings are not the population
- containers first, then resources
- inventory is the reconciliation target
- missing attribute defaults to in scope
basics
~20 sEnumerate from an authoritative source that owns the whole estate — the organisation's account directory, then each account's own resource listing — never from the checking tool's own findings. Reconcile against the asset inventory and treat every discrepancy as a finding.
solid answer
~50 sI build it in two stages from sources that cannot quietly be incomplete. First the containers: every account, subscription or project in the organisation's directory, which is hard to hide because it is tied to billing and identity. Then, inside each one, the resources, listed from the provider's own resource API rather than from a hand-maintained list. The asset inventory is the reconciliation target, not the source — it is human-maintained and always lags, so I compare the two and treat each difference as a finding rather than picking whichever list is smaller. Applicability filters must come from data on the resource itself, and an unlabelled resource defaults to in scope, because a missing tag is not evidence of anything. Finally, every account where collection failed is recorded as unassessed with a reason code, so under-coverage is loud rather than a slightly smaller denominator.
go deeper
Know that a control needs a list of the systems it applies to, and that this list has to come from somewhere other than the tool doing the checking. Be able to say why a hand-maintained list goes stale.
Walk through the two-stage enumeration — containers from the organisation's directory, resources from the provider's listing API — and explain why the asset inventory is reconciled against rather than trusted as the source.
Show you have hit the quiet failures: a region never queried, a read role never deployed into a new account, a tag-based filter that lets untagged resources leave scope. Explain how you make each one loud.
Decide who owns population completeness as a standing responsibility, and make 'containers in the directory versus containers successfully collected' a reported metric rather than something a scheduled job knows and nobody reads.
The applicability set — the population a control is measured against — is the part of a compliance check that no rule language helps you with. The rule decides whether one resource complies. The applicability set decides which resources ever get the question asked, and it is where most real coverage gaps come from. ## The circular denominator The defining mistake is deriving the population from the same tool that reports on it. If the checker enumerates twelve accounts, evaluates what it finds, and then reports a percentage over that same set, the report is internally consistent and externally meaningless: it can only ever describe the tool's own configuration. The population has to come from a source that exists for reasons unrelated to compliance, so it cannot be quietly trimmed to make the number better. ## Two-stage enumeration **Stage one, the containers.** Accounts, subscriptions or projects come from the organisation's own directory of them. This source is strong because it is load-bearing for other things: it is what gets billed, it is where identity federation is configured, it is what the provisioning process creates. An account that exists but is absent from it is itself a serious finding, and a rare one compared with an account that exists and was simply never added to a scanner config. **Stage two, the resources.** Within each container, list the resources from the provider's own listing API for that resource type, in every enabled region. Two failure modes recur here: regions that were enabled for one workload and never added to the query set, and resource types that are reachable under one API surface but not the one the collector uses. ## The inventory is a check, not a source An asset inventory or configuration database is maintained by people and processes, which means it lags creation and lags deletion. Using it as the population understates the estate. Ignoring it entirely wastes the one place where ownership, environment and data classification are recorded. The productive use is reconciliation in both directions: - **In the provider, absent from the inventory** — an unregistered system; nobody has claimed ownership of it. - **In the inventory, absent from the provider** — either a stale record, or a system living somewhere your enumeration does not reach. Both directions produce a finding with an owner. Neither is resolved by silently preferring one list. ## Applicability filters and the direction of the default 'Every managed database instance' still needs narrowing in practice — production only, regulated data only, this business unit only. Those filters have to be driven by attributes on the resource, and the default direction matters more than the filter. If the scope is 'resources tagged environment=production', then every untagged resource falls outside the control, and forgetting a tag becomes a way to leave scope. Inverting it — everything is in scope unless it carries an attribute that removes it, and missing attributes are themselves a finding — makes the failure mode visible rather than silent. ## Collection failure has to be loud The most common cause of silent under-coverage is banal: a new account is created through a path that does not deploy the collector's read role, so enumeration for that account fails or returns nothing. If the run treats that as 'zero resources found', coverage drops and the pass rate does not move. The run must distinguish 'enumerated, found nothing' from 'could not enumerate', record the second as unassessed with a reason, and compare accounts attempted against the directory count on every run. That comparison — accounts in the directory versus accounts successfully collected — is the single most useful coverage metric a control programme has. ## Recording the result The output of this work is not just a list. It is a population with provenance: which source produced each entry, when it was enumerated, which entries failed collection and why, and which were excluded from applicability by which attribute. That provenance is what makes the eventual percentage defensible to anyone who asks how you know the population is complete.
- A new account was created outside the provisioning path, so the collector's read role was never deployed. How does that surface?Only if the run compares accounts attempted against the organisation's directory. Otherwise enumeration for that account returns nothing, the run treats it as an empty account, and the pass rate is unaffected. The fix is to record failed collection as unassessed with a reason and alert on any directory entry with no successful collection.
- A team says their untagged instances are development and out of scope. How do you respond?A missing tag is not evidence of anything, so those instances stay in scope by default. If they genuinely are out of scope, that is a decision someone named approves in writing, with a rationale and a review date. Otherwise the shortest path out of a control is to forget a tag, and the scope shrinks itself.
- Should the population be rebuilt every run or maintained as a stored list?Rebuilt every run, with the previous run kept for comparison. A stored list decays exactly like an inventory does, and the delta between consecutive enumerations is valuable on its own — new resources, disappeared resources and containers that stopped collecting are all findings you would otherwise never see.
saying these in an interview costs you the question
- Uses the checking tool's own results as the population
- Treats the asset inventory as the authoritative estate list
- Scopes on a tag so untagged resources fall out silently
- Ignores accounts where enumeration failed
- Assumes one enumeration call covers every region
- Maintains the population as a hand-edited list