2026/reference/20x/c/security-decision-record/

[giscus[bot]]

2026/reference/20x/c/security-decision-record/

https://www.fedramp.gov/2026/reference/20x/c/security-decision-record/

[VSQ22022]

In the SDR JSON schema, ksiEvidence (which references Screenshot, Log, Configuration, and command/log output) is marked as required, even though raw evidence artifacts are not specified in the related SDR rules (SDR-CSX-KSI and SDR-CSX-KMT). Can the PMO confirm that CSPs are NOT expected to generate or share traditional point-in-time evidence (such as redacted screenshots or raw logs) in the SDR, and that KSI 'evidence' in 20x is instead meant to be automated, persistent validation signals and metric summaries (e.g., pass/fail validation status and 30-day / annual / daily metrics per SDR-CSX-KSI, SDR-CSX-KMT, and FRC-CSX-MOT)? If any underlying point-in-time or technical evidence is required, can CSPs share it ONLY with assessors/PMO during IV&V (per IVV-CSO-SEI and CDS-CSO-RIS) rather than with agencies in the SDR - to avoid the workload and security risk of sanitizing raw evidence?

[pete-gov]

The schema does not enforce any expectations or rules. The requirements in the schema are organizational to provide some consistent review, or on occasion aligned to specific rules. The schema is currently designed to transition legacy systems, Rev5 systems, and 20x systems. "Evidence" has different expectations across all of those.

Under CR26 the "evidence" in the schema refers to the information required under SDR-CSO-FRR/etc. (verification and validation methodology). For traditional Rev5 CSPs, things like screenshots might still be used in that process. In 20x, that would be fairly unusual.

[KristenPage]

SDR-CSO-FRR states
Providers MUST supply a Security Decision Record, in both human-readable and JSON formats, that includes at least all of the following information for each applicable FedRAMP rule:

Explanation of how the rule is followed, or an explanation of the reason and resulting risk to customers for not following the rule.
Verification that the implementation is appropriate for the rule, or that the reason for not implementing is accepted by a senior official.
Validation that the implementation is in place and working as intended, or that the reason for not implementing is accepted by a senior official.
Independent verification.
Independent validation.
Any responses or clarifications to the comments in the independent verification or validation.
Rule-specific artifacts (if applicable)

However the JSON schema provided does not have a node for rulesets - only for NIST 800-53 controls and KSIs. Is that an oversight or is there another version of the JSON s that does include it?

[pete-gov]

The JSON schemas are not templates, they only provide a very high level opinionated structure for specific types of information. We expect individual providers to determine the best way to share this information within the top level structure.

[ricmarreycoal]

For SDR rule SDR-CSX-KMT. Could you give an example of an acceptable summary for both below? Does it mean having to write up a summary every 30 days for each Key Security Indicator? Or is it an automated summary? It seems a lot to require a summary every 30 days were it to be a written statement on the data. Would a dashboard graph act as a summary?

• Summary of each metric over the past 30 days

• Summary of metric up to the past year (where available)

[pete-gov]

If you look at the requirements for Class C and Class D it shows a bit more context, but this is a plain-language requirement designed for cloud service providers to consider the optimal customer experience.

It would be very unusual to generate these summaries manually! But if someone thinks that's worth it, that's up to them. ;)

Summary of each metric over the past 30 days

Examples would vary depending on the metric and designed customer experience. Let's say something like KSI-CMT-VTD Validating Throughout Deployment. A summary over the past 30 days might be anything like:

• 17 out of 17 (100%) of deployments were validated using cryptographic integrity hashes to ensure operating code matched intended code in development
• No deployments were performed.
• Jimmy personally ran a verification script the only deployment done last week and it was good.
• etc.

Or it could be an incredibly detailed set of graph data with access to logs, root causes, timelines through tickets, resulting outcomes, etc. What kind of assurance do you want your customers to have?

Summary of metric up to the past year (where available)

Same stuff.