Initial Outcome of RFC-0031 Updated Incident Communications Procedures
NTC-0012 published at Wed, 03 Jun 2026 20:20:00 GMT // Markdown Version
The final significant guidance overhaul for the FedRAMP Consolidated Rules for 2026 was posted in RFC-0031 Updated Incident Communication Procedures on April 8, 2026. This RFC proposed updated guidance to long-standing historical Incident Communications Procedures that most cloud service providers were not properly following to establish a measurable framework that would ensure government agencies are properly notified of incidents that are likely to impact them.
Most importantly, the proposed guidance continued FedRAMP’s initiative to establish different expectations for services based on the FedRAMP Certification Class (or historical assured impact level) to ensure that expectations for Class D (High) services align correctly with agency customer expectations for mission-critical capabilities where a small incident could result in catastrophic damage to the federal government.
Many stakeholders, including trade associations, weighed in on this RFC with valuable insights and feedback. FedRAMP’s overall intent for implementing these changes remains unchanged after feedback, however many aspects of the final rules will be adjusted based on feedback.
The changes discussed in this Public Notice can be reviewed in context in the current Public Preview of the FedRAMP Consolidated Rules for 2026:
- Incident Communication Procedures Complete Ruleset Reference
- Note: We are still working on some look-and-feel improvements in the human-readable versions of these materials.
- Vulnerability Detection and Response Complete Ruleset Reference
- FedRAMP Definitions
These updated Incident Communications Procedures will take effect on July 4, 2026 and will be mandatory as follows:
- Any cloud service provider seeking to obtain a 20x Certification: July 4, 2026
- Any cloud service provider seeking to obtain or maintain a Rev5 Certification: January 1, 2027
- Any cloud service provider seeking to maintain their current pilot 20x Certification: January 1, 2027
FedRAMP strongly encourages cloud service providers to adopt these updated procedures prior to the mandatory date.
Changes to Potential Adverse Impact and Adverse Effects
RFC-0031 leverages the approach from the Vulnerability Detection and Response rules for estimating the Potential Adverse Impact N (PAIN) rating for the entire government based on the likely Adverse Effects on customers of a cloud service. We have re-defined all of these terms from the perspective of a cloud service provider instead of a federal agency but the reuse of these long-standing terms with specific federal agency meaning continues to cause confusion with FedRAMP stakeholders.
One significant lesson of the past year for FedRAMP is that we must move away from using “dual-use” terms that mean one thing to federal agencies and a different thing for private companies. We must discontinue use of Potential Adverse Impact and Adverse Effects and replace this terminology with appropriate terms that apply only to private companies and that make sense within the overall context of a FedRAMP Certification and agency use of a commercial cloud service.
The following changes to this terminology will apply broadly across the FedRAMP Consolidated Rules for 2026, including the Vulnerability Detection and Response rules and the Incident Communication Procedures:
Potential Adverse Impact will be replaced with the plain language Potential Agency Impact to reflect the underlying intent that what is being measured is the potential impact to federal agencies using the cloud service. The definition of Potential Agency Impact will be as follows:
The estimated cumulative effect of unauthorized access, disruption, harm, or other adverse impacts to all agencies using the cloud service that are likely to result from security incidents or the exploitation of vulnerabilities in the cloud service offering; as estimated following appropriate FedRAMP rules to calculate the Potential Agency Impact N-rating (PAIN).
Adverse Effects will be replaced with the plain language Customer Effects, with the levels replaced with more appropriate plain language terminology for measuring the effects that a disruption would have on customers using the service.
a. Catastrophic Adverse Effect is replaced with Debilitating Customer Effect: An unwanted customer effect that interrupts use of the cloud service for most users or compromises the integrity or confidentiality of most federal customer data. If the adverse customer effect is unknown then it should be treated as if it is debilitating until proven otherwise.
b. Serious Adverse Effect is replaced with Disruptive Customer Effect: An unwanted customer effect that interrupts use of the cloud service for many users for less than 24 hours, or that compromises the integrity or confidentiality of large amounts or many types of federal customer data.
c. Limited Adverse Effect is replaced with Narrow Customer Effect: An unwanted customer effect that interrupts use of the cloud service for some users for less than 12 hours, or that compromises the integrity or confidentiality of an extremely limited amount and type of federal customer data.
d. Negligible Adverse Effect is replaced with Minimal Customer Effect: An unwanted customer effect that is only noticeable by some users. This includes minor inconveniences such as reduced performance.
Overall Impact on Incident Communication Procedures
The following aspects of the proposed Updated Incident Communication Procedures will be changed in the Consolidated Rules for 2026:
Availability Reporting rules will move from Incident Communication Procedures into the Certification Data Sharing ruleset, required sharing will be limited to all necessary parties (the RFC required this to be public), and this will be a requirement instead of a recommendation for Class B Certifications.
a. The Certification Data Sharing ruleset is a more appropriate home for this updated rule since it isn’t really about incident reporting procedures anymore.
b. FedRAMP recognizes that some cloud services are configured such that only an active customer would be able to determine if their specific tenant instance is down and in such cases sharing this information with the public is unnecessary or even inappropriate.
Federal reportable incidents will be renamed FedRAMP reportable incidents to clarify that these are FedRAMP Certification requirements, unrelated to other types of incidents that should be reported to the government under other laws or agreements.
Evaluation of an incident to estimate the Potential Agency Impact N (PAIN) rating for the federal government will be optional; providers that do not estimate the PAIN will be required to report all incidents as if they are PAIN5 by default.
a. This change allows providers to maintain a single automated workflow against a single timeline to operate a simpler process with better customer experience if they determine this is in their business interest.
b. See: ICP-CSO DPR (Default PAIN Rating) and ICP-CSO-EFI (Estimate Federal Impact)
Clarification will be added to indicate that initial “evaluation” of the incident for FedRAMP Incident Communication Procedures is completed when it has been determined to be a FedRAMP reportable incident and the Potential Agency Impact N (PAIN) rating has been estimated (if applicable).
a. The purpose of this evaluation is to determine if a notification is necessary and how that notification should proceed, so the notification requirement rules need to explicitly reference these rules to avoid confusion if they are read by themselves.
A new SHOULD rule will be created to strongly encourage the adoption of automated incident communication capabilities.
a. Providers should not be hand-crafting artisanal incident notifications and personally sending them to all affected parties. These should be managed centrally, automatically triggered based on movement between statuses, and automatically sent with all appropriate updates on the timeframes expected to all affected parties.
Incident Reports: Reporting rules that require the inclusion of information will be rephrased to clarify that the requirement is a timely notification with as much information as is available - if information is not available then that’s fine, send what you have. Minor changes will be made to the default expected additional information for incident reports. An additional requirement will be added for incident reporting that will require the cloud service provider to include a list of likely affected customer agencies in the notification. Requirements for incident reports will now vary slightly by Class.
a. See: ICP-CSO-IIR (Initial Incident Report) and ICP-CSO-OIR (Ongoing Incident Report)
FedRAMP will no longer expect private companies to report incidents regarding agency customers directly to CISA. Instead, agencies using these cloud services will be expected to do so based on the identified impact to their own agency services.
a. This will help CISA establish the actual scope of impact to the federal government as they are not otherwise aware of what agencies are using these cloud services or how they are using them - having individual agencies reporting this information based on the measured impact within the context of their use provides more appropriate data.
b. Please note some cloud service providers may have legacy contract agreements that supersede this.
Based on the updated and clarified definitions, the Incident Report Timeframes will be adjusted as follows:
a. Class D (High) N5, N4, and N3 timeframes will all require 15min IIR, 3hr OIR, and 3hr FIR.
b. Class C (Moderate) N5, N4, and N3 will require all 1hr IIR, 6hr OIR, 6hr FIR.
c. Class B (Low) and Class A (Pilot) N5, N4, and N3 will all require 6hr IIR.
d. All other requirements will stay the same.
e. It’s worth noting that a PAIN5 or PAIN4 incident should effectively never occur in a Class D or Class C service under normal operations if they are built properly, and PAIN3 incidents should be incredibly rare.
f. See: ICP-CSO-IIR (Initial Incident Report), ICP-CSO-OIR (Ongoing Incident Report), and ICP-CSO-FIR (Final Incident Report).
General Comment Themes
This section contains additional optional insights and background on this RFC. It is information dense and does not add any critical information beyond that expressed earlier in this outcome.
This section is intended for FedRAMP stakeholders who always request additional information to understand decisions and are willing to invest considerable time in reviewing additional context.
Concerns about reporting timeframes:
The timeframes proposed in this RFC, and carried forward into the final rules, are based on the expectation that cloud service providers will use modern incident management systems that include automatic communication capabilities to ensure that all affected parties will receive timely notification of incidents so that they can respond appropriately. This is especially critical for FedRAMP Certified Class D services where such incidents are likely to have a catastrophic adverse effect on a federal agency customer and cause significant damage to the U.S. government.
Providers are strongly encouraged to exceed these required time frames and drive this number as close to 0 as possible across all levels of FedRAMP Certification. Incident communication is a critical customer experience necessity where every minute can result in harm to the public because of the likely impact to federal customer data.
That said, the definitions of these events are designed to truly identify very serious events. A PAIN5 event should be on the level of a hundred-year flood, a circumstance where a massive series of chained events led to an impact that is nearly unimaginable or there was a significant gap in the security protocols that are expected to be in place. Examples of this from FedRAMP’s experience are incredibly rare and typically involve rogue or compromised administrative accounts that were used maliciously to destroy a cloud service from within (or, in 2026, an AI agent given far too many permissions and left to act without proper limits and oversight). These are circumstances where every moment matters for customers.
Evaluating Potential Adverse Impact to the federal government:
FedRAMP has reused the common “potential adverse impact” terminology from government information security standards with explicit definitions that are intended to help a cloud service provider estimate the potential adverse impact of a vulnerability or incident to the entire federal government.
This is done by calculating the likely adverse effect, defined by four categories: negligible, limited, serious, and catastrophic. These effects are calculated based on metrics that a cloud service provider can measure, such as a degradation in performance for all users or unauthorized disclosure of all customer data in a system. The expectation is that a cloud service provider will estimate the effect on users of their service, not the actual effect on the agency or its mission.
The cloud service provider then supplies sufficient information the agency customer so that the agency itself can determine the actual potential adverse effect on agency operations, which is why incident communications and vulnerability detection and response are so critical - they must assume, to some degree, that the agency is using the service for critical services commensurate with the FedRAMP Certification Class commitments.
Recently FedRAMP has made a concerted effort to move away from terms that legal or policy frameworks apply explicitly to federal government information systems in order to clarify that private companies are not subject to these rules even if their service is included in a federal information system. We’ve updated this set of terminology and expectations to align with this approach by removing the reuse of standard federal terminology.
Reporting clock on evaluation:
Many folks commented about the lack of clarity in when the “clock starts” for the notification requirements because we used the phrase “within [time] of evaluation” without making it clear that evaluation was the outcome of 2 specific rules that require evaluating the incident to determine if it was likely to affect confidentiality or integrity of federal data along with the potential impact to agencies. It should be clear that once a cloud service provider has determined that an incident is likely to have an impact on an agency customer and evaluated what that overall impact is likely to be, that the next step is immediate notification about this. By this time most of the information about the incident will be available as it may be hours or even days into initial incident detection and response activities.
In short, the clock only starts for reporting when the organization has appropriately (and promptly) come to the conclusion that the incident must be reported. At that point action must be taken at all reasonable speed to perform the notification.
This is also why the entire timeline is requested - it is not a violation of these procedures if a cloud service provider regularly waits for days after identifying an incident before they evaluate the incident to determine if it’s likely to affect federal customer data, but it’s very likely to cause customer agencies to re-evaluate their use of a service that does not take federal customers seriously.
Confusion related to CIRCIA reporting:
CIRCIA is the Cyber Incident Reporting for Critical Infrastructure Act, which requires regulatory activities related to critical infrastructure by the Cybersecurity and Infrastructure Security Agency. This act, and these regulations, are related to national security and other similar interests regarding covered entities that experience incidents in their own operation regardless of whether or not they have federal agency customers.
CIRCIA is entirely unrelated to FedRAMP and is entirely irrelevant in the context of FedRAMP Certification. FedRAMP has nothing to do with CIRCIA and vice versa.
FedRAMP Incident Communication Procedures create requirements specific to reporting incidents that are likely to affect federal customer information that is handled by cloud service providers under a contract or other agreement with that federal agency. This is not to provide overall intelligence or insight into incidents related to potential national security interests but is intended to ensure that a federal agency customer is immediately notified of an incident so that the federal agency can begin triage and related incident response activities as required by federal policy.
We may have inadvertently caused some of this confusion by using the term “federal reportable incident” for incidents that impact federal customer data inside a cloud service provider, and will rename this term to “FedRAMP reportable incident” to be clear that this is entirely about the relationship a FedRAMP Certified cloud service provider will have with its customer agencies.
Resetting the default definition of incident and creating a separate category of reportable incidents:
In this update to Incident Communication Procedures, FedRAMP rescoped the definition of incident to include all incidents so that we could add an evaluation phase to incident management in a way that made sense. As long as the definition included only those incidents that affected federal customer data there was a bit of a race condition - how could a cloud service provider evaluate an incident to determine if it was likely to affect federal customer data if an incident was by definition likely to affect federal customer data? This would result in no incidents ever being identified or evaluated.
Resetting the definition of incident to a general definition prevents any confusion that incidents should be handled, tracked, and otherwise managed by a cloud service provider following its policies whether or not the incidents have been determined to affect federal customer data. It enables the basic evaluation process so that at some point in the lifecycle of an incident it can be evaluated to determine if it’s likely to impact federal customer data along with the potential agency impact across the government. Only when this evaluation shows that it’s likely to impact federal customer data, especially the confidentiality or integrity of such data, does it need to be reported to all affected parties.
We think most of the confused feedback about the change to this definition was the result of folks writing down feedback during their first time reading through the policy since it should be obvious a few paragraphs later that the scope of reporting has been reduced overall, not increased. We strongly encourage folks to read through an entire RFC to understand the whole context before providing feedback on specific sections early in the document.
Requests for templates and other incident reporting schemas:
FedRAMP encourages cloud service providers to compete by providing better customer experiences for their customers in the reporting of Certification Data such as Incident Reports. We do not provide schemas or templates for this reporting to encourage thoughtful implementations that go far beyond a basic spreadsheet or generic ordered lists.
This has been a consistent shift with FedRAMP over the past year and will be carried across the FedRAMP Consolidated Rules for 2026 with the removal of nearly all templates. Cloud service providers are strongly encouraged to engage user experience designers and do their own research based on their own potential capabilities to provide the best possible customer experience for all of their customers.
That said: We are currently considering including basic JSON schemas for a few critical aspects of specific reporting to create a standardized approach here. These will be included in the Consolidated Rules for 2026. The intent is only to identify high level structure for certain reporting situations in a machine-readable format while encouraging metadata and additional information to be supplied in the most effective way.
Reporting federal agency impacts directly to CISA:
Historically FedRAMP has applied federal agency standards directly to private companies running cloud services and treated them as if they are government entities, instead of a private company providing a service to the government. This included the requirement for cloud service providers to follow federal incident reporting guidelines from CISA to report incidents directly to CISA. We kept this requirement in the proposed updated Incident Communication Procedures because it’s always been that way and we wanted to ensure that CISA was in the loop when such incidents happen, but have not interrogated the requirement under the current posture of FedRAMP.
Commenters rightly pointed out that this requirement does not align with the current direction and posture of FedRAMP. Cloud service providers do not and can not understand the actual impact to agency operations caused by an incident on their platform, and therefore should not be reporting such incidents to CISA on behalf of agency customers. Instead of ensuring clear information is transmitted to CISA, this reporting requirement creates additional noise.
For example, a cloud service provider may determine during an incident that all federal agency customer data in their platform has been exposed and exfiltrated; without insight into what this type of data is, reporting of such an incident would be a significant concern to CISA. It may turn out that the agency does not care at all about this data and that it’s already just public information it copied from elsewhere, resulting in no actual incident of importance at all, wasting everyone’s time. Or it may turn out to be highly sensitive data that could expose the federal government to extremely high risk. In any situation on that spectrum, it is the responsibility of the affected agency to notify CISA of the details of the incident based on the impact to agency functions or services.
This makes incident reporting from cloud service providers to agency customers all the more critical, as agencies will need to immediately evaluate the incident to determine the impact to their own functions and services in order to report it to CISA. Therefore we have decreased the maximum timeframes for notifications of incidents with a high potential adverse impact so that providers will rapidly communicate this information to agencies, but we have removed the expectation that providers report directly to CISA themselves. Agencies will receive additional guidance to ensure they understand the importance of notifying CISA directly of incidents that impact them.