I spent nearly a decade helping run FedRAMP, including launching it in 2012 and serving as its director for the first seven years. I wrote a lot of the requirements that cloud service providers are still working to meet today.
I'll be honest: It's a lot more fun writing the requirements than implementing them.
But that experience (sitting in the middle of FedRAMP, on both the government and vendor side) gives me a particular view of what's changing with Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER). And why most teams are underestimating what FedRAMP 20x actually demands.
For the first fifteen years, FedRAMP relied heavily on documentation. You wrote hundreds of pages explaining how you secured your environment, collected evidence to back it up and periodically had someone come in to validate that you were doing what you said. Every few years, you ran the cycle again.
There's real value in that model. I know because I built it. But a 400-page security plan tells you what someone documented at a point in time. It doesn't tell you whether the system is secure today. 20x is closing that gap, and VDR & VER is the first step.
Instead of describing what you do, you prove it with live operational data, evaluated continuously against actual risk. It changes what compliance actually proves.
The POA&M process, for those who've lived it, is a prioritization and reporting exercise. Vulnerabilities come in from your scanner. You assign a severity, do some risk adjustments and manage the list against fixed timelines: Highs in 30 days, moderates in 90, regardless of what those vulnerabilities actually mean in your environment.
VDR & VER replaces that with something more contextual. Every finding now has to be evaluated against three factors: Reachability, exploitability and potential impact to federal customers (PAIN). A critical vulnerability on an internet-facing system handling federal data is an entirely different problem from the same vulnerability buried behind two layers of authentication on an isolated internal server. Under the old process, both got the same priority, risk rating and clock to remediate. Under VDR & VER, context drives the response. That means your team spends less time defending why a vulnerability is still open and more time closing the ones that actually matter.
That sounds like an improvement, and it is. But that’s where most programs stumble.
To automate that contextual evaluation at scale, you first have to understand your assets in a way most FedRAMP compliance teams haven't had to before.
Take a common scenario: A scanner flags a vulnerability on one of your systems. To evaluate it properly under VDR & VER, you need to know whether that system handles federal customer data, how it's exposed to the internet and what other systems it connects to. Without that context already defined, someone on your team has to rediscover it for every single finding. At the volumes VDR & VER generates, that manual rediscovery becomes a bottleneck.
Working with customers now standing up their VDR & VER programs, this is where I consistently see programs struggle. It's almost always a foundation problem, not a technology one. Most teams have that information somewhere (in operations, in engineering, in different corners of the organization) but it hasn't been assembled at the compliance level.
Getting that asset context right upfront is unglamorous work. It feels like going backwards when you're already behind. But it's the foundation everything else runs on. Without it, you're still doing manual triage, just with more steps. With it, most of that evaluation work gets automated, and your team's attention goes to the cases that genuinely need human judgment.
FedRAMP 20x hasn't been completely prescriptive about how you run your VDR process. That's deliberate. The intent is to let organizations prove security the way they actually operate, rather than forcing everyone into the same documentation template.
Used well, that flexibility is one of the more valuable aspects of the new model. Your VDR process can reflect how your environment actually works, not how a compliance template assumes it should. For engineers and compliance managers who like clear rules, the lack of prescription can still be frustrating. I understand that. I'm one of those people.
The flexibility is in how you define things: how you classify your assets, how you assess exploitability, how you determine agency impact. What isn't flexible is the requirement that those decisions are consistent and repeatable. Two analysts looking at the same vulnerability under the same conditions should reach the same conclusion. Every time.
That repeatability is what makes your program defensible to an assessor or a sponsoring agency. The flexibility FedRAMP gives you at the front end has to be backed by logic that holds up at the back end.
Once your VDR & VER program is running well, two things should be visible.
The first is reduced human effort on the kind of work that doesn't require human judgment: Data gathering, manual context lookups, spreadsheet consolidation. That work should be automated away. If it isn't, the program isn't working as intended.
The second is that the work your team does do is genuinely useful. Not compliance theater. The vulnerabilities getting the fastest attention should be the ones that present the greatest actual risk to your environment. Over time, you should be able to see that in your remediation data: High-exposure findings closing faster, lower-risk findings managed at the right pace.
That's the version of FedRAMP I always thought it should be, and for the first time, with 20x, the program is structured to deliver it. Compliance that reflects real security.
One thing worth knowing about our approach at Diligent: When FedRAMP announced VDR, the asset-context model it requires was already the direction our platform was heading. We weren't retrofitting an existing tool to meet a new requirement. VDR is the first of FedRAMP's three new requirements under 20x. The asset foundation you build now is what KSIs and the Trust Center run on in 2027.
Having built FedRAMP and spent years watching teams implement it, I've seen where this consistently breaks down. If you want to talk through your VDR program (where to start, what assessors will look for, how to build the asset foundation that makes everything else run), reach out to us.
