FedRAMP 20x Class D Proposal: Test Four-Hour Metric History in a Tool

If you are comparing evidence platforms for a possible move to FedRAMP 20x Class D, ask the vendor to retrieve a history of observations, explain missing intervals, and reconcile that history with a summary. Use the demonstration to decide what your team would need to build, buy, or integrate.

As checked on October 17, 2026, RFC-0036 proposes changes for the Phase 4 Cloud-Hosted Class D pilot. Its four-hour metric history is proposed language, not a finalized new obligation for Class B or C. The demonstration below is our purchasing advice, not an official FedRAMP acceptance test.

What the Class D proposal says about history

Under the proposed SDR-CSX-KMT, Class D providers would include historical metrics in the Security Decision Record (SDR) for each applicable Key Security Indicator. The proposal specifies:

• A summary of each metric over the previous 30 days.
• A summary reaching up to the previous year, where available.
• Metric data at four-hour intervals, including persistent-validation status, reaching up to the previous year, where available.

The accompanying note suggests supplying this history through an API as a supplement to the main SDR. Separately, proposed CDS-CSX-API would require responsible delivery of all machine-readable parts of the certification package through a web-compatible API. These provisions appear in RFC-0036's SDR and Certification Data Sharing sections.

For comparison, the published SDR-CSX-KMT text uses SHOULD for Class B historical summaries and MUST for Class C history, including daily metric data and persistent-validation status up to the past year where available. Its Class D text says providers must significantly exceed lower-class minimums, with specifics to be set during the Phase 4 pilot. Keep this published baseline separate from the proposed four-hour detail when preparing your evaluation brief.

Keep metric history separate from execution cadence

RFC-0036 separately proposes, under VDR-TFR-MVX, machine-resource verification and validation at least once every three days. The four-hour language in SDR-CSX-KMT describes metric data; it does not state that every KSI validation must execute every four hours. Read the two proposed provisions separately.

For a buying demonstration, ask the vendor to distinguish the time an observation describes, the time a check ran, and the time the platform received the result. Ask how its history represents an unchanged status between executions. Record the explanation and sample output so your engineering and assessment teams can evaluate that design. Do not accept an unexplained timestamp as proof that a new validation ran.

Prepare a small, explicit history sample

For this FedRAMP 20x Class D metric history tooling evaluation, choose one representative measure and a short test window. Our suggested fixture is a two-day series with a known status change, one deliberately missing interval, and one late-arriving observation. Use synthetic test data and label it as such.

Agree on the expected records before the demonstration. We recommend recording the offering identifier, measure identifier, observation time, check execution time, ingestion time, reported status, and a reference to the underlying evidence. These are suggested evaluation fields, not an official schema.

Ask the vendor to show how it distinguishes an observed unchanged value, a carried-forward value, and unavailable data. For the missing interval, request an explicit gap rather than a silently invented successful observation. For the late arrival, compare the original response with the later response and document how the correction can be recognized.

Use the proposal's availability qualifier honestly: the up-to-year summary and four-hour history are both qualified by availability. The RFC does not ask you to manufacture a year of observations. For your evaluation, record the earliest genuine observation, actual retained coverage, and how you would accumulate additional history over time.

Retrieve the sample and reconcile the summary

Run the retrieval from a client controlled by your team, using authorized test access and the vendor's documentation. For the general access exercise, use our trust center programmatic-access buying guide. Here, concentrate on whether the retrieved series is complete for the agreed fixture and whether you can explain its relationship to the summary.

Ask the vendor to select a time window, retrieve the observations, and show the calculation behind the corresponding summary. Then repeat with a different window and include the missing interval. For a product that cannot yet demonstrate a full 30-day or longer history, record that limitation separately from the short fixture's results.

Use the following worksheet as commercial acceptance criteria agreed with the vendor:

Keep credentials and sensitive operational data out of the worksheet. Record limitations in pagination, supported time windows, or retention as implementation dependencies to resolve before purchase. Avoid treating a vendor-operated demonstration as proof that your own integration is ready.

Make a bounded purchasing decision

Finish with an evidence-based list of demonstrated behavior, unresolved gaps, owners, and repeat-test dates. For example, a tool might retrieve the two-day fixture correctly while leaving the summary calculation unexplained. Accept the retrieval result for that fixture and keep summary reconciliation open.

Treat a successful history demonstration as one input to a buying decision. RFC-0036 explicitly covers only new or modified rules and directs readers to existing Class D rules for additional context. A working JSON response therefore cannot establish complete Class D readiness. Review the full proposal and applicable published rules with your assessment team before expanding the scope of your conclusion.

For the separate task of retaining package states associated with ongoing reports, see our package-history snapshot guide. Keep that document-history exercise distinct from the observation-series demonstration described here.

Frequently asked questions

Is four-hour metric history already a new Class B or C requirement?

No. The four-hour provision discussed here is proposed in RFC-0036 for Class D. The published SDR-CSX-KMT text separately specifies Class B historical summaries and Class C history with daily data; consult that text for the class-specific baseline.

Does the proposal require every validation to run every four hours?

The proposed four-hour provision concerns metric history, including persistent-validation status. RFC-0036 separately proposes machine-resource verification and validation at least once every three days; it does not make the history interval a universal execution schedule for every KSI check.

How should we assess a tool with less than a year of history?

The proposal qualifies its up-to-year history with availability. We recommend recording actual coverage, demonstrating honest missing intervals, and agreeing how retained history will grow. Keep synthetic demonstrations clearly separate from genuine operational observations.

What should happen when a promised feature cannot be demonstrated?

Record it as an unresolved purchasing dependency with an owner and a repeatable acceptance test. Require a new demonstration before counting that feature as available for your deployment.