Skip to main content

FedRAMP 20x: Assemble KSI Metric History for the SDR

SDR-CSX-KMT says Class B providers SHOULD include past-30-day summaries and up-to-year summaries where available for each applicable KSI. Class C providers MUST include those summaries plus all daily metric data, including persistent-validation status, up to the past year where available. Initial applicants with insufficient operating history need mechanisms in place and agreement to meet the requirement. Preserve actual coverage and the SDR adoption dates; do not invent history or a daily execution schedule.

Written by Boundera Team|October 26, 2026|4 min read

Main question

What KSI metric history belongs in a 20x Class B or Class C SDR?

FedRAMP 20x: Assemble KSI Metric History for the SDR

A current metric value cannot show how a security measure behaved over time. When preparing the Security Decision Record (SDR), separate the history your class calls for from the history your service actually has. That makes gaps, changes and persistent-validation status visible without manufacturing a longer operating record.

SDR-CSX-KMT is the current rule for historical KSI metrics. Its Class B and Class C provisions differ in both force and detail. Use the current text when preparing an export or reviewing an inherited checklist.

Match the history views to the certification class

For each applicable Key Security Indicator, the rule specifies these minimum views:

ClassForceHistorical information
20x Class BSHOULDA summary of each metric over the past 30 days, plus a summary up to the past year where available
20x Class CMUSTBoth summaries, plus all daily metric data, including persistent-validation status, up to the past year where available

The “where available” qualification appears on the up-to-year summary and Class C daily data. It does not appear on the past-30-day summary bullet. Initial applicants with insufficient operating history have a separate note, discussed below.

Class B’s SHOULD still calls for a documented handling decision. FedRAMP’s definition of SHOULD allows valid reasons in particular circumstances to depart, while requiring the implications to be understood and carefully weighed and the decision explained in security documentation. The Class A variant says providers MAY include historical metrics.

The October 8 changelog removed FRC-CSX-MOT as duplicative and changed KMT’s Class B force to SHOULD. Retire checklist references to that removed rule; do not carry its former six-month prerequisite into the current KMT provision.

Build summaries that can be traced to their data

The following is an editorial export practice, not an additional FedRAMP schema. Give each metric a stable identity and preserve its definition, source and coverage interval. Then connect its 30-day and available longer-term summaries to the underlying observations. For Class C, preserve all available daily data within the up-to-year window, including persistent-validation status.

Check three practical details before handoff:

  • Comparable meaning: if a calculation, resource population or metric definition changed, mark the change so unlike values do not appear to form one uninterrupted trend.
  • Traceable coverage: identify the earliest available observation and any unavailable intervals, with links to the source evidence and an explanation of known gaps.
  • Visible status: retain failed, interrupted or waiting states as recorded. A missing observation is not evidence of a historical pass.

For example, a metric introduced 70 days ago can have a 30-day summary and an available longer-term summary covering those 70 days. Label that actual span. Backfilling earlier dates with today’s result would obscure what the service can demonstrate.

Daily history is also different from daily execution. FedRAMP’s definition of persistently permits irregular cycles, interruptions and waiting periods when intentional, understood and documented; activity status is always known. KMT’s daily-data provision does not itself set a daily execution schedule for every validation. Keep the documented cycle and observed status understandable together.

Handle initial certification and adoption dates explicitly

KMT’s initial-certification note addresses a service that has not operated with related metrics available for the relevant period before applying. The provider needs mechanisms in place and an agreement to meet the requirement. This is not a universal one-year operating prerequisite, nor a reason to present unavailable history as collected data.

For 20x SDR rules, optional adoption and obtaining initial certification dates are July 4, 2026. The ongoing-certification date is January 1, 2027; the grace period ends on the first FedRAMP independent assessment started after January 1, 2027. Use these SDR dates rather than dates from another ruleset.

Questions to resolve before an SDR handoff

Can a Class C export contain only summary charts?

KMT also calls for all daily metric data, including persistent-validation status, up to the past year where available. A summary-only view does not represent that full provision.

Does a short operating history automatically prevent initial certification?

The KMT note provides for insufficient history through mechanisms in place and agreement to meet the requirement. It does not decide every other condition of initial certification.

For adjacent work, see documenting recommended-rule decisions and retaining package snapshots for ongoing reports.

Frequently asked questions

Can a Class C export contain only summary charts?

SDR-CSX-KMT also calls for all daily metric data, including persistent-validation status, up to the past year where available. A summary-only view does not represent that full provision.

Does a short operating history automatically prevent initial certification?

The KMT note provides for insufficient history through mechanisms in place and agreement to meet the requirement. It does not decide every other condition of initial certification.

Does the daily-data provision set a daily validation execution schedule?

KMT calls for historical daily data, including persistent-validation status; it does not itself set a daily execution schedule for every validation. The definition of persistently permits intentional, understood and documented irregular cycles, interruptions and waiting periods, with activity status always known.

Next step

If you want to turn this guidance into an execution plan, the product side handles control mapping, SSP drafting, and evidence collection.

Related articles