Skip to content
GUIDE·12 min read

FedRAMP Incident Reporting, Explained: The 2026 Clocks, from 15 Minutes to 3 Business Days

FedRAMP providers used to run one clock: report any suspected incident within an hour. The FedRAMP Consolidated Rules for 2026 replaced that with clocks keyed to two things, your certification class and the incident's severity rating. A severe incident at a Class D provider needs an initial report in 15 minutes. The same incident at a Class A or B provider allows six hours. Certifications that have not converted keep the old one-hour rule until January 1, 2027. Here is what counts as reportable now, the rating that sets your clocks, every deadline by class, and what each report must contain.

Key takeaways

  • The one-size rule is gone. The legacy procedures required reporting every suspected or confirmed incident within one hour of identification. The 2026 rules key each clock to your certification class and the incident's Potential Agency Impact rating, PAIN for short.
  • The default is the worst case. If you do not promptly estimate the incident's PAIN rating, the rules treat the incident as PAIN-5, the most severe rating, which carries the tightest clocks. The severity estimate is not optional paperwork. It is the step that sets your deadline.
  • Only confidentiality and integrity incidents are reportable now. The rules narrow reportable incidents to those that affect federal customer data's confidentiality or integrity, or are likely to. Availability incidents no longer go through incident reports.
  • Class D runs the fastest clocks in the program. Fifteen minutes for the initial report of a severe incident, updates every three hours, and a final report within three hours of recovery.
  • The transition has real dates. The Consolidated Rules launched June 24, 2026. Rev5 certifications could adopt them from July 4, 2026. They are mandatory for initial and ongoing certification from January 1, 2027, and the grace period ends June 1, 2027.

Who runs on these clocks

FedRAMP is the US government's program for certifying cloud services that federal agencies use. A cloud service provider (CSP) that sells to an agency, or wants to, holds or pursues a FedRAMP certification. The certification places the provider in a class:

  • Class A is the entry class. The rules phrase its incident duties as SHOULD rather than MUST.
  • Class B covers services that were formerly Low impact.
  • Class C covers services that were formerly Moderate impact.
  • Class D covers services that were formerly High impact.

The provider side owns these clocks. Agencies keep their own duties under FISMA, and your agency customers pass your reports up their own chains. This page is for the provider side: the company doing the reporting.

Where the rules stand

The incident rules came out of a fast, public overhaul:

  1. The legacy rule. One hour, for everything, from identification by your top-level incident team. The old procedures now sit on pages FedRAMP has marked "legacy, intended only for reference" during the transition.
  2. RFC-0031, the proposal. In spring 2026 FedRAMP proposed replacing the flat clock with a tiered system, through its request-for-change process on GitHub. Comments closed May 12, 2026.
  3. The Consolidated Rules for 2026. The tiered system landed in the ruleset the program calls the FedRAMP Consolidated Rules for 2026, officially launched June 24, 2026.

For Rev5 certifications, the incident rules page states its own applicability: optional adoption from July 4, 2026, required for obtaining initial certification from January 1, 2027, required for maintaining ongoing certification from January 1, 2027, and the grace period ends June 1, 2027. New 20x certifications, the streamlined path FedRAMP announced in March 2025, operate under the Consolidated Rules now, and under the program's published transition plan new Rev5 certifications stop being accepted on June 11, 2027.

One more thing about sources, because it is unusual and useful. The machine-readable rules, published in a public GitHub repository (FedRAMP/rules), are the official version, and the human-readable pages on fedramp.gov are a reference copy. The program treats its rules like code, with a changelog. The incident rules' changelog includes an update as recent as October 13, 2026.

What counts as a reportable incident

The rules call them FedRAMP Reportable Incidents. The evaluation rule, IEC-CSO-EFR, requires providers to promptly evaluate incidents to determine whether they affect the confidentiality or integrity of federal customer data, or are likely to. If they do, they are reportable and the clocks start.

Two things changed against the legacy definition:

  1. Availability dropped out. The legacy rule covered any suspected or confirmed event causing actual or potential loss of confidentiality, integrity, or availability. The new definition covers confidentiality and integrity only. An outage is no longer an incident report. The overhaul's proposal moved availability communication to a publicly accessible status service showing at least thirty days of history, mandatory for Class C and Class D providers.
  2. "Potential" became "likely to affect." The old "actual or potential loss" phrasing made almost everything reportable, which is part of why everything ran on the same one-hour clock. The new phrasing asks for a judgment. The judgment has a rating scale, and the scale has teeth.

The PAIN rating that sets your clocks

Every reportable incident gets a Potential Agency Impact N-rating. The estimate rule, IEC-CSO-EFI, defines the scale:

RatingThe likely effect on agency customers
PAIN-1Minimal effect on one or more agencies
PAIN-2Narrow effect on one or more agencies
PAIN-3Disruptive effect on one agency
PAIN-4Debilitating effect on one agency, or disruptive effect on more than one
PAIN-5Debilitating effect on more than one agency

Then the default rule, IEC-CSO-DPR, does the quietly radical thing: providers MUST treat reportable incidents as PAIN-5 unless they promptly estimate the rating. Skip the estimate and you volunteer for the tightest clocks in the program. The severity call is the first substantive act of the response, and it needs a named owner in the plan, usually the incident commander.

The clocks, by class and rating

Three reports carry clocks. All of them start when the reportable incident is identified.

The Initial Incident Report

ClassPAIN-5 / 4 / 3PAIN-2PAIN-1
Class A (advisory)6 hours1 business day1 business day
Class B6 hours1 business day1 business day
Class C1 hour24 hours1 business day
Class D15 minutes1 hour1 hour

The Ongoing Incident Reports

Reporting is persistent until the incident resolves. The ongoing rule requires notifying all affected parties of ongoing activity as new information becomes available, including updates, or the stated lack of updates, to everything previously reported.

ClassPAIN-5 / 4 / 3PAIN-2PAIN-1
Class A (advisory)1 business day1 business day1 business day
Class B1 business day1 business day1 business day
Class C6 hours24 hours1 business day
Class D3 hours6 hours24 hours

The Final Incident Report

The final report lands once the incident is resolved and recovery is complete, with final updates to everything previously reported.

ClassPAIN-5 / 4 / 3PAIN-2PAIN-1
Class A (advisory)3 business days3 business days3 business days
Class B3 business days3 business days3 business days
Class C6 hours1 business day1 business day
Class D3 hours6 hours24 hours

A Class D provider with a severe incident runs the full gauntlet: an initial report in 15 minutes, updates every three hours, and a final report within three hours of recovery. A Class B provider with a minimal incident runs one business day per report. The clocks are why the class you certify into is a response-capability decision, not just a sales tier.

Who you notify, and how

Each report goes to three places, and the rules name them for every report type:

  1. FedRAMP, by email, at fedramp_security@fedramp.gov. The legacy address was fedramp_security@gsa.gov. The address changed with the rules.
  2. Your agency customers, by their procedures. The rules require following agency-specific incident reporting procedures, which vary by agency. The procedure for every agency customer belongs in the incident response plan before the incident.
  3. All necessary parties, through your Trust Center, or the government portal the rules name for that purpose.

CISA reporting runs alongside these rules, not through them. The legacy procedures required providers to notify CISA, through cisa.gov/forms/report, when an incident matched the attack vectors in CISA's Federal Incident Notification Guidelines. Keep that path in the plan, and follow each agency's procedures, which is where most of the variation lives.

What each report contains

The initial report carries: contact information for the federal incident response coordinator; the provider's internal tracking identifier; the incident description; the incident timeline, including start time, the time and source of detection, and the time the reportability evaluation completed; the PAIN rating with its explanation, when one was done; the functional impact to agency customers, including which federal data types; the estimated recovery plan with milestones; and the list of likely affected agencies.

Ongoing reports add what response actually produces: observed incident activity, indicators of compromise, related CVEs where they apply, root cause, and response and recovery activities.

The final report closes everything out after recovery.

The rules publish a machine-readable JSON schema for all three reports, and the automation rule, IEC-CSO-AIR, says providers SHOULD use automation, with the most quotable line in the Consolidated Rules: "Modern cloud services should not be reporting incidents by hand-crafting emails!" A 15-minute clock is not a drafting deadline. It is a formatting deadline for a report your tooling assembles.

The legacy rule, for certifications still on it

If your certification has not converted, your clock is the old one. The legacy procedures required reporting any suspected or confirmed incident causing actual or potential loss of confidentiality, integrity, or availability within one hour of identification by the provider's top-level Computer Security Incident Response Team, SOC, or IT department. The recipients: impacted customers through the FedRAMP secure repository, CISA per its guidelines, FedRAMP at the old address, and agency points of contact including authorizing officials. Updates ran daily to all points of contact, and a final report followed post-incident activity covering what occurred, the root cause, the response, lessons learned, and changes needed.

One hour, for everything, regardless of severity, is why the overhaul happened. The new clocks trade that simplicity for realism: fast reporting where the impact is real, measured reporting where it is not.

How these clocks stack with everyone else's

Your incident never runs only your clocks:

  • Your agency customers have their own duties. They report up their chains under FISMA and their agency procedures. Your one report feeds their many. Late provider reporting becomes their problem, which is why contracts and agency procedures often tighten your deadlines further.
  • CIRCIA looms over the whole market. When CIRCIA takes effect, unauthorized access through a cloud service provider compromise is one of the four substantial-impact prongs. Your incident can start your customer's CIRCIA clock. The CIRCIA guide covers that regime and its still-unpublished final rule.
  • Contracts add their own clocks. Agency contracts and commercial ones carry breach response clauses with notification duties that run on their own triggers.

The discipline is the same one behind every other regime: track each clock from its own trigger. FedRAMP runs from identification of a reportable incident. CIRCIA would run from reasonable belief. Contract clocks run from whatever the contract says.

What this means for your incident response plan

  • Put the reportability evaluation in the severity matrix. The PAIN definitions are your severity scale under this regime. The evaluation has a deadline, promptly, and the default punishes silence: no estimate means PAIN-5.
  • Pre-assemble the initial report. The static fields, the coordinator contact, the tracking identifier scheme, and the agency-customer list can be drafted today. At Class D speeds the report must be an edit, not a composition. The first 24 hours checklist is the frame; this reporting step belongs inside it.
  • Name the estimate owner. The PAIN call needs a person, made in the first minutes, recorded with its reasoning. That record is what the report asks for.
  • Build the automation the rules push for. The JSON schema exists so tooling can emit reports. The rules' own line about hand-crafting emails is the program telling you what it expects.
  • File every agency's procedure now. "Varies by agency" is a pre-incident task. The list of agency customers with their procedures is itself a plan artifact, and it changes as your customer list changes.
  • Keep both regimes visible until your certification converts. Until January 1, 2027 the legacy clock still applies to certifications that have not adopted the Consolidated Rules. Mark the plan with which regime you run and the date it changes.

Frequently asked questions

Which clock applies to us today? If you hold a Rev5 certification that has not adopted the Consolidated Rules, you still run the legacy one-hour rule. New 20x certifications run the 2026 rules now. Optional adoption for Rev5 opened July 4, 2026, the rules become mandatory for initial and ongoing certification on January 1, 2027, and the grace period ends June 1, 2027.

What happens if we skip the PAIN estimate? The default rating rule treats the incident as PAIN-5, the most severe rating, which runs the tightest clocks for your class. At Class D that means the initial report is due in 15 minutes.

Do we report outages? Not as incident reports. The reportable definition covers the confidentiality and integrity of federal customer data. The overhaul's proposal moved availability communication to a public status service with visible history.

Does reporting to FedRAMP cover CISA notification? No. CISA reporting runs under CISA's own Federal Incident Notification Guidelines, as it did under the legacy procedures. The new rules' notifications go to FedRAMP, agency customers by their procedures, and all necessary parties through the Trust Center.

We are starting FedRAMP. Which class do we pick? The classes map to the former Low, Moderate, and High impact levels, with Class A as the entry class. The incident clocks tighten as the class rises, so the choice is a response-capability decision: build the plan for the class you intend to hold before you certify into it. The program's marketplace and its published rules are the primary sources for what each class requires.

Federal work rewards firms whose claims carry sources. The assessors and advisors themselves are registry-listed, and their listings are documented: see the FedRAMP services directory.

Free download: every other regime's clocks on one printable page: Breach Notification Clocks cheat sheet (PDF, one page) →

The requirements here reflect FedRAMP's published Consolidated Rules for 2026 and the legacy procedures, as last reviewed. The rules carry a public changelog and changed as recently as October 13, 2026, so verify current requirements before relying on them. Last verified: October 2026. Have a correction or addition? Request inclusion or a correction →