FedRAMP 20x Class D Proposal: Check Hosting and Dependency Classes

An architecture diagram can show several certified services without answering which certification classes matter for each relationship. The proposed FedRAMP 20x Class D hosting dependency classes in RFC-0036 deserve two separate checks: the infrastructure hosting the offering, and third-party resources likely to handle federal customer data.

As checked on October 26, 2026, RFC-0036 presents these changes as proposals for the Phase 4 Cloud-Hosted pilot. The two clauses below are not an adopted architecture migration deadline. Use them to identify planning questions while keeping current applicable rules separate.

Compare the two proposed clauses

The RFC's hosting and third-party provisions have different force, class lists and objects. Class B's appearance in the third-party clause does not expand the hosting clause's C/D infrastructure list. Neither clause says every dependency has to be Class D.

Keep the proposed SHOULD force intact. FedRAMP's current definition of SHOULD allows valid reasons to depart in particular circumstances after weighing the implications, and requires a documented explanation of how such rules are handled. That definition explains the force word; it does not turn this proposed clause into an effective obligation.

Trace hosting separately from data handling

For architecture planning, create a working view with two questions for each relevant relationship. First, what exact IaaS or PaaS offering hosts this part of the service? Second, what third-party information resources are likely to handle federal customer data within the offering?

This is an editorial review method, not a prescribed FedRAMP inventory format. Useful fields include:

• The exact offering and service used, rather than only the supplier's company name.
• The hosting relationship and the evidence for its claimed certification class.
• The federal-data flow associated with a third-party resource, including why handling is considered likely.
• The evidence connecting that resource to the certified offering cited for it.
• An owner and an open question where the relationship or supporting evidence is unclear.

For example, suppose a planning diagram shows a Class C certified IaaS offering and a separate resource included in a Class B certified offering. The hosting class belongs in the CCH analysis. The other resource's relationship to likely federal-data handling belongs in the CTP analysis. One class label does not answer both questions, and this hypothetical does not establish that the complete integration has been assessed.

Keep the proposal's open edges visible

The CCH text includes a self-hosted or hybrid-hosted alternative, but the RFC explicitly says those rules do not yet exist and will be developed separately during Phase 4. It also excludes those tracks from this pilot. Treat that wording as an unresolved planning boundary, not an available exception to use now.

Likewise, Class G's appearance in CTP is part of the proposed class list. It is not evidence that a particular Class G offering is available for your dependency. Check the actual offering and supporting information before using a class claim in an architecture decision.

The RFC says it includes new or modified provisions and does not reproduce all existing Class D rules. Keep the broader applicable rule review alongside this narrow comparison. For a separate discussion of existing documentation work, see third-party resource impact records.

Use the resulting diagram to ask precise questions: which hosting offering supports the CCH analysis, which resources fall within CTP's likely-data-handling scope, and what evidence is still missing? That produces useful proposal feedback without treating proposed language as final architecture instructions.