Build a cloud coverage register before reading the score

TL;DR: A platform score is interpretable only within its observed scope. Build a resource-level coverage register with collection method, freshness and known gaps before ranking the findings.

Where you are. This starts the cloud course with the evidence contract used by every later review.

Build the denominator outside the findings feed

The fictional customer platform has production, staging and an acquired account. Organization and billing records establish that all three belong in the review. The security platform currently sees only the first two. Start with that independent scope and left-join observations onto it; starting with findings would omit anything never collected.

“Fresh” is specific to a method and policy. It is not a universal property of an account. A configuration scan from this morning cannot establish whether a process ran during a sensor outage this afternoon.

Establish the independent inventory

The fictional platform operates a production cloud account, a staging account and an acquired account. Production has API-based posture collection and runtime sensors. Staging has posture collection but no workload sensors. The acquired account appears in billing records but is not connected to the security platform.

Create one inventory row per important resource group and record its owner, purpose and environment. Use billing and organization records as independent evidence of scope. Do not derive the denominator entirely from the security platform, because a disconnected account may be absent from its view.

Separate collection methods

Configuration collection can describe policies and network settings. Entitlement analysis can model possible access. Data classification can identify sensitive stores within its inspection scope. Runtime collection can observe supported events while its sensors are healthy. Keep these as separate columns with last successful observation times.

An account-level connection does not prove every service is supported. A managed data service may expose different audit events from a host. A disk inspection can identify installed files without observing a process that ran between scans. The coverage register should make these differences visible.

Define what unknown means

The acquired account is not clean; it is unassessed. Staging runtime is not quiet; it is unobserved by the intended sensor. An encrypted data object may be discovered but not classified. These are distinct gaps with different owners and remedies.

Assign a next evidence request to each gap. For the acquired account, first confirm control and authorized access. For staging runtime, decide which event sources are required for the service's risk. Installing an agent everywhere without checking support or purpose is not a coverage strategy.

Review the collector boundary

Read-only configuration access, disk access, content classification and remediation permissions have different consequences. Record what each integration can read or change and where it processes copied material. A security platform should not receive broad write authority merely because it needs to report a misconfiguration.

The resulting register is the basis for prioritization. A low score over a small known subset cannot be described as low risk across the company. Keep assessment completeness and observed risk as separate statements so that later improvements in inventory do not look like unexplained regressions.

Join inventory and collection without losing missing rows

The register needs stable asset identity, method, last successful observation, collection status, supported scope and evidence owner. Record collector errors separately from the last successful result. Otherwise yesterday's successful snapshot can remain green indefinitely while today's collection fails.

inventory = {"prod-worker", "stage-worker", "acquired-portal"}
required = {"configuration", "runtime"}
observations = {
    ("prod-worker", "configuration"): {"ok": True, "at": 95},
    ("prod-worker", "runtime"): {"ok": True, "at": 98},
    ("stage-worker", "configuration"): {"ok": True, "at": 92},
    ("stage-worker", "runtime"): {"ok": False, "at": 99},
}

def state(asset, method, now=100, ttl=10):
    row = observations.get((asset, method))
    if row is None: return "missing"
    if row["ok"] is not True: return "failed"
    if not 0 <= now - row["at"] <= ttl: return "stale"
    return "observed"

register = {(asset, method): state(asset, method)
            for asset in inventory for method in required}
assert len(register) == 6
assert sum(value == "observed" for value in register.values()) == 3
assert register[("acquired-portal", "configuration")] == "missing"
assert state("stage-worker", "configuration", now=103) == "stale"
# Losing the collector cannot remove its asset from the denominator.
del observations[("prod-worker", "runtime")]
assert state("prod-worker", "runtime") == "missing"
assert len(inventory) == 3
print(len(register), sum(value == "observed" for value in register.values()))  # => 6 3

The ten-unit freshness limit is a fixture policy. A real register may require different limits for configuration snapshots and event streams. It also needs service-specific requirements: a host sensor is not applicable to every managed service. An approved not-applicable result should name the alternative evidence or explain why the control is outside scope. It must not be inferred simply because no sensor exists.

Do not combine failed, missing and stale into a hidden null. Their remedies differ. Missing may require onboarding; failed may require permissions or connectivity repair; stale may require scheduling or liveness investigation. An unsupported service needs an explicit alternative, not repeated retries of an incapable collector.

Track identity and time at the right granularity

An account connection can hide missing regions, excluded resource types or denied API calls. Enumerate the scope the connector claims, then compare it with the inventory. Keep resource generation or creation identity where names can be reused. A retired node's healthy status must not transfer to a replacement with the same display name.

For dynamic workloads, a point-in-time count is insufficient. A node that lived ten minutes entirely without a sensor may be gone before the daily inventory snapshot. Retain lifecycle events and evaluate coverage over active intervals. The later runtime lesson computes this explicitly; the register should already define which evidence is needed.

Keep assessment completeness and observed findings as separate dimensions. Three fresh observations out of six required asset-method pairs describes this small fixture's collection completeness. It says nothing about how many controls passed within those observations, and it is not a weighted estimate of business risk. Report the unassessed acquired portal directly.

Review the collector as a sensitive integration

A configuration collector, a disk snapshot reader and a data classifier have different access. Classifying customer documents may require reading content that a posture collector never needs. Record the principal, permissions, data location, retention and operator access for each integration. Remediation write authority should be separately justified and controlled.

Test denied access as well as expected collection. A connector intended to read configuration should fail to mutate resources. A content classifier should not read unrelated stores merely because a broader account role is convenient. Use synthetic objects and approved receipt checks rather than real customer data in acceptance exercises.

A complete register assigns the missing evidence to someone who can obtain it. “Security owns the platform” does not mean security can confirm the acquired account's legal owner or the service team's required runtime events. Route each question to the accountable role and record the response deadline.

Do this before moving on

Run the register program and add a second region containing a new worker with no observations. Define its required methods explicitly. Produce a table with one row per asset-method pair and a separate list of control findings for the observed subset.

Assign owners for the acquired portal, failed staging runtime source and stale configuration snapshot. Specify the smallest acceptance test that would close each gap, including the evidence receipt and freshness requirement.

Review your result. Every independent inventory asset remains in the denominator. Missing and failed sources do not become clean controls. Your report separates collection completeness from findings and explains any approved not-applicable method with an alternative or scope reason.

Go deeper

• CNAPP coverage explains the different collection and response components.
• CSPM defines the configuration evidence used in the next lesson.
• CNAPP acceptance interview tests the register against lost permissions and unsupported resources.

Key takeaways

• Use an independent inventory denominator.
• Track method and freshness per required observation.
• Assign unknown coverage an owner and next evidence request.