2026/reference/rev5/c/certification-data-sharing/

[gcano-sp]

We are a FedRAMP Rev. 5 provider using USDA Connect and are looking for clarification on the programmatic access requirements for VDR/VER and other FedRAMP Certification Data.

CDS-TRC-PAC states that a FedRAMP-compatible trust center MUST provide documented programmatic access to all FedRAMP Certification Data, including human-readable materials. However, the Certification Data Sharing rules also state that the “Using a Trust Center” rules do not apply to providers using USDA Connect. For a Rev. 5 provider continuing to use USDA Connect, are we required to separately provide an API or other non-interactive programmatic interface for our VDR/VER JSON reports and related Certification Data, or does use of USDA Connect satisfy the applicable sharing requirement?

[pete-gov]

CDS-TRC-PAC states that a FedRAMP-compatible trust center MUST provide documented programmatic access to all FedRAMP Certification Data, including human-readable materials. However, the Certification Data Sharing rules also state that the “Using a Trust Center” rules do not apply to providers using USDA Connect. For a Rev. 5 provider continuing to use USDA Connect, are we required to separately provide an API or other non-interactive programmatic interface for our VDR/VER JSON reports and related Certification Data, or does use of USDA Connect satisfy the applicable sharing requirement?

USDA Connect is not a FedRAMP-compatible trust center. You will not be able to meet the CDS-CS-UTC (Using Trust Centers) rule without migrating away from USDA Connect to a FedRAMP-compatible trust center. The expectation is that every cloud service provider moves to a FedRAMP-compatible trust center within the next year to provide a better data sharing experience for agencies.

[gcano-sp]

Thank you, that helps clarify the longer-term expectation. One follow-up: do we need to migrate from USDA Connect to a FedRAMP-compatible trust center by December 7 in order to comply with VDR/VER?

Or can a Rev. 5 provider meet the December 7 VDR/VER requirements by generating the required human- and machine-readable VDR/VER reports and continuing to use USDA Connect temporarily, with migration to a FedRAMP-compatible trust center occurring separately under the CDS timeline?

[pete-gov]

Or can a Rev. 5 provider meet the December 7 VDR/VER requirements by generating the required human- and machine-readable VDR/VER reports and continuing to use USDA Connect temporarily, with migration to a FedRAMP-compatible trust center occurring separately under the CDS timeline?

Yes! You can meet all the VDR/VER requirements while still using USDA Connect except for VER-TFR-MRH (Historical Activity) - you might be drag and dropping a lot of JSON files but you can probably design for that and use a clean JSON structure so you're just dropping one JSON file with every persistent vulnerability report and then maybe a CSV or PDF summary report if you want to be nice. It should be a lot less of a hassle than uploading scans if you had to do that, though. The default for most is a monthly report, same as it is now.

For VER-TFR-MRH you could just drop files in manually every month too and document the complexity/risk/manual effort of uploading stuff to USDA Connect while transitioning to a FedRAMP-compatible trust center as the technical reason for not meeting this rule in full. I think most agency customers would find this reasonable through 2027.

[gcano-sp]

Those are the specific rules we were concerned about. VER-TFR-MRH says "automated retrieval" and references an API, which I did not believe USDA Connect supports. Since we are not implementing those rules in full, will we need to provide a corrective action plan and will that be indicated in our Marketplace listing?

[pete-gov]

Because it is a "SHOULD" rule you can just explain the technical reasons, the resulting risk, and any mitigations to offset it. If you mitigate by simply uploading a historical file monthly there would be no concerns at all.

There's no need for corrective action for not fully implementing a SHOULD rule with a good reason. At the moment that is not indicated on the Marketplace, but yes at some point in the future there might be a scorecard saying "this cloud service provider does not have an API available to automatically retrieve vulnerability history" but that is unlikely to matter to many agencies until they have deployed and begun operating tools to automatically retrieve and ingest this info - which I don't expect most will do until 2028. So not worrying about this until you adopt a FedRAMP-compatible trust center would absolutely make sense and be unlikely to cause too many problems (and certainly would not be an issue from the FedRAMP side).

[StevenCh99]

With regards to CDS-CSO-IRP:

1. Can a CSP have a policy that points to the KSI narratives as the policies and procedures? Would that be sufficient to meet the rule?
2. Must every KSI have a policy and procedure that governs them?
3. The only procedures or policies explicitly mentioned in the KSIs are for : change management (KSI-CMT-RVP), incident response (KSI-INR-RIR), recovery plans (KSI-RPL-ARP), and emergency changes (SCN-CSO-EMG). Are there any additional procedures the FedRAMP PMO expects CSPs to maintain.
4. “Providers MUST supply all relevant policies and procedures” How does the FedRAMP PMO interpret/define what policies or procedures are considered “relevant”?

Thank you very much,
Steven

[pete-gov]

Can a CSP have a policy that points to the KSI narratives as the policies and procedures? Would that be sufficient to meet the rule?

This rule exists to say that if reference important policies in your FedRAMP Certification Package then you must include them. It goes beyond the KSIs and is equally relevant for all FedRAMP Practices.

If you have a disaster response policy, you should probably include it. If you have a background check policy, you should probably include it. Unlike ISO or old FedRAMP, we won't pick a big fight with you about what you name them or what's in them, but the reality is that your customers probably want to know what you actually say your policy is.

Must every KSI have a policy and procedure that governs them?

Nope. The 20x-specific provider responsibilities for the Security Decision Rules contain the expectations of what you'll document about the KSIs. Everything beyond that is about optimizing the customer experience and providing high quality assurance.

The only procedures or policies explicitly mentioned in the KSIs are for : change management (KSI-CMT-RVP), incident response (KSI-INR-RIR), recovery plans (KSI-RPL-ARP), and emergency changes (SCN-CSO-EMG). Are there any additional procedures the FedRAMP PMO expects CSPs to maintain.

You'll hear this a lot from FedRAMP in 20x - this is a customer experience decision, not a compliance decision. In general we do not tell you what policies and procedures to maintain and expect you instead to follow any of the many many cybersecurity frameworks available to you to help you identify appropriate policies and procedures for your business and products. We also aren't particularly opinionated about what is in the policies and procedures generally... but your customers might be.

If an agency is really interested in seeing high quality disaster response policies and you can't produce them, then they probably won't want to use your product. Other times plenty of agencies won't particularly care though, and you'll be fine. But documenting exactly what policies and procedures you have, information about them, and making them easy to access is a great way to show that you are serious about security and sharing information with potential customers that want to see that stuff.

“Providers MUST supply all relevant policies and procedures” How does the FedRAMP PMO interpret/define what policies or procedures are considered “relevant”?

The It's Not a Trap! section of Using the Consolidated Rules should help you approach this!

-Pete@FedRAMP

[StevenCh99]

@pete-gov thank you very much for your answers!