RFC-0025 Retrospective on the Public Comment Process

[rhoesing]

RFC-0025 Retrospective on the Public Comment Process

❓ 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-0025 thread. Thank you!

Status: Open
Start Date: March 18, 2026
Closing Date: April 21, 2026

Summary

This Request for Comment (RFC) asks FedRAMP stakeholders to share their experiences with our public comment process over the past year to ensure we can continuously improve the stakeholder experience. FedRAMP has some specific areas of interest but the public is encouraged to share all thoughts.

FedRAMP is subject to strict limitations on this process such that many good ideas from the public for a more engaging or interactive process are unfortunately not on the table; it is still worth our time to hear your thoughts even if we may not be able to implement many suggested improvements.

Background & Authority

This RFC marks the 25th time FedRAMP has requested public comment on proposals and guidance since RFC-0001 (A New Comment Process for FedRAMP) was closed on April 2, 2025. This is an appropriate milestone to revisit this process in a retrospective that encourages the public to share their experiences of participating in this process with us.

FedRAMP has worked hard over the past year to clear traditional bureaucratic hurdles for government interaction with the FedRAMP community but is still limited by many existing laws and rules that govern these interactions. Much of our ability to engage the community is enabled by explicit authorities and responsibilities for FedRAMP that we have to reconcile with the broader laws and rules (such as the Administrative Procedure Act):

The Administrator shall: … (6) establish and maintain a public comment process for proposed guidance and other FedRAMP directives that may have a direct impact on cloud service providers and agencies before the issuance of such guidance or other FedRAMP directives;

44 USC § 3609 (a) (6) // The FedRAMP Authorization Act

To further the program’s goals, GSA and the FedRAMP Board should engage with industry, through the Federal Secure Cloud Advisory Committee (FSCAC) and other mechanisms as appropriate, to maintain a current understanding of industry technologies and practices, to understand where FedRAMP could improve its policies or operations, and to otherwise build a strong working relationship between the commercial cloud sector and the Federal community.

OMB Memorandum M-24-15, Section VIII Industry Engagement

All historical RFCs following this mechanism are available publicly along with the outcome from each RFC at our FedRAMP RFC page. FedRAMP has received 500+ comments on RFCs published to date.

Motivation

This feedback cycle has enabled critical changes during the process of developing guidance and directives, from small wording changes and clarifications, to proposed updates being reworked or scrapped entirely. Maintaining an effective process with high participation from those inside and outside the FedRAMP community is critical. We want to do what we can to improve and grow our public comment process within the constraints of existing rules and regulations.

Our core limitations include:

1. The comment period must be at least 30 days.

2. FedRAMP cannot influence public comment by responding to public comments while the comment period is open.

3. The opportunity to comment must be open to any member of the public.

4. FedRAMP must consider all public comments equally, whether it is submitted by a large trade organization, a well known cloud service provider, or a random individual.

5. All comments from the public must be publicly available.

Thankfully, we were not required to use the Federal Register - it does not provide a very good experience nor allow for discussion between commenters. We tried a few different approaches in 2023 and 2024 before settling on the current approach:

1. RFCs are published on the web at https://fedramp.gov/rfcs so that anyone can find and see them easily.

2. Primary comment and discussion is available via GitHub discussions in the FedRAMP Community due to its accessibility to the public and the fact that it is an authorized service for use by GSA.

3. Commenters who are not able to use GitHub may email the FedRAMP Director with their comment directly; comments received like this are then posted publicly to the GitHub discussions in the FedRAMP Community on the commenters behalf by FedRAMP.

Initially, this approach also included a public form where comments could be submitted, but this form was rarely used by commenters and required additional maintenance so it was retired after RFC-0018.

Retrospective Questions

FedRAMP would like to hear anything and everything that stakeholders would like to share regarding our public comment process. Some questions to spark initial comment include:

• Some stakeholders have indicated that they do not participate in public comment because they do not want their customers or partners to see what they think. What can FedRAMP do to mitigate this and encourage all stakeholders to participate?

• GitHub and email make anonymous posting difficult, should FedRAMP pursue additional anonymous options?

• How do you typically discover new FedRAMP RFCs? What can FedRAMP do to improve notifications to the community when new RFCs are posted?

• Is the 30-day comment period sufficient for you to internalize the proposal and coordinate a response?

• Have you used the separate “General Discussion / Q&A” threads for informal questions and discussion? Is the distinction between general discussion and public comment clear?

• Do you feel that your comments are genuinely considered by FedRAMP, even if the final policy doesn’t change exactly as you requested?

• Do the outcome summaries after an RFC, especially the recent notices on Initial Outcomes, sufficiently explain why certain feedback was or wasn’t incorporated?

[mjschroeder1]

From my perspective as a practitioner and advisor to stakeholders across all parts of the agency-sponsored process, the recent RFC and Public Notice process has been overwhelmingly positive. I'm highly supportive any time a regulatory or other authoritative body takes input from the public, focusing on industry inputs. When I can provide relevant input, I do so. I share the opportunity with SMEs and ask them to provide insight. I have done this before.

This was a functionally efficient, overall well-managed comment process. The public notice component was effective, thorough, and clear in responses - more so on each measure than nearly any other such experience I have had with public comments from a government entity.

That said, there are clear opportunities.

• Optional anonymity is critical. This seems to be a simple and critically basic obligation of a federal agency - to proactively provide protections for an individual's right to privacy while engaging with a process that is open to the public.

• I encounter RFCs and Notices by visiting the FedRAMP site, I encounter it in public discourse on social media like LinkedIn. I’ve just started utilizing the RSS functions.

• 30 days is insufficient for most organizations and contributors. There are potentially significant impact of the outcomes of the RFCs, especially these recent ones under discussion. More time is required for stakeholding organizations to become aware of the RFC; ingest, assess, respond; and align input with practical considerations related to operations.
  The FedRAMP Security Inbox and re-introduction of RSS feeds will have positive impacts for awareness.

• I have not used the separate General Discussion thread significantly - perhaps I should.

• From my perspective, FedRAMP considered inputs carefully and genuinely. For each, FedRAMP outcomes seem to be significantly aligned with inputs from the public which were within the scope and requirements. I spent time breaking the Initial Outcomes down into point-by-point outcomes and aligning them to the RFC proposals, in both narrative and as data, and how those differ to extant policies when applicable.
  To me, the explanation of the changes incorporated into and influencing the Initial Outcomes are remarkably clear, thorough, and even address concerns that were voiced by a singular commenter (which also aligns with the consideration of inputs).

I’m on the edge of my seat for further opportunities to engage with this process.

[Ken-Smith-Cisco]

FedRAMP has made impressive changes over the past 12 months given the tumultuous political climate and should be recognized for its efforts to modernize the program.

Some quick comments on the RFC's:

1. Too many. It was very challenging digesting, responding, and informing stakeholders of all the RFCs that were published. I hope that in future cycles there will be less or they will be more spread out.
2. I'm curious on how the PMO ranks comments and why it decides to change a policy from the initial RFC. For the RFC regarding posting CSP costs, Pete mentioned 98% of comments were against it. Is there an objective data point, or does the PMO just "take for consideration" comments?
3. It would be great to have a ~30/60 minute Q&A a week after the RFC is published so stakeholders can get immediate questions answered and that may foster better comments and engagement.
4. The separate discussion thread is great. Also appreciate the quick responses from the PMO.
5. Some policies in an RFC are more important/impactful than others. Would be great if the PMO identified some of those key items that they'd like stakeholders to focus on for comment.
6. Is there a way to have a comment page where stakeholders can respond specifically to a policy within an RFC? This would help, I think, in collecting objective data. For instance, let's say there is a way to comment on RFC-0021 MKT-GEN-SPI Service Pricing Information. If someone comments they do not want to do that, other stakeholders can simply upvote that without having to comment themselves. Kind of like the Supreme Court, where justices can simply "concur" with the majority opinion or someone can leave a comment dissenting, and that dissenting comment can be upvoted as well.

The PMO has done an incredible job communicating with all stakeholders and that is the most critical aspect of this transformative change for the program. Keep it up.

[ComplianceOps]

I support FedRAMP’s objective to improve transparency and modernize the RFC process. The current approach is a positive step; however, there are areas where accessibility and communication I think could be improved to ensure broader and more effective stakeholder participation.

1.  Accessibility for Non-Technical Stakeholders
   While GitHub is identified as an authorized platform for this process, reliance on a this platform may not fully address the needs of the broader FedRAMP stakeholder community. Many stakeholders interact with FedRAMP through more traditional communication and collaboration channels, and limiting primary engagement to tool that is primarily for developers may be unintentionally reducing participation.

This creates a practical barrier to participation, even when access is technically available, it may result in underrepresentation of key operational and compliance perspectives. Additionally, while an email submission option is available, it still relies on manual posting into GitHub discussions and does not provide an equivalent or intuitive engagement experience for non-technical users.

Recommendation:
Provide alternative submission methods (e.g., structured web form or simplified interface)
Ensure these methods offer a comparable user experience to GitHub-based participation

2.  Notification and Awareness Gaps
   The current model relies on stakeholders subscribing to GitHub repositories or relying on periodic summary communications. In practice, this can lead to gaps in awareness of:
   Newly published RFCs
   Comment periods and deadlines
   Final decisions and outcomes

Example: Certain requirement changes or expectations communicated through FSI broadcasts may not be easily discoverable or tied back to a formal RFC or notification mechanism, making it difficult for stakeholders to track when new requirements are introduced.

Recommendations:
Establish a centralized and authoritative notification mechanism (e.g., distribution list or subscription service)
Ensure all RFC-related updates are consistently communicated and traceable

3.  Fragmentation of Information Across Channels
   RFC-related information is currently distributed across multiple channels (GitHub, email communications, FSI updates), making it difficult to track the full lifecycle of an RFC.

Recommendation: 
Maintain a centralized location that includes:
RFC status (Draft, Open for Comment, Finalized)
Decision summaries
Links to discussions and supporting materials

4.  Lack of Structured Feedback Format
   Unstructured GitHub comments make it difficult to consistently capture and evaluate stakeholder input, particularly regarding operational and compliance impact.

Recommendation: 
Introduce a standardized feedback template capturing:
Stakeholder type (CSP, Agency, 3PAO)
Affected control areas
Operational/implementation impact
Risk considerations

5.  Limited Communication of Implementation Impact
   Final RFC outcomes are not always accompanied by clear guidance on how changes translate into operational requirements.

Example: When new expectations are introduced without clear implementation guidance or traceability to formal RFC decisions, organizations may only become aware of impacts during assessment or continuous monitoring activities, increasing the risk of reactive compliance efforts.

Recommendation: 
Include an “Implementation Impact” section in finalized RFCs outlining:
Required actions
Timeline expectations 
Affected artifacts (e.g., SSP, POA&M, ConMon processes)

Summary
While the current approach improves transparency, enhancing accessibility, notification, and structured communication would improve participation and help ensure more effective adoption across the FedRAMP ecosystem. Without these improvements, there is a risk that key stakeholder groups may not be reasonably positioned to provide input during the RFC process, which could impact downstream implementation and compliance alignment.

[adamlang-1kosmos]

The last batch of RFCs were my first interactions with the process as a new comer to the FedRAMP world.

Once I got the gist of it all, the interactions seemed rather simple (in a good way).

The separate discussion thread for discussion among FedRAMP representatives and stakeholders is a nice addition to democratize the RFCs. People can actually discuss and get clarification among the community before weighing in officially. Though I am currently on the fence about all the RFCs side-conversations being in one discussion thread. I would keep in mind it may not scale well if the active community size increases.

One thing I didn't like was that the result of an RFC (class name changes) had little to do with the actual RFC. It made the RFC feel bait and switchy.

[wisecryptic]

The RFC process has been a strong and continually improving process. Over its lifetime, it has incrementally matured in ways that benefit both contributors and FedRAMP.

• The general discussions and Q&A have been an excellent resource.
• FedRAMP has been consistently responsive to feedback.
• The new outcome documents are a welcome addition and genuinely helpful.

The standard 30‑day comment period is generally sufficient. Extending the period for the early‑2026 “batch” of RFCs was a smart decision—the size and complexity of that set clearly warranted additional time.

Anonymity remains an important option because it enables more candid and unfiltered participation. As you may have guessed, I think it is wise to be a little cryptic. When I share public comments, I use an “anonymous‑lite” approach, keeping them separate from business interests so that:

• I can express my best thinking without external pressures.
• My clients can be confident they won’t be incorrectly associated with the feedback.
• FedRAMP and other stakeholders avoid forming any unintended or unfair impressions about my clients.

One question going forward is how much of the discussion should shift left and what kind of feedback cycle should follow each document release.
Historically, FedRAMP has:

• Opened forum discussions
• Created various panels
• Held working group meetings

Shift‑left opportunities require more upfront effort, but early input tends to guide the conversation in the right direction and reduces overall rework. A recurring critique of past shift‑left efforts is that they sometimes over‑indexed toward the largest players and major consultancies, which occasionally produced outcomes that were less workable for the long tail of participants.
Another key element to preserve—something GitHub handles particularly well—is enabling commenters to interact with one another. This fosters community growth in an asynchronous and organic way.

[austinsonger]

1) “Some stakeholders don’t comment publicly due to customer/partner visibility—how to mitigate?”

• Allow “attribution options” while keeping comments public. For example: “Posted as Organization,” “Posted as Individual,” or “Posted as ‘FedRAMP Community Member’ (non-attributed).”

2) “GitHub/email make anonymous posting difficult—should FedRAMP pursue anonymous options?”

Yes—if it can be done without undermining the integrity of the process.

• A good compromise is pseudonymous posting with verification (FedRAMP validates the commenter is a real person/entity, but publishes without identity).
• Alternatively: allow “confidential identity, public comment”—FedRAMP retains the submitter’s identity internally for anti-abuse, but posts publicly without attribution.
• If true anonymity is not feasible, explicitly state that and provide a “low-risk” template for commenters who want to participate without exposing sensitive context.

3) “How do you discover new RFCs? Improve notifications?”

A few low-lift options that would help:

• An email listserv / newsletter specifically for RFC announcements (separate from general FedRAMP updates).
• An RSS feed (or Atom feed) for new RFC postings and for status changes (open/closing/outcome posted).
• A single GitHub “RFC Announcements” repo/discussion where each new RFC is posted as a release/announcement—many stakeholders already watch GitHub for notifications, but they need a single place to watch.

4) “Is 30 days sufficient?”

Often, 30 days is tight for organizations that need internal review, legal/comms review, and consolidation across multiple product teams—especially for technical baselines or broad process shifts.

• Consider using two-phase posting for complex RFCs:
  1. Preview / heads-up (non-comment period) to allow internal planning, followed by
  2. the formal 30+ day comment window.
• If two phases aren’t workable, provide a one-page RFC summary (what’s changing, who it impacts, what decisions are being made) to reduce digestion time.

5) “General Discussion / Q&A threads—clear distinction?”

The split is helpful, but it could be clearer operationally:

• Put a short banner at the top of each thread clarifying:
  • Public Comment thread = submit formal feedback (no FedRAMP responses during open period)
  • Q&A thread = informal discussion; FedRAMP may respond (if/when allowed)
• Link them bi-directionally so readers don’t miss the Q&A option.

6) “Do you feel comments are genuinely considered?”

When outcome summaries are detailed, yes. The biggest trust-builder is when FedRAMP:

• groups repeated themes,
• explains tradeoffs/constraints,
• and clearly says what changed (or why it didn’t).

7) “Do outcome summaries and Initial Outcomes sufficiently explain decisions?”

They’re heading in the right direction. Two improvements would make them even more actionable:

• Include a simple decision log table: Theme → Decision (Adopt/Partial/Decline) → Rationale → Resulting change location (section/link).
• Include a diff/changelog (even lightweight) so implementers can quickly see what materially changed from the draft.

Additional suggestions (optional)

• Provide a comment template (Impact, Recommendation, Rationale, Suggested Wording) to improve signal-to-noise.
• Add an explicit invitation for implementation examples (what would break, what would be unclear for 3PAOs, what would increase cost/time).
• Consider tagging RFCs by topic (ConMon, baselines, automation, 20x, etc.) to improve filtering and notifications.

[Lowebrew]

This is an independent opinion separate from my organizations`.

See the Question as "#.Q", and the addressing answers a "#.A"

1.Q: Some stakeholders have indicated that they do not participate in public comment because they do not want their customers or partners to see what they think. What can FedRAMP do to mitigate this and encourage all stakeholders to participate?

1.A: I personally find this odd, I have been open with my agencies and have even offered to help them write opinions to post on their behalf. I think these individuals that are in fear of such should reconsider and talk with their agencies and clients. Or if this is a real issue due to past behavior, create an anonymous GitHub to post under.

2.Q: GitHub and email make anonymous posting difficult, should FedRAMP pursue additional anonymous options?
2.A: I understand people don't want to create a throw away account for this, but I also have no other solution to offer for this besides reaching out to a trusted individual to post on their behalf.

3.Q: How do you typically discover new FedRAMP RFCs? What can FedRAMP do to improve notifications to the community when new RFCs are posted?
3.A: I watch Pete's & FedRAMP Linkedin, the FedRAMP site, and COOEY server. Just haven't set up GitHub alerts yet.

4.Q: Is the 30-day comment period sufficient for you to internalize the proposal and coordinate a response?
4.A: 60-day period just because I know many of us are juggling rev 5, 20x, and AI as not only ISSOs, but as 3PAOs in many cases too, along with other obligations. The extra time would help allow a little more time to process and respond. RFC-24 was a bit longer than 30 days which was great, though I missed the deadline myself.

5.Q: Have you used the separate “General Discussion / Q&A” threads for informal questions and discussion? Is the distinction between general discussion and public comment clear?
5.A: I have not, I prefer something similar to Discord forums, though I will make a better effort to use the discussion threads

6.Q: Do you feel that your comments are genuinely considered by FedRAMP, even if the final policy doesn’t change exactly as you requested?
6.A: I don't really care, I address RFCs with intentions of not only trying to reach out to FedRAMP, but also the community as I know there are others who read these comments.

7.Q: Do the outcome summaries after an RFC, especially the recent notices on Initial Outcomes, sufficiently explain why certain feedback was or wasn’t incorporated?
7.A: I feel these have improved over time but have no extra feedback to offer.

[vedigaurav]

Overall, the RFC process represents a strong example of iterative improvement done well. FedRAMP’s openness to feedback and its visible incorporation of that feedback has created a more collaborative and effective policy development model. Continued investment in accessibility, transparency, and stakeholder experience will only strengthen this foundation further. I believe other community members have already suggested some areas of improvements and echo their sentiments and feedback as listed below:

Encouraging Broader Participation: Optional anonymity or pseudonymous participation could meaningfully increase engagement. Many stakeholders balance customer, partner, and organizational sensitivities, and providing flexible attribution options (e.g., individual, organization, or non-attributed) would allow for more candid and diverse input while maintaining transparency.

Improving Accessibility and Usability: While GitHub has proven effective for many, it may present a barrier for less technical participants. Introducing a parallel, user-friendly submission method—such as a structured web form—could help broaden participation without replacing the existing workflow. A standardized feedback template (e.g., impact, recommendation, rationale) may also improve the consistency and quality of input.

Enhancing Awareness and Notification: The addition of RSS feeds and existing communication channels is a positive step. Expanding this with a dedicated RFC mailing list or centralized notification mechanism would further ensure stakeholders are consistently aware of new RFCs, timelines, and outcomes.

Refining Timing and Structure: The standard 30-day comment period works well in many cases, but for more complex or high-impact RFCs, additional time or a two-phase approach (preview followed by formal comment period) could improve the quality of feedback. This would better accommodate internal coordination across organizations.

Sustaining Community Engagement: The inclusion of general discussion and Q&A threads has been a strong addition, fostering collaboration and shared understanding across the community. As participation grows, ensuring these channels remain organized and scalable will be important to preserving their value.

Thank you for the opportunity to contribute and for the ongoing efforts to modernize and improve the program.

[WhalerMike]

Thank you for opening this retrospective. Twenty-five RFCs in a year is a substantial commitment to public engagement, and the structured GitHub Discussions format has been a meaningful improvement over traditional comment channels.

A few observations from the perspective of an organization building governance tooling that complements CISA assessment capabilities:

1. The RFC process works well for policy feedback but could better serve implementation-layer discussion.

The RFCs to date have done an excellent job of soliciting feedback on policy proposals (certification designations, marketplace expansion, leveraging external frameworks, etc.). What's less clear is how organizations building tooling that operationalizes FedRAMP and CISA requirements should engage with the program.

For example, BOD 25-01 mandates continuous monitoring integration with CISA infrastructure. ScubaGear provides the assessment mechanism. But between the directive's intent and the assessment tool, there's an implementation layer -- continuous drift detection, remediation orchestration, governance state management -- that vendors are actively building. The current RFC process doesn't have an obvious pathway for this category of feedback: it's not a policy comment, and it's not a product pitch, but it's directly relevant to how the community operationalizes FedRAMP and CISA requirements at scale.

Suggestion: Consider whether a periodic "implementation patterns" RFC or discussion thread could provide a structured venue for the community to share how they're operationalizing the policies that FedRAMP and CISA publish. This would complement the policy-level RFCs without conflating the two.

2. The relationship between FedRAMP RFCs and CISA directive implementation could be more explicit.

Several RFCs (particularly those touching continuous monitoring and configuration management) have direct implications for how agencies implement CISA directives like BOD 25-01. Making these connections explicit in the RFC context would help respondents provide more targeted feedback. The Rev5 CWG discussions on CM-2, CM-6, and CM-8 controls, for instance, map directly to the operational challenges agencies face in maintaining SCuBA baseline compliance -- but the RFC threads don't always surface that linkage.

3. CR26's machine-readable approach is a strong signal -- the RFC process should mirror it.

The move toward machine-readable, LLM-ingestible rulesets in Consolidated Rules 2026 is philosophically aligned with making governance itself more deterministic and automatable. As the rule structure becomes more machine-trackable, the feedback process could benefit from structured comment formats that make it easier to aggregate and analyze responses programmatically. This would also make it easier for the community to track how their feedback influenced final outcomes -- a transparency measure that would strengthen participation.

4. Equal-access-to-information principles are well-maintained -- continue this discipline.

The explicit statement that FedRAMP does not provide special answers to individual parties is exactly right, and the consistent application of this principle across the RFC threads builds trust. As the 20x program matures and more vendors engage, maintaining this discipline will be increasingly important.

Thank you to the FedRAMP PMO for this retrospective. The willingness to examine your own processes in public is itself a model for the transparency the program promotes.