Skip to main content

FedRAMP 20x Availability Reporting During an Outage

CDS-CSO-AVR requires Class B and C availability reporting to remain available when the primary offering is unavailable. Cover current status and at least 30 days of history, including incidents, in human-readable and machine-readable formats. Test shared dependencies and evaluate incident reportability separately.

Written by Boundera Team|October 10, 2026|3 min read

Main question

How should Class B and C providers keep FedRAMP 20x availability reporting accessible during an outage?

When the application is down, its status page becomes one of the most useful services you operate. FedRAMP 20x availability reporting for Class B and C providers calls for more than a green indicator embedded in the application: the reporting service must remain available when the primary offering is unavailable.

Design the reporting path around that failure condition. This article separates the official reporting rule from practical architecture and exercise suggestions.

What the availability rule covers

Under CDS-CSO-AVR, Class B and C providers MUST maintain a web service available to all necessary parties that shows current and historical core-service availability over at least the past 30 days, including availability incidents. Both human-readable and machine-readable formats are required. The service MUST remain available even when the primary cloud service offering is unavailable. The rule expressly permits this service to be separate from the trust center. Class A uses SHOULD instead of MUST for this rule. FedRAMP Certification Data Sharing

The page lists July 4, 2026 for obtaining initial certification and January 1, 2027 for maintaining ongoing certification, with the grace period ending on the first independent assessment started after January 1, 2027. Keep the applicable adoption timing alongside your design decisions.

Trace the reporting service's failure dependencies

Start with an architecture review of the status page, its data feed and the process used to update it. The following are implementation suggestions, not a mandated hosting pattern:

  • Identify shared DNS, identity, network and deployment dependencies with the primary offering.
  • Check whether operators can post an update if the ordinary administration console is unavailable.
  • Exercise both the page a person reads and the endpoint an agency tool consumes.
  • Confirm the historical incident record remains accessible during the simulated outage.
  • Record who owns recovery of the reporting service itself.

Independent hosting can help isolate some failures, but the useful test is the actual dependency path. A separate hostname can still depend on the same identity provider or deployment pipeline. Describe which failure your design tolerates and which dependencies remain shared.

Keep current state and history understandable

Use consistent service names across the human view and machine feed. For example, distinguish an unavailable administrative console from delayed background processing rather than collapsing both into one unexplained status value. This is editorial design advice; the official rule supplies the coverage and availability obligations.

For an exercise, choose a recent incident and ask a reader to reconstruct what happened using the reporting service alone. Can they identify the affected core service, the period of disruption and its current state? Then perform the same exercise against the machine-readable output. Investigate mismatches before relying on either view during a real outage.

Our trust-center scope guide covers the broader information-sharing context. Keep the outage-reporting test focused on whether necessary parties can actually obtain availability information.

Evaluate incident reportability separately

For the Class B and C scope discussed here, IEC-CSO-EFR requires prompt evaluation of whether an incident affects, or is likely to affect, the confidentiality or integrity of federal customer data. Incidents meeting that test are FedRAMP Reportable Incidents and follow the Incident Evaluation and Communication rules. FedRAMP Incident Evaluation and Communication

A status update alone does not answer that evaluation question. Route the operational outage and the security evaluation to named owners, and retain the reasoning connecting them. When the evaluation establishes reportability, use the incident notification workflow for the communication process.

The practical acceptance exercise is straightforward: interrupt the primary offering, retrieve the availability page and feed, inspect the retained history, and confirm that the team can still update the report. Save the results and resolve the dependencies the exercise exposes.

Frequently asked questions

Must the availability service be part of the trust center?

CDS-CSO-AVR expressly says it may be separate from the trust center.

How much availability history does the rule cover?

For Class B and C, CDS-CSO-AVR requires current and historical core-service availability over at least the past 30 days, including availability incidents.

Does a status page decide whether an incident is reportable?

The separate IEC-CSO-EFR evaluation considers actual or likely confidentiality or integrity effects on federal customer data. Route that evaluation alongside operational availability reporting.

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