RFC-0031 Updated Incident Communications Procedures

[pete-gov]

RFC-0031 Updated Incident Communications Procedures

❓ Please note that FedRAMP will not answer questions in this thread as it is reserved for public comment. If you would like to ask a question or generally discuss this RFC informally, please use the General discussion / Q&A for Mar/Apr RFCs. Thank you!

Status: Closed
Start Date: April 8, 2026
Closing Date: May 12, 2026

---

Summary & Motivation

FedRAMP’s historical Incident Communications Procedures require cloud service providers to “report any incident (suspected or confirmed) that results in the actual or potential loss of confidentiality, integrity, or availability of the cloud service, including the impact to federal customer data that it stores, processes, or transmits.”

These procedures have not been consistently followed or enforced because they are broad and often unclear. In practice, most cloud service providers with FedRAMP Certification rarely notify FedRAMP of an incident. FedRAMP believes that a clear set of reporting requirements must be established using a modern rules-based format to ensure cloud service providers understand and can implement incident reporting requirements to meet their ongoing FedRAMP certification requirements after initial certification. These rules should focus effort on reporting meaningful incidents that an agency customer would not otherwise be aware of and align with the potential adverse impact to agency operations.

This RFC proposes updates to the Incident Communications Procedures as follows:

1. Move reporting on incidents causing an impact to availability into public status pages or other notification mechanisms without requiring federal-specific reporting.
2. Focus incident reporting on likely or confirmed incidents that threaten confidentiality or integrity of federal customer data.
3. Clearly define the expected incident reporting data for federal reportable incidents.
4. Modify the expected timeframes for federal reportable incidents to factor for the potential adverse impact to the government and the level of commitment from the cloud service provider for managing agency risk, including much stricter requirements for cloud services that commit to Class D (High) certifications to align with the potential impact of an incident to such systems used by agencies.

For members of the public that have not followed recent developments in the FedRAMP modernization process, Public Notice NTC-0004 explains FedRAMP Certification and the related classes.

Feedback Requested

In addition to general feedback, FedRAMP would like to understand how we can effectively align these requirements with the existing reporting and informational fields that cloud service providers are creating during typical commercial incident response.

Effective Date(s) & Overall Applicability

The final version of this set of rules will be included in the FedRAMP Consolidated Rules for 2026 by the end of June 2026 after incorporating feedback from public comment. It will apply to both Rev5 and 20x type FedRAMP Certifications (replacing the current Incident Communications Procedures for 20x).

Documentation Guidelines

The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this documentation are to be interpreted as described in IETF RFC 2119.

This document exists within the full context of FedRAMP documentation, including FedRAMP Definitions. It is not intended to be a standalone document and often references terminology or requirements that are explained elsewhere. Members of the public that haven’t followed recent developments in the FedRAMP modernization process may need to review other materials for context.

The following critical terms used in this document are already defined in the FedRAMP Definitions:

• Federal Customer Data
• Incident
• Likely
• Promptly
• Negligible Adverse Effect
• Limited Adverse Effect
• Serious Adverse Effect
• Catastrophic Adverse Effect

New Definitions

This RFC proposes modifying the official FedRAMP Definitions for Rev5 and 20x as follows:

FRD-INT Incident

Has the meaning given in 44 USC § 3552 (b)(2), which is “an occurrence that—(A) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (B) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.”

Note: The FedRAMP Definition for this term previously scoped incidents only to those affecting federal customer data; this update to terminology removes that scoping to apply the base term “incident” to any such action that affects a cloud service offering.

FRD-IIR Initial Incident Report

An initial report about an incident that is supplied by FedRAMP Certified cloud service providers to FedRAMP and agency customers, aligned to the rules in the FedRAMP Incident Communications Procedures.

FRD-OIR Ongoing Incident Report

A recurring report about an ongoing incident that is supplied by FedRAMP Certified cloud service providers to FedRAMP and agency customers, aligned to the rules in the FedRAMP Incident Communications Procedures.

FRD-FIR Final Incident Report

A final report after recovery from an incident that is supplied by FedRAMP Certified cloud service providers to FedRAMP and agency customers, aligned to the rules in the FedRAMP Incident Communications Procedures.

FRD-RSP Responsibly

In a way that shows that you have good judgment and the ability to act correctly and make decisions on your own.

Note: Refrain from broadcasting any details that might assist adversaries in their endeavors, disclosing vulnerabilities prior to full remediation, or providing overly specific technical information that could potentially facilitate further compromise. In short: use your best judgment, don't be that guy.

FRD-AAP All Affected Parties

All federal entities whose interests are affected directly or are likely to be affected directly in the event of a vulnerability or incident related to federal customer data. This always includes FedRAMP and the directly impacted federal customer agency.

Incident Communication Procedures

The following requirements and recommendations will apply to Incident Communication Procedures.

ICP-FRP-ORV Ongoing Review

FedRAMP MUST periodically review Incident Communication Procedures with cloud service providers, based on lack of reporting or other information, to ensure cloud service providers are aware of the rules and have properly implemented procedures in alignment with these rules. If a provider is found to be unaware of these rules or failed to implement proper procedures, FedRAMP will request a Corrective Action Plan and grant a 3 month grace period to implement proper procedures pending remediation and revocation of FedRAMP Certification.

Effective Date: 2027 January 1

Note: Failure to follow proper incident reporting procedures is a critical failure in a service provider’s implementation of FedRAMP Certification controls.

ICP-CSO-PAR Public Availability Reporting

Class C (Moderate) and Class D (High) providers MUST maintain a publicly accessible status service that indicates the current and historical availability of core services within their cloud service offering over at least the past 30 days, including information about any availability incidents, in both human-readable and machine-readable formats; information on how to access and use this service must be available to all necessary parties in the authorization data for the cloud service offering.

Class A (Pilot) and Class B (Low) providers SHOULD maintain a publicly accessible status service that indicates the current and historical availability of core services within their cloud service offering over at least the past 30 days, including information about any availability incidents, in both human-readable and machine-readable formats; information on how to access and use this service must be available to all necessary parties in the authorization data for the cloud service offering.

Notes:

• This requirement allows considerable flexibility in maintaining this service to encourage providers to optimize for their federal agency customer experience, including flexibility in interval and presentation.
• Providers are strongly encouraged to create an availability reporting process that allows customers to subscribe to notifications in addition to having a public status service.

ICP-CSO-EFR Evaluate Federal Reportability

Providers MUST promptly evaluate incidents to determine if they affect confidentiality or integrity of federal customer data OR are likely to affect confidentiality or integrity of federal customer data; if true, the incident is a federal reportable incident.

ICP-CSO-EFI Estimate Federal Impact

Providers MUST evaluate federal reportable incidents to estimate adverse impact of the incident on government customers AND assign one of the following potential adverse impact ratings:

• N1: The incident is expected to have a negligible adverse effect on one or more agencies that use the cloud service offering.

• N2: The incident is expected to have a limited adverse effect on one or more agencies that use the cloud service offering.

• N3: The incident is expected to have a serious adverse effect on one agency that uses the cloud service offering.

• N4: The incident is expected to have a catastrophic adverse effect on one agency that uses the cloud service offering OR a serious adverse effect on more than one federal agency that uses the cloud service offering.

• N5: The incident is expected to have a catastrophic adverse effect on more than one agency that uses the cloud service offering.

  Note: FedRAMP has specific definitions for cloud service providers to follow to determine adverse effects based on the impact to the cloud service provider rather than the typical NIST definitions that require estimating the impact to government organizations.

ICP-CSO-AAP All Affected Parties

Providers MUST responsibly notify all affected parties after identifying federal reportable incidents by proactively sending an email, push notification, or submitting a form as specified in FedRAMP rules or as specified in agreements with specific agency customers; default requirements unless otherwise agreed to in writing are as follows:

1. Notify FedRAMP via email to fedramp_security@gsa.gov or fedramp_security@fedramp.gov
2. Follow specified instructions and contact arrangements provided by the security contact of each agency customer.
3. Upload notification information to the cloud service offering’s secure portal (typically USDA Connect) or FedRAMP-compatible Trust Center.

ICP-CSO-CSA Notify Cybersecurity and Infrastructure Security Agency

Providers MUST responsibly notify the Cybersecurity and Infrastructure Security Agency (CISA) if an incident affects confidentiality or integrity of federal customer data, following CISA’s Submitting Incident Notifications instructions on CISA’s Federal Incident Notification Guidelines web page.

ICP-CSO-IIR Initial Incident Report

Providers MUST responsibly notify all affected parties after identifying federal reportable incidents, including information available for least the following items in the Initial Incident Report:

1. Contact information for the federal incident response coordinator
2. Provider's internally assigned tracking identifier
3. Description of the incident
4. Timeline of the incident, including start time, time and source of detection, time of completed federal reportable incident evaluation, and other major incident milestones determined by the provider
5. Historically and currently estimated potential adverse impact of the incident, including an explanation of the evaluation following the requirements in ICP-CSO-EFI
6. Functional impact to federal agency customers (include impact to confidentiality and/or integrity and the impacted federal customer data types)
7. Estimated recovery plan, milestones, and timelines

Note: Provide as much of the information components listed above as possible in the Initial Incident Report within the required ICP-CSO-IRT Incident Report Timeframes, but prioritize prompt notification with potentially incomplete information above delayed reporting with complete information. Additional information can be included in subsequent Ongoing Incident Reports.

ICP-CSO-IIR Ongoing Incident Reports

Providers MUST responsibly notify all affected parties of ongoing activity as new information becomes available during incident response for federal reportable incidents, including updates (or lack of updates) to all previously reported information and the following additional information if available:

1. Attack Vector identified from CISA’s Attack Vectors Taxonomy
2. Observed incident activity
3. Indicators of compromise
4. CERT identifier
5. Related CVE (if applicable)
6. Root cause
7. Response and recovery activities

ICP-CSO-FIR Final Incident Report

Providers MUST responsibly notify all affected parties once the incident has been resolved and recovery is complete, including final updates to all previously reported information.

ICP-CSO-IRT Incident Report Timeframes

Providers MUST notify all affected parties, based on the PAIN and certification type, within the following timeframes:

Class D (High)

Potential Adverse Impact	Initial Incident Report	Ongoing Incident Reports	Final Incident Report
N5	Within 15min of evaluation	Every 3 hours	Within 3 hours of recovery
N4	Within 30min of evaluation	Every 6 hours	Within 6 hours of recovery
N3	Within 1hr of evaluation	Every 6 hours	Within 6 hours of recovery
N2	Within 1hr of evaluation	Every 6 hours	Within 6 hours of recovery
N1	Within 1hr of evaluation	Every 24 hours	Within 24 hours of recovery

Class C (Moderate)

Potential Adverse Impact	Initial Incident Report	Ongoing Incident Reports	Final Incident Report
N5	Within 1hr of evaluation	Every 6 hours	Within 6 hours of recovery
N4	Within 1hr of evaluation	Every 6 hours	Within 6 hours of recovery
N3	Within 6hrs of evaluation	Every 24 hours	Within 1 business day of recovery
N2	Within 24hrs of evaluation	Every 24 hours	Within 1 business day of recovery
N1	Within 1 business day of evaluation	Every business day	Within 1 business day of recovery

Class B (Low), Class A (Pilot)

Potential Adverse Impact	Initial Incident Report	Ongoing Incident Reports	Final Incident Report
N5	Within 6hrs of evaluation	Every business day	Within 3 business days of recovery
N4	Within 6hrs of evaluation	Every business day	Within 3 business days of recovery
N3	Within 12hrs of evaluation	Every business day	Within 3 business days of recovery
N2	Within 1 business day of evaluation	Every business day	Within 3 business days of recovery
N1	Within 1 business day of evaluation	Every business day	Within 3 business days of recovery

Note: Speed is a security factor. Where possible, provide Ongoing Incident Reports as soon as updates are available.

Collaborative Continuous Monitoring

The following updates will be made to the Collaborative Continuous Monitoring rules to align with the updated Incident Communications Procedures.

CCM-OAR-AVL Report Availability

The following required high-level summary item will be added to Ongoing Authorization Reports:

6. Federal reportable incidents or an attestation that no such incidents occurred
7. Lessons learned and changes planned or made as a result of federal reportable incidents

Vulnerability Detection and Response

The Vulnerability Detection and Response rules will be updated to change references from “security incidents” to “federal reportable incidents” to ensure consistency and alignment to the updated Incident Communications Procedures.

[RobertWright-GEN]

Genesys appreciates the opportunity to comment on RFC-0031. The shift from blanket incident reporting to a risk-tiered model based on federal customer impact is a meaningful improvement, and the separation of availability reporting into public status pages is well-aligned with how commercial cloud services already operate. We offer three recommendations to strengthen the final rule.

1. Establish a Crosswalk Between Commercial Severity Frameworks and PAIN Ratings

Relevant Requirements: ICP-CSO-EFR (Evaluation for Federal Reportability), PAIN rating definitions (N1–N5)

The PAIN rating system introduces a new severity taxonomy that CSPs must apply under time pressure during active incidents. Most mature CSPs already operate with established severity frameworks — PagerDuty's P1–P5, ServiceNow's 1–4, or internally defined severity scales — that drive automated escalation, on-call routing, and executive notification. These frameworks are deeply embedded in operational tooling and muscle memory.

During an active incident, requiring responders to mentally translate between their operational severity model and a separate PAIN taxonomy introduces cognitive overhead at exactly the moment when speed and clarity matter most. The risk is not that CSPs can't learn the PAIN scale — it's that dual-tracking two severity models during a live incident increases the chance of misclassification or delayed reporting.

Recommendation: FedRAMP should publish guidance — or invite CSPs to submit as part of their incident response documentation — a validated crosswalk between their existing commercial severity framework and the PAIN rating scale. For example, a CSP using PagerDuty might document:

PagerDuty Severity | PAIN Rating | Rationale -- | -- | -- P1 (Critical) | N4 or N5 | Full service disruption or confirmed data breach affecting multiple agencies P2 (High) | N3 or N4 | Significant degradation or confirmed compromise of federal customer data P3 (Medium) | N2 | Limited impact, contained to single service component P4 (Low) | N1 | Negligible impact, no federal customer data affected

This crosswalk would be documented in the CSP's incident response plan, reviewed during annual assessment, and applied operationally so that when a P1 fires in PagerDuty, the team already knows the corresponding PAIN range and reporting timeline without a separate evaluation step.

This approach preserves FedRAMP's ability to define the PAIN taxonomy while allowing CSPs to operationalize it within their existing workflows. It also gives assessors a concrete artifact to evaluate — "show me your severity-to-PAIN crosswalk" — rather than relying on after-the-fact justification of individual PAIN assignments.

2. Clarify Format Intent for IIR, OIR, and FIR — and Address Machine-Readable Gap

Relevant Requirements: ICP-CSO-IIR (Initial Incident Report), ICP-CSO-OIR (Ongoing Incident Reports), ICP-CSO-FIR (Final Incident Report), ICP-CSO-PAR (Public Availability Reporting)

We read the IIR, OIR, and FIR requirements as specifying required data elements rather than prescribing a delivery format. We'd like to confirm that interpretation is correct, because the distinction has significant operational and automation implications.

At Class C, the IIR window for an N4/N5 incident is one hour from evaluation completion. The required IIR fields — contact information, tracking identifier, incident description, timeline, PAIN rating, functional impact, recovery plan — map directly to fields that already exist in standard commercial incident management platforms (PagerDuty, ServiceNow, CrowdStrike Falcon, and similar). If the RFC's intent is format-agnostic, CSPs can build automated pipelines that assemble these fields from their existing tooling into a structured report — JSON, PDF, templated email, or notification portal — without manual template population during an active incident. This is consistent with the excellent guidance in ICP-CSO-IIR that CSPs should "prioritize prompt notification with potentially incomplete information above delayed reporting with complete information."

Without explicit confirmation, the risk is that 3PAOs or individual agencies interpret the silence as requiring a specific template or format, leading to inconsistent assessment outcomes and CSPs maintaining manual reporting workflows alongside their automated ones — exactly the kind of dual-track burden that FedRAMP's modernization efforts are working to eliminate.

Separately, we note an asymmetry in the RFC's format requirements. ICP-CSO-PAR explicitly requires machine-readable format for public availability reporting — which is the right call and aligns with FedRAMP's direction under CR26 toward machine-readable, tooling-generated outputs. However, the RFC is silent on whether IIR, OIR, and FIR content will eventually require a machine-readable schema as well. Given that CR26 is retiring DOCX/XLSX formats, requiring semi-structured text for Class C authorization data by November 2027, and broadly pushing toward machine-readable deliverables, it seems likely that incident reports will follow the same trajectory.

Recommendation: We ask FedRAMP to address two questions in the final rule:

1. Confirm format-agnostic intent for IIR/OIR/FIR. Explicitly state that CSPs may satisfy content requirements using any delivery format — including structured output from commercial incident management platforms — provided all required data elements are present.

2. Signal the machine-readable roadmap for incident reports. Is the omission of a machine-readable requirement for IIR/OIR/FIR intentional for this release, with the expectation that it will be addressed in a future update? Or is FedRAMP's position that incident reports should remain human-readable only? If machine-readable incident reports are on the roadmap, publishing a target schema — even as a SHOULD — would allow CSPs to build automation against a stable target now rather than retrofitting later. This is especially relevant for CSPs that are already investing in automated report generation pipelines to meet the aggressive Class C reporting timelines.

3. Clarify When the Reporting Clock Starts — Define "Evaluation Completion"

Relevant Requirements: ICP-CSO-EFR, ICP-CSO-IIR, reporting timeframe definitions

The reporting timeframes are anchored to "evaluation completion" — the point at which a CSP determines an incident is federally reportable and assigns a PAIN rating. This is the right anchor point, but the RFC does not define what constitutes completion of the evaluation step, and this ambiguity creates risk for both CSPs and FedRAMP.

Consider a realistic scenario: a CrowdStrike detection fires at 2:00 AM, the on-call engineer begins triage at 2:15 AM, and by 2:45 AM they've confirmed malicious activity but haven't yet determined whether federal customer data is in scope. At 3:30 AM, forensic analysis confirms federal data was accessed. When did "evaluation" complete — at 2:45 when the incident was confirmed, or at 3:30 when federal reportability was determined?

The distinction matters because for an N4/N5 at Class C, the IIR is due within one hour of evaluation completion. If the clock starts at 2:45, the IIR is due by 3:45. If it starts at 3:30, the IIR is due by 4:30. That 45-minute difference is significant during an active incident.

Without a clear definition, CSPs face a perverse incentive to delay documenting their evaluation to preserve reporting runway — exactly the opposite of what the policy intends. Conversely, an overly strict interpretation could penalize CSPs who move quickly through triage but need additional time to scope federal impact.

Recommendation: Define "evaluation completion" as the point at which the CSP has sufficient information to make a reasonable determination of (a) federal reportability and (b) initial PAIN rating. Explicitly state that the evaluation period encompasses the time from initial detection through federal impact scoping, and that the clock starts when the CSP can reasonably assign a PAIN rating — not when the incident is first detected or when triage begins.

Additionally, consider requiring CSPs to document their evaluation timeline as part of the IIR (detection time, triage start, federal impact determination, PAIN assignment). This gives FedRAMP and agencies visibility into the evaluation process without creating a rigid definition that doesn't account for the variability of real-world incidents.

[nicole-gov]

The following public comment was received via email from Wiz on April 23:

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment.

---

RFC-0031: Updated Incident Communications Procedures

As a FedRAMP High Authorized CSP and a leader in Cloud Native Application Protection Platforms (CNAPP), Wiz is committed to advancing the security posture of the federal government through modernized, risk-based security operations. Wiz strongly supports FedRAMP’s objective to shift incident reporting away from administrative overhead and toward meaningful security outcomes. Below is our feedback on the proposed updates:

1. Support for Focus on Confidentiality and Integrity

Wiz applauds the proposed shift to focus formal incident reporting on "likely or confirmed incidents that threaten confidentiality or integrity of federal customer data."

• Rationale: In modern cloud environments, high-volume telemetry can create noise that obscures actual risk. By narrowing the scope to data-centric impact, FedRAMP allows CSPs to focus their expert resources on investigating genuine threats rather than reporting minor availability fluctuations that do not jeopardize federal data.
• Alignment: This aligns with a Risk-First philosophy, which prioritizes remediation based on the Toxic Combinations of vulnerabilities, identities, and data sensitivity.

2. Modernizing Reporting through Automation (ICP-CSO-EFI)

The RFC introduces the requirement for CSPs to "promptly evaluate" incidents to determine if they are federal reportable incidents.

• Feedback: Wiz suggests that FedRAMP explicitly encourages the use of automated detection and response tools to satisfy this requirement. Manual log reconstruction is often too slow to meet the prompt threshold.
• Using runtime sensors and graph-based security context that shows both internet reachability and toxic-combinations of risk across varying factors (identity, data, vulnerabilities, misconfigurations, etc.), CSPs can automatically correlate an alert (e.g., a reverse shell) with the specific data assets at risk. As such, we recommend that the final guidance acknowledge that automated Incident Narratives backed by blast-radius mappings are preferred methods for establishing the timeline and impact required in FRD-IIR (Initial Incident Reports).

3. Public Status Services for Availability

The proposal to move availability reporting for Class C (Moderate) and Class D (High) providers to publicly accessible status pages is a positive step toward transparency and operational efficiency.

Recommendation: While Wiz supports this, we suggest FedRAMP clarify the "historical availability" requirement. Specifically, ensuring that status pages provide enough granularity to satisfy agency SLAs without creating a secondary reporting burden that contradicts the RFC’s goal of simplification.

4. Enhancing Ongoing Authorization Reports (OAR)

The inclusion of incident summaries and "lessons learned" in OARs is a critical improvement for continuous monitoring.

• Feedback: Wiz supports this integration. We recommend that FedRAMP provide a standardized template for these summaries to ensure that lessons learned from one CSP can be anonymized and shared as Threat Intel across the federal community, thereby strengthening the collective defense.

Conclusion

For agencies and CSPs looking to meet the new RFC-0031 requirements, modern tools are essential to bridge the gap between detection and reporting.

• Context-Aware Detection: Unlike traditional logs, mapping how a vulnerability connects to toxic combinations of risk (e.g., a privileged identity, sensitive data, etc.) makes the Federal Impact Evaluation (ICP-CSO-EFI) near-instant and should be recommended as a best practice.
• Automated Narratives: FedRAMP should recommend automated captures of process-level activity to generate a chronological narrative, satisfying the timeline requirements for FRD-IIR and FRD-OIR without manual log-diving.
• Public Transparency: By automating continuous monitoring, CSPs can maintain the high levels of uptime and transparency required for the new public status page mandates.

Wiz believes that RFC-0031 represents a significant step forward in maturing FedRAMP’s operational requirements. By embracing automation and data-centric risk management, the PMO is enabling CSPs to move from "compliance-by-checklist" to "security-by-design."

We look forward to the finalized Consolidated Rules for 2026 and remain a dedicated partner in securing the federal cloud.

[Quzara]

Quzara LLC — Public Comment on RFC-0031
Updated Incident Communications Procedures
Submitted by: Quzara LLC
Date: May 2026
GitHub Discussion: #138

Quzara LLC operates Cybertorch™, a FedRAMP High Authorized Managed Detection and Response (MDR) and SOC-as-a-Service platform built on Azure Government. We provide 24/7 security monitoring, incident detection, triage, and response for federal agencies, Defense Industrial Base contractors, and cloud service providers maintaining FedRAMP authorizations. We support this RFC's goals and the shift to a tiered reporting model.
These comments are grounded in our operational experience running a Class D (High) SOC and managing the full incident lifecycle — from detection through recovery — on behalf of federal customers.

Comment 1: The reporting clock has no defined starting point
Rules: ICP-CSO-EFR, ICP-CSO-EFI, ICP-CSO-IRT
Problem: The reporting timelines begin after "evaluation," but the RFC does not define when evaluation is complete. In a SOC environment, an incident passes through multiple measurable phases before anyone can determine federal reportability or assign a PAIN rating:

MTTD (Mean Time to Detect) — elapsed time from incident occurrence to detection by monitoring systems
MTTA (Mean Time to Acknowledge) — elapsed time from alert firing to analyst acknowledgment
MTTI (Mean Time to Investigate/Triage) — elapsed time from acknowledgment to initial classification, which is where reportability and impact rating determination actually happen

The reporting timelines sit downstream of all three phases but don't acknowledge any of them. Without a defined trigger, the boundary between "still triaging" and "evaluation complete" is subjective. This creates an unintentional incentive to delay formal classification to extend the reporting window — the opposite of what this RFC intends.
Recommendation: Define the reporting trigger as completion of initial triage — the point at which the incident response team has sufficient information to make a preliminary reportability determination and assign an initial impact rating. Clarify that this determination need not be definitive and that impact ratings may be revised in subsequent reports as the investigation matures.

Comment 2: Managed security providers are invisible in the notification chain
Rules: ICP-CSO-EFR, ICP-CSO-AAP, ICP-CSO-IIR, ICP-CSO-IRT
Problem: The RFC assumes incident communications are a direct provider-to-FedRAMP/agency relationship. In practice, many FedRAMP-authorized providers rely on FedRAMP-authorized managed security providers for detection, triage, and escalation. The MDR provider is often the first entity to detect an incident, complete triage, and determine reportability — sometimes before the provider itself is aware.
This creates a timing problem. The coordination handoff from MDR provider to the CSP — alert, escalate, brief, confirm — introduces latency that could consume a significant portion of a 15- or 30-minute Class D reporting window. The RFC doesn't account for this handoff.
Recommendation: Acknowledge that providers may designate a FedRAMP-authorized managed security provider as a reporting agent for notification and reporting purposes. The provider retains compliance responsibility, but the MDR provider may initiate notifications and submit initial and ongoing reports on the provider's behalf under a documented arrangement. This reflects existing operational practice and directly supports faster reporting.

Comment 3: Multi-tenant notification doesn't scale within Class D timelines
Rule: ICP-CSO-AAP
Problem: A Class D provider serving 20+ federal agency customers cannot realistically notify each agency individually — using potentially different channels and contact arrangements — within 15 minutes (N5) or 30 minutes (N4) while simultaneously conducting containment and response. The notification logistics alone (composing per-agency communications, following each agency's specified contact procedures, confirming receipt) can exceed the reporting window.
Recommendation: Allow centralized notification mechanisms as compliant alternatives: a secure broadcast to a pre-established distribution list, an authenticated machine-readable incident notification feed that agencies subscribe to, or a structured push through the provider's Trust Center. Agencies requiring non-standard channels could document those in their customer agreements. This scales operationally while preserving agency-specific flexibility — and is consistent with the machine-readable status page approach already established for availability reporting.

Comment 4: Ongoing reporting cadence competes with active response
Rules: ICP-CSO-IRT, ICP-CSO-OIR
Problem: At Class D N5, ongoing reports are required every 3 hours. During active containment and forensics, the team managing the incident is simultaneously expected to produce structured narrative reports on a fixed cadence. Every report cycle diverts analyst attention from containment and recovery — the work that actually reduces federal customer risk.
The RFC already states that providers should prioritize prompt notification with potentially incomplete information above delayed reporting. That principle should apply to ongoing reporting as well.
Recommendation: Allow structured machine-readable status updates (via API endpoint, Trust Center feed, or standardized JSON/OSCAL schema) to satisfy ongoing report requirements. Reserve human-authored narrative content for initial and final reports, where completeness and context are most valuable. This keeps agencies informed in near-real-time without pulling responders off the actual response.

Comment 5: "Responsibly" needs sharper guidance at Class D
Rules: FRD-RSP, ICP-CSO-IIR
Problem: The definition of "responsibly" is intentionally flexible, which works at Class B/C. At Class D — supporting DoD and high-impact federal workloads — the 15-minute N5 reporting window creates tension with responsible disclosure. Within 15 minutes of completing triage, the response team may have confirmed an active compromise but not yet identified the full attack vector or completed containment. Sharing indicators of compromise at that stage could alert the adversary or expose technical details before the environment is secured.
Recommendation: Add Class D-specific guidance clarifying that initial reports at N4/N5 should prioritize the fact of the incident, the impact rating, functional impact to federal customers, and contact information. Detailed indicators of compromise, attack vectors, and root cause analysis may be appropriately deferred to ongoing or final reports once the response team determines that disclosure will not compromise active containment.

Comment 6: CISA notification requirements will create duplicative reporting
Rule: ICP-CSO-CSA
Problem: The RFC requires FedRAMP notification plus separate CISA notification. Many providers already report to CISA under existing authorities. When CIRCIA reporting requirements take effect, there will be three or more overlapping notification obligations with different timelines, formats, and thresholds — all triggered by the same incident.
Recommendation: Clarify that a single CISA notification satisfies the RFC's CISA reporting requirement regardless of which authority triggers it. FedRAMP should coordinate with CISA on a shared reporting format or intake mechanism so that one submission satisfies both requirements.

Comment 7: The most aggressive Class D timelines should be validated before enforcement
Rule: ICP-CSO-IRT
Problem: The Class D N5 initial report window is 15 minutes. Even for a mature 24/7 SOC, when you account for the full detection-to-notification chain — detection, analyst acknowledgment, triage, report composition, delivery — 15 minutes from completed triage to delivered report is extremely tight. Industry benchmarks for mean time to detect alone frequently exceed 15 minutes for sophisticated attacks. The combined chain, even at a well-staffed SOC, is realistically measured in hours, not minutes.
FedRAMP's own Phase 2 lessons learned demonstrated that pilot-based validation produces better outcomes than untested mandates.
Recommendation: Implement Class D N5 and N4 initial report timelines in two phases. Phase 1 (January 1, 2027): set both at 1 hour — already more demanding than today's uniform standard because the new timelines are scoped to confidentiality/integrity incidents only, eliminating noise. Phase 2 (July 1, 2027): tighten to the proposed 15- and 30-minute targets after reviewing 6 months of reporting data. This validates feasibility before enforcement, consistent with FedRAMP's broader iterative approach to modernization.

Comment 8: SOC performance metrics should be part of Ongoing Authorization Reports
Rule: CCM-OAR-AVL
Problem: The RFC introduces reporting timelines but provides no framework for measuring or improving the operational capabilities that determine whether those timelines can be met. A provider can file reports on time while running a SOC with poor detection and triage performance. The timelines only measure the last mile of a much longer chain.
The updates in this RFC add incident summaries and lessons learned to Ongoing Authorization Reports, which is a step forward. But they don't capture the operational health of the provider's detection and response capability.
Recommendation: Require or strongly encourage Class C and Class D providers to include SOC performance metrics in their Ongoing Authorization Reports:

MTTD (Mean Time to Detect) — measures detection capability
MTTA (Mean Time to Acknowledge) — measures SOC staffing and responsiveness
MTTI (Mean Time to Investigate) — measures triage efficiency and directly determines how quickly the reporting clock starts
MTTC (Mean Time to Contain) — measures active response capability
MTTR (Mean Time to Recover) — measures recovery speed and directly determines when the final report deadline begins
MTTN (Mean Time to Notify) — measures notification execution against the timelines in this RFC

Trending these metrics over time gives FedRAMP and agency customers visibility into the provider's actual operational posture — not just whether they filed reports on time, but whether the entire detection-to-response pipeline is improving. This turns incident communications from a reactive compliance exercise into a measurable continuous improvement program, consistent with the Phase 2 finding that trending validation data promotes confidence in a provider's security program.

We appreciate FedRAMP's commitment to transparent rulemaking and the opportunity to contribute operationally grounded feedback.

[wisecryptic]

in addition to comment 2, there are multiple other scenarios where a system outside of FedRAMP statutory scope (T2 system) may affect a system within statutory scope (T1 system). the owners of the T2 would report directly to the T1. The T1 would then need to investigate and report potential impact. Additionally, the T2 system, may have contractual obligations to report to the T1 system only/first, and the T1 will handle wider reporting and coordination with affected federal parties. Naturally, this document is targeting those T1s within statutory scope, but these scenarios demonstrate multiple examples of an incident response handling chain that begins before that T1 commences its own incident handling procedure.

[vedigaurav]

From UberEther Inc.

1. Gap: Lack of standardized communication templates
   Issue: Inconsistent reporting formats may continue despite procedural updates.
   Recommendation: Publish mandatory templates for initial reports, updates, containment status, and closure reports.

2. Gap: No prescribed telemetry standards
   Issue: CSPs may provide inconsistent forensic artifacts and logs.
   Recommendations: Standardize required telemetry formats, log retention, and evidence-sharing procedures.

3. Gap: Subjective severity determination
   Issue: The proposed PAIN model may still produce inconsistent scoring between organizations.
   Recommendation: Develop standardized scoring examples and calibration exercises.

4. Gap: Insufficient guidance for “suspected” incidents
   Issue: CSPs may hesitate to report until confirmation, increasing reporting delays.
   Recommendation: Define explicit thresholds for “suspected,” “confirmed,” and “material” incidents.

5. Gap: No industry benchmark alignment
   Issue: Severity methodology differs from common enterprise frameworks like CVSS or MITRE ATT&CK impact models and may differ across different services/tools.
   Recommendations: Provide mappings between PAIN, CVSS, MITRE ATT&CK, and NIST incident categories and common security/reporting services.

[wisecryptic]

The creation of these standards likely avoided 1,2,3 and 4 purposely so that the process could be better served by 5.

[CSP-AB]

The Cloud Service Providers - Advisory Board (CSP-AB) submits the following comments for RFC-0031:

Overall

• We appreciate FedRAMP's commitment to transparency and timely incident communication. To ensure these guidelines achieve their intended goals effectively, we encourage FedRAMP to clarify the primary objectives driving the proposed requirements. If the goal is transparency, we suggest considering whether the proposed response and update timelines are necessary to achieve that end. Additionally, we would welcome clarification on whether FedRAMP or agencies are expected to take specific actions upon receiving incident notifications, as that context would help CSPs tailor their reporting accordingly.

• We also note that CISA notification is already required under existing frameworks. To avoid duplicative reporting burden and unnecessary noise for both FedRAMP and agency customers, we recommend aligning these requirements with existing CISA notification processes rather than establishing a parallel regime. A more streamlined approach would better serve the goal of protecting federal data and information systems.

FRD-INT Incident

• We recommend retaining the existing scope of the incident definition, which focuses on incidents affecting federal customer data. This scoping reflects FedRAMP's core mission of protecting federal information on cloud services. We would welcome additional explanation of the rationale for broadening the definition to ensure the change is well-understood and well-supported before implementation.

ICP-CSO-PAR Public Availability Reporting

• We request that FedRAMP reconsider the blanket public reporting mandate for Class C and Class D providers and explore whether greater flexibility might better serve the program's goals. Class C and Class D service offerings support enterprise-wide and mission-critical agency operations, and the detailed, service-specific availability data most valuable to those agencies may be more sensitive in nature and better suited to direct, access-controlled reporting channels.

• We suggest FedRAMP consider a tiered model in which Class A and Class B CSPs satisfy the public reporting requirement as proposed, while Class C and Class D CSPs may meet the obligation through documented, agency-specific mechanisms — such as authenticated Trust Centers — that can provide richer, more operationally relevant information. This approach would align with the broader ADS framework's distinction between publicly accessible metadata and access-controlled authorization data.

ICP-CSO-EFI Estimate Federal Impact

• We recommend replacing the term "federal reportable incident" with "FedRAMP reportable incident" to more precisely reflect the scope of mandatory FedRAMP reporting, which does not encompass all federal information reporting obligations. This change would improve clarity and reduce the risk of confusion with other reporting frameworks.
• We appreciate the importance of impact evaluation as part of the incident response process and recognize the intent behind the N1–N5 rating system. To reduce the time burden on CSPs during active incidents and improve reporting consistency, we suggest FedRAMP consider simplifying the impact descriptions. For example, N4 could be defined as a catastrophic effect on one or more agencies, and N3 as a serious adverse effect on one or more agencies, with N1 and N2 remaining as currently proposed. A more streamlined rating scale would likely improve both reporting speed and accuracy during high-pressure incidents.
• We encourage FedRAMP to consider how the N1–N5 severity rating system interacts with the Shared Responsibility Model. Because CSPs generally do not have visibility into individual agency configurations and workloads, accurately assessing adverse impact on specific agency missions in real time is operationally challenging. We are concerned this may lead to inconsistent severity assignments and could create unintended incentives in reporting.
  FedRAMP should consider of one of two alternative approaches: (1) a uniform reporting structure that does not require CSPs to estimate agency-level impact, or (2) redefining severity based on CSP-observable indicators — such as scope of data affected, number of accounts impacted, or type of data exposed. If an impact-based model is retained, we suggest that agencies themselves advise on adverse impact experienced from notifiable events, supported by a clear, operationalizable definition of "adverse impact on agency customers" that CSPs can consistently apply.
• Finally, the requirement for CSPs to perform intensive operational impact evaluations—specifically N1–N5 ratings—is at odds with the shared responsibility framework because CSPs generally lack the necessary visibility into agency-specific configurations and deployments, they cannot observe how services are utilized within localized environments.Additionally, the existing criteria for "negligible," "limited," "serious," and "catastrophic" impacts are impractical for CSPs, as these benchmarks rely on mission-specific variables that providers are unable to verify. We recommend FedRAMP transfer the duty of conducting comprehensive mission-specific impact evaluations to the individual agencies so CSPs can prioritize the delivery of objective technical metrics, such as the volume of impacted agencies.

ICP-CSO-CSA Notify Cybersecurity and Infrastructure Security Agency

• Where CSPs are already required to notify FedRAMP, we encourage FedRAMP to explore whether a shared portal or automated notification mechanism could simultaneously satisfy the CISA notification requirement upon submission. Such an approach could meaningfully reduce the reporting burden on CSPs while ensuring CISA receives timely, consistent information. We believe this type of coordination would serve both efficiency and security goals.

ICP-CSO-IIR Initial Incident Report

• We recommend FedRAMP formalize a two-phase reporting structure for initial and ongoing incident reports. A minimum required data set for the initial notification — such as a tracking ID, incident description, and estimated severity — would allow CSPs to meet the one-hour window while acknowledging that complete information is rarely available at that stage. Remaining data elements could then be required in the first Ongoing Incident Report. We appreciate that the current proposal notes that incomplete information is acceptable, and we encourage FedRAMP to codify this principle explicitly rather than leaving it as an informal allowance, as this would provide CSPs with greater clarity and confidence in their reporting obligations.
• We respectfully suggest that FedRAMP revisit the designation of all initial report fields as MUST requirements. Several fields are unlikely to be meaningfully completed or accurate within one hour of incident detection. Specifically:

1. Incident timeline — a complete and useful timeline cannot be constructed within 1 hour of detection
2. Historical impact data — by definition, this cannot be included in an initial report
3. Estimated recovery time — this is highly speculative during an active incident and will almost always be inaccurate at the 1-hour mark.

Requiring these fields at the initial report stage may result in submissions that are necessarily incomplete or speculative, which could undermine the intent of the reporting framework.

• We recommend a tiered obligation structure across the incident lifecycle:

1. Initial Report (1 hour): MUST include only the minimum fields reliably available at detection — incident coordinator contact, provider tracking ID, brief incident description, and estimated start date if known.
2. Ongoing Reports: SHOULD include updates to remaining fields as the investigation matures.
3. Final Report: MUST include all required fields in full.

This structure would produce higher-quality, more reliable information at each stage and better reflect the realities of active incident response.

ICP-CSO-IRT Incident Report Timeframes

• We encourage FedRAMP to consider aligning its reporting timeframes with existing frameworks, including CIRCIA's 72-hour initial report requirement. Harmonizing with established regimes would reduce confusion and reporting burden for CSPs operating across multiple compliance frameworks.
• We also suggest that ongoing reports be structured to require updates only when there is material new information to share, or when the FedRAMP PMO identifies a specific need for additional reporting. Mandatory periodic updates during an active incident can divert resources from containment and remediation — the activities most critical to limiting harm to federal systems.
• We recognize that certain high-severity incidents may warrant faster notification, and we are open to discussing a tiered approach; however, a 15-minute initial report for N5 incidents may not be operationally feasible given the activities required in the immediate aftermath of a major incident. During a catastrophic multi-agency incident, the first hours are consumed by detection confirmation, initial triage, and response team activation. Producing a structured report with 7+ data elements within this window diverts critical resources from incident containment.
• We recommend that initial incident reporting timelines be aligned with CIRCIA, DOD, and other established frameworks, which generally provide 72 hours for initial notification. If FedRAMP believes a shorter timeframe is warranted for certain incident types, we encourage FedRAMP to coordinate with CISA, DOD, the Office of the National Cyber Director, and OMB to establish a unified standard. A harmonized reporting timeline across frameworks would reduce burden on CSPs and improve the consistency of incident data received by the government.
• We recommend standardizing ongoing incident report timelines to 24 hours across all certification classes and severity levels, with a single follow-up report required and additional reporting triggered only at the FedRAMP PMO's discretion based on demonstrated need. Reporting obligations during an active incident should be calibrated carefully — the primary focus of response teams during this period should remain on understanding and remediating the incident. Reporting should be limited and justified while the incident is ongoing unless a clear need for such information can be demonstrated by the FedRAMP PMO.

[pete-gov]

FedRAMP should consider of one of two alternative approaches: (1) a uniform reporting structure that does not require CSPs to estimate agency-level impact, or (2) redefining severity based on CSP-observable indicators — such as scope of data affected, number of accounts impacted, or type of data exposed.

For the general awareness of the public, all of these terms have definitions that are linked in this RFC that include CSP-observable indicators. There is even a relevant note in ICP-CSO-EFI Estimate Federal Impact that reminds people of this.

FedRAMP Definitions are a critical resource in understanding FedRAMP's use of terminology and must not be ignored. The Definitions are part of the rules.

[JJensen-Proofpoint]

Proofpoint, Inc. – Public Comment on RFC-0031
Updated Incident Communications Procedures
Submitted by: Proofpoint, Inc.
Date: May 12, 2026

Proofpoint, Inc. (“Proofpoint”) welcomes the opportunity to provide comments on FedRAMP’s RFC-0031 Updated Incident Communications Procedures (“ICP”).

Founded in 2002, Proofpoint is a leading cybersecurity and compliance company specializing in email security, business email compromise (“BEC”) prevention, identity-centric threat defense, and data protection. We have been spearheading cybersecurity and compliance efforts for a quarter of a century. Operating as a cloud-based software-as-a-service (“SaaS”) provider, we deliver solutions that are used globally across a broad range of industry sectors, including by multinational enterprises, regulated entities, and public-sector organizations. Our products and services are built on the recognition that people—not infrastructure—are the primary targets of modern cyberattacks. Our solutions focus on detecting, blocking, and remediating threats that exploit trust, identity, and digital communications, particularly across email and cloud collaboration environments. In addition to advanced BEC and phishing protection, we provide identity threat defense, data loss prevention, cloud application security, and compliance and archiving tools that support regulated organizations globally.

As a FedRAMP Moderate Authorized Cloud Service Provider (“CSP”) advancing toward FedRAMP High and Impact Level 4 (“IL4”), Proofpoint is committed to strengthening human-centric security across federal agencies and the defense industrial base (“DIB”). We strongly support the objectives that RFC-0031 aims to achieve and agree with its foundational premise: that federal agencies need timely, meaningful visibility into incidents that may affect the confidentiality or integrity of their data, and that CSPs should invest meaningfully in cybersecurity and incident response. These goals align with Proofpoint’s mission and with the daily work of cybersecurity professionals across the ecosystem (please see Defending the gates: How a global coalition disrupted Tycoon 2FA, a major driver of initial access and large-scale online impersonation for a recent example of Proofpoint’s work in collaboration with other leading cybersecurity and compliance companies). However, as drafted, certain implementation requirements set forth in RFC-0031 risk undermining—rather than advancing—those shared objectives. There are four areas in particular that we address in this response: (1) how the definition of “incident” is overbroad and may sweep in routine security events that do not present meaningful federal risk; (2) how the extremely short reporting timeframes are likely to cause a significant distraction and have a counterproductive effect; (3) how the inclusion of “likely” without further definition may recreate the same uncertainty RFC-0031 is trying to solve; and (4) how the public availability reporting requirement creates adversary intelligence risk for cybersecurity providers. We would be grateful for FedRAMP’s close attention to our comments, so that RFC-0031 is well positioned to advance its goal of improving federal incident communications while preserving effective incident response.

I. The Definition of “Incident” is Overbroad

RFC-0031 takes a sensible step forward by narrowing federal incident reporting requirements to focus on what FedRAMP identifies as “meaningful incidents that an agency customer would not otherwise be aware of.” The proposed framework, however, risks falling short of that objective because the definition of “incident” remains overbroad. RFC-0031 adopts the definition of “incident” from 44 U.S.C. § 3552(b)(2), which includes “an occurrence that actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system,” as well as an occurrence that “constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” In addition, RFC-0031 would remove the prior limitation that tied the term “incident” to federal customer data. As a result, the threshold term “incident” may capture activity that does not ultimately present a meaningful risk to federal customer data, contrary to RFC-0031’s stated objective of focusing reporting on meaningful incidents that warrant agency awareness.

The practical effect of that language is especially broad because the second prong of the definition is not limited to actual or likely compromise of information or systems. Instead, it extends to any occurrence that “constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” Security policies, security procedures, and acceptable-use policies are often written broadly and prophylactically. They may govern internal workflows, user behavior, customer conduct, access-control processes, configuration requirements, escalation procedures, software-use restrictions, and other operational matters. A deviation from one of those requirements may be important for internal compliance or risk management—but treating those matters as “incidents” would expand federal incident reporting beyond meaningful confidentiality or integrity risks and into ordinary operational compliance management.

For example, a customer’s violation of an acceptable-use policy, an employee’s failure to follow an internal escalation procedure, a blocked attempt to access a restricted resource, a misconfiguration identified through monitoring, or a software-use restriction violation may all be treated internally as policy or procedure issues. But standing alone, those events do not necessarily indicate unauthorized access to federal customer data, compromise of a federal information system, or any confidentiality or integrity impact requiring agency notification.

That result would recreate the same practical problem RFC-0031 is attempting to solve. FedRAMP explains that the existing incident-communication framework has been broad, unclear, and inconsistently followed or enforced. A definition that captures too much activity at the threshold stage may preserve that uncertainty by forcing providers to decide, often on incomplete information, whether ordinary security events, policy deviations, or contained activity must be processed as potential federal incidents. Providers may respond defensively by over-escalating low-risk events to avoid second-guessing, while others may apply different internal thresholds for filtering out immaterial activity. Either outcome would undermine FedRAMP’s goal of establishing a more useful and consistent reporting regime focused on meaningful incidents.

The practical burden is not merely administrative. Overbroad incident definitions can dilute the value of incident communications for agency customers by increasing the volume of notices or preliminary communications that do not reflect actual or likely harm to federal customer data. They can also divert provider resources from investigation, containment, eradication, and remediation toward threshold reporting analyses for matters that do not present meaningful federal risk. In that respect, an overbroad predicate definition may make incident reporting less actionable for agencies and less effective for providers, contrary to RFC-0031’s stated objective.

NIST’s incident-response guidance offers a practical way to address this concern by distinguishing ordinary observable security activity from cybersecurity incidents that warrant further incident-response treatment. NIST SP 800-61 Rev. 3 defines an “event” broadly as “any observable occurrence” involving computing assets, including physical and virtual platforms, networks, services, and cloud environments (see NIST SP 800-61r3 (April 2025) at 2). NIST recognizes that many events may have security implications, but it does not treat every such event as an incident. Instead, NIST explains that additional analysis is often needed to determine whether adverse cybersecurity events indicate that a cybersecurity incident has occurred. That distinction is important here because it reflects the practical reality that providers must first identify, assess, and filter large volumes of security-relevant activity before determining whether an event presents a meaningful security impact. Without a similar threshold distinction, an overbroad incident definition risks compressing that process and treating routine, unsuccessful, contained, or immaterial activity as an “incident” before there is a reasonable basis to conclude that federal customer data has been affected.

To be clear, this concern does not diminish the importance of timely and meaningful incident reporting. Agency customers require prompt visibility into incidents that may affect the confidentiality or integrity of federal customer data, particularly where the provider is best positioned to identify activity that the agency would not otherwise detect. RFC-0031 appropriately seeks to improve that visibility and make incident communications more useful, consistent, and actionable. Our concern, however, is that an overbroad threshold definition could undermine these goals by sweeping in routine or immaterial activity that does not present meaningful risk to federal customer data. A more clearly defined and bounded definition would better serve FedRAMP’s objective by preserving timely reporting for significant incidents while reducing noise, uncertainty, and unnecessary diversion of incident-response resources.

Proposed Solutions

First, we urge FedRAMP to add an explicit “event” definition in the FedRAMP Definitions or in commentary to RFC-0031, drawing on NIST SP 800-61, which defines an “event” as “any observable occurrence” involving computing assets and notes that “additional analysis is often needed” to determine whether an adverse event constitutes an incident. This distinction is well-established in industry practice and would provide a defensible framework for classifying activity that does not rise to the level of an “incident” requiring evaluation.

Second, we urge FedRAMP to include illustrative examples of activities that do not constitute incidents to help providers, agencies, and assessors apply the incident definition consistently. These examples should clarify that the following types of activities do not, standing alone, constitute incidents:

• Unsuccessful or blocked malicious activity, including vulnerability scans, reconnaissance, probing, failed login attempts, brute-force or credential-stuffing attempts, and phishing attempts, where there is no evidence of compromise, credential theft, unauthorized access, or impact to federal customer data;

• Security detections resolved without impact, including automated alerts later determined to be false positives and malware detections quarantined before execution or before access to federal customer data;

• Policy, procedure, or acceptable-use issues without federal impact, including customer acceptable-use violations and internal policy or procedure deviations that do not result in, and are not reasonably likely to result in, unauthorized access to, disclosure of, modification of, loss of, or impairment of federal customer data or the FedRAMP-authorized service;

• Configuration or operational issues remediated before exposure, including misconfigurations identified and corrected before federal customer data is exposed or the FedRAMP-authorized service is affected; and

• Other blocked, contained, or unsuccessful activity with no evidence of actual or likely compromise or impact to federal customer data.

II. The Extremely Short Reporting Timeframes Risk Doing More Harm Than Good

RFC-0031 provides that providers “MUST promptly evaluate incidents to determine if they affect confidentiality or integrity of federal customer data OR are likely to affect confidentiality or integrity of federal customer data; if true, the incident is a federal reportable incident.” It then imposes extremely short reporting timeframes for those federal reportable incidents. For Class D providers, RFC-0031 would require initial reports within 15 minutes for N5 incidents, 30 minutes for N4 incidents, and one hour for N1 through N3 incidents. For Class C providers, it would require initial reports within one hour for N4 and N5 incidents, six hours for N3 incidents, 24 hours for N2 incidents, and one business day for N1 incidents. RFC-0031 would also require recurring updates as frequently as every three hours for Class D N5 incidents and every six hours for Class D N2 through N4 incidents and Class C N4 and N5 incidents.

The ICP-CSO-IRT Incident Report Timeframes tie those deadlines to “evaluation,” but the table does not expressly define the term. Read in context, “evaluation” appears to mean the completed evaluation that an incident is a federal reportable incident. That reading is consistent with RFC-0031’s Initial Incident Report requirements, which list the “time of completed federal reportable incident evaluation” as one item in the incident timeline. Even so, the timing table should make that point clear.

Notwithstanding that clarification, the proposed reporting windows are too short. In tabletop exercises and real incidents, confirmation and scoping can take days, not minutes, even for well-resourced providers. In the first hours of a suspected event, a provider must determine the full scope of affected systems, customer-specific impact, data types implicated, or mitigation steps before they have enough information to determine whether an incident is federally reportable. That reality makes minute-based initial reporting windows especially difficult to reconcile with the goal of useful, accurate incident communications.

Those deadlines may force providers to choose between reporting quickly and responding effectively. At the point of federal reportability, providers may still be validating affected systems, preserving evidence, assessing containment options, coordinating with third-party vendors, determining whether other customers are affected, and evaluating what information can be shared responsibly.

The burden is compounded because the reporting deadlines require providers to run multiple parallel workstreams at once. While technical teams are investigating, containing, and preserving evidence, other personnel must prepare customer notifications, coordinate legal and communications review, and determine what information can be shared responsibly. For cybersecurity providers serving large enterprise customer bases, that diversion is especially consequential: delays in containment, remediation, or restoration can create downstream exposure for customers that rely on the provider’s services for protection, detection, access control, monitoring, or response. As a result, minute- and hour-based deadlines can pull the same personnel and information needed to fix the issue into expedited reporting and communication workstreams, increasing the risk of broader customer impact while the incident is still unfolding.

The recurring update requirements raise similar concerns. Fixed updates every three to six hours may be useful when material new information is available, but they may also produce low-value reports that repeat prior information or state that the investigation remains ongoing. Preparing and clearing those updates may consume the same resources needed to investigate the root cause, contain the incident, preserve evidence, and restore secure operations.

Deadlines measured in minutes may not improve agency awareness if they produce rushed, incomplete, or rapidly changing reports while diverting resources from containment and investigation. In the earliest stages of a real incident, what matters most is rapid investigation, containment, and remediation. Reporting deadlines measured in minutes can divert scarce expert resources at precisely the moment those resources are most urgently needed, forcing providers into an impossible choice between mitigating harm and meeting reporting mechanics. A reporting framework should preserve rapid notification for high-impact incidents, but the timing requirements should be realistic enough to support accurate scoping, meaningful content, and effective incident response.

Proposed Solutions

First, we encourage FedRAMP to clarify that “evaluation” in the ICP-CSO-IRT Incident Report Timeframes means the time of confirming that a federal reportable incident will impact FedRAMP customers.

Second, we recommend that FedRAMP replace the 15- and 30-minute initial reporting windows with more realistic deadlines. For example, FedRAMP could require Class D providers to submit initial reports within one hour for N5 incidents, four hours for N4 incidents, eight hours for N3 incidents, and one business day for N1 and N2 incidents, measured from the completed federal reportable incident evaluation. This would preserve rapid reporting for the most severe incidents while allowing providers enough time to validate basic facts, identify affected systems, and prepare information that is accurate and useful.

Third, we urge FedRAMP to consider separating preliminary notice from the initial incident report for the highest-severity incidents. For example, FedRAMP could require a short preliminary notice when a provider has completed the federal reportability evaluation for an N5 or N4 incident, followed by a fuller initial report after the provider has completed basic validation and scoping. That approach would preserve rapid agency awareness while reducing the risk of inaccurate or incomplete substantive reports.

Fourth, we recommend that FedRAMP tie recurring updates to material developments rather than rigid three- or six-hour intervals. Providers should update agencies when there is a material change in scope, affected systems, federal customer data impact, containment status, recovery timeline, mitigation steps, or recommended agency action. If FedRAMP retains fixed update intervals, those intervals should operate as deadlines for active incidents where material information is available, not as a requirement to submit repetitive updates that simply state that the investigation remains ongoing. Requiring strict reporting intervals when there is nothing substantive to report shifts resources away from investigation and mitigation and to unnecessary administrative work.

Finally, we ask that FedRAMP expressly allow providers to identify unknown information as “under investigation” in early reports and supplement or correct that information as facts develop. That clarification would encourage timely, good-faith reporting without penalizing providers for not having complete information in the earliest stages of response.

III. The Inclusion of “Likely” Incidents Recreates an Issue that RFC-0031 Is Trying to Solve

RFC-0031 appropriately moves away from the current requirement to report “suspected” incidents. That change is important because a suspicion-based standard can require providers to notify agencies before they have sufficient information to determine whether an incident occurred, whether federal customer data was affected, or whether the notice would provide meaningful or actionable information. Replacing “suspected” with a more concrete standard should help reduce premature reporting and focus agency communications on incidents that present a meaningful risk to federal customer data.

The proposed “likely or confirmed” standard represents a step forward, but the term “likely” risks reintroducing similar uncertainty if it is not further defined. In the early stages of incident response, providers often have incomplete, and sometimes conflicting, information. A provider may detect suspicious activity without yet knowing whether it was successful, whether federal customer data was implicated, whether confidentiality or integrity was threatened, or whether the event will ultimately be confirmed as an incident at all. In that setting, an undefined “likely” standard may be difficult to distinguish from a “suspected” incident standard in practice.

As a result, RFC-0031 may inadvertently recreate the same defensive overreporting it seeks to reduce. Faced with compressed reporting timelines and uncertainty about what “likely” requires, providers may feel compelled to report early-stage investigations whenever federal impact cannot yet be ruled out. Such reports may be incomplete, rapidly changing, and less useful to agency customers. At the same time, differing interpretations of “likely” across providers may lead to inconsistent implementation across the FedRAMP ecosystem.

The concern is not that providers should wait for final confirmation before notifying agencies. There will be circumstances where available facts show a sufficiently concrete likelihood of federal impact even before an investigation is complete. The concern is that, without a clear threshold, “likely” may function as a proxy for “suspected” and preserve the same uncertainty and overreporting incentive that RFC-0031 is intending to correct.

Proposed Solution

We urge FedRAMP to define “likely” or provide interpretive guidance explaining the level of factual support required before an incident becomes federally reportable on that basis. At a minimum, we encourage FedRAMP to clarify that “likely” requires more than a suspicion, theoretical possibility, or unresolved question about federal impact. The standard should require a reasonable factual basis to conclude that the incident affects, or is likely to affect, the confidentiality or integrity of federal customer data.

Alternatively, we encourage FedRAMP to clarify that providers may conduct reasonable preliminary analysis before determining that an incident is “likely” to affect federal customer data. A provider should not be required to treat an incident as federally reportable merely because federal impact has not yet been ruled out. Instead, the obligation should attach when available facts indicate a concrete likelihood of federal impact, even if the provider has not yet confirmed every detail.

IV. The Public Availability Reporting Requirement Creates Adversary Intelligence Risk

RFC-0031 would require Class C and Class D providers to “maintain a publicly accessible status service” that “indicates the current and historical availability of core services within the CSO over the past 30 days, at a minimum,” including “information about any availability incidents.” The RFC does not appear to define what “information about any availability incidents” must be included. The RFC further provides that the status service must be available “in both human-readable form and machine-readable form.” Class A and Class B providers are “encouraged” to maintain a similar public status service. RFC-0031 explains that this requirement is intended to move availability-related reporting into public status pages or similar mechanisms, rather than requiring federal-specific incident reporting for availability impacts.

That approach may reduce federal-specific reporting burden, but it also creates adversary intelligence risk. A public availability service does not merely tell customers whether a service is operational. Depending on the level of detail, it may also reveal which core services are affected, when disruptions began, how long they lasted, how frequently particular services experience degradation, and how quickly the provider restores service. Over time, that information can create a public record of operational patterns, dependencies, and recovery limitations. For ordinary customer communications, that information may be useful. But in the federal cloud context, a public, standardized availability-reporting requirement may give adversaries a reliable source of information about when cloud services supporting agency workloads are degraded, unstable, or in recovery.

The machine-readable requirement heightens that concern. A human-readable status page can inform customers about service availability, but a machine-readable feed may allow adversaries to automate monitoring across multiple FedRAMP-authorized providers, correlate disruptions across services, and identify moments when providers or agency customers may be under operational stress. An attacker could use that information to launch phishing campaigns, credential attacks, exploitation attempts, or social-engineering efforts during periods of service degradation or recovery, when help desks, administrators, and users may be more likely to take unusual action or bypass ordinary caution.

Our concern is consistent with RFC-0031’s own instruction that providers notify affected parties “responsibly.” RFC-0031 defines “responsibly” to caution providers against broadcasting details that might assist adversaries, disclosing vulnerabilities before full remediation, or providing overly specific technical information that could facilitate further compromise. The public availability-reporting requirement should be calibrated to that same principle. A public status mechanism that is too detailed, too easily aggregated, or too closely tied to federal service architecture may conflict with the RFC’s broader instruction to avoid disclosures that assist adversaries.

The concern is not with availability transparency as such. Agency customers need timely information about service outages and degradation, and public status pages can be useful customer-communications tools. The issue is that the proposed requirement may require public disclosure of operational information in a format and level of detail that creates avoidable adversary intelligence risk. Availability reporting should give customers enough information to understand service impact and take appropriate action, without creating a public, automated source of operational data that can be used to target providers or federal customers.

Proposed Solutions

First, we encourage FedRAMP to clarify that “information about any availability incidents” refers to high-level availability information necessary for customer awareness, such as whether a core service is operational, degraded, or unavailable, and general timing information. The definition should not be interpreted to require public disclosure of affected components, internal dependencies, causes, exploitation details, mitigation steps, recovery sequencing, unresolved vulnerabilities, or other operational details that could assist adversaries.

Second, we urge FedRAMP to permit—and, where appropriate, to encourage—customer-authenticated status reporting in lieu of public status reporting, particularly for services supporting federal or defense workloads. Customer portals or agency-specific notification channels can provide timely availability information to affected customers without creating a public source of operational intelligence for adversaries.

Finally, we urge FedRAMP to add an express security exception allowing providers to withhold, generalize, delay, or provide through secure customer-specific channels any availability information where public disclosure could assist adversaries, reveal sensitive architecture or dependencies, expose unresolved vulnerabilities, interfere with incident response or remediation, or otherwise increase risk to federal customers.

V. Conclusion

Proofpoint appreciates the opportunity to provide feedback on RFC-0031 and its efforts to modernize and strengthen incident communication procedures. We share the overarching goal of improving the timeliness, clarity, and usefulness of information provided to federal agencies. Proofpoint remains committed to supporting FedRAMP and the broader federal cybersecurity community in advancing these objectives and welcomes continued dialogue to ensure that RFC-0031 results in a balanced, effective, and security-conscious framework that enhances both agency visibility and overall cyber resilience.

[abowers-elastic]

Elastic N.V.

FRD-INT Incident

• It is not clear why the Incident definition has removed "federal customer data". What scenarios is the PMO considering with this removal? What is the intent particularly given the "Affected Parties" definition essentially re-establishes "federal customer data" through the statement that notifications always include "directly impacted federal customer agency"?

ICP-CSO-EFI Estimate Federal Impact

• Why is FedRAMP PMO choosing to deviate from the NIST definitions that form the basis for many CSPs' IR plans and procedures?

ICP-CSO-IIR Ongoing Incident Reports

• How do we get a CERT identifier? Is this issued following the initial notification?

ICP-CSO-IRT Incident Report Timeframes

• The Ongoing Incident Report intervals are overly prescriptive and complex. This reporting requirement will impact CSPs ability to focus on mitigation and recovery.

CCM-OAR-AVL Report Availability

• Are attestations required for each monthly report?

[TM-Microsoft]

Microsoft offers the feedback outlined below:

Summary & Motivation Section

Move reporting on incidents causing an impact to availability into public status pages or other notification mechanisms without requiring federal-specific reporting

Comment:

The proposed requirement for cloud providers to publicly communicate all service events impacting government entities would result in a materially worse customer experience than what FedRAMP customers receive today. Currently, incident communications are typically scoped directly to impacted tenants, which allows customers to quickly determine relevance and take appropriate action.

More than 85% of service events impact fewer than 10 customers across both commercial and government cloud environments. Requiring all events to be communicated publicly would create additional operational burden for FedRAMP tenants, as customers would need to continuously evaluate whether broadly published events are actually applicable to their environment. This reduces clarity and increases noise during incident response situations.

Additionally, publicly communicating all narrowly scoped service events risks creating an inaccurate and potentially misleading perception regarding the reliability of cloud services. Many events are isolated in scope, short in duration, or limited to highly specific configurations or tenants. Presenting these events broadly, without appropriate contextualization, may unintentionally distort customer understanding of overall platform health and resiliency.

There is also potential for unintended impact to non-FedRAMP customers, who may not distinguish between government and commercial cloud environments or understand the architectural and operational differences between them. This can create unnecessary concern and confusion across the broader customer base.

A more effective approach would preserve targeted, tenant-scoped communications while ensuring government customers continue to receive timely, actionable, and transparent information relevant to their specific impact scenario.

FRD-RSP Responsibly

In a way that shows that you have good judgment and the ability to act correctly and make decisions on your own.

Recommended language update:

Execution of processes should ensure the application of need-to-know principles, restricting incident information to authorized entities to mitigate the risk of misuse.

FRD-AAP All Affected Parties

All federal entities whose interests are affected directly or are likely to be affected directly in the event of a vulnerability or incident related to federal customer data. This always includes FedRAMP and the directly impacted federal customer agency.

Recommended language update:

All federal entities whose interests are directly affected, or where the likelihood of impact is high, in the event of a vulnerability or incident related to federal customer data.

ICP-CSO-PAR Public Availability Reporting

Class C (Moderate) and Class D (High) providers MUST maintain a publicly accessible status service that indicates the current and historical availability of core services within their cloud service offering over at least the past 30 days, including information about any availability incidents, in both human-readable and machine-readable formats; information on how to access and use this service must be available to all necessary parties in the authorization data for the cloud service offering.

Recommended language update:

Class C (Moderate) and Class D (High) providers MUST maintain a status service that:

• indicates the current and historical availability of core services within their cloud service offering over at least the past 30 days

including:

• information about any availability incidents, in both human-readable and machine-readable formats
• excluding active incidents (where all affected parties are already notified and the incident may require additional need to know containment)
• information on how to access and use this service must be available to all necessary parties in the authorization data for the cloud service offering. 

ICP-CSO-EFI Estimate Federal Impact

Note: FedRAMP has specific definitions for cloud service providers to follow to determine adverse effects based on the impact to the cloud service provider rather than the typical NIST definitions that require estimating the impact to government organizations.

Comment:

FedRAMP should clarify or remove this note, as it shifts the focus of impact to the CSP itself, which does not align with the definitions.

ICP-CSO-IRT Incident Report Timeframes 

Class D (High) Table

Comment:

1. The initial notification requirement of less than 1hr will be a challenge, especially given the level of detail expected as part of this updated control. Granted, this is only required at impact N4 or N5, but given that N4 would include "direct or indirect unauthorized access, disclosure, or modification of a minority of Federal data stored within the cloud service offering" as compared to N3 being limited to cases where the data impacted is "a small amount...[for] only a few relevant users" would mean a significant number of our privacy events could be considered "N4". These notification timelines surpass what is required by US-CERT commitments and would advise that requiring "less than 1 hour" notification will likely result in performative, but incomplete notifications from CSPs.

2. The ongoing incident report timelines is a concern. These exceed the US-CERT requirements, and currently the expectation far exceeds what seems reasonable for CSPs to staff and support. While the highest priority incidents will get 24/7 action, we don't expect impacts at the N4 or less level will be resourced in a way that allows every 6-hour updates, or even every 24 hour updates. If this is enforced, it will likely result in performative, perhaps even automated notifications.

Overall, for both 1 and 2: we would suggest that the N1-N5 impact framework consider three potential areas of impact:

• Impact due to service outage or service instability.
• Impact due to a security incident (malicious actor or security vulnerability)
• Impact to confidentiality/integrity/availability due to failure of a CSP's internal controls. (Only applies where there is no evidence of the first two impacts.)

Comment: "Final Incident Report" column - We recommend updating the table to clearly distinguish between:

• a resolution (“all clear”) notification sent upon mitigation, and
• a post-incident after-action report that includes analysis and prevention recommendations, which may require a longer timeline than currently specified.

[acloudcj]

FedRAMP explicitly asks for input on alignment with commercial incident response workflows, so this comment focuses there, with additional observations on scope, harmonization, and operational mechanics.
What we support up front.
Two design choices in this RFC are clearly right and worth affirming.
First, the Initial Incident Report, Ongoing Incident Report, and Final Incident Report structure mirrors how mature incident response programs already document an incident’s lifecycle. Standardizing the touchpoints across CSPs gives FedRAMP and agencies a consistent surface to consume, and it gives CSPs a clear set of moments where they know reporting is expected.
Second, separating availability reporting (public status pages) from confidentiality and integrity reporting (federal channel) is overdue. Customers and agencies have different information needs during availability events versus security events, and conflating them has historically meant CSPs over reported routine availability issues to FedRAMP while under reporting actual security incidents.
Scope of “incident” and the reporting trigger.
The RFC broadens the definition of “incident” in ways that align with current commercial and federal usage. That broader definition should not by itself create a federal reporting obligation. Many events that meet the technical definition of an incident (a security-relevant occurrence, a near miss, a successfully blocked attempt) do not impact federal customer data and should not flow through the federal reporting channel.
The federal reporting trigger should be explicitly tied to actual or likely impact to the confidentiality or integrity of federal customer data. Stating this directly avoids two failure modes: CSPs over reporting events that meet the definition but lack federal impact (which floods the channel and dilutes signal), and CSPs under reporting because they were unsure whether the definition automatically triggered a federal obligation.
Recordkeeping for incidents that are evaluated but not reported.
If the scope clarification above is adopted, CSPs will routinely evaluate incidents that do not meet the federal reporting threshold. The RFC should clarify the recordkeeping expectation for these evaluations: retention period, required data elements, and whether they need to be made available to FedRAMP or 3PAOs on request during continuous monitoring or annual assessment. Without that clarity, CSPs will either over document (out of caution) or under document (out of uncertainty), and assessors will lack a consistent baseline to evaluate against.
The 15 minute clock for Class D catastrophic incidents.
This is the most consequential timing in the RFC, and it needs a reality check against how incident response actually unfolds. The first 15 minutes of a suspected incident are almost always spent determining whether there’s actually an incident. Is this a detection rule false positive? An overloaded component? An adversary action? Responders are pulling together telemetry, paging the right people, and deciding severity. Forcing an IIR submission during this window creates one of two outcomes: either the report goes out with unreliable data that FedRAMP and agencies then act on, or the CSP holds the report (violating the clock) until they have enough signal to say something meaningful.
The better design is to tie the clock to confirmed incident declaration rather than initial detection. Commercial frameworks already distinguish between “page” and “declare,” and the IR playbook typically escalates to incident status once a team lead validates the signal. Fifteen minutes from declaration is operationally feasible; 15 minutes from an alert firing is a bureaucratic artifact that will produce noisy reports.
The RFC should also explicitly define “evaluation” and when the clock starts. If evaluation is the triage step (assessing whether an event is reportable), the IIR clock should start at the conclusion of evaluation, not at the start. The required data elements in the IIR (incident type, affected systems, impact assessment, initial scope) are often not knowable in the first minutes after a page. Either the timeline needs to accommodate that reality, or the required fields in the IIR need to allow “unknown at time of initial report” as a valid value with the expectation that the OIR will fill them in.
Harmonization with existing federal reporting regimes.
This RFC operates in a crowded space. CSPs serving federal customers may already be subject to CIRCIA reporting (for covered cyber incidents and ransomware payments), agency specific incident reporting requirements, sector specific obligations (defense, financial, healthcare), and CISA reporting requirements for federal contractors. Adding a FedRAMP-specific reporting regime without explicit reconciliation creates a real risk that a single incident triggers four or five overlapping reporting obligations with different timeframes, different data elements, and different destinations.
FedRAMP should publish a crosswalk between the RFC-0031 reporting requirements and: - NIST SP 800-61 Rev 3 incident handling guidance - NCISS (National Cyber Incident Scoring System) severity ratings - CISS (Cyber Incident Severity Schema) - CIRCIA reporting obligations - CISA Emergency Directives and Binding Operational Directives reporting
If a CSP files a CIRCIA report that already contains the data elements FedRAMP wants, the RFC should explicitly allow that filing to satisfy the federal reporting obligation (with appropriate routing). Otherwise CSPs are running parallel reporting pipelines for the same incident, which adds burden without adding signal.
Harmonizing timeframes is the harder version of this. CIRCIA gives 72 hours for substantial cyber incidents and 24 hours for ransomware payments. The RFC’s 15 minutes is materially tighter than any other federal reporting regime. If the intent is to give FedRAMP earlier visibility than other channels, state that explicitly and acknowledge the trade off. If the intent is to align with existing regimes, the timing needs to move.
Alignment with commercial incident tooling.
The RFC’s explicit ask is how to align these requirements with what CSPs already produce during commercial incident response. A few concrete suggestions:
Most mature CSPs use PagerDuty, Opsgenie, ServiceNow, or Jira for incident tracking. These systems already capture the data FedRAMP wants (detection time, severity, impact scope, remediation actions, resolution time). If the IIR/OIR/FIR schemas are publishable as JSON or OSCAL structures, CSPs can generate them automatically from existing workflows rather than maintaining a separate FedRAMP reporting pipeline. The alternative, where a responder manually fills out a FedRAMP specific form while simultaneously running the incident, is exactly the kind of burden this RFC says it wants to avoid.
Publishing the standardized data elements as a machine readable schema (with field definitions, enumerations for severity, and examples) would let GRC vendors and CSPs build integrations rather than reinvent the wheel. This is the same argument that applied to RFC-0024 (machine readable packages), and the rationale carries over.
Public availability reporting: scope and access model.
Moving availability incidents to public status pages is directionally correct, but the RFC leaves several practical questions open.
Do existing CSP status dashboards satisfy the public availability reporting requirement? Most mature CSPs already operate Statuspage, Atlassian Statuspage, Better Stack, or custom-built dashboards that publish availability events with incident timelines, affected components, and resolution status. If these existing artifacts satisfy the requirement, that should be stated explicitly so CSPs don’t build duplicate channels. If they do not satisfy the requirement, the RFC should specify what’s missing.
Where must status information be hosted? On the CSP’s primary marketing domain, on a dedicated status subdomain, on a FedRAMP-operated aggregator, or some combination? Each option has different implications for discoverability, branding, and CSP control over messaging. The RFC should pick one or explicitly allow CSPs to choose.
What does “publicly accessible” mean? General public access (anyone with a browser) or authenticated customer access (only entities with an account)? These are very different posture decisions. General public access maximizes transparency but exposes details that could inform adversaries reconnoitering the platform. Authenticated customer access protects sensitive operational detail but reduces transparency and makes the data less useful for federal agencies that don’t have CSP accounts.
The most practical model is customer and vendor provided access: authenticated agency customers see the full status feed, while general public sees a redacted high level version. This balances transparency against the operational reality that detailed status information about a CSP serving federal data is itself sensitive. The RFC should explicitly endorse a tiered access model rather than defaulting to either extreme.
Hybrid availability and security incidents.
The separation between availability reporting and confidentiality/integrity reporting is the right design, but it raises a routing question for hybrid incidents. A DDoS attack is an availability incident and a security event. A ransomware detonation that takes a service offline is availability and confidentiality. The RFC should clarify whether hybrid incidents route through the federal reporting channel, the public status page, or both. Defaulting to “both” is reasonable but should be stated explicitly rather than left to CSP interpretation, with guidance on what level of detail goes through each channel (the public status page need not disclose the same forensic detail as the federal channel).
The “Responsibly” definition.
Defining “Responsibly” as “exercising sound judgment without aiding adversaries” is well intentioned but functionally subjective. Consider the recurring dilemma during active incidents: a CSP detects an IOC (indicator of compromise) that would be valuable to share with peer providers and CISA for broader defense. Sharing publicly could theoretically “aid adversaries” by revealing what’s detected; withholding it could leave peer organizations exposed.
The RFC should either (a) explicitly carve out IOC and threat intelligence sharing with CISA, sector ISACs, and peer FedRAMP CSPs as explicitly not aiding adversaries, or (b) provide concrete examples of what “aiding adversaries” means in practice. Without that, CSP counsel reading this definition will advise restraint, and the community defense value of timely sharing gets suppressed.
N1-N5 severity mapping.
The RFC introduces N1-N5 severity ratings. Most CSPs use P1-P4 (or SEV0-SEV3) severity in their incident tooling, and federal frameworks use NCISS and CISS. A mapping table between N-ratings, common commercial severity schemes, and the federal severity frameworks referenced above would reduce translation errors during high stress reporting moments. If FedRAMP publishes a reference mapping, CSPs can configure their tools once and trust the automation rather than relying on responder judgment during an active incident.
Class A/B vs Class D timeline asymmetry.
The extended timeframes for Class A/B (up to 1 business day) versus 15 minutes for Class D make sense in principle (higher impact systems get tighter scrutiny). The operational concern is that many CSPs offer multiple service tiers that span authorization classes. A provider with both a Class B Low baseline service and a Class D High baseline service running on shared infrastructure needs clear guidance on which clock applies when an underlying infrastructure incident affects both. The default should probably be the tightest applicable clock, but stating that explicitly would avoid reporting delays during multi tier incidents.
One final process observation.
The RFC notes minimal incident reporting despite certification requirements. Before tightening the procedures, it would be useful to understand why current reporting is minimal. Is the bar unclear? Are CSPs assessing incidents as non reportable when they should be reported? Are the existing channels hard to use? Without a diagnosis, a procedural update may not solve the underlying problem. A brief analysis of the root cause (or an invitation for CSPs to share their current incident reporting experience) would inform whether this RFC addresses the real gap or just adds more structure on top of a broken channel.

[Alliancefordigitalinnovation]

The Alliance for Digital Innovation (ADI) appreciates the opportunity to comment on RFC-0031, Updated Incident Communications Procedures. To support FedRAMP’s efforts, we offer the following suggestions and comments:

• Clarify that the broader definition of “incident” does not itself create a federal reporting obligation.
• Federal reporting should be triggered only when an incident affects, or is likely to affect, the confidentiality, integrity, or availability of federal customer data or systems. For availability, reporting should be limited to significant impacts on availability orders of magnitude beyond the service level agreement due to nefarious activity.
• Clarify recordkeeping expectations for incidents evaluated but deemed not reportable, while avoiding overly prescriptive requirements that could create unnecessary compliance burdens.
• Clarify whether existing CSP status dashboards satisfy the public availability reporting requirement.
• Clarify where status information must be hosted.
• Clarify whether “publicly accessible” means general public access or authenticated customer access.
• Recommend customer/vendor-provided access rather than broad public access.
• Clarify “evaluation” and the start of the reporting clock, while preserving flexibility for CSPs to make reasonable business determinations based on the facts available at the time.
• Address the practical problem with the 15-minute reporting window.
• Reconcile the 15-minute initial report with fields that are unlikely to be known that quickly.
• Recommend alignment or crosswalk with NIST, NCISS, CISS, and other federal frameworks.
• Recommend thoughtful alignment of this regime with CIRCIA. Any differences in how the same incident is treated under FedRAMP and CIRCIA should be intentional, justified, and avoid conflicting or duplicative obligations.
• Recommend harmonizing FedRAMP timeframes with existing federal reporting regimes.
• Support the Initial/Ongoing/Final report structure.
• Support separating availability reporting from confidentiality/integrity reporting, which came from your pasted comments.

Thank you for your consideration on this matter.

[nicole-gov]

The following public comment was received via email from Adobe on May 12:

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment.

---

Adobe Inc. Comments
In Response to FedRAMP PMO RFC-0031
Updated Incident Communications Procedures

May 12, 2026

Adobe appreciates the opportunity to provide feedback on RFC-0031, the proposed Updated Incident
Communications Procedures. We commend the FedRAMP Program Management Office (PMO) for its
continued efforts to modernize incident reporting requirements in a way that improves clarity, aligns
with operational realities, and strengthens agency visibility into meaningful cybersecurity risks. We
support the PMO’s objective of transitioning from broad, inconsistently applied requirements to a more
structured, rules-based framework. Below are Adobe’s comments on the proposed updates.

1. Risk-Tiered Reporting Framework

Adobe generally supports RFC-0031’s proposed transition from broadly defined reporting expectations
to a tiered model based on potential adverse impact and system classification. This includes the RFC’s
proposed change from a 1-hour reporting deadline to a 6 to 24-hour deadline for initial incident
reports for Low- and most Moderate-level services.¹ This risk-based approach better aligns with
operational triage and reduces unnecessary reporting burdens for lower-impact events. The flexibility
will help cloud service providers (CSPs) to provide more meaningful initial reports without
compromising responsiveness.

2. Compressed Reporting Timelines for Moderate and High

The compressed proposed timeline for final incident reports for Moderate-level systems, from 72 hours
to a deadline of 6 to 24-hours after recovery, may introduce operational challenges. This is particularly
so where final reports depend on root cause analysis and cross-team coordination.² We suggest
maintaining flexibility regarding when recovery occurs to ensure adequate room to complete incident
response operations.

RFC-0031 also introduces accelerated incident reporting timelines for High-level systems. This includes
initial incident reporting requirements as short as 15 to 60 minutes after evaluation, and final incident
reports within 3 to 6 hours of recovery.³ We understand the intent to align reporting urgency with the
potential impact of incidents affecting High baseline systems, though the proposed timelines may
introduce operational challenges at the earliest stages of incident detection and triage.

3. Public Reporting for Availability Incidents

Adobe supports RFC-0031’s proposal to move reporting of incidents affecting availability to publicly
accessible status pages rather than requiring federal-specific reporting.⁴ This reduces the volume of
redundant reporting obligations and better aligns FedRAMP with established commercial practices. We
agree that focusing federal reporting on incidents affecting confidentiality and integrity will improve
the signal-to-noise ratio for agencies.

4. Incident Definition Update

RFC-0031 expands the definition of “incident” to include any occurrence affecting a cloud service
offering.⁵ However, RFC-0031 maintains that only incidents affecting or likely to affect confidentiality or
integrity of federal customer data are reportable.⁶ Adobe supports the PMO’s effort to standardize
terminology without broadening the set of reportable events beyond current practice.

Thank you for the opportunity to provide feedback. Please do not hesitate to contact us if we can be of
further assistance.

Footnotes

1. ICP-CSO-IRT Incident Report Timeframes, Class B (Low). ICP-CSO-IRT Incident Report Timeframes, Class C
   (Moderate). ↩

2. ICP-CSO-IRT Incident Report Timeframes, Class C (Moderate). ↩

3. ICP-CSO-IRT Incident Report Timeframes, Class D (High). ↩

4. ICP-CSO-PAR Public Availability Reporting. ↩

5. FRD-INT Incident. ↩

6. ICP-CSO-EFC Evaluate Federal Reportability. ↩

[nicole-gov]

The following public comment was received via email from Google on May 12:

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment.

---

The following are our comments on RFC-0031 opened 4/8/2026 and closing 5/12/2026:

1. Incident Report Timeframes (ICP-CSO-IRT)

Concern: The proposed requirement to reduce the initial incident reporting timeframe for N5 incidents from one hour to 15 minutes, with ongoing updates every three hours, presents significant operational challenges without clear security benefits. For large-scale cloud service providers, such tight windows during the critical early stages of a catastrophic event are likely to result in non-substantive notices that prioritize administrative compliance over incident resolution. Furthermore, excessive communication requirements create an administrative burden that can distract technical teams from their primary objective of fixing the underlying issue.

Recommendation: Maintain the existing industry-standard timelines of initial notification within one hour and subsequent updates within 24 hours. This maintains alignment with Department of Defense (DOD) IL5 requirements and existing FedRAMP 20x goals of commercial parity.

2. Estimation of Federal Impact (ICP-CSO-EFI)

Concern: The requirement for Cloud Service Providers (CSPs) to provide detailed operational impact analysis—specifically by assigning adverse effect ratings (N1–N5)—is inconsistent with the shared responsibility model. CSPs generally lack "need to know" access regarding how an agency has internally deployed or configured a service within their own specific environment.

Furthermore, the specific definitions for "negligible," "limited," "serious," and "catastrophic" effects are insufficient for CSP evaluation because they rely on mission-contextual thresholds that a provider cannot verify. For example:

• Mission Subjectivity: Definitions for "serious" and "catastrophic" effects are based on "significant" or "severe" negative impacts to an organization. A CSP cannot accurately judge these impacts without visibility into an agency's unique missions or internal workflows.
• Quantifying Data Impact: Ratings such as N2 (Limited) or N3 (Serious) require the CSP to determine if a "small amount" or a "minority" of federal customer data was affected. By design, hyperscale CSPs do not have access to the content of federal customer data and cannot determine the relative significance or proportion of data impacted from an infrastructure level.
• Arbitrary Outage Thresholds: The definitions use infrastructure metrics, such as outages of 12+ hours or 24+ hours, as proxies for mission impact, However, an infrastructure outage does not automatically translate to a severe mission impact if the agency has implemented resilient architectures that the CSP cannot see.

Recommendation: Shift the responsibility for detailed operational impact reporting to the agencies themselves. CSPs should focus on reporting objective technical facts regarding the CSP’s services impacted and the scale of affected agencies, while agencies perform the mission-specific impact assessments using their own internal context and visibility.

[nicole-gov]

The following public comment was received via email from Salesforce on May 12:

I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment.

---

Requirement_ID	Title/Section	Salesforce Comment
ICP-CSO-PAR	Public Availability Reporting	Concern: "Publicly Accessible" Is Undefined and Creates Ambiguity Around Authentication Requirements The ICP-CSO-PAR requirement mandates that Class C and Class D providers maintain a "publicly accessible" status service, but does not define what "publicly accessible" means in practice. Specifically, it is unclear whether the requirement mandates zero-friction unauthenticated access open to anyone on the internet, or whether a documented credential provisioning process — such as a self-service agency portal or just-in-time access provisioning through a Trust Center — would satisfy the requirement. This ambiguity is operationally significant for Class C and Class D CSPs whose status data may contain sensitive security details appropriate for agency customers but not appropriate for unrestricted public exposure. Without a clear definition, CSPs cannot make informed implementation decisions and risk investing in solutions that may not satisfy the requirement at finalization. Recommendation: FedRAMP should explicitly define "publicly accessible" within the context of ICP-CSO-PAR and clarify whether a documented, self-service credential provisioning process satisfies the requirement. Given that the requirement already notes "considerable flexibility," FedRAMP should confirm that access-controlled status services with streamlined agency provisioning — such as subscription-based notifications or authenticated portals available to all agency customers without unnecessary friction — meet the intent of the requirement. A clear definition will enable CSPs to make confident implementation decisions and reduce inconsistency across the industry. --------------------------------------------------------------------------------- Concern: Class C and Class D CSPs Should Be Permitted to Provide Enhanced Agency-Specific Availability Data Through Controlled Channels Recommendation: FedRAMP should reconsider the blanket public reporting mandate for Class C and Class D providers and instead allow greater flexibility to meet availability reporting obligations through agency-specific, access-controlled channels. Class C and Class D service offerings support enterprise-wide and mission-critical agency operations - the detailed, service-specific availability data most valuable to those agencies is inherently more sensitive and is better served through direct, provisioned reporting channels than through a publicly accessible status page. Rather than mandating public availability reporting for the highest certification classes, FedRAMP should permit Class C and Class D CSPs to satisfy this requirement through documented agency-specific reporting mechanisms - such as authenticated Trust Centers - that provide richer, more relevant information than a generic public status service could offer. A tiered model where public reporting is appropriate for Class A and Class B, and agency-specific controlled reporting satisfies the requirement for Class C and Class D, better reflects the operational reality of enterprise cloud services and aligns with the broader ADS framework's distinction between publicly accessible metadata and access-controlled authorization data.
ICP-CSO-EFI	Estimate Federal Impact	Concern: CSPs Cannot Reliably Assess Agency-Level Adverse Impact Under the Shared Responsibility Model The N1–N5 severity rating system requires CSPs to evaluate and predict the adverse impact of an incident on individual agency customers — information that CSPs do not have visibility into under the Shared Responsibility Model. CSPs cannot observe agency-specific configurations, workloads, or operational dependencies in real time, making it structurally impossible to assign accurate severity ratings based on estimated agency impact during an active incident. This creates two significant risks: CSPs may under-report to avoid triggering escalated reporting requirements they cannot substantiate, or over-report out of caution — neither of which serves the intent of the framework. The complexity of the rating system adds operational burden without meaningfully improving incident outcomes. Concern: The N-Level Impact Descriptions Are Overly Complex and Difficult to Apply Consistently The current N1–N5 descriptions require nuanced impact determinations that are time-consuming and subject to inconsistent interpretation - particularly under the time pressure of an active incident. Evaluating whether an incident has a "serious" versus "catastrophic" effect on one versus multiple agencies introduces unnecessary decision complexity that slows reporting and increases the risk of misclassification. Recommendation: FedRAMP should redefine severity ratings based on CSP-observable indicators rather than estimated agency impact. Observable indicators such as scope of data affected, number of accounts impacted, and type of data exposed are measurable by the CSP in real time and provide a consistent, operationalizable basis for severity classification. If FedRAMP retains an agency impact-based model, agencies themselves should be responsible for advising on the adverse impact they experience from notifiable events, and FedRAMP should provide a clear, consistently applicable definition of "adverse impact on agency customers" that CSPs can apply without agency-specific knowledge.
ICP-CSO-IIR, ICP-CSO-IIR	Initial Incident Report, Ongoing Incident Reports	Concern: Initial Report MUST Requirements Are Not Achievable Within a 1-Hour Window The current proposal designates all initial report fields as MUST requirements, but several of these fields cannot be accurately or meaningfully completed within one hour of incident detection. Specifically: - Incident timeline — a complete and useful timeline cannot be constructed within 1 hour of detection - Historical impact data — by definition, this cannot be included in an initial report - Estimated recovery time — this is highly speculative during an active incident and will almost always be inaccurate at the 1-hour mark Applying a blanket MUST designation to all fields conflates the minimum information FedRAMP actually needs at initial notification with information that only becomes available as the incident matures. The result is that CSPs will submit low-quality, inaccurate initial reports simply to satisfy the requirement — which undermines the intent of the reporting framework. Recommendation: Restructure the reporting obligations using tiered obligation language across the incident lifecycle: - Initial Report (1 hour): MUST include only the minimum fields available at detection — incident coordinator contact, provider tracking ID, brief description, and estimated start date if known - Ongoing Reports: SHOULD include updates to remaining fields as they become available - Final Report: MUST include all required fields in full
ICP-CSO-IRT	Incident Report Timeframes	Concern: Ongoing Reporting Frequency Is Excessive and Detracts From Active Remediation The proposed ongoing reporting cadence of every 3–6 hours is more frequent than most established incident reporting regimes and exceeds even internal executive-level reporting cadences during the most severe incidents. At this frequency, updates will not contain meaningful new information — they will become automated, repetitive placeholders that consume time and attention from the teams actively working to resolve the incident. This is a well-documented problem in incident response: excessive reporting obligations during an active event pull skilled responders away from remediation and toward administrative tasks, ultimately slowing resolution and increasing agency risk. Recommendation: Standardize ongoing reporting to 24 hours across all certification classes and N-levels, consistent with most established reporting regimes. Require only a single mandatory follow-up report, with additional reporting triggered only when the FedRAMP PMO determines it is necessary to protect the security and integrity of affected federal systems. Any requirement for more frequent reporting should be accompanied by a documented PMO justification. This approach ensures agencies receive timely, meaningful updates while keeping incident responders focused on what matters most — understanding and remediating the incident. --------------------------------------------------------------------------------- Concern: "Evaluation" Is Undefined, Creating Ambiguous Reporting Triggers The RFC does not define the term "evaluation," yet it serves as a critical trigger for reporting obligations and timeline requirements. Generally, "evaluation" means something fundamentally different from a confirmed incident - it represents the investigative period during which teams are actively working to determine whether an event rises to the level of a reportable incident. Without a clear definition, CSPs cannot reliably determine when their reporting clock starts, leading to inconsistent compliance postures across the industry. If the reporting clock begins at the start of evaluation rather than at confirmed incident determination, CSPs will be forced to over-report unconfirmed events simply to avoid missing a deadline — adding noise to the reporting system and distracting responders during the most critical investigative window. Recommendation: FedRAMP should provide an explicit definition of "evaluation" in the final rules, clearly distinguishing it from a confirmed incident. FedRAMP should also clarify whether the reporting clock begins at the start of evaluation or upon confirmation that a reportable incident has occurred. Best practice and alignment with other frameworks suggests the clock should start at the point a provider reasonably believes a reportable incident has occurred — not at the moment any anomalous event is first detected.