Continuous Over Point-in-Time
An assessment starts aging when accounts, software, providers, or boundaries change. Review the claims affected by those changes instead of waiting for the next full reconstruction.
The Blueprint states the principle. This page explains why it matters, what changes, and where the limits remain.
The traditional approach
A contractor prepares for an assessment, gathers evidence, fixes gaps, and shows what was true during the review. The next week, an administrator creates a privileged account. Six months later, the company changes its backup service. The assessment remains part of the history, but it cannot answer whether those changes preserved the safeguards.
A three-year certificate answers a real question about the assessment period. It should not be stretched into a claim that every relevant fact remains true for three years.
The CMMC 20X approach
Give each important claim a refresh rule. Account coverage may need a new export every month. A policy approval may remain current for a year. A recovery test may be repeated on a schedule. A new identity provider should immediately reopen every claim that depended on the old one.
This is not automated certification. It is a practical way to identify which evidence and findings need attention now.
In practice
| Fixed-cycle review | CMMC 20X |
|---|---|
| Evidence recollected before each review | Each evidence type has a refresh date |
| One age rule for the whole package | Account exports, policies, scans, and recovery tests age differently |
| System changes found during the next review | A relevant change reopens the claims it affects |
| Old certificate used as the current state | Past finding preserved alongside later changes and open work |
What should trigger review
- Scope change — new systems, enclaves, CUI flows, facilities, or business units
- Provider change — new services, changed data handling, or revised inherited responsibility
- Architecture change — identity, boundary, logging, endpoint, backup, or network redesign
- Security event — a material incident, newly exploited weakness, or failed recovery exercise
- Evidence degradation — collection failure, stale data, loss of coverage, or unresolved contradiction
- Mission change — changed data sensitivity, supplier criticality, or production consequence
What can be checked automatically
Software can refresh an account list, check whether expected logs arrived, detect that an evidence source failed, compare a configuration with its prior state, and notify the owner of an affected claim.
A failed check starts correction or review. A passing check adds current support. Neither one makes a certification or contracting decision.
What changes for each reviewer
For contractors
Fix the records affected by a change while the people who made it still remember why.
For advisors
See what changed since the last visit and spend time on the new risk or unfinished work.
For assessors
See the evidence collected during the period, the changes that followed, and the claims that still need independent testing.
Getting started
- Choose consequential facts. Begin with identity coverage, inventory, vulnerability handling, logging health, boundaries, and recovery evidence.
- Name the source and owner. Record where each fact comes from and who must resolve a failure.
- Define freshness by type. A policy approval, account inventory, scan result, and recovery exercise should not share one arbitrary age rule.
- Define material changes. State which events make which claims or inherited evidence uncertain.
- Keep the human conclusion visible. Record what the reviewer decided and why.