RFC-0020: FedRAMP Authorization Designations

[pete-gov]

RFC-0020: FedRAMP Authorization Designations

❓ Please note that FedRAMP will not answer questions in this thread as it is reserved for public comment. If you would like to ask a question or generally discuss this RFC informally, please use the General discussion / Q&A for RFC-0019 through RFC-0024 thread. Thank you!

Status: Closed
Start Date: January 13, 2026
Closing Date: February 19, 2026

The initial outcome from this RFC can be seen here: https://www.fedramp.gov/notices/0004/

Summary

This RFC proposes changes to directly tackle the confusion between “FedRAMP authorization” and an agency “authorization to operate” to align with terminology and usage in statute, OMB policy, and NIST materials. The proposed general changes in this RFC include:

• FedRAMP authorizations will be given specific formal labels to clearly identify them.
• FedRAMP security categories will transition from FIPS 199 security categories (Low, Moderate, High) to a number-based level system instead.

This RFC is aligned with other concurrent RFCs that have additional detail on specific topics but have been published separately to encourage topic-specific comments:

• RFC-0021: Expanding the FedRAMP Marketplace
• RFC-0022: Leveraging External Frameworks
• RFC-0023: Sponsorless Rev5 Certifications

Motivation

A FedRAMP authorization indicates that FedRAMP has packaged essential security information from a cloud service provider that can be used by an agency to make a determination whether or not to use that service; it is not a decision by an Authorizing Official that the service has been granted an Authorization to Operate (ATO). The use of “authorization” in a government IT context should be limited to the use outlined in OMB Circular A-130 around Authorization to Operate and the NIST Risk Management Framework’s Authorization Step.

The FedRAMP Board has found that the use of the words “authorized” / “authorization” for a FedRAMP authorization has created significant confusion about the separation of responsibilities for authorizing the use of information systems in government and recommended that FedRAMP establish separate designations for FedRAMP authorizations.

Cloud service providers frequently misunderstand FedRAMP “authorization” to be a government-wide ATO that allows any agency to immediately use their service. Federal employees often mistakenly believe that they can use any FedRAMP “authorized” cloud service without agency oversight. Agency security officials may take inappropriate risks when adopting a FedRAMP “authorized” cloud service in the mistaken belief that FedRAMP or other agencies oversee its security on their behalf, sometimes without even reviewing the materials in the FedRAMP authorization package. These behaviors, even if limited, can result in adverse impacts to federal information and federal information systems.

Similarly, a FedRAMP authorization at a given traditional NIST FIPS 199 security objective (Low, Moderate, High) does not necessarily align with the security objective of an agency information system that reuses that FedRAMP authorization. Only an Agency Authorizing official can identify the security category of an information system for their specific use case; there is an entire Categorize Step in the NIST Risk Management Framework dedicated to this for federal agencies. Agencies regularly use FedRAMP authorization materials in agency information systems with an ATO at a lower or higher security objective than the FedRAMP authorization; this is strongly encouraged.

FedRAMP should, to the greatest extent possible, provide a process to industry and federal agencies that reuses common industry terminology and avoids confusion around government terms. The designations FedRAMP uses should make it easier for all parties to understand the existing separation of responsibilities between FedRAMP, agencies, and cloud service providers. Overlapping, confusing, or duplicative designations should be avoided; therefore, both FedRAMP “authorization” and the terminology around the complexity of the assessment should have easy to understand designations that avoid this type of confusion.

Therefore, this RFC proposes creating FedRAMP Certified (Rev5) and FedRAMP Validated (20x) designations for FedRAMP authorizations, with each designation having 6 levels of increasingly complex assessment and monitoring requirements. To mitigate initial confusion, all current FedRAMP authorizations will be automatically mapped to a specific designation and level.

FedRAMP Certified (Rev5)

The “FedRAMP Certified” authorization designation indicates that a service has completed a point-in-time assessment by FedRAMP, based primarily on a review of filed paperwork, that meets legacy FedRAMP Rev5 requirements. FedRAMP has reviewed and assessed this package for completeness against a legacy FedRAMP Rev5 baseline and certified that there is sufficient information in the assessment materials to be used by agencies following the legacy FedRAMP Rev5 process. All Rev5 Certified services are FedRAMP authorized.

FedRAMP Certification levels do not indicate the security of the cloud service overall! These levels only indicate the coverage and depth of the assessment materials available to agencies via FedRAMP.

Effective Date: March 18, 2026 (tentatively) - on or near this date, all cloud services will be transitioned to their new designation.

Rev5 Certified Levels	Description	Historical FedRAMP Rev5 Categorization
Certified Level 1	There is a minimum amount of information in the FedRAMP Certification package that is adequate for use in a negligible or low risk non-sensitive authorization decision in most cases.	Li-SaaS
Certified Level 2	There is a small amount of information in the FedRAMP Certification package that is adequate for use in a low impact authorization decision in most cases.	Low
Certified Level 3	There is a typical amount of information in the FedRAMP Certification package that is adequate for use in a moderate impact authorization decision in most cases.	Moderate
Certified Level 4	There is a typical amount of information in the FedRAMP Certification package that is adequate for use in a moderate impact authorization decision in almost every case. This level also means that the cloud service provider has implemented all Rev5 Balance Improvement Releases and met nearly all recommendations from FedRAMP with no corrective action for the past year.	N/A
Certified Level 5	There is a significant amount of information in the FedRAMP Certification package that is adequate for use in a high impact authorization decision in many cases.	High
Certified Level 6	There is a significant amount of information in the FedRAMP Certification package that is adequate for use in a high impact authorization decision in almost every case. This level also means that the cloud service provider has implemented all Rev5 Balance Improvement Releases and met nearly all recommendations from FedRAMP with no corrective action for the past year.	N/A

Marketplace Lifecycle for Rev5

Cloud services following the legacy FedRAMP Rev5 agency authorization or program authorization processes will transition between the following statuses during their lifecycle on the Marketplace:

1. Preparation: The provider is carrying out the essential activities to prepare the organization to manage its security and privacy risks following the FedRAMP Rev5 process.

   Note: This status has specific requirements outlined in RFC-0021: Expanding the FedRAMP Marketplace.

2. Agency Authorization In Process: An agency has notified FedRAMP that they have begun an agency authorization for the cloud service in accordance with FedRAMP guidelines.

3. Assessment by FedRAMP: FedRAMP is performing the final assessment that may result in FedRAMP Certification for the cloud service offering. The target time for this step is less than 30 days if the package is truly complete.

4. Continuous Monitoring: The cloud service is FedRAMP Certified and is continuously monitoring the security of their service in alignment with FedRAMP Rev5 continuous monitoring requirements.

   Note: This is the target end status for Rev5 cloud service offerings.

5. Remediation: The provider is currently correcting a significant underlying issue with the cloud service.

FedRAMP Validated (20x)

The “FedRAMP Validated” authorization designation indicates that a service has demonstrated to FedRAMP the ability to persistently validate their security posture such that their validation package will always accurately reflect the current status of their service. FedRAMP has assessed the processes used by this service provider and ensured there is sufficient information in the persistent assessment materials to be used by agencies to make ongoing authorization decisions. All 20x Validated services are FedRAMP authorized.

FedRAMP Validation levels do not indicate the security of the cloud service overall! These levels only indicate the coverage and depth of the assessment materials available to agencies via FedRAMP.

Effective Date: March 18, 2026 (tentatively) - on or near this date, all cloud services will be transitioned to their new designation.

20x Validated Levels	Description	Historical FedRAMP 20x Categorization
Validated Level 1	There is a minimum amount of information in the FedRAMP Validation package that is adequate for use in a negligible or low risk non-sensitive authorization decision in most cases.	Pilot
Validated Level 2	There is a small amount of information in the FedRAMP Validation package that is adequate for use in a low impact authorization decision in most cases.	Low
Validated Level 3	There is a typical amount of information in the FedRAMP Validation package that is adequate for use in a moderate impact authorization decision in most cases.	Moderate
Validated Level 4	There is a typical amount of information in the FedRAMP Validation package that is adequate for use in a moderate impact authorization decision in almost every case. This level also means that the cloud service offering has met nearly all recommendations from FedRAMP with no corrective action for the past year.	N/A
Validated Level 5	There is a significant amount of information in the FedRAMP Validation package that is adequate for use in a high impact authorization decision in many cases.	N/A
Validated Level 6	There is a significant amount of information in the FedRAMP Validation package that is adequate for use in a high impact authorization decision in almost every case. This level also means that the cloud service offering has met nearly all recommendations from FedRAMP with no corrective action for the past year.	N/A

Marketplace Lifecycle for 20x

Cloud services following the FedRAMP 20x process for program authorizations will transition between the following statuses during their lifecycle on the Marketplace:

1. Preparation: The provider is carrying out the essential activities to prepare the organization to manage its security and privacy risks following the FedRAMP 20x process; the cloud service may also be FedRAMP Validated Level 1 in this status.

   Note: This status has specific requirements outlined in RFC-0021: Expanding the FedRAMP Marketplace and RFC-0022: Leveraging External Frameworks.

2. Prioritized: The provider has been accepted into a pilot or other prioritization process where they are working directly with FedRAMP on finalizing a FedRAMP 20x Validation.

3. Assessment by FedRAMP: The service has submitted a complete 20x Validation package to FedRAMP that meets all FedRAMP 20x requirements for final assessment and processing. The target time frame for this step is less than 30 days if the package is truly complete.

4. Persistent Validation: The cloud service is FedRAMP Validated and is in the ongoing status of persistent validation in alignment with FedRAMP 20x persistent validation requirements.

   Note: This is the target end status for 20x cloud service offerings.

5. Remediation: The provider is currently correcting a significant underlying issue with the cloud service, typically as part of formal corrective action.

[zsoltbalogh]

Should 20x Level 5 and 6 mention Validation instead of Certification package in the table?

[pete-gov]

Should 20x Level 5 and 6 mention Validation instead of Certification package in the table?

Yes that is a copy/paste typo - fixed here, I'll put a fix in on the website too.

[jsantore-cgc]

I think this is somewhat confusing:
We're still Li-SaaS/Low/Mod/High (1,2,3,5) with (4) for Mod+balance improvement, and (6) High-balance improvement.

Some of the BIR stuff is beta, or must be done in conjunction with a CSP's AO, and cannot be unilaterally achieved. So someone might be stuck at level 3 somewhat involuntarily and then would appear to be 'less good' than a potential competitor at level 4. If that's the intended result, I'm not sure it should be. At the very least, I'd like to see 'no one can get level 4/6 until all of the BIR stuff is in general release and non-optional'

[cb-axon]

I agree this structure introduces confusion and inequity.

Levels 4 and 6 appear tied to Balance Improvement Releases (BIR), some of which are still evolving, optional, or dependent on agency coordination. CSPs should not be effectively penalized or appear “less mature” because adoption requires AO approval or because certain BIR elements are not yet fully mandatory or generally available.

At minimum, Levels 4 and 6 should be scoped only to mandatory, fully released requirements. Consideration should also be given where a CSP has attempted to adopt improvements (e.g., SCN-related changes) but was blocked by agency customers.

Additionally, clearer guidance is needed on how DoD-authorized systems will map into these levels to avoid reciprocity confusion.

[jsantore-cgc]

I also (and have commented on this elsewhere) worry about the stigma of 'corrective action' if corrective action is unclearly defined without means for appeals. Basically we don't want anyone penalized for a good faith disagreement over an particular requirement that may not be as clear as intended.

Also, does it make sense to adjust these to ''unaddressed corrective action' or something to that effect. If someone fixes the underlying cause of the CAP, I'm not sure it makes sense from a risk acceptance perspective to keep that as a black mark. It's not necessarily indicative of a lack of rigor or due care (particularly in light of good faith disagreements).

[wisecryptic]

It would make more sense to not include corrective action as a level criteria, but as a note, tag or similar indicator that corrective action is taking/took place.

[cb-axon]

I agree with these concerns.

If corrective action (CAP) status is tied to level designations, there must be clear, objective standards for what triggers a CAP and who has authority to issue it. In a decentralized model where agencies manage their own ATOs, one agency’s interpretation should not effectively impact a CSP’s Marketplace standing without defined criteria, adjudication, and appeal rights.

Corrective action should not function as an implicit downgrade mechanism. Historically, a CAP has not resulted in a formal reduction of impact level, and creating a structure where it indirectly does so—without clear standards—introduces risk and inconsistency.

If retained, CAP status would be better reflected as a contextual note or tag rather than a gating factor for higher designation levels.

[LSC100100]

The differences between the FedRAMP "certified" designation and the FedRAMP "validated" designation are not clear. How will these different designations be used to acquire new CSPs? Will RFPs specify a solution must be FedRAMP "certified" rather than FedRAMP "validated"? It is difficult enough trying to educate everyone on these terms and the nuances won't be understood by most people. Suggest going with 1 designation that means you've successfully been through the process (regardless of whether it is Rev5 or 20x), especially with Rev5 being phased out (and with Rev5 possibly temporarily opening up for no sponsorship).

Which gets to another point: why does any of this process hinge on Federal sponsorship? That is out of industry control and shouldn't be baked into this process at all. FedRAMP can vet a CSP solution irrespective of whether a federal agency is sponsoring it or not. And even though the 20x pathway does not require a sponsor, industry will still have to pay hundreds of thousands of dollars each year to re-do a 3PAO review if they have no sponsor. Why? You've already vetted the CSP and they are doing continuous monitoring. It is still a heavy financial burden for businesses.

Thanks for your consideration of these items.

[cb-axon]

I agree with the concern that the distinction between “Certified” (Rev5) and “Validated” (20x) may create confusion in acquisition. However, simply changing terminology will not prevent agencies from specifying one pathway over the other in RFPs, which could fragment the market.

Rather than collapsing to a single designation, FedRAMP should provide clear guidance on what agencies may and may not require in solicitations while both pathways remain active. Until a formal Rev5 phase-out plan and date are published, agencies should not be permitted to categorically exclude one pathway, in my opinion.

On sponsorship, this issue is addressed in RFCs currently open.

[TBailey223]

To address some of the concerns, I would recommend adding clarifying language that "Certified" & "Validated" are designations for the pathway by which CSPs achieve the standards set forth by FedRAMP.

I.e. CSPs that are Certified Level X have the same security rigor as CSPs that are Validated Level X.
OR something like this:
"The FedRAMP PMO recognizes the Certified and Validated authorization paths as security-equivalent at the same Level"

This could help mitigate confusion from agencies and stakeholders alike that may misinterpret "Certified" as superior to Validated or vice versa.

[jerome-miastkowski]

We Support Single Designation Based on Impact Level

We support the point raised in this comment, particularly the concern around introducing separate “Certified” and “Validated” designations.

At the end of the day, what matters is the impact level. A Low is a Low. A Moderate is a Moderate. A High is a High. The path taken to get there, Rev5 or 20x, should not create different labels that complicate acquisition or create confusion in RFP language.

Adding multiple designations risks making an already complex process harder to understand for contracting officers, program managers, and vendors. Stakeholders should focus on whether a solution meets the required impact level and is in good standing under continuous monitoring, not on the specific assessment pathway used.

We support moving toward a single, clear designation that signals a provider has successfully met the applicable FedRAMP impact baseline, regardless of whether that was achieved through Rev5 or 20x. Keeping the focus on impact level will reduce confusion and make adoption easier across government and industry.

[acloudcj]

A few questions as I work through this:

On the level definitions - The descriptions use phrases like "typical amount of information" (Level 3) versus "significant amount of information" (Level 5), but I'm not seeing the underlying NIST control mappings that would make these levels concrete. For Rev5, we have well-understood Low/Moderate/High baselines tied to SP 800-53. What's the equivalent for these new levels? Is Level 3 still the ~325 controls from Moderate, or is that changing? Without that anchor, it's hard to know what a CSP is actually committing to at each tier - and what an agency should expect to find in the package.

On the problem this solves - The motivation section identifies a real issue: agencies sometimes adopt FedRAMP services without reviewing the package or issuing their own ATO, assuming someone else is handling oversight. That reads to me like a governance gap, not a terminology gap. Will calling it "Certified" instead of "Authorized" actually change that behavior? I'm genuinely curious what mechanisms exist (or are planned) to ensure agencies do the work on their side - reviewing packages, making risk determinations, issuing ATOs. If those mechanisms don't exist, renaming gives agencies new terminology to skip over rather than fixing the underlying accountability problem.

One concrete suggestion - The Levels 1-6 naming is going to collide with DISA's Impact Levels (IL2, IL4, IL5, IL6) in procurement conversations. They mean completely different things, but program offices often conflate FedRAMP and DISA requirements already. Would something like "Assessment Tier" or "Coverage Tier" instead of "Level" help distinguish these? Or even just avoiding the specific numbers DISA uses (2, 4, 5, 6)?

[wisecryptic]

100% agree on the third concrete suggestion. Setting up a 1-6 scale is going to massively collide with the impact level scale

[cb-axon]

On the level definitions, I do not view the use of terms like “typical” and “significant” as a flaw that must be engineered out. The FedRAMP process has never been purely about control counts. Every system will have some findings, and assessments are ultimately about whether the package contains sufficient depth and clarity to support a risk decision. The underlying FISMA/NIST Low/Moderate/High baselines remain intact and are being mapped to KSIs at Levels 1, 2, 3, and 5. In that sense, “typical” versus “significant” reads as a reflection of depth of information within each KSI—not a redefinition of the control set—and some degree of subjectivity is inherent and appropriate.

On the broader issue, I agree that terminology changes alone will not solve governance gaps. However, reducing overlap between a FedRAMP designation and an agency ATO is still directionally helpful. It may not fix agency behavior on its own, but it does remove a longstanding source of confusion.

Regarding naming, I would keep “Level” as the construct, but numeric overlap with DISA Impact Levels is likely to create procurement confusion. Using Roman numerals or letters instead of Arabic numbers would reduce that risk without fundamentally changing the model.

[jerome-miastkowski]

We Support Explicit Impact-Level Equivalency Statement in Marketplace Listings

We understand that the underlying NIST SP 800-53 baselines are not changing as part of this transition. However, the RFC should more clearly and explicitly state that the new Certified and Validated levels do not alter the underlying impact-level control expectations.

For agencies, primes, and compliance reviewers evaluating services in the FedRAMP Marketplace, the most important signal is the impact level alignment. If a service supports a Moderate impact authorization decision, that must mean the same Moderate baseline expectations that have historically applied under SP 800-53.

A Moderate must remain a Moderate. A Low must remain a Low. A High must remain a High.

To prevent confusion in procurement and compliance reviews, we recommend that FedRAMP include an explicit statement in both the RFC and Marketplace listings such as:

“FedRAMP Certified and FedRAMP Validated designations do not modify or replace the underlying NIST SP 800-53 impact-level baselines. Where a service supports a Low, Moderate, or High impact authorization decision, it reflects alignment to the corresponding established NIST baseline. The pathway (Rev5 or 20x) reflects assessment methodology, not a change in required control expectations.”

Including this clarification directly in Marketplace descriptions would ensure that stakeholders evaluating a service do not question whether the authorization meets the same baseline expectations historically associated with Low, Moderate, or High impact systems.

[TBailey223]

Having discussions with customers on this RFC and others. Has the PMO given any thought to the perception / optics of FedRAMP Certified vs. FedRAMP Validated, where agencies may interpret "Certified" as more robust than "Validated" or vice versa?

[jerome-miastkowski]

Adding to this comment, there is already confusion around the perception of “FedRAMP Certified” versus “FedRAMP Validated.” Regardless of intent, agencies may interpret one as more rigorous than the other. In real acquisition environments, those optics matter.

This is why we support simplifying the designation structure and keeping the focus on impact level. The pathway should not create perceived hierarchy or ambiguity. A Low must remain a Low. A Moderate must remain a Moderate. A High must remain a High.

To eliminate confusion, we recommend FedRAMP include explicit language such as:

“FedRAMP Certified and FedRAMP Validated designations do not modify or replace the underlying NIST SP 800-53 impact-level baselines. Where a service supports a Low, Moderate, or High impact authorization decision, it reflects alignment to the corresponding established NIST baseline. The pathway (Rev5 or 20x) reflects assessment methodology, not a change in required control expectations.”

Clear, consistent anchoring to impact level will reduce misinterpretation in procurement and compliance discussions.

[vedigaurav]

Gap #1
Relevant Requirements: Introduction of numeric FedRAMP Authorization Designation levels.
Issue: Numeric levels are not tied to how agencies should use them in ATO decision-making, creating risk of inconsistent or incorrect interpretation.
Recommendation: Provide explicit agency guidance on how designation levels should (and should not) be used in authorization decisions.

Gap #2
Relevant Requirements: Automatic mapping of existing authorizations to new designations and levels.
Issue: Mapping criteria are not defined, risking subjective or inconsistent level assignments for legacy authorizations.
Recommendation: Publish objective mapping criteria and examples for each designation level.

Gap #3
Relevant Requirements: Designation levels reflect assessment completeness at a point in time.
Issue: No process is defined for level progression or regression over the system lifecycle.
Recommendation: Define clear rules and triggers for moving between levels based on new assessments or evidence.

Gap #4
Relevant Requirements: Replacement of FIPS 199 impact language with numeric designation levels.
Issue: The RFC does not explain how numeric levels align with existing FIPS 199 and NIST RMF requirements used by agencies.
Recommendation: Provide a formal mapping between numeric levels and FIPS 199 impact categories.

Gap #5
Relevant Requirements: Immediate transition to new designations in the FedRAMP Marketplace.
Issue: No transition or communication plan is described for CSPs or agencies.
Recommendation: Publish a transition plan including timelines, notifications, and correction mechanisms.

Gap #6
Relevant Requirements: Designation levels rely on qualitative descriptors (e.g., “significant amount”).
Issue: Qualitative language may reintroduce subjectivity and inconsistent interpretation.
Recommendation: Supplement descriptors with measurable thresholds or objective criteria.

Gap #7
Relevant Requirements: Numeric levels are intended to represent assessment completeness, not security posture.
Issue: Levels may still be misused as security rankings by procurement officials.
Recommendation: Add clear disclaimers and acquisition guidance to prevent misuse of designation levels.

[cb-axon]

Gap 1 – I disagree with the premise but agree additional guidance would help. The numeric levels are inherently tied to how agencies will use them in ATO decision-making. A Level 6 designation will naturally be viewed as more robust than a Level 3. That said, agency guidance on how to perform independent due diligence—and how to diverge from a Marketplace designation where appropriate—would be useful.

Gap 2 – I disagree. The mapping is already clear: Rev5 Moderate maps to Level 3 and Rev5 High maps to Level 5, with Levels 4 and 6 tied to implementation of Balance Improvement Releases. The structure does not appear ambiguous.

Gap 4 – I disagree. The RFC already reflects alignment through the mapping described above. The numeric levels do not replace FIPS 199; they layer on top of the existing impact categories.

Gap 5 – I do not see a detailed transition plan as strictly necessary. The RFC explains that legacy Rev5 authorizations will be mapped into the new structure. The underlying history remains publicly accessible for anyone who needs to reference prior designations.

Gap 6 – I disagree with the recommendation to over-specify measurable thresholds. Some level of qualitative judgment is inherent and appropriate. It is not realistic to define objective depth metrics across vastly different system architectures and control implementations. Flexibility allows the designation to account for real-world variation. For example, one CSO may implement encryption across three core services, while another may implement it across hundreds of distributed services; defining a uniform “depth” threshold that applies equally to both environments would be impractical, potentially misleading, and lacking nuance that is important in evaluating security.

Gap 7 – I disagree. Completeness and depth of assessment do carry security implications. Higher levels do provide additional assurance, and it is reasonable for agencies to consider that as part of their evaluation.

[kcarr91]

General Concern About FedRAMP Certified (Rev5) Timing:
If FedRAMP "rev 5" is being phased out, we should retain the current Low, Moderate, and High designations. Introducing new terminology now will only create confusion during the transition period. By the time the market fully adjusts, everyone should be migrating to 20x anyway.

If the sole change is terminology, simply update the wording from "FedRAMP Authorized" to "FedRAMP Certified" (e.g., "FedRAMP High Certified") without introducing numbered levels.

If FedRAMP proceeds with new certification levels:
The framework should include only four levels, mapping directly to Li-SaaS, Low, Moderate, and High. So that FedRAMP High would map to Certified Level 4, being the max level.

1. Decouple Rev 5 Balanced Improvement Releases (BiR) from certification levels. Instead, establish clear completion deadlines for BiR implementation independent of certification status.
2. BiR implementation requires active agency customer acceptance. CSPs should not be penalized when their customers decline to adopt optional BiR items.
3. Learn from DoD's experience. The Department of Defense has addressed similar issues, note the absence of Impact Levels 1 and 3, and how CMMC evolved from five levels (v1.0) to three levels (v2.0) specifically to reduce confusion.
4. Define "met nearly all recommendations" explicitly. This phrase requires clear, measurable criteria.
5. Reconsider the "no corrective action" requirement. If the PMO want’s Corrective Action Plans (CAPs) to have a greater impact on CSPs consider instead displaying CAPs from the past year on the CSO FedRAMP Marketplace listing for transparency.

Regarding the Motivation Section:
The RFC states that federal employees often mistakenly believe they can use any FedRAMP "authorized" cloud service without agency oversight, and that agency security officials may take inappropriate risks by assuming FedRAMP or other agencies oversee security on their behalf.

Renaming authorizations to "Level X FedRAMP Certified" will not address this misconception. This is fundamentally a training and education issue that requires targeted interventions beyond terminology changes.

Related Recommendation:
This issue reinforces a point I've stated previously: Appendix K (FIPS 199 categorization) in the FedRAMP SSP should be removed or updated to better clarify that each agency customer must complete their own Categorize Step per the NIST Risk Management Framework. It should be much more “in your face” than the current note in the template.

I have had to explain to government customers that my Appendix K FIPS 199 categorization is not one for one applicable to their specific use case and that they must conduct their own system categorization.

[cb-axon]

I respectfully disagree with the recommendation to retain only Low/Moderate/High or to simply relabel “Authorized” as “Certified” without structural change. The confusion between FedRAMP authorization and an agency ATO is real, and clearer designation boundaries are a reasonable step toward reducing that ambiguity.

While Rev5 may eventually phase out, introducing the new structure now helps normalize the separation of responsibilities ahead of full 20x adoption. More differentiation was also part of the broader modernization effort. Levels beyond the traditional impact categories provide a mechanism to reflect assessment maturity and program improvements. The solution is to ensure the criteria are clear—not to eliminate differentiation entirely.

I agree that training and education remain necessary, but terminology does matter. Reducing overlap in how “authorization” is used can meaningfully improve understanding in acquisition and operational contexts.

On Appendix K, I do support stronger emphasis that agencies must conduct their own Categorize step under RMF. That clarification would be beneficial regardless of the final designation model.

[Femi2026]

We strongly support the transition to a number-based level system, which better reflects assessment depth and aligns with DISA’s mission and operational needs.
We recommend that RFC-0020 explicitly recognize DISA Impact Level 4 (IL4) authorized services as strong candidates for FedRAMP Certified Level 4, based on demonstrated assessment rigor and sustained operational performance. Services that have undergone the DISA “FedRAMP+” evaluation and meet DISA IL4 separation and boundary requirements provide the type of increased coverage and depth of assessment materials that Level 4 is intended to represent.
Formally acknowledging DISA IL4 authorization as supporting evidence for Level 4 designation would align with the marketplace transparency goals of RFC-0021 and encourage mature, sponsorless Rev5 certifications as described in RFC-0023, while preserving agency Authorizing Official decision authority.
This approach would significantly reduce duplicative assessment effort for DoD agencies seeking DISA IL4 capable solutions, improve reuse efficiency, and better reflect real-world operational risk maturity without creating confusion around authorization responsibility.

[cb-axon]

agree that DISA alignment should be addressed in this RFC, particularly where services have undergone additional evaluation beyond baseline FedRAMP requirements.

However, any mapping should account for the underlying FedRAMP impact level. A FedRAMP High system with DISA IL4 authorization reflects a different control set and assessment rigor than a FedRAMP Moderate system with DISA IL4. Those distinctions should not be collapsed into a single equivalency.

If reciprocity or recognition is formalized, the mapping should clearly differentiate Moderate+IL4 from High+IL4 to accurately reflect control scope and assessment depth.

[Max-sudo-hub]

• Rev 5 Certified Levels suggestion to simplify | Certified Level 3 and Certified Level 3+ (plus). The Plus designator should be for BIR and it helps consolidate the levels down to 5 (norm) versus 6 (no one has 6 levels in the industry).
• Too many levels will confuse people a lot, Here are levels from other schemes: Common Criteria had 7 Levels, CMMI has 5, CMMC had 5 but now 3, DISA IL effectively has 4. FedRAMP should have 3 to 5 as the range but not 6. UK has Cyber Essentials and Cyber Essentials Plus
• Add "Ready" status on the Historical Table for mapping purposes due to its planned sunset
• Decoupling a Certification from formal AO Driven Attestations, Authorization is a good move.
• Recognizing & Reconciliation against DISA Impact Levels would be magical
• Recognizing & Reconciling STIGs and CCIs within the proposed levels would be super magical & the greatest cyber regulatory hack one could pull

[cb-axon]

• I am not strongly opinionated on whether the structure uses a “+” model or six distinct levels. However, I do not believe other frameworks (e.g., Common Criteria, CMMC) should dictate FedRAMP’s structure. Those programs serve different purposes and operate under different risk models. While DISA alignment is more relevant, even DISA and FedCiv environments have differing risk tolerances.
• I do not support mapping “Ready” to any Certified level. Ready status is not an evidence-submission assessment and should not be conflated with certification depth.
• I do agree that decoupling certification from formal AO authorization language is a positive change.
• Formalized DISA reciprocity would be beneficial if clearly defined.
• I do not believe STIGs or CCIs belong in the level mapping construct. They are implementation guidance artifacts, not universal control baselines, and do not apply uniformly across all cloud service architectures.

[john-allison]

Observations.

1. Six levels is too many. It may be time to rethink even the number of current authorization levels, and see if reducing that would be in the best interest of the government and industry.
2. The names, Level 1, Level 2, should be replaced with their authorization level. So you should be certified moderate and then obtain a moderate authorization from a federal agency.
3. It would be good to formalize a certification level and authorization level that will incorporate DoD Impact Levels. Get FedRAMP and DISA to agree on a single standard for the CSPs, and have it clean versus SSP addendums and so forth. This would justify the additional certification levels if the additional DISA controls is excessive.

With the DoD/DoW placing a priority on speed and innovation, they will need to leverage compliant commercial cloud extensively. The ability to go through a sponsorless certification process is a no-brainer compared to deploying the app inside a DoD/DoW cloud, if the addressable market is there for the right scale.

[cb-axon]

I agree that clearer DISA reciprocity would be valuable. Formal alignment or defined mappings between FedRAMP designations and DoD Impact Levels would improve reuse and reduce duplicative assessment effort, provided the differences in underlying baselines and risk tolerances remain transparent.

[JustAnother3PAO]

I'm only here because of Pete's engagement farming post on LinkedIN last night.
I like the distinction between certified and validated. I do NOT like the number scale or the arbitrary definitions at each level.
Reminds me too much of the difference between "Secret" and "Top Secret", significant versus catastrophic or "grave harm."
I would split this out into three criteria per system:

1. "Validated" or "Certified"
2. Baseline level (Low, Moderate, High)
3. [EDIT] Enhancement score that will be shown on FR Marketplace for each CSP

So for example, Wayne Enterprises holds a "Validated High 80" on their CSO BatGadgetsGov. But their competitor, Queen Consolidated holds a "Validated Moderate 90" on their CSO Arrows'R'Us GovCloud.

[adamlang-1kosmos]

I have a question about your comment in the General Discussion if you would be interested.
#115 (comment)

[cb-axon]

I agree with the distinction between “Certified” and “Validated,” but I do not support introducing an enhancement score.

A numeric score risks oversimplifying complex security posture into a single metric. That would inevitably influence procurement decisions in a way that goes beyond providing information and begins to approximate centralized risk scoring.

Scoring models are also highly gameable and inherently lack nuance. If the goal is to provide agencies with sufficient information—not to make ATO decisions on their behalf—then publishing granular scores would likely create more distortion than value. The proposed level system makes more sense in that it proposes higher levels based on the AMOUNT of information and depth.

There are more foundational issues to address in the program before layering on a scoring construct of this kind.

[mjschroeder1]

I do not support point 3 regarding a scoring model.

[mjschroeder1]

Mostly adding support to these sentiments which were more thoroughly framed in other comments:

• Certified/Validated is a strong distinction and the definitions are robust and clear.

• Decoupling from FIPS 199 and replacing with numeric levels adds confusion, especially to agency business owners and risk assessment/acceptance teams.

• Use an addendum to indicate alignment to BIRs. Moderate+/High+ or Enhanced Moderate/Enhanced High.
  If numeric level structure is the way, six distinct categorizations is too many. Use an addendum to indicate alignment to BIR, not a distinct category.

• Initially, the less-than-specific size descriptors in the Level description tables did not quite make sense. Following FR stakeholder explanations on a recent FedRAMP CWG, I understood how clear and common-sense this language is. There should be a similar 'explainer' associated to this table, because the clarity feels abstract from standard.

• The following is an outstanding addition to the language, that can be utilized by FedRAMP practitioners to help executive stakeholders make risk and posture decisions:
  "FedRAMP Certification/Validation levels do not indicate the security of the cloud service overall! These levels only indicate the coverage and depth of the assessment materials available to agencies via FedRAMP."

[cb-axon]

I agree that the Certified vs. Validated distinction is strong and well-articulated.

I do not agree that numeric levels inherently add confusion. The RFC clearly maps the levels back to the existing FIPS 199 baselines, so the underlying impact categories remain intact. While there may be an initial learning curve, that is manageable and not a structural flaw.

I also do not support moving BIR alignment to a separate addendum construct. If differentiation is the goal, it should be clearly visible in the primary designation. Relegating that information to a separate label risks making maturity signals harder to find and less transparent.

I strongly agree that the clarification language—stating that levels reflect assessment coverage and depth, not overall security—should be consistently displayed wherever the levels are presented.

[TrevorLowing]

Feedback: FedRAMP Authorization Designations (Level 1-6)

Thank you for RFC-0020 proposing authorization level nomenclature (Levels 1–6) to decouple FedRAMP authorization designations from federal impact categorization (FIPS 199 or successor). I support this modernization. My review confirms RFC-0020 is FISMA-compliant and does not create statutory conflicts.

Summary: Compliance Assessment

✅ FISMA Compliant: RFC-0020 does not conflict with FISMA (44 U.S.C. § 3544) requirements. Agency AOs retain full authorization authority; RFC-0020 only changes nomenclature and decouples FedRAMP authorization levels from agency categorization decisions.

✅ FAR Compliant: FAR Part 39 (cloud services procurement) requirements unchanged; CSPs must still meet federal security standards. RFC-0020 aligns with FAR 2.0 modernization efforts to simplify and standardize procurement processes.

✅ OMB M-24-15 Aligned: Supports modernization intent; removes false equivalence between FedRAMP levels and FIPS 199 impact categories.

---

Implementation Support Areas

Area #1: Procurement Language Updates (FAR Part 39 Contracts & FAR 2.0 Alignment)

Issue: Federal agencies use RFQs that reference FedRAMP Low/Moderate/High levels. RFC-0020 changes this to Levels 1–6.

What Agencies Need:
Agencies need updated procurement language templates for contracts to specify required authorization levels. Suggest FedRAMP PMO provide:

1. Updated GSA Schedule language (for GSA IT Schedule sellers)

   • Old: "Must hold FedRAMP High authorization"
   • New: "Must hold FedRAMP Level 5 authorization" (or equivalent)

2. Sample RFQ language for agencies procuring FedRAMP services:

   Required: FedRAMP authorization at _____ level
   (Suggest offering: Levels 3, 4, 5, or 6)
   

3. Obsolescence guidance: When do agencies stop accepting Low/Moderate/High designations? (Suggest: Dec 31, 2027 for Rev5, immediate for 20x)

Recommendation: FedRAMP should develop and publish (in parallel with RFC-0020 implementation) a "Procurement Language Modernization Guide" showing pre/post RFC-0020 contract language.

---

Area #2: Transition Timeline Clarity

Issue: RFC-0020 changes FedRAMP Marketplace listings from Low/Moderate/High to Levels 1–6. Agencies and CSPs need a clear transition period.

Questions for PMO Clarity:

1. Marketplace dual-listing period: Will FedRAMP show both old and new designations for a transition period (e.g., 6 months), or hard cutover to Levels 1–6?
2. Existing authorizations: Do Rev5 authorizations already issued (as Low/Moderate/High) get relabeled to Levels 1–6, or keep old nomenclature until renewal?
3. Customer communication: Should CSPs on Marketplace notify federal customers before nomenclature change?

Recommendation: Publish transition timeline showing:

• RFC-0020 effective date (when Levels 1–6 become required for new authorizations)
• Marketplace migration date (when old Low/Moderate/High listings transition to Levels 1–6)
• Dual-display period (if any)
• Mandatory cutover date for existing Rev5 CSPs

---

Area #3: Nomenclature Mapping (Current vs Proposed)

Issue: RFC-0020 introduces Levels 1-6, but agencies already track multiple overlapping labels. Without a clear crosswalk, this creates a confusing triple or quadruple mapping between:

• FedRAMP authorization labels (Low/Moderate/High)
• Proposed FedRAMP Levels (1-6)
• FIPS 199 impact categories (Low/Moderate/High)
• NIST SP 800-53 baselines (Low/Moderate/High, and versioned)

Why This Matters: AOs, contracting officers, and CSPs will need to translate among these terms for RFQs, ATO decisions, and Marketplace listings. If the crosswalk is not explicit, agencies risk mixing authorization designations with impact categorizations.

Recommendation: Publish a one-page crosswalk table and use it consistently across guidance, Marketplace listings, and procurement templates. Example format:

Current FedRAMP	Proposed Level	FIPS 199 Impact	NIST 800-53 Baseline
Low	Level 2	Low	Low (r5)
Moderate	Level 4	Moderate	Moderate (r5)
High	Level 6	High	High (r5)

Include a note that FIPS 199 impact category remains an agency decision, while FedRAMP Levels represent authorization designations based on standardized baselines.

---

Area #4: AO Tooling & Guidance for Decoupling Decision

Problem: RFC-0020 says FedRAMP level ≠ agency impact category. But AOs need guidance on when to accept a lower FedRAMP level for a higher-impact system (if ever acceptable).

Example Scenario:

• System: High-impact federal database (FIPS 199 High)
• CSP offering: FedRAMP Level 3 authorization
• AO decision: "Can we authorize this system?"

Current RFC-0020 Gaps:
The RFC says AOs can now decouple FedRAMP authorization level from impact category, but doesn't provide decision framework for AOs to evaluate "is Level 3 sufficient for a High-impact system?"

Agency Contexxt Feedback:
AOs need decision criteria, not just permission to decouple. Recommend PMO provide:

1. Control gap analysis templates:

   • "System requires X controls per NIST SP 800-53 for High impact"
   • "FedRAMP Level 3 provides Y controls"
   • "Gap: Z controls must be accepted as agency-provided or system-specific"

2. Risk acceptance guidance:

   • When is it acceptable to accept FedRAMP Level 3 for High-impact system? (Risk-dependent; PMO can't answer, but AOs need framework)
   • Recommend reference to NIST SP 800-37r2 Authorize phase risk framework

3. Documentation requirements:

   • AO must document "why Level 3 is sufficient" in ATO memo (standard practice; no change to RFC-0020, but should be stated)

Recommendation:
Create "RFC-0020 AO Decision Framework" showing:

• Risk assessment process (NIST RMF Authorize phase)
• Control gap analysis
• Risk acceptance documentation
• Examples (Low/Moderate/High impact × various FedRAMP levels)

---

Area #5: Control Baseline Clarity Needed

Issue: RFC-0020 Levels map to NIST SP 800-53 control baselines. But baselines are not static—NIST may update SP 800-53r6 or beyond.

Question for PMO:
If NIST updates baseline controls mid-year, do FedRAMP Levels 1–6 automatically update, or are they "locked" to a specific NIST version?

Example concern:

• RFC-0020 ties Level 4 to NIST SP 800-53 Moderate baseline
• Jan 2027: NIST publishes SP 800-53r6 with expanded controls
• Does Level 4 now mean "new r6 Moderate baseline" or "old r5 Moderate baseline"?

Recommendation:
RFC-0020 implementation guidance should specify:

• Levels are tied to NIST SP 800-53 version: "Level 4 = NIST SP 800-53r5 Moderate baseline" (with version in Marketplace listing)
• If NIST publishes SP 800-53r6: FedRAMP determines if Levels remain tied to r5 (backward compatibility) or update to r6 (requires re-assessment)
• Transition guidance: Timeline for CSPs to update assessments if baseline changes

---

Testing Recommendation: Pilot with GSA IT Schedule

Suggestion:
FedRAMP should work with GSA to pilot RFC-0020 Levels 1–6 nomenclature on GSA IT Schedule before full Marketplace rollout.

• GSA IT Schedule already requires FedRAMP (good test population)
• Agencies can evaluate procurement language changes in real contracts
• Can validate that AOs understand decoupling concept

Timeline: Pilot with ~50 GSA Schedule IT services (March–June 2026), then roll out to full Marketplace (July–Sept 2026).

---

Closing

RFC-0020 is legally sound and operationally beneficial. Decoupling FedRAMP levels from impact categories gives AOs necessary flexibility while maintaining NIST baseline rigor. I recommend focusing implementation effort on:

1. ✅ Procurement language updates (GSA Schedule + agency RFQs)
2. ✅ Transition timeline clarity (Marketplace migration, dual-display period)
3. ✅ Nomenclature mapping crosswalk (current vs proposed labels)
4. ✅ AO decision framework (control gap analysis, risk acceptance documentation)
5. ✅ NIST baseline version control (locked versioning vs. auto-update)

I am willing to support GSA pilot testing in a personal capacity if FedRAMP seeks public input.

Submitted by: Trevor Lowing (private citizen, personal capacity)
Contact: Trevor.Lowing@gmail.com
Disclaimer: The views expressed are my own.

[mjschroeder1]

Adding support to the Area 5 commentary especially.

[cb-axon]

Area 2 – I agree that additional transition clarity would be helpful. That said, the RFC appears to contemplate an administrative relabeling on the Marketplace rather than requiring CSP action for initial mapping. Aside from potential Level 4/6 considerations, this is largely a PMO-side change, so a “mandatory cutover” would effectively occur when FedRAMP updates the Marketplace.

Area 3 – I do not find the mapping particularly confusing, though a simple crosswalk may help some stakeholders. It is important to note that NIST SP 800-53 Low/Moderate/High baselines have never been a perfect one-to-one mapping with FedRAMP designations (as there are FedRAMP-specific layers added onto it), so some abstraction has always existed.

Area 4 – I believe this section may be framed backward. The practical use case is often the reverse: an agency categorizes its data at FIPS 199 Moderate and procures a service that is FedRAMP High (Level 5). The agency does not need to issue a High ATO simply because the CSP holds a higher FedRAMP designation. The real governance issue has historically been agencies adopting CSP categorizations wholesale, rather than conducting their own Categorize step.

Area 5 – I do not see baseline versioning as ambiguous at this time. FedRAMP is currently anchored to SP 800-53 Rev5. If and when Rev6 is issued, that will require a broader transition plan similar to the Rev4 to Rev5 shift (which took years). It is premature to define mechanics for a revision that does not yet exist. If and when Rev6 is adopted, it is reasonable to expect FedRAMP would update or introduce new KSIs in 20x that map to the revised control set, rather than automatically redefining existing levels midstream.

[mjschroeder1]

Area 4 – I believe this section may be framed backward. The practical use case is often the reverse: an agency categorizes its data at FIPS 199 Moderate and procures a service that is FedRAMP High (Level 5). The agency does not need to issue a High ATO simply because the CSP holds a higher FedRAMP designation. The real governance issue has historically been agencies adopting CSP categorizations wholesale, rather than conducting their own Categorize step.

Adding my insight to this part of the discourse.
In my experience previously in an agency environment, there can be a decoupling in both directions, and they both should be addressed clearly by outputs of this RFC.

When agencies are seeking a cloud tool, it's common to have a small use-case and the request comes via a focused team, within an organization, within an administration, within the agency. That just needs this cloud tool to do their job. They may or may not have insight into all the agency governance structure that leads to input on an authorization package - let alone whatever FedRAMP is.
Agency product owners can often find themselves with either a Moderate Data Security Impact use case and a Low (or Li-SaaS) system contracted for the service.

The direction you describe here, using a High system for a Moderate use case, can often lead to confusion among risk review teams and Authorizing Officials, who have diverse responsibilities, often aligning much more thoroughly to non-cloud delivery models than to FedRAMP nuances. There have been scenarios where the lack of clarity of an AO based on this type of decoupling have introduced months of delay to Authorization outcomes.

I agree there needs to be clarification, good points made here.

[jerome-miastkowski]

Area #3 - We Support A Clear Nomenclature Crosswalk

As FedRAMP transitions to new Level 1–6 designations, it is critical that agencies and industry are not left translating between multiple overlapping terms without a clear reference point. Today, stakeholders already work across FedRAMP authorization labels, FIPS 199 impact categories, and NIST SP 800-53 baselines. Adding numbered Levels without an explicit crosswalk increases the risk of misinterpretation in RFQs, ATO decisions, and Marketplace evaluations.

A simple, standardized crosswalk table would materially reduce confusion and ensure consistent understanding across agencies and CSPs.

Most importantly, the crosswalk should clearly reinforce that FIPS 199 impact categories and their corresponding NIST baselines remain unchanged. The FedRAMP Level should reflect the authorization designation and assessment pathway - not redefine or fragment the underlying Low, Moderate, or High baseline expectations.

Making this mapping explicit will help ensure that a Low remains a Low, a Moderate remains a Moderate, and a High remains a High, regardless of nomenclature changes.

[jerome-miastkowski]

Area #5 - Control Baseline Versioning Must Be Explicit

RFC-0020 should clearly state that each FedRAMP Level is tied to the current published revision of NIST SP 800-53 at the time of authorization.

To prevent ambiguity as standards evolve, we recommend explicit language such as:

“Each FedRAMP Level is aligned to the current published revision of NIST SP 800-53 at the time of authorization. When NIST publishes a new revision of SP 800-53, Cloud Service Providers have 12 months from the NIST publication date to implement and demonstrate alignment to the updated baseline.”

Without this clarity, agencies and CSPs will not know whether a Level designation reflects an outdated control baseline or the current one. A defined 12-month transition window provides predictability, ensures alignment with evolving federal standards, and prevents indefinite lag between NIST updates and FedRAMP implementation.

Clear version anchoring and a fixed transition timeline are essential to maintaining trust and consistency in the FedRAMP Marketplace.

For anyone that thinks 12-months isn't long enough, you are not going to like migrating to 20x...

[cb-axon]

Overall, I support the intent of clarifying designations and separating FedRAMP from agency ATO language. That said, a few concerns stand out.

• The numeric Levels 1–6 create likely confusion with DISA Impact Levels (IL2, IL4, IL5, IL6). In procurement conversations, “Level 5” could easily be misinterpreted as either FedRAMP Level 5 or DISA IL5. That ambiguity should be addressed proactively, either through naming adjustments or clear acquisition guidance.
• Separately, a formal reciprocity crosswalk with DISA should be included. Any alignment should account for differences in underlying FedRAMP impact levels (e.g., Moderate+IL4 vs High+IL4 vs High+IL5), rather than treating IL4 as a flat equivalency. It should also recognize where reciprocity already exists (e.g., Moderate often aligning with IL2) to avoid unnecessary duplication.
• Balance Improvement Releases should only factor into higher levels if they are mandatory and generally available. Some CSPs cannot implement optional items (e.g., SCN-related changes) because agency customers must approve them. CSPs should not be disadvantaged in designation level due to agency-imposed constraints.

On a positive note, I have strong support for publishing target assessment completion timelines. Clear performance targets and turnaround metrics help both agencies and CSPs plan effectively and hold the process accountable. 🎯👏

[wisecryptic]

my assumption is that the memorandum of reciprocity still stands for an IL2/FedRAMP Moderate and equivalent. It would be good to get clarification if that extends to a 20x equivalent as well.
as a matter of note, the CC SRG has a nice table to show FR mod v high il4 v il5.
FedRAMP could redirect to these links from their website to avoid confusion.

[CSP-AB]

The Cloud Service Providers - Advisory Board submits the following comments.

Motivation - a FedRAMP authorization at a given traditional NIST FIPS 199 securityobjective (Low, Moderate, High) does not necessarily align with the security objective of an agency information system that reuses that FedRAMP authorization.

• Deviating from the FIPS categorization scheme will create confusion for agencies that are still subject to FISMA and the NIST 800-53 Rev.5 controls which include multiple references to FIPS. This would create a deviation from FISMA and also be unnecessarily confusing.

Rev5 Certified Levels

• FedRAMP states that the proposed levels "only indicate the coverage and depth of the assessment
  materials available to agencies via FedRAMP." However, this is not the case for Levels 4 and 6, which differ from Levels 3 and
  5 respectively by measuring outcomes instead of the coverage/depth of the assessment materials available to the agencies. Suggest changing this justification and also collapsing the levels so that Level 4 becomes Level 3+ and current Level 6 becomes Level 4+--
  reflecting that both of those levels measure an accomplishment above and beyond the amount of material available.

• If Rev5 will be going away within the near future, this seems like a significant and widespread change that will have effects throughout security and contracting that will take years to implement and understand for marginal security benefit. We recommend not changing Rev5 designations or modifying the existing ones to incentivize the move to balance improvement releases.

• These certification levels are difficult to discern for both industry and the government customer. Additionally, Levels 1-6 naming is going to collide with DISA's Impact Levels (IL2, IL4, IL5, IL6) in procurement and security conversations. They mean completely different things, but program offices often conflate FedRAMP and DISA requirements already. Trying to imagine what a FedRAMP Level 4, IL-2 offering looks like is going to be even more confusing and difficult to explain to non-experts of either (or both) FedRAMP Levels or DISA Impact Levels.

• It is not clear what the material difference between a Certification Package being adequate in "many cases" vs. "almost every case". The community will need to understand that difference and how it will be measured.

Certified Level 4

• This language in Level 4 and Level is conceptually distinct from the guidance outlined above: "These levels only indicate the coverage and depth of the assessment materials available to agencies via FedRAMP." Rather, Levels 4 and 6 differ from Levels 3 and 5
  respectively only in measuring implementation of Balance Improvement Releases and absences of corrective actions--neither of these pertain to the coverage or depth of the assessment materials available.

Certified Level 6: This level also means that the cloud service provider has implemented all Rev5 Balance Improvement Releases and met nearly all recommendations from FedRAMP with no corrective action for the past year.

• Suggest changing the verbiage to "mandatory" balance improvement releases. Some CSPs won't be able to do optional releases because some agencies do not permit this due to their internal requirements, like SCN.

• What is the material difference between a Certification Package being adequate in "many cases" vs. "almost every case". How will that be measured?

Marketplace Lifecycle for Rev5: The target time for this step is less than 30 days if the package is truly complete.

• We are HIGHLY supportive of these target times being published and encourage the FedRAMP PMO to continue this type of transparency and accountability.

20x Validated Levels

• We are concerned that these levels will be confused with DoD CSP SRG Impact Levels 2/4/5/6. Recommend sticking with Pilot, Low, Moderate, and High for 20x to limit confusion in the marketplace. This will also provide clarity to stakeholders regarding CSPs that have multiple offerings serving both DoD and federal customers.

[drewmk]

The current 1-6 level structure directly conflicts with DISA’s Impact Levels and lacks a clear framework for equivalency. To ensure clarity and utility, Rev5 certified levels should maintain parity with existing governmental standards.

While the rationale for Validated levels is clear, the transition from Validated to Certified remains problematic without an Authority to Operate (ATO). As the preference for Certified status consistently outweighs Validated levels, any interim stages offer limited value to companies pursuing authorization.

Currently, MaintainX has a package prepared for agency review; however, we are unable to proceed due to the lack of a clear authorization path. We suggest establishing recognizable equivalencies from the upper Validated levels to lower Certified levels to facilitate this process for providers.

[PTrier-Indie]

I agree with the representative from GovRAMP's opinions fully. I want to also state that RFC's language is misleading and burying the lead on the impact of RFC-0020. This RFC should be kicked back and broken up into 2-3 proposals. A lot of the feedback is good but we are peeling the onion instead of remember we came for an apple.

The title and summary make it seem like this is just about changing verbage however This RFC does two other things:

1. Adds two new levels/categorizations for FedRAMP by making it 6 levels.
2. Strengthens FedRAMP 20x by allowing people to shorthand say they are "FedRAMP Validated". We will see the same issues people run into with "FIPS 140-3 compliant" and "Ready Moderate".

In its current state I see it as a boon for 20X CSPs and their sales teams but harmful and confusing to established Rev 5 CSPs or newcomers that can't afford a FedRAMP build and a real advisor to help them navigate these changes.

[fortetroy]

Posting Comments on Behalf of Fortreum, LLC

https://fortreum.com/

---

General Comment – FedRAMP Certified (Rev5)

These levels, while intending to simplify the approach, add additional complexity once the Rev5 Balance Improvement Releases (BIRs) are incorporated at Levels 4 and 6.

For example, if a CSP maintained a FedRAMP Moderate authorization and implemented all BIRs, they would arguably be meeting more FedRAMP requirements at the assigned Level 4 than a FedRAMP High authorized CSP assigned Level 5.

Suggestion

Reduce the levels to 1–4:

1. Li-SaaS
2. Low
3. Moderate
4. High

Add an additional identifier for CSPs meeting all BIRs and having no CAPs for the past year:

• Moderate + all BIRs + no CAPs → Level 3.5
• High + all BIRs + no CAPs → Level 4.5

---

General Comment – FedRAMP Validated (20x)

Similar logic and reasoning as the Rev5 approach applies here.

---

Detailed Comments

---

Comment 1

Section: Motivation, first paragraph

The explanation does not tell the whole story clearly. It states:

“A FedRAMP authorization indicates that FedRAMP has packaged essential security information from a cloud service provider that can be used by an agency to make a determination whether or not to use that service; it is not a decision by an Authorizing Official that the service has been granted an Authorization to Operate (ATO).”

However, a FedRAMP ATO on the Marketplace does indicate that the CSO has been granted an ATO by at least one agency or the JAB. Therefore, at least one agency has authorized it.

This should be clarified. Suggested addition:

Even though a CSO is listed on the Marketplace as having an ATO, each agency AO must review the package and authorize their own agency’s use of that CSO.

---

Comment 2

Section: Motivation, paragraphs two and three

Confusion about what FedRAMP authorization means can be addressed through better education rather than adding more paths. The logic here is not entirely valid.

Adding new paths will likely increase confusion, particularly for those new to FedRAMP who are already trying to understand the distinctions between authorization, certification, and validation.

---

Comment 3

Section: Motivation, paragraph six

The RFC states:

“Therefore, this RFC proposes creating FedRAMP Certified (Rev5) and FedRAMP Validated (20x) designations for FedRAMP authorizations, with each designation having 6 levels of increasingly complex assessment and monitoring requirements.”

However, the document does not later describe any changes to 3PAO assessment requirements or monitoring requirements. It only discusses package completeness requirements.

This should either be clarified or aligned with the stated intent.

---

Comment 4

Section: FedRAMP Certified (Rev 5), first paragraph

Is “FedRAMP Certified” the new agency-less path described in RFC-0023?

If yes:

• Explicitly state that.
• Reference RFC-0023.
• Consider combining the RFCs.
• Use the term “FedRAMP Program Certification” for consistency.

---

Comment 5

Section: FedRAMP Certified (Rev 5), first paragraph

The text states:

“All Rev5 Certified services are FedRAMP authorized.”

If so, consider renaming this to “FedRAMP Program Authorization” to maintain consistency with Agency Authorization terminology.

---

Comment 6

Section: FedRAMP Certified (Rev 5), first paragraph

Do agencies still need to issue their own ATO on top of FedRAMP Program Certification?

Or is this equivalent to a JAB ATO and accepted government-wide?

This distinction should be made explicit.

---

Comment 7

Section: FedRAMP Certified (Rev 5), table

Do the Certification Levels apply:

• To agency ATO packages as well, or
• Only to FedRAMP Program Certification (RFC-0023) packages?

Clarification is needed.

---

Comment 8

Section: FedRAMP Certified (Rev 5), table

Calling these “levels of certification” adds complexity to an already complex process.

If the goal is to indicate completeness:

• Consider a star rating or similar indicator
• Or rename them to “Completeness Levels”
• Or “Quality Levels”

The objective appears to be package completeness, not certification depth.

---

Comment 9

Section: FedRAMP Certified (Rev 5), table

The level structure becomes inconsistent once Rev5 BIRs are incorporated.

Example:

A Moderate CSP that implements all BIRs could meet more FedRAMP requirements at Level 4 than a High CSP assigned Level 5.

Suggested Alternative

Reduce levels to 1–4:

1. Li-SaaS
2. Low
3. Moderate
4. High

Add fractional identifiers:

• Moderate + all BIRs + no CAPs → Level 3.5
• High + all BIRs + no CAPs → Level 4.5

---

Comment 10

Section: FedRAMP Certified (Rev 5), table

Certified Level 5 applies to High systems.

However, RFC 0023 states that FedRAMP Program Certification cannot be used for High packages (see LPC-GEN-LVL “Level Limited” section).

This appears inconsistent.

---

Comment 11

Section: Marketplace Lifecycle for Rev 5

Add the following statuses:

• Agency Authorized
• FedRAMP Program Certified
• FedRAMP Validated

Some of the lifecycle entries appear to be sub-processes rather than statuses.

Suggested structure:

Preparation

• FedRAMP Program Certification in Process
• FedRAMP 20x Validation in Process
• Agency Authorization in Process
• FedRAMP Package Review in Process

Authorized

• Continuous Monitoring in Process
• Remediation in Process

---

Comment 12

Section: Marketplace Lifecycle for Rev 5, item 3

Is “Assessment by FedRAMP”:

• A formal assessment or audit?
• Or a completeness review only?

Will the same review be conducted for Agency ATO packages?

---

Comment 13

Section: Marketplace Lifecycle for Rev 5, item 5

Is “Remediation” equivalent to a Corrective Action Plan (CAP)?

If so, rename this to CAP for clarity.

Also:

Will a CSP be placed in remediation for failing to adhere to newly finalized FedRAMP policies, such as Security Inbox updates?

---

Comment 14

Section: FedRAMP Validated (20x), first paragraph

Stating that a 20x Validated package is “FedRAMP authorized” implies equivalency with Rev 5 packages.

That is not accurate.

Rev 5 and 20x packages do not implement the same control sets or assurance depth. This distinction must be clearer.

---

Comment 15

Section: Marketplace Lifecycle for 20x, table

Similar concerns as the Rev5 lifecycle structure apply here.

---

Comment 16

Section: Marketplace Lifecycle for 20x, item 2

Rev 5 packages cannot be prioritized?

Please clarify.

[jerome-miastkowski]

We Disagree With Comment 14 – Baseline Equivalency and Assurance Model

It is correct that describing a 20x Validated package as “FedRAMP authorized” implies equivalency with Rev5 packages. That implication is appropriate.

20x supports the same FIPS 199 Low, Moderate, and High impact baselines as Rev5 and maps to the same underlying NIST SP 800-53 control expectations. In terms of impact-level security baseline, it is equivalent. The assessment methodology may differ, but the baseline itself does not.

The distinction between Rev5 and 20x is in assessment mechanics and evidence validation - point-in-time certification versus persistent validation - not in the underlying impact-level requirements. A Moderate must remain a Moderate. A Low must remain a Low. A High must remain a High.

Importantly, the 20x model is designed around persistent validation and continuous evidence alignment rather than reliance on a largely static assessment package. A model built on ongoing validation of control implementation provides more current and operationally relevant assurance than a periodic point-in-time review. That represents an evolution in assurance approach - not a reduction in baseline expectations.

Both pathways align to the same NIST baselines and support the same FIPS 199 impact categorizations, so describing both as FedRAMP authorized is accurate and appropriate.

[jerome-miastkowski]

Clarification on Impact Level Equivalency Across Certified and Validated Designations

We support the intent of this RFC to reduce confusion between a FedRAMP authorization and an agency Authorization to Operate (ATO), and to introduce clearer terminology through the “Certified” (Rev5) and “Validated” (20x) designations.

To further reduce confusion, we recommend explicitly clarifying that the introduction of new designations and numbered levels does not alter or redefine the underlying FIPS 199 impact level equivalency of the applicable FedRAMP baseline.

Specifically, the RFC should clearly state that:

• A Low, Moderate, or High impact authorization decision remains tied to the same corresponding FedRAMP baseline expectations, regardless of whether the cloud service is designated as:
  • FedRAMP Certified (Rev5) at the applicable level, or
  • FedRAMP Validated (20x) at the applicable level.
• The distinction between Rev5 and 20x reflects differences in assessment methodology (e.g., point-in-time certification versus persistent validation), packaging of evidence, and monitoring approach - not a change in the underlying impact level baseline.
• The numeric levels describe the coverage, rigor, and completeness of the assessment materials available to agencies, but do not redefine the fundamental security expectations associated with Low, Moderate, or High impact systems.

Absent an explicit statement of equivalency, stakeholders may misinterpret the 20x pathway or the new numeric designations as establishing different or tiered versions of Low, Moderate, or High impact baselines. Clarifying that impact levels remain constant—independent of pathway - would reinforce that these reforms modernize assessment and assurance mechanisms rather than redefine security categorization.

We recommend adding a clarifying statement such as:

“FedRAMP Certified and FedRAMP Validated levels that correspond to Low, Moderate, or High impact support authorization decisions aligned to those same FIPS 199 impact levels. The pathway (Rev5 or 20x) reflects differences in validation methodology and assurance mechanisms - not differences in the underlying impact-level baseline security expectations.”

Making this equivalency explicit would materially reduce confusion across agencies, cloud service providers, and acquisition stakeholders while preserving the clear separation of responsibilities described in this RFC.

[TheVantaCat]

Public Comment on RFC-0021: Expanding the FedRAMP Marketplace

These comments are my own opinions and experiences - not of my employer(s). Meow.

Gap 1 - FedRAMP "levels" are falling into the same "trap" that DoD Cloud SRG did - align to DoD Cloud SRG Impact Levels or leave Low, Moderate, and High alone

The proposed transition from FIPS-199 'Low, Moderate, High' to a numbered 1-6 level system in RFC-0020 represents a significant administrative burden with negligible security benefit.

1. Redundant Frameworks: This proposal creates a Civilian Impact Level system that runs parallel to, but is not harmonized with, the DoD CC SRG. If the PMO wishes to use a numbered system, it should adopt the DoD`s established IL levels to ensure true reciprocity and reduce crosswalk confusion.

2. Contractual Chaos: Removing the 'Moderate' and 'High' designations will invalidate or require updates to nearly every existing federal cloud contract and agency procurement policy, stretching decades back. Is GSA FedRAMP PMO prepared for this?

3. The 'K.I.S.S.' Perspective: FedRAMP should be simplifying the path to authorization, not adding a new nomenclature that requires a decoding ring to understand. Keep the labels that the industry and agencies already use, or go 'all-in' on the DoD SRG. A middle-ground numbered system is the worst of both worlds.

Why?

The proposed 1–6 level system repeats the architectural flaws of the early DoD Cloud SRG. Historically, the DoD attempted to use "intermediate" levels (like IL1 and IL3) to categorize data that didn't fit neatly into Public vs. CUI buckets. This resulted in:

• Operational Confusion: AOs could not clearly distinguish the risk profile.

• Eventual Consolidation: The DoD eventually abandoned these "middle-ground" levels to align with the current IL2, IL4, IL5, and IL6 structure.

FedRAMP should not ignore this history. Creating "Level 4" (Moderate + BIRs) implies a new impact tier that does not exist in FIPS-199 or the current SRG, leading to "Contractual Chaos" for existing federal cloud procurements.

For a history lesson on DoD Cloud SRG Impact Levels over time:
https://disa.mil/-/media/Files/DISA/News/Events/Symposium/Cloud-Computing-Security-Requirements-Guide.ashx

GAP 2: Decoupling System Impact Levels from Documentation Completeness

A "Level" should remain a fixed pointer to the FIPS-199 Impact Level (Low, Moderate, High). The thoroughness of a package—such as the inclusion of Balance Improvement Releases (BIRs) or a clean CAP history—is Metadata about the package.

• The Impact Level: Describes the information protected for the agency (Risk).

• The Package Metadata: Describes how complete the documentation is (Quality).

Instead of a 1–6 level "certification" system, FedRAMP should retain existing standard impact levels and introduce a separate Quality/Completeness Requirements as metadata to the CSP Marketplace entry. These requirements for Quality/Completeness then be rated in the standard Not Implemented, Partically Implemented, and Fully Implemented categories to describe completeness of the certification package and its activities.

Benefits of this approach:

1. Clarity for Agencies: Agencies can immediately see the data boundary (Moderate) without doing math to determine if "Level 4" fits their mission.

2. Granular Search: The Marketplace could allow users to filter by "Impact: High" + "Completeness" criteria.

3. Avoiding "Level Inflation": Mixing these two distinct data points into a single "Level 1–6" scale creates a false hierarchy where a "High" system with standard documentation (Level 5) might appear less "complete" than a "Moderate" system with extra documentation (Level 4), despite the High system having significantly more rigorous security controls.

GAP 3: From "FedRAMP Certified" to "FedRAMP Annual Authorization"

Propose that "FedRAMP Certified" in this RFC be renamed "FedRAMP Annual Authorization."

• Accuracy: "Certified" is a vague term that implies a static trophy. "Annual Authorization" accurately describes the current assessment cadence (the 3PAO annual assessment).

• NIST Alignment: This creates a clear distinction between the Time-Driven (Annual) and Data-Driven (Continuous/20x) authorization models defined in NIST SP 800-37 R2 and other RFCs.

• Transparency: An Agency and its AO can immediately understands the "shelf-life" of the evidence they are reviewing.

GAP 4: From "FedRAMP Validated" to "FedRAMP Continuous Authorization" or "FedRAMP Ongoing Authorization"

Propose that "FedRAMP Validated (20x)" be renamed "FedRAMP Continuous Authorization" or "FedRAMP Ongoing Authorization"

1. Alignment with NIST 800-37 R2 (Ongoing Authorization)

NIST SP 800-37 Rev. 2 defines Ongoing Authorization as a departure from the "static, point-in-time" process. It is a "time-driven or event-driven" authorization that relies on a robust Information Security Continuous Monitoring (ISCM) strategy.

• The 20x Connection: The "20x" methodology is, by definition, an ISCM strategy. It mandates automated, high-frequency data feeds.

• Term Consistency: "Validated" is not a recognized RMF state. "Ongoing Authorization" and "Continuous Authorization" (or cATO in DoD parlance) is a recognized, high-maturity state that AOs already understand.

2. Why "Validated" is the Wrong Word

In the current RFC-0020 draft, "Validated" implies a completion of a review. However, the intent of the 20x path is to move away from "one-off" reviews.

• Validation = Static: Suggests a certificate that sits on a shelf for a year.

• Continuous Authorization = Dynamic: Signals that the authorization is active and contingent on the next data pulse. If the 20x data feed fails or shows high risk, the "Continuous" status is immediately in question.

3. Operational Impact for the Agency

Using Ongoing Authorization or Continuous Authorization provides a clear directive to Agency AOs:

• No Re-Authorization Sprints: Because the system is in a state of Ongoing Authorization, agencies don't need to treat the annual assessment mark as a crisis.

• Trust in Automation: It explicitly tells the AO that the package they are looking at is not a "snapshot from last July," but a living reflection of the current security state.

GAP 6: Decoupling Lifecycle Status from Authorization Type

The current RFC conflates Authorization Methodology with Marketplace Lifecycle. These should be treated as two independent data dimensions. Mixing them creates "status fragmentation" and forces AOs to learn different progress terminologies for different paths.

The Proposed State-Machine Architecture

Recommend a unified set of Lifecycle Statuses that apply to all systems, regardless of whether they are pursuing Annual or Continuous Authorization.

Example:

• Authorization Type (Annual vs. Continuous) is a Methodology.

• Lifecycle Stage (Preparation, Review, Authorized, Continuous Monitoring) is a Status.

Why Decoupling Matters

1. Lifecycle as Marketplace Metadata - The Marketplace listing should reflect the real-time status of the package, regardless of whether the CSP is pursuing an Annual or Continuous authorization. Mixing these creates "Lifecycle Bloat," where the PMO has to define different statuses for different "Levels."

2. Simplified Search: An Agency AO should be able to query the Marketplace for all systems that are Status: Authorized and then sub-filter by Method: Continuous Authorization (20x).

3. Reduced Cognitive Load for Agencies: By standardizing the lifecycle stages, FedRAMP removes the need for stakeholders to "decode" what a status means based on which designation level the CSP has chosen.

[jerome-miastkowski]

Comment On GAP 3 & 4: Authorization Method as a Sub-Category

We support the goal of clearly distinguishing between point-in-time and persistent validation models. However, rather than replacing “Certified” and “Validated” with entirely new primary labels, we recommend retaining a single top-level designation: FedRAMP Authorized.

Both Rev5 and 20x support the same FIPS 199 Low, Moderate, and High impact baselines and align to the same underlying NIST SP 800-53 control expectations. The security outcome at each impact level should remain constant. A Moderate must remain a Moderate. A Low must remain a Low. A High must remain a High.

Instead of separate primary labels, FedRAMP could introduce an Authorization Method sub-category, for example:

• FedRAMP Authorized – Annual
• FedRAMP Authorized – Continuous

This approach preserves baseline equivalency while clearly signaling the assurance model and assessment cadence. It reinforces that the distinction is methodological - not a difference in impact-level control expectations.

Maintaining “FedRAMP Authorized” as the primary designation reduces procurement confusion, avoids tier fragmentation, and keeps the impact level as the central anchor. Adding a clearly defined methodology sub-category provides the necessary clarity without creating parallel or competing authorization labels.

[jerome-miastkowski]

Comment On GAP 1: Preserve Explicit NIST Baseline Anchoring

We support the concern raised in GAP 1 and emphasize the importance of preserving clear and explicit alignment to established NIST impact-level baselines.

FedRAMP impact levels are not branding constructs; they are direct references to defined NIST SP 800-53 control baselines. Those baselines form the foundation for numerous downstream compliance frameworks, including NIST SP 800-171 and other derivative federal programs.

20x and Rev5 support the same FIPS 199 Low, Moderate, and High impact baselines - and align to the same underlying NIST SP 800-53 control expectations - that mapping must remain explicit, visible, and unambiguous in Marketplace listings and guidance materials.

A Moderate must remain clearly and directly tied to the NIST SP 800-53 Moderate baseline. A Low must remain tied to the Low baseline. A High must remain tied to the High baseline.

Introducing a standalone numbered system risks obscuring that anchor unless the RFC clearly states that any new “levels” are supplemental descriptors related to assurance methodology or package completeness — not replacements for, or modifications to, the underlying NIST baseline designation.

Clarity at the impact level is foundational to maintaining consistency and defensibility across the broader federal cybersecurity framework ecosystem. Preserving explicit NIST baseline alignment ensures continuity, reduces interpretive risk, and strengthens confidence in both Rev5 and 20x pathways.

[jerome-miastkowski]

We Support GAP 2 and GAP 6: Structural Clarity and Impact-Level Integrity

We strongly support the structural recommendations outlined in GAP 2 and GAP 6.

GAP 2 correctly identifies that impact level and documentation completeness are distinct concepts and should not be conflated. The FIPS 199 impact level describes the risk posture and the corresponding NIST SP 800-53 control baseline. Documentation completeness, assurance rigor, or implementation maturity are separate attributes. Mixing these dimensions into a single numbered “Level” creates unnecessary hierarchy and interpretive confusion.

A Moderate must remain a Moderate. A Low must remain a Low. A High must remain a High. Completeness or methodology should not alter the meaning of the underlying impact-level baseline.

Similarly, GAP 6 appropriately distinguishes between authorization methodology and lifecycle status. Authorization type (e.g., Annual vs. Continuous) is a methodological choice. Lifecycle stage (e.g., Preparation, Review, Authorized, Continuous Monitoring) is a status indicator. These are independent data dimensions and should be presented as such in the Marketplace.

Decoupling these elements reduces cognitive load for agencies, prevents status fragmentation, and reinforces that the security outcome is anchored to the impact level - not to packaging mechanics or lifecycle labels.

Preserving clear architectural separation between impact level, authorization methodology, and lifecycle status will strengthen clarity, defensibility, and long-term stability across the FedRAMP ecosystem.

[PS-SEC-MSG]

RFC-0020: FedRAMP Authorization Designations (Certified, Validated, and Level System)

I am a FedRAMP-recognized independent assessor. I support the intent of RFC-0020 to reduce confusion between FedRAMP program status and an agency Authorization to Operate (ATO) decision. I also support a consistent Marketplace representation that reduces misinterpretation risk for agencies and providers.

Across the broader RFC discussions, multiple commenters have asked for (1) an authoritative crosswalk between legacy terminology and the new level system, (2) standard claim language to reduce marketing misrepresentation, and (3) clear, objective criteria for any level attributes tied to improvements and corrective-action history. The requests below focus only on RFC-0020.

1. Definitions and triggers for "FedRAMP Certified" (Rev 5) vs "FedRAMP Validated" (20x)

Comment:
RFC-0020 introduces two designations and states that both are "FedRAMP authorized." The definitions are directionally clear, but implementation details are still ambiguous for Marketplace records, artifacts, and public claims.

Proposed clarification:

• Publish a short glossary for Marketplace and public use that defines:
  • FedRAMP Certified (Rev 5) as a point-in-time package reviewed by FedRAMP for completeness against the Rev 5 baseline.
  • FedRAMP Validated (20x) as a persistent validation approach where the validation package is expected to reflect current security posture.
  • "FedRAMP authorized" as a program status that supports, but does not replace, agency ATO decisions.
• Define the trigger events that change status for each designation (for example, what constitutes entry into or exit from Certified or Validated, and what changes the level number).
• Require Marketplace records and public artifacts to display the designation and level together, for example, "FedRAMP Certified Level 3 (Rev 5)" or "FedRAMP Validated Level 3 (20x)," not "FedRAMP Level 3" by itself.

2. Level meaning, crosswalk to legacy constructs, and stability expectations

Comment:
RFC-0020 correctly notes that levels do not indicate overall security. In practice, agencies and acquisition staff will still look for an easy crosswalk to legacy terms (Low, Moderate, High, Li-SaaS) and will rely on Marketplace shorthand during procurement. Multiple commenters have asked for an authoritative mapping and stability rules.

Proposed clarification:

• Publish and maintain an authoritative crosswalk table that maps each designation level to legacy constructs (including Li-SaaS and Low, Moderate, High where applicable). Keep the crosswalk versioned and include an effective date for changes.
• Clarify that the level is a statement about coverage and depth of assessment materials, not an agency system security category, and not a substitute for the RMF Categorize step for an agency system.
• Provide a minimum notice period (for example, 90 days) before changing the crosswalk or level definitions, unless the change addresses an urgent security risk.

3. Avoiding confusion with other "level" schemes and common federal terminology

Comment:
Number-based "levels" are widely used in federal environments (for example, DoD cloud Impact Levels). Without an explicit FedRAMP qualifier, numeric levels can be misread as alignment to other schemes or as a direct statement of security impact.

Proposed clarification:

• In Marketplace data fields and public guidance, require the label to include the FedRAMP designation prefix, for example:
  • "FedRAMP Certified Level X" or "FedRAMP Validated Level X"
• Consider adding a short "scheme identifier" to machine-readable Marketplace data such as:
  • designation = Certified or Validated
  • scheme = Rev5 or 20x
  • level = 1-6
    This makes it harder to confuse FedRAMP levels with other level systems.

4. Level attributes tied to Balance Improvement Releases and "no corrective action" conditions

Comment:
RFC-0020 includes additional conditions in some level descriptions (for example, Balance Improvement Releases and "no corrective action for the past year"). These conditions can be valuable, but they need objective measurement criteria and clear applicability across offerings to avoid inconsistent expectations.

Proposed clarification:

• Define objective criteria for any "no corrective action for the past year" condition, including:
  • What counts as corrective action.
  • The measurement period and start date.
  • How disputes are handled and whether there is an appeals mechanism.
• If Balance Improvement Releases or recommendations are used as level qualifiers, clarify:
  • Which releases are in-scope for the level claim.
  • Whether they must be applicable to the offering type.
  • Whether releases must be generally available before they can be used as a condition.
• Consider separating these attributes from the level number as an additional Marketplace indicator or badge (for example, "Balance Improvements Implemented" or "No Corrective Action 12 months") so that the level number remains focused on package coverage and depth.

5. Marketplace representation and transition guidance for legacy and in-flight work

Comment:
RFC-0020 proposes an automatic transition of existing Marketplace listings to new designations and levels on or near the effective date. Agencies and providers need predictability for in-flight work and consistent Marketplace record fields.

Proposed clarification:

• Specify the exact Marketplace data fields that will represent:
  • designation type (Certified or Validated)
  • scheme (Rev5 or 20x)
  • level number
  • lifecycle status (for example, Preparation, Assessment by FedRAMP, Continuous Monitoring, Persistent Validation)
  • conversion timestamp and crosswalk version used
• Clarify whether in-process deliverables must be relabeled retroactively, or only prospectively after the transition date. If updates are expected, specify the minimum set of artifacts that must be updated (for example, cover page labeling and Marketplace listing fields only).

6. Standard disclaimer language to distinguish FedRAMP status from an agency ATO

Comment:
We strongly support a required standard disclaimer that can be reused consistently by CSPs, assessors, and Marketplace entries.

Proposed clarification (suggested disclaimer text):
"A FedRAMP designation (Certified or Validated) indicates that FedRAMP has reviewed the cloud service offering's security package for use by federal agencies. A FedRAMP designation is not an agency Authorization to Operate (ATO) decision. Each federal agency is responsible for authorizing the use of the cloud service offering in its environment, including completing its risk assessment and authorization activities."

7. Discouraged and prohibited phrasing for public claims during transition

Comment:
To reduce misrepresentation and procurement confusion, FedRAMP should publish clear examples of discouraged or prohibited claims.

Proposed clarification:

• Discourage claims that imply government-wide approval, for example:
  • "Government-wide ATO"
  • "Approved for all federal agencies"
  • "FedRAMP ATO"
• Require that any public claim include the designation and level, for example, "FedRAMP Certified Level 3 (Rev 5)," and include or link to the standard disclaimer text above.

Personal capacity note: This comment is submitted in an individual capacity and does not represent any employer or organization.

Matthew S. Graham, CISSP
https://www.linkedin.com/in/msgcyberassessments/

[OG-of-the-realms]

I like the concept of Certified and Validated as distinctions between Rev5 and 20X paths.

Perhaps an approach that keeps Low/Moderate/High as the authorization impact rating - to keep consistency with NIST and FIPS, and to avoid confusion/consternation among Federal Agencies that make explicit callouts in contract language.
However, perhaps add Maturity Level (maybe a better name to avoid industry anger and confusion with CMMC). Similar to the comment from fortetroy

A CSP goes through Rev5 or 20X and gets FedRAMP Moderate Certified/Validated, Level 1. They implement all of the SHOULDs and don't have substantial risks, they get Level 2. They go beyond the spirit of the KSIs for Moderate and impress the PMO, no risks, do all/most of the SHOULDs/MAYs/etc, they get Level 3.
Provides an indicator to customers that yes, Vendor 1 meets the bar for entry to market. But Vendor 2 is knocking it out of the park consistently.

[rubrik-fedramp-team]

• The use of qualitative descriptors such as "typical amount of information" and "significant amount of information" to define certification levels introduces unnecessary ambiguity into the authorization process. These relative terms are subjective and open to interpretation by agencies, 3PAOs, and CSPs, potentially leading to inconsistent package standards or misaligned expectations during the review cycle. We recommend that FedRAMP explicitly define what these terms translate to in the context of the package deliverables. Specifically, we request the guidance be updated to map these terms to established baselines or artifact lists.
• Rubrik recommends that the FedRAMP PMO remove the "no corrective action" criteria as a gating factor for Level 4 and Level 6 designations. Penalizing providers for participating in transparent, NIST-compliant risk management creates a perverse incentive for CSPs to potentially suppress key data to protect their Marketplace standing.
• Rubrik recommends that the PMO narrow the scope of BIRs as prerequisites for Levels 4 and 6 to those that are mandatory. A CSP should not be held accountable for implementing optional enhancements that require the explicit coordination, budgetary expenditure, or policy acceptance of an Agency Sponsor. It is recommended that the criteria for achieving Level 4 and Level 6 be restricted exclusively to the implementation of mandatory, generally available BIRs that the CSP can execute unilaterally.
• Rubrik requests additional acquisition guidance to Federal contracting officers regarding the equivalency of the "Certified" and "Validated" designations. The RFC should explicitly state that both designations guarantee adherence to the identical underlying NIST SP 800-53 impact-level baselines (Low, Moderate, High). The Marketplace interface should prominently feature an equivalency disclaimer, ensuring that acquisition professionals understand that the distinction reflects the methodology of assessment (point-in-time vs. persistent validation), not a deficiency in the system's security posture or baseline control implementation.

[Rene2mt]

Thank you to the FedRAMP team for taking a fresh look at authorization designations and for directly addressing the long-standing confusion around what "authorization" represents in practice. Clarifying this terminology is worthwhile and appreciated.

That said, I share the concern raised by several other commenters that changing Rev. 5 designations - if they are only intended to persist through roughly 2027 - may not justify the disruption. Introducing short-lived terminology changes risks creating churn in documentation, contracts, and internal governance processes without delivering lasting value.

I am also concerned about the possibility of parallel paths emerging where CSPs must maintain Rev. 5 authorization packages for some agency customers while simultaneously pursuing 20x approaches for early adopters. Without a clear unifying model, this could increase complexity for CSPs, agencies, and assessors rather than reduce it.

One alternative framing to consider is moving away from authorization terminology entirely and instead thinking in terms of security
capability maturity. Rather than distinguishing primarily between "authorized," "certified," or "validated," FedRAMP could define a small set of security maturity tiers that reflect how a cloud system actually achieves and sustains security.

Agencies could then evaluate systems based on a combination of their own (data / mission's) impact level and system's FedRAMP security maturity tier, using both to inform risk acceptance and ATO decisions. Below is a rough example of how this could be structured:

Impact Level	Tier 1 – Foundational	Tier 2 – Repeatable	Tier 3 – Integrated	Tier 4 – Adaptive	Tier 5 – Resilient
Low Impact	Policy-driven controls, manual evidence collection. KSIs largely document-based (e.g., inventory completeness, basic access reviews).	Repeatable operational security processes and centralized logging. KSIs begin reflecting operational signals (e.g., vuln scan cadence, patch timelines).	Security integrated into CI/CD and cloud operations. KSIs reflect automation depth (e.g., build pipeline security checks, IaC validation rates).	Continuous validation and automated remediation. KSIs emphasize real-time posture (e.g., drift detection, mean time to remediate).	Predictive posture and resilience metrics. KSIs may include anomaly prediction, automated containment effectiveness, and recovery performance.
Moderate Impact	Acceptable only for limited pilots or constrained workloads. KSIs mostly attestational or periodic.	Suitable for many traditional Moderate workloads. KSIs reflect repeatability and operational consistency (e.g., logging coverage, MFA enforcement rates).	Strong candidate for reuse across agencies. KSIs tied to deployment pipelines, identity posture, and configuration conformance.	High-confidence posture with continuous assurance signals. KSIs increasingly machine-generated and near-real-time.	Mission-ready Moderate systems. KSIs emphasize resilience, supply chain visibility, and response automation effectiveness.
High Impact	Generally insufficient except for tightly scoped scenarios. KSIs largely policy or control verification oriented.	May require significant agency risk acceptance. KSIs show process maturity but limited automation depth.	Baseline for many High systems today. KSIs reflect strong integration of security telemetry with operations.	Strong model for future High reuse and continuous authorization. KSIs demonstrate automated validation, rapid response, and measurable security reliability.	Target state for highly sensitive workloads. KSIs emphasize continuous operational trust, mission resilience, and predictive defense capabilities.

I realize this idea would require significant refinement, but it could provide a unifying model that supports:

• today's Rev. 5 control-based assessments
• the transition period where different approaches coexist
• the longer-term vision of continuously validated systems reporting
  measurable security signals (e.g., KSIs) tied to actual system state

In short, a cloud security maturity-oriented approach could help FedRAMP shift the conversation from "what controls are documented" to "how securely the system actually operates over time."

Thank you again for the thoughtful RFC and for continuing to modernize the program.

[Quzara]

This is a governance problem dressed up as a terminology problem. Agencies skip package review and bypass the Categorize step because there are no accountability mechanisms on the agency side — not because "authorized" is a confusing word. A label change will not change that behavior. Embedded agency-side guidance in the Marketplace would. The RFC should acknowledge this limitation rather than imply that nomenclature is the fix.

"FedRAMP Certified" will be read as a security endorsement — which is precisely the misunderstanding FedRAMP is trying to correct. Every major compliance framework (ISO 27001, SOC 2, PCI DSS) uses "certified" to mean an independent body validated security conformance. The RFC immediately contradicts this by stating certification levels "do not indicate security." That disclaimer will not survive contact with a procurement official. The label works against the stated goal.

The 1-6 numbering will collide with DISA Impact Levels in DoD procurement. Contracting officers who already conflate FedRAMP and DISA requirements will write RFPs referencing "Level 4 or higher" believing it aligns with IL4. FedRAMP needs a published statement of non-equivalence and should consider whether "Assessment Tier" is less collision-prone than "Level."

Levels 4 and 6 are unreachable at launch. Required Balance Improvement Releases are still in beta or require AO coordination CSPs cannot unilaterally initiate. Publishing phantom tiers creates false marketplace signal and makes compliant CSPs appear inferior to competitors through no fault of their own. Withhold these levels until prerequisites are in general release, or label them explicitly as forthcoming.

"No corrective action for the past year" is the wrong standard and creates perverse incentives. A CSP that found a gap and closed it in 30 days should not be treated identically to one that ignored findings for eleven months. More importantly, this standard incentivizes CSPs to avoid transparent engagement with FedRAMP reviewers to dodge formal corrective action — the opposite of the relationship model FedRAMP should want. Replace this with "no unresolved corrective action at time of level assessment" and publish a formal appeals mechanism before this goes live.

Assessment coverage and compliance track record are two different things — collapsing them into one number loses information. A CSP with deep documentation and one resolved POA&M is not equivalent to one with shallow documentation and a clean record. Separate these into two independently queryable Marketplace attributes: an Assessment Coverage Tier and a Compliance Track Record Indicator.

We support FedRAMP's modernization direction. These comments are intended to strengthen implementation, not oppose the initiative.
Quzara LLC

[nicole-gov]

The following public comment was received via email from Coalfire on Thu Feb 19 @ 5:25PM.

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc.

---

RFC-0020

FedRAMP Certified (Rev 5)
The certified levels descriptions are confusing. Especially the words "minimum, small, typical, significant". These words are subjective and could be misleading. When I see words like "small" or "typical" that says to me that the Certification package could have included more information but the CSP chose not to, or was unable to provide more information. That has a negative connotation.

Why not simplify by saying (for example):

"The FedRAMP Certification package includes all required information for use in a moderate impact authorization decision in most cases."

• What is the meaning of "in most cases" and "in many cases"? I expect this to be a common question from CSPs. Is that there to account for situations when an agency has additional requirements beyond a fedramp baseline? Can you add a section explaining this? Even 1-2 sentences would be helpful.

Certified vs. Validated Alternative
Using different terminology for Rev 5 (Certified) vs. 20x (Validated) adds unnecessary confusion. What is the benefit of having different terms? If the goal is to simplify FedRAMP, we should not be creating a situation where agencies have to choose whether they prefer a certified CSP vs. a validated CSP.

Why not use the term "provisional authorization", which is already a well-known industry term, instead of certified/validated? This would align with the DoW model where DISA grants the PA and the agency grants the ATO.

[nicole-gov]

The following public comment was received via email from Information Technology Industry Council (ITI) on Thu Feb 19 @ 4:07PM.

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc.

---

ITI’s Comments on RFC-0020 FedRAMP Authorization Designations

Pete Waterman
FedRAMP Director
General Services Administration (GSA)

Dear Mr. Waterman

The Information Technology Industry Council (ITI) appreciates the opportunity to comment on RFC-0020 FedRAMP Authorization Designations. ITI is the premier global advocate for technology, representing the world’s most innovative companies. Founded in 1916, ITI is an international trade association with a team of professionals on four continents. We promote public policies and industry standards that advance competition and innovation worldwide. Our diverse membership and expert staff provide policymakers the broadest perspective and thought leadership from technology, hardware, software, services, and
related industries.

We agree with the rationale that clearer FedRAMP designations will reduce persistent market confusion between FedRAMP authorized systems and an agency Authorization to Operate (ATO) under FISMA. We believe the proposed changes will make the Marketplace easier to interpret for federal customers and industry, and will help reduce ambiguity in how authorization packages are used to support agency-specific authorization decisions. While the proposed criteria for Certification Levels 1–3 and 5 have the advantage of building on a historical categorization, we believe additional clarity is needed for the newly created Rev5 Certified Levels 4 and 6. The descriptions introduce subjectivity in determining if a cloud service with an existing authorization will be listed as a Certification Level 3 versus 4, or a Certification Level 5 versus 6 under the new authorization designation scheme. This subjectivity is exacerbated by the fact that there is no indication of the criteria defining a "typical" or “significant” amount of information used to determine the appropriate level. We recommend that the PMO define objective thresholds that distinguish Levels 4 and 6 from Levels 3 and 5.

Another area which requires additional clarity is the FedRAMP PMO’s adoption of the term “certificate” in conjunction with using Levels 1 – 5. This will lead to even more confusion than already exists as there is a risk of confusion between the DoD FedRAMP+ Impact Levels (aka IL2/IL4/IL5/IL6) and these new FedRAMP levels of certification. In addition, CMMC also uses 3 levels, which may also cause confusion with FedRAMP. With this in mind, we recommend the FedRAMP PMO adopt the terminology that the FedRAMP Joint Authorization Board (JAB) used of a Provisional-ATO (P-ATO), as this still requires an agency to do an ATO to and accept the risk for any cloud service that is FedRAMP authorized.

Further, if providers can be moved between levels at the discretion of the PMO, several questions arise: 1) What is the established periodicity for these decisions? 2) What is the communication plan from the PMO regarding such changes? 3) Is there a formal process to appeal a PMO decision? As such, we recommend that the PMO clearly articulate the circumstances and process by which cloud providers would be moved between levels and the timing/periodicity of any reviews that would cause a provider to move between levels.

We thank you for your attention to this issue and for your consideration of our comments,

Megan Petersen
Senior Vice President of Policy
Public Sector and Counsel
Information Technology Industry Council (ITI)

[nicole-gov]

The following public comment was received via email from Salesforce on Thu Feb 19 @ 5:36PM.

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc.

---

Requirement_ID	Title/Section	Salesforce Comment
FedRAMP Certified (Rev5)	FedRAMP Certified (Rev5)	1. "Many cases" vs "Almost every case" Concern: The distinction between “adequate for use in … authorization decision in many cases” (e.g., Level 5) and “in almost every case” (e.g., Levels 4 and 6) is not defined. Without clarity on what “many” vs. “almost every” means and how that is measured or assessed, authorizing officials and reviewers cannot consistently interpret or rely on the difference between those levels. Recommendation: Define and document (1) the material difference between “many cases” and “almost every case” (e.g., scope of scenarios, types of systems/use cases, or risk conditions covered), and (2) how that distinction is measured or determined (e.g., criteria, sampling, review process, or percentage/threshold). Adding this to the certification level descriptions or supporting guidance would make the levels more interpretable and auditable. 2. Clarify “all Rev5 Balance Improvement Releases” (mandatory vs. optional) Concern: The phrase “all Rev5 Balance Improvement Releases” does not distinguish between mandatory and optional BIRs. Some BIRs are mandatory and others optional; without that distinction, it is unclear what CSPs must implement to meet levels that reference “all Rev5 Balance Improvement Releases” (e.g., Certified Levels 4 and 6). Recommendation: Specify that the requirement refers to mandatory BIRs (e.g., “all Mandatory Rev5 Balance Improvement Releases”) and/or publish a clear list of which BIRs are mandatory vs. optional for each certified level so CSPs and authorizing officials know exactly what is in scope. 3. Clarify how certified level is determined (verification vs. self-designation) Concern: It is unclear whether FedRAMP verifies that required BIRs and other level criteria are satisfied before a CSP is designated a given certified level, or whether CSPs self-designate. If designation is not independently verified, the meaning and reliability of “Certified Level X” may be inconsistent; if it is verified, stakeholders are not sure how or by whom. Recommendation: In the certified-level documentation (and related process guides), state explicitly whether FedRAMP (or an authorized third party) verifies compliance before a level is assigned. If verification is performed, describe the process (e.g., review of evidence, sampling, or audit). If CSPs self-designate, state that clearly and describe any subsequent review, sampling, or attestation used to maintain confidence in the designation. 4. Align evidence and validation for supporting artifacts (e.g., Secure Configuration Guide) Concern: For supporting requirements such as the upcoming Secure Configuration Guide (e.g., due March 1), the process has been described as relying on CSP self-reporting (e.g., whether it is complete and where it is hosted). A one-off or highly flexible approach with minimal validation may produce inconsistent evidence and make it hard for authorizing officials to rely on certified levels. Recommendation: Define consistent, repeatable expectations for how CSPs demonstrate compliance with required artifacts (e.g., Secure Configuration Guide): what evidence is required, where it is hosted or submitted, and how FedRAMP or another designated party validates it. Ensure the approach is documented, scalable, and resourced so it can be applied consistently across CSPs and over time. Summary: 1. “Many” vs “almost every”: Define what “many cases” and “almost every case” mean and how that distinction is measured or assessed. 2. BIRs: Specify that only mandatory Rev5 BIRs are required and/or publish which BIRs are mandatory vs optional per level. 3. Level designation: State clearly whether FedRAMP (or a third party) verifies level criteria before designation or CSPs self-designate, and describe the process. 4. Supporting artifacts: Define how compliance with required artifacts (e.g., Secure Configuration Guide) is demonstrated and validated in a consistent, repeatable way.
FedRAMP Validated (20x)	FedRAMP Validated (20x)	1. Historical categorization for Validated Level 5 Concern: Validated Level 5 is described as having “a significant amount of information … adequate for use in a high impact authorization decision in many cases,” which aligns with high-impact use. The “Historical FedRAMP 20x Categorization” for Level 5 is currently “N/A,” while Level 2 is mapped to “Low” and Level 3 to “Moderate.” Leaving Level 5 as “N/A” makes it unclear how it relates to the existing impact-level framework and can hinder mapping and comparison for agencies. Recommendation: Map Validated Level 5 to High in the “Historical FedRAMP 20x Categorization” column so the level’s alignment with high-impact authorization decisions is explicit and consistent with the level descriptions. If “N/A” is intentional (e.g., no historical equivalent), add a short note in the policy or table explaining why Level 5 has no historical categorization. 2. Defining “nearly all” in Level 4 and Level 6 Concern: Level 4 and Level 6 state that the cloud service offering has “met nearly all recommendations from FedRAMP with no corrective action for the past year.” The term “nearly all” is subjective and can be interpreted differently by CSPs, assessors, and agencies. Without a clear definition, it is hard to apply the requirement consistently and to verify compliance. Recommendation: Replace or define “nearly all” with explicit, measurable criteria. For example: specify a percentage (e.g., “at least 90% of applicable recommendations” or “no more than X% outstanding”), or a numeric cap (e.g., “no more than one [or two] open recommendations,” with any exceptions documented). Publish this definition in the same policy or in linked guidance so Level 4 and Level 6 expectations are unambiguous and auditable. Summary: 1. Validated Level 5 historical categorization: Map Validated Level 5 to High in the Historical FedRAMP 20x Categorization column (or document why it stays N/A) so its link to high-impact use is clear for agencies. 2. “Nearly all” in Level 4 and Level 6: Define “nearly all” in measurable terms (e.g., percentage or cap on open recommendations) and publish it in the policy or guidance so Level 4 and Level 6 are consistent and auditable.

[nicole-gov]

The following public comment was received via email from The Alliance for Digital Innovation (ADI) on Thu Feb 19 @ 11:34PM.

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc.

---

RFC 0020

The Alliance for Digital Innovation (ADI) appreciates the opportunity to comment on RFC-0020, Authorization Designations.

We understand and support the underlying rationale, particularly the goal of eliminating confusion between FedRAMP “Authorized” systems and an agency’s “Authorization to Operate” for a FedRAMP “Authorized” system. Clarifying that distinction and reinforcing the separation of responsibilities can improve risk management across the federal ecosystem.

The published criteria for Certification Levels 1 through 3 and Level 5 are relatively clear. However, uncertainty arises in the descriptions of Certification Levels 4 and 6. Level 4 refers to a “typical amount” of information in the FedRAMP Certification package sufficient for use in a moderate impact authorization decision, while Level 6 refers to a “significant amount” of information sufficient for use in a high impact authorization decision. Because the framework does not define what constitutes a “typical” versus “significant” amount of information, the schema introduces subjectivity in distinguishing Level 3 from Level 4 and Level 5 from Level 6. The absence of objective, measurable criteria may lead to inconsistent application and uncertainty for agencies and providers alike.

Moreover, if providers may be moved between levels at the discretion of the PMO, additional transparency would strengthen confidence in the process. We would appreciate clarification on the following: (1) the established periodicity for level determinations; (2) the communication plan the PMO will follow when level changes occur; and (3) whether a formal and transparent appeal process will be available to providers; and if so, what does that process look like.

We also recognize the intent behind transitioning from the longstanding Low/Moderate/High construct to a six-level designation model. At the same time, many external frameworks have intentionally aligned policies, acquisition language, and cross-framework mappings to FIPS 199 impact levels to maintain consistency with NIST guidance. Moving to a new level-based structure without a clearly articulated crosswalk and explanation of the policy rationale may introduce interpretive challenges as agencies reconcile FedRAMP designations with existing Risk Management Framework categorizations. Providing additional clarity on how the new levels are defined and how they map to established constructs would reduce confusion, promote consistency, and support smoother adoption across the federal community.

Thank you for your consideration on this matter.