Requirement ID: SDR-CSX-KMT
The requirement
Class A: Providers with 20x Class A Certifications MAY also include historical metrics in their Security Decision Record.
Class B: Providers with 20x Class B Certifications SHOULD also include historical metrics in their Security Decision Record, supplying at least the following information for each applicable Key Security Indicator:
- Summary of each metric over the past 30 days
- Summary of metric up to the past year (where available)
Class C: Providers with 20x Class C Certifications MUST also include historical metrics in their Security Decision Record, supplying at least the following information for each applicable Key Security Indicator:
- Summary of each metric over the past 30 days
- Summary of metric up to the past year (where available)
- All daily metric data (including status of persistent validation) up to the past year (where available)
Class D: Providers with 20x Class D Certifications MUST significantly supersede the minimum requirements for lower Classes, with specifics to be set during the 20x Phase 4 Pilot.
Notes:
For initial FedRAMP Certification, providers will need to have mechanisms in place and agree to meet this requirement in the event the cloud service has not been operating with related metrics available for the required period prior to applying for initial certification.
What does this mean?
This requirement is about keeping a history of your Key Security Indicator metrics inside your Security Decision Record, not just a single point-in-time snapshot.
The expectation scales by certification class. For Class A, including historical metrics is optional. For Class B, it is recommended, with a 30-day summary and a summary going back up to a year where that data exists. For Class C, it is mandatory, and the bar is higher: the same summaries plus all daily metric data (including the status of persistent validation) up to the past year, where available. Class D goes further still, with details to be defined during the 20x Phase 4 Pilot.
The “where available” language acknowledges that a newer service may not yet have a full year of data.
This article is also a LinkedIn newsletter. If you would like to receive it straight to your inbox, subscribe here.
Why does this matter?
A single snapshot tells you how a control looks today. History tells you whether it has been holding steady, drifting, or failing intermittently. Trends often reveal problems that a one-time reading hides, such as a validation check that passes most days but quietly fails on others.
If historical metrics are not retained, reviewers and your own teams lose the ability to confirm that security posture has been consistent over time. Gaps in the record can also undermine confidence in the persistent validation that the SDR model depends on.
Example scenario
A fictional provider seeking a Class C certification is only four months into operating its service. It has daily Key Security Indicator data for those four months but not a full year. Following the “where available” allowance, it includes all daily data it does have, along with its 30-day and to-date summaries, and documents a mechanism to continue capturing daily data so that a full year of history accrues over time. This aligns with the intent of the note about having mechanisms in place at initial certification.
What evidence could demonstrate implementation?
Examples may include:
- Stored daily metric records showing persistent validation status over time.
- 30-day and up-to-one-year metric summaries referenced in the SDR.
- Configuration or procedure documentation describing how metrics are collected and retained.
- Records or attestations describing the mechanism to meet the requirement where a full history does not yet exist.
Common pitfall
A likely misunderstanding is treating the summaries as sufficient for Class C. Class C calls for all daily metric data up to the past year where available, including persistent validation status, not just rolled-up summaries. Discarding daily detail after producing a summary would leave the record incomplete.
Question for your team
For each applicable Key Security Indicator, do we currently retain daily data (including persistent validation status) in a way that lets us reconstruct up to a full year of history for our certification class?
Key takeaway
Capturing and retaining historical Key Security Indicator data, at the depth matching your certification class, lets your Security Decision Record show sustained security posture over time rather than a single moment.
Related requirements
None listed in the source data.
Have a question about putting this requirement into practice?
38North Security can help you turn the requirements into an operating model that works in practice. Talk to us →
The quoted requirement statements, lists, and note above are from the provided FedRAMP CR-26 JSON for SDR-CSX-KMT. Other content, including the implementation ideas, example scenario, and evidence examples, is general guidance and should be validated against official FedRAMP guidance.
About the Authors
