Assurance & drift
Your compliance score answers "is this control met?" Assurance answers a different question: "how much should we trust that answer?"
Both matter, and they can disagree. A control marked compliant on the strength of a screenshot somebody took eleven months ago is compliant and barely assured. A control with three current, verified pieces of evidence is compliant and well assured. The compliance score alone can't tell those apart — which is exactly the gap an auditor walks into.
Open it from Assurance in the Frameworks page header.
Read the dashboard
Controls are listed weakest first, because the bottom of that list is your work queue. Each row carries a per-control confidence score derived from the evidence behind it: how much there is, how well it verifies, and how current it is.
Controls with no snapshot yet are counted separately. They aren't scored badly — they aren't scored at all, and that distinction is deliberate. An unmeasured control should never be mistaken for a confident one.
The interesting controls are the ones where compliance is high and assurance is low. That combination is where a clean-looking program is resting on evidence that won't survive being asked about.
Drift is what erodes a score
Compliance is a decision made at a point in time. The world then keeps moving: a cloud connector reports a configuration change, a policy is superseded, a document ages past its review date. Those are drift events — signals that something behind a control may no longer be what it was when you assessed it.
Unacknowledged drift events from the last 30 days carry a penalty against the control's assurance score. That is the mechanism by which a program that stops being maintained visibly decays, rather than quietly going stale while its dashboard still reads green.
Acknowledging drift
Acknowledging a drift event removes it from the penalty calculation on the next assurance compute. Acknowledgement means "I've seen this and it doesn't change the verdict" — not "make the warning go away."
If the signal does change the verdict, the honest move is to reassess the control and refresh its evidence. The score will recover on its own once real evidence backs it.
An acknowledgement is an assertion by a named person that the drift doesn't undermine the control. It's part of the trail. Clearing a backlog of drift events without reading them produces a confident-looking score with nothing behind it — the precise failure this dashboard exists to make visible.
Where the score moves on its own
You don't have to compute assurance by hand. Scores refresh on the next assurance compute after the things they depend on change — evidence attached or expired, control status changed, drift acknowledged. The trend widget surfaces controls whose assurance is falling, which is usually a better place to start than the absolute worst score: a control that has always been weak is a known gap, while one that is becoming weak is a new one.
How this connects
- Evidence quality and freshness drive most of the score — see Evidence quality & freshness.
- Cloud posture findings are one source of drift signals — see Findings to frameworks.
- Compliance scoring itself is covered in Assess controls.