A deterministic method for deriving Potential Agency Impact from asset context, NIST security categorization, and vulnerability impact.
By Matthew Venne, Chief Technology Officer, stackArmor
Under FedRAMP 20x and the Consolidated Rules for 2026 (CR26), providers are asked to evaluate a vulnerability by its Potential Agency Impact rather than its scanner severity. The FedRAMP Vulnerability Evaluation and Reporting rules define PAIN ratings and the factors providers should consider, but they do not prescribe a single method for deriving the rating.
That flexibility allows providers to account for different architectures and operating environments. It also makes a consistent, reviewable calculation important when an analyst, assessor, or agency needs to understand how a rating was reached.
We developed a repeatable approach to that derivation. Two of its three inputs already sit in a typical authorization package. The third – what the vulnerable asset is actually worth – is the one FedRAMP has newly put in scope and where this method does its work. The calculation remains fixed so an analyst, assessor, or agency can review the same inputs and reproduce the result.
The Three Inputs
The rating is derived from three inputs:
What data does the system hold? The NIST SP 800-60 information types the system is intended to process.
What is the vulnerable asset actually worth? The asset’s security requirements, capped by a ceiling derived from those information types.
How much damage can the flaw do to the asset? The CVSS Environmental Impact Subscore.
This approach uses established frameworks rather than introducing a new taxonomy. Assessors retain CVSS, agencies retain NIST SP 800-60, and the method supplies a repeatable step between them.
One Input Is Established. One Is New.
The first and third inputs are well established. The second is the newer consideration.
The NIST SP 800-60 determination is not new work. Every cloud service provider authorization package already contains it; it is what sets the system’s impact level in the first place. FedRAMP is moving away from that wording in favor of the Class A-D rating, but FIPS 199 categorization remains a language every agency understands. It is one input a customer, agency reviewer, and assessor can all read without translation. We have built agent skills to assist with the information-type determination.
Asset security requirements may not be in every authorization package yet. This is a genuinely new FedRAMP expectation, but the reasoning behind it is familiar. Many customers have been making the same argument informally for years: in POA&M deviation requests that explain why a finding is less serious than its base score implies, or in inventories already labeled by value, criticality, or tier. The method does not introduce the concept. It gives an argument customers already make a fixed place in the derivation and produces a result an assessor can review.
We have developed and tested agent skills that suggest asset labels from configuration and telemetry across an inventory. Human review is still required. The label is an input to a risk decision, not a scan result.
Why Asset Classification Matters
We considered whether asset classification could be a recommended step rather than a required one. In this approach, it remains essential.
Classification is the triage signal. Once the queue is longer than the team can work, it helps answer the practical question of what gets fixed first. High-value assets should receive priority, and “high value” should have a documented meaning before a finding arrives rather than being argued after the fact. Including asset value helps a vulnerability management program move beyond severity-based sorting toward risk-based prioritization.
Why Scanner Severity Alone Is Not Enough
Scanner severity describes a vulnerability in the abstract. It does not know whether the affected asset holds mission data or marketing copy, whether it sits at the edge or three hops deep, or whether the organization would notice its loss.
The result is a remediation queue sorted by a number that may not represent the context assumed by the remediation clock. Teams can spend time on findings that present limited real-world exposure, or they can carve out exceptions one at a time through a process that is slow, inconsistent, and difficult to defend during an assessment.
The new deadlines are what make that noise expensive. FedRAMP’s remediation and mitigation windows represent a significant change in expectation, and a queue sorted only by scanner severity will be difficult to work within them. The design goal was therefore signal-to-noise: an ordering a team can genuinely triage against, with the shortest clock reserved for findings that present the greatest potential agency impact.
The Intended-Use Ceiling
Under this approach, an asset cannot be rated more seriously than the data it is authorized or intended to process supports.
The effective requirement is calculated as:
Effective security requirement = the lower of the asset requirement and the intended-use ceiling
The ceiling is a guardrail, not a law of nature. It is evaluated per deployment rather than set once. The same stack deployed as code for two agencies may not carry the same data, so when the target changes, the ceiling moves with it. In some situations, the ceiling stops being measurable and should be lifted. The supporting white papers examine where that line sits. For many customers – those serving a limited number of agencies with little shared infrastructure between tenants – the ceiling remains measurable and can work in their favor.
One consequence is intentional: the most severe ratings cannot be reached unless the information impact or breadth of agency consequences supports a debilitating outcome. “Debilitating” means unable to function. This keeps the shortest remediation clock attached to the findings that have earned it.
Figure 1: The effective requirement is the per-objective minimum of the asset archetype and the intended-use ceiling. Here, a high-severity CVE lands on a system-of-record database whose availability ceiling is Low, so the finding resolves to N3, a disruptive effect, rather than escalating to Debilitating.
Agency Risk and Provider Risk Are Not the Same Risk
The government’s risk profile is not necessarily the same as the provider’s.
An agency may rate an information type Low for confidentiality because disclosing it would not significantly affect that agency’s mission. The same disclosure could still cause serious reputational, contractual, or commercial consequences for the provider. Both assessments can be correct because they answer different questions.
This is why the method keeps asset security requirements and agency information-type security requirements as separate inputs rather than collapsing them into one number. The agency’s data types set the ceiling for Potential Agency Impact; that is the rating FedRAMP is requesting. The asset’s own security requirements can still reflect the provider’s corporate security objectives without distorting the agency-facing rating or being erased by it.
Merging the two can lose information in both directions. It may inflate agency impact with concerns the agency does not share while discounting assets the provider cannot afford to lose.
Internet Reachability
Reachability is a significant source of noise in severity scoring and requires evaluation in the context of the deployed architecture.
The current operating rule – a network-attackable vulnerability on an internet-accessible system – is a starting signal, not a verdict, and it should be documented as such.
A narrower test asks whether the affected protocol matches a protocol that is actually exposed and in use. Today’s scanners do not consistently report that relationship in a machine-readable format, so automated conclusions should be validated against the architecture and available evidence.
We are working to close that gap with AI-driven enrichment of CVE data to infer the affected protocol at scale, which is currently in testing. Our view is that this kind of data may be worth more as shared infrastructure than as any one vendor’s differentiator. How it gets built, and by whom, is a conversation worth having with hyperscalers, security vendors, and the government.
The Payload Path Explorer shows what the narrower test can look like: place a CVE within a small cloud architecture, apply real controls such as protocol termination, identity-aware proxies, and parameterized queries, and see where the payload’s path continues or is interrupted.
How We Calibrated the Method
The method was calibrated against published standards, with the reasoning behind its adjustments documented for review.
-
Derived the top band exhaustively. We worked through every combination the inputs can take and determined which genuinely amount to an inability to function. That required judgment, and we documented the reasoning behind each band boundary so a finding’s placement can be checked against a stated rationale instead of re-argued case by case.
-
Excluded exploitability from the impact term. FedRAMP already handles exploitability separately. Folding it in would count the same signal twice.
-
Excluded Scope. It is an incomplete signal that requires analyst review, and successive CVSS versions treat it differently. Leaving it out keeps the method version-agnostic.
-
Anchored likely-exploited status to published data. The method uses an EPSS cutoff calibrated to the share of CVEs observed as exploited in the wild, with the CISA Known Exploited Vulnerabilities Catalog providing an independent path to the same designation.
One rule governs future changes: new considerations are handled as governed rules about how the inputs are resolved rather than as changes to the equation. The calculation stays fixed while the inputs improve. That makes a rating from one reporting period comparable to a rating from another.
What This Buys You
A repeatable, evidence-backed decision for every finding.
The rating can be traced to inputs an assessor can inspect: the system’s NIST SP 800-60 information types, the asset’s security requirements, and whether it directly serves multiple agencies, and the CVSS Environmental Impact Subscore.
That gives the remediation queue a defensible order. Teams can explain why a finding received its PAIN rating, what evidence supports it, and what would cause the rating to change. If the deployment, data, or agency use changes, the rating can be recalculated rather than reargued from scratch.
This does not replace CVSS or FIPS 199. It connects them to the asset being evaluated.What Comes Next
We are building a vulnerability management solution around this methodology rather than bolting the methodology onto a scanner queue after the fact. Every customer benefits from the same derivation, the same evidence trail, and the same fixed calculation.
The first pilots are with Kubernetes customers for a practical reason: our current tooling is easiest to exercise against a cluster, where workloads, images, and exposure are discoverable from the environment itself. The target is not a Kubernetes product. We are building toward the full range of customer deployment patterns, and the derivation does not change from one pattern to the next; only where the inputs are read from changes.
The two early screens below are mockups under active development, not a shipped product.
Figure 2: Early triage queue mockup. Findings are grouped by resource and ordered by derived rating, with reachability and known-exploited counts carried on the row. The ordering is the triage signal; the queue is not sorted by scanner severity. Identifiers were scrubbed with AI tooling, and the horizontal whitespace was compressed for legibility. The image is otherwise a high-fidelity representation of the current interface.
Figure 3: Early finding-detail mockup showing the derivation rather than only the result: exposure and exploitability inputs, the per-objective impact alignment behind the rating, and the reason for a multi-agency adjustment from N4 to N5.
Read the Papers
The method and its supporting work are published for public review, with an open GitHub discussion for challenges and corrections.
-
The Method: The deterministic CVSS Environmental derivation, closed-form calculation, and remediation matrices. A companion blog is also available.
-
Before the PAIN Equation: How asset security requirements and the intended-use ceiling are derived.
-
High-Centered PAIN Calibration: The normalization and threshold work behind the scale.
-
Compliance and Benchmark Findings: Applying the method to configuration and benchmark findings.
-
Internet Reachability at Scale: The protocol-match problem and enrichment approach. A companion blog is also available.
For additional context, see Putting the Risk Back in FedRAMP and CVSS in Transition: CISA BOD 26-04, FedRAMP VDR, and the Rise of Risk-Based Vulnerability Management.
