KSI-AFR-ICP—Incident Communications Procedures
Formerly KSI-AFR-10
>Control Description
>FRMR Requirements12
Normative requirements from the FedRAMP Requirements and Recommendations document — 8 mandatory, 3 recommended, 1 optional.
Incident Reporting to FedRAMP
Providers MUST responsibly report incidents to FedRAMP within 1 hour of identification by sending an email to fedramp_security@fedramp.gov or fedramp_security@gsa.gov.
Incident Reporting to Agencies
Providers MUST responsibly report incidents to all agency customers within 1 hour of identification using the incident communications points of contact provided by each agency customer.
Incident Reporting to CISA
Providers MUST responsibly report incidents to CISA within 1 hour of identification if the incident is confirmed or suspected to be the result of an attack vector listed at https://www.cisa.gov/federal-incident-notification-guidelines#attack-vectors-taxonomy, following the CISA Federal Incident Notification Guidelines at https://www.cisa.gov/federal-incident-notification-guidelines, by using the CISA Incident Reporting System at https://myservices.cisa.gov/irf.
Incident Updates
Providers MUST update all necessary parties, including at least FedRAMP, CISA (if applicable), and all agency customers, at least once per calendar day until the incident is resolved and recovery is complete.
Incident Report Availability
Providers MUST make incident report information available in their secure FedRAMP repository (such as USDA Connect) or trust center.
Final Incident Report
Providers MUST provide a final report once the incident is resolved and recovery is complete that describes at least:
- What occurred
- Root cause
- Response
- Lessons learned
- Changes needed
Responsible Disclosure
Providers MUST NOT irresponsibly disclose specific sensitive information about incidents that would likely increase the impact of the incident, but MUST disclose sufficient information for informed risk-based decision-making to all necessary parties.
Implementation Summaries
Providers MUST maintain simple high-level summaries of at least the following for each Key Security Indicator:
- Goals for how it will be implemented and validated, including clear pass/fail criteria and traceability
- The consolidated _information resources_ that will be validated (this should include consolidated summaries such as "all employees with privileged access that are members of the Admin group")
- The machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- The non-machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- Current implementation status
- Any clarifications or responses to the assessment summary
Automated Reporting
Providers SHOULD use automated mechanisms for reporting incidents and providing updates to all necessary parties (including CISA).
Human and Machine-Readable
Providers SHOULD make incident report information available in consistent human-readable and machine-readable formats.
Application within MAS
Providers SHOULD apply ALL Key Security Indicators to ALL aspects of their cloud service offering that are within the FedRAMP Minimum Assessment Scope.
1 optional guidance (MAY)
AFR Order of Criticality
Providers MAY use the following order of criticality for approaching Authorization by FedRAMP Key Security Indicators for an initial authorization package:
- Minimum Assessment Scope (MAS)
- Authorization Data Sharing (ADS)
- Using Cryptographic Modules (UCM)
- Vulnerability Detection and Response (VDR)
- Significant Change Notifications (SCN)
- Persistent Validation and Assessment (PVA)
- Secure Configuration Guide (RSC)
- Collaborative Continuous Monitoring (CCM)
- FedRAMP Security Inbox (FSI)
- Incident Communications Procedures (ICP)
>Trust Center Components4
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express incident communication through automated status pages with structured timelines, webhook-driven agency notifications, and machine-readable incident feeds. Every notification is timestamped and logged, creating an immutable communication trail that proves when agencies were informed — not just that a process exists.
Incident Status Page
Dashboard expressing incident status with structured communication timelines — agencies see when each notification was sent and the incident lifecycle in full
Incident Communication Procedures
How customers and agencies are notified during security incidents — including automated notification triggers and escalation paths
Incident Communication SLA
Human-readable SLAs for incident notification timelines (e.g., US-CERT 1-hour reporting)
Post-Incident Report Template
Sample post-incident report showing communication timeline and root cause analysis
>Programmatic Queries
CLI Commands
pd incident list --since "30 days ago" --output json | jq '.[] | {id,title,status,urgency,created_at}'pd incident log --id <incident-id> --output json | jq '.[] | {type,created_at,summary}'>20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Does your incident response plan explicitly address every FedRAMP ICP requirement (initial notification, updates, final report), and where are gaps documented?
- •Are all incident severity levels mapped to specific ICP notification timelines, including edge cases like near-misses or suspected but unconfirmed incidents?
- •How do you ensure incident communications cover all leveraging agencies, not just the ones that reported or were directly affected?
- •What happens when an incident spans multiple CSO components or involves a shared responsibility boundary — how do you ensure nothing falls through the cracks?
Automation & Validation:
- •What automated severity classification triggers FedRAMP notification workflows, and what happens if the classification engine miscategorizes an incident?
- •How do you automatically track and enforce ICP notification deadlines (e.g., 1-hour, 24-hour), and what fires when a deadline is about to be missed?
- •What automated tests or tabletop simulations validate your incident communication pipeline end-to-end?
- •If your notification system (email, ticketing, SOAR) goes down during an active incident, what failover procedure ensures communications still go out on time?
Inventory & Integration:
- •How does your SIEM or SOAR platform integrate with the ICP notification workflow to automatically trigger communications based on detection rules?
- •How do you maintain a current, verified contact list for FedRAMP, CISA, and all leveraging agency security teams, and how often is it validated?
- •What tools track the full lifecycle of incident communications (initial alert through final report) to ensure no required communication is dropped?
- •How are secure communication channels (encrypted email, portal) integrated into your incident response toolchain?
Continuous Evidence & Schedules:
- •How do you prove that ICP notification timelines were met for every reportable incident over the past year?
- •Is incident communication history available via API or structured data export, or only as email threads and PDFs?
- •How do you demonstrate that ICP procedures remain effective between incidents — through drills, audits, or automated checks?
- •What evidence shows follow-up communications and final incident reports were delivered on the required schedule?
Update History
Ask AI
Configure your API key to use AI features.