Baselines
FedRAMP's baselines are available in OSCAL XML, JSON and YAML formats on the OSCAL Foundation's fedramp-resources GitHub repository.
The OSCAL Foundation is making FedRAMP baselines available both as OSCAL profiles and as pre-processed resolved profile catalogs. While organizations can initially use the resolved profile catalogs to reduce complexity and get started more quickly, full profile resolution is required to handle control overlays and multiple frameworks. Profiles are authoritative. Resolved Profile Catalogs are for convenience only.
See the Concept of Operations below.
Quick Start (MVP/CORE)
Get started quickly by skipping profile resolution processing and instead using "resolved profile" catalogs of the FedRAMP baseliens.
Although OSCAL offers a great deal of flexibility with baselines and overlays, if you need to get started quickly and just want a single OSCAL file with the controls for your baseline.
The following OSCAL "resolved profile" catalogs are exactly what you need:
- FedRAMP HIGH Baseline (OSCAL Catalog) [ XML | JSON | YAML ]
- FedRAMP MODERATE Baseline (OSCAL Catalog) [ XML | JSON | YAML ]
- FedRAMP LOW Baseline (OSCAL Catalog) [ XML | JSON | YAML ]
- FedRAMP LI-SaaS Baseline (OSCAL Catalog) [ XML | JSON | YAML ]
OSCAL Tailoring and Overlays
OSCAL is designed to be referential. It enables tailoring of controls and the ability to overlay controls. The FedRAMP OSCAL profiles are available for these more complex scearios.
The following referential structure is used:
- A single FedRAMP Rev 5 tailoring profile imports the NIST SP 800-53 Rev 5 catalog. FedRAMP control tailoring that applies to all baselines is performed here.
- High, Moderate, and Low FedRAMP Rev 5 Profiles each import the FedRAMP Tailoring Profile. Each also identifies the controls for that baseline and include any baseline-speicifc control tailoring.
- Low-Impact SaaS is a special FedRAMP tailoring of the FedRAMP Low baseline. It imports the FedRAMP Low Profile and tailors it further.
The "resolved profile" catalogs at the top of this page are the result of processing the control selection and tailoring represented here.
Available OSCAL Catalog and Profiles
The following OSCAL catalogs and profiles are available:
-
NIST SP 800-53, Revision 5 (OSCAL Catalog) [ XML | JSON | YAML ]
-
FedRAMP Tailoring Profile (OSCAL Profile) [ XML | JSON | YAML ]
-
FedRAMP MODERATE Baseline (OSCAL Profile) [ XML | JSON | YAML ]
-
FedRAMP LI-SaaS Baseline (OSCAL Profile) [ XML | JSON | YAML ]
Concept of Operations
OSCAL catalogs are used to define controls. OSCAL profiles are used to establish control baselines, tailor controls, handle control overlays, and aggregate controls from multiple compliance frameworks.
OSCAL tools SHOULD process profiles as the authoritative representation for baselines, tailored controls, overlays, and aggregated frameworks imposed on a specific system.
Resolved Profile Catalogs
It is possible to pre-process OSCAL profiles and catalogs into a cached resolved profile catalog. This result is represented as an OSCAL catalog, using the same syntax. The OSCAL Foundation has done this for the FedRAMP baselines.
| Benefits | Tradeoffs |
|---|---|
| Allows organizations to initially skip profile processing and focus on other aspects of OSCAL adoption | Overlays and multiple frameworks are not possible. The cached content can become stale. |
The SSP OSCAL guidance for “import-profile” specifically discourages the use of a “resolved profile catalog” for good reasons.
It makes sense to create the “tailoring-profile” and have the other profiles pull from the tailoring-profile, while this approach is useful from authoring effort perspective, it adds runtime burden for having to resolve multiple layers of profiles.
Is there an approach to resolve “multiple stacked profiles” into single profiles so that they can be referenced directly in the SSP?
The baselines are not likely to change very often, so perhaps a more efficient runtime solution bears better.
In reply to #1
While I completely agree that multi-layer profile resolution is the the preferred approach and the only way to handle overlays and multi-frameworks, we are looking to initially reduce complexity to the greatest degree practical for MVP/Core adoption, then allow organizations to mature their capabilities over time based on their needs and priorities.
In reply to #1
Discussed in today's TFG. We agree that that resolved profiles allow an easy quick-start. Verified that we show it initially in the adoption and moving to proper profile processing by the "Normalized" phase.. Considering this closed.
In the TFG meeting, highlighted the need to verify FedRAMP has not changed the baselines since these were drafted in Jan 2025.
No comments to display
In the TFG meeting we discussed putting more content at the top to clarify tools should be using the profiles and performing the resolution themselves. Tools may cache as appropriate depending on frequency of updates to these profiles and any overlays. @Brian Ruftaking action to draft content.
Clarify this is important to ensure baselines remain fresh.
In reply to #2
This is complete.
No comments to display