Incident Response¶

This document establishes the organization's policy for detecting, evaluating, reporting, and closing incidents affecting the system, and the procedures by which GRC-ITSM executes that policy. It covers alert ingest and categorization, escalation of an Alert into an Incident, the human reportability and impact evaluation, the FedRAMP reporting chain from initial report through final report, the After Action Report and its approval, and the FedRAMP Security Inbox. It implements the FedRAMP Incident Evaluation and Communication (IEC) and Addressing FedRAMP Communication (AFC) rule families from the FedRAMP Consolidated Rules for 2026, and the Incident Response Key Security Indicators (KSI-INR).

Download the KB article (Markdown)

Framework applicability¶

FedRAMP 20x classes differ in reporting timeframes and validation depth, not in the procedure itself; the Organization-Defined Values table carries the Class C values.

Policy¶

• P-1. Every alert is tracked and categorized. Alerts from security and operational tooling are ingested as Alert tickets and assigned a category from the shared Alerts and Incidents taxonomy. The category differentiates the alert type for triage and reporting and drives automatic framework attribution.
• P-2. Reportability is a human determination, made promptly. Every incident is evaluated to determine whether it affects, or is likely to affect, the confidentiality or integrity of federal customer data; such incidents are FedRAMP Reportable Incidents (IEC-CSO-EFR, MUST). The determination is a required workflow step, recorded with its supporting fields on the ticket.
• P-3. Impact rating sets the clock. Reportable incidents are assigned a Potential Agency Impact N-rating (PAIN) at evaluation (IEC-CSO-EFI, SHOULD). A FedRAMP Reportable Incident whose PAIN rating is not promptly estimated is handled as PAIN 5 (IEC-CSO-DPR, MUST); the responder performing the evaluation applies that default.
• P-4. Reporting is persistent until the incident is resolved. Affected parties receive an Initial Incident Report, Ongoing Incident Reports as new information becomes available, and a Final Incident Report once recovery is complete (IEC-CSO-IIR, IEC-CSO-OIR, IEC-CSO-FIR, each MUST at Class C), on the PAIN-keyed timeframes in the ODV table.
• P-5. Reporting is automated wherever it can be. Incident reporting draws on platform data and minimizes human intervention in producing and delivering reports (IEC-CSO-AIR, SHOULD).
• P-6. Dangerous vulnerabilities are incidents. An internet-reachable, likely exploitable vulnerability rated above PAIN 3 is treated as a FedRAMP Reportable Incident until it is at least partially mitigated to PAIN 3 or below (VER-TFR-IRI, SHOULD at Class C; the organization implements it as binding internal policy). A likely exploitable vulnerability that is not internet-reachable and is rated PAIN 5 is treated the same way until it is at least partially mitigated to PAIN 4 or below (VER-TFR-NRI, MAY at Class C; the organization implements it as binding internal policy).
• P-7. FedRAMP can always reach the organization. The organization maintains a FedRAMP Security Inbox, receives FedRAMP mail without disruption, trusts the @fedramp.gov and @gsa.gov domains by default, routes Emergency designated messages to a senior security official, completes required actions within the timeframes in Emergency and Emergency Test designated messages, and immediately notifies FedRAMP of any inbox address change (AFC-CSO-INB, AFC-CSO-RCV, AFC-CSO-TFG, AFC-CSO-EMR, AFC-CSO-CRA, AFC-CSO-NOC, each MUST). Receipt is acknowledged automatically (AFC-CSO-ACK, SHOULD, implemented).
• P-8. Every incident ends in an approved After Action Report. Root cause, lessons learned, and corrective actions are authored on the incident record and approved by the After Action Report Approvers CAB before the incident resolves (KSI-INR-AAR).
• P-9. The procedure reviews itself. The effectiveness of this document is reviewed on the cadence in the ODV table (KSI-INR-RIR), and past incidents are reviewed for patterns not previously apparent (KSI-INR-RPI).

Organization-defined values¶

Roles and responsibilities¶

• Anyone may report a suspected incident.
• Assigned agent (Alerts and Incidents). Each Alert and Incident is assigned a tracking owner automatically via the Agent Assignment - Alerts/Incidents role. Assignment confers tracking ownership, not approval authority.
• Evaluating responder. Completes the Evaluate action: the reportability determination, the PAIN rating and its rationale, the incident timestamps, and the detection source.
• After Action Report Approvers CAB. The Approver - After Action Reports role grants membership to the After Action Report Approvers CAB, who approve After Action Reports. Approval is always by the CAB, never by the assigned agent.
• FedRAMP Security Inbox notification group. The Notifications - FedRAMP Security Inbox role defines who is notified of inbound FedRAMP mail; at least three people hold it.
• ISSO and System Owner. Accountability and escalation. The ISSO reviews this document on the cadence in the ODV table and the System Owner approves it. The System Owner designates the senior security official who receives Emergency designated messages.

Alert ingest and categorization¶

GRC-ITSM ingests alerts from endpoint detection and response, SIEM, observability tooling, and similar sources into Alert tickets. Every Alert carries a category from the shared Alerts and Incidents taxonomy:

The category differentiates alert types for triage and reporting, and drives the automatic attribution of controls, requirements, KSIs, and FedRAMP rules to the ticket per (ticket type x category), scoped to the system's authorized baselines.

Escalation to Incident¶

A responder escalates an Alert into an Incident with an action button. The escalation converts the Alert into an Incident in place: all Alert field detail carries forward, and the incident evaluation and reporting fields and processes are added. Because Alerts and Incidents share one category taxonomy, the category set at Alert creation survives the conversion.

Two further entry paths open Incidents directly:

• Vulnerability escalation (automated). A deployed escalation runbook converts qualifying vulnerabilities into Incidents at the two boundaries in P-6: internet-reachable, likely exploitable, above PAIN 3 (VER-TFR-IRI), and non-internet-reachable, likely exploitable, at PAIN 5 (VER-TFR-NRI). The runbook reads the current rating, so an approved Vulnerability Deviation that adjusts the rating adjusts the escalation. Escalated tickets name their source in the title and preserve the link to the source Issue. Vulnerability handling itself follows the Vulnerability Detection & Response Policy and Procedures.
• FedRAMP Security Inbox. Inbound FedRAMP mail opens an Incident directly; see the FedRAMP Security Inbox section.

Evaluation¶

The Incident workflow is Open, Reporting, AAR, Resolved. The first step is a human Evaluate action capturing these required structured fields:

For reportable incidents the PAIN rating sets the reporting clocks. The platform tracks each reporting deadline with an OLA on the Incident ticket, keyed to the PAIN rating, and notifies the incident points of contact.

The FedRAMP reporting chain¶

Each report is a structured, timestamped action on the Incident ticket. Evaluation results carry forward read-only, and the workflow enforces the order.

1. Send Initial Report (IIR). Records Reported To, Initial Report Sent At, Functional Impact (required), Recovery Plan, and Affected Agencies (IEC-CSO-IIR).
2. Send Ongoing Report (OIR). Repeatable; run as new information becomes available and on the cadence in the ODV table (IEC-CSO-OIR).
3. Recovery Complete. Records Recovery Completed At against the recovery plan.
4. Send Final Report (FIR). Available only after recovery completes. Requires Final Report Sent At, Functional Impact, Root Cause, Response and Recovery Activities, and Affected Agencies; carries forward Reported To, Observed Activity, and Related CVEs (IEC-CSO-FIR).

The full FedRAMP timeline therefore lives on one record: started, detected, evaluation completed, initial report, ongoing reports, recovery complete, final report. Externally reportable incidents surface on dedicated reports carrying that timeline in human-readable and machine-readable form on the FedRAMP Incident Report schema, which is how the organization minimizes human intervention in reporting (IEC-CSO-AIR).

After Action Report and approval¶

After the Final Incident Report, the Complete AAR action authors the After Action Report on the same ticket: Root Cause, Lessons Learned, and Corrective Actions.

The AAR Approval action then runs the After Action Report Approvers approval process: the submitter selects one or more CAB members to approve, and the Approver - After Action Reports role grants membership to the After Action Report Approvers CAB, who approve AARs. AAR completion writes dated machine validation evidence automatically. The workflow advances through AAR to Resolved.

FedRAMP Security Inbox¶

A dedicated FedRAMP Client in GRC-ITSM defines the FedRAMP senders as users. The FedRAMP Security user carries fedramp_security@fedramp.gov and fedramp_security@gsa.gov, the two mailboxes FedRAMP uses for Emergency and Emergency Test designated messages (AFC-FRP-UFS); broader trust applies at the @fedramp.gov and @gsa.gov domain level (AFC-CSO-TFG).

Inbound mail from these senders:

• opens an Incident ticket carrying the message criticality designation in the title (for example [EMERGENCY]);
• sends an automatic acknowledgment on receipt (AFC-CSO-ACK);
• notifies every holder of the Notifications - FedRAMP Security Inbox role, under an inbox SLA requiring human acknowledgment within one hour (an internal SLA that supports AFC-CSO-RCV) with at least three people notified.

The organization routes Emergency designated messages to the senior security official designated by the System Owner (AFC-CSO-EMR), completes the required actions in Emergency and Emergency Test designated messages within the timeframe included in the message (AFC-CSO-CRA), and immediately notifies FedRAMP of any change to the FedRAMP Security Inbox address (AFC-CSO-NOC). Actions in Important designated messages are completed within the specified timeframe (AFC-CSO-IMA, SHOULD).

The same FedRAMP Security user is the outbound target: the IEC incident reporting actions carry an email notification target of fedramp_security@fedramp.gov.

Automated validation evidence¶

Operating this process produces machine validation evidence automatically. AAR completion writes dated validation runs, evidencing that after action reports are generated and lessons learned are incorporated (KSI-INR-AAR). Reporting-deadline OLAs accumulate pass and fail history against the IEC reporting rules. Externally reportable incidents publish on the FedRAMP Incident Report schema for automated retrieval.

Authority, review, and revision¶

Issued under the authority of the System Owner and binding on all personnel with access to the system. Exceptions require written System Owner approval.

The ISSO reviews this document for effectiveness at least annually, after each approved After Action Report, and when frameworks, the system, or lessons learned warrant; the System Owner gives final approval. This review evidences persistent review of documented incident response procedure effectiveness (KSI-INR-RIR).

Past incidents are reviewed for patterns or vulnerabilities not previously apparent (KSI-INR-RPI). This review is a procedure commitment: the organization performs it on the cadence in the ODV table, and the scheduled-ticket mechanism that will carry it in GRC-ITSM is not yet implemented.

FedRAMP coverage¶

IEC provider rules: Evaluate FedRAMP Reportability (MUST), Default PAIN Rating (MUST), Estimate Federal Impact (SHOULD), Initial Incident Report (MUST at Class C), Ongoing Incident Reports (MUST at Class C), Final Incident Report (MUST at Class C), Automated Incident Reporting (SHOULD) (IEC-CSO). AFC provider rules: Maintain a FedRAMP Security Inbox (MUST), Notification of Changes (MUST), Receive Email Without Disruption (MUST), Trust @fedramp.gov and @gsa.gov (MUST), Complete Required Actions (MUST), Emergency Message Routing (MUST), Acknowledge Receipt (SHOULD), Important Message Actions (SHOULD) (AFC-CSO); the FedRAMP-side sender rule the inbox relies on is AFC-FRP-UFS. VER incident boundaries: Internet-Reachable Incidents (VER-TFR-IRI, SHOULD at Class C), Non-Internet-Reachable Incidents (VER-TFR-NRI, MAY at Class C). KSI-INR: Generating After Action Reports, Reviewing Incident Response Procedures, Reviewing Past Incidents. Underlying NIST: IR-4, IR-5, IR-6. CMMC: IR.L2-3.6.1, IR.L2-3.6.2, IR.L2-3.6.3.