FedRAMP 20x KSI Validation: How Often and in What Format

Under FedRAMP 20x, Key Security Indicator (KSI) evidence must be validated on a fixed cadence: machine-based information resources at least once every 7 days at Low and at least once every 3 days at Moderate, and non-machine-based validations at least once every 3 months. Every validation result must be both machine-readable and human-readable and regenerable on demand. Static screenshots and configuration dumps are not acceptable as the system of record.

Key takeaways

• Machine-based KSI validation runs at least every 7 days at Low and at least every 3 days at Moderate (FedRAMP requirement PVA-CSX-PMV).
• Non-machine-based validation must complete at least once every 3 months (PVA-CSX-NMV).
• 20x High is expected to be more frequent than Moderate, but FedRAMP has not yet finalized the cadence.
• Evidence must be machine-readable and human-readable and regenerable on demand; screenshots and static dumps cannot be the system of record (PVA-TPX-STE).
• A failed validation, or a broken validation pipeline, is treated as a vulnerability under Vulnerability Detection and Response (PVA-CSX-FAV).

How often must KSI evidence be validated?

FedRAMP 20x sets validation frequency by two factors: whether the information resource is machine-based or non-machine-based, and the impact level of the cloud service offering.

For machine-based information resources, providers MUST complete the validation processes for their Key Security Indicators at least once every 7 days at Low and at least once every 3 days at Moderate. This requirement is identified as PVA-CSX-PMV in the FedRAMP 20x Persistent Validation and Assessment process.

For non-machine-based information resources, providers MUST complete the validation processes at least once every 3 months. This is requirement PVA-CSX-NMV.

These are floors, not targets. The word "least" is doing real work: a provider whose engineering workflow already validates configuration on every deployment is free to validate far more often, and most mature 20x programs will. The cadence numbers exist so that no in-scope resource ever goes longer than the stated window without a fresh, current validation result.

Resource type	Low	Moderate	High
Machine-based information resources	At least every 7 days	At least every 3 days	More frequent than Moderate; cadence not yet finalized
Non-machine-based information resources	At least every 3 months	At least every 3 months	At least every 3 months (High specifics not yet finalized)

Source: FedRAMP 20x Persistent Validation and Assessment (PVA-CSX-PMV, PVA-CSX-NMV)

The "machine vs non-machine" split is the part teams most often get wrong, so it is worth defining precisely.

What's the difference between machine-based and non-machine validations?

A machine-based information resource is one whose state can be checked programmatically. Cloud resources, identity provider configuration, network rules, encryption settings, and pipeline controls all fall here, because a script or API call can read the current state and compare it to the expected state. These resources carry the tight cadence, every 7 days at Low and every 3 days at Moderate, precisely because automation makes frequent checking cheap.

A non-machine-based information resource is one validated through a human process rather than an automated query. Examples include a tabletop exercise, a policy review, a signed acknowledgment of security training, or a documented approval that has no machine-queryable equivalent. These run on the quarterly cadence: at least once every 3 months.

The distinction is not about importance. A non-machine validation is not "lower priority" evidence. It still needs a defined process, an owner, a recency requirement, and a result that ties back to a specific KSI. The cadence is longer only because the underlying activity is human and cannot be polled on a three-day loop.

One practical consequence: most real KSIs are validated by a mix of both methods. FedRAMP's KSI implementation summary requirement (KSI-CSX-SUM) explicitly asks providers to document the machine-based processes and their persistent cycle, and the non-machine-based processes and their persistent cycle, separately, for each KSI. If a KSI has both, both cadences apply to their respective parts.

What format does FedRAMP require for KSI evidence?

FedRAMP 20x requires validation evidence that is both machine-readable and human-readable, and that can be regenerated on demand from the live system. The point is that evidence reflects the current state of the offering, not a frozen snapshot from an earlier moment.

This rules out a long-standing compliance habit. Assessors MUST NOT rely on screenshots, configuration dumps, or other static output as evidence, except when they are evaluating the accuracy and reliability of the process that generates such artifacts (requirement PVA-TPX-STE). In other words, a screenshot can illustrate how a control looks, but it cannot be the authoritative record that the control is in place right now.

A strong KSI validation result is a structured object, not a picture. It should be queryable by a machine and readable by a human reviewer, and it should carry enough context to stand on its own:

• The KSI or assertion being checked
• The information resource or process in scope
• The source system the evidence came from
• The expected condition (the pass/fail criteria)
• The actual observed condition
• The pass or fail result
• The timestamp of the validation
• A reference back to the underlying evidence
• The owner or remediation path if the check fails

"Encryption is enabled" is not a validation. A validation says which storage resources were checked, what encryption setting was required, what the cloud API actually returned, when the check ran, and which resources, if any, failed. That object is machine-readable enough to feed a dashboard and human-readable enough for an assessor to follow.

Because the evidence must be regenerable on demand, the system of record is the pipeline, not a folder of exports. If an assessor asks for current state, the answer is to run the validation again and produce a fresh, timestamped result, not to retrieve a file someone saved last month. This is the operational heart of persistent validation, and it is why most 20x teams move quickly to automate KSI evidence collection rather than assemble packages by hand.

What happens when a validation fails?

A failed validation is a vulnerability. FedRAMP is explicit: providers MUST treat issues detected during persistent validation, and failures of the persistent validation process itself, as vulnerabilities, then handle them under the FedRAMP Vulnerability Detection and Response process (requirement PVA-CSX-FAV).

Two distinct failure modes both count:

1. A failed check — the validation ran and returned a non-compliant result. For example, a storage resource that should be encrypted is not. This is a finding about the offering's security state.
2. A broken pipeline — the validation could not run, ran incompletely, or stopped producing current results. A scanner that silently fails, a credential that expired, or a job that skipped half the in-scope resources all fall here. The gap in coverage is itself the vulnerability.

This second case is what makes 20x validation different from a scheduled scan. Under traditional continuous monitoring, a scan that did not run was an operational nuisance. Under 20x, a validation that did not run leaves an in-scope resource without current evidence, and that absence is treated as a vulnerability to be detected, tracked, and remediated. It is not enough to be compliant when checked; the checking itself has to keep working.

The practical implication is that your validation cadence and your pipeline health are part of the same obligation. Missing a 3-day Moderate window is not a paperwork lapse. It produces stale evidence, and stale evidence on an in-scope resource is a finding.

How assessors evaluate validation cadence and format

Assessors do not just confirm that a validation result says "pass." They verify the underlying processes, both machine-based and non-machine-based, that produce those results. That includes the effectiveness, completeness, and integrity of the automated checks, the same for the human processes, and whether the processes actually cover every consolidated information resource in scope (requirement PVA-TPX-UNP).

To survive that review, a provider should be able to show, for each KSI:

• The pass/fail criteria and how they were defined
• Which information resources are covered and how missing ones are detected
• The machine cadence and the non-machine cadence, documented per KSI
• How evidence is protected from tampering and how stale evidence is flagged
• How failed checks and failed pipelines are routed and remediated

If the process behind a result cannot be explained, the result is hard to trust, regardless of how clean the output looks. For the full set of themes these checks map to, see our FedRAMP 20x KSI guide, which covers all eleven KSI themes from Authorization by FedRAMP through Supply Chain Risk.

Frequently asked questions

How often must FedRAMP 20x KSI evidence be validated?

Machine-based information resources must be validated at least once every 7 days at Low and at least once every 3 days at Moderate. Non-machine-based information resources must be validated at least once every 3 months. These are minimums under FedRAMP requirements PVA-CSX-PMV and PVA-CSX-NMV; more frequent validation is allowed and common.

What is the validation cadence for FedRAMP 20x High?

FedRAMP states that High is expected to require more frequent machine-based validation than Moderate, but the specific cadence has not yet been finalized in current 20x guidance. Providers planning for High should expect a window shorter than the 3-day Moderate requirement.

Are screenshots acceptable as KSI evidence?

No, not as the system of record. Assessors must not rely on screenshots, configuration dumps, or other static output as evidence, except when they are evaluating the reliability of the process that generates those artifacts (PVA-TPX-STE). Evidence must be machine-readable and human-readable and regenerable on demand from the live system.

What does "machine-readable and human-readable" mean in practice?

It means each validation result is a structured object a machine can query (for dashboards, alerting, and authorization data) and a person can read and follow (for assessor review). A single screenshot is human-readable but not machine-readable; a raw JSON blob with no context is machine-readable but hard for a reviewer to interpret. 20x evidence has to be both.

What is the difference between a machine-based and a non-machine-based information resource?

A machine-based resource has a state that can be checked programmatically, such as cloud configuration, identity settings, or network rules, and carries the 7-day or 3-day cadence. A non-machine-based resource is validated through a human process, such as a tabletop exercise or a policy review, and carries the quarterly cadence. Many KSIs involve both, and each part follows its own cadence.

What happens if a KSI validation fails or a pipeline breaks?

Both are treated as vulnerabilities. A failed check and a failed or broken validation pipeline must be handled under the FedRAMP Vulnerability Detection and Response process (PVA-CSX-FAV). A pipeline that stops producing current results leaves in-scope resources without fresh evidence, and that gap is itself the finding.

Does the cadence reset if I validate more often than required?

The cadence is a maximum interval, not a fixed schedule. Validating more frequently than every 7 days at Low or every 3 days at Moderate is fully compliant and encouraged. The requirement is only that no in-scope resource ever exceeds the stated window without a current validation result.

Sources

• FedRAMP 20x Persistent Validation and Assessment (PVA-CSX-PMV, PVA-CSX-NMV, PVA-CSX-FAV, PVA-TPX-STE, PVA-TPX-UNP)
• FedRAMP 20x Key Security Indicators (KSI-CSX-SUM and the eleven KSI themes)
• FedRAMP 20x Vulnerability Detection and Response

---

Last updated: June 2026. Written by the Boundera team.