Validating FedRAMP 20x Key Security Indicators: What Verification and Validation Actually Require

Most teams starting FedRAMP 20x ask the same question first: “Which controls map to which KSI?” It feels like the natural place to start, because for a decade FedRAMP meant a control baseline, a System Security Plan and a spreadsheet of evidence. But it’s the wrong first question. FedRAMP says so directly on its KSI overview page: “Do not attempt to approach Key Security Indicators from a traditional compliance standpoint!”

Under the Consolidated Rules for 2026, a KSI isn’t a control to describe. It’s a security outcome you have to show is happening, keep showing, and have an independent assessor confirm. FedRAMP puts it this way: “Security controls define required protections, but Key Security Indicators provide measurable validation that those protections are functioning properly.”

This post covers what the rules actually ask for when it comes to validating KSIs, and where teams tend to go wrong.

What a KSI is under the 2026 rules

The 2026 rule set organizes 46 Key Security Indicators into 10 themes, from Cloud Native Architecture and Service Configuration down to Cybersecurity Education.

All 46 KSIs from FedRAMP’s machine-readable Consolidated Rules. Amber indicators are optional at Class B and required at Class C.

Each indicator is written as a short outcome statement. For example, KSI-IAM-AAM (Automating Account Management) reads: “The lifecycle and privileges of all accounts, roles, and groups are securely managed using automation.” KSI-CMT-RMV asks that changes to machine-based resources be “executed through the redeployment of version controlled resources rather than direct modification wherever reasonable.”

Note what these statements leave out. None of them says “document a policy” or “maintain a procedure.” They describe how the system behaves. Each KSI still references NIST 800-53 controls in the machine-readable rules, but those references are for traceability. The control mapping doesn’t prove anything on its own.

{
  "KSI": {
    "IAM": {
      "name": "Identity and Access Management",
      "indicators": {
        "KSI-IAM-AAM": {
          "name": "Automating Account Management",
          "statement": "The lifecycle and privileges of all accounts, roles, and groups are securely managed using automation.",
          "controls": ["ac-2.2", "ac-2.3", "ac-2.13", "ac-6.7", "ia-4.4", "ia-12", "ia-12.2", "ia-12.3", "ia-12.5"]
        }
      }
    }
  }
}

KSI-IAM-AAM as it appears in FedRAMP’s rules file. The statement is the requirement; the controls are there for traceability.

The word that shows up most across the indicators is persistently. FedRAMP gives it a specific definition: activities “repeated over a long period of time in spite of obstacles or difficulties,” where cycles may vary or pause, but “the status of persistent activities will always be known.” That last clause is the one that matters. A review you ran once for the assessment doesn’t count as persistent.

Verification and validation are two different things

The 2026 rules separate these two terms clearly, and KSI validation rests on the difference:

• Verification is “confirmation through objective evidence that specified FedRAMP Practices have been fulfilled.” In plain terms: did you build what you said you built?
• Validation is “confirmation through objective evidence that implemented security capabilities and related certification data are suitable for their intended FedRAMP Certification use and support the expected security outcomes.” In plain terms: does it actually work, and can the data about it be trusted?

The Independent Verification and Validation (IVV) rules put obligations on both sides. Providers MUST supply assessors with evidence of implementation and evidence of effectiveness. Assessors MUST verify that the implemented measures match what was documented, validate that they have the intended outcome, and SHOULD “perform independent research to test such information.”

What the Security Decision Record requires for each KSI

The Security Decision Record (SDR) replaces the traditional SSP. FedRAMP defines it as “a persistently maintained, verified, and validated record of the security decisions made by a provider over the lifecycle of a cloud service offering.” It MUST be supplied in both human-readable and JSON formats against a published FedRAMP schema.

For every applicable KSI, rule SDR-CSX-KSI requires five short summaries: the measures, their cycle, verification of the measures, verification of the automation behind them, and validation that it all works as intended. The assessor then verifies and validates the same measures, and both sets of findings end up in the record agencies read.

How a KSI gets proven under the 2026 rules, from provider measures to the Security Decision Record.

The fourth item, verifying the automation, is the one most teams underestimate. FedRAMP isn’t only asking whether your control works. It’s asking whether the automation that reports on the control can be trusted. A dashboard showing 100% MFA coverage is only as good as the query behind it. If that query misses service accounts or a second identity provider, the measure is wrong, and validation has to catch that.

The assessor’s findings don’t disappear into a separate report either. Providers MUST include them in the Certification Package “without inappropriate modification” (IVV-CSO-ICP).

Metrics change by class

For 20x Classes B, C and D, providers MUST include all KSIs in a FedRAMP independent assessment at least once per year. The historical data you keep also scales with class, and five indicators move from optional to required between Class B and Class C.

Class C requires a full year of daily metric data in the SDR. That history can’t be created after the fact.

If you’re aiming for Class C, a year of daily data means your measurement pipeline has to be running well before the assessment window opens.

From rules to certification: the Class A lifecycle

The rules read as a flat list, but the journey through them has a sequence, and the sequence matters. Class A is the entry point: self-service, with the independent assessment a MAY rather than a MUST (IVV-CSO-FIA), which makes it the cleanest view of the lifecycle every class shares. Scope gates everything at the front, the Security Decision Record is the bulk of the middle, and continuous monitoring never ends.

The Class A lifecycle. Classes B through D follow the same shape with the assessment made mandatory and heavier metric history.

Scope comes first

Validation only means something if the boundary is right. The Minimum Assessment Scope rules require providers to identify every information resource “likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability” of that data (MAS-CSO-IIR), to document information flows and security categories for all of those resources, and to address how third-party resources could affect federal data.

This matters because an inventory-driven measure such as KSI-PIY-GIV (Generating Inventories) is only valid if its authoritative sources cover the whole assessed scope. If a measure reports “all resources compliant” but doesn’t include a region, account or SaaS dependency that’s inside the boundary, the measure is wrong.

Rev5 is moving the same way

Providers staying on Rev5 aren’t exempt from this shift. FedRAMP’s Rev5 control guidance asks, for each control, what risk it addresses, where it runs in the offering, what safeguards implement it, who owns it, what evidence shows it’s operating, and how it will keep working as things change. The guidance says a control “should not only be described once in a document.” Rev5 providers also use the SDR, with control summaries in place of KSI summaries.

Where teams go wrong

The same patterns keep showing up:

• Writing prose where a measure belongs. A paragraph explaining that access reviews happen quarterly isn’t a measure. A job that exports entitlements, compares them to role definitions, records any exceptions and stores the result is.
• Leaving the automation unchecked. Teams show the output of a check but can’t explain how they know the check itself is accurate.
• Starting metrics too late. Class B and C metric history can’t be created retroactively.
• Treating “persistent” as “periodic.” The rule allows irregular cycles, but the status always has to be known and documented.
• Keeping GRC and engineering apart. FedRAMP says plainly that “GRC and Assurance Engineering is critical.” The people who can explain a KSI measure are usually the people who built the pipeline.

Use the machine-readable rules

FedRAMP publishes the full Consolidated Rules as structured JSON with a validation schema in the public FedRAMP/rules repository, including every KSI, its class variants and its related controls. Build your KSI inventory, SDR scaffolding and validation tests from that file instead of copying from web pages. That way, when FedRAMP updates the rules, you can see exactly what changed.

Build measures that hold up

Scoping a 20x certification or moving an existing authorization to the 2026 rules? Optimal builds FedRAMP 20x and Rev5 authorization packages around evidence that runs on its own, from KSI measures and validation pipelines to a Security Decision Record your assessor can verify. Schedule a 30-minute conversation.

Sources

• FedRAMP Consolidated Rules (machine-readable JSON)
• FedRAMP Consolidated Rules for 2026
• Key Security Indicators
• 20x Boundary
• 20x Assurance
• 20x Package
• Rev5 Controls