RFC-0022 Leveraging External Frameworks

[pete-gov]

RFC-0022 Leveraging External Frameworks

❓ 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 26, 2026

Summary

This RFC proposes a temporary high speed path to FedRAMP authorization for cloud services with existing security assessments from external security frameworks so that federal agencies and providers can test and pilot these services prior to investing in a full FedRAMP authorization path.

This authorization, part of the FedRAMP 20x path and designated as FedRAMP Validated Level 1, allows providers that meet certain criteria to receive a FedRAMP Validated authorization by meeting only a small portion of 20x Low requirements - without additional independent verification and validation from a FedRAMP recognized independent assessor. This authorization will meet the necessary legal and policy requirements to allow agencies to test or pilot the use of these services based on their own risk determinations.

This process does NOT establish “reciprocity” with any external framework but does allow limited reuse of existing assessment and certification materials for a temporary authorization. Providers will be allowed to maintain the FedRAMP Validated Level 1 status for up to 1 year from the first agency reuse of this FedRAMP authorization. Agency reuse of this authorization should be limited to negligible and low risk systems.

This RFC is aligned with one other concurrent RFC that has additional details on specific topics but has been published separately to encourage topic-specific comments:

• RFC-0020: FedRAMP Authorization Designations
• RFC-0021: Expanding the FedRAMP Marketplace

Background & Authority

This proposed authorization combines multiple authorities and responsibilities into a single opportunity, aligned with priorities from the Office of Management and Budget and the Federal CIO outlined in OMB Memorandum M-24-15.

OMB M-24-15, Section IV: “To identify more cloud service offerings that could become FedRAMP authorized, and to accelerate their eventual path to being authorized, FedRAMP will provide procedures for issuing a time-specific temporary authorization, as discussed in NIST risk management guidelines, that would allow Federal agencies to pilot the use of new cloud services that do not yet have a full FedRAMP authorization.”

NIST SP 800-37 Rev 2, Appendix F: “If the authorizing official, after reviewing the authorization package, determines that the risk to organizational operations, organizational assets, individuals, other organizations, and the Nation is acceptable, an authorization to operate is issued for the information system… The authorizing official may choose to authorize the system to operate only for a short period of time if it is necessary to test a system in the operational environment before all controls are fully in place, (i.e., the authorization to operate is limited to the time needed to complete the testing objectives). [Formerly referred to as an interim authority to test.]”

OMB M-24-15, Section V: “FedRAMP will establish criteria for accepting widely-recognized external security frameworks and certifications applicable to cloud products and services, based on FedRAMP's assessment of relevant risks and the needs of Federal agencies. This will include leveraging external security control assessments and evaluations in lieu of newly performed assessments, as well as designating certifications that can serve as a full FedRAMP authorization, if appropriate.”

Greg Barbaccia, Federal CIO, at the FedRAMP 20x Phase 2 Launch: “We know that if we want the government to accept and adopt incredible technology, we need to meet you half way. Ideally more. [...] We want to accept existing commercial frameworks and documentation, saving you time, saving you money…”

Motivation

All civil servants deserve access to high quality tools for non-sensitive use cases with a minimum investment of agency time and funding. Cloud services often have highly specific use cases for agency users that aren’t enterprise-wide and might even be limited to only a few certain users in large agencies. The current policy environment makes the assessment, authorization, and deployment of smaller services for targeted use cases almost impossible for most agencies because it never makes sense to spend tens of thousands of dollars to review the security of a service that won’t be deployed enterprise-wide.

At the same time, cloud services are often available at low cost for groups of users such that yearly licenses for 500 users might only cost $10/mo each for a total yearly revenue of $60,000. The profit from a deal like that with a single agency would cover a fraction of the salary for a single security engineer or compliance expert… so without large expensive deals guaranteed there is little reason to invest in a FedRAMP authorization. In its current state, law and policy effectively blocks agency access to such services by requiring a FedRAMP authorization by default.

FedRAMP must make it as simple as possible for agencies to quickly obtain and maintain a FedRAMP authorization for cloud services they intend to use for non-sensitive use cases while simultaneously encouraging commercial cloud service providers to enter the federal market and generate revenue to invest in the additional capabilities necessary for initial and ongoing authorization of higher impact use cases.

To meet this need, FedRAMP will leverage statutory and policy authority to create a special time-limited FedRAMP authorization status for cloud services that meet widespread commercial security requirements called FedRAMP Validated Level 1.

FedRAMP Validated Level 1 will be a special designation during the Preparation phase for a cloud service provider, consistent with the Preparation phase of the NIST Risk Management Framework, to indicate that the provider is carrying out the essential activities necessary to prepare the organization to manage its security and privacy risks following the FedRAMP 20x process. This special designation highlights that the cloud service offering may already meet many of the underlying expectations for managing security but has yet to fully implement the government-specific requirements and recommendations necessary for a FedRAMP 20x Validation.

Proposed Requirements for FedRAMP Validated Level 1

All relevant proposed requirements and recommendations for the FedRAMP Marketplace process discussed in RFC-0021 also apply, including the requirements and recommendations for cloud service offerings in the Preparation status.

The following requirements and recommendations apply to ALL cloud services seeking to obtain and maintain FedRAMP Validated Level 1; unless otherwise stated in a specific requirement, the default corrective actions for cloud service providers that fail to address these requirements will be as follows:

Corrective Actions: Requirements will be enforced under a 3 strike rule over the lifetime of a cloud service offering’s continuous Marketplace listing:

1. The first failure will result in public notification and a 3 month grace period to address the requirement.
2. The second failure will result in public notification and a revocation of FedRAMP Validated for a period of at least 3 months.
3. The third failure will result in public notification and suspension from the FedRAMP Marketplace entirely for a period of at least 12 months.

MKT-LEF-PRE Preparation State Listing Required

Providers MUST have their cloud service offering listed in the FedRAMP Marketplace in the Preparation state for FedRAMP 20x.

Note: FedRAMP will only list products that are within the Scope of FedRAMP, please review the requirements for the Preparation state MKT-LEF-PRE in RFC-0020 to understand the circumstances here.

MKT-LEF-ASF Approved Security Frameworks

Providers MUST have completed an external security assessment from the following list that is appropriately current and included an independent assessment from an appropriately accredited independent auditor as required by the framework:

1. SOC 2 Type II
2. ISO/IEC 27001
3. HITRUST e1, i1, r2
4. StateRAMP (dba GovRAMP) Provisionally Authorized, Authorized
5. CMMC Level 2
6. FedRAMP Ready

Notes:

• This list is not an endorsement of any security framework but is intended to capture common frameworks with wide commercial adoption or direct relevance that are likely to contain audited materials to meet the Validated Level 1 requirements.
• Additional external security frameworks may be added to this list based on demand.

MKT-LEF-MAP Mapping to Key Security Indicators

Providers MUST include a temporary mapping from their existing commercial security assessment to a subset of FedRAMP Key Security Indicators in simple, short, narrative text with direct links to the source material; this mapping must be available in both machine-readable and human-readable formats and include at least the following indicators:

1. KSI-AFR-MAS Minimum Assessment Scope
2. KSI-AFR-ADS Authorization Data Sharing
3. KSI-AFR-CCM Collaborative Continuous Monitoring
4. KSI-AFR-FSI FedRAMP Security Inbox
5. KSI-CMT-LMC Logging Changes
6. KSI-CMT-RVP Reviewing Change Procedures
7. KSI-CNA-MAT Minimizing Attack Surface
8. KSI-IAM-MFA Enforcing Phishing-Resistant MFA
9. KSI-IAM-SNU Securing Non-User Authentication
10. KSI-INR-RIR Reviewing Incident Response Procedures
11. KSI-MLA-OSM Operating SIEM Capability
12. KSI-SVC-SNT Securing Network Traffic
13. KSI-SVC-RUD Removing Unwanted Data

Notes:

• If a mapping is not clear then the indicator should be addressed with new information that indicates it has not been independently audited.
• FedRAMP is renaming some Key Security Indicators, this RFC may be updated with the same Key Security Indicators but different names.

MKT-LEF-AFM Availability of Full Materials

Providers MUST make the full materials from the leveraged existing commercial security assessment available to all necessary parties as part of the FedRAMP Validated Level 1 authorization package.

MKT-LEF-IVV Independent Verification and Validation

Providers MAY have their FedRAMP Validated Level 1 authorization package independently verified and validated by a FedRAMP recognized independent assessor prior to submission to FedRAMP; this is NOT required.

MKT-LEF-FPS Formal Procedures for Submission

Providers MUST precisely follow formal FedRAMP procedures to submit a complete authorization package for FedRAMP Validated Level 1.

Note: This formal procedure will be published separately when this proposal has been approved and formalized after public comment but will likely consist of a simple form with attestation that requirements have been completed.

Corrective Actions: Failure to submit a sufficient or complete report will result in a 3 month penalty for resubmission.

MKT-LEF-DFV Deadline for FedRAMP Validation

Providers MUST obtain a FedRAMP 20x Validation within 12 months of their FedRAMP Validated Level 1 cloud service offering receiving an agency Authorization to Operate.

Note: This applies to any positive Authorization to Operate decision even if the agency is using outdated or internal terminology such as “Interim Authority to Test.”

MKT-LEF-ATO Authorization to Operate Notification

Agencies MUST notify FedRAMP after approving the Authorization to Operate a cloud service based on reusing a FedRAMP Validated Level 1 package by emailing info@fedramp.gov to coordinate FedRAMP access to at least the following information from the agency:

1. The signed ATO letter.
2. Contact information for the System Owner, Information System Security Officer, and Authorizing Official.
3. All agency-specific materials generated for the Authorization to Operate, including at least the System Security Plan and Security Assessment Report.
4. Approval or denial for FedRAMP to share these materials with other agencies, signed by the Authorizing Official or a delegate.

Notes:

• This is a statutory obligation for agencies in the form of supplementary information required pursuant to 44 USC § 3609 (a).
• 44 USC § 3613 (c) states: “Upon issuance of an agency authorization to operate based on a FedRAMP authorization, the head of the agency shall provide a copy of its authorization to operate letter and any supplementary information required pursuant to section 3609(a) to the Administrator.”
• This applies to any positive Authorization to Operate decision even if the agency is using outdated or internal terminology such as “Interim Authority to Test.”

MKT-LEF-NLR Negligible or Low Risk Use Cases

Agencies SHOULD limit the reuse of a FedRAMP Validated Level 1 package to pilot/test uses cases or those with negligible or extremely low risk when performing an Authorization to Operate with conditions for their use of this cloud service.

MKT-LEF-RFM Review Full Materials

Agencies SHOULD review the full materials, including the external security assessment, when making an authorization decision to reuse the FedRAMP Validated Level 1 package in an agency Authorization to Operate.

MKT-LEF-LIO Low Impact Only

Agencies SHOULD NOT reuse a FedRAMP Validated Level 1 authorization to perform an agency Authorization to Operate at higher than the Low impact level UNLESS deploying significant compensating controls.

MKT-LEF-ROQ Require Ongoing FedRAMP Qualification

Agencies SHOULD include a requirement in their Authorization to Operate that the cloud service offering maintain a FedRAMP Validated status with automatic revocation of the Authorization to Operate in the event that the FedRAMP Validated status is revoked.

Related Updates to the Minimum Assessment Scope

To avoid confusion related to this FedRAMP Validation level (which is intended only for agency use), FedRAMP will update the Minimum Assessment Scope under FRR-MAS-03 for both 20x and Rev5 as follows:

FRR-MAS-03 Non-FedRAMP Authorized Third-Party Information Resources

Providers MUST clearly identify and document the justification, mitigation measures, compensating controls, and potential impact to federal customer data from the configuration and usage of third-party information resources that are not FedRAMP Validated Level 2+ or FedRAMP Certified Level 1+, ONLY IF FRR-MAS-01 APPLIES.

Note: The purpose of FedRAMP Validated Level 1 is to encourage agency-based testing and piloting of these services following a detailed use-case specific review, therefore anyone other than an agency authorizing official should treat a FedRAMP Validated Level 1 service as if it does NOT have a FedRAMP authorization.

[apolaniaklaus]

Dear FedRAMP Community and PMO Team,
Thank you for the opportunity to comment on RFC-0022 — Leveraging External Frameworks, which proposes the FedRAMP Validated Level 1 authorization pathway. I support the intent behind this proposal — namely to reduce redundant assessment effort, accelerate agency adoption of cloud services for low risk use cases, and lower barriers for smaller offerings — while still providing a legally recognized mechanism for agency risk decisions.
That said, I offer the following recommendations and cautions to ensure that this mechanism protects federal data and maintains the rigor that agencies and stakeholders expect from the FedRAMP program.

1. Differentiation and Assurance of External Reports Is Critical
   The RFC currently lists external frameworks such as SOC 2 Type II and ISO/IEC 27001 as acceptable baseline artifacts. While these frameworks are widely recognized and commercially valuable, not all reports are created equal:
   • Lack of consistency in auditing depth: SOC 2 and ISO audits vary in scope and rigor depending on the audit firm, engagement scope, sampling, and evidence depth.
   • Narrative vs. technical testing: Some auditors rely heavily on management descriptions rather than thorough technical testing.
   • Oversight challenges: Commercial audit ecosystems and GRC automation tools can sometimes enable reports with limited scrutiny.
   Because of this, I recommend adding criteria to assess the quality and depth of these external assessments, including but not limited to:
   • Auditor accreditation and independence (if auditors can be part of the CPAO or C3PAO community would greatly increase assurance, mind you I do not work for these types of firms but I have seen firsthand the difference between these firms and questionable practices).
   • Explicit evidence of operational effectiveness testing
   • Scope verification (including carve-outs and exclusions)
   • Consistency of testing depth across control categories

2. Independent Verification Should Be More Than Optional
   RFC-0022 states that external reports can be reused without independent FedRAMP IV&V. However, the foundational strength of FedRAMP has historically relied on independent assessment rigor to validate both design and implementation of controls.
   To maintain confidence in Validated Level 1 packages:
   • Make IV&V strongly encouraged or required for certain frameworks or risk profiles.
   • If IV&V remains optional, require a justification statement and evidence of adequate audit rigor.
   This preserves efficiency while still guarding against superficial assessment artifacts.

3. Scope and Boundary Discipline Must Be Explicit
   Federally scoped assessments like FedRAMP have strong requirements around system boundaries, inherited components, and threat vectors. By contrast, many commercial audits permit broad carve-outs and scope reductions that would be unacceptable in a FedRAMP authorization.
   For Validated Level 1:
   • Require clear documentation of scope boundaries for each external assessment, including:
   o What systems/services were in scope
   o What was excluded and why
   o How third-party dependencies were treated
   • Include explicit evaluation of boundary completeness in the mapping to Key Security Indicators.
   Without disciplined boundary definition, reuse artifacts may create blind spots that put federal data at risk.

4. Agency Guidance and Oversight Requirements Should Be Strengthened
   Agency Authorizing Officials will bear significant risk decision authority under this model. To support sound decisions:
   • Require agencies to document risk acceptance rationale when relying on Validated Level 1 packages
   • Encourage agencies to periodically review and reassess Validated Level 1 services before reuse or migration to higher sensitive use
   This ensures the agency risk decision is documented and defensible.

5. Maintain Guardrails for Federal Data Protection
   I strongly support limiting Validated Level 1 reuse to low risk use cases. This aligns with NIST risk principles and helps preserve the integrity of FedRAMP as a program for protecting sensitive federal data. However, additional guardrails should include:
   • Structured mapping expectations (some of this has been covered)
   • Periodic reviews
   • Escalation paths for exceptions
   • Explicit criteria for when a full authorization must be pursued

Conclusion
FedRAMP Validated Level 1 has the potential to modernize how agencies adopt secure cloud services, reduce unnecessary duplication, and open the FedRAMP pipeline to more offerings. However, this pathway should not undermine the assurance expectations historically upheld by the program.
By enhancing criteria around external frameworks, auditor quality, scope definition, and agency guidance, FedRAMP can achieve both efficiency and robust risk management.
Thank you again for this opportunity to comment.

[cb-axon]

I support the overall intent of FedRAMP Validated Level 1. This pathway appropriately balances cost, speed, and risk for low-impact, time-bound pilot use cases. That context matters when evaluating how much additional rigor is necessary.

On external framework quality, I agree differentiation is important. However, this is not Moderate or High authorization. For limited-duration, low-risk testing, we do not need to replicate full FedRAMP rigor. A reasonable safeguard would be requiring complete, unqualified assessments (e.g., clean SOC 2 Type II opinions) and, for StateRAMP/GovRAMP, a full authorization rather than provisional or “progressing” statuses. At minimum, there should be clear attestation that the federal use case falls within the scope of the external assessment.

On IV&V, I do not believe it should be required for Level 1. The purpose of this pathway is to actually leverage existing frameworks. If FedRAMP-level IV&V becomes expected, the value proposition collapses and providers may as well pursue full FedRAMP from the outset.

Scope discipline is important, but enforcement should primarily support agency decision-making rather than create another PMO review layer. Agencies should receive sufficient documentation to understand boundaries, exclusions, and third-party dependencies. There will inevitably be blind spots—that is inherent to this being a limited, pilot-oriented authorization. Cost and risk tradeoffs should be acknowledged explicitly.

Agency AOs always retain full risk decision authority. This pathway simply gives them a structured way to test products before requiring vendors to invest heavily in full authorization. That is a practical and beneficial shift.

Finally, I strongly support limiting this pathway strictly to Level 1 use cases. The guardrails in the RFC—mapping to KSIs, time limits, and mandatory transition to full 20x within 12 months of first ATO—are appropriate. Enforcement of scope and transition requirements will be the key to maintaining program integrity.

Overall, this is a reasonable evolution of low-impact FedRAMP pathways, provided the allowed external frameworks are complete and credible, and the use cases remain tightly scoped.

[acloudcj]

I appreciate the intent here which I am assuming is about breaking the chicken-and-egg problem for smaller CSPs who can't justify FedRAMP investment without proven federal demand makes sense.

I'm curious about the design choice to retire FedRAMP Ready (per RFC-0023) while simultaneously introducing Validated Level 1. Ready already required independent 3PAO assessment, it just lacked formal pilot authorization. Why not preserve Ready and formalize agency pilot authority against it, similar to DISA's IATT model? That would enable the pilot use case while maintaining independent validation. Validated Level 1 achieves the same objective but removes the independent assessment layer entirely. Is the view that independent assessment at the pilot stage adds cost without commensurate security value, or is there another driver I'm missing?

[jsantore-cgc]

As a former 3PAO, and self-described RAR subject matter expert (I joke, but only slightly. I have personally worked on so many RARs over the years, such that it became a running joke internally that I was 'the RAR guy'), I have watched as the original intent of FedRAMP Ready morphed over the years with massive scope creep. It was supposed to be a low touch, low cost 'are you on the right path' evaluation, and wound up being so strict it was essentially dubbed 'FedRAMP Perfect' because the threshold for approval was so high.

Also, what was unique about a RAR was that it was more narrative based. There was no SRTM or explicit control evaluations as such, but rather descriptions of things. Think of it as more subjective than objective kinda/sorta. It caused way more confusion than I think it helped. Particularly in the front parts of the RAR where the 3PAO had to narratively describe the overall architecture independent of the SSP front matter. Additionally there were no 'findings' as such that you could carry and remediate. A RAR was pass/fail, and the amount of grace you got between pass and fail got much stricter over time.

FedRAMP Ready was also a prerequisite of the now defunct JAB as a first level review process. This is now moot. It was also used as an attempt to advertise maturity to hopefully garner interest from agency sponsors, and this is also moot with the program authorizations coming in other RFCs.

I guess I'm not sure what the point of a RAR would be these days, or why I would ever recommend someone pursue one. My take is that a Level 1 is more in line with the original intent of a RAR.

Your mileage may vary. I actually enjoyed working on RARs as they had a unique approach to things, but at the tail end, the juice wasn't worth the squeeze, and I'm ok with them getting retired at this point.

[cb-axon]

agree with the sentiment that FedRAMP Ready (RAR) and Validated Level 1 serve very different purposes. Comparing them directly misses the structural shift happening here.

RAR was tied to Moderate/High ambitions and evolved into a near–full rigor exercise, particularly in the JAB era. It became expensive, subjective, and often indistinguishable from a “pre-assessment.” That defeated its original purpose as a lightweight signal of readiness. In contrast, Validated Level 1 is explicitly scoped to Low-risk, time-bound pilot use cases. It is not a stepping stone to Moderate/High by default, nor is it intended to be a proxy for deeper assurance.

The “independent validation” in RAR was largely narrative and did not produce materially different outputs than many external frameworks (e.g., SOC 2). Removing that additional layer at the pilot stage is appropriate. If FedRAMP-level rigor is required up front, the benefit of leveraging external frameworks disappears.

I also support this pathway because it allows agencies and CSPs to determine actual demand and target impact level during the pilot phase. Some services may only ever require Level 1. Others may scale to Level 3 or Level 5 once validated in practice. This creates a more rational investment path for smaller providers.

Overall, I strongly support Validated Level 1 as structured—provided the external frameworks accepted are complete and credible (e.g., unqualified SOC 2, full GovRAMP authorization rather than provisional states) and the one-year time-bound guardrail is strictly enforced.

[Max-sudo-hub]

This is a great entry point for all to participate. I would add the following to the MKT-LEF-ASF Approved Security Frameworks

• PCI-DSS (pick a level)
• UK Cyber Essentials

[cb-axon]

I would caution against adding PCI-DSS or UK Cyber Essentials to the approved framework list.

Both are highly scope-constrained frameworks. PCI-DSS assessments typically apply only to systems in scope for payment processing, not the broader system architecture that a federal use case would rely on. UK Cyber Essentials is similarly narrow and often limited to UK-resident environments, which may not align with U.S. federal data residency and boundary expectations.

Validated Level 1 should leverage broadly scoped security frameworks that evaluate the overall system boundary relevant to federal use, not narrowly tailored compliance regimes tied to specific industries or geographies.

[vedigaurav]

Gap #1: Ambiguity in Control Coverage Sufficiency for External Framework Mapping
Issue: While RFC-0022 requires mapping external assessments to a subset of FedRAMP Key Security Indicators, it does not define what constitutes sufficient coverage for each KSI. As written, a narrative mapping could acknowledge gaps without establishing minimum expectations, resulting in inconsistent security baselines across Validated Level 1 authorizations.
Recommendation: Define minimum sufficiency criteria for KSI mappings (e.g., required evidence types or minimum assessment depth) to ensure consistent and comparable security posture across Validated Level 1 services.

Gap #2: No Explicit Guardrails on Multi-Tenant or Shared-Service Risk
Issue: The RFC does not address how risks associated with multi-tenant architectures or shared-service platforms should be evaluated under Validated Level 1, particularly when external frameworks may assess controls at an organizational rather than service-specific level.
Recommendation: Require providers to explicitly document tenant isolation, shared responsibility boundaries, and service-specific applicability of external assessments as part of the KSI mapping.

Gap #3: Unclear Handling of Significant Changes During the 12-Month Validated Period
Issue: The RFC does not define how significant architectural, hosting, or security changes during the 12-month Validated Level 1 period should be handled. Without defined expectations, agencies may unknowingly rely on outdated risk information.
Recommendation: Establish explicit change notification requirements for Validated Level 1 services, including thresholds that trigger reassessment, remapping, or potential revocation.

Gap #4: No Defined Criteria for Early Revocation Based on Risk Degradation
Issue: Revocation mechanisms focus on procedural non-compliance rather than material risk degradation (e.g., breach, failed audit renewal, or framework certification lapse).
Recommendation: Define conditions under which FedRAMP may revoke Validated Level 1 status early due to increased risk, including loss of external certification validity or material security incidents.

Gap #5: Insufficient Guidance on Agency-Specific Compensating Controls
Issue: Agencies are permitted to reuse Validated Level 1 authorizations with compensating controls, but the RFC does not provide guidance on documenting, validating, or sharing those controls for reuse transparency.
Recommendation: Provide guidance on documenting agency-implemented compensating controls and clarify whether these controls may be reused or referenced by other agencies considering similar use cases.

Gap #6: No Defined Marketplace Signaling for “Pilot-Only” Status
Issue: RFC-0022 states that Validated Level 1 should be treated as not a full FedRAMP authorization, but does not define how this limitation will be clearly communicated in the Marketplace to prevent misinterpretation by agencies or procurement officials.
Recommendation: Introduce explicit Marketplace labeling (e.g., “Pilot/Test Use Only – Time-Limited”) to clearly distinguish Validated Level 1 from higher FedRAMP authorization levels.

Gap #7: Unclear Provider Obligations if No Agency Reuse Occurs
Issue: The 12-month clock for obtaining full 20x Validation begins upon first agency reuse, but the RFC does not address scenarios where no agency elects to reuse the Validated Level 1 package.
Recommendation: Clarify whether Validated Level 1 status expires absent agency reuse, and define provider obligations or renewal conditions in such cases.

Gap #8: Lack of FedRAMP Capacity Signaling for Validated Level 1 Intake
Issue: The RFC does not indicate whether FedRAMP intake for Validated Level 1 is capacity-constrained or how prioritization will occur if submission volume exceeds expectations.
Recommendation: Provide transparency on intake capacity, prioritization logic, or throttling mechanisms to support predictable provider planning.

[cb-axon]

Gap 1 – I do not view this as a deficiency. KSIs across the program are not defined with rigid “sufficiency” thresholds. Some ambiguity is intentional and allows agencies to evaluate risk in context. Gaps in coverage are acceptable at Level 1, provided they are transparent and understood by the agency AO.

Gap 2 – I do not believe this pathway is intended to deeply evaluate multi-tenant risk. This is a low-impact, pilot-only construct. Even traditional FedRAMP Low assessments are not exhaustive in this area. Agencies choosing to pilot under Level 1 should understand the limited assurance model.

Gap 3 – This is a strong point. There should be clearer expectations around significant changes during the 12-month window. At minimum, guardrails should define what constitutes a material change and whether agencies must be notified or re-evaluate pilot use.

Gap 4 – Some flexibility is appropriate here. Given the elevated risk tolerance inherent in Level 1, FedRAMP should retain discretion to revoke status in material degradation scenarios without exhaustively enumerating every trigger.

Gap 6 – I strongly support clearer Marketplace labeling. Level 1 should be visibly marked as time-bound and pilot-only to prevent misinterpretation by agencies or procurement officials.

Gap 7 – I do not see this as ambiguous. The 12-month clock begins upon first agency ATO. Whether additional agencies join or whether the original agency continues use does not change the requirement: within 12 months, the provider must obtain full 20x Validation or lose the designation.

[TBailey223]

Excited about this one as well. In particular, I appreciate the benefit this will provide to CSPs to leverage prior investments and work in attaining other frameworks to reduce the time / cost to entry, without sacrificing security rigor.

[JustAnother3PAO]

Other international frameworks should also be considered as external frameworks for level 1, such as CCCS, IRAP, and ISMAP. Significant numbers of controls overlap and would be satisfactory for the use cases described in this RFC.

[cb-axon]

I do not support expanding the list to include frameworks such as CCCS, IRAP, or ISMAP.

Those frameworks are typically scoped to services operating within their respective national jurisdictions and often impose residency or boundary requirements that do not align with U.S. federal CONUS-focused deployments. In many cases, the assessed system scope would not match the boundary relevant to FedRAMP use.

Validated Level 1 should rely on frameworks that are broadly scoped to the full service architecture applicable to U.S. federal use cases. Expanding to geographically constrained frameworks risks creating mismatches in boundary coverage and increasing ambiguity around what was actually assessed.

[TrevorLowing]

Feedback: Leveraging External Frameworks for Level 1 Authorization

Thank you for RFC-0022 proposing a temporary Level 1 authorization pathway using external assessment frameworks (SOC 2, ISO 27001, HITRUST). I support rapid authorization pathways for low-risk services. However, RFC-0022 creates a CRITICAL legal ambiguity with FISMA § 3544 that requires DOJ/OMB clarification before scaling federal adoption.

---

CRITICAL: FISMA § 3544 Statutory Conflict Identified

The Conflict

FISMA Statute (44 U.S.C. § 3544(b)(3)):

"Agencies SHALL comply with minimum security standards 
consistent with standards issued by NIST"

RFC-0022 Proposal:

"Level 1 authorization allows CSPs to be authorized for 
federal use under SOC 2, ISO 27001, or HITRUST 
assessments (non-NIST frameworks) for 12 months"

The Problem:
Can an agency authorize a federal system to use Level 1 (non-NIST-assessed) services and still comply with FISMA § 3544(b)(3)'s mandate to use "NIST standards"?

Auditor Challenge Scenario

Federal inspector general (IG) or auditor reviewing Level 1 authorization:

Auditor: "Your system is authorized under FedRAMP Level 1 using SOC 2 assessment. But FISMA requires you to comply with NIST standards. Is SOC 2 assessment sufficient to meet FISMA's NIST standard requirement?"

Agency AO: "FedRAMP says Level 1 is acceptable for low-risk systems."

Auditor: "FedRAMP's position is not equivalent to statutory authority. FISMA statute says 'NIST standards' specifically. SOC 2 is not a NIST standard. Do you accept your system has a FISMA compliance gap?"

Agency AO: silence (legal review needed)

Legal Risk Assessment

Question	Answer	Risk
Does RFC-0022 directly contradict FISMA language?	No; FISMA allows agency judgment	MEDIUM
Can courts challenge Level 1 authorization as FISMA-non-compliant?	Possibly; statutory mandate for NIST is explicit	HIGH
Would IG audit find FISMA compliance gap in Level 1 authorization?	Likely; SOC 2 ≠ NIST standard	HIGH
Is statutory ambiguity ("NIST" = exclusive vs. "at minimum") the issue?	Yes; statute is ambiguous	CRITICAL

---

Recommendation #1: Seek DOJ/OMB Legal Opinion BEFORE Scaling Level 1

What Is Needed:
FedRAMP should request formal DOJ/OMB legal opinion clarifying whether Level 1 authorization under external frameworks (SOC 2, ISO, HITRUST) satisfies FISMA § 3544(b)(3)'s "NIST standards" requirement.

Specific Legal Questions for DOJ:

1. Does "consistent with standards issued by NIST" mean:

   • (a) Mandatory exclusive use of NIST standards (no external frameworks allowed), OR
   • (b) At least NIST standards, but agencies may use others if equivalent (RFC-0022 interpretation)?

2. If agency authorizes Level 1 service and IG finds non-NIST assessment, can IG conclude FISMA violation?

3. Does FedRAMP's PMO-approved Level 1 determination provide legal safe harbor for agencies adopting Level 1?

Outcome:

• If DOJ says (a) = FISMA-exclusive NIST: RFC-0022 Level 1 cannot proceed as written (external frameworks not permitted)
• If DOJ says (b) = agencies can supplement: FedRAMP must document equivalency basis (why SOC 2 ≈ NIST controls)
• If legal safe harbor granted: agencies can cite FedRAMP/DOJ opinion in audits (reduces IG risk)

---

Recommendation #2: If Proceeding, Require NIST Equivalency Documentation

If DOJ opinion permits external frameworks under FISMA, RFC-0022 implementation must include:

Equivalency Mapping Required

For each external framework (SOC 2, ISO, HITRUST), create FedRAMP-published equivalency document:

SOC 2 Equivalency Mapping to NIST SP 800-53

SOC 2 Trust Service Criterion: CC7.2 (Software Development Practices)
  Maps to → NIST SA-3 (System Development Lifecycle)
  Equivalency: PARTIAL (SOC 2 covers development; NIST requires documentation + evidence)

SOC 2 Trust Service Criterion: A1.2 (Entity Obtains/Maintains Understanding of IT Infrastructure)
  Maps to → NIST CM-9 (Configuration Management)
  Equivalency: PARTIAL (SOC 2 covers infrastructure understanding; NIST requires formal change control)

⚠️ GAPS IDENTIFIED:
  - SOC 2 does NOT assess: incident response procedures (NIST IR family)
  - SOC 2 does NOT assess: system monitoring/logging (NIST AU family)
  - SOC 2 does NOT assess: access control segregation of duties (NIST AC-2/5/6)

CONCLUSION: SOC 2 assessment alone is NOT equivalent to NIST Moderate baseline.
RECOMMENDATION: SOC 2 + additional agency-specific assessment required for Level 1.

Result

Agencies would use equivalency docs to justify "Level 1 (SOC 2) + agency-specific controls = FISMA-compliant system." Provides legal defensibility.

---

Recommendation #3: 12-Month Sunset + Transition Plan Mandatory

Agreement with RFC-0022: 12-month pilot for Level 1 is appropriate caution. However, implementation must include:

1. Hard deadline: No new Level 1 authorizations after [12 months from RFC-0022 effective date]
2. Transition requirement: CSPs already authorized at Level 1 must commit to full Rev5 or 20x authorization by deadline
3. No "pilot extensions": Don't extend Level 1 beyond 12 months without formal (difficult) process change
4. CSP contract language: Require CSPs to disclose Level 1 status to federal customers and include transition timeline in service agreements

Why This Matters:
Federal agencies will not risk deploying "surely temporary" Level 1 services if CSP can't guarantee Level 1 → Level 5+ transition. Sunset clarity is essential.

---

Recommendation #4: Restrict Level 1 Scope (Critical Gap in RFC-0022)

Issue: RFC-0022 doesn't specify what "Level 1" means in terms of system risk/scope. Could CSP use Level 1 for:

• Low-risk, non-sensitive SaaS? Yes (appropriate)
• Medium-risk unclassified system with PII? No (risk mismatch)
• High-impact system with sensitive federal data? Definitely not

FedRAMP Should Specify Level 1 Scope Limits:

Level 1 Authorization is limited to:
✓ Non-federal-data systems (CSP's own infrastructure, not containing federal data)
✓ Low-impact systems (FIPS 199 Low, or equivalent)
✓ Non-PII systems (if system processes PII, minimum Level 3 required)
✓ Non-sensitive mission systems (not critical to agency operations)
✓ Pilot/pilot-stage services (not production federal systems)

✗ NOT permitted for:
✗ Systems processing Personally Identifiable Information (PII)
✗ Systems processing CUI information
✗ Mission-critical systems
✗ Systems processing healthcare data (if compliance required)
✗ Systems with federal user accounts (authentication/identity requirements)

Success Criteria: FedRAMP publishes "Level 1 Scope & Restrictions" doc that agencies reference in authorization decisions.

---

Issue: First-Customer Risk for Early Adopters

Problem: Level 1 CSP with SOC 2 assessment has never been deployed in federal environment. Early-adopting agency becomes "first customer," bearing risk that production use exposes gaps SOC 2 assessment didn't catch.

Example First-Customer Risk:

• SOC 2 assessment validates availability (99.9% uptime)
• Federal agency adopts for non-critical pilot
• System fails to integrate with federal identity provider (SOC 2 didn't test this)
• Agency must revise architecture
• Level 1 CSP discovers federal environment has requirements SOC 2 assessment didn't anticipate

Recommendation:
FedRAMP should warn early-adopting agencies:

"Level 1 services have not been validation tested in federal operational environments. Early adoption carries integration risk that full FedRAMP assessment would have identified. Recommend pilot deployment (non-critical) first."

---

Closing

My Position: I support RFC-0022's goal of faster authorization for low-risk services. However:

1. DO NOT SCALE Level 1 until DOJ/OMB clarifies FISMA § 3544 statutory interpretation
2. IF PROCEEDING: Publish NIST equivalency mapping so agencies can defend Level 1 authorization in IG audits
3. ENFORCE: 12-month sunset; no extensions without major process change
4. RESTRICT: Level 1 scope to low-risk, non-sensitive, non-PII systems only
5. DOCUMENT: First-customer risk disclosure for early-adopting agencies

Recommendation:

• Pause RFC-0022 implementation until DOJ provides FISMA opinion
• Proceed in parallel with equivalency mapping doc so implementation can move quickly once legal question resolved
• Publish scope restrictions now (doesn't need legal opinion; operational guidance)

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

[cb-axon]

I disagree that RFC-0022 creates a FISMA conflict, and I think the audit scenario described misunderstands how RMF and FedRAMP actually operate.

Leveraging SOC 2, ISO, or HITRUST as evidence for a time-bound Level 1 package does not mean NIST standards are being ignored. Agencies are still issuing ATOs under NIST RMF. External assessments are inputs — not replacements — for NIST-based risk determinations. FedRAMP 20x KSIs themselves are not verbatim NIST controls, yet they can be mapped to NIST expectations. We do not write a narrative for every NIST control to “comply with NIST,” nor is that how FISMA has to work (nothing in the law says that). Auditors need to think deeper than “SOC 2 ≠ NIST, therefore non-compliant.” That is not how risk-based frameworks function.

It is also highly unlikely that a proposal grounded explicitly in OMB M-24-15 and NIST SP 800-37 authority was drafted without legal review. This is not a bypass of NIST standards; it is a structured, temporary authorization mechanism explicitly contemplated in federal guidance.

I do not believe a public one-to-one NIST equivalency matrix is required. NIST standards are frameworks, not rigid “all controls must pass” statutes. Agencies document risk acceptance. That is the compliance mechanism. Level 1 is explicitly low-impact and time-bound; defensibility comes from documented AO decision-making, not exhaustive crosswalk paperwork. This is exactly the kind of thinking that FedRAMP is trying to get the industry out of.

On the 12-month sunset, I agree guardrails matter. External frameworks should not be relied on indefinitely. However, if a CSP transitions to full 20x Level 1 within that window, pilot use can reasonably continue. The restriction should be on indefinite reliance on commercial artifacts — not on agencies exercising risk judgment during pilots.

Finally, scope limitations are already defined. Level 1 is low-impact, pilot-oriented, and bounded by FIPS 199 definitions (as determined by the agency when they are deciding what data they will put in this system during pilot). There is no need to reinvent those constraints here.

Overall, this pathway reflects practical risk management — not statutory evasion. The concern seems rooted more in misunderstanding of RMF mechanics than in an actual legal conflict.

[TrevorLowing]

You make some great points about AO discretion, and I think we actually agree on the theory. However, I’m looking at this from a different angle: the "view from the trenches" during an actual audit.

You’re arguing that the RMF permits this flexibility (I agree). My concern is whether an agency AO can actually defend it when an IG auditor starts asking pointed questions.

---

The "Auditor in the Room" Problem

In my experience, "AO Discretion" sounds great until an auditor asks: "FISMA says you must follow NIST standards; you used SOC 2. Where exactly does this SOC 2 meet NIST Control AC-2?"

If the AO doesn't have a clear "gap map," they’re left guessing. I’m not asking for a line-by-line crosswalk, but AOs need to know what they are not getting with SOC 2 so they can document that they are accepting those specific holes. Informed risk acceptance is defensible; "blind" risk acceptance is an audit finding waiting to happen.

---

What would actually help AOs?

If we want agencies to actually use this Level 1 pathway, we should give them three simple tools:

1. A Legal Safe Harbor: A quick memo from OMB/DOJ stating that using Level 1 for pilots is officially deemed "FISMA compliant." This ends the argument with the auditor immediately.
2. A "Gap Map": A high-level cheat sheet showing which NIST families SOC 2 covers well and where it’s thin. This lets the AO say, "I know SOC 2 is weak on Personnel Security, but for this 6-month pilot, I’m okay with that."
3. Clearer "Lane" Guidance: FIPS 199 is a start, but we should be explicit. If a tool has SSO integration or handles PII, it’s a different risk than a lunch menu app. Let's give AOs a "Green/Yellow/Red" guide for use cases.

---

Bottom Line

We both want the same thing: a FedRAMP that moves faster.

You’re looking at the policy (which is sound), and I’m looking at the implementation (which is where the "gotchas" live). If we give AOs the "ammunition" to defend their decisions, they’ll actually adopt this. Without it, the risk of an IG finding will keep most of them in the slow lane.

[Leah-GovRAMP]

GovRAMP supports the inclusion of GovRAMP Authorized and Provisionally Authorized as acceptable frameworks.

GovRAMP recommends the following amendments to RFC 22:

1) GovRAMP recommends that GovRAMP Ready and GovRAMP Core be included as acceptable frameworks.

GovRAMP Ready.
Although FedRAMP has proposed retiring its FedRAMP Ready status, GovRAMP Ready will remain a verified status within the GovRAMP Security Program. Several state agencies rely on GovRAMP Ready in a manner similar to a GovRAMP Authorization at a Low Impact level to demonstrate a product’s security posture. GovRAMP Ready requirements closely align with FedRAMP Ready Rev. 5 and include an independent 3PAO assessment. Unlike FedRAMP Ready, GovRAMP Ready products participate in monthly continuous monitoring coordinated through the centralized GovRAMP PMO, as well as an annual 3PAO assessment.

GovRAMP Core.
GovRAMP Core is the newest verified status in the GovRAMP program and is based on 60 NIST controls selected for their high-risk mitigation value using the MITRE ATT&CK Framework from Ready at a Moderate Impact Level. GovRAMP Core requires independent validation of evidence submitted to the GovRAMP PMO, including documentation frequently requested by participating governments—most notably the Incident Response Plan, Contingency Plan, Control Implementation Summary, and Customer Responsibility Matrix. Products with GovRAMP Core status participate in quarterly continuous monitoring and an annual reassessment with the GovRAMP PMO.

2) GovRAMP does not support restricting products that leverage external frameworks to the 20x path exclusively. Consistent with the flexibility provided in RFC 22, providers should be permitted to choose the path that best aligns with their readiness and business model—either Rev. 5 or 20x. Opening both paths (Rev. 5 and 20x) will help with the objectives mentioned in RFC-0021, Expanding the FedRAMP Marketplace.

Some providers may leverage alternative frameworks to serve federal customers and support FedRAMP’s goal of expanding the marketplace; however, they may not yet be prepared to commit to a 20x path until agencies demonstrate consistent acceptance of that approach. Limiting these providers to a single path could create unnecessary barriers to entry, particularly for small and medium-sized businesses, as well as for solutions that are not fully cloud-native.

3) GovRAMP welcomes this initial step and recommends that a next phase focus on establishing an accelerated path to higher FedRAMP authorizations where appropriate (e.g., GovRAMP Authorized – Moderate Impact to Level 3).

4) GovRAMP recommends excluding SOC 2 Type II as an acceptable framework because it does not provide the rigor, consistency, or ongoing assurance required to support risk-based authorization decisions. SOC 2 reports allow significant scoping flexibility, enabling service providers to exclude systems or controls, which can materially limit the depth and comparability of the assessment when compared to a NIST SP 800 53–based evaluation. In addition, SOC 2 is fundamentally a point in time, retrospective attestation and lacks a true continuous monitoring component. While reports may cover varying historical periods, they do not provide real-time or ongoing visibility into whether a provider continues to operate as attested. Continuous monitoring is a core value proposition of modern authorization programs—including the intent of the 20x approach—and without it, agencies lack the assurance needed to validate a provider’s sustained security posture over time. At a minimum, FedRAMP should ensure that they do not accept reports that have a “qualified opinion.”

5) Please clarify the statement: “Providers will be allowed to maintain FedRAMP Validated Level 1 status for up to one year from the first agency reuse of this FedRAMP authorization.” Specifically, is the one-year period triggered by the first agency reuse or the second agency reuse? And please define what happens after the one-year mark

[maseface-kimura]

We support leveraging GovRAMP as an external framework!

[joksenhe]

Thank you for providing a forum for comments and I appreciate the efforts of this RFC to make it easier for CSO's to get started and expand access for agencies. I'd like to offer a couple recommendations that could help.

I don't believe the named frameworks in MKT-LEF-ASF are similar in their alignment to federal requirements, and differentiating NIST 800-53-based frameworks from other pathways would be a positive step. GovRAMP-Authorized at the moderate level is based on an accredited 3PAO annual assessment, monthly continuous monitoring submissions, and is an 800-53 Rev5 control set that is over 98% identical to those selected for FedRAMP Authorized. I'd suggest products carrying that designation be granted a Certified Level 3 status for one year knowing that many agency products will be minimally at a Level 3 and these products are well prepared for an agency ATO.

I suggest that so long as Rev5 is still an option for agencies, the external framework route should not be limited to only pursuing a 20x status. Allow CSO's to leverage their heavy investment in Rev5 and recognize that they may be required to maintain Rev5 for non-Federal clients and forcing them into 20x, before it becomes ubiquitous in the federal space, will drive up costs even further.

[gguercio]

We support leveraging GovRAMP as an external framework. To add to Leah's comment about GovRAMP Authorized – Moderate Impact to Level 3, as a 3PAO that supports both FedRAMP and GovRAMP. Outside of the Red Team requirement and a few controls the testing rigor is very much the same between FedRAMP Tier 3 (moderate) and GovRAMP Authorized. To me this seems to be the most logical leveraging of all those proposed.

[cb-axon]

I appreciate the perspective shared regarding GovRAMP alignment and the rigor of its Moderate authorization process. There is no question that GovRAMP has invested significantly in aligning to NIST 800-53 and strengthening its assessment model.

That said, I would caution strongly against treating GovRAMP Authorized – Moderate (or any external framework) as directly equivalent to FedRAMP Level 3 or higher tiers.

The key distinction is not solely control alignment — it is governance, statutory authority, and enforcement structure. FedRAMP operates under federal law, OMB direction, and agency oversight mechanisms that do not apply in the same way to private or state-administered frameworks. Even where control sets are highly similar, the enforcement model, escalation paths, and accountability structures are materially different.

RFC-0022 works precisely because it limits reuse to Level 1 / LI-SaaS, time-bound pilot use cases. That scope acknowledges differences in framework rigor, review consistency, and oversight structures while still allowing practical reuse for low-risk scenarios. Expanding this into direct equivalency at Moderate risks creating a parallel authorization model that blurs federal accountability.

I also disagree with excluding SOC 2 solely on the basis of variability while simultaneously elevating other frameworks to Moderate equivalency. All assessments vary in quality; that is why the RFC requires explicit control mapping and disclosure of scope. Alignment to NIST 800-53 is helpful, but the existence of similar controls does not automatically create equivalency in authorization posture.

If a CSP has achieved GovRAMP Authorized – Moderate and believes it is substantially aligned to FedRAMP requirements, that investment should meaningfully reduce effort to generate full FedRAMP artifacts. Translating that work into FedRAMP-required documentation and pursuing full authorization is the appropriate durable path. Direct equivalency, however, would be a step too far in my opinion.

Level 1 reuse is a reasonable bridge. Formal Moderate reciprocity would materially alter the structure and risk posture of the program.

[EarlCrane]

I support GovRAMP’s comments on RFC 22 and strongly encourage FedRAMP to explicitly recognize validated external frameworks—particularly GovRAMP Ready and GovRAMP Core—as eligible on-ramps for the accelerated pathway. Both designations provide independently assessed, continuously monitored, and periodically reassessed security assurance aligned to NIST-based expectations, and they are already relied upon at scale by state and local government customers.

In addition, I also support GovRAMP’s recommendation not to constrain external frameworks to only the 20x path; providers should be able to choose the most appropriate route based on readiness and agency adoption realities. This has been demosntrated repeatedly through historical public-private partnerships and frameworks that less constraints encrouage innovation and mission and cost effective measures.

Finally, SOC 2 Type II should not be treated as an equivalent framework for federal risk decisions because it is scope and management-defined: it evaluates the provider’s described system and the controls the provider chose to design/operate. Guidance from the AICPA is intended to be broad and as a result, SOC 2 does not provide a consistent, comparable baseline suitable for standardized, risk-based authorization decisions in an accelerated pathway.

[cb-axon]

Overall, I strongly support this pathway. Validated Level 1 appropriately lowers the barrier for pilot use cases while still maintaining guardrails. That said, a few refinements would strengthen the external framework section.

First, MKT-LEF-ASF should require that listed frameworks meet a higher bar. For SOC 2 Type II, only unqualified opinions should be accepted. A qualified opinion should be a red flag even at Level 1. I fully support leveraging SOC 2 Type II here — it meaningfully assesses operational effectiveness over time and, in some areas (e.g., vulnerability management monitoring), goes beyond the point-in-time nature of traditional initial FedRAMP assessments.

Second, there should be a required attestation that the federal boundary to be authorized is fully within the scope of the external assessment. There is no guarantee that a SOC 2, GovRAMP, or HITRUST audit actually covers the specific systems or services an agency intends to use. Scope alignment must be explicit.

Third, these external assessments should be recent. I recommend requiring completion within the last six months prior to submission. If this is meant to support near-term pilot decisions, stale audit artifacts should not be acceptable.

For StateRAMP/GovRAMP, only full authorizations should qualify — not provisional or “progressing” statuses. The assessment must be complete and comparable in rigor to support even low-risk federal pilots.

Finally, I strongly support requiring CSPs pursuing this pathway to align with 20x exclusively. With the known sunset of Rev5, allowing new entrants to pursue legacy paths creates unnecessary fragmentation. If a provider has not already committed to Rev5, they should be building toward 20x. This keeps the program modernized and avoids dual-track complexity.

[pete-gov]

The following public comment was received via email from CoreWeave on Wed Feb 11 @ 2:45pm.

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	Requirement	Current Text	Comment	Proposal
0022	MKT-LEF-DFV	Providers MUST obtain a FedRAMP 20x Validation within 12 months of their FedRAMP Validated Level 1 cloud service offering receiving an agency Authorization to Operate.	The amount of effort (and associated timelines) to achieve validation is commensurate with the level being pursued. Instead of making this requirement be a flat 12 months across all levels, could we make it be based on the level pursued post-ATO?	20x Validation Level 2 - 6 months 20x Validation Level 3 & 4 - 9 months 20x Validation Level 5 & 6 - 12 months
0022	N/A	Corrective Actions: Requirements will be enforced under a 3 strike rule over the lifetime of a cloud service offering’s continuous Marketplace listing:	There may be failures during the Preparation phase but before the provider's final validation. Instead of making CAs last the lifetime of a cloud service offering, this could instead reset over time.	3 strike rule, but it resets every 3 years, or you "lose" one recorded failure each year, etc.
0022	MKT-LEF-ASF	Providers MUST have completed an external security assessment from the following list that is appropriately current and included an independent assessment from an appropriately accredited independent auditor as required by the framework: SOC 2 Type II ISO/IEC 27001 HITRUST e1, i1, r2 StateRAMP (dba GovRAMP) Provisionally Authorized, Authorized CMMC Level 2 FedRAMP Ready	Should we consider adding FedRAMP Certified Levels 2 through 6 to the list of approved frameworks in MKT-LEF-ASF? This would allow existing Rev 5 providers to 'bridge' into the 20x ecosystem by obtaining a temporary Level 1 Validation while they transition over. The KSI mappings already exist.	Should we consider adding FedRAMP Certified Levels 2 through 6 to the list of approved frameworks in MKT-LEF-ASF? This would allow existing Rev 5 providers to 'bridge' into the 20x ecosystem by obtaining a temporary Level 1 Validation while they transition over. The KSI mappings already exist.

[PTrier-Indie]

MKT-LEF-ASF Approved Security Frameworks

• I would recommend the removal of SOC II and ISO 27001. A correctly scoped and performed SOC 2 or ISO 27001 initial assessment has more controls and pushes for a better security posture than a Rev 5 LiSaaS. But, there is far too much variety in quality for these assessments in the current market. They also care far more about entity level controls than FedRAMP. HITRUST or PCI are more comparable to FedRAMP's approach and scoping.
• That does trim the pickings greatly. If FedRAMP wanted to keep SOC 2 and ISO 27001 as options they would need some form of trusted firm listing.
• Or allow trust firms that are currently 3PAOs, which would halve the amount of bad SOC 2's and ISO 27001's leveraged for this.

[cb-axon]

I would not support removing SOC 2 or ISO 27001 from the approved framework list, nor limiting their use to a subset of “trusted firms.”

While assessment quality can vary, that variability is not unique to SOC 2 or ISO. Restricting frameworks based on auditor type risks creating unnecessary barriers without solving the underlying scoping issue. Additionally, frameworks like HITRUST or PCI are often more narrowly scoped by design, intentionally limiting the systems assessed (e.g., to payment environments). In practice, a properly scoped SOC 2 Type II assessment frequently covers a broader portion of a service boundary than a tightly scoped HITRUST or PCI engagement.

It is also important to remember that this pathway is limited to Validated Level 1 / LI-SaaS use cases — low-impact, pilot-oriented deployments. Even within FedRAMP, rigor expectations at this level are lower by design. We are not establishing Moderate or High equivalency here. The intent is to enable time-bound testing under agency risk ownership, not to replicate full FedRAMP assurance through a different lens.

Rather than removing SOC 2 or ISO 27001, I would suggest tightening guardrails:

• Require SOC 2 Type II reports to have an unqualified opinion.
• Require assessments to be recent (e.g., completed within the last 6 months).
• Require explicit attestation that the federal service boundary is fully within the scope of the external assessment.

Those adjustments address quality and scope concerns while preserving the flexibility appropriate for Level 1 pilots.

[AetherHund29]

I think this RFC represents a thoughtful and pragmatic step toward implementing OMB Memorandum M 24 15 and accelerating agency access to low risk cloud capabilities. The FedRAMP Validated Level 1 designation appropriately balances reuse of existing commercial security investments with preservation of agency risk authority and time bound authorization conditions. Leveraging widely adopted external security frameworks for temporary pilot use is aligned with NIST risk management guidance and addresses long standing barriers to entry for innovative cloud providers serving limited or targeted federal use cases.

While the proposal intentionally does not establish formal reciprocity with external frameworks, it would be valuable to define a forward looking roadmap for structured reciprocity evaluation. As written, FedRAMP Validated Level 1 facilitates reuse of materials for Low impact pilot use but stops short of creating a scalable reciprocity model. Clarifying how FedRAMP will assess framework equivalency over time would support transparency and consistency and provide providers and agencies with clearer expectations.

In particular, consideration should be given to Moderate impact systems. Most federal mission systems operate at the Moderate level, and currently no transitional mechanism exists for providers that have already undergone independent Moderate equivalent assessments under frameworks such as GovRAMP Authorized, ISO IEC 27001, HITRUST r2, CMMC Level 2, or FedRAMP Ready. Establishing a controlled and time bound Moderate pilot pathway could meaningfully reduce duplicative assessment burden while preserving federal risk standards and agency decision authority. For example, a Moderate pilot designation could allow limited reuse of independently assessed NIST 800 53 Revision 5 Moderate aligned frameworks under enhanced continuous monitoring expectations, mandatory control mapping to FedRAMP requirements, and a defined transition period into full FedRAMP 20x validation. Such a pathway would not constitute blanket reciprocity but rather a structured bridge for agencies performing risk informed pilot deployments.

Additional clarification around the 12 month validation requirement would also be helpful. If a provider timely enters the FedRAMP 20x validation pipeline but final validation is pending due to PMO processing timelines or assessor availability, it would be beneficial to clarify whether that submission satisfies the transition requirement. Clear guidance would reduce uncertainty for agencies and providers and avoid unintended service disruption.

Further, publishing a transparent framework equivalency evaluation methodology would strengthen the implementation of Section V of OMB M 24 15. Defining how external frameworks are assessed for control coverage, independence rigor, continuous monitoring maturity, and enforcement mechanisms would create a scalable foundation for future reciprocity decisions and reduce ambiguity in how frameworks such as GovRAMP are considered.

Finally, additional guidance defining negligible or low risk use cases could improve consistency across agencies. Providing scenario based examples tied to FIPS 199 categorization or common deployment models would help Authorizing Officials apply this pathway in a more uniform and defensible manner.

Overall, this RFC is a strong step toward accelerating secure cloud adoption for low risk use cases. Expanding the proposal to include a defined Moderate pilot bridge and a transparent reciprocity evaluation framework would further advance the objectives of FedRAMP 20x while maintaining rigorous risk management standards.

[cb-axon]

I agree that RFC-0022 is a pragmatic step for low-impact pilot use, but I would caution strongly against extending this concept into a Moderate pilot bridge or structured reciprocity model.

The distinction between temporary reuse for Level 1 pilots and formal equivalency at Moderate is significant. Moderate impact systems represent the majority of federal operational environments, and expanding external framework reuse into that tier would materially change the assurance model. Not all independently assessed frameworks — even those aligned to NIST 800-53 — operate under the same statutory authority, enforcement structure, or governance oversight as FedRAMP.

Validated Level 1 works precisely because it is tightly scoped, low-impact, and time-bound. Moving toward Moderate pilot reciprocity risks creating a parallel authorization regime that blurs accountability and fragments the federal authorization model. If a provider has already undergone a rigorous Moderate-aligned assessment under another framework, the durable path remains translating that work into full FedRAMP artifacts and pursuing formal authorization.

On the 12-month transition requirement, I believe that responsibility appropriately rests with the CSP. If a provider elects to pursue the Level 1 pathway, they should already be planning assessment timelines with a 3PAO and accounting for FedRAMP’s published review targets. Unbounded extensions due to lack of planning would undermine the time-limited nature of the construct.

That said, it would be reasonable to clarify that if a CSP has completed a full initial assessment, received a positive recommendation from a 3PAO, and submitted within PMO service-level targets, they should not be removed from the Marketplace solely due to PMO processing timelines. In that case, maintaining their pilot designation until a validation decision is made would be a practical and fair approach.

I support leveraging external frameworks as an entry signal. I do not support formalizing Moderate reciprocity or expanding this into a broader equivalency regime.

[tvolpejr-vitg]

FedRAMP PMO,

I appreciate the opportunity to provide comments on RFC-0022 regarding the proposed FedRAMP Validated Level 1 designation and the temporary pathway leveraging external security frameworks.

I strongly support the proposed approach to accept widely recognized external security frameworks as part of a time-limited authorization mechanism. This is a pragmatic and strategically aligned step that advances the objectives outlined in OMB Memorandum M-24-15 to accelerate federal access to secure commercial cloud technologies while preserving agency risk ownership.

In particular, I would like to express specific support for the inclusion of GovRAMP (formerly StateRAMP) as an approved external framework under MKT-LEF-ASF.

GovRAMP is already closely aligned to FedRAMP in several important respects:

Control Baseline Alignment
GovRAMP leverages NIST SP 800-53 controls and mirrors the structural approach of FedRAMP Rev. 5 baselines. The technical overlap particularly at the Low and Moderate impact levels substantially reduces the interpretive and architectural gap between frameworks.

Independent Assessment Rigor
GovRAMP requires independent third-party assessments conducted by accredited assessors. The evidence packages, security assessment reports, and continuous monitoring expectations are materially similar in structure to FedRAMP artifacts.

Public Sector Relevance
Unlike more commercially oriented frameworks such as SOC 2 or ISO/IEC 27001, GovRAMP was purpose-built for U.S. public sector risk environments. As such, it more naturally accounts for government threat models, data handling expectations, and transparency requirements.

Maturity Signaling
A provider that has achieved GovRAMP Authorized or Provisionally Authorized status has already demonstrated organizational maturity in implementing NIST-based controls, maintaining documentation, and undergoing recurring audit scrutiny. Leveraging that investment meaningfully reduces duplication without materially increasing risk for Low-impact pilot use cases.

The inclusion of GovRAMP therefore represents a rational reuse of existing assurance artifacts rather than a dilution of standards. It enables qualified providers to enter the federal ecosystem more efficiently while preserving the expectation that full FedRAMP 20x Validation must be achieved within the prescribed timeframe.

[cb-axon]

I appreciate the points raised regarding GovRAMP alignment and agree that it represents one of the closer structural parallels to FedRAMP among external frameworks.

That said, I would caution against expanding the role of any external framework beyond the limited, time-bound pilot intent described in RFC-0022. These frameworks can provide meaningful signals of maturity and alignment, but they do not operate under the same statutory, enforcement, and governance structures as FedRAMP. Not all assessments are created equal (as noted multiple times in these comments), and assurance depends not only on the control set but on how it is reviewed, enforced, and overseen.

For that reason, I strongly support leveraging external frameworks ONLY for Validated Level 1 (IE low-impact), pilot-oriented use cases with explicit time limits. If a provider has achieved GovRAMP Authorized status and demonstrates substantial alignment, it should not be difficult to translate that work into full FedRAMP artifacts and pursue full authorization within the defined transition window, if the program is as equivalent as some say.

Leveraging GovRAMP as an entry signal for a pilot makes sense to me. Treating it as functionally equivalent to full FedRAMP authorization would not, given the difference in motivations and oversight.

[pdudek-3PAO]

I support the overall initiative of FedRAMP Validated Level 1, with revisiting the list of frameworks under MKT-LEF-ASF. Obviously not all frameworks are built the same and the quality and consistency of those reports within some frameworks on the commercial side can vary. Other NIST based frameworks listed such as GovRAMP have undergone a full traditional Rev 5 baseline assessment and reviewed/authorized by the GovRAMP PMO and should be given credit towards a FedRAMP Marketplace listing. CMMC Level 2 certification would also translate well for FedRAMP Level 1 considering the rigor and needing to meet all 110 practices within 800-171.

[cb-axon]

Would CMMC level 1 be likely to consider the same scope as the FedRAMP Minimum Assessment scope? In my experience, no, since CMMC is often more focused on corp-type systems, than the Cloud system itself.
I'd also consider adding to the standard the path for new frameworks to get added, as well as at least some indicators that may trigger a framework to get removed, and what happens in that instance? IE all pilots in process using that standard must cease, or they are grandfathered in until full authorization timelines, as already required by the standard?

[CSP-AB]

CSP-AB submits the following comments:

MKT-LEF-ASF Approved Security Frameworks - External security assessments

• Please be explicit on any timing requirements in regards to when the assessment must have been completed to leverage.

MKT-LEF-ASF Approved Security Frameworks - SOC 2 Type II

• Suggest changing this to a SOC 2 TYPE II with an unqualified opinion.

[cb-axon]

Fully agree here, and supportive of keeping SOC 2 Type II as leveraged and keeping any external frameworks limited to pilots for Level 1 (or equivalent FedRAMP levels as the standard comes out). We think those external frameworks should just be limited so that there is less potential for abuse, like someone got a SOC 2 Type II 2 years ago and didn't renew it, or got a qualified SOC 2 indicating concerning problems.

[drewmk]

The initiative allowing Federal agencies to pilot new cloud services is an excellent step toward opening the FedRAMP market to emerging providers and lowering barriers of entry.

To ensure the initiative's success, the FedRAMP program should provide additional guidance on the transition from an active pilot to a full authorization path, as well as the expected outcomes once a pilot concludes.

Furthermore, the FedRAMP program should more clearly define "Authorizing individuals." The current language is broad, ranging from a CIO to any civil servant. Without specific directives, agencies are likely to default to the most risk-averse approach, typically CIO involvement, which may slow the process.

[AbnormalMary]

FedRAMP’s effort to leverage widely adopted commercial frameworks is a pragmatic step toward accelerating access to modern cloud services. In that context, we believe it is important to distinguish between frameworks that meaningfully validate security posture and those that primarily validate documentation.

SOC 2 Type II is a management-scoped attestation engagement conducted by an independent CPA firm under AICPA standards. While it provides valuable assurance for commercial customers, it does not establish a uniform, government-aligned security baseline comparable to FedRAMP. As such, it should be treated carefully within this pathway and so as not to be viewed as equivalent to a government-aligned authorization framework.

We are encouraged to see the inclusion of GovRAMP, which is more directly aligned with government security requirements and provides stronger structural comparability to FedRAMP expectations. Clear differentiation among external frameworks will be important to ensure agencies fully understand the risk posture associated with FedRAMP Validated Level 1 offerings.

[cbiggsrun]

Comments from Fortreum:

1. Summary section, second paragraph: I suggest giving this a more helpful name like “FedRAMP Pilot Level”. Validated Level 1 is not a helpful label.

2. Summary section, third paragraph: This states that “This process does NOT establish “reciprocity” with any external framework…” In our minds, this means this standard is not as useful as we thought it would be because reciprocity between other frameworks is what CSPs wanted.

3. MKT-LEF-ASF Approved Security Frameworks section: The certifications listed (SOC, ISO, HITRUST, etc.) would have been done on a CSP’s commercial environment, not the FedRAMP environment, and thus would not be applicable because the FedRAMP environment is usually different from commercial. And CSPs generally are not keen to spend money to achieve other certifications for their federal environment because FedRAMP is the highest bar.

4. MKT-LEF-MAP Mapping to Key Security Indicators section: See previous comment. CSPs’ commercial environments are different from their FedRAMP environment, so trying to map existing certifications to KSIs would not indicate the appropriate level of security (or risk) that an agency would need to know before using the federal CSO.

5. MKT-LEF-IVV Independent Verification and Validation section: This seems to imply that a CSP would pay to have a 3PAO test the controls in the report AGAIN (after it was presumably tested before as part of that SOC or ISO audit). Most CSPs would not appreciate the additional costs.

6. MKT-LEF-DFV Deadline for FedRAMP Validation section: This states that providers MUST obtain a FedRAMP 20x Validation within 12 months of their FedRAMP Validated Level 1 cloud service offering receiving an agency Authorization to Operate. This seems to be saying that if a CSP already has an agency ATO, they would try to achieve a FedRAMP Certification and must go through a FedRAMP 20x validation as well. I don't see the logic in this since an agency ATO is the holy grail for CSPs.

7. MKT-LEF-ATO Authorization to Operate Notification section: This seems to imply that an agency can give an ATO to a CSP who used a SOC or ISO report from their commercial environment and met the 20x KSIs. Is this in line with what agencies want?

[cb-axon]

2. I agree with the RFC as written. These external frameworks should not be treated as equivalent to FedRAMP. That is precisely why this pathway is limited to Level 1 and time-bound pilot use. Recognizing that external frameworks provide some value to unblock low-risk testing makes sense. Establishing formal equivalency with frameworks that do not operate under federal statutory authority does not.

3. I disagree with the assumption that these certifications are inherently inapplicable because they were performed on “commercial” environments. Many CSPs — including some of the largest — operate FedRAMP authorizations on commercial infrastructure. Not all providers maintain fully separate federal stacks. These pilots are clearly intended for CSPs entering the federal market, not those who already architected federal-only environments from day one.

4. same point — the purpose of mapping is transparency. If scope differences exist, they should be disclosed. That does not invalidate the model; it reinforces that Level 1 is a pilot, not full authorization.

5. this section is explicitly optional (“MAY”), so it does not create an additional mandatory cost burden.

6. I believe there is a misunderstanding here. This requirement seems to apply to CSPs leveraging the external-framework Level 1 pathway. If a CSP already has a full FedRAMP authorization, this pathway is irrelevant to them. Once full FedRAMP validation is achieved, they exit the Level 1/external framework construct entirely.

7. yes, agencies may choose to issue a pilot ATO based on the defined Level 1 criteria. If they are uncomfortable doing so, they are not required to issue an ATO. That is the core design principle — agency risk ownership remains intact. Scope alignment between commercial and federal deployments is a CSP–agency scoping matter, not a reason to categorically exclude frameworks like SOC 2, since they CAN include the environment the agency would utilize.

Level 1 is intentionally narrow. It should remain that way. Expanding it to equivalency or restricting it based on generalized assumptions about commercial environments would undermine the balance the RFC is trying to strike.

[Rene2mt]

I strongly support this proposal. It meaningfully reduces barriers to entry into the FedRAMP ecosystem while appropriately leveraging prior security investments and independent assessments made by CSPs.

I recommend explicitly including FedRAMP Moderate Equivalency within requirement MKT-LEF-ASF. While it may be implied under CMMC Level 2, explicitly naming it would eliminate ambiguity and provide clearer guidance to CSPs and assessors.

Additionally, the final guidance should clarify expectations for evidence recency (e.g., testing performed within the past 12 months). Clear recency criteria will help ensure equivalency determinations are based on current security posture rather than legacy assessment artifacts.

Overall, this is a pragmatic step toward expanding participation without reducing rigor.

[Alliancefordigitalinnovation]

The Alliance for Digital Innovation (ADI) appreciates the opportunity to comment on RFC-0022, Leveraging External Frameworks.

We support the goal of improving efficiency and accelerating secure cloud adoption by recognizing external frameworks where appropriate. FedRAMP Validated Level 1 has the potential to serve as a useful innovation accelerator, but its long-term credibility will depend on clear limits, strong supply chain controls, and avoiding shortcuts that prioritize speed at the expense of consistent, scalable security outcomes.

We believe the KSIs for Level 1 provide a gap around supply chain risk. Given the prevalence of recent high-profile incidents exploiting software supply chains, foundational safeguards such as software integrity, visibility into third-party dependencies, and secure build environment practices should be incorporated. In addition, security awareness training and business continuity and disaster recovery planning should be included as well.

We also caution against characterizing certain cloud deployments as presumed “low risk.” We understand that agencies have the flexibility to make individual risk determinations. However, modern cloud systems are deeply interconnected through APIs, identity, and shared infrastructure. Even narrowly scoped deployments may create broader agency exposure depending on integration points and potential blast radius. We believe that a clearer articulation of how risk will be evaluated in interconnected environments would strengthen confidence in the Validated Level 1 designation.

Finally, the proposal to allow agencies to reuse a Level 1 authorization for higher-impact systems through “significant compensating controls” raises concerns about fragmented and inconsistent security postures that are hard to assess at scale. Services intended for Moderate or higher impact environments should instead progress through the appropriate FedRAMP authorization level pathway (either Rev 5 or 20x when available) to preserve clarity and consistency across the federal ecosystem.

Thank you for your consideration on this matter.

[PS-SEC-MSG]

RFC-0022: Leveraging External Frameworks
I appreciate the opportunity to comment on RFC-0022. I am submitting this feedback in an individual capacity as a FedRAMP Senior Assessor and Practice Lead who actively supports cloud service providers in meeting FedRAMP requirements and adapting to the FedRAMP 20x evolution. I support a temporary leveraged path for a time-limited authorization that allows agencies to pilot low-risk use cases while providers progress toward full FedRAMP 20x validation. To improve consistency, reuse quality, and enforceability, the comments below focus on eligibility evidence, mapping expectations, machine-readable requirements, timeline mechanics, and enforcement triggers.
Perspective: Senior assessor, implementation-focused, seeking objective and consistently enforceable requirements.

1. Terminology alignment with updated program labeling
   Comment/Question:
   RFC-0022 uses “FedRAMP Validated” and “Validated Level 1.” The RFC-0020 initial outcome indicates FedRAMP plans to use a single official label (FedRAMP Certified), avoid separate designations such as “FedRAMP Validated,” and avoid numbered “levels” in favor of Certification Classes.
   Proposed clarification language:
   • Update RFC-0022 terms to align with the final Consolidated Rules naming (for example: “FedRAMP Certified (20x pilot) - [class]” or equivalent), and include a one-sentence marketplace label definition agencies and providers can reuse consistently.
   • Publish a short crosswalk so agencies can map older “Validated Level 1” references to the new label.

2. Eligibility package: minimum evidence checklist
   Comment/Question:
   RFC-0022 requires leveraged materials be available but does not define a consistent minimum set of artifacts to prove eligibility across frameworks.
   Proposed clarification language:
   • Publish a one-page “Eligibility Evidence Checklist” that includes, at minimum:
   • Final report or certificate plus report period dates
   • Scope statement for the assessed boundary and explicit exclusions/carve-outs
   • Auditor identity and accreditation evidence (see item 4)
   • Bridge letter (or equivalent) describing any gap between report end date and submission date
   • Statement of exceptions (qualified opinions, limitations, unresolved items) and how they affect eligibility

3. “Appropriately current”: define time windows by framework
   Comment/Question:
   Multiple commenters raised concerns about stale artifacts and uneven rigor; without a defined “appropriately current” window, enforcement and agency reuse will be inconsistent.
   Proposed clarification language:
   • Define “appropriately current” using:
   • Maximum age since report end date at submission (by framework)
   • Maximum allowed gap between report end date and submission, with an allowed bridge-letter format for short gaps

4. Minimum quality gate for SOC 2 and similar attestations
   Comment/Question:
   The public thread has already debated whether SOC 2 belongs. Due to it’s overwhelming presence in the ecosystem, I believe it should be considered. If it remains eligible, the implementation risk is variability and scope mismatch.
   Proposed clarification language:
   If SOC 2 Type II remains eligible, require:
   • Unqualified opinion (explicitly state qualified opinions are not eligible for this leveraged path)
   • Report period within the “appropriately current” window
   • Boundary inclusion attestation (item 5)

5. Boundary and scope alignment: require an explicit boundary inclusion attestation
   Comment/Question:
   Existing comments highlight that external certifications often cover a commercial scope that may not match the federal offering boundary.
   Proposed clarification language:
   Require a short provider-signed attestation:

• “The service boundary described in this package is fully within the scope of the external assessment materials provided, except for the following explicitly listed components.”
• If there are out-of-scope components, require a standard delta table: component, reason out of scope, compensating measure, independently audited (yes/no).

6. “Appropriately accredited independent auditor”: publish an objective rubric
   Comment/Question:
   RFC-0022 references an “appropriately accredited independent auditor” but does not define acceptable evidence by framework or geography.
   Proposed clarification language:
   • Publish a framework-specific rubric stating:
   • What qualifies as an acceptable audit body per framework
   • What proof is required (certificate/registry link where available, independence statement)
   • How multi-site certifications are handled and mapped to the leveraged boundary
   • How non-US auditors are handled for international frameworks

7. KSI mapping: require a standard template and minimum field set
   Comment/Question:
   RFC-0022 requires mapping in narrative text with direct links and also requires machine-readable and human-readable formats. It does not define coverage states, citation rules, or minimum fields.
   Proposed clarification language:
   • Publish a mapping template with required fields per KSI:
   • Coverage status: covered, partially covered, not covered, not independently audited
   • Source citation(s): report section reference, evidence ID, pointer/link to authoritative artifact
   • Boundary applicability: in-scope, inherited, out-of-scope
   • Gap summary: what is missing; if supplemental evidence is provided, label it “not independently audited”
   • Brief generic example mapping entry
   • KSI: Incident Response Procedures
   • Coverage status: partially covered
   • Source: External report section X.Y; evidence ID IR-01; pointer to IR plan
   • Gap: External assessment validates existence/review; does not validate federal reporting timelines. Provider addendum labeled not independently audited.

8. KSI identifier stability and renaming
   Comment/Question:
   RFC-0022 indicates KSI names may change.
   Proposed clarification language:
   • Maintain stable KSI identifiers even if display names change; publish versioned mapping templates with a clear deprecation window.

9. Machine-readable format: specify schema, versioning, validation
   Comment/Question:
   RFC-0022 requires machine-readable mapping but does not specify formats or a validator.
   Proposed clarification language:
   • Define a canonical JSON schema for the KSI mapping (required fields, controlled vocabularies)
   • Allow CSV/YAML if losslessly convertible to the canonical JSON schema
   • Publish a lightweight validator/linter and schema versioning guidance
   (Also aligns with FedRAMP’s move to provide JSON schema + validation guidance elsewhere).

10. Submission procedure and “insufficient package” penalty: add a minor-fix path
    Comment/Question:
    RFC-0022 sets a 3-month resubmission penalty for insufficient/complete reports, but does not define “sufficient.”
    Proposed clarification language:
    • Define sufficiency by referencing the eligibility checklist and mapping template requirements
    • Add a short “minor fix” window for administrative issues (missing file, broken link) before multi-month penalties
    • Reserve multi-month penalties for demonstrably incomplete packages that prevent review
    (This matches FedRAMP’s stated intent elsewhere to avoid punitive penalties for minor correctable issues).

11. Timeline mechanics: define exactly when the 12-month clock starts and how recorded
    Comment/Question:
    The RFC ties the deadline to the first agency ATO reuse and requires agency notification to FedRAMP.
    Proposed clarification language:
    • Define clock start as the date on the first agency ATO letter that reuses the package, or the date FedRAMP receives the ATO notification (pick one for consistency)
    • Clarify what happens at 12 months: listing state change/expiration and whether agency ATOs remain agency risk decisions even if the listing status changes
    • Clarify what happens if there is no agency reuse (does the listing expire after a defined period)

12. Handling significant changes during the 12-month period
    Comment/Question:
    Multiple commenters flagged the gap: expectations for significant changes during the leveraged period are unclear.
    Proposed clarification language:
    • Require a lightweight change notice for significant changes that affect the leveraged boundary or mapped KSIs
    • Require mapping updates when a change impacts a KSI, and have agencies acknowledge the change notice as part of reuse decisions

13. Three-strikes enforcement: define triggers, attachment, reset rules, and dispute path
    Comment/Question:
    RFC-0022 applies three-strikes across the marketplace listing lifecycle and starts with public notification.
    General discussion indicates a need for clear definitions and processes so good-faith misunderstandings do not look like “breaches of trust.”
    Proposed clarification language:
    Define:
    • What constitutes a “failure” (missing eligibility artifacts, mapping nonconformance, missed conversion deadline)
    • Whether strikes attach to the offering listing, the provider, or both
    • Whether and how strikes expire/reset after sustained compliance (for example, lose one strike after N months)
    • A brief dispute/appeal path for interpretation disagreements

14. Optional IV and V: safe harbor wording and bounded scope
    Comment/Question:
    RFC-0022 states IV and V is optional. Packages and listings need consistent wording so “optional” does not become de facto required.
    Proposed clarification language:
    Publish standard “safe harbor” text such as:
    • “Independent verification and validation by a FedRAMP-recognized assessor was not performed. This package relies on the external framework assessment and provider attestations.”
    • If performed: “IV and V was limited to mapping completeness and traceability review. It did not include a full FedRAMP assessment.”

15. Agency reuse: publish a minimum package and a standard agency-facing summary
    Comment/Question
    RFC-0022 includes agency recommendations (review full materials, limit reuse to low risk) but does not provide a standardized summary artifact.
    Proposed clarification language
    Provide:
    • A minimum agency reuse package list
    • A standardized “agency-facing summary” template including scope, leveraged framework type, report date window, mapping highlights, explicit gaps labeled not independently audited, and conversion milestones

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/