Coverage Drift

A control is implemented, tested, and works. The estate then grows around it: new services created outside the template it lives in, new accounts outside the policy's scope, new repositories outside the scanner's configuration.

The control's coverage shrinks while its pass rate stays at one hundred percent, and every assessment of the systems it covers is clean.

Why it matters

It is a failure with no signal. Unlike a control that breaks, a control whose reach narrows produces no errors, no failed builds and no alerts — and the assessment methodology, which examines the systems the control knows about, cannot detect it by construction.

It is also the normal state of any control in a growing organisation unless coverage is measured deliberately.

Implementation patterns

• Measure coverage against the authoritative inventory, not against the systems the control already knows about. That inversion is the entire point, and it requires an inventory that is generated rather than maintained.
• Report coverage as a first-class control metric alongside pass rate — a control at 100% pass and 60% coverage is providing 60% of its intended assurance.
• Make the compliant path the default, so new systems inherit the control from the template rather than needing to be added to it. A guardrail changes what the easiest behaviour is; a gate only checks the behaviour it can see.
• Alert on the appearance of systems outside coverage, which is the detection that closes the gap.
• Monitor the control's own health: execution count, failure rate, and time since last execution — because a control that stopped running produces silence, and silence looks like success.
• Fail closed, since failing open is the most common way a control becomes decorative: a credential expires, the error is swallowed, and the control has not operated for months.

Industry example

Regulated organisations such as Zerodha and Groww, and data-protection platforms such as Druva, all reach the same conclusion during their first serious assessment cycle: the control inventory looks healthy and the estate inventory does not match it.

The resolution is structural — paved roads that carry the controls, and coverage measured against an automatically generated inventory — rather than a remediation project, which is a treadmill.

Failure scenarios

• Coverage never measured, so drift is invisible.
• A manually maintained inventory, wrong within a quarter.
• Remediation by ticket, which never catches up with creation.
• Control health unmonitored, so a stopped control looks like a passing one.
• Assessment scoped to the control's known systems, which cannot detect the gap by design.

Trade-offs

Measuring coverage requires an authoritative inventory, which is real work and which many organisations do not have — and building it surfaces an uncomfortable number of systems nobody owns.

That discomfort is the finding. The alternative is an assurance position based on a control whose reach nobody has measured, which is a claim rather than a control — and the gap grows with the organisation, which means it is cheapest to close now.

Interview question

"Your dependency scanner reports zero critical findings and has for a year. What would you check before believing it?"