Compliance drift is the gradual movement of a system out of compliance after it was last verified. A control that passed at the audit stops holding because something changed: a resource was edited, a new one was created without the required settings, a review was missed, or the standard itself was updated. Nothing announces it, so it is usually found at the next audit.
The audit is the wrong place to find it. By then the gap has been open for months, the evidence for the period is incomplete, and the fix competes with everything else due that week. This guide covers how compliance drift differs from other kinds of drift, the five ways it starts, how to detect each one, and a remediation workflow that leaves evidence behind.
Compliance drift vs configuration drift vs infrastructure drift
The three terms are used loosely and often swapped. They measure different gaps, and a system can have one without the others.
| Term | What is compared | Example |
|---|---|---|
| Infrastructure drift | A live cloud resource against the code that declares it | A security group rule is edited in the console and no longer matches Terraform |
| Configuration drift | A server or cluster against its intended baseline | One host in a fleet carries a package version the others do not |
| Compliance drift | A system against a control requirement | A database exists without the encryption at rest that the policy requires |
The distinction matters because the checks are different. A clean infrastructure drift check says the live resources match the code. It does not say the code is compliant. A change can be reviewed, merged, applied through the pipeline, and match its code exactly, and still take the system out of compliance. In the other direction, a console change can cause infrastructure drift while leaving every control intact.
Five ways compliance drift starts
Knowing the cause tells you which detection method would have caught it, so it is worth naming them precisely.
- 1A change made outside the pipeline. An engineer opens a port or disables a setting in the console during an incident and it is never reverted. This is infrastructure drift and compliance drift at the same time.
- 2A new resource created without the controls. A new account, region, or service is brought into use and the baseline that covers the existing estate does not apply to it yet. Nothing was changed; something was added.
- 3A compliant definition changed in code. A pull request removes an encryption setting or copies a module without it, and no policy check exists for that control. The change is reviewed and approved by people who were not looking for it.
- 4A control that expires. Nothing in the infrastructure changes, but time passes. An access key crosses the rotation age, a quarterly access review is skipped, a certificate nears expiry, a restore test falls overdue.
- 5The requirement moves. A benchmark publishes a new version, a framework adds a control, or the scope grows because the system now handles a new type of data. The system stayed still and the line moved.
Causes 2, 4, and 5 involve no change to any existing resource, which is why change-focused controls alone never catch all compliance drift.
How to detect compliance drift
No single check sees all five causes. Detection works in layers, each aimed at the causes the others miss.
| Cause | Detected by | When it fires |
|---|---|---|
| Change outside the pipeline | Continuous evaluation of live state, plus a scheduled infrastructure drift check | Minutes to a day after the change |
| New resource without controls | Continuous evaluation of live state across every account and region | When the resource is first evaluated |
| Compliant definition changed in code | Policy checks on the plan, before deploy | In the pull request |
| Control that expires | Calendar-based checks with a named owner | On the due date |
| Requirement moves | Tracking the framework and benchmark versions you are assessed against | When a new version is published |
Before deploy. Policy as code evaluates the planned change against your rules and blocks or warns in the pull request. Checkov, Open Policy Agent with Conftest, and Kyverno for Kubernetes all work this way. Compliance as code tools compared covers the choice. This is the cheapest place to catch a problem, and it only sees changes that go through the pipeline.
After deploy. Continuous evaluation checks live resources against rules regardless of how they were created. AWS Config rules and conformance packs, Azure Policy, and the posture checks in Google Cloud Security Command Center do this natively, and cloud security platforms do it across providers. The current list of failures is one command away:
# AWS: Config rules that currently have non-compliant resources
aws configservice describe-compliance-by-config-rule \
--compliance-types NON_COMPLIANT \
--query 'ComplianceByConfigRules[].ConfigRuleName'
# Azure: summary of policy compliance for the current subscription
az policy state summarize
On a calendar. Time-based controls need a due date and an owner, the same as any other recurring task. Key age can be read from the IAM credential report. Access reviews and restore tests need a record of when they last happened.
Two numbers show whether detection is working: how long a control stays broken before it is noticed, and how long it takes to fix once noticed. Track both per control. A control that is found broken at every audit has a detection time measured in months.
Compliance drift remediation: a workflow
Remediation is where compliance drift most often goes wrong, in one of two ways. Either the finding is fixed by hand in the console and reappears at the next deploy, or it is closed in a ticket without anyone confirming the fix. This sequence avoids both.
- 1Confirm the finding against the live resource. Scans can be stale and rules can be wrong. Read the resource's current configuration before acting on the report.
- 2Find the owner and the cause. Decide which of the five causes applies. The cause determines step 7.
- 3Contain it if data is exposed. If the gap is a public bucket or an open database port, close the exposure first, through a change that is recorded.
- 4Fix it where the resource is defined. If the resource is managed by code, change the code, or the next apply will undo a manual fix. If it has no code, bring it under code as part of the fix.
- 5Review and apply through the normal pipeline. The remediation is a production change and deserves the same plan, policy check, and approval as any other.
- 6Verify with a fresh evaluation. Run the same check again, confirm it passes, and keep the before and after results together. A closed ticket is not evidence.
- 7Close the gap that allowed it. Add the missing policy check, extend the baseline to the new account, or put the review on a calendar with an owner. Without this step the same finding returns.
What is safe to remediate automatically
Automatic remediation is attractive and should be applied narrowly. The test is whether the fix can break a running workload.
| Lower risk, reasonable to automate | Needs a person to review |
|---|---|
| Turning audit logging back on | Changing network rules that carry traffic |
| Re-enabling versioning on a bucket | Changing encryption, which can require replacing the resource |
| Re-applying required tags | Changing IAM policies or trust relationships |
| Opening a ticket with the evidence attached | Blocking public access on a bucket that may be serving a website |
Whatever is automated should still leave a record of what was changed, when, and why, so the automatic fix is itself auditable.
Worked example: drift with no infrastructure drift
Illustrative example, not a customer result. A team completes a SOC 2 audit in March. Its policy states that production databases are encrypted at rest.
In May, an engineer adds a reporting database by copying an older Terraform module that predates the encryption requirement. The pull request is reviewed and approved. No plan-time policy check exists for database encryption, so nothing flags it. The change is applied through the pipeline.
At this point the scheduled infrastructure drift check is clean, because the live database matches its code exactly. The system is out of compliance anyway. This is cause 3.
In June, the team turns on the AWS Config managed rule rds-storage-encrypted, which reports the new instance as non-compliant. Detection time: about a month.
The fix is not a one-line change. An existing unencrypted Amazon RDS instance cannot have encryption switched on in place. The team takes a snapshot, copies it with encryption enabled, restores a new instance from the encrypted copy, and moves the application to it, all as a planned change with a maintenance window. They update the module, re-run the rule, and save both results.
For step 7 they add a plan-time policy that fails any database resource without storage encryption. The same mistake in a future pull request now fails in review, where fixing it takes a minute, not a maintenance window.
Preventing compliance drift
Prevention is the detection layers moved as early as each one can go.
- Gate changes before deploy. Every control that can be expressed as a rule on a plan should fail the pull request, not a later scan.
- Apply the baseline to new accounts automatically. Organization-level guardrails, such as AWS service control policies or Azure Policy assignments at the management group, cover an account from the moment it exists.
- Evaluate live state continuously, in every region. Scans limited to the regions you use miss the resource someone created in a region you do not.
- Give time-based controls owners and dates. If nobody is named, the review does not happen.
- Make evidence a by-product. When policy results, approvals, and scan outcomes are recorded as changes happen, the audit period is covered without a collection sprint. The cloud infrastructure audit checklist lists what that evidence needs to show.
ops0 runs the same policy engine in both places: as a gate on the planned change before deploy, and as a continuous scan of live cloud state afterward, across SOC 2, CIS, ISO 27001, ISO 27002, HIPAA, and GDPR. Results, approvals, and deployments are recorded as they happen, and a finding is remediated as a reviewed change, not a console edit. Compliance automation in ops0 describes the workflow.
What is compliance drift?
Compliance drift is the gradual movement of a system out of compliance after it was last verified. A control that passed at the audit stops holding because a resource was changed, a new one was created without the required settings, a recurring review was missed, or the standard was updated.
What causes compliance drift?
Five things: changes made outside the deployment pipeline, new resources or accounts created without the baseline controls, code changes that remove a compliant setting, time-based controls that expire such as key rotation and access reviews, and requirements that change when a framework or benchmark is updated.
How is compliance drift different from configuration drift?
Configuration drift is a system differing from its intended configuration baseline. Compliance drift is a system differing from a control requirement. They overlap, but a system can match its configuration and its code exactly and still be out of compliance if that configuration never met the requirement.
How do you detect compliance drift?
In layers. Policy checks on the planned change catch non-compliant code before deploy. Continuous evaluation of live state, such as AWS Config rules or Azure Policy, catches out-of-band changes and new resources. Calendar-based checks catch controls that expire. Tracking framework versions catches requirements that change.
What is compliance drift remediation?
It is the process of returning a drifted control to a compliant state and proving it. Confirm the finding, identify the owner and cause, contain any exposure, fix the resource where it is defined in code, apply the change through the normal pipeline, verify with a fresh evaluation, and close the gap that allowed the drift.
Can compliance drift be remediated automatically?
Some of it. Fixes that cannot break a running workload, such as re-enabling logging or re-applying tags, are reasonable to automate. Changes to network rules, encryption, and IAM should be reviewed by a person, because an automatic fix can cause an outage or undo an emergency change.
- Conformance packs: AWS Config documentation. Grouping Config rules and remediation actions to evaluate accounts continuously.
- rds-storage-encrypted: AWS Config documentation. The managed rule used in the worked example.
- Encrypting Amazon RDS resources: Amazon RDS documentation. Why an unencrypted instance must be restored from an encrypted snapshot copy.
- Get compliance data of Azure resources: Microsoft Learn. How Azure Policy evaluates and reports compliance state.
- SP 800-137: Information Security Continuous Monitoring: NIST. The case for monitoring controls continuously instead of at assessment time.
