It’s been just over three months since CR26 officially came out, and the first FedRAMP 20x assessments are starting. After months of interpreting rules and building toward continuous validation, providers are reaching the point where somebody independent gets to look at what they actually built.
That means some previously hypothetical questions are getting real answers. What does an assessor actually look at? How far do they trace a validation result into the underlying system? What happens when the dashboard is green but the population underneath it is incomplete? And how much does the assessor care about the logic and source data behind the result?
We sat down with Matt Earley, founder and president of 38North Security, and Justin Padilla, Senior Director of Cybersecurity at Kratos, to talk about what they’re seeing as providers move into assessment and what teams can do now to make the process less painful.
Prefer to watch instead? Here’s the full conversation with Matt Earley and Justin Padilla.
Continuous validation is an operating-model problem
Some providers were surprised by how much CR26 would affect existing Rev. 5 programs, especially as requirements like VDR and VER moved from future-state planning into current work. Providers now have to think through automation, authoritative sources, validation logic, telemetry, reporting, and how all of those pieces stay current as the environment changes.
Learn more: A FedRAMP 20x Primer for Executives
And the organizational work may be even harder. Compliance, security engineering, DevOps, product, and other teams often own different parts of the system. Continuous validation has to pull information from all of them and make it work as one operating model.
That pushes the work much closer to the source: the systems generating the data, the teams maintaining the infrastructure, and the people responsible for whether a security measure is actually working. Smaller cloud-native providers may have an easier starting point because their environments are often more automated and their teams closer together. Larger organizations may have to connect years of accumulated systems, workflows, and ownership boundaries.
Justin is seeing the same uncertainty from the assessor side. Providers want to know how the FedRAMP Rules will be assessed, how much of their Rev. 5 approach carries forward, and in some cases whether they are moving toward 20x at all. Those questions need answers before an assessor starts tracing results through code, telemetry, and source data.
Learn more: FedRAMP 20x VDR Is More Than Just Automation
Valid doesn’t always mean passing
One of the more important things to understand about 20x assessment is that a valid result is not always a passing result. The automation can be working correctly and the data can be coming through accurately, but the result can still show a failure. If the security measure is not meeting the expected outcome, failure is the accurate result.
From the assessor’s perspective, the harder question is whether that result can be trusted. Answering that requires looking considerably deeper than whatever appears in the dashboard.
The dashboard is only the first layer
Matt breaks 20x assessment into three layers of proof. The first is the result itself: what shows up in the dashboard or trust center, the JSON output, and the human-readable explanation of what the provider says is happening.
Underneath that is the validation logic that produced the result. These are the queries, scripts, validators, or other methods pulling information from the environment and deciding whether the expected security outcome is being met. An assessor needs to understand what that logic is testing, how often it runs, what inputs it uses, and whether the result actually means what the provider says it means.
The third layer is the source of truth: the system itself. Inventories, configurations, logs, services, telemetry, security signals, and the other operational data the validation logic is using.
The important part is that the assessor can move through all three. A green result in the trust center may be perfectly accurate based on the inputs it received. But if the validator was only looking at part of the environment, or if the source data was incomplete, the larger claim may still be wrong.
This is where 20x assessment gets much more technical than simply reviewing what is presented on a dashboard. The assessor has to be able to follow the result back through the logic and into the underlying system to understand what was actually measured and whether the result represents the environment it claims to cover.
The result is only as good as the population it covers
Once you can follow the result through all three layers, the next question is whether those layers are looking at the right population in the first place. That is where Minimum Assessment Scope becomes critical.
Learn more: Minimum Assessment Scope and Why FedRAMP 20x May Cost Less to Maintain
Under Rev. 5, scoping could turn into long discussions about authorization boundaries, metadata, dependencies, and third parties. MAS gives providers more room to make risk-based decisions about which resources handle federal data or could materially affect its confidentiality, integrity, or availability. That can produce a leaner scope, but it also means the provider has to be able to explain and defend what it leaves out.
From the assessor side, that means comparing the proposed scope against the actual environment: accounts and subscriptions, architecture, data flows, identity relationships, infrastructure as code, and other sources that show what is really there.
Sometimes the discrepancy is incredibly ordinary. The provider says twenty databases are in scope. The assessor sees nineteen. Or twenty-one. There may be a perfectly reasonable explanation, but the population being validated still has to match the population the provider says it is covering.
Otherwise, even technically sound validation logic can produce a result that overstates what the provider has actually proven.
When the result and the environment don’t match
Say the trust center reports 100 percent logging coverage. The validation logic ran successfully, the dashboard is green, and everything appears to be working exactly as intended. Then the assessor traces the result back and discovers that the logic could only see nineteen of twenty in-scope accounts.
Justin’s first question in that situation is simply: why?
Maybe there is an error in the code. Maybe the telemetry is incomplete. Maybe the twentieth account requires a manual validation method. The point is to understand what produced the discrepancy and whether the reported result still accurately represents the environment.
That is also where the collaborative nature of 20x assessment matters. The assessor is still independent, but the process is not supposed to be a gotcha exercise where one unexpected result suddenly means the provider has failed. The assessor examines the implementation, asks questions, documents what it finds, and gives the government the information it needs to make its own risk decisions.
The goal is an accurate, explainable result supported by what is actually happening in the system, even when that result is a failure.
Start small and prove the whole path
For providers trying to make the assessment less painful, Matt’s advice was to resist the urge to solve all of 20x at once. Pick one or two meaningful KSIs and work them all the way through.
Start with scope. Identify the authoritative sources and the telemetry or security signals you need. Build the validation logic that queries those sources at the right cadence. Then decide where the result is going to be presented and how someone outside the team will be able to understand what it means.
That exercise forces the right questions early. Who owns the source data? What happens when the query fails? How does a new account enter the population? What does the result actually prove, and what is still outside the claim?
It also makes the organizational dependencies obvious. Compliance cannot build this alone. Engineering, DevOps, security operations, product, and the other teams responsible for the underlying system have to be involved because they own the systems and processes the evidence is coming from.
Once one complete path works, the provider has something concrete to scale. More importantly, it has already practiced the kind of scrutiny the assessor is going to apply later.
Bring the assessor in before you think you need to
Justin recommends involving the assessor early. The more the assessor understands about what the provider is automating, where automation is partial, what tools and languages are involved, and what the agency sponsor expects, the easier it is to understand how the assessment itself should be approached.
Early engagement can coexist with assessor independence. The assessor still has to reach an independent conclusion about the implementation and the evidence. Giving them context earlier simply means fewer surprises when the formal assessment begins.
FedRAMP also allows assessors to share advice on techniques and procedures that can improve security posture, effectiveness, clarity, and reporting, as long as objectivity is maintained. In practice, that means providers can ask what the assessor expects to examine, surface problems early, and get clarity on how a particular approach is likely to be evaluated.
That communication becomes even more important when the implementation is not uniform. Some KSIs may be fully automated, others only partially automated, and some may still require manual validation. The assessor needs to understand those differences, and the provider benefits from finding out early whether its approach is understandable and defensible.
Tooling should make the assessment easier to inspect
A useful 20x platform should make the evidence trail easier to inspect. The presentation layer matters, but so does the automation producing the result and the telemetry underneath it.
From Justin’s perspective, the assessor needs to be able to understand how the result was produced and where the underlying data came from. If the platform makes that difficult to follow, it is creating more work during assessment.
Matt made a similar point from the advisory side. The platform also has to support the operating model itself. Continuous validation depends on current data, repeatable validation logic, and visibility into how results change over time. Security teams need to be able to use that information as part of normal operations throughout the year.
That is also why providers should look carefully at tools that have simply added 20x as another framework option. The better question is whether the platform actually supports the way 20x works: current data, repeatable validation logic, traceable results, and enough visibility underneath the dashboard for an assessor to understand how the result was produced.
Learn more: NorthWatch Helps Operationalize Continuous Validation for FedRAMP 20x
It keeps coming back to traceability
By the end of the conversation, we had come back to the same idea from almost every direction: traceability. You can have a dashboard that is sparkling green, strong validation logic, and well-written documentation. The assessment still comes down to whether all of those things are describing the same operating reality.
That means the right scope, the right population, the right source data, and validation logic that actually supports the result being reported. An independent assessor should be able to start with the claim, follow it through the logic and into the underlying system, and understand how the provider got there.
For providers preparing for assessment now, that gives you a practical test. Make those connections explicit before the assessor arrives. Know where the data comes from, what population the validation covers, who owns it, what happens when something changes, and whether the result you are publishing still says what you think it says.
Preparing for a FedRAMP 20x assessment?
38North Security can help you work through scope, validation logic, evidence sources, and assessment readiness before the assessor arrives. Talk to our FedRAMP team → https://38northsecurity.com/contact/
About the Authors
