Azure Configuration Drift: What Changes Between Architecture Reviews and Why It Matters

Azure configuration drift is the gap between the architecture you signed off and what the tenant actually runs today — and Azure Policy will not show it to you, because it reports current compliance state, not the delta from your last review. The categories that create real risk are RBAC accumulation, network rule sprawl, logging-retention cuts, and stale policy exemptions.

You approved a network security rule change three weeks ago. Something about unblocking a test environment. And now you’re sitting here wondering — did anyone actually revert that?

You’re not sure. You check Azure Policy. It tells you the environment is 94% compliant. It does not tell you what changed, or when, or whether that NSG rule is still sitting open with inbound access from Any on port 3389. That’s not what Azure Policy does. It shows you compliance state right now. It doesn’t show you the delta.

That gap — between “what’s non-compliant today” and “what’s different from the architecture we signed off on six months ago” — is where configuration drift lives. And it compounds quietly until something makes it visible. Usually an audit finding. Sometimes an incident.

Key takeaways

• Drift is continuous, not an event. NSG rules, RBAC grants, Key Vault policies, and retention settings change under operational pressure and never get reverted.
• Azure Policy, Defender for Cloud, and Activity Log each show a slice — current compliance, internal-ruleset findings, or raw change history — but none compares the tenant to the architecture you formally signed off.
• The four highest-risk categories: RBAC accumulation, network configuration drift, logging and retention drift, and policy exemptions that outlive their purpose.
• Detection only matters with a response path — a baseline snapshot, a scheduled comparison, and findings routed to owners and mapped to NIS2, DORA, or ISO27001 controls.

How Azure environments accumulate drift without anyone noticing

Here’s what a normal operational month looks like. An engineer adds an inbound NSG rule to unblock a testing scenario. The testing is done, the rule isn’t removed. A Key Vault access policy gets modified during a release — widened to let a service principal in — and nobody tightens it afterward. A storage account gets created directly through the portal to handle an urgent data transfer, and it inherits defaults rather than the hardened baseline your team defined.

None of these are reckless decisions. They’re operational decisions made under time pressure by people with legitimate access. But three months later, the environment running in production looks materially different from the architecture that was reviewed, documented, and signed off.

Azure Resource Graph is the source of truth here — it gives you a real-time queryable view of every resource property, every role assignment, every policy assignment, every diagnostic configuration across your tenant. The gap between what Resource Graph holds right now and what your architecture documents say? That’s your drift.

The categories that actually create regulatory and security risk

Not all drift carries equal weight. These are the ones that matter.

RBAC accumulation is the highest-risk category, consistently. Contributor access granted on a resource group to unblock an incident. The incident is resolved. The assignment is not removed. Do that a dozen times over eighteen months and the effective permission surface of the environment looks nothing like the access model that was designed.

This isn’t theoretical. A mid-market financial services firm — a Dutch payment processor with around 200 staff — went through a DORA readiness assessment last year and surfaced 34 active RBAC assignments that couldn’t be mapped to any documented business justification. Several were at subscription scope. One was a Subscription Owner assignment for a contractor who’d left the organisation eight months earlier. The auditor’s finding was not the specific assignment — it was the absence of any access review process that would have caught it. That distinction matters: the control failure is structural, not individual.

Network configuration drift creates attack surface. An NSG rule permitting inbound 3389 from Any — created for a one-time remote debugging session — is still an NSG rule. Azure Security Center will flag it. But if nobody is reviewing Security Center findings against the baseline from the last architecture review, the finding sits in a queue. Gartner’s 2024 Cloud Security survey found that 68% of cloud security incidents involved misconfigured network controls, and in the majority of post-incident reviews, the misconfigured rule had been in place for more than 30 days before the incident.

Logging and retention drift is the quietest category and the one most likely to surface as a regulatory finding. DORA Article 10 requires ICT-related incident detection capabilities. NIS2 Article 21 requires logging sufficient to reconstruct security events. If a Log Analytics workspace has its retention period dropped from 180 days to 30 days — because someone was optimising costs — the diagnostic capability present during your last audit is no longer present. No outage. No alert. Just a gap that shows up when an auditor asks you to produce logs for an incident from two months ago.

Policy exemptions that outlive their purpose are self-undermining governance. An exemption is created to allow a legacy resource to exist in a non-compliant state during a migration. The migration gets deprioritised. The exemption stays. Your compliance dashboard still shows green because the policies appear active. But enforcement mode is set to Audit, not Deny, and half the exemptions were supposed to expire six months ago.

What Azure’s native tools actually cover

Azure Policy tells you what’s non-compliant right now. That’s useful. But it doesn’t compare current state to the architecture that was last formally assessed. It doesn’t know that this specific NSG rule was supposed to be temporary. It doesn’t surface “this changed since your last review.”

Defender for Cloud assesses against its own internal rule set. It surfaces genuine misconfigurations — real findings, worth reviewing. But it doesn’t know that your environment was assessed against NIS2 six months ago, that specific findings were remediated and signed off, and that the remediation has since regressed. It can’t show you that regression.

Activity Log is forensic. It answers “what changed in the last 90 days” if you know what to query. It doesn’t answer “how far has this environment drifted from the documented architecture.”

Resource Graph is the closest thing Azure provides natively to a drift detection foundation. Because it gives you a real-time view of all resource properties across the tenant, you can build baseline comparisons — capture a snapshot at the point of an architecture review, write KQL queries to compare current state against it. This is technically achievable. It takes real engineering effort to build and maintain, and it produces raw data rather than mapped findings.

Drift detection only matters if it triggers something

Detection without a response path is just an alerting system you feel bad about ignoring.

A functional governance workflow has three parts. A baseline — not a diagram, an actual Resource Graph snapshot capturing resource configurations, role assignments, policy assignments, diagnostic settings at the point of the last formal assessment. A comparison mechanism that runs against the baseline on a defined interval (weekly is realistic for most teams) and produces a categorised delta. And a response process that maps findings to owners and compliance implications.

That last part is where most teams stall. An NSG rule change needs to go to the network team and map to NIS2 Article 21. An out-of-model RBAC assignment needs to go to the identity team and map to ISO27001 Annex A.9. A policy exemption past its expiry date needs to go to the governance team. Without that routing, drift detection is a report that nobody acts on.

FAQ

Why doesn’t Azure Policy detect configuration drift? Azure Policy reports what is non-compliant against its assigned rules right now. It does not compare the current tenant to the architecture you signed off at your last review, and it does not know a specific NSG rule was meant to be temporary. It shows compliance state, not the delta. See Azure Policy versus a full architecture assessment.

Which type of drift carries the most risk? RBAC accumulation, consistently. Contributor or Owner grants added to unblock an incident are rarely removed, so over eighteen months the effective permission surface stops matching the designed access model. Auditors flag the absence of an access review process more than any single assignment — the control failure is structural.

How do I actually detect drift in Azure? Capture an Azure Resource Graph snapshot of resource properties, role assignments, policy assignments, and diagnostic settings at the point of a formal review. Then run KQL comparisons against that baseline on a defined interval — weekly is realistic — and route each categorised finding to an owner mapped to the relevant control.

What does undetected logging drift cost at audit? If a Log Analytics workspace retention drops from 180 to 30 days for cost reasons, the diagnostic capability present at your last audit silently disappears. There is no outage and no alert — just a gap that surfaces when an auditor asks for logs of an incident from two months ago, against NIS2 Article 21 or DORA Article 10.

PAA connects Azure Resource Graph directly to your governance workflow. It runs a full WAF and CAF assessment against your tenant, maps findings to NIS2, DORA, GDPR, ISO27001, and SOC2 controls, and writes the output to GitHub or Confluence in a format that can be reviewed, assigned, and tracked. Per-tenant encryption keys in your own Key Vault. Runs in hours.

The question isn’t whether your environment has drifted since the last review. It has. The question is which categories, how far, and what those specific deviations are costing you right now in regulatory exposure you don’t have visibility into.