Every experienced Azure or Entra admin has lived this incident: something stops working — sign-ins fail for a subset of users, an app loses access, MFA prompts behave strangely — and the first hour is spent not fixing anything but trying to establish what changed. Someone edited a Conditional Access policy last Tuesday. Was it deliberate? What did it look like before? Who approved it? The tenant has no memory beyond its audit logs, and nobody wrote anything down. This guide is about building that memory deliberately: what change tracking looks like when it's done well, what the platform gives you for free (and for how long), and what regulations like NIS2 and DORA actually require — as opposed to what people selling things say they require.
Why cloud config drifts
Configuration drift — the gap between what you believe your environment looks like and what it actually looks like — is worse in cloud admin planes than it ever was on-prem, for structural reasons:
- The portal makes changes frictionless. Any admin with the right role can reshape tenant-wide security policy in four clicks, with no changelog, no review, and no artefact left behind. Compare that with on-prem changes that at least required touching a server someone monitored.
- Many hands, one tenant. Entra and Azure settings are touched by IT admins, security teams, consultants, support engineers following a Microsoft ticket, and automation — each with partial context. Temporary changes ("just exclude this group from CA while we debug") have a documented tendency to become permanent by being forgotten.
- The platform itself moves. Microsoft renames settings, changes defaults, deprecates policies and rolls out new security baselines. Even a tenant nobody touches doesn't stay still.
- The blast radius is asymmetric. A single edited Conditional Access policy, a modified cross-tenant access setting, or a consent grant to an over-permissioned app can quietly change the security posture of the whole organisation. These are precisely the changes least likely to be caught by anyone's day-to-day work — nothing breaks; something just becomes possible that shouldn't be.
Concrete drift scenarios — CA policy edits, app consent grants and friends — get a dedicated treatment in the Entra config drift guide. Here we stay at the programme level.
What the platform gives you, and the retention cliff
Entra ID and Azure both keep audit trails, and they're genuinely good — every directory change, policy edit, role assignment and consent grant lands in the Entra audit log with actor, timestamp and (usually) old and new values; subscription-level operations land in the Azure Activity Log.
The catch is retention. Entra audit and sign-in logs are retained for 30 days with a Premium licence (less on the free tier); the Azure Activity Log is retained for 90 days. Those windows are shorter than the questions you'll need to answer. "When did this policy change and what did it say before?" is routinely a six-month-old question — drift, by its nature, is discovered long after it occurs. An incident investigation, an auditor's sample, or a "has this ever been different?" question will regularly outrun native retention.
The first, non-negotiable step of any governance effort is therefore simply: export the logs somewhere durable. Diagnostic settings can stream Entra and Azure logs to a Log Analytics workspace, a storage account, or an event hub. Storage-account archival is nearly free; Log Analytics costs more but makes the data queryable. Do this today, before you need it — logs you didn't export are gone, and no later investment recovers them.
But understand what audit logs are and aren't. They're an event stream: they tell you a change happened, if you know to look and the event is within retention. They are not a statement of current or past configuration — reconstructing "what did our CA policy set look like on 1 March" from an event stream means replaying every change since some known state, which nobody actually does under incident pressure.
What good change tracking looks like
Mature teams converge on the same handful of practices, whatever tooling they use:
Baseline snapshots. Periodically capture the actual configuration — CA policies, named locations, authentication methods policy, app registrations and their credentials and permissions, privileged role assignments, cross-tenant settings — as structured exports. Most of this is a page of Graph API or PowerShell scripting. The snapshot answers the question the audit log can't: what did it look like then?
Diffing, with humans reviewing the diff. A snapshot archive becomes change tracking the moment you compare consecutive snapshots and route the differences to someone who can say "expected" or "investigate". This is the heart of the whole discipline. It catches everything: portal changes, API changes, changes by Microsoft support, changes by compromised accounts.
Alerting on the changes that can't wait for review cadence. A small set of events warrant real-time alerts rather than weekly review: CA policy created/modified/deleted, privileged role assignments, new credentials on privileged apps, break-glass account activity. Native tooling (Log Analytics alert rules, or your SIEM) covers this once logs are flowing.
Intent capture. The hardest part is not technical: recording why a change was made and who approved it. Lightweight is fine — a change ticket reference, a pinned message, a required note. The test is whether, a year later, you can distinguish a deliberate change from drift. Teams that manage configuration as code (Terraform, Microsoft365DSC, Bicep) get intent capture almost free through pull requests, plus drift detection when reality diverges from the repo — the strongest version of this whole practice, at the cost of upfront investment and discipline about not making portal changes.
Regular reconciliation review. A monthly or quarterly session where someone walks the diff since last time, closes the loop on temporary changes, and re-certifies the sensitive configuration. Boring, effective, and exactly what auditors mean by "change management operating effectively".
What NIS2 and DORA actually expect
Both regulations are cited constantly in tooling marketing, so it's worth being precise about what they say — and don't.
NIS2 (applying to essential and important entities across the EU) requires appropriate and proportionate cybersecurity risk-management measures. Its Article 21 measure list includes policies on risk analysis, incident handling, business continuity, supply chain security, and — relevantly here — security in network and information systems acquisition, development and maintenance, plus policies to assess the effectiveness of the measures. Change management and configuration control are standard, expected components of such a framework (they're explicit in the implementing acts for some sectors and in every reference framework NIS2 assessments map to, such as ISO 27001, which has controls for change management and configuration management). What NIS2 does not do is name any product category, mandate a specific retention period for your Entra logs, or require a particular tool. If someone tells you NIS2 requires you to buy something, they are compressing "you need demonstrable change control, and tooling makes that much easier" into a sales claim.
DORA (applying to EU financial entities and their critical ICT providers) is more prescriptive: it requires an ICT risk-management framework including identification and documentation of ICT assets and configurations, mechanisms to detect anomalous activity, logging, and — explicitly — ICT change management, with changes recorded, tested, assessed and approved through a controlled process. For an in-scope entity, "we have no record of who changed our tenant's Conditional Access policies or why" is a genuine finding. But again: DORA mandates outcomes and processes, not products. A disciplined snapshot-diff-review practice built on exported logs and scripts can satisfy it; so can commercial tooling that does the same with less ongoing effort.
The honest framing: regulation is a reason to prioritise this work, not the reason to do it. The operational case — faster incident diagnosis, catching silent security regressions, surviving staff turnover — stands entirely on its own, and applies to a 50-person company no regulator has ever heard of.
Where to start, in order
- Export Entra and Azure logs to durable storage (an afternoon; protects everything else you'll do later).
- Script a snapshot of CA policies, app registrations, and privileged role assignments; store outputs with timestamps (a day).
- Alert on the top five sensitive change types (a day, once logs are in Log Analytics).
- Institute a monthly diff review with notes on every unexplained change (ongoing, an hour a month).
- Then decide whether to invest in configuration-as-code, commercial governance tooling, or both — from a position where you already have the data and the habit, and can evaluate what genuinely adds value on top.
Drift is not an exotic threat; it's the accumulated residue of ordinary work done without a memory. The fix is mostly about deciding, once, that your tenant's configuration history is worth keeping.