Updated July 2026 to reflect the FedRAMP Consolidated Rules for 2026, released June 25, 2026.

The core concept

Incident response is what happens when something goes wrong: detect, contain, recover, learn. Every framework wants the same thing: a tested capability, not a plan in a binder.

The distinction matters. A plan is a document that describes what you would do. A capability is evidence that you have done it, tested it, and improved it based on what you learned. Frameworks differ on notification timelines, testing cadence, and how much of the “learn” part has to be continuous. The question is the same: when something breaks, can you respond effectively, and can you prove it?

The second half of that question is where most organizations struggle. The detection and containment usually happen because people care about keeping systems running. The documentation, the notification chain, the post-incident review, and the evidence trail that proves the plan actually executed as written, all of that falls apart when it is not wired into the operational workflow.

Incident response also touches other disciplines. The FedRAMP Security Inbox (FSI) is an inbound channel that creates tracked work. Monitoring and detection (SIEM, EDR, ITDR, uptime checks, disk space alerts) are the upstream feeds. After-action reviews produce improvement items that become tracked issues. IR is not a standalone capability. It is a node in the operational graph.

What CMMC requires

CMMC does not want a plan. It wants an operational capability with evidence of testing and execution.

The relevant practices:

• IR.L2-3.6.1 (Level 2, 5 points, not POA&M eligible): Establish an operational incident-handling capability for organizational systems that includes preparation, detection, analysis, containment, recovery, and user response activities.
• IR.L2-3.6.2 (Level 2, 5 points, not POA&M eligible): Track, document, and report incidents to designated officials and authorities, both internal and external.
• IR.L2-3.6.3 (Level 2, 1 point, POA&M eligible): Test the organizational incident response capability.

Two of the three IR practices are 5-point and not POA&M eligible. You cannot plan to fix them later. They have to be in place at assessment time. The capability has to be demonstrable, not aspirational.

IR.L2-3.6.1 has seven assessment objectives, [a] through [g]. Assessors verify each one:

• [a] An incident-handling capability is established
• [b] Preparation activities are performed
• [c] Detection activities are performed
• [d] Analysis activities are performed
• [e] Containment activities are performed
• [f] Recovery activities are performed
• [g] User response activities are performed

What a C3PAO assessor looks for:

• An incident response plan that names real people, not just “the security team.” Specific roles with specific individuals assigned.
• Evidence of actual incidents handled per the plan. Tickets with timelines, escalation records, resolution documentation. If you have had zero incidents and cannot show how you tested the capability, that is a gap.
• Tabletop exercises or functional tests at least annually, with documented results and lessons learned. This is the IR.L2-3.6.3 test.
• Training records for IR team members.
• A notification chain that is current. Not three job changes out of date.
• Post-incident reviews that feed back into the plan. Assessors look for evidence the plan evolved based on what happened.

The common gap: the plan lives on SharePoint. Nobody has tested it. The notification chain lists people who left. When something happens, the first 30 minutes are spent figuring out who to call. The plan says “escalate to the ISSO” but nobody remembers who the ISSO is because the person who held that role transferred six months ago.

The scoring matters. IR.L2-3.6.1 and IR.L2-3.6.2 are each 5-point and not POA&M eligible. If your incident response is a plan nobody has exercised, you fail both at assessment time. IR.L2-3.6.3 (testing) is 1-point and POA&M eligible. You can defer the testing practice, but not the capability itself.

What FedRAMP Rev5 requires

FedRAMP spells out what your IR program has to include, how often you test it, and who gets notified.

The relevant controls:

• IR-2 (Incident Response Training): train IR team members annually and upon assuming an IR role.
• IR-3 (Incident Response Testing): test the IR capability at least annually.
• IR-4 (Incident Handling): document, coordinate, and track incidents.
• IR-5 (Incident Monitoring): track and document incidents on an ongoing basis.
• IR-6 (Incident Reporting): report incidents to appropriate authorities. FedRAMP’s Rev5 control guidance for IR-6 now reads, in full: “Follow the FedRAMP Incident Evaluation and Communication rules.” More on those rules below; they apply to Rev5 too.
• IR-7 (Incident Response Assistance): provide an incident response support resource available to system users.
• IR-8 (Incident Response Plan): maintain the plan, distribute to key personnel, review and update annually.

Key requirements:

• Incident reporting following the FedRAMP Incident Evaluation and Communication (IEC) rules: FedRAMP Reportable Incidents get an Initial, Ongoing, and Final Incident Report to FedRAMP and agency customers (IEC-CSO-IIR, IEC-CSO-OIR, IEC-CSO-FIR). Mandatory for Rev5 by January 1, 2027; optional adoption from July 4, 2026.
• Where CISA fits now: FedRAMP collects responses to CISA Binding Operational Directives and Emergency Directives on behalf of the federal government, communicating through the FedRAMP Security Inbox.
• Annual IR plan review and update (IR-8).
• Defined points of contact with specific roles, not generic team references.
• Evidence of annual testing with findings and corrective actions (IR-3).
• Training records for IR team members, including initial training on assumption of the IR role (IR-2).
• An incident response support resource available to system users (IR-7). This is not just an email address. It is a mechanism users can reach when they need to report or respond to an incident.

The FedRAMP Security Inbox

The FedRAMP Security Inbox (FSI) survived into the Consolidated Rules; its rules now live in the Addressing FedRAMP Communication (AFC) ruleset, which FedRAMP labels “formerly FedRAMP Security Inbox.” It is required for both Rev5 and 20x, in force since January 5, 2026 (grace ended July 1, 2026), and it is the official channel for communications from FedRAMP.

AFC requirements:

• Providers MUST establish and maintain an email address to receive messages from FedRAMP (AFC-CSO-INB).
• Email from an @fedramp.gov or @gsa.gov address MUST be treated as sent from FedRAMP by default (AFC-CSO-TFG), received and reacted to without disruption, no CAPTCHAs or customer portals in FedRAMP’s way (AFC-CSO-RCV).
• Emergency messages route to a senior security official (AFC-CSO-EMR), and providers MUST complete the required actions within the timeframe stated in the message (AFC-CSO-CRA). The default timeframes scale by Certification Class (AFC-FRP-ERT): within 12 hours at Class D, by 3:00 p.m. Eastern on the 2nd business day at Class C, the 3rd business day at Class B, and the 5th business day at Class A. The old impact-level timeframes are gone; the clock is keyed to your class.
• Acknowledgment (AFC-CSO-ACK) is a SHOULD, not a MUST: providers SHOULD promptly and automatically acknowledge receipt.

The FSI is not optional. If FedRAMP sends you an Emergency message and your response time depends on someone noticing an email in a shared inbox, you have a problem. The FSI has to be wired into your ticketing system so that messages create tracked work with SLA timers.

What independent assessors look for:

• Evidence the IR plan is current, tested, and operational. Not current on paper. Current meaning updated based on the most recent test results and incident findings.
• Incident tickets with timelines, escalation records, and resolution documentation. The ticket should reconstruct the timeline from first detection to final resolution.
• Training records matching the IR roster.
• Evidence of annual testing with findings and corrective actions.
• A working FSI with evidence that messages are tracked and emergency messages are routed and resolved within the required timeframes.

The common gap: the plan is current on paper but never exercised. Notification chains reference people who left. No evidence of annual testing. The FSI does not exist or is not monitored. When an emergency message arrives from FedRAMP, nobody knows it is there until days later.

What FedRAMP 20x requires

20x pushes incident response harder than Rev5, with a specific focus on what happens after the incident. The INR domain covers persistent review of procedures, pattern analysis of past incidents, and feeding lessons learned back into the program.

A critical distinction: detection and monitoring live in a separate domain. The MLA (Monitoring, Logging, and Auditing) KSIs cover SIEM (KSI-MLA-OSM), log review (KSI-MLA-RVL), configuration evaluation (KSI-MLA-EVC), logged event types (KSI-MLA-LET), and log data access (KSI-MLA-ALA). INR is review, learn, improve. MLA is detect, monitor. Together, they close the full IR lifecycle.

The INR KSIs (the pilot’s numeric IDs like KSI-INR-01 no longer exist):

• KSI-INR-RIR, Reviewing Incident Response Procedures: “The effectiveness of documented incident response procedures is persistently reviewed.” One of only seven KSIs mandatory even at 20x Class A (FRC-CLA-MFR).
• KSI-INR-RPI, Reviewing Past Incidents: “Past incidents are persistently reviewed for patterns or vulnerabilities that were not previously apparent or identified.”
• KSI-INR-AAR, Generating After Action Reports: “Incident after action reports are generated and lessons learned are persistently incorporated.”

Related requirements:

• The FedRAMP Security Inbox now lives in the AFC ruleset (above), shared with Rev5; the pilot-era KSI-AFR family is gone from the final rules.
• Incident communication is now its own ruleset: IEC, Incident Evaluation and Communication (next section).
• KSI-CED-RAT (Reviewing All Training): the training KSI explicitly covers “staff involved with incident response or disaster recovery.”

The “persistently” bar

The bar is persistent review, not periodic. This is a meaningful difference.

KSI-INR-RIR asks you to persistently review the effectiveness of your IR procedures. Not review them once a year. Persistently. That means your review cadence is tied to incident volume, new threat intelligence, and organizational changes, not just a calendar entry.

KSI-INR-RPI asks you to look across incidents for patterns and systemic weaknesses. Not handle each incident as a standalone event. If three incidents in six months share the same root cause, 20x expects you to identify that pattern and address the systemic issue.

KSI-INR-AAR asks that lessons learned are persistently incorporated, meaning the IR program changes based on what you find. After-action reports that go into a folder and never change anything do not satisfy this KSI.

Incident Evaluation and Communication (IEC)

The pilot-era Incident Communications Procedures and their flat 1-hour reporting did not survive. The IEC ruleset replaced them, and it is no longer 20x-only: 20x providers adopt it from July 4, 2026, Rev5 by January 1, 2027.

The workflow is defined step by step:

• IEC-CSO-EFR: Providers MUST promptly evaluate incidents to determine whether they affect, or are likely to affect, the confidentiality or integrity of federal customer data. Those are FedRAMP Reportable Incidents.
• IEC-CSO-EFI: Providers SHOULD estimate the Potential Agency Impact N-rating (PAIN, N1 through N5). Skip the estimate and IEC-CSO-DPR defaults you to PAIN-5, the most aggressive reporting clock.
• IEC-CSO-IIR / IEC-CSO-OIR / IEC-CSO-FIR: an Initial Incident Report when the clock starts, Ongoing Incident Reports as new information becomes available, and a Final Incident Report once the incident is resolved and recovery is complete. All three go to FedRAMP, agency customers, and your trust center, against a FedRAMP JSON schema.

The timelines scale by Certification Class and PAIN rating. At PAIN-3 through PAIN-5:

Lower PAIN ratings get more time. These are notification timelines, not containment timelines. And IEC-CSO-AIR says providers SHOULD use automation to minimize human intervention in the reporting process. FedRAMP’s own commentary on that rule: “Modern cloud services should not be reporting incidents by hand-crafting emails!”

The common gap on the path to 20x: IR procedures reviewed once a year at best. Past incidents handled individually with no pattern analysis across them. After-action reports exist but lessons learned never track back to procedure updates. The connection between “incident happened, we learned something” and “the procedure changed because of what we learned” is not traceable.

The pain we lived

We manage compliant environments across multiple clients. Here is what incident response looked like before we built it into the platform.

The IR plan existed. It was a Word document. Last updated when the system was authorized. The notification chain listed people who no longer worked there. When an actual incident happened, the first 20 minutes were spent on Slack figuring out who owned what, because the plan was in a document library nobody had bookmarked.

Containment and recovery worked because the team knew their systems. The documentation did not. Timelines were reconstructed after the fact from memory and chat logs. “When did we first detect this?” turned into an argument about whether someone’s Slack message at 2:47 PM counted as detection or whether it was the monitoring alert at 2:32 PM that nobody saw until later.

Evidence collection was retroactive. After the incident was resolved, someone had to go back and document the timeline, the decisions, and the actions taken. This happened days later if at all. Details were lost. The documentation was a best-effort reconstruction, not a real-time record.

After-action reviews happened when we had time, which was rarely. When they did happen, the findings went into a document and nothing changed. The IR plan stayed the same. The notification chain stayed stale. The same gaps surfaced at the next incident. We knew what needed to change, wrote it down, and then moved on to the next fire. The improvement items were aspirational, not tracked.

Training was another gap. IR team members changed. New people joined. But the training was a one-time walkthrough when they started, not a structured program with annual refreshes. When an assessor asked for training records, we had onboarding notes, not IR-specific training evidence.

Annual tabletop exercises were a checkbox. Run the exercise, write up the findings, put the document in the compliance folder. Nobody tracked whether the findings were actually addressed. The exercise results and the plan existed in different locations with no linkage. The exercise in 2024 identified the same gaps as the exercise in 2023 because nothing had been fixed.

The FedRAMP Security Inbox was the worst gap. Before January 2026, the FSI requirement was not formalized the way it is now. Communications from FedRAMP arrived in email. Sometimes they got forwarded. Sometimes they sat. Emergency messages had no routing logic. There was no SLA timer, no senior security official automatically notified, no ticket created. If someone was on vacation, the message waited.

All incidents, whether from SIEM alerts, EDR detections, ITDR findings, or monitoring alerts (uptime, disk space, certificate expiry), needed to flow into one system. Instead, they were scattered across email, Slack, and three different dashboards. A SIEM alert generated a case in the SIEM console. A monitoring alert sent an email. An EDR detection went to the EDR dashboard. The team had to check multiple places to get a complete picture. Correlation across sources was a manual exercise.

How we automate it

An IR plan in a Word document is a plan that will fail when you need it. Here is how we built incident response into Stratus GRC-ITSM.

1. Incident ticket creation. Incidents are tickets with required fields: type, severity, affected systems, initial assessment. All sources flow into one system. SIEM alerts, EDR detections, ITDR findings, monitoring alerts (uptime, disk space), manual reports, and the FedRAMP Security Inbox all correlate into the same Incident ticket type with the same required fields. One intake point, regardless of source.
2. The FedRAMP reporting lifecycle lives in the ticket. This is the part we are proudest of. We defined the full incident lifecycle, initial incident report (IIR), ongoing incident report (OIR), final incident report (FIR), and after-action report (AAR), directly into Incident tickets. The platform tracks the due dates of each step automatically and self-generates validation evidence of the process. When IEC-CSO-IIR gives a Class C provider 1 hour for a PAIN-3 initial report, the deadline on the ticket is the same deadline FedRAMP is counting against. And because the reports are steps in the ticket, machine-readable incident reports in FedRAMP’s JSON format are generated from the same data.
3. Automatic POC notification. Incident creation triggers notification to all defined points of contact. Nobody has to remember who to call. Roles are defined in the system and updated when people change. A P1 incident at 3 AM notifies the right people immediately, not when someone checks their email in the morning.
4. Severity-based workflows. Different severities trigger different response workflows. A P1 incident escalates immediately with broader notification and a compressed timeline. A P3 follows standard triage. The routing is defined once and applied every time. No ad-hoc decisions about who to loop in.
5. FedRAMP Security Inbox integration. The FSI is wired to create tickets automatically. Emails from fedramp.gov and gsa.gov create tracked tickets. Emergency messages route to the senior security official (AFC-CSO-EMR) with the completion timeframe from the message (AFC-CSO-CRA), against the class-based defaults above. The SLA timer starts when the ticket is created, not when someone notices the email.
6. Response phase tracking. Each phase of the response (detection, containment, eradication, recovery) is tracked with timestamps and assigned owners, and an externally-reportable alerts and incidents report surfaces the full FedRAMP incident timeline (detected, evaluation, initial report, ongoing, recovery, final) across every incident. When an assessor asks “show me the timeline for your last incident,” you pull the report. No reconstruction from memory or chat logs.
7. After-action workflow. When a security incident is closed, an after-action report is created automatically. This is not optional. The AAR captures root causes, lessons learned, corrective actions, and external reportability, tracked like any other ticket. Approval stays human by design; the platform prepares the AAR, a person signs it. Findings feed the issue tracker as improvement items linked to the incident that produced them. This directly supports KSI-INR-AAR, and completed AARs feed the KSI validation evidence automatically.
8. Tabletop exercise tracking. Annual IR exercises are scheduled as recurring tasks. Results, attendance, and improvement items are tracked as tickets, not stored in a separate folder. When an assessor asks for evidence of IR testing (IR.L2-3.6.3 for CMMC, IR-3 for Rev5), the exercise records, findings, and corrective actions are all in the same system as the incidents themselves.
9. Pattern analysis. Incident data is aggregated for trending by type, severity, root cause, and response time. This supports KSI-INR-RPI, which asks you to persistently review past incidents for patterns. The platform surfaces the data. The IR lead reviews it and takes action when patterns emerge.

graph LR
    ALERT[Alerts: SIEM, monitoring, FedRAMP inbox] --> INC[Incident Ticket]
    INC --> CONTAIN[Contain]
    CONTAIN --> RECOVER[Recover]
    RECOVER --> AAR[After-Action Report]
    INC --> RPT[IEC Reports: IIR / OIR / FIR on tracked due dates]

    style ALERT fill:#2b5797,stroke:#5b9bd5,color:#fff
    style INC fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style CONTAIN fill:#5c4a1a,stroke:#ffc857,color:#fff
    style RECOVER fill:#1a5c3d,stroke:#51cf66,color:#fff
    style AAR fill:#4a1a5c,stroke:#c77dff,color:#fff
    style RPT fill:#5c1a3d,stroke:#ff6b9d,color:#fff

The throughline: every incident, from every source, enters the same workflow. The workflow handles routing, notification, escalation, FedRAMP reporting deadlines, documentation, after-action reporting, and improvement tracking. One process serves CMMC assessors, FedRAMP independent assessors, and 20x KSI validation.

When a CMMC assessor asks for evidence of an operational incident-handling capability (IR.L2-3.6.1), the incident tickets, timelines, escalation records, and after-action reports are there. When an independent assessor asks for FSI evidence and IEC reporting, the tracked tickets with SLA timers, the report timestamps, and the resolution records are there. When a 20x validation check hits KSI-INR-RIR for persistent procedure review, the improvement items linked to incidents and the procedure updates they triggered are there.

Compliance is a byproduct of operations, not a separate workstream.

FAQ

This article is part of a 15-part series on the operational disciplines that CMMC, FedRAMP Rev5, and FedRAMP 20x all test. [Read the series overview: Stop Building for Compliance. Build for Operations.]