When configuration drift is detected, someone with authority should decide what happens to the change: keep it, revert it, or gate that kind of change from now on. Detection on its own only produces a signal. An owner, a response time and an escalation threshold turn that signal into security.
Change boards review the changes people propose. Drift is about the changes nobody proposed, and those need a process of their own.
What matters most
- Start with a declared baseline. Drift only means something against an approved state for your critical services.
- Know how old that baseline is. A baseline last updated for an audit describes the environment on the day of the audit.
- Give every finding an owner. Each drift finding needs a person, a response time and an escalation threshold.
- Decide, then record. Keep, revert or promote, with the decision and a name attached.
What is configuration drift?
Configuration drift is the gap between the baseline your team approved and what your tenant enforces today. An administrator edits a Conditional Access policy or a new license assignment alters defaults, and a control that was configured correctly no longer matches.
Some drift is harmless. The risk is that it goes untracked, so the baseline your security program relies on weakens without anyone deciding it should.
Where does configuration drift come from?
Changes someone proposed
These go through your change process. Someone asks about rollback and impact, and the change is approved or refused.
Changes no one proposed
An administrator edits a setting directly in an admin portal, or software acting on its own changes the tenant. Neither reaches the change board agenda.
Our post Guarding the Wrong Door makes the case that change control has guarded one door well while the other door never had a process behind it.
How should you respond to configuration drift?
- Declare the baseline. Define the approved state for your critical services, including which settings should be in place and which changes need approval.
- Measure its age. Note when the baseline was last updated and what triggered the update. The time since then is your window of unverified drift.
- Detect drift against it. Compare the live tenant with the baseline between assessments, and alert right away on changes to high-impact settings.
- Assign an owner and a response time. Give every finding a named owner, an expected response time and an escalation threshold if it is not addressed.
- Review the diff and decide. At each change board meeting, review every change since the last one and record one decision for each: keep, revert or promote.
For why so many baselines are older than teams expect, read our post Your Zero Trust Program Is Built on a Snapshot.
What do keep, revert and promote mean?
| Decision | When it fits | What happens next |
|---|---|---|
| Keep | The change was reasonable and the risk is acceptable | The baseline is updated, so the change becomes part of the approved state |
| Revert | The change weakens a control or was never intended | The setting returns to the baseline, and the owner records why |
| Promote | This kind of change is too risky to make without review | Future changes of this type go through the change process before they happen |
ITIL already has the change board review an emergency change after it goes in and decide whether it stands. Applying the same review to drift gives every unreviewed change an owner who has to defend keeping it.
Sort the review by blast radius. Changes that cannot be undone, or that could take down a tenant, belong in the promote column and should alert within the hour they happen.
Is there a tool that tells me when a Microsoft 365 security setting changes?
Detecting configuration change is a solved problem, and several kinds of tools can do it. In our experience, the harder part is having a declared baseline and an easy way to put the difference in front of the people who own the risk.
The Accelerynt Security Platform validates your tenant against your approved baseline on a schedule your team configures and on demand. Between scans, drift detection watches critical controls, and each drift event records what changed, the before and after values, who changed it and when. Findings carry an owner and a history in a risk register, including whether a finding came back after a fix.
For how drift fits into ongoing tenant management, read how to manage Microsoft 365 security and prove it works. Conditional Access exclusions are a common source of drift, covered in which Conditional Access policy takes precedence in Entra ID, and the wider practice is explained in what continuous control validation means for Microsoft security.
Where to go next
To see how far your tenant has drifted from its baseline today, start with a Microsoft Control Validation Assessment. When the findings need ranking, read how to turn assessment findings into a remediation roadmap.
For bringing these decisions to the change board, read how to get a security control approved by the change advisory board.
Frequently asked questions
Is there a tool that tells me when a Microsoft 365 security setting changes?
Yes. Configuration-as-code tools, posture management products and validation platforms can all detect change. The Accelerynt Security Platform validates your tenant against your approved baseline and, between scans, records each change to critical controls with the before and after values, who made it and when.
What should we do when configuration drift is detected?
Give the finding an owner, a response time and an escalation threshold, then decide whether to keep the change, revert it or gate that kind of change in the future. Record the decision so the baseline stays accurate.
How do we know if our security baseline is out of date?
Check when it was last updated and what triggered the update. If the answer is the last audit, the gap between that date and today is the window in which changes have gone unverified.
Is all configuration drift a security problem?
No. Some drift is a reasonable change that was never recorded. The risk comes from changes no one reviewed, because they can weaken a control without anyone deciding they should.