Skip to main content
Official source: Incident Evaluation and Communication (IEC), FedRAMP Consolidated Rules release 2026.10.14.01. This page is a plain-English summary. The official rule text governs.

​
In short

When an incident affects, or is likely to affect, the confidentiality or integrity of federal customer data, it is a FedRAMP Reportable Incident. You must report it to FedRAMP and affected agencies. The reporting clock depends on your class and the incident’s Potential Agency Impact N-rating (PAIN). If you don’t promptly estimate the PAIN, you must treat the incident as PAIN-5, which means the fastest timeframes. For a Class D provider, the initial report for a PAIN-3 to PAIN-5 incident is due within 0.25 hours (15 minutes). FedRAMP expects this reporting to be automated, not hand-crafted email.

​
Who it applies to

Upstream describes the General Provider Responsibilities subset as applying to “providers with FedRAMP Certifications of any type.”
The subsets list Classes B, C and D, but IEC-CSO-IIR, IEC-CSO-OIR and IEC-CSO-FIR each state a Class A variant. For Class A, FRC-CLA-MFR makes IEC-CSO-EFR and IEC-CSO-FIR mandatory, and FRC-CLA-RFR recommends IEC-CSO-IIR and IEC-CSO-OIR.

​
Key dates

​
How the workflow runs

The upstream activity workflow:
1

Evaluate reportability (IEC-CSO-EFR)

When you identify an incident, promptly decide whether it is a FedRAMP Reportable Incident. If not, you’re done.
2

Rate the incident (IEC-CSO-EFI or IEC-CSO-DPR)

Either promptly estimate the PAIN rating, or use the default of PAIN-5. The reporting clock starts here, using the estimated or default PAIN timeframes.
3

Send the Initial Incident Report (IEC-CSO-IIR)

Report within the timeframe for your class and PAIN rating.
4

Send Ongoing Incident Reports (IEC-CSO-OIR)

Keep reporting persistently until the incident is resolved.
5

Send the Final Incident Report (IEC-CSO-FIR)

Once the incident is resolved and recovery is complete.

​
What you need to do

​
General provider responsibilities

Upstream on IEC-CSO-AIR: “Modern cloud services should not be reporting incidents by hand-crafting emails!”
Where to send reports. For IEC-CSO-IIR, IEC-CSO-OIR and IEC-CSO-FIR, upstream lists three notification routes:
  • FedRAMP, by email to fedramp_security@fedramp.gov
  • Agency customers, following each agency’s own incident reporting procedures
  • All necessary parties, through an update in your trust center or USDA Connect (FedRAMP staff said on 2026-10-28 they will make this route optional; see the staff note below)
FedRAMP publishes an Incident Report JSON schema covering all three reports. Initial Incident Report contents (IEC-CSO-IIR). Include as much as is available at the time, or the current status of each item:
  1. Contact information for the federal incident response coordinator
  2. Your internal tracking identifier
  3. Description of the incident
  4. Timeline, including start time, time and source of detection, time of completed reportability evaluation and other major milestones
  5. Historical and current estimated PAIN, with an explanation of the IEC-CSO-EFI evaluation (if applicable)
  6. Functional impact to agency customers, including impact to confidentiality and/or integrity and the federal customer data types affected
  7. Estimated recovery plan, milestones and timelines
  8. List of likely affected customer agencies
Ongoing Incident Report additions (IEC-CSO-OIR). Include as much as is available:
  1. Observed incident activity
  2. Indicators of compromise
  3. Related CVE identifier (if applicable)
  4. Root cause
  5. Response and recovery activities
Incident PAIN ratings (IEC-CSO-EFI): If you don’t complete this step, the incident is PAIN-5 by default (IEC-CSO-DPR).

​
FedRAMP responsibilities

​
Differences by class

The reporting timeframe depends on your class and the incident’s PAIN rating. Timeframes are exactly as stated upstream.

​
Initial Incident Report (IEC-CSO-IIR)

​
Ongoing Incident Reports (IEC-CSO-OIR)

​
Final Incident Report (IEC-CSO-FIR)

Upstream labels these as timeframes for each report but doesn’t state the exact event each clock runs from. The workflow says the reporting clock starts once the incident is determined reportable and rated (estimated or default PAIN-5). The Final Incident Report is due after the incident “has been resolved and recovery is complete.” The rules don’t address this further.

​
Vulnerabilities treated as incidents

Vulnerability evaluation and reporting tells you when to treat certain vulnerabilities as FedRAMP Reportable Incidents:
  • VER-TFR-IRI: internet-reachable, likely exploitable vulnerabilities with PAIN greater than 3, until partially mitigated to N3 or below. MAY for Classes A and B, SHOULD for C and D.
  • VER-TFR-NRI: likely exploitable vulnerabilities that are NOT internet-reachable with PAIN of 5, until partially mitigated to N4 or below. MAY for Classes A, B and C, SHOULD for D.

​
What FedRAMP staff have said

Where to send incident reports. On 2026-10-21, pete-gov confirmed a provider’s plan: email FedRAMP at fedramp_security@fedramp.gov, follow each agency’s own reporting procedure, and post reports for all necessary parties to your trust center or USDA Connect where an agency has no specific procedure. pete-gov added that many agencies put notification expectations in the procurement agreement, usually as an email address. Discussion #146 comment
The “all necessary parties” route is an oversight. On 2026-10-28, pete-gov said the IEC-CSO-IIR, IEC-CSO-OIR and IEC-CSO-FIR rules require notifying affected parties, not all necessary parties, so the notification requirement shouldn’t list them. FedRAMP opened FedRAMP/Rules#47 and said it will make the all-necessary-parties notification optional. Posting incident information in the trust center is still helpful but up to you. Staff also said a notification must not enable a threat actor, so sanitize it. In most cases public posting should be fine. If even the existence of an incident could create a threat, share it carefully with affected parties only. This is a stated plan. The upstream text in release 2026.10.14.01 still lists the route, so the published rule governs until it changes. This refines the 2026-10-21 note above. Discussion #146 comment