Configuration drift in Microsoft 365 rarely arrives as one “big” change – it accumulates through small tweaks to policies, sharing, auditing, and admin roles. This article explains how to combine real-time auditing with continuous monitoring to create a repeatable model that proves both what changed and whether you’re compliant right now, with clear remediation paths.
Inside this article
Real-time auditing and continuous monitoring address different parts of Microsoft 365 configuration drift. Auditing is event-driven, providing forensic evidence to answer who changed what, when, and by what method – while accounting for real-world audit log latency and coverage gaps. Continuous monitoring is state-driven, verifying whether the tenant currently matches a defined baseline (CIS, Microsoft baselines, or a custom “golden” standard) and preventing silent regressions. This article outlines how to deploy a combined operating model that provides baseline inventory and version control, mapped audit collection, drift-to-event correlation, and clear remediation paths including rollback.
Microsoft 365 (M365) configuration drift rarely shows up as one obvious “big” change. It creeps in: a Conditional Access policy is tweaked, an external sharing control loosens, mailbox auditing shifts, or a “temporary” admin role assignment quietly becomes permanent.
If IT teams try to solve drift with only one signal – and that creates blind spots.
Real-time auditing can give you a steady stream of change events, but you may still struggle to answer the most important question: are we still in a compliant, approved state right now? Audit logs also aren’t always instant – some records can arrive minutes later, or even days later – so “someone watching logs” isn’t a realistic control. This is also an important consideration for SIEM solutions that rely on audit logs being shipped.
Continuous monitoring, allows you to detect if configurations have drifted away from the approved baseline in your tenant, but you may not be able to prove how it happened, or who initiated it.
This blog looks at how to implement both as a single, repeatable operating model: define your baseline, capture change evidence for the same high-risk domains, correlate drift findings back to the events that caused them, and build remediation lanes (auto-remediate, ticket-and-approve, or monitor-only). The result is less uncertainty, faster investigations, stronger audit readiness, and ultimately improved M365 tenant resilience.
A practical way to think about drift is this: most organizations will reach a known “good state” within their Microsoft 365 (M365) tenant where all their configurations are where they want them to be. This maybe achieved after an initial tenant setup, a hardening project, or a security consultancy engagement. Drift management is about being able to see when you’ve moved away from that known-good state, why it changed, and who made the change.
Drift isn’t always a single major change. It can be a gradual erosion over time: a death by a thousand cuts. Which is why you need to be able to continuously know the configuration state within your M365 tenant.
There are two distinct states within this: real-time auditing and continuous monitoring. While the two terms are often confused (because they both trigger alerts), they’re fundamentally different signals.
Real-time auditing tells you that an action happened. A policy was edited. A role was assigned. A setting changed.
M365 change auditing is your forensic trail. It’s the quickest way to trigger alerts when high-risk configuration areas change. When working well, auditing will help ensure you can reliably answer questions like:
In M365, “real-time auditing” is constrained by Microsoft’s back-end pipelines. Even if your tooling collects events immediately, some audit records may arrive minutes – or sometimes much longer (up to hours or even days) – after the change. This means auditing latency is a very real concern. That makes “someone constantly watching logs” unrealistic – and it creates blind spots when teams assume “real time” means “instant.”
Continuous monitoring tells you whether the tenant’s current configuration matches your desired state. Drift can show up as big point-in-time changes, or, as I mentioned, it can appear as minor edits that accumulate until your tenant no longer reflects what was approved.
Continuous monitoring ensures you’re able to keep tabs on what is happening and protect against this type of outcome. Continuous monitoring will help ensure you can answer key questions like:
Continuous monitoring is how you prevent “silent regressions,” like a control being undone after a project or incident.
Auditing provides change evidence. Monitoring provides state assurance. Together, they help you detect drift, identify the change event that caused it, and drive consistent remediation.
Auditing works best when it’s treated as an operations system, not just turning on logs. Below I’ve defined 6 steps to help you put that system in place.
We’ve already stated that some logs can be delayed. You need to keep this in mind when setting SLAs and expectations around this. Currently, a best-case scenario with “real-time” auditing within the CoreView platform is hourly. This is coming down as Microsoft and its partners work together to reduce the time lag. Obviously, your individual SLAs will be heavily dependent on the audit setup that you are using.
Testing isn’t optional. It prevents “shelfware drift monitoring,” where something is deployed, quietly collects data, but no one trusts it enough to operationalize it during incidents or audits.
Native tooling can work, but success depends on timeliness, coverage, and context. Raw audit trails often arrive without clear guidance on what matters, who should act, and how the change impacts your approved baseline. Which is why following the above steps is critical.
Also, keep in mind that not everything is audited in Microsoft 365. Newly released features may ship without audit coverage. For example, Microsoft’s new Unified Tenant Configuration Management APIs shipped without an audit trail in early preview due to prioritization. Also, Unified Audit Log (UAL) outages happen: occasional service breakdowns can lead to missing events temporarily, followed by backlog later.
This is the tool stack you should have in place to capture and investigate admin activity and configuration changes.
Microsoft Purview Audit (or UAL) is your primary source for audit events across Microsoft 365. It can help you validate which workloads and operations you rely on.
Microsoft Entra ID audit logs are key for directory changes, app registrations, and role-related activity. Note that some Entra events do flow into the Unified Audit Log (e.g., certain role assignments), but not all Entra-specific operations do. Your drift audit program should explicitly define whether it’s collecting:
The ability to create PowerShell scripts will help with point-in-time checks, exporting events, and building repeatable investigation scripts. Scripts should be kept source-controlled and peer-reviewed.
While M365 DSC (Desired State Configuration) is primarily baseline/state-oriented, it pairs well with audit events when you need to validate what changed versus what is deployed. This is your reference point for “what should be” within your tenant.
Sentinel is a useful additional tool when it comes to creating alerting workflows tied to your auditing outputs.
These Microsoft-native tools can provide a strong foundation for configuration auditing, but there are recurring “gaps”. These need to be filled when building a comprehensive drift-auditing program. These are some of the core areas you’ll need to find ways to address:
In a recent interview, the lead admin from an automation-mature M365 team described a familiar drift problem: they weren’t struggling to get alerts – they were struggling to understand what those alerts meant against an approved baseline.
Their tenant management system (backed by Azure Automation runbooks) logged plenty of change events, but the change history lacked baseline-aware context. They had no simple way to tell whether a modified setting originally came from the “golden” configuration. So, when someone
manually removed or altered a baseline-enforced control, the team could see that a change occurred, but still couldn’t quickly answer the questions that matter in drift response: Are we still in an approved state right now? Was this change undoing an intentional control, or just normal operations?
The result was manual reconciliation, which was slow, error-prone, and hard to scale. And from an audit-readiness perspective, it created a second problem: proving what should have been in place often took extra time, increasing the risk of delayed detection (or delayed evidence) when baseline controls were modified.
Microsoft doesn’t cover all bases so deploying a third-party tool can help if your organization requires: better correlation (event/configuration item/baseline impact), a single operational view across tenants and workloads, and easier reporting for auditors and leadership.
Broadly the tools you should consider fall into these categories:
SSPM tools provide continuous visibility into your SaaS configuration and security controls so you can detect misconfigurations, enforce policy, and reduce risk across apps like M365.
These tools will help you get context around “who/what changed it”.
SIEMs/SOAR can be helpful here, but only when they’re configured to ingest the right M365 audit sources, normalize identities (human vs. automation vs. app), and detect configuration-relevant change patterns – not just generic anomalies.
These tools can help you to operationalize findings and work towards remediating issues.
If you want drift monitoring to improve compliance outcomes, you need three ingredients: an established “good” baseline, a drift detector, and a remediation path.
This process helps to make baselines reviewable, versioned, and repeatable.
Microsoft 365 DSC is a common approach for defining and exporting tenant configuration state, then comparing it over time. It can be effective for teams with the PowerShell maturity to run and maintain it, but many enterprises hit three constraints: coverage breadth, usability (script-first), and scale when trying to snapshot, compare, and operationalize findings across large environments.
Some controls should be checked more often than others. A practical model to follow is:
If your tool checks on a schedule, label it honestly. Continuous monitoring is about maintaining near-current state awareness, not just producing periodic snapshots.
Every drift finding must map to a decision, such as, auto-remediate, ticket-and-approve, or monitor-only. If you skip this, your drift reports will likely quickly become backlog generators.
You should expect some drift noise at first, around things like inherited settings, legacy exceptions, and admin behavior variance. Don’t ignore these results. Instead, make sure you tune your baseline around them.
It’s important to note that continuous monitoring is where many programs fail, because teams mistake “a daily report” for control enforcement. On top of that, a common failure point is the build vs. buy trap: your team may be able to use PowerShell to write scripts to capture configuration state, but this can have inherent ongoing risks around maintenance, ownership gaps, brittle logic, and coverage limitations as M365 evolves.
Make sure you track false positives, noisy controls, and gaps in coverage and that you continually adjust baselines and thresholds instead of ignoring alerts.
For continuous configuration drift monitoring in M365, you’ll typically need to deploy a small set of native tools to help you capture and version a baseline, fill coverage gaps with targeted checks, and turn findings into alerts and response workflows.
Microsoft 365 DSC exports a “desired state” snapshot of many M365 workloads (as code) to serve as your baseline. It also enables repeatable drift detection by re-exporting on a schedule and diffing against the baseline (Git/CI-friendly). It’s an important tool for providing broad posture checks.
As mentioned above, this isn’t essential but it can be helpful with creating alerting workflows tied to monitoring outputs.
You should consider deploying third-party configuration tools if you require broad configuration coverage without relying on custom scripting, baseline enforcement across complex environments, faster reporting for audits and leadership, and consistent remediation workflows.
The main categories to look at include:
These tools continuously assess Microsoft 365/Entra configuration against best-practice frameworks and flag changes over time.
SSPM is focused on SaaS misconfigurations, risky settings, and posture scoring (often using frameworks/mappings).
If you don’t want Sentinel, these tools can help with alerting and automation as they can ingest drift findings and drive response workflows.
Used to open tickets, route approvals, and execute playbooks when drift is detected.
Useful when you want recovery after bad changes, compromise, or admin mistakes (not just detection).
If you want to follow a single implementation path for creating real-time auditing and continuous monitoring of your M365 configurations, the simplest model is:
baseline first, audit second, correlation third, remediation last.
Define two accountable owners:
Then define a cadence, for example:
Prioritize what you baseline first. Start with controls that auditors ask about early (identity, privileged roles, external sharing, mail flow). Then expand to configurations that are either security-critical or complex/time-consuming to rebuild – drift in “non-security” settings can still create outages, user friction, and ticket overload.
Create a baseline inventory across:
Aim to create a baseline table that covers importance, rationale, and exception handling.
Treat baseline updates like change control, keep note of who proposed it, why it changed, who approved it, and when it becomes active.
Your audit coverage must map to the same baseline domains. If you can detect drift in an area but can’t capture change evidence there, your investigations will be incomplete. For identity controls, you should validate whether the evidence is in Purview Audit, Entra audit logs, or both – otherwise drift can be visible without a complete event trail.
Ensure you know everyone understands what to do when drift is detected, for example:
This will ensure you have a single incident record that includes both state drift and event evidence.
Assign one lane per control:
If you can’t roll back confidently, enforcement will stall. You should also document rollback steps and validation checks per baseline domain.
A drift program succeeds when it reduces uncertainty, not when it generates more telemetry. M365 auditing and monitoring can produce overwhelming volume – thousands of activity types across 100+ workloads. This can lead to your team drowning in results. Successful programs start narrow, and scope to “must-alert” events.
Practical best practices that hold up in audits and incidents, include:
Route the right changes to the right team: Security teams care about a different slice of settings than collaboration or messaging teams. Drift monitoring must deliver targeted alerts, not an indiscriminate stream of events.
Separate “signal” from “bombardment”: The biggest operational risk isn’t lack of data – it’s too much data without context. Tune what you watch, who receives it, and what action is expected.
Prioritize what you look for: As I mentioned above, start with what auditors will focus on (Identity, admin roles, external sharing, and mail flow) before expanding out to security and business-critical configurations.
Separate “change volume” from “change risk”: Do not alert on every event. Alert on events that affect your baseline or blast radius.
Normalize admin identities: Require named accounts, limit shared accounts, and document break-glass usage.
Treat “continuous monitoring” as an engineering standard: If a tool scans periodically, call it scheduled scanning. If you cannot measure “current state,” you are not monitoring drift.
Make exceptions explicit and expiring: Every exception needs an owner and a review date.
Test your program: At least quarterly, you should create controlled changes to verify the following: alert triggers, drift detects, check correlation works, and make sure remediation is repeatable.
Microsoft’s native tools can help support you with pieces of drift auditing and monitoring, but in our experience, teams still struggle with consistency and operational overhead. That’s especially true when responsibilities are split across security, identity, messaging, and collaboration admins.
In practice, drift programs tend break down in four key areas. When organizations need to:
Native tooling and scripts can work, but they often lack the operational context teams actually need, plus they can also introduce gaps. For example:
CoreView Configuration Manager helps plug these gaps. We’ve talked about some of the inconsistencies in log data for M365, and while CoreView is restricted to Microsoft’s audit availability, it doesn’t rely solely on waiting for audit events to arrive. CoreView actively snapshots tenant configuration state and compares snapshots to detect drift, then surfaces the before/after change, when it changed, and who made the change – so responders can investigate without stitching together multiple portals, exports, and log queries.
Many organizations run snapshots hourly, and changes are presented immediately after the snapshot completes. This avoids waiting on audit log pipelines that can lag for hours (or longer), while still providing operationally useful near-current visibility.
Where CoreView provides a big operational win is in centralizing change evidence and translating it into actionable, baseline-aware findings across your environment. This can be a major headache if
you try to do it manually. CoreView excels at getting the right configuration change signals to the right owners (security, identity, messaging, collaboration) with enough context to act, without flooding everyone with raw telemetry.
CoreView Configuration Manager provides an enterprise-supported alternative to Microsoft 365 DSC-style drift approaches.
CoreView builds Microsoft 365 Tenant Resilience by making configuration governance operational at scale.
Most security teams can detect an attack. Far fewer can recover tenant-level control once it’s lost. Make sure you’re in the know and download the free guide “Attackers Know How to Take Your Tenant. Do You Know How to Take It Back?” Then schedule a demo or see the product for yourself.
Treat audit logs as forensic evidence, not your only “near real-time” signal. Pair event collection with scheduled state snapshots of the same high-risk controls (identity, external sharing, mail flow, privileged roles). That way, if an audit record arrives late (or backfills after an outage), you still detect that the tenant moved away from baseline and can respond while the window is still open.
Any alert that can’t answer “so what?” will eventually get ignored. The practical fix is to attach each alert to the following:
Event evidence tells you who did what, when, and how, but it doesn’t prove your tenant is currently in an approved state. State assurance requires continuous or frequent configuration comparisons against an approved baseline, plus exception handling (accepted risk with an owner and review date). In audits, teams often lose time because they can produce logs, but can’t quickly prove the current intended configuration.
Because drift rarely stays in one control plane. A single outcome (e.g., weakened access controls) can involve Entra ID, Exchange, and collaboration settings – each with different logs, schemas, and admin interfaces. When teams have to stitch together timelines manually, they waste time on correlation instead of containment. A drift program works best when it produces a single incident record that includes both the state delta and the most likely cause of events.
Exceptions need to be treated like time-bound decisions, not “special cases forever.” For each exception, record the following:
