GreyAware Request a demo
Menu

Control coverage · Practical field guide

A practical guide to security control coverage

Build a clear review of expected controls, matched evidence, freshness, and exceptions—then turn potential coverage gaps into owned work.

By GreyAwareUpdated Free to read · No form required

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.

Classify the evidence before choosing the action
CategoryWhat it meansNext review
Observed, currentMatched evidence meets the defined freshness rule.Assess health and policy separately where required.
Observed, staleA match exists, but the evidence is too old.Check device lifecycle, connectivity, and collection.
Unmatched or ambiguousNo reliable control match is available.Investigate identity and source completeness.
Approved exceptionA 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