FedRAMP's Rev 5 baseline overhaul: CSPs now set their own control parameters

Published as NTC-0013 (June 16, 2026). FedRAMP issued the initial outcome of RFC-0026 through RFC-0030 — the rebuild of every Rev 5 baseline inside the Consolidated Rules for 2026 (CR26). Three structural changes land at once: FedRAMP removes most of its assigned control parameter values and hands that job back to the provider; it pulls FedRAMP-specific guidance out of the baselines into a separate “FedRAMP Rules” construct; and it replaces the SSP / SAR / CRM templates with a machine-readable Certification Package. The changes are mandatory for new Rev 5 certifications on January 1, 2027, and existing providers adopt them at their first independent assessment after that date. If you hold or are pursuing a Rev 5 authorization, the way you author your package is changing.

We covered the incident-communications side of CR26 — the NTC-0012 reporting overhaul — when it landed. NTC-0013 is the larger structural piece: it changes the baseline itself, and with it the document set every cloud service provider builds and every agency reviews. This is a practitioner read of what changed, why FedRAMP made each move, and what a provider should do in the months before it becomes mandatory.

The short version

The NIST SP 800-53 Rev 5 control catalog has not changed. What changed is the FedRAMP layer that sits on top of it — and that layer is where most of the authoring work in a FedRAMP package actually lives. Three things moved:

1. You set your own control parameters now. FedRAMP removed most of the organization-defined parameter values it used to assign. Providers set their own, per NIST’s rules, based on what the service actually does — and defend them.
2. FedRAMP-specific guidance left the baseline. The extra rules FedRAMP layered onto individual controls are gone from the baselines and now live in a separate “FedRAMP Rules” construct.
3. The template set is replaced by a machine-readable Certification Package. The System Security Plan, Security Assessment Report, and Control Implementation Summary / Customer Responsibility Matrix give way to three new documents built as data.

Each one changes how you write a package, not which controls you implement. Taken together, they move FedRAMP further toward the data-first direction of the 20x program — and they shift judgment and authoring burden onto the provider.

1. You now set — and defend — your own control parameters

For years, a large share of a FedRAMP Rev 5 baseline arrived with the organization-defined parameters already filled in. Where NIST writes a control as “the organization defines the frequency of [X],” FedRAMP supplied the value, and providers inherited it. That made authoring faster, but FedRAMP’s own conclusion is that it backfired: pre-assigned values created a ceiling. Providers implemented to the assigned minimum rather than to what their architecture and risk warranted, and in some cases that was weaker than what the service was already doing.

NTC-0013 removes most of those assigned values. In FedRAMP’s words, providers must now “follow NIST rules to assign their own actual organization-defined control parameter values based on the actions taken by the cloud service, and identify these assignments within their System Security Plan (or future Security Decision Record) for review by FedRAMP and agencies.”

The practical effect is a shift from inheriting a number to owning one. A parameter you set yourself is a parameter you have to justify — to FedRAMP at certification and to every agency authorizing official who reads your package. That cuts both ways:

• The risk: every organization-defined parameter is now an authoring decision and a defensibility question. Set a value you cannot evidence, and it becomes a finding. Set one that contradicts how the system actually behaves, and an assessor will catch the gap between the parameter and the configuration.
• The opportunity: you can set values that reflect what your service genuinely does rather than a generic floor. A provider whose architecture already exceeds the old assigned minimum can now say so, document it, and turn it into a differentiator instead of hiding it under a ceiling.

This is the change most likely to surprise teams that authored a Rev 5 package before. The control-implementation narrative work we describe in what assessors actually read in your SSP now extends to the parameters themselves: each one needs a real, evidenced basis, not an inherited default.

2. FedRAMP-specific guidance moved into “FedRAMP Rules”

The second change is organizational, but it matters for how you read the requirements. FedRAMP historically embedded additional guidance directly in the baseline — extra rules attached to specific controls that went beyond the NIST text. NTC-0013 removes nearly all of that from the Rev 5 baselines.

The requirements did not disappear. They moved into a separate construct FedRAMP calls “FedRAMP Rules” — described as “all the applicable rules that are uniquely necessary for a cloud service to assure government customers.” What stays attached to the control is demoted to tips and clarifications; the binding obligations are now expressed as discrete, referenceable rules in CR26.

For a practitioner, the consequence is that the baseline and the requirements are no longer the same document. You read the NIST control, you set your own parameter, and you check the separate FedRAMP Rules for the obligations that are FedRAMP-specific. It is a cleaner separation — controls in one place, FedRAMP’s uniquely-government requirements in another — but it means a Rev 5 package authored against the old embedded-guidance model needs to be re-mapped against the new rules construct, not find-and-replaced.

This is the same structural direction running through the rest of CR26 and the 20x program: pull the requirements out of prose and into a defined, referenceable, increasingly machine-readable form.

3. The Certification Package replaces the SSP, SAR, and CRM

The third change is the one that reshapes the deliverable. The legacy FedRAMP template set — the System Security Plan, the Security Assessment Report, and the Control Implementation Summary / Customer Responsibility Matrix — is replaced by a machine-readable Certification Package built from three documents:

• Certification Package Overview — replaces most of the System Security Plan. It consolidates the description of the cloud service offering and its authorization boundary.
• Security Decision Record — replaces the control-implementation content of the SSP and the Security Assessment Report. It is organized around each FedRAMP Practice and consolidates the implementation and assessment decisions for it.
• Secure Configuration Guide — replaces the Control Implementation Summary / Customer Responsibility Matrix. It consolidates the responsibilities that flow to the customer.

The headline is not the renaming; it is the machine-readable part. A package that used to be a set of large prose documents becomes structured data — the same shift the 20x program made with Key Security Indicators. For providers, that is a tooling and data-model change as much as a writing change: the boundary, the practices, the parameters, and the customer responsibilities all need to be expressed in the package’s structured format rather than narrated in a document.

The boundary work does not get easier — if anything, expressing it as data forces precision that prose let teams paper over. The authorization boundary remains the most consequential design decision in any federal authorization, and the Certification Package makes the cost of an imprecise boundary visible earlier.

The timeline

The dates are firm enough to plan against, and the window before mandatory adoption is short for a change of this size:

• May 4, 2026 — public preview of the Consolidated Rules for 2026 launched.
• June 24, 2026 — CR26 released. (FedRAMP has amended it through versioned rule releases since; the CR26 changelog at fedramp.gov/2026/changelog/ is the one to watch.)
• January 1, 2027 — mandatory for new Rev 5 certification applications, and the line after which existing certified offerings must adopt the new approach at their first FedRAMP independent assessment.
• June 11, 2027 — last date FedRAMP accepts new Rev 5 certification requests.
• No later than 2029 — targeted (not yet finalized) end date for all existing Rev 5 certifications.

The practical reading: a provider starting a Rev 5 certification today should design the package to the new model now rather than build to the legacy templates and re-author in six months. A provider already certified should treat their next independent assessment after January 1, 2027 as the conversion point and plan the parameter-setting and Certification Package work into it deliberately.

What a cloud provider should do now

1. Inventory every organization-defined parameter you inherited. For each one, decide the value your service actually warrants and capture the evidence for it. The parameters you cannot yet evidence are your real work list — they were invisible while FedRAMP assigned them and are now yours to defend.
2. Re-map your requirements against “FedRAMP Rules,” not the old embedded guidance. Do not assume a one-to-one carryover. Read the new rules construct and confirm which obligations apply to your service.
3. Plan the Certification Package as a data-model change, not a document rewrite. The Overview, Security Decision Record, and Secure Configuration Guide are structured artifacts. If your current package lives in prose, the conversion is an engineering task — budget for it.
4. Pick your conversion point deliberately. New application: build to the new model from the start. Existing certification: scope the parameter-setting and package conversion into your first assessment after January 1, 2027 rather than discovering it under deadline.
5. Treat the parameters you set as a posture decision. Where your architecture genuinely exceeds the old assigned floor, set the value to match and document it. The ceiling is gone; a well-evidenced parameter is now something you can stand behind rather than something you inherited.

Where this fits

NTC-0013 is the structural half of CR26; the NTC-0012 incident-communications overhaul is the operational half, and FedRAMP’s vulnerability-management response to CISA BOD 26-04 lands alongside both. Read together, they describe a FedRAMP that is moving its requirements out of prose, handing more judgment to the provider, and expressing the whole package as data.

Our FedRAMP and DoD CC SRG practice authors Rev 5 packages to the standard an independent assessor and an agency authorizing official actually read — and that now includes setting and defending your own control parameters and building the Certification Package as structured data, not a binder. If you hold a Rev 5 authorization, or you are mid-application and just learned the template set is changing under you, a scoping conversation will surface the gap quickly: which parameters you have to take ownership of, how your requirements re-map to the new rules, and what converting to the Certification Package actually takes before your date.

Related reading: FedRAMP 20x deep-dive · FedRAMP Rev 5 SSP changes · FedRAMP Rev 5 control mapping · NTC-0012 incident communications overhaul · FedRAMP framework overview