2026/reference/rev5/d/independent-verification-and-validation/

[giscus[bot]]

2026/reference/rev5/d/independent-verification-and-validation/

This site contains FedRAMP's Consolidated Rules for 2026.

https://www.fedramp.gov/2026/reference/rev5/d/independent-verification-and-validation/

[VSQ22022]

Relationship between Vulnerability PAIN (VER-EVA-EPA, N0–N5) and Incident PAIN (IEC-CSO-EFI, N1–N5)

Both the Vulnerability Evaluation (VER) and Incident Evaluation (IEC) rulesets use the term Potential Agency Impact N-rating (PAIN), but with slightly different scales and contexts:

VER-EVA-EPA (Vulnerability PAIN, N0–N5): Estimates the hypothetical agency impact if a detected vulnerability were exploited (including N0 where exploitation is extremely unlikely to have adverse effects).
IEC-CSO-EFI (Incident PAIN, N1–N5, defaulting to N5 under IEC-CSO-DPR): Estimates the likely adverse impact of an active FedRAMP Reportable Incident (with no N0, since an event with no likely impact on federal customer data would not meet IEC-CSO-EFR reportability).

Could you confirm:

1. Distinct evaluations: Are Vulnerability PAIN (VER-EVA-EPA) and Incident PAIN (IEC-CSO-EFI) intended to be tracked and evaluated independently (e.g., an incident caused by or involving a CVE is rated based on the actual/likely incident impact under IEC-CSO-EFI rather than automatically inheriting the underlying vulnerability's VER-EVA-EPA rating)?
2. How VER-TFR-IRI and VER-TFR-NRI cross over: Under VER-TFR-IRI (unexploited internet-reachable likely exploitable vulnerabilities rated N4 or N5) and VER-TFR-NRI (non-internet-reachable likely exploitable vulnerabilities rated N5), providers SHOULD treat the vulnerability as a FedRAMP Reportable Incident. When one of those N4/N5 vulnerabilities gets treated as an Incident under VER-TFR-IRI or VER-TFR-NRI, does its Vulnerability N4/N5 rating automatically become the Incident N-rating, or is the Incident N-rating evaluated separately under IEC-CSO-EFI?

[pete-gov]

Distinct evaluations: Are Vulnerability PAIN (VER-EVA-EPA) and Incident PAIN (IEC-CSO-EFI) intended to be tracked and evaluated independently (e.g., an incident caused by or involving a CVE is rated based on the actual/likely incident impact under IEC-CSO-EFI rather than automatically inheriting the underlying vulnerability's VER-EVA-EPA rating)?

Yes. A vulnerability means something might happen. An incident means something did happen OR we're assuming something did happen until proven otherwise (the overlap for when a vulnerability gets declared as an incident). Note that it's fairly common for incidents to occur without being tied to a vulnerability until after the incident is resolved and the root cause vulnerability is understood - that's a big reason why there are separate incident vs vulnerability reporting rules.

So sometimes there's an incident without a vulnerability, sometimes a vulnerability means there's a potential incident, sometimes a vulnerability leads to discovering an incident, and sometimes an incident leads to a vulnerability. And sometimes multiple vulnerabilities map in various ways to multiple incidents. So overall the rules are constructed to focus on point of entry / detection (did you detect it as a vuln or as an incident?).

How VER-TFR-IRI and VER-TFR-NRI cross over: Under VER-TFR-IRI (unexploited internet-reachable likely exploitable vulnerabilities rated N4 or N5) and VER-TFR-NRI (non-internet-reachable likely exploitable vulnerabilities rated N5), providers SHOULD treat the vulnerability as a FedRAMP Reportable Incident. When one of those N4/N5 vulnerabilities gets treated as an Incident under VER-TFR-IRI or VER-TFR-NRI, does its Vulnerability N4/N5 rating automatically become the Incident N-rating, or is the Incident N-rating evaluated separately under IEC-CSO-EFI?

Incidents are default PAIN5 (IEC-CSO-DPR Default PAIN Rating) unless they are evaluated separately. Providers can evaluate to a different N rating than the vulnerability, though, if that makes sense. Especially over the lifetime of the incident. For example, 3 different vulnerabilities might be rolled into 1 incident at a higher PAIN rating, or a PAIN5 vulnerability might be mitigated to a single narrow confirmed customer impact shortly after the incident has been declared so the incident gets evaluated as PAIN1.

Realistically though I would expect in most cases that folks will map the initial incident PAIN to the vulnerability PAIN in the case where an incident is triggered by the existence of a high PAIN vulnerability.