Detecting drift between two audits
Two audits, same verdict, same score — and an estate that has moved underneath. Drift detection compares findings resource by resource rather than verdict by verdict, which is how you see the three new gaps hiding behind the two that were fixed.
The blind spot a score cannot see
Take a control that was non-compliant in March and is still non-compliant in June. The verdict has not changed, so the score has not changed, and a comparison of the two audits reports nothing.
Except that in March it flagged two service accounts, and in June it flags three different ones. The two originals were fixed; three new ones appeared. Remediation worked and the estate got worse at the same time, and neither the verdict nor the score says a word about it.
This is not an edge case. On a cloud estate where resources are deployed by pipeline, it is the normal state of affairs.
Comparing findings, not verdicts
Drift detection compares the named objects in each finding between two audits, including when the verdict is identical on both sides, and produces two lists:
| List | What it contains | How to read it |
|---|---|---|
| New findings | Objects at fault in audit B that were not in audit A | This is the drift. It almost always points to a deployment that did not follow the standard — a pipeline to fix, not just a resource. |
| Resolved findings | Objects at fault in audit A that no longer are in B | This is the proof of work done, object by object. The substance of an end-of-project debrief. |
Both lists carry the control title, its level and the object concerned, and both are included in the CSV export of the comparison — which is what makes them usable in a meeting rather than merely visible on a screen.
Why the naming format matters
Drift only works because findings are written the same way every time. On Active Directory that means the object's distinguished name; on Entra ID, the object identifier or the policy name. The identifier makes the finding actionable and removes the ambiguity between two objects with the same display name; it is the key the comparison joins on. Without a stable name, drift is invisible.
Which is why renaming resources looks like drift. A resource renamed between two audits appears as one resolved finding and one new finding. It is worth knowing before you present the list as evidence of anything.
The condition nobody respects the first time
Comparing two audits run on different scopes produces differences that mean nothing. Same baseline, same perimeter — the same tenant, the same domain — or the comparison is arithmetic rather than information.
The most common way this goes wrong is silent: a service becomes unreachable between two audits, gets excluded from the scope, and the score rises because its findings simply disappeared. Nothing was remediated. This is why the connector reports what it could reach, and why that belongs in your notes.
What a rising score can actually mean
- Remediation. The one you were hoping for.
- Deletion. Resources removed rather than fixed. Legitimate, but not the same story.
- Scope reduction. A service excluded, a baseline modified mid-engagement.
- Controls not evaluated. A missing role assignment turns failures into “not evaluated”, and not evaluated is excluded from the calculation.
The resolved-findings list separates the first two immediately; the scope notes in the report handle the last two. Which is the whole point of reading them before commenting on progress.
Using it in practice
- Pin the initial audit as the reference run. It is excluded from retention purging, and it is what every later comparison anchors to.
- Attach a note to each audit: “initial audit”, “after the MFA rollout”, “reduced scope, legacy domain excluded”. Six months later, that one line is the difference between an explicable curve and a mysterious one.
- Re-run the same baseline on the same perimeter. Freeze it for the duration of the engagement.
- Read the new findings first, before the score. A recurring stream of new findings on the same control is a standard problem, not an operations problem.
- Take the resolved list to the debrief. “Here are the fourteen resources you fixed, by name” is a better closing slide than a score that moved eight points.