🔒 Closed beta: four products · 📉 Corrections record: AI mistakes, counted by class and fed back into the next run · 📢 New post: FedRAMP PAIN Ratings: PAIN-0 Added October 5; No Prescribed Method for Rating a Finding · 📝 Also fresh: FedRAMP Status Claims: Brand Use Policy, Not the Consolidated Rules · 🚦 Beacon — the FedRAMP 20x KSI emitter — see what it emits ✨ · 🆕 20x Hub: program reference, kept current · 🧪 KSI Quick Check: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPComplianceConMon

FedRAMP PAIN Ratings: PAIN-0 Added October 5; No Prescribed Method for Rating a Finding

On October 28, 2026, Coalfire published a piece by Michael Allen, a Director there, under the title "FedRAMP hands you a five-level scale. It doesn't tell you how to use it." (The byline on the page reads October 26; the page's structured metadata says October 28.) It previews a white paper describing how Coalfire calibrates Potential Agency Impact ratings, and it closes with a disclaimer worth repeating here: the piece "reflects Coalfire's interpretive methodology under the current FedRAMP Consolidated Rules for 2026" and "is not a substitute for your own legal or compliance review."

So this is a vendor's reading of a program rule, which makes it a reading. What follows is what the rules themselves say, read from the Consolidated Rules datafile at version 2026.10.13.01 and the rendered ruleset pages, on October 29, 2026.

The short version: most of Coalfire's description of the rule checks out, the scale has six levels rather than five as of three weeks before the post, the customer-effect tiers are defined terms with stated thresholds rather than bare labels, and the two default ratings FedRAMP has written down are both at the top of the scale rather than the middle.

The rule, as written

The rule is VER-EVA-EPA, Estimate Potential Agency Impact, in the Evaluation subset of the Vulnerability Evaluation and Reporting ruleset. Force is MUST:

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the likely potential agency impact of exploitation on government customers AND assign one of the following Potential Agency Impact N-ratings (PAIN):

Six ratings follow, not five:

Rating Expected effect
N0 Exploitation is extremely unlikely to have any adverse effects on agencies that use the cloud service offering.
N1 Minimal customer effects on one or more agencies.
N2 Narrow customer effects on one or more agencies.
N3 A disruptive customer effect on one agency.
N4 A debilitating customer effect on one agency, OR a disruptive customer effect on more than one federal agency.
N5 A debilitating customer effect on more than one agency.

N0 was added on October 5, 2026. It came in through issue #32 in FedRAMP's rules repository, opened on October 2 by a FedRAMP maintainer and closed three days later with an "FR Approved" label, asking for "N0 ... for situations where exploitation could be expected to have no customer effects." The same release inserted the word "likely" into the rule statement; the per-rule changelog records it as "Clarified that likely potential agency impact should be calculated; added PAIN0 to clarify that likely potential agency impact can be entirely mitigated/remediated." Before that release the scale ran N1 through N5, which is five levels, and that is presumably the scale the post's title describes.

The combination logic Coalfire describes is accurate. Customer effect has four tiers, scope is one agency or more than one, and the two cross: disruptive on one agency is N3, disruptive across more than one is N4. What the post leaves out of that sentence is that N4 is also where a debilitating effect on a single agency lands, so N4 is reachable by two different routes.

The customer-effect tiers are defined terms

The post's central claim is that "FedRAMP doesn't say how a provider decides which customer-effect tier applies to a specific finding on a specific asset." The four tiers are FedRAMP-defined terms, and they are not bare adjectives. From the definitions page:

  • Minimal Customer Effect (FRD-MCE) — "An unwanted customer effect that is only noticeable by some users. This includes minor inconveniences such as reduced performance."
  • Narrow Customer Effect (FRD-NCE) — "An unwanted customer effect that interrupts use of the cloud service for some users for less than 12 hours, or that compromises the integrity or confidentiality of an extremely limited amount and type of federal customer data."
  • Disruptive Customer Effect (FRD-DCF) — "An unwanted customer effect that interrupts use of the cloud service for many users for less than 24 hours, or that compromises the integrity or confidentiality of large amounts or many types of federal customer data."
  • Debilitating Customer Effect (FRD-DCE) — "An unwanted customer effect that interrupts use of the cloud service for most users or compromises the integrity or confidentiality of most federal customer data."

There are real thresholds in there: a duration ladder of 12 hours, 24 hours, and then no stated bound, crossed with a population ladder of some users, many users, most users, plus a parallel data-impact clause for each. What FedRAMP has not supplied is the step before that — the function that turns a scanner finding on a particular asset into a prediction about how many users lose service for how long. That is a narrower missing piece than "it doesn't tell you how to use it," and it is a real one.

Where FedRAMP says it will not prescribe a method, and where it doesn't

Coalfire writes that "FedRAMP has said elsewhere in the same ruleset that it won't prescribe one, because the mix of factors varies too much from provider to provider to standardize." There is such a statement, and it is attached to a different rule. VER-EVA-ELX, Evaluate Exploitability, carries this note:

The likelihood of exploitation will vary depending on so many factors that FedRAMP will not recommend a specific framework for approaching this beyond these rules.

That is about exploitability, not about impact, and the reason given is the number of factors rather than variation between providers. VER-EVA-EPA itself carries no notes at all — only its statement, the six ratings, a mapping to SP 800-53 RA-03, and a terms list. The refusal to prescribe a method for the impact rating is not stated anywhere; it is inferred from the absence of one.

The companion rule is VER-EVA-EFA, Evaluation Factors, and its force is SHOULD, not MUST. It lists eight factors, each phrased as a question rather than an input: Criticality, Reachability, Exploitability, Detectability, Prevalence, Privilege, Proximate Vulnerabilities, Known Threats. Coalfire's list matches. There is no weighting, no matrix, and no worked example, which is also what the post says. We covered this rule and its MUST-force neighbours when BOD 26-04 landed on the same ruleset.

One more absence is worth stating because it is checkable in ten seconds. Coalfire's methodology recommends crossing asset criticality against "the CVSS Environmental score for that specific finding on that specific asset, not the CVSS Base score." The string "CVSS" appears zero times in the entire Consolidated Rules datafile. The word "severity" appears once, in an unrelated rule about FedRAMP's own corrective actions. CR26 carries no severity-scoring vocabulary of its own, so using CVSS at all, Base or Environmental, is a provider's method rather than a program requirement. Nothing prohibits it either.

The two defaults FedRAMP did write are at the top of the scale

The post previews "a mid-scale N3 default that only moves with evidence — new findings don't start at best case or worst case." FedRAMP has written down two defaults in this area, and both of them start at the worst case.

The first is inside the definition of Debilitating Customer Effect, which continues past the sentence quoted above:

If the adverse customer effect is unknown then it should be treated as if it is debilitating until proven otherwise.

Debilitating on one agency is N4, and on more than one it is N5. So an unknown customer effect, by the definition's own instruction, resolves to the top two ratings.

The second is a rule, and it is a MUST. IEC-CSO-DPR, Default PAIN Rating, in the Incident Evaluation and Communication ruleset:

Providers MUST treat FedRAMP Reportable Incidents as if they have a Potential Agency Impact N-rating (PAIN) of 5 UNLESS they promptly estimate the PAIN rating following the rule in IEC-CSO-EFI (Estimate Federal Impact).

IEC-CSO-EFI is the estimation step, it is a SHOULD, and FedRAMP gives it a separate name — "this step is called Incident Rating" — with a note that "all incidents must be assigned a default PAIN-5 ... if this step is not completed." That is the line Coalfire describes between a vulnerability's rating and an incident's, and FedRAMP draws it by naming the incident-side act differently and assigning it its own default.

There is no equivalent default-rating rule for detected vulnerabilities. Nothing in the Vulnerability Evaluation and Reporting ruleset says where an unrated finding sits while you work on it. A provider that adopts a mid-scale starting point is therefore filling genuinely empty space, which is the post's argument and it holds. It is worth knowing that the two adjacent defaults the program wrote both point the other way, because an assessor reading IEC-CSO-DPR and FRD-DCE in the morning will arrive at your N3 default in the afternoon.

What the rating actually controls

The rating is not a label on a report. It selects a row in four separate clocks.

Remediation. VDR-TFR-PVR, Mitigation and Remediation Expectations, is a SHOULD at every class and carries a table per class, crossing the PAIN rating against internet-reachability and likely exploitability. Class C, verified against the published page:

PAIN LEV + IRV LEV + NIRV NLEV
PAIN-5 2 days 4 days 16 days
PAIN-4 4 days 8 days 64 days
PAIN-3 16 days 32 days 128 days
PAIN-2 48 days 128 days 192 days

Coalfire names 2 days and 128 days as the ends of the Class C clock. Both figures are in the table. So is 192 days, at PAIN-2 and not likely exploitable, which is the longest Class C timeframe and also the point at which VER-TFR-MAV requires the finding to be categorized as an accepted vulnerability — "not or will not be fully mitigated or remediated within 192 days of evaluation."

The Class B figures in the same rule are longer in ten of those twelve cells and identical in the other two — PAIN-4 and PAIN-2 in the not-likely-exploitable column — which is part of how little separates the two classes once the rulesets are diffed.

Two structural details about that table. It has four rows, not six: PAIN-1 is present with no timeframes and PAIN-0 is absent entirely, at every class. And the class tables are not a uniform tightening — at Class D, PAIN-5 with a likely-exploitable internet-reachable finding is 12 hours, which is the only sub-day cell anywhere in the rule.

Incident reporting. IEC-CSO-IIR sets the initial-report deadline from the same rating. At Class C it is 1 hour for N3 and above, 24 hours for N2, and one business day for N1. At Class D the top three ratings collapse to 15 minutes. The difference between an N2 and an N3 at Class C is the difference between a day and an hour.

Incident escalation. VER-TFR-IRI is the bridge in the other direction: a Class C provider SHOULD treat an internet-reachable likely-exploitable vulnerability rated above N3 as a FedRAMP Reportable Incident, and keep treating it as one until it is partially mitigated to N3 or below. VER-TFR-NRI does the same for findings that are not internet-reachable, at N5 only, and it is a MAY at every class except D. Three conditions each — rating, reachability, exploitability — which matches Coalfire's description.

Evaluation itself. VER-TFR-EVU gives Class B seven days from detection to complete evaluation, Class C five days, Class D two. The rating has to be produced inside that window, before most of the context that would justify it exists.

The assessor's side

The ticket that sent me to this source asked for an assessor's reading, so here is the part of the ruleset that governs what an assessor does with a PAIN rating.

VER-EVA-EPA has no rule-specific artifact list, which means it inherits the default expected artifacts for every FedRAMP requirement. Those live in the info.default_artifacts.FRR block of the datafile and, notably, are not rendered on the ruleset pages at all — the string "artifact" appears zero times in the published Vulnerability Evaluation and Reporting page. There are five:

  1. Explanation of how the rule is followed, or an explanation of the reason and resulting risk to customers for not following the rule.
  2. Verification that the implementation is appropriate for the rule.
  3. Validation that the implementation is in place and working as intended.
  4. Independent verification.
  5. Independent validation.

Items four and five are an assessor's work, carried in a record the provider owns every field of. IVV-IAS-VIM and IVV-IAS-VEF both attach the same note to them: "This requires reviewing the actual measures themselves at a technical level, such as reviewing underlying code as appropriate; don't simply review documentation or screenshots." An assessor asking to see the mechanism that produced a rating, rather than the rating, is operating inside the rules.

The reporting rule is where this gets concrete, and where the thing Coalfire sells turns out to have no home. VER-RPT-VDT is a MUST and it lists eleven items a vulnerability report has to carry. Three of them are about the rating:

  • "Historically and currently estimated Potential Agency Impact N-rating of exploitation"
  • "Time and Potential Agency Impact N-rating of each completed and evaluated reduction in Potential Agency Impact N-rating"
  • "Estimated time and target Potential Agency Impact N-rating of next reduction in Potential Agency Impact N-rating"

So the report must carry the rating, every prior value of it, the timestamp of each change, and a forecast of the next one. There is no required field for why any of those values was chosen. The nearest thing is the catch-all item — "any supplementary information the provider responsibly determines will help federal agencies assess or mitigate the risk" — which is discretionary by construction. The rating history is a required, machine-readable, dated series; the reasoning behind it is optional prose. That asymmetry is the practical reason a documented method matters: the numbers are on the record whether or not the basis for them is, and under the five default artifacts the basis is what gets independently verified.

VER-EVA-ELX carries one more note that belongs in any assessment conversation about this, because it describes the consequence of getting the evaluation wrong rather than the method for getting it right:

The proof, ultimately, is in the pudding - providers who regularly evaluate vulnerabilities as not likely exploitable without careful consideration are more likely to suffer from an adverse impact where the root cause was an exploited vulnerability that was improperly evaluated. If done recklessly or deliberately, such actions will have a negative impact on a provider's FedRAMP Certification.

Who it applies to, and by when

Coalfire names two of the four dates on this calendar, and both are right. The Vulnerability Evaluation and Reporting and Vulnerability Detection and Response rulesets share one calendar, and their published status line reads "Required (Mandated by CISA BOD 26-04)":

  • Optional adoption allowed: 2026-07-04
  • Obtaining initial certification: 2026-12-07
  • Maintaining ongoing certification: 2026-12-07
  • Grace period ends: 2027-03-07

The grace date is the one the post does not mention, and it is a flat date rather than the "first assessment after" form used elsewhere in CR26.

Applicability: every subset of both rulesets is Class B, Class C, and Class D, on both the 20x and the Rev5 track. Class A providers are outside the Vulnerability Evaluation and Reporting ruleset entirely, even though VDR-TFR-PVR publishes a Class A remediation table.

Incident Evaluation and Communication, where the PAIN-5 default lives, runs on a different and earlier calendar, and it splits by track:

  • 20x — obtaining initial certification 2026-07-04, maintaining ongoing certification 2027-01-01, grace running to the next assessment
  • Rev5 — obtaining and maintaining both 2027-01-01, grace period ending 2027-06-01

For a 20x Class B or Class C provider, that means the incident-side default rating has already been in force for an initial certification since July, while the vulnerability-side rating obligation starts in December. The rulesets that cross-reference each other do not start together.

Where this lands for what we build

The FedRAMP Management Engine is our POA&M-lifecycle and evidence-origin record, which is the shape VER-RPT-VDT asks for: a rating, each prior value of it, and a timestamp on every change, carried forward rather than reconstructed at reporting time. The reasoning behind each rating is the part the reporting rule has no field for, and therefore the part a provider has to decide to keep on its own.

The question worth carrying

Pick a finding your scanners flagged this week. Can you say which of the four customer-effect definitions it maps to, name the users and the hours that put it there, and show the same method applied to the finding before it?

That is the whole of what VER-EVA-EPA asks for, and the only part of it FedRAMP wrote down is the destination.

Reference