This is the second cluster of the 124 CSP requirements behind FedRAMP 20X — the largest single cluster, and where most of the engineering investment in a 20X program actually lands:
- Persistent Validation and Assessment (PVA) — 8 CSP requirements
- Vulnerability Detection and Response (VDR) — 33 CSP requirements
41 CSP requirements total. PVA defines the cadence at which you continuously prove your KSIs are working. VDR defines what happens when one of those proofs fails.
For the full breakdown of the 124, start with the pillar post: FedRAMP 20X: Why 60 KSIs Actually Mean 124 Requirements for Cloud Service Providers.
Persistent Validation and Assessment (PVA): 8 CSP requirements
PVA says: it's not enough for your KSIs to be true. They have to be demonstrably true, persistently, on a defined cadence, with documented responsible parties and cycles.
The cadence is the part most teams aren't expecting:
Every 3 to 7 days for machine-based resources
A KSI like "phishing-resistant MFA is enforced" can be validated automatically by exporting your IdP policy and checking the allowed factors against an expected baseline. Doing that every 3–7 days is a manageable engineering investment. Doing it manually, with screenshots, is operationally untenable.
Every 3 months for non-machine-based resources
Things like training effectiveness reviews, supply-chain risk reviews, or after-action reports for past incidents fall under the 3-month cadence. These aren't automated, but they still need to happen on a scheduled, documented basis with named owners.
The "persistently" language matters. FedRAMP defines persistent activity as something that occurs in a steady, repeated way over a long period, with intentional, documented cycles, even when there are interruptions. PVA isn't "set up a daily cron job and forget it" — it's a documented, owned process where the cadence, responsible parties, actions taken, and status are all knowable at any moment.
Pass/fail criteria must be explicit and traceable. Every KSI implementation summary must include clear pass/fail criteria with traceability to the underlying validation. "We have phishing-resistant MFA" is not a validation. "Our IdP policy allows only WebAuthn/FIDO2 factors and disallows SMS/TOTP/email/push, validated by automated policy export every 24 hours, last validated [timestamp]" is.
Practical guidance: Build a validation engine, not 60 separate checks. The teams that succeed treat PVA as a single internal product — a validation framework that ingests evidence from across the stack, evaluates it against defined criteria, emits structured results, and pipes failures into the vulnerability backlog.
Vulnerability Detection and Response (VDR): 33 CSP requirements
VDR is the largest single requirement set in the entire 20X framework — 33 of the 124 CSP requirements come from this one document. It defines how your security organization detects, evaluates, mitigates, and reports on vulnerabilities of any kind.
There's a specific bridging requirement, PVA-CSX-FAV, that explicitly wires PVA and VDR together: a failed persistent validation is treated as a vulnerability and fed into the VDR process. So the validation engine isn't just a dashboard with green and red lights. Every red light becomes a tracked vulnerability with a defined lifecycle.
VDR has four operational pieces:
Detection
Vulnerabilities can come from multiple sources: failed PVA checks, scanner findings, third-party disclosures, internal discovery, customer reports. VDR expects all of them to feed into the same intake.
Evaluation on the N1–N5 potential adverse impact scale
Every vulnerability gets evaluated for its potential adverse impact, on a defined 5-point scale. This is the prioritization signal that determines remediation timing.
Mitigation within defined timeframes
Each impact level carries a remediation clock. Higher-impact vulnerabilities have to be mitigated faster. This is what keeps known gaps from drifting indefinitely.
Monthly reporting
Vulnerability status — including newly discovered, in-progress, and accepted-risk — is reported on a monthly cadence to FedRAMP and agency customers.
Practical guidance: Treat the vulnerability backlog as production. The VDR pipeline should look like the rest of your engineering bug tracker, not a separate compliance system. The teams that hit remediation clocks consistently are the ones whose security findings flow through the same backlog, sprint, and on-call structure as feature work.
How PVA and VDR work together
The combined effect is that your security posture stops being a static thing you describe and becomes a process with continuous outputs: a stream of validation results, a backlog of tracked vulnerabilities, and a monthly summary that shows the trend over time.
If you're scoping a 20X program for the first time, this is where the cost estimate usually doubles. The KSIs themselves often map to capabilities your service already has. The persistent validation infrastructure to prove every one of them automatically, every 3–7 days, forever — with explicit pass/fail criteria and a vulnerability tracking pipeline behind it — is rarely something a team has built end-to-end before.
Two final patterns worth flagging: make the evidence machine-readable from day one (FedRAMP 20X expects machine-readable submission formats — if your validation engine emits structured results natively, your authorization package writes itself), and time the cadence to your real operational reality. Picking a cadence you can't actually meet is worse than picking one you can.
What's next
Once your validation engine is producing evidence and your vulnerability process is keeping up, the next cluster governs how that proof gets published and reviewed by federal customers: Authorization Data Sharing (ADS) and Collaborative Continuous Monitoring (CCM) — 33 CSP requirements that handle the trust center, the Ongoing Authorization Report, and the Quarterly Review cadence.