- In short
- Compliance drift is when a control that is correct at design time silently stops being true in production as configurations change - a data-residency pin, say, becoming false months later after an unrelated change. Without a named owner watching a specific evidence artifact, drift is not detected until an audit or incident surfaces it, and passing an initial constraint pre-filter is not the same as proving ongoing compliance. Controls must be revalidated on a regular cadence, not verified once and assumed permanent.
A control can be true at design time and false later
Compliance is not a state you reach and keep; it is a state you have to maintain. The CCAR-P exam treats recognising compliance drift as an evaluate-level skill because it is the failure that a tidy, correct-at-design-time control register does not prevent. A control that was genuinely true when the system shipped can silently stop being true in production as configurations change - and because nothing announces the change, the control's failure is invisible until an audit or an incident surfaces it.
The canonical example is data-residency pinning. At design time, processing is pinned to the approved region and the control is correct. Months later, an unrelated logging configuration change starts writing request metadata to a store in a second region. The residency control is now false, but no alarm sounded, because the change was never framed as a compliance change and no one was watching the residency claim. The control that everyone believed was live had quietly gone non-operational.
- Compliance drift and revalidation
- Compliance drift is a control correct at design time silently becoming false in production as configurations change. Without a named owner watching a specific evidence artifact, drift goes undetected until an audit or incident surfaces it. Passing an initial constraint pre-filter is not ongoing proof, so controls must be revalidated on a regular cadence rather than verified once.
Why drift is silent, and what makes it detectable
Drift is silent for a structural reason: the change that breaks a compliance control usually does not look like a compliance change. A logging tweak, an infrastructure migration, a new feature's storage choice - each can undo a control while appearing to be routine engineering. Because the change is not flagged as compliance-relevant, nobody re-checks the control, and the gap opens without anyone connecting cause to effect. Assuming a logging or infrastructure change is unrelated to compliance simply because it was not labelled a compliance change is exactly how drift takes hold.
What makes drift detectable is the control-owner-evidence triad doing its job over time. A named owner watching a specific evidence artifact is the mechanism that catches drift: if someone owns the residency control and periodically inspects a data-flow record, the second-region writes surface as a live finding rather than an audit surprise. Without that owner and that artifact, there is nothing standing between the silent change and the eventual audit. This is why an unowned control is not just incomplete at design time but actively dangerous over time - it is precisely the control that will drift undetected.
A prerequisite is not ongoing proof
The compliance layer's constraint pre-filter - choosing a delivery route or entry point that survives the obligation - is a point-in-time decision. It is a genuine prerequisite: you cannot be compliant on a route that could never satisfy the obligation. But passing that pre-filter is not the same as proving ongoing compliance. The route being compliant at selection says nothing about whether the deployment stays compliant as it evolves, because production changes and the pre-filter does not re-run itself.
So the correct posture is revalidation on a cadence. Controls are re-checked on a regular schedule, not verified once and assumed permanent, because configurations drift and evidence goes stale. This is the same reasoning as choosing a fail-closed posture in fail-open vs fail-closed design: a control you are not actively watching degrades toward the unprotected state, and only deliberate, repeated verification keeps it in the state you designed. Treating a design-time decision as a permanent guarantee is the mistake; treating compliance as a maintained property is the fix.
What the CCAR-P exam trips candidates on
The first trap is treating a compliant entry-point decision made at design time as a permanent guarantee with nothing further to monitor. The scenario shows a compliant route chosen and the matter closed; the credited reading is that the route is a prerequisite and ongoing compliance still needs a named owner, a maintained evidence artifact, and revalidation on a cadence. Design-time correctness does not persist on its own.
The second trap is assuming a logging or infrastructure change is unrelated to compliance because it was not flagged as a compliance change. A scenario introduces a routine-seeming config change that quietly breaks a residency control; the credited reading is that the label does not determine the impact, and only ongoing revalidation of the affected control would catch it. The exam rewards candidates who treat compliance as a maintained property and who expect drift from unlabelled changes.
Worked example
A team selected a compliant delivery route for a regulated workload, mapped obligations to controls once in a design document at launch, and considered compliance settled. Months later, a logging configuration change began writing request metadata to a store in a second region. The residency gap was discovered at an audit. What went wrong at each stage, and what should the team have done?
Several failures compound into a textbook drift incident. At launch, the team treated a design-time mapping as the whole job: controls were named in a document, but no owner was attached to the residency control and no evidence artifact tracked where data actually landed. That is the unowned, evidence-less control the triad warns about - correct on paper, unwatched in practice.
Then the silent change. A logging configuration was altered, and because it was not framed as a compliance change, no one connected it to the residency control. Request metadata began flowing to a second region, the residency control became false, and nothing surfaced it - there was no owner watching a data-flow record, so the change that broke the control passed as ordinary engineering. The control was real at design time and silently false in production, which is the definition of drift.
The gap then surfaced at the audit, the most expensive place to find it, when a reviewer asked for evidence that data stayed in-region and the team had a design document instead of a data-flow record. What they should have done: assign a named owner to the residency control, attach a living evidence artifact - a data-flow record or region query - and revalidate it on a regular cadence, so an unrelated logging change would trigger a finding rather than an audit surprise. The lesson the exam draws is that a compliant entry point is a prerequisite, not a permanent guarantee, and only ongoing revalidation catches drift before an auditor does.
Common misreadings to avoid
Misconception
Once a compliant entry point or route is chosen at design time, compliance is settled with nothing further to monitor.
What's actually true
Misconception
A logging or infrastructure change is unrelated to compliance if it was not labelled a compliance change.
What's actually true
How this shows up on the exam
Domain 5 items describe a control that was correct at launch and later failed, often through an unrelated configuration change discovered at an audit. The reliable method is to identify it as compliance drift, name the missing mechanism - an owner watching a living evidence artifact on a revalidation cadence - and reject any framing that treats a design-time decision as a permanent guarantee. Expect the breaking change to be disguised as routine, unlabelled engineering.
This is the time dimension of the control-owner-evidence triad: the owner and evidence exist precisely so drift is caught. It depends on the evidence artifacts vs design documents distinction, since a living artifact is what reveals drift while a design document conceals it, and it mirrors the degrade-deliberately reasoning of fail-open vs fail-closed design.
A team chose a compliant route and mapped controls in a design document at launch, then considered compliance done. Months later a logging change wrote data to a second region, breaking residency, and the gap surfaced at an audit. What is the correct diagnosis and fix?
People also ask
What is compliance drift?
How can a control be true at design time and false later?
Why does a compliant entry point not guarantee ongoing compliance?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.