1. Home
  2. |Insights
  3. |FedRAMP Solicits Public Comment on Overhaul to Incident Communications Procedures

FedRAMP Solicits Public Comment on Overhaul to Incident Communications Procedures

What You Need to Know

  • Key takeaway #1

    FedRAMP proposes significant updates to its Incident Communications Procedures that would apply to both Rev5 and 20x FedRAMP-Certified cloud service providers.

  • Key takeaway #2

    The most significant proposed updates include revised, more nuanced incident reporting timelines, clarification of the incident reporting trigger, and proactive FedRAMP monitoring of providers’ incident reporting performance and processes.

  • Key takeaway #3

    The comment period closes on May 12, 2026, and FedRAMP anticipates a finalized version in June 2026. Cloud service providers should consider submitting comments and should monitor the release of the final version, which will impact incident reporting obligations.

Client Alert | 4 min read | 04.14.26

Introduction

The Federal Risk and Authorization Management Program (FedRAMP) continues to advance its modernization agenda. On April 8, 2026, FedRAMP released RFC-0031, Updated Incident Communications Procedures for public comment. This RFC proposes replacing the current FedRAMP Incident Communications Procedures (ICP) with what FedRAMP calls “a clear set of reporting requirements … established using a modern rules-based format.” 

Below is a summary of key changes proposed in RFC-0031.    

Uniform One-Hour Incident Reporting Deadline To Be Replaced With Varied Deadlines Tied to Certification Level and Incident Impact Analysis

This is the most significant proposed change for FedRAMP cloud service providers (CSP). Under the current FedRAMP ICP, CSPs must report suspected and confirmed incidents to stakeholders within one hour of being identified — a single, uniform deadline that applies regardless of the severity or nature of the incident. Under RFC-0031, CSPs will be required to consult a matrix that cross-references two variables — the provider's Certification Class[1]  and the incident's (appropriately coined) Potential Adverse Impact Number (PAIN) — to determine their applicable reporting deadlines. The PAIN rating ranges from N1 (negligible adverse effect on one or more agencies) to N5 (catastrophic adverse effect on more than one agency) and must be assigned by the provider as part of its initial incident evaluation.

The tiering would be most demanding for Class D providers (equivalent to FedRAMP High). For example, a Class D provider facing an N5-level incident would be required to file its Initial Incident Report within 15 minutes of completing its evaluation, submit Ongoing Incident Reports every three hours, and deliver a Final Incident Report within three hours of recovery. Even for lower-severity incidents, Class D providers face Initial Incident Report deadlines of 30 minutes (N4) or one hour (N1 through N3). In contrast, Class A (equivalent to FedRAMP Ready) and Class B (equivalent to FedRAMP Low/LiSaaS) providers would face the least demanding timelines, with Initial Incident Report deadlines ranging from six hours (N4 and N5) to one business day (N1 and N2), and Final Incident Reports due within three business days of recovery across all PAIN levels.

The practical implication is significant: CSPs would no longer apply a single one-hour rule. CSPs would need to build internal incident response procedures capable of rapidly evaluating incident severity, assigning a PAIN rating, and dispatching notices within timeframes as short as 15 minutes depending on their Certification Class and the impact of the incident.

Introduction of a Formal Evaluation Requirement for Incidents and Modifications to Incident Reportability Criteria

RFC-0031 introduces a formal evaluation requirement for CSPs, “ICP-CSO-EFR” (Evaluate Federal Reportability), to determine if incidents are “federal reportable incidents.” Specifically, CSPs must report incidents that affect or are likely to affect the “confidentiality or integrity of federal customer data.” This is significantly narrower than the current ICP, which requires reporting of incidents that result in the “actual or potential loss of confidentiality, integrity, or availability” of the “cloud service” or the “availability to assets or services provided by the service offering.” ICP-CSO-EFR’s reportability evaluation precedes the PAIN analysis necessary to determine reporting deadlines.

Reporting Process Changes: Status Pages and Standardized Report Types

RFC-0031 would require Class C (equivalent to FedRAMP Moderate) and Class D providers to maintain a publicly accessible dashboard or similar offering indicating the current and historical availability of core services within their cloud service offering over at least the past 30 days, including information about any availability incidents, in both human-readable and machine-readable formats. Class A and Class B providers are encouraged, but not required, to maintain such a service.

RFC-0031 also introduces three new formally defined report types — Initial Incident Report, Ongoing Incident Report, and Final Incident Report — each with enumerated minimum content requirements.  This creates a more specific framework for information reporting. For example, RFC-0031 details the minimum requirements the Initial Incident Report must include: contact information for the federal incident response coordinator; the provider's internally assigned tracking identifier; a description of the incident; a timeline (including start time, detection time, and evaluation time); the estimated PAIN rating with an explanation; the functional impact to federal agency customers; and an estimated recovery plan with milestones and timelines. This provides a more concrete and clearer framework than the Rev5 version.

New Proactive FedRAMP Engagement Obligations and Corrective Action Framework

Under the current ICP, failure to report incidents can result in escalation actions, but there is no affirmative obligation for FedRAMP to monitor CSPs’ incident reporting. RFC-0031 adds a proactive obligation: FedRAMP must periodically review Incident Communication Procedures with CSPs — based on lack of reporting or other information — to ensure CSPs are aware of the rules and have properly implemented procedures. If a provider is found to be unaware of or to have not implemented proper procedures, FedRAMP will request a corrective action plan and grant a three-month grace period, with failure to remediate potentially resulting in revocation of FedRAMP Certification.

Takeaways

The comment period for RFC-0031 closes on May 12, 2026. CSPs — particularly those holding or pursuing Class C (Moderate) or Class D (High) certifications — should carefully review the proposed changes and assess whether their existing incident response procedures can satisfy the new PAIN/Certification Class matrix requirements, as well as what operational challenges from the newly proposed processes merit discussion via comments. The final version of the updated rule is expected to be incorporated into the FedRAMP Consolidated Rules for 2026 by the end of June 2026 and will apply to both Rev5 and 20x type FedRAMP Certifications. Comments may be submitted via the FedRAMP GitHub RFC thread (preferred) or by email (via pete@fedramp.gov).

For questions about RFC-0031 or how these changes may affect your FedRAMP authorization strategy, compliance obligations, or incident response program, please contact our team.

[1] FedRAMP is replacing its Low/Moderate/High authorization framework with Certification Classes ranging from A (a new status for “pilot” FedRAMP Certifications, roughly equivalent to FedRAMP Ready) to D (equivalent to FedRAMP High authorization.)

Contacts

Insights

Client Alert | 5 min read | 04.14.26

OFSI Imposes £390,000 Penalty on Apple Subsidiary for Russian Sanctions Breaches: Key Compliance Takeaways

The UK’s Office of Financial Sanctions Implementation (OFSI) has published details of a £390,000 penalty it imposed on ADI, an Irish subsidiary of Apple Inc., on 19 March 2026. The penalty relates to two payments totalling approximately £635,000 made in 2022 to Okko LLC, a sanctioned Russian app developer, for App Store revenue. Although the underlying facts are relatively simple, there are several interesting takeaways from OFSI’s penalty notice....