The key decision
Which assets have current evidence of the expected control, and which still need investigation?
1. Define what coverage means
A control coverage review asks whether an expected security control is observed for the assets that should have it. Start with a specific question, such as whether managed employee laptops have recent, matched EDR evidence. Avoid combining unrelated controls into one score before defining what each result means.
Keep three ideas separate: an asset is known, a control record is observed, and the control is operating as intended. A matched agent record supports the second claim. It does not, by itself, establish prevention effectiveness or that every required policy is active.
2. Establish the expected population
Choose the scope before counting control records. Record the asset types, organizational boundary, snapshot time, and documented exclusions. Start from inventory and reconcile it with management and security sources; starting only from the EDR console makes devices absent from that console easy to miss.
CIS Control 1 emphasizes managing enterprise assets across physical, virtual, remote, and cloud environments. Use that inventory principle to build a defensible review population.
Write an explicit expectation
For example: “Managed employee laptops in this review require a matched EDR record with evidence within our agreed freshness window.” Then name the source of ownership, the identifiers used for matching, and who approves exceptions. Keep unsupported devices and exceptions visible as distinct categories.
3. Match records and assess freshness
Preserve the original source records when reconciling identities. Prefer identifiers that remain useful through renames and re-enrollment; review conflicts instead of assuming every matching hostname represents the same device.
- Identity
- Which identifiers support the match? Could the record be a duplicate, reused name, or previous enrollment?
- Time
- When did the source last observe the device, and when was the record collected? A recent import can contain old evidence.
- Meaning
- Does the source describe installation, check-in, policy, health, or another condition? Do not substitute one for another.
- Expectation
- Does this control apply to the device’s role and current lifecycle state?
Set freshness windows with the teams that understand normal reporting behavior. An intermittently connected laptop and a continuously running server may need different review rules. Publish the chosen rule alongside the result.
4. Keep uncertainty visible
Use mutually exclusive review categories so every in-scope asset has a place. The following is a suggested reporting model, not a claim about a particular product’s status labels.
Scroll the table horizontally to view all columns.
| Category | What it means | Next review |
|---|---|---|
| Observed, current | Matched evidence meets the defined freshness rule. | Assess health and policy separately where required. |
| Observed, stale | A match exists, but the evidence is too old. | Check device lifecycle, connectivity, and collection. |
| Unmatched or ambiguous | No reliable control match is available. | Investigate identity and source completeness. |
| Approved exception | A documented exception applies. | Retain its owner, rationale, and expiry. |
5. Report a denominator people can trust
Illustrative example: a review contains 1,000 in-scope laptops. Of those, 900 have current matched EDR evidence, 40 have stale evidence, 35 are unmatched or ambiguous, and 25 have approved exceptions. These categories account for the full 1,000 devices.
90% observed-current coverage
900 current matches ÷ 1,000 in-scope devices.
If the team also reports coverage excluding approved exceptions, label that separate calculation: 900 ÷ 975 ≈ 92.3%. Show the 25 exceptions alongside it. Neither figure is a measure of detection effectiveness, and neither makes the 75 stale or uncertain devices disappear.
For a specific unmatched laptop, check the inventory record, stable identifiers, last observation, and collection status. A rename, retired asset, or delayed source can explain the result. If the evidence still indicates a deployment gap, assign an owner to validate and address it through the normal operational process.
6. Turn the review into owned work
Rank follow-up using the asset’s role, exposure, and evidence quality. A critical server without a reliable record may deserve attention before a retired laptop, even if both appear in an unmatched list.
- Record the asset, expected control, source evidence, and confidence in the match.
- Name the next validation step, responsible team, and review date.
- After action, obtain fresh evidence and reassess the same expectation.
- Report population changes separately from resolved findings when comparing periods.
Bring the evidence into a product evaluation
Use GreyAware to explore how asset records and observed controls can be correlated, then inspect the evidence behind potential gaps. Confirm supported sources, freshness, and matching behavior for your environment during evaluation.
Explore control coverage visibility Review asset inventory and correlation Use the EDR migration checklist Discuss your coverage review