Requirement ID: VDR-TFR-PVR
The requirement
VDR-TFR-PVR sets vulnerability response timeframes based on three factors:
- the vulnerability’s Potential Agency Impact N-rating (PAIN)
- whether it is internet-reachable
- whether it is likely exploitable
The higher the potential impact and the easier the vulnerability is to reach and exploit, the shorter the response window.
The exact timeframes vary by certification class. Classes A and B share the same schedule, Class C is tighter, and Class D is the most stringent. N1 vulnerabilities have no defined timeframe, while the highest-risk N5 vulnerabilities carry the shortest deadlines.
Within the applicable window, providers should either remediate the vulnerability or mitigate it to a lower potential agency impact.
What does this mean?
Once a vulnerability has been evaluated, its context determines how quickly the provider should act.
A lower-impact vulnerability that is difficult to reach or exploit gets more time. A high-impact vulnerability that is internet-reachable and likely exploitable gets much less.
The requirement also gives providers more than one way to meet the deadline. They can mitigate the vulnerability so that its potential agency impact decreases or remediate it.
This article is also a LinkedIn newsletter. If you would like to receive it straight to your inbox, subscribe here.
Why does this matter?
A single response deadline for every vulnerability would treat very different risks as though they were equal.
VDR-TFR-PVR directs the fastest response toward vulnerabilities that could cause the greatest harm and are most accessible to an attacker. That helps teams focus limited vulnerability response effort where delay carries the most risk.
What could implementation look like?
This is illustrative, not mandatory. One approach could be:
- Evaluate each vulnerability in the context of the cloud service offering to determine its PAIN rating, internet reachability, and likely exploitability.
- Use those results and the provider’s certification class to identify the applicable response timeframe.
- Set a due date from the evaluation date and track the vulnerability until it is remediated or mitigated to a lower impact.
- Re-evaluate when conditions change, since changes in reachability, exploitability, or potential agency impact may change the applicable timeframe.
A compensating control may reduce the vulnerability’s risk while permanent remediation is being completed.
Example scenario
A Class C provider detects a vulnerability in an internet-facing service. Its evaluation finds that exploitation could have a high potential agency impact and that the vulnerability is both internet-reachable and likely exploitable.
The team cannot deploy the permanent fix immediately, so it removes external reachability within the required window. That mitigation reduces the immediate risk while permanent remediation continues.
What evidence could demonstrate implementation?
Examples may include:
- Vulnerability records showing evaluation date, PAIN rating, reachability, exploitability, and calculated due date.
- Records of mitigation to a lower impact or remediation.
- Change or configuration records supporting the mitigation action.
- Reporting that compares response dates against the applicable timeframe.
Common pitfall
Setting deadlines from a generic severity score alone.
The required timeframe depends on the vulnerability’s potential impact in your environment, along with internet reachability and likely exploitability. Ignoring those factors can put a vulnerability in the wrong response window.
Question for your team
Can we show how the current PAIN rating, reachability, and exploitability of every open vulnerability determine its response deadline?
Key takeaway
The amount of time you have to act should reflect the vulnerability’s real-world risk: its potential agency impact, internet reachability, and exploitability.
Related requirements
VER-EVA-EPA (Estimate Potential Agency Impact) defines the PAIN rating used to determine the applicable timeframe.
Have a question about putting this requirement into practice?
38North Security can help you turn the requirements into an operating model that works in practice. Talk to us →
The requirement above is summarized from the FedRAMP CR-26 JSON for VDR-TFR-PVR. The complete class-specific timeframe tables are available in the source. Implementation ideas, the example scenario, and evidence examples are general guidance and should be validated against official FedRAMP guidance.
About the Author
