In This Article
Something went wrong in production and you need to know, right now, whether the incident needs to be reported to FedRAMP.
The short version: only if the incident has affected, or is likely to affect, the confidentiality or integrity of federal customer data. Availability alone does not trigger anything.
Here are the specifics you will need to plan around: the reportability test, the exact timeframes at every class, and the grace period deadline that is closer than most teams think.
The Overview:
- Only confidentiality and integrity trigger a report. Availability is not in the reportability test under IEC-CSO-EFR, even though it is part of minimum assessment scope.
- Skip the PAIN estimate and you get PAIN 5. IEC-CSO-DPR defaults you to the rating with the shortest clocks.
- Three reports, one schema. Initial, ongoing, and final all use the FedRAMP Incident Report JSON schema.
- Class D initial reports are due in 15 minutes. Class C gets an hour, Class A and B get six.
- The final report is a MUST at every class. Class A can treat initial and ongoing as SHOULD, but not the final.
- June 1, 2027 is the grace period cliff for Rev 5 systems adopting this ruleset, with no extensions.
Read on to get the details you need.
What is the incident evaluation and communication ruleset?
The Incident Evaluation and Communication ruleset in the FedRAMP Consolidated Rules for 2026 (CR26) defines when a FedRAMP certified cloud service offering has to tell FedRAMP and its agency customers that something happened, how fast, and in what format.
Here's how it works and what you're required to do:
- Identify an incident
- Evaluate whether it is FedRAMP reportable
- Rate how badly it is likely to land on an agency
- File three reports on a fixed schedule: initial, ongoing, and final
All of these reports use the same machine-readable file. FedRAMP publishes it as the Incident Report schema, described as a unified schema for the three incident report types in the IEC-CSO lifecycle.
What counts as a FedRAMP reportable incident
FedRAMP Reportable Incidents are those that affect, or are likely to affect, the confidentiality or integrity of federal customer data.
Under IEC-CSO-EFR, providers must promptly evaluate incidents for this factor.
Note what is absent: availability.
Example: Your site goes down for 30 seconds. Nothing exposed, nothing tampered with, no reason to think either is coming. That is an availability incident and it does not trigger a FedRAMP report.
But, malicious activity in a production bucket or database holding federal customer data is a concern, because it has either affected confidentiality or integrity or is likely to.
Take note: Minimum assessment scope covers confidentiality, availability, and integrity of federal customer data. Incident reportability covers only confidentiality and integrity. Two different tests, and one of them drops availability. Do not carry the scope definition into the reportability decision.
PAIN, and why you default to 5
Once an incident is reportable, you rate it.
PAIN stands for Potential Agency Impact N-rating. Ratings go N1 through N5. It is your best estimate of the likely adverse impact on an agency customer, and you update it as your investigation turns up more.
FYI: IEC-CSO-DPR requires the incident be treated as PAIN 5 until you estimate it. Given that PAIN 5 carries the shortest clocks at every class, skipping the estimate is the most expensive way to save five minutes.
The three reports and timelines
Initial incident report
Class A and Class B carry the same clock. The difference is that at Class A the initial report is a SHOULD, meaning best practice rather than required.
Fifteen minutes at Class D is the window to evaluate reportability, assign a PAIN rating, generate the JSON, email FedRAMP, notify your agency contacts, and update your trust center.
Ongoing incident reports
Ongoing reports carry new indicators of compromise and new activity as the investigation develops. At Class D that is a three-hour cadence on a live incident.
Final incident report
The final report is a MUST at every class, including Class A. This is the one requirement in the ruleset nobody escapes.
Source: FedRAMP's Incident Evaluation and Communication rulesets for Class B, Class C and Class D, plus Class A related rules.
Dates that matter for Incident Reporting Requirements
If you hold a Rev 5 authorization, the Incident Evaluation and Communication ruleset has its own schedule, and it is one of the earlier cliffs in CR26.
Circle June 1, 2027 in red on your comically large desk calendar, friend. FedRAMP's deadlines page states there will be no extensions past the ending of the default grace period, and that it applies regardless of notification, corrective action, or progress.
Our CR26 deadlines post covers the wider rollout.
What you need in place before an incident
Three things have to exist before you have an incident to report.
- A reportability decision your on-call can make. Someone at 2am needs to answer "confidentiality or integrity of federal customer data, yes or no" without convening a meeting.
If that question routes to a compliance lead who is asleep, your fifteen minutes are gone.
- A generated JSON file (not a handcrafted one). The Incident Report schema covers all three report types and carries a provider tracking ID, incident description, timeline, milestones, and both your historical and current PAIN ratings with the reasoning behind them. Ask your GRC or incident response vendor directly whether they emit this schema.
- A notification path that hits every party at once. FedRAMP by email, each agency point of contact by their appropriate method, and your trust center updated. Three destinations, one clock.
What this means for your FedRAMP program
Incident reporting is the clearest example of why CR26 rewards automation over documentation. Nothing about a fifteen-minute window is solvable with a better template.
The deliverable is a machine-readable file whose contents come from things you already know: your environment, your data flows, your impact assessment. If those live in a Security Decision Record rather than a Word document, the incident report becomes a generation problem instead of a writing problem.
That is the difference between a program that meets these clocks and one that discovers on the worst day of its year that it cannot.
How Paramify helps with FedRAMP incident reporting
The hard part of this ruleset is producing a valid, complete JSON file inside a window measured in minutes, three separate times, while an incident is still active.
Paramify keeps your environment, data flows, and security decisions in one source of truth, and generates CR26 JSON deliverables from that data rather than from a person filling in a form. The same source feeds your Security Decision Record and your trust center, so what agencies see during an incident matches what your program actually knows.
We have been through CR26 ourselves. Paramify holds its own FedRAMP 20x Class C certification, which means these clocks apply to us too.
Learn More:
- Watch the full video walkthrough: When Do You Have to Report an Incident to FedRAMP?
- What Is FedRAMP 20x?
- What is an SDR? Understanding the Security Decision Record
- You Need a Trust Center for FedRAMP 20x: Here's Why
- CR26 deadlines you need to know
- How to Get FedRAMP 20x: A Step-by-Step Guide
Frequently asked questions
When do you have to report an incident to FedRAMP?
When the incident has affected, or is likely to affect, the confidentiality or integrity of federal customer data. That is the test in rule IEC-CSO-EFR. Incidents with no confidentiality or integrity impact are not FedRAMP reportable.
Do I have to report an outage to FedRAMP?
Not for the downtime itself. Availability is not part of the reportability test. An outage becomes reportable only if it also affects, or is likely to affect, the confidentiality or integrity of federal customer data.
What is a PAIN rating?
PAIN is the Potential Agency Impact N-rating, from N1 to N5. It is your estimate of the likely adverse impact on an agency customer, and you revise it as you learn more. If you do not estimate it, the rules treat the incident as PAIN 5.
How fast do I have to file an initial incident report?
It depends on your certification class and PAIN rating. At Class D, 15 minutes for PAIN 3 and above. At Class C, one hour. At Class A and B, six hours. Lower PAIN ratings get longer windows.
Is the final incident report required at every class?
Yes. The final report is a MUST at Class A, B, C, and D. At Class A the initial and ongoing reports are SHOULD requirements, but the final report is not optional anywhere.
Schedule Your Demo Today to Start Automating Your Incident Reporting
.svg)
.svg)
