The firewall rule changed in March. A new asset got onboarded in June. The senior compliance engineer left in October. The SSP, written in January, still says what it said in January. By assessment time, it describes an organization that no longer exists.
That gap, between what the documentation claims and what the organization is, is drift. It is the single most predictable failure mode in CMMC assessment. And the industry has been mislabeling it for years.
The mainstream framing treats drift as a discipline problem. The contractor should have updated the SSP. The compliance manager should have run quarterly reviews. The MSP should have prompted them. We’ve watched this story play out across dozens of engagements. The framing is wrong. Drift is structural. It happens when documentation lives somewhere the business doesn’t.
Naming Drift as a Structural Problem
Most CMMC guidance talks about documentation hygiene the way personal finance talks about budgeting. Build a habit. Set a reminder. Run a recurring meeting. The implicit theory is that contractors fall behind because they aren’t disciplined enough.
That theory does not survive contact with a 50-person manufacturer. The compliance manager, if there is one, has six other roles. IT is reactive by necessity. Nobody on staff has the authority to chase every infrastructure change back into the SSP. The result is not laziness. It is a system without a feedback loop between change and documentation.
Drift is not what happens when the contractor fails. It is what happens by default when the documentation is a deliverable and the business is a process. The deliverable freezes the moment it’s produced. The process keeps moving. The gap opens immediately.
That’s the position. Discipline isn’t the answer. Architecture is.
The Five Forms Documentation Drift Takes
The SSP, the asset inventory, the network diagram, the POA&M, the access matrix. They go stale in different ways for different reasons. Naming the forms matters, because each one has a different point of failure.
Configuration drift. Someone changes a firewall rule, a group policy object, a conditional access policy, an S3 bucket setting. The change happens in the system because the business needed it. The SSP, which described the prior configuration, does not get updated. Multiply that across a year and a 110-control program and the SSP describes a fiction.
Asset drift. A new endpoint, a new SaaS subscription, a new virtual machine, a new contractor laptop. The CMMC asset inventory was accurate the day it was produced. New assets enter the environment without entering the inventory. Old assets get retired without being struck from it. The asset inventory becomes a record of what used to be true.
Personnel drift. Roles change. The named system owner for an access-control requirement leaves the company. Incident response transfers from the IT director to a new MSP. The change happens in the org chart. It does not happen in the SSP, the POA&M, or the responsibility matrix. Audits surface this constantly, a control attributing ownership to someone who left eight months ago.
Process drift. The procedure for granting access used to run through HR. It now runs through a ticketing tool a project manager set up because HR was slow. The documented process and the operating process diverged on a Tuesday afternoon. The assessor will notice.
Vendor drift. A managed service got swapped. A backup tool got replaced. A SIEM got migrated. The vendor list in the SSP references a system that doesn’t exist. The shared responsibility matrix still names a partner who no longer holds the contract.
Five categories. Each has its own cadence. Configuration drift is weekly. Asset drift is constant. Personnel drift averages quarterly. Process drift is silent until it surfaces in an audit room. Vendor drift hits hardest at the worst time, because vendor changes happen mid-cycle and nobody propagates them into the compliance artifacts until prep starts.
A six-month-old SSP is a snapshot of an organization edited everywhere except in the documentation.
Why “Documentation Discipline” Has Failed as a Solution
The industry has been selling discipline as the answer for a decade. Run quarterly SSP reviews. Set up a compliance steering committee. Use a GRC tool to track outstanding remediations. Make the compliance manager a P&L line item.
Each one of those interventions can work. None of them can scale. Here is the structural reason.
The cadence of review is always slower than the cadence of change. A quarterly SSP review captures one quarter of drift in arrears. By the time it concludes, a new quarter has started. Discipline against a moving target reduces the gap. It does not close it. The asymptote is non-zero drift.
The cost of discipline scales with the size of the documentation surface. As CMMC programs mature, that surface grows. More controls in scope means more artifacts. More systems means more configurations to track. The labor required grows faster than the labor available, and that’s before annual self-attestations and triennial assessments stack on top.
The person running the discipline is the same person running the business. Compliance managers at small contractors are not full-time roles. The MSP doing the readiness work is paid by the engagement. When the engagement ends, the discipline ends with it. The contractor returns to a baseline state of drift the day the consultant invoice clears.
And the tooling sold against this problem has been wrong-shaped. GRC dashboards report on documentation. They do not produce it. A dashboard tells you the SSP is out of date. It cannot make the SSP not out of date. That gap is the entire industry as of early 2026.
Discipline buys a temporary suppression of the symptom. The disease is unaddressed.
What a Living System of Record Actually Is
The right answer to drift is to stop treating documentation as a deliverable and start treating it as a byproduct.
A living system of record is exactly what it sounds like. A single source of truth for the contractor’s compliance posture, where the documentation pulls from operational data rather than the other way around. The SSP, the asset inventory, the access matrix, the network diagram, the POA&M. They all read from the same underlying records. When something changes in the operating environment, the change propagates to every artifact that references it. Change it once. It updates everywhere.
The conceptual move is subtle. In the old model, the SSP is a document a human authors at a point in time. It captures the state of the world at that moment, and from that moment forward, it ages. In the new model, the SSP is a view onto a live data structure that describes the current state of the world. There is no aging, because the view always reflects the most recent data.
Three properties make a system of record genuinely living, rather than just a fancier dashboard.
It captures the data at the source. The firewall configuration is not retyped into a document by a human. It is pulled from the firewall itself, or from the configuration management tool that maintains the firewall. The asset inventory is not curated quarterly. It is sourced from the device management platform, the cloud provider’s resource graph, and the identity provider’s enrolled-device list, continuously.
It maintains the relationships, not just the data. A control mapping is not a static row in a spreadsheet. It is a link between an objective, the system that satisfies it, the configuration that implements it, the evidence proving it, and the person who owns it. When any node in that graph changes, the system knows what else has to change. Documentation regenerates from the graph.
It writes through, not around. When a remediation closes, the closure is recorded in the system of record before any artifact updates. There is no out-of-band SSP revision. The system of record is canonical. Every other artifact is a view.
When all three properties hold, drift stops being a manual problem. The compliance manager isn’t chasing changes. The system is. The role shifts from “maintain the SSP” to “make decisions about the things the system surfaces.” That is a different job, and a tractable one for small contractors.
This is the architectural answer. It is also the difference between a dashboard and an operating layer. The dashboard reports drift after the fact. The living system of record prevents drift by removing the gap where drift happens. There is no gap between the change and the documentation because they are the same record.
Proof in flow is the companion idea. Evidence is captured as a byproduct of the work. Documentation is captured the same way. Same architectural pattern, two artifacts. If both are byproducts of the work, the assessor finds an environment where the records and the reality match. That is what audit-ready means.
The Drift Audit Contractors Can Run This Week
Specifics, because the abstract version of this argument doesn’t move anyone to do anything different on Monday.
Pick three artifacts. The SSP, the asset inventory, and the access matrix are the highest-leverage choices. For each one, ask three questions.
When was this last updated by a human? If the answer is more than ninety days, you have drift.
What would have to change in the operating environment for this artifact to need an update? List the triggers. New endpoint. New user. Firewall change. Policy change. Vendor change. If you cannot list the triggers, the artifact is not being maintained against reality. It is being maintained against memory.
Who would know that the trigger happened? If the answer is “the person who left in October” or “the MSP who finished their engagement,” the feedback loop is broken. The change is happening. Nobody is closing the loop.
Run those three questions across the three artifacts and you have a drift inventory in under an hour. We’ve watched contractors who thought they were eight weeks from assessment realize, in that hour, they were closer to eight months. Better to find out now than at the wall.
What to Look For When Evaluating Tools
The drift problem changes how contractors should evaluate compliance tooling. The right questions are not the usual ones.
Ask whether the tool reads from operational systems or asks humans to type into a form. Tools that ask humans to type are recreating the drift problem inside a different UI.
What happens when the firewall config changes? If the answer is “we send a notification” or “we update the dashboard,” that is still drift, just with a faster reporting layer. The right answer is “the SSP regenerates” or “the affected control mapping updates automatically.”
Ask whether the assessor sees the same record the contractor maintains. If the audit package is a separate artifact assembled before assessment, the tool is not a system of record. It is an export tool. The audit package and the operating environment must be the same thing, viewed through a different lens. That is the test.
Ask how the tool handles the POA&M lifecycle across cycles. If remediations resolve into a different system than the ongoing compliance posture, you have two systems of record, which is to say you have none.
Personnel change is the last test. If the responsibility for a control is hardcoded to a name, the first time someone leaves, the tool has drift baked in.
The contractors who’ll pass Phase 2 aren’t the ones with the best documentation. They’re the ones whose system of record updates itself when the environment changes.
Where This Lands
Documentation drift is not a problem to be managed. It is a problem to be designed out of existence. The contractors who treat it as a discipline issue will spend the rest of the CMMC cycle running quarterly reviews against a continuously moving target, and they will fail or barely pass for the same reason they failed or barely passed last time. The math of the drift cadence makes that inevitable.
The contractors who treat it as an architecture issue will replace the gap with a feedback loop. The SSP becomes a view, not a document. The asset inventory becomes a query, not a list. The POA&M becomes a state machine, not a spreadsheet. None of that is a tooling fad. It is the structural shift the 110 controls mapped to NIST 800-171 actually require if you read them carefully. The controls assume the documentation reflects the system. They do not assume the documentation lags the system by a quarter.
Documentation-as-deliverable was a 2018 idea. The 2026 idea is documentation-as-byproduct. That shift is what makes the difference between a contractor whose compliance program persists across cycles and a contractor whose compliance program resets every assessment. It is the difference between a compliance project and a compliance operating layer.
The right answer to the SSP that’s going stale right now isn’t a better SSP. It’s an SSP that maintains itself.