Infrastructure Drift Detection

Drift detection compares your approved C4 architecture model against the live state of your Azure subscription — automatically, on every scan. When resources are added, removed, or changed without going through IaC, C4CI surfaces the difference as a severity-scored alert and provides a reviewed remediation path.

Drift detection is available on Pro and above. Enterprise and PAYG add compliance reporting plus the reviewed remediation workflow. It is the core differentiator of C4CI — not a bolt-on feature. The platform is built around the loop: connect → see → detect → approve → apply.

What is infrastructure drift?

Infrastructure drift is the difference between what your architecture documentation says should exist and what actually exists in your cloud environment. It happens constantly: a developer provisions a VM directly in the Azure Portal instead of via Terraform, an incident response engineer opens a firewall rule and forgets to close it, a VM SKU gets changed in a cost-cutting exercise without updating the IaC.

In a typical organisation, drift accumulates silently for weeks or months. The architecture diagram becomes a historical artefact rather than a living document. When an audit arrives — or when something breaks — nobody knows what the diagram represents anymore.

For teams subject to NIS2 or DORA, drift is a compliance risk. Both regulations require proof that documented architecture matches live infrastructure. Without automated drift detection, producing that proof means a manual audit — expensive, slow, and only accurate at the moment it was taken.

How C4CI detects drift

Every C4CI scan queries Azure Resource Graph and builds a snapshot of your subscription. Drift detection compares the current snapshot against the last approved baseline — the state you explicitly said represented your intended architecture.

1. Scan — C4CI queries Azure Resource Graph with Reader role only. The scan discovers all resources, their properties, and their relationships. No agents, no SDKs, no changes to your infrastructure.
2. Compare— the new snapshot is diff'd against the approved baseline. Added resources, removed resources, and changed properties are identified separately.
3. Score — each drift item is assigned a severity: Critical, Warning, or Info. Severity is based on the type of change and the resource type affected.
4. Present — drift items appear in the Drift panel on the project page and as annotations on the C4 diagram. You see the delta in context.
5. Approve or remediate — you review each item and either approve it (update the baseline) or, on Enterprise and PAYG, trigger remediation (generate OpenTofu code to restore the intended state).

Drift severity levels

Every drift item is scored at one of three severity levels. Severity determines notification urgency and where the item appears in the drift panel.

The remediation workflow

C4CI never mutates your infrastructure automatically. Every change requires an explicit human approval step. The remediation workflow follows four steps:

1. Review the delta — the Drift panel shows each changed resource with before/after property values. Critical items are shown first.
2. Choose an action — for each item, you can: approve (the change was intentional — update the baseline), reject and remediate (generate OpenTofu code to restore intended state), or defer (flag for later review).
3. Generate OpenTofu code — if you choose to remediate, C4CI generates the OpenTofu diff for the selected items. You review the code in the portal before anything is applied.
4. Open a PR — the generated code is pushed to your IaC repository as a pull request via the GitOps integration. You review, approve, and merge through your normal code review process. C4CI never bypasses it.

Drift detection and NIS2 / DORA compliance

NIS2 Article 21 requires organisations to implement technical measures to manage ICT risk — including ensuring that documented architecture reflects the actual operational environment. Drift detection is the automated mechanism that produces that proof on a continuous basis rather than at audit time.

Every drift scan produces an immutable snapshot stored with a timestamp. These snapshots serve as audit evidence: at any point you can show an auditor the state of your infrastructure on a given date, what diverged from the approved architecture, and what action was taken. Compliance reporting exports are available on Enterprise and PAYG tiers.