By Maril Vernon, Field CISO, Anecdotes
I spent years on the offensive side of security performing red and purple team assessments, bypassing controls that GRC teams, and often times even auditors, were convinced were working.
Spoiler: it was rarely as difficult as it should have been. Not because those teams were careless, but because they were measured against a system that rewarded proving a control existed at one moment in time, not whether it would still hold up operationally on some random Tuesday six months after the audit.
FedRAMP Rev5 was built around that model. Organizations described how controls were implemented, mapped those narratives to NIST 800-53, and supported them with carefully curated evidence.
Assessors then sampled that evidence annually to determine whether the implementation matched the documentation. But, if you've ever participated in an audit then you know how much room that leaves to manage scope and narrative. And if you've ever been a pentester, you know that's exactly where to start looking.
FedRAMP 20X changes the question entirely. Instead of asking organizations to describe their security posture, it asks them to continuously prove it. That shift sounds subtle, but it fundamentally changes what assurance looks like.
The Biggest Change Isn't the Framework. It's the Evidence.
FedRAMP 20X replaces narrative-heavy controls with Key Security Indicators (KSIs): measurable outcomes backed by machine-readable evidence.
There are 56 KSIs in the Low baseline and 61 in Moderate, organized across twelve security domains that include cloud-native architecture, identity and access management, monitoring, incident response, and change management.
The framework moves away from asking whether you documented a process and toward demonstrating that the process is actually working.
A simple example illustrates the difference. Under Rev5, a control might ask you to describe your multi-factor authentication policy. The corresponding KSI asks you to prove, using machine-readable evidence, that phishing-resistant MFA is enforced across every privileged account in production today.
One is a claim supported by curated evidence. The other is an objective fact. Facts are much harder to debate in an audit room.
For organizations that have spent years optimizing for annual assessments, this is more than a documentation update. It requires building systems capable of producing trustworthy evidence continuously, not just assembling it when an audit is around the corner.
Continuous beats point-in-time, because modern threats are continuous
The biggest operational shift in FedRAMP 20X isn't the controls themselves; it's the cadence.
Under Rev5, evidence was collected to support a point-in-time assessment. Under 20X, evidence becomes part of a living system.
Machine-based KSIs are revalidated on a short, recurring schedule, as often as every few days for Moderate systems, while process-based KSIs still require at least quarterly validation.
The expectation is no longer that you can prove something was true once during a fixed window. It's that you can continue proving it's true as your environment constantly changes.
That makes sense when you look at how modern infrastructure actually works. Cloud environments are constantly changing. Developers deploy multiple times a day.
Identities are created, modified, and removed continuously. Attackers figured out years ago that environments don't stay static after an audit.
Compliance has traditionally been the only part of the equation still pretending they do.
FedRAMP 20X is one of the first major assurance frameworks to acknowledge that reality. If your systems operate continuously, your assurance model has to operate continuously too.
Continuous assurance demands continuous evidence
You simply cannot build an evidence package every three days, nor should you have to. Under 20X, evidence needs to flow directly from the systems doing the work.
That means machine-readable data, aligned to OSCAL where applicable, alongside human-readable summaries that provide context, timestamps, and enough information for an assessor to understand what they're looking at.
The Phase 2 completeness guidance makes those expectations explicit. Automation must cover at least 70 percent of KSIs, every KSI must be addressed, and evidence must exist in both machine-readable and human-readable forms.
That isn't busywork. It's recognition that modern assurance requires both automation and explanation. Machines can validate at scale, but humans still need enough context to understand what the data is actually telling them.
For organizations coming from Rev5, this is often the moment where the transition starts feeling less like compliance and more like engineering.
The real work is engineering, not writing
That's because the biggest gap between Rev5 and 20X isn't documentation- it's systems design.
The first step is understanding where you stand today. Run a KSI gap analysis and score every requirement as fully covered, partially covered, or not covered. Identify whether each KSI can be automated, requires manual process, or will ultimately need both.
Follow FedRAMP's recommended priority order, starting with Authorization by FedRAMP, then Cloud Native Architecture and Identity and Access Management before moving into Service Configuration, Monitoring, and the remaining domains.
From there, build the evidence pipeline. Most automatable KSIs already sit on data your organization generates every day through cloud platforms, identity providers, SIEMs, vulnerability scanners, and configuration management tools. The challenge isn't creating new data.
It's consistently collecting it, normalizing it, mapping it to KSIs, generating structured evidence, and doing all of that on the required cadence at scale.
Ironically, the most painful work often isn't the technical telemetry at all. It's policy approvals, governance workflows, training records, and other manual processes that were never designed to operate continuously. Those are usually the longest time hack items, which is exactly why they're worth tackling first.
Your assessor's role changes as well. Under Rev5, a 3PAO spent much of its time evaluating documentation and narratives. Under 20X, they're validating whether your evidence pipeline accurately reflects reality.
Audit becomes less about reading policies and more about trusting the integrity of the systems producing your evidence.
As someone who spent years finding the gap between what organizations documented and what was actually happening inside their environments, I can tell you this eliminates a lot of hiding places for threat actors.
Automation isn’t the goal, sustainability is
None of this means every organization needs to buy a platform. You can absolutely build these pipelines yourself, and many organizations will. But continuously doing everything I’ve mentioned (collecting evidence, normalizing data, mapping it to KSIs, generating machine-readable outputs, creating human-readable summaries, and maintaining those integrations) quickly becomes ongoing engineering work.
That's where automation earns its place. Not because humans can't do the work, but because there are better ways to spend highly skilled engineering time than rebuilding evidence packages over and over again.
Persistent validation should become an operational capability, not a permanent manual project.
We experienced that firsthand at Anecdotes when we became the first agentic GRC platform to achieve FedRAMP 20X Moderate (Or Class C) authorization using our own platform.
We didn't reach Moderate on the first assessment. We initially landed at Low, used the findings to improve the environment, validated again, and ultimately achieved Moderate.
To me, that's the strongest proof that the framework is working exactly as intended. FedRAMP 20X rewards organizations that treat assessment as a feedback loop and continuously improve, not the ones that simply tell the cleanest story.
Start before you have to
The biggest mistake a Rev5 organization can make is treating 20X like a paperwork migration.
If all you do is remap your SSP without building the systems that continuously produce trustworthy evidence, you'll eventually find yourself rebuilding everything under deadline pressure, by hand, which is exactly what 20X was designed to eliminate.
Don't start with your most complicated control, start with the boring one. Pick a KSI where you already have most of the data. Instrument it end to end. Run continuous validation. See what breaks. Fix it. Repeat. Build the muscle before you build the scale.
Because FedRAMP 20X isn't asking whether you can survive one audit. It's asking whether your assurance program can survive every random Tuesday after it. The organizations that make this transition successfully won't be the ones with the best documentation. They'll be the ones that started building continuous assurance before the deadline forced them to.
Go deeper. Anecdotes CISO Jake Bernardes unpacks this move from Rev5 to continuous, machine-readable assurance at the GRC Data and AI Summit 2026, a virtual event on August 12 for security, risk, and compliance leaders getting agent-ready.
If you are staring down the Rev5 clock, that is the room to be in. Register free.
About the author
Maril Vernon is Field CISO at Anecdotes and a former red and purple team operator. She writes and speaks on GRC Engineering, continuous controls monitoring, offensive security, and the evolution of modern assurance programs. Her work focuses on helping organizations move beyond compliance as a documentation exercise and toward security decisions grounded in trustworthy, real-time data. Anecdotes is the first agentic GRC platform to achieve FedRAMP 20X authorization by leveraging its own platform.
Sponsored and written by Anecdotes.
English (US) ·