Skip to main content
Official source: Security Decision Record (SDR), FedRAMP Consolidated Rules release 2026.10.14.01. This page is a plain-English summary. The official rule text governs.

​
In short

The Security Decision Record (SDR) replaces the traditional System Security Plan. It is a persistently maintained, verified and validated record of the security decisions you make over the life of your cloud service offering. For every applicable FedRAMP rule you must explain how you follow it (or why you don’t and the resulting risk), show your own verification and validation, and include your assessor’s independent verification and validation. 20x providers add summaries for each Key Security Indicator, and Rev5 providers add summaries for each Rev5 control.

​
Who it applies to

The 20x subset lists Classes B, C and D, but SDR-CSX-KMT includes a Class A variant (MAY).

​
Key dates

​
What you need to do

The JSON format follows the FedRAMP Security Decision Record schema.

​
General provider responsibilities (20x and Rev5)

For each applicable FedRAMP rule, SDR-CSO-FRR requires at least:
  1. An explanation of how you follow the rule, or the reason you don’t and the resulting risk to customers.
  2. Verification that the implementation is appropriate for the rule, or that a senior official accepted the reason for not implementing it.
  3. Validation that the implementation is in place and working as intended, or that a senior official accepted the reason for not implementing it.
  4. Independent verification.
  5. Independent validation.
  6. Any responses or clarifications to comments in the independent verification or validation.
  7. Rule-specific artifacts, if applicable.

​
20x-specific provider responsibilities

For each applicable Key Security Indicator, SDR-CSX-KSI requires summaries of at least:
  1. The measures (and their objectives) that demonstrate the indicator, or the reason you have no measures and the resulting risk to customers.
  2. The cycle for any measures you implement persistently, if applicable.
  3. Verification that the measures demonstrate the indicator, or that the reason for not having them is accepted.
  4. Verification that your automation is accurate and sufficient to demonstrate appropriate measures, or that automation isn’t necessary for each measure.
  5. Validation that the measures are accurately produced, in place and working as intended, or that the reason for not having them is valid.
The note on SDR-CSX-KMT says that for initial certification, if your service hasn’t been running with related metrics for the required period, you will need to have mechanisms in place and agree to meet the requirement.

​
Rev5-specific provider responsibilities

For each applicable Rev5 control, SDR-CSF-CTF requires summaries of at least:
  1. Any organization-defined parameter values.
  2. Implementation status: Implemented, Partially Implemented, Planned, Alternative Implementation or Not Applicable.
  3. The mechanisms or activities that address the control, including inheritance from another cloud service offering if applicable.
  4. The verification in place to ensure the implementation is appropriate for the control.
  5. The validation in place to ensure the implementation is working as intended.
  6. Independent verification.
  7. Independent validation.
  8. Any responses or clarifications to comments in the independent verification or validation.
  9. Control-specific artifacts, if applicable.

​
Differences by class

SDR-CSX-KMT (Key Security Indicator Metrics) varies by class. The 2026-10-08 release changed Class B from MUST to SHOULD and clarified that persistent validation status is one of the metrics.

​
What FedRAMP staff have said

Describe how and show the result. On 2026-10-13, pete-gov said SDR-CSO-FRR asks for a lot, and most of it isn’t structured in the schema. You must provide both summaries of how things are done and verification and validation that they are being done that way. Asked to confirm, pete-gov said yes: you provide both an explanation of the steps you take to verify and validate, and the results of performing them. pete-gov also said schemas aren’t templates: follow the rules, not the schemas. Discussion #146 comment, follow-up
You own all SDR content. On 2026-09-08, pete-gov said the provider is responsible for all content in its SDR, including the independent verification and validation that the assessor supplies under IVV-IAS-SUM. The assessor verifies inclusion under IVV-IAS-VIP. For SDR-CSX-KSI, the assessor verifies and validates what you supply for all five items for each KSI. The assessor doesn’t supply your tests and evidence. Discussion #169 comment, follow-up
Where independent results come from. On 2026-10-13, pete-gov said IVV-IAS-SUM is the instruction to the assessor to supply the information for items 4 and 5 of SDR-CSO-FRR (independent verification and validation). Discussion #146 comment
Organizing SDR responses. On 2026-09-01, dan-fedramp said you are encouraged to organize SDR responses in whatever way communicates your solution and residual risk to an agency reviewer, including combining data into a single field. dan-fedramp also said SDR-CSO-FRR and SDR-CSF-CTF aren’t meant to make you re-list every requirement or control response. For those two rules, describe the process that ensures compliance, for example how your GRC tool generates the SDR, a script that checks completeness and format, and that script’s output for the current version. Discussion #146 comment
“Source of update” metadata. On 2026-08-17, dan-fedramp said “Source of update” in SDR-CSO-MTD tells the reviewer whether the update is regular and recurring or prompted by an unusual event. There are no prescribed values. Examples are a process such as continuous monitoring, SCN or incident response. Discussion #147 comment
Artifact links. On 2026-08-18, paulagosta said artifacts should support the machine-readable answers, not replace them (for example, linking the same SRTM for every item of SDR-CSF-CTF). On 2026-08-24, emu-gov said direct links are best when an artifact isn’t in the SDR itself. “See Trust Center” can cause delays, and FedRAMP will push back on submissions where reviewers can’t find the files. Discussion #147 comment (paulagosta), Discussion #147 comment (emu-gov)
Rev5 transition timing. On 2026-09-22, pete-gov said there is a grace period for everything in Rev5. For some rulesets, such as the SDR, it is based on when the first FedRAMP independent assessment (annual assessment) starts, not when it ends. A provider finishing an annual assessment in December 2026 can early adopt or wait until its next assessment starts. On 2026-08-27, paulagosta suggested using item 8 of SDR-CSF-CTF to note the assessment date when independent verification and validation came from earlier annual assessments. Discussion #146 comment (pete-gov), Discussion #146 comment (paulagosta)