The public conversation around FedRAMP VDR has gotten too simple, too quickly.
Automate vulnerability management. Ingest the scanner output. Generate the report. Share the evidence. Meet the December deadline. Everybody take a lap.
Now do it in a real cloud environment where the asset data is messy, the scanner output is noisy, the agency impact depends on how the system is used, and the first version of your scoring logic is probably going to be wrong.
Roll up your sleeves, folks: That is where the actual work starts.
That’s because FedRAMP’s new Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) requirements move the work into a harder place. Cloud service providers now have to connect vulnerability findings to the security context of the actual system: where the vulnerability sits, what it touches, what impact it could have on federal customers, what response timeline applies, and whether the decision can be explained later without everyone suddenly discovering a deep personal interest in goat farming.
In this episode of the 38North Security Podcast, Ingrid Velasquez-Woodley speaks with Sam Leestma, Vice President of Solutions Engineering, and Spence Witten, Principal of Cybersecurity Consulting, about why VDR is being underestimated, why VER is where the real work shows up, and why automation only works when the organization has done the much harder work underneath it.
Watch the full discussion:
If you’d rather read it, here is the full breakdown.
The Market is Making VDR Sound a Little Too Clean
A lot of the current conversation around VDR is focused on the parts that are easiest to package: more automation, better reporting, continuous vulnerability management, machine-readable outputs, and the December 7, 2026 deadline. Those are real pieces of the story. Providers do need a more current, automated way to support VDR and VER, and the legacy monthly scanning model is not going to carry the weight of the new requirement.
The problem is that automation has become the easy word to cling to. It makes the requirement sound like a tooling problem, when the harder work is deciding what the automation should believe. A scanner can discover a vulnerability, but the scanner does not know what that asset does for the agency, what data is involved, what protections sit around it, whether the vulnerability is actually exploitable in that environment, or whether the response timeline should change based on that context.
That was Sam’s first point in the conversation. The answer, he said, lies in VER: the evaluation. To evaluate vulnerabilities correctly, a provider has to know a lot about its system. It needs telemetry. It needs to know where vulnerabilities sit, what protections exist around those assets, and how those details affect the attributes of the vulnerability. It has to pull information from different places and build the story around what the vulnerability actually means.
More frequent scanning helps. More current data helps. But raw scan results by themselves do not allow a provider to respond appropriately, prioritize and categorize vulnerabilities, or give customers assurance that the provider understands what can actually affect their data and systems.
That is the distinction getting lost in the more convenient parts of the market conversation. VDR does not get hard because providers lack vulnerability lists. VDR gets hard because the list has to become a defensible decision.
Is your organization’s FedRAMP vulnerability program ready for the December 7th deadline? Get your readiness review here.
VER is Where the Work Starts to Bite
Spence made the point that VDR and VER really need to be considered together. A lot of people are going to keep saying “VDR” because that is the term everyone has been using since the beginning of the 20x conversation, but the evaluation and reporting piece is where the process becomes operationally serious.
The older model was blunt: high, medium, low. Thirty days, ninety days, one hundred eighty days. It was not elegant, and it was definitely not fun, but it was understandable. A team could take the scanner output, pull the highs, mediums, and lows, track the SLAs, populate the POA&M, and move the machine forward.
VDR and VER add the questions that actually matter. Where does the vulnerability live? What data is exposed to it? How exploitable is it? How publicly accessible or internet-reachable is the affected asset? What would exploitation mean for the agency customer? Those questions are much closer to how a security leader would want to prioritize in the first place.
Spence put it in CISO terms (with the appropriate caveat that nobody should make him a CISO): If he had a stack of vulnerabilities, he would not want to sort them only by an arbitrary CVSS high, medium, and low. He would want to know where the vulnerability lives, what data is exposed, how exploitable it is, and how reachable the affected system is. That is how prioritization should work.
CVSS still has a role. It is a useful starting point. But CVSS was never designed to be a reactive, system-aware model that understands whether a vulnerability is exploitable in a specific environment or whether the risk should move up or down based on architecture, exposure, protections, and agency impact. The industry has been using it as if it could do that job, and now FedRAMP is forcing a more granular conversation.
That is why providers need processing logic. They need a way to tag vulnerabilities as scan results come in, apply system context, normalize and de-conflict findings, and rescore them on the fly. Trying to do that manually, finding by finding, is where the whole thing falls apart.
Even a small organization can have a few hundred findings on a recurring basis. De-conflicting scanner results, normalizing them, figuring out where they sit, applying exposure and exploitability logic, mapping the affected data, and assigning response timelines by hand is not a serious plan. It is a spreadsheet-shaped cry for help.
Learn more: FedRAMP Rev. 5 Providers Have Until December to Change How They Manage Vulnerabilities
Sometimes Complexity is Better
FedRAMP 20x is getting some grief because PAIN ratings and response timelines are more complicated than the old 30/90/180-day model. That criticism is understandable. People like simple rules because simple rules are easy to operationalize, easy to explain, and easy to audit.
Security, unfortunately, did not stay simple just because the spreadsheet liked it better.
Spence’s view was that sometimes complexity is better, and this is one of those cases. The new model reflects the reality that providers are not going to fix every vulnerability immediately everywhere it exists. The real question is which subset needs action now, which subset can move on a different timeline, and which findings still matter but do not deserve the same level of urgency.
Sam added the reason that matters. The threat landscape has changed. AI-enabled attack automation, faster vulnerability discovery, and faster exploitation all compress the timeline, especially for externally available vulnerabilities. A provider that treats every high vulnerability as a 30-day problem may already be behind by day two.
At the same time, Spence pointed out that the world is now full of vulnerability slop. AI and automated research can produce a lot of findings that may never be worth exploiting, may not be consistently exploitable, or may not be durably persistent. The answer cannot be treating everything as equally urgent. That just creates noise, fatigue, and eventually a giant pile of accepted risk that nobody wants to talk about.
VDR and VER are trying to force a more useful split. Some vulnerabilities are high when they matter. Some are more relaxed when they do not. That complexity is annoying, but it is also more realistic than pretending every finding with the same generic score carries the same operational impact.
The Data Model Matters More Than the Dashboard
To calculate a Potential Agency Impact N-rating, or PAIN rating, consistently, providers need more than scanner data. They need to know what kind of data they have, where that data sits, what the impact of that data is, and how the affected asset fits into the system.
Sam used the simplest possible example: a system with a lunch menu should not be treated the same way as a system with a large amount of HR data. A scanner may produce findings that look similar, but the potential agency impact is not the same. The provider has to know the difference before it can make a useful decision.
That turns VDR into both a technical problem and a communication problem. Providers need internal telemetry about where data sits, what kind of device or resource is affected, what protections exist around it, and how many similar assets share the same vulnerability. They also need to understand what the system means to the agency customer because the CSP’s implementation is part of a larger FISMA authorization and a larger agency risk picture.
And that is where the dashboard story starts to get thin. A dashboard can show a rating, but the rating is only as good as the context behind it. If the asset inventory is incomplete, the tags are stale, the data flows are poorly understood, or agency impact is mostly vibes, the output is going to inherit that weakness.
The same is true for the model itself. Providers can come up with scoring logic that looks reasonable in a room. Then they have to run it against the real environment and see what happens. Spence called this out later in the conversation: the first version is going to be out of whack because nobody gets it right in a vacuum. You need tuning time after deployment because it is not going to work perfectly out of the box.
That may be the most practical warning in the whole discussion. December 7 is not the day to find out that the model technically works but produces nonsense.
Your FedRAMP vulnerability program has until December 7 to change. Start your readiness review.
Rev. 5 Providers Need to Stop Treating This Like a Future 20x Project
VDR and VER become mandatory on December 7, 2026 for cloud services obtaining or maintaining FedRAMP Certification. That includes existing Rev. 5 providers.
That timing matters because a lot of providers are still mentally sorting FedRAMP 20x into the future-work bucket. They are thinking about 20x as a transition project, a strategy decision, maybe even a procurement conversation. VDR and VER sit in front of that. They become part of the operating model for current FedRAMP cloud offerings before many providers complete a broader 20x transition.
Spence called it a sea change, and his concern was that GRC teams may not realize how hard this lands on the operational side of the house. On the surface, the requirement can look manageable. Security operations, product security, engineering, incident response, and leadership may see the blast radius very differently.
His advice was not complicated: If you are in GRC, call a meeting with the security operations people, product security people, and the teams you usually try to shield from compliance nonsense. They can tell you how this changes their life. The answer will vary by organization because every provider has its own shadow processes, corporate reporting, vulnerability workflows, board-level reporting, and federal-specific exceptions.
This is where VDR stops being a compliance update and starts messing with the way the company actually operates. Spence gave the example of board-level vulnerability reporting. A public company may already have a quarterly process for communicating vulnerabilities to the board, even though there is no neat NIST control for that exact thing. VDR can still affect it because the federal vulnerability model is changing underneath the reporting.
The timeline is tight once you look at the actual work. Spence estimated that rolling out data tagging could take a month in a mid-size or large organization, and implementing the technical solution could take another month or two. Then you still need tuning time because the first version of the logic will not be right. Suddenly “we’ll deal with it later” starts to look less like a strategy and more like a dare.
The Old POA&M Scripts Are Not Invited to This Party
The legacy monthly scanning process was painful, but it was relatively easy to understand. Pull the scan results. Sort the highs, mediums, and lows. Track the SLAs. Populate the POA&M. Chase the deviation requests. Do the spreadsheet ritual. Complain, reasonably, and continue.
Spence said 38North Security does this kind of vulnerability review all the time. Under the old model, you could validate whether companies were processing vulnerabilities correctly, reporting them accurately, capturing all of them, and meeting the applicable timelines. It was not glamorous work, but the analysis was straightforward.
VDR makes that analysis infinitely more complicated. Providers now have to factor in where the vulnerability sits, whether the asset is publicly accessible or internet-reachable, whether the vulnerability is actually exploitable, what data or function is exposed, and which timeline applies after all those factors are considered. Findings that looked similar under the old severity model may land on different timelines under VDR.
That is why manual processing is a fantasy. A script that grabs highs, mediums, and lows from a scan report and drops them into a POA&M will not solve for system context, exploitability, agency impact, divergent deadlines, mitigation status, acceptance records, and reporting outputs.
Sam framed the divide as organizations built around security versus organizations built around compliance. Commercial organizations that already secure highly sensitive information may have tooling, telemetry, and operational response processes that are at least adjacent to what VDR requires. They may not meet the exact FedRAMP rules yet, but the concepts are familiar.
Organizations that have lived entirely in federal compliance may have a harder time if their vulnerability process is built around monthly scans, spreadsheets, deviation requests, and doing the required thing because the government asked for it. Sam’s line was blunt: compliance does not equal security. VDR may be one of the clearest places where FedRAMP is trying to force the two closer together.
Mitigation is Where the Paperwork Starts Losing
FedRAMP’s distinction between remediation and mitigation matters because providers will have vulnerabilities they cannot close inside the applicable timeline.
Remediation means the vulnerability is gone. The provider applied the patch, changed the configuration, updated the component, or otherwise removed the vulnerability from the system.
Mitigation means the vulnerability may still exist, but the provider has changed the conditions around it to reduce exploitability or lower the potential impact. That could mean isolating systems, adding protections, reducing exposure, changing architecture, or in some cases taking something offline until a real fix is available.
Sam used the example of a multi-tenant agency system handling HR data. If that system has an N5 vulnerability and no patch is available, the old answer cannot be “vendor dependency, please extend.” The provider has to look at the security context of the system and determine whether existing protections bring the risk down to an acceptable rating and timeline. If they do not, the provider has to add more protection.
That changes the work. Mitigation becomes an architecture and operations issue, not a note in a POA&M. At higher PAIN levels, incident response may activate quickly, especially at Class D and in some Class C situations. Providers that keep generating N4s and N5s may need to change the security design instead of manually reacting every few days.
Spence connected that to incident response maturity, which is where the conversation got especially practical. A control set can create a framework for incident response, but no single NIST 800-53 control makes an organization good at incident response. Teams get good by doing it. A lot of compliant teams are weak at incident response because they rarely run those processes themselves; they rely on a corporate IR team or a third party.
VDR is going to put pressure on that arrangement. If the federal program starts streaming high-impact vulnerability activity into a corporate IR team, that team is going to have thoughts, feelings, and probably a calendar invite with too many people on it. Providers will either need to get stronger internally or build a much tighter operating model with the teams that own response.
Risk Acceptance Has to Grow Up
Risk acceptance is common in commercial security programs, but it has always been awkward in FedRAMP. Private-sector organizations accept risk all the time. Sometimes executives sign off on a high vulnerability because the business has decided to live with it. Under traditional Rev. 5 FedRAMP, that kind of acceptance was much harder to use cleanly.
FedRAMP 20x gives providers a more explicit path for accepted vulnerabilities, and Spence saw that as a good move. It brings FedRAMP closer to commercial practice while also making commercial practice more disciplined.
That second part matters. Risk acceptance gets abused when teams run out of better options. A company piles up hundreds or thousands of high findings, cannot deal with them, and eventually starts accepting risk because the alternative is admitting the process is broken. FedRAMP is not creating acceptance as a shrug button.
Accepted vulnerabilities still require explanation. They still need to be reported. The provider still has to show why the risk is being accepted, what remains, and why the decision is defensible. That is a healthier model than pretending risk acceptance does not exist, and it is much better than letting unresolved vulnerabilities disappear under a blanket sign-off.
Automation Still Has to Be Designed by People
A lot of VDR commentary gets flattened into “it’s automated now.” The tool ingests the scanner output, applies the logic, generates the rating, and the process starts to sound almost self-executing.
In the conversation, Ingrid paused on that exact point. Sam had been explaining that the strongest VDR model did not come from engineers sitting alone, or from compliance people sitting alone. It came from getting risk managers, compliance, security, and engineering in the same room to decide what matters, what information needs to be derived, and how those concepts can be proven programmatically.
That is where human judgment enters the automation.
People still have to decide which inputs matter, how to represent agency impact, how to weigh asset role and exposure, how to account for existing protections, how to handle edge cases, and what the model should do when a vulnerability is technically present but meaningfully mitigated.
Spence took that point further. There is always a place for human judgment in vulnerability management. A security leader or analyst may look at a rating and disagree. They may need to document why a countermeasure lowers the risk, why a finding is mitigated in one part of the environment, or why a custom software vulnerability needs a different kind of review.
The difference is volume. People cannot apply that level of manual judgment to every finding, every time. Automation should handle the repeatable bulk of the work so human intelligence can focus on the weird edge cases, the odd vulnerabilities, the custom systems, and the decisions where the default logic gets close but does not fully capture reality.
That is a much more useful way to talk about automation. VDR does not remove the human component. It moves the human component into the design of the model, the tuning of the logic, and the review of the exceptions.
VDR Does Not Belong in a Compliance Corner
Ownership may be the biggest cultural shift in the whole requirement.
Under the old model, many organizations could maintain a separate federal compliance ecosystem. A FedRAMP team could sit slightly apart from the rest of the company, collect evidence, manage spreadsheets, tap corporate teams when needed, and translate security work into compliance artifacts. That structure made sense in a world built around periodic evidence reconstruction.
VDR does not fit neatly into that corner. The work cuts across GRC, security operations, security engineering, product security, incident response, IT automation, and leadership. The federal compliance program no longer dictates exactly what the organization should look like. It tells providers what they need to produce, and the provider has to decide how the business will actually produce it.
Spence described it as organization-dependent. FedRAMP is not telling every provider how to structure the team. It is saying, in effect, that the provider needs to report this data and realistically needs automation to get there. The company has to figure out the operating model behind the scenes.
That is the cultural change hiding inside the technical requirement. FedRAMP vulnerability management is moving closer to actual security operations. Providers that treated compliance as a parallel universe are going to feel that shift.
Where NorthWatch Fits
NorthWatch VDR was built for the evaluation and reporting layer of this problem.
NorthWatch does not perform vulnerability scanning. It does not patch, mitigate, remediate, or manage broad change control. It ingests scanner output, applies the configured security context of the system, calculates the applicable Potential Agency Impact N-rating and response deadline, maintains watch-list status, and produces reporting outputs.
The simplest framing is still useful: Your scanners find the vulnerabilities, and NorthWatch tells you which ones matter and by when. The product does not make VDR magically easy because VDR is not magically easy. It gives providers a way to operationalize the part that cannot be done well with scanner output and spreadsheets alone: contextual evaluation, response deadlines, status, and reporting.
The services layer matters because the context has to come from somewhere. Advisory helps define the path, scope, and operating decisions. Engineering helps build the integrations, telemetry, tagging, and pipelines that make the model work. NorthWatch makes the result visible, reviewable, and shareable.
That is also why “plug it in and you are compliant” is the wrong promise. VDR depends on the system. It depends on the data. It depends on the customer. It depends on the operating model. The tool matters, but the tool has to be configured around the reality of the environment.
Stop Being Flippant and Get to Work
Sam and Spence’s closing advice was basically: Stop being flippant about this and get to work.
That is probably the right message. The market is going to keep making VDR sound clean because clean messages sell. But providers have to live with the messy version: imperfect asset data, incomplete tagging, noisy findings, legacy workflows, unclear ownership, agency-specific impact, mitigation decisions, risk acceptance, incident response pressure, and scoring logic that needs tuning before anyone should trust it.
Rev. 5 providers have until December 7, 2026 to make VDR and VER part of the operating model for cloud services obtaining or maintaining FedRAMP Certification. That means the work needs to start well before the deadline. The first step is getting the right people in the room and mapping how vulnerability management actually works today.
Where do scan results come from? How are findings normalized and de-conflicted? How are assets classified? Where does federal data live? Which systems are internet-reachable? Who owns mitigation? Who owns remediation? Who can accept risk? What happens when there is no patch? What reporting already exists, and who relies on it?
From there, providers need to find the gaps in the data, the logic, and the operating model. Weak context will produce weak vulnerability decisions. Stale tags, unclear ownership, incomplete inventories, and poorly understood data flows will show up in the output. Automation only becomes useful when the information behind it is good enough to defend.
The providers in the strongest position will be the ones that can turn scanner output into contextual evaluation, response deadlines, mitigation decisions, acceptance records, and reporting that agencies and assessors can rely on without rebuilding the analysis manually every time new scan results arrive.
Talk With 38North About VDR and VER Readiness
If you are not sure whether your current vulnerability program can support VDR and VER, now is the time to find out.
38North Security helps cloud service providers evaluate their current vulnerability management process, identify data and automation gaps, define the VDR operating model, and prepare for the December 7 deadline.
Talk with our team about a VDR/VER readiness assessment or a NorthWatch VDR conversation.
About the Authors
