FedRAMP AI Incident Reporting Starts with the Model Request Record

FedRAMP changed its incident communication model in 2026. The Consolidated Rules for Incident Evaluation and Communication require providers to promptly evaluate incidents that affect, or are likely to affect, the confidentiality or integrity of federal customer data. A reportable event then moves through an initial report, ongoing reports and a final report under class-specific timeframes.

An LLM incident fits that process when the facts meet the rule. The response team needs those facts at request level: identity, federal customer data, model destination, policy, decision and time.

TL;DR

• Start the FedRAMP reportability evaluation with federal customer data and likely confidentiality or integrity impact.
• Confirm the certification class, applicable transition date and PAIN rating before calculating a deadline.
• Build initial, ongoing and final reports from one incident record with stable request identifiers.
• Preserve model-route, identity, content-classification and policy evidence for affected HTTP calls.

Current rules and transition dates control the playbook

FedRAMP launched the Consolidated Rules for 2026 on 24 June 2026. The Incident Evaluation and Communication rules allow optional adoption beginning 4 July 2026. For Rev5, the rules list 1 January 2027 for obtaining and maintaining certification, with a grace period ending 1 June 2027. For 20x, the published dates differ. A provider operating on 23 September 2026 must therefore identify its certification type, class and adopted rule set before using a reporting clock.

The current Rev5 incident-response control page maps IR-1 through IR-9 to the FedRAMP Incident Evaluation and Communication rules. It covers policy, training, testing, handling, monitoring, reporting, plans and information-spillage response.

Write the applicable path at the top of the runbook. A stale PDF saved in a shared drive can carry rescinded procedures. FedRAMP's legacy site now warns readers that earlier standalone materials were replaced during the 2026 transition.

Reportability begins with federal customer data

Rule IEC-CSO-EFR tells providers to promptly evaluate incidents for actual or likely effects on the confidentiality or integrity of federal customer data. The same rule identifies those events as FedRAMP Reportable Incidents. For AI traffic, the evaluation should answer five concrete questions:

• Which federal customer data entered the prompt, retrieval context or response?
• Which agency customers were likely affected?
• Which model endpoint and provider entity received the request?
• Did an unauthorized identity access the data, or did an approved identity use an unapproved route?
• Which policy decision and application action occurred?

Availability can still matter under the wider incident and service context, while the current reportability statement quoted above centers confidentiality and integrity. Keep the exact rule language in the decision record.

The FedRAMP AI controls mapping helps assign identity, audit, communications and configuration evidence to NIST SP 800-53 families.

PAIN ratings set the reporting tempo

The 2026 rules introduce Potential Agency Impact N-ratings from N1 through N5. N1 is likely minimal customer effect on one or more agencies. N5 is likely debilitating customer effect on more than one agency. When a provider skips a prompt impact estimate, IEC-CSO-DPR assigns the incident a default PAIN-5 treatment.

Initial-report timeframes then vary by certification class and PAIN. The published reference gives Class B six hours for the three highest ratings and one business day for N1 or N2. Class C shortens the N3, N4 and N5 interval to one hour. A Class D provider receives 15 minutes at those same ratings. Teams should read the live table for their class because ongoing and final-report clocks use different intervals.

My view is that a severity matrix hidden in a 40-page plan is a response failure waiting to happen. Put the certification class, PAIN rubric and contact route on the first screen an on-call analyst opens.

The initial report needs request facts

The current initial-report rule asks for the federal incident response coordinator, provider tracking identifier, description, timeline, PAIN history and explanation, functional impact, federal customer data types, recovery plan and likely affected agencies. It directs notification to FedRAMP, agency customers under agency-specific procedures and all necessary parties through the applicable update channel.

An AI incident record should supply those fields without forcing responders to reconstruct traffic across four consoles. Include:

• incident ID and affected AI request IDs;
• first known activity, detection time and reportability decision time;
• authenticated principal, workload and agency tenant;
• prompt and response data classifications;
• model provider, endpoint, region and route resolution;
• policy version, decision, response treatment and containment state.

At 02:17, the useful view is a narrow row showing agency, principal, model, data class, decision and time. A chart labelled "LLM errors increased" leaves the initial report mostly empty.

Ongoing and final reports need stable lineage

Ongoing reports add observed activity, indicators of compromise, related CVEs where applicable, root cause, and response and recovery work. The final report follows resolution and completed recovery. Stable identifiers should connect every update to the same incident, affected requests, changes and evidence.

A model route may change during containment. Preserve the original endpoint and the emergency policy version, then record the corrective version deployed afterward. IR-4 in the NIST SP 800-53 catalog calls for preparation, detection and analysis, containment, eradication and recovery. IR-5 tracks and documents incidents. IR-6 covers internal and authority reporting. Those controls provide the system-level structure; FedRAMP's current communication rules define the provider reporting process.

Use the same evidence schema for permitted and denied requests. A denial during the incident window can prove containment. It can also show that another path remained open.

AI scenarios belong in testing and training

IR-3 calls for testing the incident response capability. IR-2(1) adds simulated events to training. Include AI-specific scenarios that cross the authorized cloud-service boundary:

1. An authenticated employee sends federal customer data to an unapproved LLM endpoint.
2. A retrieval component exposes another agency tenant's records in the model context.
3. A routing fallback changes region after the approved provider endpoint fails.
4. A prompt-injection sequence causes an agent to include protected context in an outbound model call.

For each exercise, test reportability, PAIN assignment, contacts, initial-report assembly, containment, ongoing updates and final evidence. The FedRAMP AI audit-evidence guide supplies the request fields an assessor or incident lead should sample.

Keep the HTTP boundary exact by assigning local model execution, endpoint compromise and credential theft to the endpoint, IAM, cloud and provider evidence owners. A traffic gateway contributes only where the relevant model request or response crossed its path.

Automation should assemble rather than decide

IEC-CSO-AIR says providers should use automation to minimize human intervention in reporting FedRAMP Reportable Incidents. Automation can collect timestamps, affected request IDs, model routes, data classes, policy versions and agency tenants. It can populate the current JSON schema and alert the designated coordinator.

Human owners still decide legal and factual questions: reportability, likely impact, affected agencies, message approval and recovery status. Preserve the evidence behind those decisions. A machine-generated PAIN rating without its inputs gives reviewers an answer with no reasoning trail.

The FedRAMP AI compliance checklist pairs this incident workflow with boundary, identity, logging and change-control tests that should run before production use.

DeepInspect

DeepInspect can provide detection, containment and evidence for authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It consumes identity context, classifies prompt content, evaluates role and route policy, restricts destinations, inspects responses and writes a per-decision record outside the calling application.

That record can populate an incident timeline and identify affected agency tenants, model routes and policy decisions. DeepInspect leaves FedRAMP reportability, PAIN assignment, notifications, endpoint response, stolen credentials, local execution, STDIO and bypass traffic with the responsible provider, agency, identity and incident teams.

Book a technical deep dive at deepinspect.ai.