The FedRAMP SSP Replacement: Security Decision Record

If you’ve worked in FedRAMP, you know the System Security Plan (SSP). Hundreds of pages, usually updated right before assessment, and potentially out-of-date three weeks  later. Under the 2026 Consolidated Rules, the SSP is gone and replaced by something called the Security Decision Record (SDR). 

The SDR isn’t a simple rebrand, and it’s not a document you write once and defend at assessment time. Instead, it’s a living, continuously maintained account of every security decision you’ve made, and it’s structured in layers most teams aren’t expecting. 

FedRAMP defines it as a persistently maintained, verified, and validated record of your security decisions across the life of the cloud service offering. It has to exist in both human-readable and JSON form, and it has to stay current, not just be accurate on the day you submit it.  

So, what do we keep record of? Well, that changes for each layer of requirements: 

Layer one: every applicable FedRAMP rule needs seven things

This is the base requirement, and it applies no matter which path you’re on. For each applicable FedRAMP rule, your SDR has to include: 

  1. An explanation of how you follow the rule (or the reason and resulting risk if you don’t) 
  2. Verification that the implementation is appropriate (or that a senior official has accepted the risk of not implementing it) 
  3. Validation that the implementation is in place and working as intended 
  4. Independent verification 
  5. Independent validation 
  6. Any responses or clarifications to comments from that independent verification and validation 
  7. Rule-specific artifacts, where applicable 

Notice what’s baked into that list: it’s not just “explain your decision.” It’s explanation, then internal verification, then internal validation, then an independent party doing verification and validation again, then a documented back-and-forth if there’s disagreement. That’s a five-step chain per rule, not a paragraph in a spreadsheet. If that pipeline doesn’t already exist inside your organization, building it is the actual FedRAMP work, and everything else is downstream of it.

Layer two: 20x adds Key Security Indicators, and they’re a separate five-item list

If you’re on the FedRAMP 20x path, every applicable Key Security Indicator (KSI) needs its own short, high-level summary covering: 

  1. An explanation of the measures that demonstrate the KSI, and their objective (or the reason and risk if you don’t have measures for it)
  2. The cycle for any measures implemented persistently, if applicable
  3. Verification that the measures demonstrate the KSI
  4. Verification that your automation is accurate and sufficient to demonstrate the measures (or that automation isn’t needed for that one)
  5. Validation that the measures are accurately produced and are working as intended

It’s worth calling out here: this isn’t the same list as the FedRAMP Rules requirement relabeled for KSIs. It’s a distinct, shorter set of expectations that sits on top of the rule-level requirements. A team that treats “document the rule” and “document the KSI” as the same exercise will under-build one of them.

Layer three: Rev5 hasn’t disappeared, and it has its own structure

If you’re on the Rev5 path instead of 20x, the SDR doesn’t ask for KSIs, it asks for your NIST 800-53 controls. This list runs to nine items per control: organization-defined parameter values, implementation status (Implemented, Partially Implemented, Planned, Alternative Implementation, or Not Applicable), the mechanisms or activities addressing the control, verification, validation, independent verification, independent validation, any clarifying responses, and control-specific artifacts.

The engineering over documentation challenge

The SDR isn’t one list that applies uniformly. It’s three related but distinct structures depending on what you’re documenting:

  • FedRAMP rules: Applies to everyone, seven items recorded
  • KSIs: Applies to 20x only, five items recorded
  • Rev5 controls: Applies to Rev5 only, nine items recorded

Conflating them is an easy way to under-scope your build.

Most teams can picture what a document looks like. Almost nobody starting out has a verification-and-validation pipeline that runs continuously, feeds independent review, and produces machine-readable output on demand. That’s an operational project and it’s the thing to start building now, regardless of which class or path you’re targeting.

A-LIGN is a top three FedRAMP assessor with over 1,000 federal assessments completed. Reach out today to begin your journey and reach certification with confidence.