RFC-0021: Expanding the FedRAMP Marketplace #111
Replies: 31 comments 10 replies
-
|
Two thoughts:
(emphasis mine). Really, all you can state is that it is intended to be included as a third-party resource in other CSOs. Whether or not it actually gets used is likely unknowable at this stage.
|
Beta Was this translation helpful? Give feedback.
-
|
Regarding question 2, I support maintaining a balanced structure that separates accreditation and recognition functions, allowing each body to focus on its distinct area of expertise. Previous experience has demonstrated that FedRAMP’s governance and appeals processes have been problematic for addressing 3PAO performance issues. |
Beta Was this translation helpful? Give feedback.
-
|
I strongly support inclusion of Indirect use. That visibility has been needed for a long time, as many CSPs primarily operate in indirect or government-adjacent roles. I agree that the language should focus on “intended to be included” rather than implying actual downstream use, which may not yet be measurable. Over time, it would be reasonable to require evidence of marketplace demand or integration interest from existing FedRAMP services, similar to prior prioritization models for the JAB. On advisory vs. assessment listings, I do not read this as superseding existing accreditation requirements. Advisory firms are not currently required to adhere to formal accreditation standards, but independent assessors are. Any assessor listed should still be required to maintain A2LA accreditation and existing FedRAMP recognition requirements. The attestation requirement appears additive to—not a replacement for—those standards. (Since we know the PMO won't respond/comment here, these are just my thoughts to your question). |
Beta Was this translation helpful? Give feedback.
-
|
+1 to both @wisecryptic and @cb-axon comments. To add, indirect customers (other commercial entities with business to government) tend to be much more for CSPs than direct customers (agencies) There are also additional indirect customers from reprocity of FedRAMP assessments - CMMC, Canadian Protected B, and GovRamp for State/Local/Tribal. |
Beta Was this translation helpful? Give feedback.
-
|
MKT-FRX-TAT Target Authorization Time Package review, historically, is subjective and there can be several rounds of discussions and resubmissions (even if not a formal resubmission, but a request for the PMO to review a single document and state acceptance/denial). CSPs should not be penalized for what they believe is a complete package, but the PMO reviewer still identifies issues (again, historically some of this has come down to grammar). MKT-GEN-DOD Demonstration of Ongoing Demand CSPs do not maintain a list of agencies requesting access to authorization data as it is stored in USDA connect and access is managed by the PMO. Additionally, via 20x, much of this information is going to be public and CSPs will not maintain a list of all people who have access the Trust Portal or CSP documents. MKT-GEN-SPI Service Pricing Information This is a bad idea. Costs are heavily dependent on features/services purchased including support and also may include discounts for specific customers. An "average" cost could be very skewed depending on a high number of variables. It may be best to simply include base-pricing instead, which should standardize all CSPs pricing information. While this is "up to the CSP" to implement, the Corrective Action is concerning. How often will this be required to be updated? |
Beta Was this translation helpful? Give feedback.
-
|
MKT-FRX-TAT – I agree the proposed penalty structure is too harsh. Package completeness has historically involved back-and-forth discussion, and what one reviewer considers sufficient may evolve over time. Some appeal mechanism or formal dialogue step should be built in before imposing a resubmission penalty, especially while industry adjusts to new expectations. MKT-GEN-DOD – USDA Connect is being sunset per related RFCs, and FedRAMP High CSPs already host their own authorization materials. Additionally, 20x does not require all materials to be public, and I haven't seen a CSP post some FedRAMP requirements like detailed contingency plans with contact information publicly. That said, demonstrating ongoing demand has not historically been difficult; sales engagement and active agency interest are typically evident. The requirement should align with realistic data sources rather than assuming CSPs maintain formal logs of every authorization package access event. MKT-GEN-SPI – I agree this requirement is problematic. Cloud pricing is highly variable and dependent on features, usage tiers, support models, and negotiated discounts. Publishing a generalized price risks misleading agencies and oversimplifying complex offerings. Even “base pricing” is often not meaningful across different architectures and service combinations. At minimum, strong disclaimers and flexibility are needed; ideally, this requirement should be reconsidered. |
Beta Was this translation helpful? Give feedback.
-
|
Gap #1 Gap #2 Gap #3 Gap #4 Gap #5 Gap #6 Gap #7 |
Beta Was this translation helpful? Give feedback.
-
|
Gap 2 – I agree this requirement is problematic. Cloud pricing is highly variable and dependent on features, usage tiers, support models, and negotiated discounts. Publishing a generalized price risks misleading agencies and oversimplifying complex offerings. Even “base pricing” is often not meaningful across different architectures and service combinations. At minimum, strong disclaimers and flexibility are needed; ideally, this requirement should be reconsidered. Gap 3 – I agree. Client relationships should not be forced into public disclosure where contractual or business sensitivities exist. Anonymized attestations or private verification mechanisms would better balance transparency and confidentiality. FOIA exposure concerns should also be addressed explicitly. Gap 5 – I agree with this recommendation. Some agencies explicitly request that their use or interest not be publicly disclosed, even outside classified contexts. The policy should allow anonymized or aggregated reporting of demand to respect agency preferences and procurement sensitivities. |
Beta Was this translation helpful? Give feedback.
-
Public Comment on RFC-0021: Expanding the FedRAMP MarketplaceFirst and foremost, we want to apologize upfront for the length of this comment. We are strong advocates of FedRAMP and genuinely enthusiastic about the modernization efforts underway, including the 20x initiative and the broader push toward transparency and efficiency. We believe the PMO is moving the program in the right direction, and we want to be constructive partners in that effort. That said, certain aspects of RFC-0021 raise significant concerns for our organization and, we believe, for the broader FedRAMP ecosystem. We felt it was important to articulate those concerns thoroughly rather than superficially. We hope this comment is received in the spirit it is intended: as a good-faith effort to improve the proposal, not to obstruct progress. Background: Advisory-Focused 3PAOsOur organization is a 3PAO on the FedRAMP Marketplace that focuses primarily on advisory services. We want to be transparent about our position: we have a financial stake in this discussion, and we recognize that some may view our comments through that lens. We ask that our arguments be evaluated on their merits regardless. When we pursued A2LA accreditation years ago, we did so with FedRAMP's full knowledge that we intended to focus on advisory work. FedRAMP listed us on the marketplace under this model, and we have operated transparently in this capacity ever since. Our clients engage us specifically because we offer the technical rigor of an accredited organization without the conflict of interest that arises when the same firm advises on and then assesses a security program. We raise this history because some may ask why an organization that focuses on advisory services sought accreditation as an assessor. The answer is that for many of our customers, the accreditation demonstrates technical competence, and technical competence matters for advisory work. We maintain full assessment capabilities and could perform assessments for the right client engagement. Our business focus on advisory services is a strategic choice, not a limitation of capability. FedRAMP's decision to list 3PAOs on the marketplace reflected an understanding that CSPs benefit from having access to conflict-free advisors with verified qualifications. That understanding appears to have changed, and we believe the change warrants careful examination. The Recategorization ProblemWe anticipate that FedRAMP may respond to concerns like ours by noting that advisory-focused 3PAOs are not being eliminated, merely recategorized. Under this view, we would simply move from the 3PAO listing to the Advisory Services listing, and business would continue as usual. Some may further argue that our A2LA accreditation remains intact regardless of marketplace listing, and that we can continue to display our credentials on our own website and marketing materials. If our value proposition is real, the argument goes, the market will recognize it without needing a government URL. This framing understates how the FedRAMP ecosystem actually works. For federal contractors, agencies, and CSPs navigating the authorization process, the FedRAMP Marketplace is not merely a directory. It is the definitive source of truth. When procurement officers evaluate potential service providers, marketplace presence and categorization carry significant weight. Being listed as a 3PAO signals that an organization has met rigorous, third-party-verified standards for technical competence. Being listed as an advisor under the proposed MKT-ADV-* requirements signals only that an organization has a website, three client attestations, and contact information. If 3PAOs who do not perform assessments (or have not yet) are removed from the 3PAO listing, it does not simply change their category. It signals to the market that they have been decertified or are no longer in good standing. It forces affected organizations to explain a negative ("We are still accredited, we just aren't on the list anymore") rather than proving a positive. The government creates the market conditions in the FedRAMP ecosystem; changing the labeling schema has consequences for organizations that built their reputations within the existing framework. For CSPs evaluating potential advisors, believe it or not, the 3PAO designation is often one of the deciding factors, as evident by many of our clientele. It answers the question: "How do I know this firm actually knows what they're doing?" If advisory-focused 3PAOs are moved into a category with no competency requirements, that signal disappears. CSPs would have no way to distinguish between a firm that invested years and substantial resources in earning accreditation and a firm that set up a website last month. Some may argue that the market can sort this out, that sophisticated CSPs can evaluate advisors based on track record and reputation without relying on accreditation. We respectfully disagree. The FedRAMP market includes many first-time participants who lack the institutional knowledge to evaluate advisor qualifications independently. These CSPs rely on marketplace signals precisely because they cannot yet distinguish between qualified and unqualified guidance. Removing the only objective quality signal does not empower the market; it leaves inexperienced buyers vulnerable to poor advice. Due Process and Equal Treatment ConcernsThe note under MKT-RIA-ATT states that "FedRAMP recognized independent assessors that do not actually perform independent assessments will be removed from the Marketplace to avoid confusion." We have significant concerns about how this determination would be made and applied. Lack of Defined CriteriaThe RFC provides no criteria, process, or evidentiary standard for determining which 3PAOs "do not actually perform independent assessments." Who makes this determination? What factors are considered? Is it based on historical assessment volume? A stated business model? Marketing language? The RFC is silent on these questions, leaving the decision entirely to the discretion of the PMO without any defined parameters or accountability. Equal Treatment ConcernsWe note that there are currently fifteen 3PAOs listed on the FedRAMP Marketplace with zero completed assessments. Some of these organizations are traditional audit firms that maintain their accreditation and qualified staff but have not yet completed a FedRAMP assessment for various business reasons. Others may be newer entrants still building their practice. Still others, like our organization, focus their business development efforts on advisory services while maintaining full assessment capabilities. Under the language of this RFC, all fifteen of these organizations could potentially be subject to removal. Yet we suspect the PMO's intent is more targeted. If so, the RFC should clearly articulate the criteria that distinguish a 3PAO that "does not actually perform assessments" from one that simply has not yet performed assessments, or one that performs assessments selectively, or one that focuses on advisory work while retaining assessment capabilities. Without such criteria, the PMO would be making subjective, case-by-case determinations about which accredited organizations deserve marketplace recognition and which do not. If two 3PAOs both show zero assessments on the marketplace, both maintain A2LA accreditation, both employ qualified assessors, and both pay their annual certification fees, on what basis would one be removed while the other remains listed? The RFC provides no answer. The result is a policy that could be applied arbitrarily, favoring some organizations over others based on factors that are neither disclosed nor subject to review. Accreditation vs. ActivityMost fundamentally, we question the authority and appropriateness of removing 3PAO marketplace status from an organization that maintains all accreditation requirements. Our organization holds current A2LA accreditation. We employ qualified personnel. We meet every technical and administrative requirement that FedRAMP and A2LA impose on 3PAOs. We recertify annually like every other accredited assessor. We have the demonstrated capability to perform assessments and would do so for clients whose engagements meet our terms. The fact that we focus our business development on advisory services does not mean we lack assessment capability. It means we have made a business decision about where to concentrate our efforts. That decision could change. A client with the right circumstances could engage us for assessment work, and we would be fully qualified to perform it. Focusing on advisory work is not the same as being incapable of assessment work, and the RFC conflates these two very different situations. By removing marketplace recognition from a 3PAO that maintains all requirements, FedRAMP would effectively be making a business judgment about how accredited organizations should allocate their resources. It would be telling qualified firms that their accreditation is insufficient unless they also generate assessment revenue. This goes beyond marketplace organization into active market interference, handicapping a private company's ability to compete for work despite that company meeting every objective qualification standard. Questions for FedRAMPWe would ask FedRAMP to consider:
We are not seeking special treatment. We are seeking clarity, consistency, and due process. If FedRAMP believes that 3PAO marketplace listing should be contingent on assessment activity rather than accreditation status alone, that represents a significant policy change that should be clearly articulated, applied uniformly, and subject to defined procedures. The current RFC language, which simply states that certain organizations "will be removed" without specifying how or why, does not meet that standard. Why Advisor Competence Serves FedRAMP's InterestsWe recognize that some within FedRAMP may view advisor qualifications as outside the program's scope. The argument is straightforward: FedRAMP's statutory mandate is to authorize secure cloud services for the federal government. The program accredits assessors because the government relies on their testing to make risk decisions. Advisors, by contrast, work for CSPs, not the government. Under this view, it is not the government's role to certify, accredit, or tier private-sector consultants. We would offer a different perspective, one grounded in the practical realities of the authorization pipeline. The "Garbage In" ProblemThe PMO has long identified package quality as a significant challenge. Initial submissions frequently contain gaps, inconsistencies, and errors that require multiple rounds of revision before authorization can proceed. This "garbage in" problem contributes directly to the backlog that frustrates agencies, CSPs, and FedRAMP alike. Every deficient package consumes reviewer time that could be spent on well-prepared submissions. Poor advisory work is often the root cause. When a CSP engages an unqualified advisor, the resulting SSP, SAR, and POA&M reflect that lack of expertise. Controls are implemented incorrectly. Documentation fails to meet requirements. Boundary definitions create confusion. The assessor may identify these issues, but by then the problems are baked into the submission. The PMO inherits packages that require extensive remediation. Qualified advisors produce better packages. Organizations with demonstrated expertise in NIST 800-53, FedRAMP requirements, and cloud security architecture guide their clients toward compliant implementations from the outset. The resulting submissions are cleaner, more complete, and easier to review. This is not speculation; it is the predictable consequence of engaging qualified guidance early in the process. By removing the distinction between A2LA-accredited advisors and firms with no verified qualifications, FedRAMP is not simply reorganizing a directory. It is eliminating the only quality filter that currently helps CSPs identify advisors likely to produce authorization-ready packages. The result will be more CSPs engaging unvetted advisors, more deficient initial submissions, and more strain on an already overburdened review process. Preserving a quality signal for advisory services is not about helping accredited firms sell services. It is about helping FedRAMP receive better deliverables. FedRAMP 20x Makes This Even More CriticalEverything we have described above applies to the traditional authorization process. With FedRAMP 20x, the stakes are higher. However, it also raises the technical bar significantly. Under the traditional model, an advisor's primary deliverables were documentation: SSPs, policies, procedures, and assessment-ready artifacts. Under 20x, advisors must guide CSPs through implementing automated evidence collection, configuring systems to produce machine-readable compliance data, and architecting environments that can demonstrate security posture continuously rather than at a point in time. This requires genuine engineering depth, not just familiarity with NIST 800-53 control language. The margin for error also shrinks. In the traditional process, a human assessor could identify implementation gaps, ask clarifying questions, and work with the CSP to remediate issues before the package reached the PMO. The 20x model reduces that human review layer. Automated validation is binary: the KSI evidence either meets the requirement or it does not. If an unqualified advisor guides a CSP toward an implementation that cannot produce valid KSI evidence, there is no assessor in the loop to catch the mistake before it becomes a rejection. Put simply, 20x shifts more of the quality burden upstream, directly onto the advisory phase. The advisory engagement becomes the primary human touchpoint where implementation quality is determined. If that guidance is sound, the CSP enters the automated validation process well-positioned to succeed. If it is not, the CSP fails validation with less opportunity for human intervention to course-correct. We believe this makes the current moment particularly important for preserving quality signals in advisory services. As FedRAMP raises the technical bar through 20x, the need for qualified, technically rigorous advisors grows in proportion. We are concerned that lowering the barrier to advisory listing while simultaneously demanding higher technical sophistication from CSP implementations could work at cross-purposes, potentially slowing the very modernization effort that FedRAMP is working to accelerate. We raise this not as a criticism of 20x, which we genuinely support, but as a reason to be more deliberate, not less, about how the marketplace signals advisor quality during this transition. Why Advisor Competence Matters for CSPsThe MKT-ADV-* requirements establish no accreditation, certification, or technical competency standards for advisory services. We understand the appeal of a low barrier to entry: it encourages competition, avoids regulatory overreach, and lets the market determine which advisors succeed. Some may characterize a proposal for quality differentiation as gatekeeping, arguing that the only "good" advisors would be those wealthy enough to afford A2LA accreditation fees, while brilliant boutique consultants who know NIST 800-53 inside out would be locked out. We respectfully disagree with this framing. In cybersecurity, "trust but verify" is not gatekeeping; it is the baseline expectation. ISO 17020 accreditation is not merely paperwork. It ensures impartiality, technical consistency, and adherence to quality management standards. If a boutique firm is truly expert in FedRAMP requirements, meeting those standards should not be an insurmountable barrier. The accreditation process exists precisely to distinguish verified competence from self-reported expertise. The government relies on standards for virtually everything in the security and compliance space. Federal agencies require ISO 27001 certification for certain contractors. FedRAMP itself is built on NIST frameworks. The entire 3PAO program exists because self-attestation is insufficient for consequential security decisions. If standards matter for assessment, they should matter for advisory work as well, particularly given that advisors shape the security programs that assessors later evaluate. Lowering the bar to "anyone with a website and three attestations" does not democratize the advisory market. It degrades it. CSPs seeking qualified guidance would have no reliable way to distinguish verified expertise from confident marketing. Advisors Shape OutcomesAdvisors guide organizations through the entire FedRAMP journey. They help CSPs make foundational decisions about architecture, control implementation, boundary definition, and documentation. These early decisions shape everything that follows. An assessor evaluates a security program after it has been built; an advisor influences how it gets built in the first place. When an unqualified advisor provides poor guidance, the consequences compound. A CSP may spend months implementing controls incorrectly, developing documentation that does not meet requirements, or designing an architecture that cannot support the security objectives. By the time an assessor identifies these problems, the CSP has invested significant time and money in a flawed approach. In some cases, the CSP must start over. If FedRAMP requires rigorous accreditation for the entity that checks the work, it seems incongruous to require nothing for the entities that typically guide CSPs on how the work gets done. Conflict of Interest ImplicationsFedRAMP has long recognized the importance of separating advisory and assessment functions. Existing rules prohibit a 3PAO from assessing a system on which they provided advisory services. We acknowledge these safeguards and do not suggest they are being removed. Our concern is more subtle. If advisory-focused 3PAOs are recategorized into a listing with no quality differentiation, and if CSPs seeking qualified guidance cannot distinguish accredited advisors from unaccredited ones, the path of least resistance becomes engaging a 3PAO that offers both services. Those firms retain their accreditation signal. They can demonstrate verified competence. For a CSP trying to make a sound procurement decision, the 3PAO with both capabilities looks like the safer choice. The existing COI rules would still apply: the same firm could not advise and assess the same system. But the market pressure this RFC creates would push more CSPs toward firms that offer both services, increasing the likelihood of creative interpretations, staff rotations, or other arrangements that technically comply with COI rules while undermining their intent. We have seen these dynamics play out in other compliance markets, and we are concerned about replicating them here. Advisory-focused 3PAOs exist to give CSPs a third option: verified competence without the COI risk. Eliminating the quality signal that distinguishes this option does not eliminate demand for qualified, conflict-free advisory services. It simply makes that demand harder to satisfy. Concerns Regarding Advisory Service RequirementsRFC-0021 proposes that advisory firms listed on the marketplace "MUST have an appropriate web site that publicly shows...Types of consulting services offered, including a clear pricing structure." We wish to raise several concerns about this requirement. Statutory AuthorityWe note that the FedRAMP Authorization Act (44 USC 3607-3616) does not mention advisory services. The statute's scope is limited to cloud computing products and services, independent assessment services (defined as third-party organizations performing conformity assessments), and the authorization process itself. While FedRAMP may argue that marketplace listing is voluntary and therefore these requirements do not constitute regulation, we would ask for clarification on the authority under which FedRAMP proposes to mandate pricing disclosure for private-sector consultants who are not performing conformity assessments. Pricing Transparency and Complex EngagementsMore substantively, we question whether a "clear pricing structure" requirement serves CSPs well when applied to advisory services. We recognize and support the goal of price transparency. CSPs benefit from understanding the cost landscape before engaging service providers. However, the implementation assumes that advisory work can be meaningfully reduced to a published price list, and this assumption does not reflect how complex advisory engagements actually work. Not all advisory engagements are equal. A gap assessment for a mature organization with existing compliance infrastructure looks very different from a gap assessment for a startup building from scratch. A readiness engagement for a straightforward SaaS application differs fundamentally from one involving complex hybrid architectures, multiple interconnected systems, or significant engineering work to achieve compliance. Advisory firms that provide deep technical and engineering services cannot accurately represent their pricing in the same format as firms offering commoditized, checklist-driven consulting. The requirement for a "clear pricing structure" implicitly favors standardized, lower-touch advisory models. Firms that offer templated approaches can publish fixed prices because their scope is predictable. Firms that tailor their work to each client's architecture, maturity level, and specific challenges cannot meaningfully do the same without either understating their value or posting ranges so broad as to be uninformative. Practical Market EffectsWe are also concerned about the practical effects of published pricing on how CSPs evaluate potential advisors. In our experience, publishing price ranges can cause prospective clients to self-select out before understanding the value proposition. We have had multiple engagements where a CSP initially contacted us solely to satisfy their organization's "three vendor" procurement requirement, with no intention of pursuing our services because our published range appeared to exceed their budget. Yet once they had an opportunity to speak with us and understand our approach, they recognized the value and signed with us regardless of the initial range concern. This dynamic would be disrupted by a marketplace that emphasizes pricing as a primary comparison metric. CSPs browsing the advisory listings may filter or sort by price, dismissing higher-value providers before ever engaging in a conversation. The result is not better-informed procurement decisions but rather a race toward the lowest published price point, which often correlates with less thorough, less technical, and ultimately less effective advisory work. A Suggested AlternativeWe are not opposed to price transparency in principle. We simply observe that a requirement designed for commoditized services may not translate well to complex, engineering-intensive advisory work. A CSP comparing advisory firms based on a published price grid is likely comparing fundamentally different scopes, approaches, and levels of expertise, none of which the pricing field can convey. If FedRAMP's goal is to help CSPs make informed decisions about advisory services, we would suggest that qualitative information, such as areas of specialization, technical certifications, client references, and demonstrated expertise, may be more valuable than a pricing structure that cannot capture the variability inherent in serious advisory work. At minimum, we would ask that FedRAMP consider allowing advisory firms to indicate that pricing is engagement-dependent and available upon consultation, rather than requiring a public price list that may mislead more than it informs. Statutory ConsiderationsThe FedRAMP Authorization Act defines FedRAMP's scope around cloud computing products, services, and "independent assessment services." Advisory services are not mentioned in the statutory framework. We recognize that marketplace listing is voluntary. FedRAMP is not requiring advisory firms to do anything; it is simply setting criteria for who appears in a directory. Under this view, concerns about regulatory authority are misplaced. We would offer a practical counterpoint. The FedRAMP Marketplace has become the de facto mechanism through which agencies discover and evaluate cloud services and the firms that support them. For service providers, marketplace presence is not optional in any meaningful sense. Being unlisted, or being listed in a category that conveys no quality signal, has real market consequences that function similarly to regulatory exclusion even if they are not legally equivalent. We do not claim that FedRAMP lacks authority to organize its marketplace as it sees fit. We simply observe that the practical impact of these organizational decisions extends beyond mere categorization, and we ask that FedRAMP consider those impacts carefully. A Constructive Path ForwardWe recognize that our recommendation may appear self-serving. We are proposing a framework that would preserve a category in which we currently hold a competitive advantage. We ask that the proposal be evaluated on whether it serves CSPs, agencies, and FedRAMP's operational efficiency, not on whether it benefits us. We also understand the PMO's desire to ensure the "Assessor" list contains only organizations that actively perform assessments. When an agency or CSP clicks on the 3PAO listing, they reasonably expect to find firms that conduct assessments. Having some entries represent organizations that focus primarily on advisory work could create confusion and degrade the user experience. We take this concern seriously. However, we believe this is a categorization challenge that can be solved through user interface improvements rather than by removing qualified firms from the marketplace entirely. De-listing is a disproportionate response to what is fundamentally a labeling and filtering problem. Proposed Tiered FrameworkOur suggestion is a tiered approach to advisory listings, implemented through marketplace filters or distinct tabs: Tier 1 (Accredited Advisory) would include 3PAOs that maintain A2LA accreditation and focus primarily on advisory services while retaining assessment capabilities. These firms have demonstrated competence through the same process required of assessment-active firms and remain subject to ongoing oversight. Any organization willing to invest in accreditation could qualify for this tier; it is not limited to current participants. This tier could appear under an "Accredited Advisory" filter or tab, clearly distinguished from the "Assessment Services" listing while retaining recognition of verified A2LA status. Tier 2 (Non-Accredited Advisory) would include firms meeting the proposed MKT-ADV-* requirements without accreditation. This tier would remain open to any organization that meets the website, attestation, and contact information requirements. Benefits of This ApproachThis approach:
Some may argue that a tiered system adds complexity to a marketplace that should be simple. We would respond that meaningful distinctions are worth preserving, particularly when they help buyers make better decisions and improve the quality of submissions entering the review process. A marketplace that lists all advisors identically regardless of qualifications is simple, but it is not informative. The goal should be clarity, not just brevity. ConclusionWe support FedRAMP's efforts to improve marketplace transparency. We share the goal of helping CSPs find qualified assistance and navigate the authorization process more efficiently. Our concern is that the current proposal achieves the opposite of its intent. By recategorizing accredited 3PAOs that focus on advisory services into a listing with no quality threshold, and by creating no meaningful standards for advisory competence, this RFC would eliminate the primary signal CSPs use to identify qualified, conflict-free advisors. The likely result is not a more transparent marketplace but a less informative one, where CSPs either cannot distinguish qualified advisors from unqualified ones or default to engaging 3PAOs that offer both advisory and assessment services. The downstream consequences extend beyond market confusion. Unqualified advisors produce deficient packages. Deficient packages burden the authorization process. The authorization backlog grows. Everyone suffers. We also have serious concerns about the lack of defined criteria and due process for removal decisions. Fifteen 3PAOs currently show zero assessments on the marketplace. If FedRAMP intends to remove some but not others, the basis for that distinction should be transparent, consistently applied, and subject to review. Organizations that maintain all accreditation requirements should not have their marketplace status revoked based on undisclosed criteria or subjective PMO determinations. We believe FedRAMP can achieve its transparency and usability goals while preserving quality signals that serve CSPs, agencies, and the efficiency of the program itself. A simple UI solution, distinguishing "Accredited Advisory" from "Assessment Services" through filters or tabs, would address the user experience concern without the collateral damage of removing qualified firms from meaningful marketplace recognition. We would welcome the opportunity to discuss these concerns and explore alternative approaches. Thank you for considering this comment. We remain committed to supporting FedRAMP's mission and look forward to continued dialogue on these important issues. |
Beta Was this translation helpful? Give feedback.
-
|
" 
|
Beta Was this translation helpful? Give feedback.
-
|
MKT-GEN-DOD #2 "A list of all agencies that have requested access to authorization data, covering the period since the previous Ongoing Authorization Report" MKT-GEN-SPI |
Beta Was this translation helpful? Give feedback.
-
|
Very excited to see the benefits that come with the use of the FedRAMP "In Preparation" stage for Marketplace listing. This will allow CSPs to be listed on the Marketplace earlier, helping address the significant challenge of attaining a Marketplace listing via either FedRAMP In Process, which required sponsorship, or FedRAMP Ready, requiring a completed Readiness Assessment. This will reduce the cost of starting the FedRAMP Journey, which will expand the industry to even more providers. |
Beta Was this translation helpful? Give feedback.
-
|
I support this change to the Marketplace listings. |
Beta Was this translation helpful? Give feedback.
-
Feedback: Expanding the FedRAMP MarketplaceThank you for RFC-0021 expanding the FedRAMP Marketplace to include advisory services, 3PAO assessors, and implementation support vendors. I support increased transparency and vendor competition. However, the expansion introduces procurement and quality assurance gaps that FedRAMP PMO must address in implementation guidance. Critical Issue #1: Marketplace Vendor Quality Vetting Gap — FAR 15.304 Compliance Required (FAR 2.0 Context)Problem: RFC-0021 expands Marketplace to include three new vendor categories (Tier 3 = advisors, Tier 4 = implementation support). These vendors are listed but not vetting like CSPs are. FedRAMP does not validate advisor quality, implementation vendor capability, or conflict-of-interest. Impact on Federal Procurement: Current Gap: RFC-0021 is silent on whether Marketplace listing = quality approval or = just a vendor directory. Agency Context Feedback: Recommendation to FedRAMP PMO:
Success Criteria: Agencies can cite FedRAMP Marketplace qualification standards in RFQs instead of creating custom evaluation criteria. Saves procurement effort; increases standardization; aligns with FAR 2.0 goals to reduce acquisition burden. Issue #2: Conflict-of-Interest Vetting for Advisors — Privacy Act & FAR 3.704 Compliance (FAR 2.0 Transparency)Problem: Advisors on Marketplace may represent competing interests:
Federal Procurement Risk: Recommendation to FedRAMP PMO:
Benefit: Agencies can evaluate whether advisor conflicts affect agency procurement decisions. Marketplace listing becomes more trustworthy. This transparency aligns with FAR 2.0 modernization emphasis on digital disclosure and commercial best practices. FAR Citation: 48 CFR Part 3 (Improper Business Practices and Personal Conflicts of Interest) Issue #3: 3PAO Marketplace Expansion — Quality Variation Risk (SIN Multiple Assessor Management)Problem: RFC-0021 expands 3PAO listings on Marketplace (good: more competition, more transparency). But FedRAMP doesn't track which assessor completed which assessment. If one 3PAO's work is used across 50+ federal agencies, and that 3PAO's quality declines, how does FedRAMP identify affected authorizations? Real-world risk:
Recommendation to FedRAMP PMO:
FAR Citation: FAR 46.401 (Quality Assurance standards applicable to contractors) Issue #4: Implementation Support Tier — Who Validates Implementation Quality?Problem: RFC-0021 lists implementation support vendors on Marketplace but provides no quality validation mechanism. If CSP hires low-cost implementation contractor and results in non-compliant system architecture, who is liable? Example scenario:
Responsibility Question:
Recommendation to FedRAMP PMO:
Consider implementation vendor insurance requirement (E&O coverage) to protect CSPs/agencies. Issue #5: Pricing Transparency Risk — "Low-Cost Advisors" May Indicate Low QualityProblem: RFC-0021 publishes advisor pricing, which is good for transparency. But agencies may equate low cost with good value. If cheap advisor provides poor guidance, an agency authorization may be delayed or rejected. Agency Context Feedback: Recommendation to FedRAMP PMO:
This helps procurement officers trade cost vs. quality trade-off. Procurement Language Updates NeededFor agencies' RFQs, I recommend FedRAMP-provided templates for:
ClosingRFC-0021's marketplace expansion is operationally sound but requires quality and conflict-of-interest guardrails to work effectively. Without vetting and transparency on advisor quality/conflicts, the expanded Marketplace becomes just a larger directory—still requiring agencies to perform independent due diligence. Recommend FedRAMP PMO focus implementation guidance on:
Submitted by: Trevor Lowing (private citizen, personal capacity) |
Beta Was this translation helpful? Give feedback.
-
|
I disagree with several of the assumptions in these recommendations. Quick points:
Bottom line: RFC-0021’s Marketplace expansion should improve visibility for industry without being misconstrued as FedRAMP validation of third-party advisory/implementation quality. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with @TrevorLowing that the FAR cannot be ignored here. By making MKT-GEN-SPI a requirement for Marketplace eligibility, the PMO is creating a de facto procurement prerequisite. If a CSP is placed into 'indefinite Remediation' for withholding proprietary pricing data—data that they are legally protected from disclosing under FAR Part 12—then the FedRAMP PMO is effectively penalizing a provider for exercising their rights under federal law. We should keep the Marketplace focused on security validation (K.I.S.S.) and leave pricing transparency to the individual agency contracting officers who are already empowered by the FAR to conduct price reasonableness determinations." |
Beta Was this translation helpful? Give feedback.
-
|
MKT-GEN-DOD requires information to be included in the Ongoing Authorization Reports from Collaborative Continuous Monitoring in CCM-OAR-AVL. However, Collaborative Continuous Monitoring is currently optional as a Balance Improvement Release for Rev5 authorizations. Thus the requirement for MKT-GEN-DOD appears to make the optional CCM now required for Rev5 authorizations to be listed on the Marketplace (that is, if RFC-0021 were to be published and effective prior to CCM being required broadly). This should be adjusted or clarified to avoid any ambiguity, i.e., is CCM in fact a requirement (and not optional) in order to demonstrate ongoing demand to be listed on the Marketplace per MKT-GEN-DOD? |
Beta Was this translation helpful? Give feedback.
-
|
Overall, I strongly support inclusion of the Indirect classification (MKT-GEN-SOF Scope of FedRAMP). This has been needed since the program’s inception and better reflects how cloud ecosystems actually operate.
On MKT-ADV-ATT, the attestation requirement should allow limited public anonymity.
Finally, I have significant concerns about mandatory CSP pricing disclosures.
|
Beta Was this translation helpful? Give feedback.
-
|
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.
|
Beta Was this translation helpful? Give feedback.
-
|
Section MKT‑GEN‑SOF After reviewing this section, I recommend removing all content except the final note. Instead of listing specific use cases, it would be more effective to simply include a tag identifying CSPs that support direct agency use. The rationale is straightforward: Section: MKT‑GEN‑DOD I recommend removing this section entirely. Agencies using the product Agencies requesting access to authorization data If FedRAMP’s intent is to maintain an accurate and high‑quality Marketplace, a cleaner approach could be as follows: Section MKT‑GEN‑SPI – Service Pricing Information I’m pleased to see that the guidance allows for significant flexibility in how pricing can be represented. This accommodates the wide range of models used across CSPs. Some providers rely on highly customized pricing structures, while others may prefer simply linking to their existing GSA or marketplace listings. Still others will welcome the ability to present standardized, easily consumable package pricing tailored for agency customers. Section MKT‑PRE‑DLA – Deadline for Authorization Clarification: If a provider satisfies the requirements for the next phase during the 6‑month removal period, they should be reinstated immediately at that new phase (e.g., Agency Authorization or Prioritized) rather than waiting for the full 6‑month window to elapse. Section: Advisory Service Listings (General) I am very encouraged by the introduction of advisory service listings. This change has the potential to broaden the advisory ecosystem significantly and enable agencies and CSPs to access a wider range of expertise and better‑aligned solutions. The 3PAO itself Given this diversity, I recommend that FedRAMP maintains a unified advisor/3PAO list but adding optional labels or tags such as: Assessment Services Available – for advisors who actively seek or meet criteria to become a 3PAO Callout on the note describing a JSON schema to be provided: this will be useful. Within 3–6 months of launch, FedRAMP should consider running an AI‑based clustering or classification exercise to identify natural advisory categories emerging from real‑world service descriptions. These could then be added as tags (one‑to‑many), similar to how CSPs currently categorize their business offerings. Repeating this analysis annually would help FedRAMP stay aligned with the evolution of the advisory landscape. Documentation Advisors may also differentiate themselves through thought leadership. As a best practice, advisory firms should highlight on their websites: Open‑source projects they own or contribute to While these are strong indicators of expertise and investment in the FedRAMP community, they should not be required or ranked. Formalizing such criteria would risk Goodhart’s law—where the metric becomes the target and loses value. Section: MKT‑ADV‑ATT – Attestation Requirements I understand the intent to ensure that only active advisors are listed; however, it’s important to consider the long tail of highly specialized advisory providers. Many niche advisors offer deep, targeted expertise that can be extremely valuable to certain CSPs. In addition, some advisors—particularly boutique firms—may work with a single client for extended periods rather than supporting multiple CSPs simultaneously. This does not diminish their value or capability. While this may initially appear less orderly, it would broaden the advisory landscape and expose the community to more innovative, best‑of‑breed providers rather than only long‑established or dominant firms. |
Beta Was this translation helpful? Give feedback.
-
|
apologies for the length; The size and impact of changes warrant an in-depth review |
Beta Was this translation helpful? Give feedback.
-
Comment on MKT-GEN-PKOWe are strong supporters of the FedRAMP 20x program. We believe 20x will produce better security outcomes while significantly reducing the work required to achieve and maintain FedRAMP authorization. The combination of stronger security with lower administrative burden is exactly what the ecosystem needs. We want to see both industry and agencies move toward 20x as quickly as possible. That’s why we’re concerned about requiring CSPs to choose between 20x and Rev5 at this stage, while 20x remains in pilot and agencies have not clearly signaled when or how they will adopt it. Even though the PMO has stated that new Rev5 authorizations will be phased out in 2027, it is unclear whether agencies also intend to phase out Rev5 on a similar timeline. Today, agencies broadly accept Rev5. There is not yet comparable clarity around 20x acceptance timelines or processes from federal agencies. In that environment, asking a CSP to pursue only 20x and forgo Rev5 creates meaningful commercial risk for any provider serving the federal market. The structure of MKT-GEN-PKO reinforces this dynamic. As written, CSPs that pursue Rev5 retain a future path to transition to 20x (“a path for Rev5 Certified cloud service offerings to transition to 20x Validated will be available in the future”). However, CSPs that pursue 20x do not retain a pathway back to Rev5. This would be particularly harmful if a CSP receives procurement interest and sponsorship from an agency buyer that requires Rev5, but is prevented from proceeding due its existing 20x authorization. In effect, Rev5 offers optionality; 20x does not. This leaves CSPs with a hard choice:
Given this choice, it’s very likely CSPs will choose Rev5 as the lower-risk option. That outcome would likely reduce near-term 20x participation and, as a result, slow agency adoption as well. We understand that resource constraints may be driving the desire to require CSPs to choose a single path. That is a reasonable operational concern, and the PMO deserves sufficient resources to execute an initiative of this importance. At the same time, allowing CSPs to pursue 20x, in parallel with Rev5, should not be viewed as duplicative or wasteful. Broader 20x participation will accelerate ecosystem maturity, validate the security model in real-world deployments, and ultimately drive long-term time and cost efficiencies for FedRAMP overall. Our comments come from a place of wanting 20x to succeed and succeed quickly. More CSPs are likely to invest in 20x, and help drive agency adoption, if doing so does not jeopardize their current or future Rev5 pathway and associated business. Preserving that flexibility may be one of the most effective ways to accelerate 20x adoption across both industry and government. Thank you for the opportunity to provide input. |
Beta Was this translation helpful? Give feedback.
-
Comment in Support – MKT-GEN-PKO and Impact-Level ConsistencyWe support the concerns raised regarding MKT-GEN-PKO, particularly as they relate to perception and market dynamics during the transition to 20x. 20x and Rev5 support the same FIPS 199 Low, Moderate, and High impact baselines and align to the same NIST SP 800-53 control expectations, then they represent the same security outcome at each impact level. The distinction is in validation methodology - not in baseline requirements. A Moderate must remain a Moderate. A Low must remain a Low. A High must remain a High. Any structural requirement that forces providers to “pick a path” must be accompanied by explicit language in the Marketplace and guidance materials reinforcing that the two pathways are baseline-equivalent. Without that clarity, agencies and industry may interpret 20x as a different or riskier tier rather than an evolution in assurance model. We strongly support modernization through 20x. Ensuring that 20x is clearly positioned as producing the same impact-level security outcome - while improving assurance mechanics - is essential to accelerating adoption and avoiding unnecessary hesitation across the ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
We caution against any policy changes that would reduce the number of listed 3PAO providers. Maintaining a robust, diverse pool of 3PAOs is vital to the long‑term health of the FedRAMP marketplace. Limiting participation—intentionally or unintentionally—could disadvantage firms that are new entrants or that conduct only a small number of assessments per year, despite their capability and value. These organizations help expand capacity, foster innovation, and prevent concentration risks. A broader, more competitive 3PAO marketplace also directly benefits CSPs by increasing choice and helping moderate pricing when seeking assessment quotes. That said, we support the introduction of the Advisory Services Listings concept, as this is a constructive approach that preserves transparency and allows these firms to continue contributing expertise to the ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
In both the current and proposed marketplace, MKT-GEN-DOD remains a significant barrier to entry that many companies, including MaintainX, find difficult to navigate. Without a preexisting agency partnership, it appears that other agencies consistently prioritize offerings from entities that already have an agency in use. This trend continues to present challenges for organizations seeking to establish new footholds in this sector. |
Beta Was this translation helpful? Give feedback.
-
Posting Comments on Behalf of Fortreum, LLCComment 1Section: Summary, first bullet The RFC states that Cloud Service Providers may list a cloud service offering while preparing to obtain a FedRAMP Certification or Validation, but does not explain what Certification and Validation mean. Please either:
Comment 2Section: Summary, first bullet What about Agency Authorizations?
This should be clarified. Comment 3Section: FedRAMP Marketplace Listings (MPL) Process, first paragraph Despite the title, this section does not actually describe the process for:
The section should clearly outline entry criteria, maintenance requirements, and removal conditions. Comment 4Section: MPL Process, Target Response Time in General Define all possible Marketplace designations a CSP may hold, similar to how it was done in RFC-0020. Consider consolidating RFC-0020 and this RFC to reduce fragmentation and improve clarity. Comment 5Section: MPL Process, Target Response Time in General, Item 1 Does “Preparation” apply to both:
If so, what distinguishes:
Clarification is needed. Comment 6Section: MPL Process, Target Response Time in General, Item 2 What does “FedRAMP Validated Level 1” mean? Will submissions for other Validation levels also be listed? Comment 7Section: MPL Process, Target Response Time in General, Item 4 Can a CSP submit a Prioritization request for an Agency Authorization? Comment 8Section: MKT-FRX-TAT Target Authorization Time, first paragraph Does this section apply to:
The language appears focused only on Program Certification or 20x. Agency authorizations seem omitted. Comment 9Section: MKT-FRX-TAT Target Authorization Time, first paragraph What does “assessment” mean in this context? Is it:
The term should be clearly defined. Comment 10Section: MKT-FRX-TAT Target Authorization Time, second bullet The RFC states:
This effectively functions as a 3-month penalty, not a 1-month penalty. Consider renaming for accuracy. Comment 11Section: MKT-FRX-SUM Summary of Authorization Decision The text states:
This suggests FedRAMP is the authorizing authority. If this section applies only to FedRAMP Program Certification, clarify that. Summary of Listing Decision Comment 12Section: MKT-GEN-SOF Scope of FedRAMP The RFC states that providers MUST demonstrate that a cloud service offering is intended for direct use by agencies. How must this be demonstrated?
Clear evidence requirements should be specified. Comment 13Section: MKT-GEN-SOF Indirect Use If a CSP has only Indirect Use, what type of listing or authorization would they receive? Would this fall under FedRAMP Program Certification? Comment 14Section: MKT-GEN-DOD Demonstration of Ongoing Demand Does this requirement apply only to Direct Use CSPs? If Indirect Use CSPs are included, clarify how ongoing demand must be demonstrated. Comment 15Section: MKT-GEN-PKO Pick One: 20x or Rev 5 For transparency, FedRAMP should publish:
This would allow CSPs to make informed decisions. Comment 16Section: MKT-PRE-SUR Subset of Requirements How can a CSP:
…during the preparation phase, prior to initial 3PAO assessment? This appears operationally infeasible. Comment 17Section: MKT-PRE-DCP Demonstrating Continuous Progress How can CSPs provide quarterly reporting when:
The five listed reporting elements may not yet exist. Suggested AlternativeMeasure preparation progress using:
It should also be acknowledged that due to NIST control requirements, CSPs cannot simply “FedRAMP” their commercial environments. Separate compliant environments must be built, which requires substantial time and cost. Comment 18Section: MKT-ADV-WEB Website Requirements The RFC requires machine-readable and human-readable formats. What constitutes “machine-readable”?
Clear examples should be provided. Comment 19Section: MKT-ADV-ATT Attestation Requirements What if an advisor’s customers will not allow public attribution, even for positive feedback? Can attestations be submitted privately to the PMO? Comment 20Section: MKT-ADV-ATT Attestation Requirements, note The requirement states that at any given time there must be 3 attestations dated within the past 12 months. Concerns
Suggested Alternative
Comment 21Section: MKT-RIA-ATT Attestation Requirements, Corrective Action While a grace period is provided for independent assessors, no defined path back to FedRAMP recognition is included. Additionally: Should the same corrective action process apply to new advisory firms? Comment 22Section: MKT-ADV-ACI Attestant Contact Information This requirement mandates information that MKT-ADV-WEB makes optional. These two sections should be reconciled for consistency. |
Beta Was this translation helpful? Give feedback.
-
General Comment – MKT-GEN-PKO (Pick One: 20x or Rev5)We understand the intent of requiring providers to select either the Rev5 Certification pathway or the 20x Validation pathway to avoid duplicative effort. However, it is important to clearly state that Rev5 and 20x are intended to produce the same security outcome at each impact level. Both pathways align to the same FIPS 199 Low, Moderate, and High baselines and the same underlying NIST SP 800-53 control expectations, so the pathway is an implementation choice - not a different security tier. A Moderate must remain a Moderate. A Low must remain a Low. A High must remain a High. We recommend that the Marketplace explicitly clarify that the “Pick One” requirement is an administrative efficiency measure and does not represent a difference in impact-level control requirements or security outcomes. The focus should remain on impact-level alignment and continuous compliance—not on pathway distinction. |
Beta Was this translation helpful? Give feedback.
-
We Disagree On MKT-GEN-SOF Scope of FedRAMPWe respectfully disagree with the categorical exclusion of services used to meet CMMC requirements from the statutory scope of FedRAMP. The RFC states:
This framing incorrectly treats CMMC-related services as inherently outside the statutory boundary, without examining the legal status of the information being processed. Under 44 U.S.C. § 3506 and FISMA, federal information security requirements apply to information systems used or operated by an agency, or by a contractor on behalf of an agency. The statutory trigger is not whether a system is marketed to agencies or contractors. The trigger is whether the system processes federal information in support of a federal function. Controlled Unclassified Information (CUI) is federal information. It originates from a federal agency, remains subject to federal regulation, and is provided to contractors strictly for performance of federal contracts. When a cloud service stores, processes, or transmits CUI in support of contract performance, that system is operating on behalf of a federal agency within the meaning of § 3506. Describing a platform as “used for CMMC” does not alter the underlying legal status of the information. CMMC is a compliance framework established by DoD to safeguard CUI. It does not define whether a system falls within FISMA scope. The relevant question is whether federal information is being processed on behalf of an agency. Where CUI is involved, that condition is satisfied. Moreover, many cloud services that host CUI for contractors function as part of the broader federal information ecosystem. They support contract deliverables, data exchange, and reporting that ultimately interface with agency systems. In substance, these systems operate as contractor-managed components of federal information systems, even if agency personnel do not directly access them. FedRAMP’s statutory scope should therefore be determined by the nature of the information and the operational relationship to the agency—not by whether the service is described as supporting CMMC compliance. A categorical exclusion of CMMC-related services risks misapplying 44 U.S.C. § 3506 by focusing on customer type rather than federal information handling. Where a cloud service processes CUI in performance of a federal contract, it falls within the statutory boundary that FedRAMP implements. |
Beta Was this translation helpful? Give feedback.
-
We Support MKT-GEN-SPI Service Pricing InformationFor too long, the market has tolerated a “call for quote” default that limits transparency and slows acquisition. While complex enterprise pricing may require negotiation, the absence of publicly available baseline pricing creates unnecessary friction, disadvantages smaller agencies and contractors, and obscures meaningful comparison across offerings. The Marketplace should function as an accessible and informative resource. Requiring general pricing information improves market efficiency by:
The “call for quote” model often results in inconsistent pricing visibility, extended procurement timelines, and reduced accountability. While customized pricing remains a potential for large or highly specialized deployments, baseline pricing should not be treated as proprietary or opaque by default. We support the flexibility built into the requirement, which allows providers to determine the most appropriate way to present general pricing information based on their business model. This preserves commercial flexibility while setting a clear expectation of transparency. We also support the corrective action framework outlined in the proposal. Public notification and remediation status provide accountability while avoiding disproportionate consequences such as removal from the Marketplace or revocation of authorization. Increased pricing transparency strengthens the integrity of the FedRAMP Marketplace, improves acquisition outcomes, and encourages a healthier, more competitive federal cloud ecosystem. |
Beta Was this translation helpful? Give feedback.
-
Public Comment on RFC-0021: Expanding the FedRAMP MarketplaceThese comments are my own opinions and experiences - not of my employer(s). Gap 1 - Summary of Authorization Decisions should not be free text - instead be requirements based with common categorial rating.
Authorization decisions by PMO to be listed on Marketplace should be requirements based, not opinion based.
Why? Focusing on requirement-based agency assessments protects the FedRAMP PMO from legal disputes and FOIA sensitivities related to acquisition barriers. This shift also allows for simplified, categorical reporting for Gap 2 - Indirect use should remain only if another FedRAMP CSP uses another FedRAMP CSP as a dependency in its package(MKT-GEN-SOF Scope of FedRAMP)
The 'Indirect Use' designation should be clear language - Restricted to cases where a FedRAMP-authorized CSP utilizes another FedRAMP-authorized CSP as a functional dependency. Why? Gap 3 - FedRAMP PMO, not CSPs, should be responsible for tracking demand data for agency requested access to packages
It is out of bounds for a CSP to be tracking request data by agencies, when its a PMO responsibility under current title and authorities. Gap 4 - Conflict between MKT-GEN-SPI and FAR Part 12/15 regarding Commercial Product Pricing
CSPs should provide a link to how to obtain pricing information on their public page, or point of contact, for federal procurements. Gap 5 - Pricing Information Corrective actions needs to be defined with better language and a time period
If PMO is continuing to pursue the corrective action clause, the proposed corrective action places a Cloud Service Offering (CSO) into "indefinite Remediation" for failing to provide pricing data. However, the term "Remediation" traditionally signals a security vulnerability or a Plan of Action and Milestones (POA&M) deficiency. Using the same label for a missing URL as a critical security flaw may lead to "status fatigue" among Agency AOs, potentially causing them to overlook genuine security risks. Furthermore, it is of my opinion it should not be "indefinite", but at least 1 year, then a further consequence of FedRAMP Authorization is now threatened if PMO is intimate of keeping this corrective action. Why? While the requirement correctly notes that Certification or Validation will not be revoked, the "Remediation" tag is a significant red flag in the Marketplace. This could inadvertently block a CSP from being selected for a new agency ATO (Authority to Operate) based on a procurement technicality rather than a security failure. Instead of a generic "Remediation" status, suggest a distinct administrative flag, such as "Administrative Non-Compliance: Pricing Information Pending." This maintains the PMO’s goal of public notification without conflating business data with the security posture of the offering. Furthermore, allowing "indefinite" does not make this a requirement - but instead as a may verse the intent of a shall. Gap 6 - It should be optional on CSP Marketplace listing if a CSP supports 20x and/or Rev 5 until path from Rev 5 to 20x is clearly defined by PMO with an enforcement date.
Similar to the recent Rev. 4 to Rev. 5 transition, this requirement begins with an optional 'early-mover' phase before shifting to a clear, enforceable cutoff date. This ensures the industry has a predictable roadmap for compliance. This should include statuses such as |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for introducing the concept of advisory organizations in this RFC — this is a helpful addition and reflects how many CSPs actually navigate the authorization process today. One concern, however, is that the term “advisory” could quickly become broad enough that it doesn’t meaningfully help CSPs or agencies distinguish between firms with deep FedRAMP lifecycle experience and those providing more general compliance consulting. I like the positive attestation requirements in this regard but would also encourage FedRAMP to consider additional ways to promote transparency signals that help the market differentiate advisory maturity. For example, advisory organizations could be encouraged to disclose items such as:
These types of signals would give CSPs and agencies better insight into advisory depth without limiting participation. Overall, I support recognizing advisory organizations in the ecosystem and believe a transparency-based approach would really help this new marketplace designation be useful in practice. |
Beta Was this translation helpful? Give feedback.
-
|
MKT-FRX-TRT Target Response Time in General To ensure consistent interpretation, FedRAMP should provide clear definitions for what constitutes “insufficient” and “non‑qualifying.” |
Beta Was this translation helpful? Give feedback.
-
CSP-AB submits the following comments for RFC-0021General RFC-0021 Expanding the FedRAMP Marketplace
Summary – This RFC proposes expanding the FedRAMP Marketplace to better serve the entire FedRAMP community by changing the following:
Summary – All cloud service providers will be required to share general pricing information.
MKT-GEN-SOF Scope of FedRAMP Indirect Use: The product will be included as a third-party information resource in other cloud service offerings that are directly used by agency customers.
MKT-GEN-DOD Demonstration of Ongoing Demand: Providers MUST demonstrate ongoing demand and utility by including the following additional information as part of each Ongoing Authorization Report as required by FRR-CCM-01:
MKT-GEN-SPI Service Pricing Information - Providers MUST include general pricing information for the cloud service offering (or links to existing public pricing information) in their Marketplace data; this general pricing information should include the general price for services offered to agencies and to other customers if applicable. General Comment:
Issues and Concerns:
Recommendation:
MKT-ADV-ATT Attestation Requirements - Advisors MUST publicly maintain positive attestations from at least 3 cloud service providers that have used the consultant within the past 12 months and include them with the information required by MKT-ADV-WEB.
|
Beta Was this translation helpful? Give feedback.
-
|
RFC-0021: Expanding the FedRAMP Marketplace Perspective: Senior assessor, implementation-focused, seeking objective and consistently enforceable requirements.
Comment Key ambiguities include whether the listing obligation applies to the legal entity that holds recognition only, whether separately branded service lines require separate listings, and how FedRAMP will interpret "types of assessment services offered" (service categories, authorization designations, levels, and baselines). Proposed clarifying language
Questions:
Comment A workable approach is to require transparency about pricing model and bands, not negotiated deal terms. Proposed clarifying language
Questions:
Comment Without a canonical source of truth and a basic validator, this requirement will be difficult to enforce fairly. Proposed clarifying language
Questions:
Comment This also reduces the risk that attestations are used as marketing testimonials rather than structured signals. Proposed clarifying language
Questions:
Example short attestation template structure (illustrative):
Comment Proposed clarifying language
Questions:
Comment Proposed clarifying language
Questions:
Comment These clarifications will reduce confusion about who is responsible for delays and how attestations and listings are affected by provider status changes. Proposed clarifying language
Questions:
Personal capacity note: This comment is submitted in an individual capacity and does not represent any employer or organization. Matthew S. Graham, CISSP |
Beta Was this translation helpful? Give feedback.
-
|
MKT-GEN-SPI Service Pricing Information Additionally, pricing strategies are proprietary business information. Mandating their public disclosure in a security compliance registry encourages anti-competitive behavior and undercutting. Furthermore, it could inadvertently create a price collusion situation between competing vendors, all without adding any value to the security posture of the service. We respectfully request that the PMO reconsider this requirement. MKT-FRX-TAT Target Authorization Time MKT-GEN-DOD Demonstration of Ongoing Demand In addition, how does this requirement apply to Rev5 authorizations, given that it is implemented via the Collaborative ConMon BIR, which is optional at this time? |
Beta Was this translation helpful? Give feedback.
-
|
The advisory/assessor boundary requires more than separate web pages — and this RFC needs to say so. |
Beta Was this translation helpful? Give feedback.
-
|
Advisory track record should be measurable, not just attested. Three positive client attestations tells an agency nothing about scale, depth, or outcomes. What matters is how many CSPs a firm has guided through a completed authorization, across what impact levels, over what time period. FedRAMP should require advisory firms to disclose — in structured, machine-readable format — the number of engagements completed, authorization outcomes, and assessment levels involved. Firms that have done the real work will be distinguished from those that have done one engagement and collected three signatures. Positive sentiment is not a proxy for competence, and an unstructured attestation requirement produces a marketing directory, not a quality signal. The advisory subcategory taxonomy is absent and agencies will suffer for it. "Advisory services" in the FedRAMP context covers meaningfully different capabilities that should not share a single Marketplace label. At minimum, FedRAMP should distinguish between managed security service providers delivering ongoing operational functions, compliance engineering and acceleration firms building authorization packages and driving CSPs through the process, and strategic advisors helping CSPs make program-level decisions without delivering technical implementation. An agency or CSP searching for help cannot tell from the current framework whether they are hiring a firm that will build their Boundary or one that will write their policies. These require different capabilities, different vetting criteria, and should carry different listing requirements. |
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received via email from Coalfire on Thu Feb 19 @ 5:25PM. I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc. RFC-0021 Public Pricing Challenges Publicizing pricing structures for services is not something that FedRAMP should require and could be perceived as anti-competitive. Public pricing requirements often result in manipulative pricing structures that don’t reflect the actual costs of services. Providers already have contact information and there should be consideration for additional contact information related to quotes/pricing requests. Unnecessary External Influence FedRAMP should not dictate how a commercial company market themselves on their own websites. Most other standards bodies have rules against logos and what accredited organizations cannot do but they do not dictate how they manage their websites or marketing details provided on their website. Any requirements should be limited to the firms listing on the FedRAMP marketplace. |
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received via email from Salesforce on Thu Feb 19 @ 5:36PM. I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc.
|
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received via email from The Alliance for Digital Innovation (ADI) on Thu Feb 19 @ 11:34PM. I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc. RFC 0021 The Alliance for Digital Innovation (ADI) appreciates the opportunity to comment on RFC-0021, Expanding the FedRAMP Marketplace, and support efforts to enhance transparency and usability for agency customers. One requirement of this RFC is, “all cloud service providers will be required to share general pricing information,” accompanied by the statement that providers may determine the most effective way to meet this requirement given varied pricing models. While the intent of enhancing convenience for potential customers is understandable, the inclusion of general pricing information appears outside the core scope of a government cloud security authorization program. Neither the published RFC, the FedRAMP Authorization Act, nor OMB Memorandum M-24-15 explicitly require the FedRAMP PMO to collect and publish general pricing information in any form. Moreover, we are concerned that there is not a stated process for determining whether published pricing information is accurate. Agencies already have access to pricing information directly from vendors, through publicly available sources, or via established government procurement channels. We recommend formally working with GSA procurement teams to make that pricing data easily available through the FedRAMP marketplace to security professionals, mission owners, and information technology leaders. Without working across GSA to provide consistent, vetted pricing information, the FedRAMP PMO may introduce administrative burden (through duplicative validation processes) and potential confusion across the acquisition community. We commend that the RFC establishes a 12-month limit for cloud service providers listed in “Preparation” status. However, additional clarity regarding the objective criteria required to enter “Preparation,” as well as measurable milestones that demonstrate sufficient progress within that 12-month window, would strengthen confidence in Marketplace designations. Clearly defined entry and progression standards would enable agencies to distinguish between early-stage intent and demonstrable security maturity, thereby reducing the risk of premature adoption decisions while preserving the integrity and credibility of the Marketplace. Finally, ADI is concerned that the “Choose One” requirement (MKT-GEN-PKO) may artificially hinder the move towards FedRAMP 20x. We understand and support the idea that the FedRAMP PMO should not have to maintain multiple authorizations for one CSP, especially in the current fiscally constrained environment. That said, given that there is a pathway to move from Rev 5 to 20x and not the other direction, many people will choose Rev 5 as the less risky path to market if forced. In the short run, the more pathways available to new market entrants or even new products from current market participants would provide more rapid adoption of FedRAMP 20x. Additionally, we believe that agencies will determine - whether a CSP chooses one pathway or another - what requirements they need from CSPs in order to authorize them to operate within their organizations. A CSP decision to go with the 20x pathway may still result in that CSP being required to participate in a Rev 5 process if the agency decides that is how they want to manage their risk. We recommend that FedRAMP strike this requirement from this RFC. Thank you for your consideration on this matter. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
RFC-0021: Expanding the FedRAMP Marketplace
Status: Closed
Start Date: January 13, 2026
Closing Date: February 19, 2026
Summary
This RFC proposes expanding the FedRAMP Marketplace to better serve the entire FedRAMP community by changing the following:
This RFC is aligned with other concurrent RFCs that have additional detail on specific topics but have been published separately to encourage topic-specific comments:
Motivation
The FedRAMP Marketplace currently shows a small snapshot of the entire FedRAMP-related ecosystem, with cloud service providers needing to be close to the end of their FedRAMP journey to be listed while advisory services are completely ignored. This makes it difficult for agencies to understand the potential early progress of cloud service providers while making it unnecessarily confusing for cloud service providers trying to find help implementing FedRAMP.
Every month companies publicly announce with great fanfare that they are establishing programs to pursue FedRAMP Certification or Validation… then the rest of us hear very little about their progress. Often agencies reach out to FedRAMP to ask for the status of a company that made an announcement many months ago and frequently that company didn’t even tell FedRAMP about their plans! Creating a formal process with a low barrier to entry that allows companies serious about FedRAMP to indicate this on the FedRAMP Marketplace and to keep interested potential customers up to date is a strong win for everyone.
Adding an option for advisory services to be listed directly will similarly address a frequent request from industry - FedRAMP can’t recommend specific vendors or services, but we can at least ensure that everyone who takes FedRAMP advisory seriously is listed in a central Marketplace to help industry move faster.
FedRAMP Marketplace Listings (MPL) Process
The following requirements and recommendations apply to any cloud service offering listed in the FedRAMP Marketplace:
MKT-FRX-TRT Target Response Time in General
MKT-FRX-TAT Target Authorization Time
MKT-FRX-SUM Summary of Authorization Decision
MKT-FRX-PAD Publishing Activity Data
MKT-GEN-SOF Scope of FedRAMP
MKT-GEN-DOD Demonstration of Ongoing Demand
MKT-GEN-SPI Service Pricing Information
MKT-GEN-PKO Pick One: 20x or Rev5
Cloud Service Offerings in the Preparation State
The following requirements and recommendations also apply to ALL cloud service offerings listed in the Preparation state.
MKT-PRE-SUR Subset of Requirements
MKT-PRE-DCP Demonstrating Continuous Progress
MKT-PRE-DLA Deadline for Authorization
Advisory Services Listings
The following requirements and recommendations apply to all advisory services listed in the Marketplace.
MKT-ADV-WEB Website Requirements
MKT-ADV-ATT Attestation Requirements
MKT-ADV-ACI Attestant Contact Information
MKT-ADV-SWS Separate Web Site for Other Listings
FedRAMP-Recognized Independent Assessor Listings
MKT-RIA-WEB Website Requirements
MKT-RIA-ATT Attestation Requirements
Beta Was this translation helpful? Give feedback.
All reactions