RFC-0026 Clarifying CA-7 Continuous Monitoring Expectations for Rev5 Providers

[rhoesing]

RFC-0026 Clarifying CA-7 Continuous Monitoring Expectations for Rev5 Providers

❓ 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 and Q&A for RFCs related to Rev5 Updates (RFCs 0026, 0027, 0028, 0029, & 0030) thread. Thank you!

Status: Open
Start Date: March 19, 2026
Closing Date: April 22, 2026

Summary

This RFC outlines FedRAMP Consolidated Rules 2026 clarifications and updates to the CA-7 Continuous Monitoring control for all FedRAMP Rev5 baselines to ensure cloud service providers with multiple agency customers provide sufficient information to support ongoing authorization to all agency customers. These updates are summarized as follows:

• Remove outdated references to the JAB
• Instruct 3PAOs to treat gaps in meeting this requirement as high impact findings
• Document corrective actions
• Provide guidance on the intersection with the Collaborative Continuous Monitoring BIR

Motivation

FedRAMP is not simply a security program - it is a government-wide program established to provide a standardized, reusable approach to security assessment and authorization for cloud services used by agencies. FedRAMP’s primary responsibility is ensuring agencies have the information they need to make ongoing authorization decisions about the cloud services they are already using. Any agency that issued an authorization to operate a cloud service based on the information provided in a FedRAMP authorization package must also have access to ongoing authorization data (including all continuous monitoring and annual assessment artifacts) to support their authorization to operate.

The Additional FedRAMP Requirements and Guidance for CA-7 Continuous Monitoring [add link if possible] in their current form have a confusing reference to the JAB path that was rescinded by OMB Memorandum M-24-15. This guidance currently reads as follows:

“Requirement: CSOs with more than one agency ATO must implement a collaborative Continuous Monitoring (ConMon) approach described in the FedRAMP Guide for Multi-Agency Continuous Monitoring. This requirement applies to CSOs authorized via the Agency path as each agency customer is responsible for performing ConMon oversight. It does not apply to CSOs authorized via the JAB path because the JAB performs ConMon oversight.”

The implementation of a continuous monitoring program that shares necessary information with all agency customers is a critical component for the presumption of adequacy provided by a FedRAMP Certification; if these materials are not available to all agency customers then the cloud service provider is not sharing adequate information for use in an agency authorization and corrective action is required.

FedRAMP acknowledges that these requirements changed unexpectedly and abruptly in July 2024 with the rescission of the previous FedRAMP memorandum and establishment of a new vision for FedRAMP by OMB Memorandum M-24-15; this RFC proposes a structured timeline, clear next steps, and predictable corrective action to ensure that all cloud service providers can continue to meet ongoing FedRAMP Certification requirements without further surprise.

The section below, “CA-7 Additional FedRAMP Requirements and Guidance,” would entirely replace the existing guidance for CA-7.

CA-7 Additional FedRAMP Requirements and Guidance

Guidance: The optional Collaborative Continuous Monitoring Balance Improvement Release for Rev5 includes a detailed blueprint for maintaining a healthy modern continuous monitoring program.

FedRAMP does not provide a template for the Continuous Monitoring Plan. Providers should reference the FedRAMP Collaborative Continuous Monitoring Balance Improvement Release or the Rev5 Continuous Monitoring Playbook when developing the Continuous Monitoring Plan.

Requirement RV5-CA07-VLN (Vulnerability Reporting)

Providers MUST share vulnerability information with all agency customers and FedRAMP using one of the following two processes:

1. Implementing the Vulnerability Detection and Response Balance Improvement Release for Rev5 (either in Beta or Wide Release); or

2. Sharing Operating System, Database, Web Application, Container, and Service Configuration Scans, at least monthly; AND sharing updated Plans of Action and Milestones (POA&Ms), at least monthly; AND sharing all scans performed by an Independent Assessor, at least annually.

NOTES:

• Providers implementing the Vulnerability Detection and Response Balance Improvement Release do not maintain Plans of Action & Milestones.
• Plans of Action and Milestones have a required FedRAMP Template and if you are leveraging the FedRAMP Managed Repository (Connect.gov) there is a required folder for POA&M placement. Ensure you are placing your POA&Ms within the correct folder in their native format and have either POAM or POA&M in the naming convention.

Requirement RV5-CA07-CCM (Collaborative Continuous Monitoring)

Providers MUST provide recurring monitoring information (including meetings) to all agency customers and FedRAMP using one of the following two collaborative continuous monitoring processes:

1. Implement the Collaborative Continuous Monitoring Balance Improvement Release for Rev5 (either in Beta or Wide Release); or

2. Implement the traditional collaborative continuous monitoring approach as described in the FedRAMP Rev5 Continuous Monitoring Playbook or successor materials.

Effective Date for All RV5-CA07 Requirements

These requirements will be effective immediately for gradual adoption when published with the FedRAMP Consolidated Rules for 2026 by the end of June 2026. There will be an initial grace period without any corrective action until December 31, 2026.

Enforcement with corrective action will begin on January 1, 2027.

Failure Measures for All RV5-CA07 Requirements

These failure measures and corrective actions apply only to providers that are NOT following the Collaborative Continuous Monitoring Balance Improvement Release process (because that process has separate failure measures and corrective actions).

Failure measures that will trigger corrective action include:

1. Failure to host a traditional monthly ConMon meeting open to all agency customers (RV5-CA07-CCM) and FedRAMP during any given month.

2. Failure to share the required information (RV5-CA07-VLN), following the required process, with all agency customers and FedRAMP during any given month.

NOTE: Providers implementing the Vulnerability Detection and Response Balance Improvement Release do not maintain Plans of Action & Milestones.

Corrective Actions for All RV5-CV07 Requirements

These requirements will be enforced over a 12-month period that resets after each failure (meaning a provider must go 12 months without failures to clear the corrective actions) as follows:

1. First failure:

   1. FedRAMP will notify the provider and request a Corrective Action Plan.

   2. FedRAMP will notify all agencies.

   3. Providers will be granted a one month grace period for implementation after submitting the initial Corrective Action Plan.

2. Second failure:

   1. FedRAMP will notify the provider and request an updated Corrective Action Plan.

   2. FedRAMP will notify all agencies that the provider has failed 2 times.

3. Third failure:

   1. FedRAMP will notify the provider and request an updated Corrective Action Plan.

   2. FedRAMP will notify all agencies that the provider has failed 3 times.

   3. FedRAMP will move the cloud service offering into the “Remediation” status on the FedRAMP Marketplace and publicly summarize the failures leading to corrective action.

4. Fourth failure:

   1. FedRAMP will notify the provider and request an updated Corrective Action Plan.

   2. FedRAMP will notify all agencies that the provider has failed 4 times and is pending revocation of FedRAMP Certification.

   3. FedRAMP will maintain the cloud service offering in the “Remediation” status on the FedRAMP Marketplace with a public summary of the failures.

5. Fifth failure:

   1. FedRAMP will notify the provider and revoke their FedRAMP Certification.

   2. FedRAMP will notify all agencies that the provider failed 5 times in 12 months and their FedRAMP Certification has been revoked.

   3. The cloud service offering will be removed from the FedRAMP Marketplace for a period of at least 6 months, after which the cloud service offering may undergo a full new assessment for FedRAMP Certification.

[alexmellott]

I am supportive of this proposal. Based on my experience advising programs and now working directly on the CSP side, I have frequently seen collaborative continuous monitoring not implemented as intended. In practice, agencies and CSPs often provide ConMon data only to the original authorizing organization on a recurring basis, rather than engaging in a truly shared process.

One suggestion would be to more clearly reinforce that collaborative ConMon is meant to be collaborative in nature. Too often, I have observed situations where a single agency exerts disproportionate control over the process, imposing agency-specific requirements and directing all ConMon activities for every organization reusing the authorization. This approach can undermine the efficiency and shared responsibility that collaborative ConMon is intended to achieve.

[lewisrcombs78]

Recent updates introduced through RFC-0026 establish new operational requirements for continuous monitoring (ConMon) activities within the FedRAMP ecosystem. While the intent of RFC-0026 appears to strengthen visibility and accountability across agency customers, several provisions may unintentionally diverge from the modernization direction established by federal policy, including OMB Memorandum M-24-15, the FedRAMP Authorization Act, and the NIST Risk Management Framework (RMF).
This report identifies eight structural contradictions between RFC-0026 and existing federal governance and modernization initiatives. The most significant concerns are prescriptive monthly reporting requirements, expanded cross-agency data-sharing mandates, centralized enforcement mechanisms, and manual operational processes that conflict with federal priorities for automation, efficiency, reuse of commercial cloud services, and risk-based decision-making.
These findings do not suggest that RFC-0026 lacks value. Rather, they indicate a potential misalignment between implementation mechanisms and the broader federal modernization strategy. Addressing these inconsistencies will help ensure that continuous monitoring remains scalable, risk-based, and aligned with government-wide cloud adoption and security modernization goals.

---

Background
Federal Cloud Governance Modernization
Federal cloud security governance has undergone significant modernization through recent statutory and policy changes, including:
• FedRAMP Authorization Act
• OMB Memorandum M-24-15
• NIST SP 800-37 Rev. 2 (Risk Management Framework)
• NIST SP 800-53 Rev. 5 (Security Controls)
• NIST OSCAL Automation Initiative
Collectively, these frameworks emphasize:
• Risk-based decision-making
• Automation and machine-readable security data
• Reuse of commercial cloud authorizations
• Reduction of duplicative federal requirements
• Clear governance roles and shared oversight responsibilities
The intent of modernization is to enable scalable cloud adoption while maintaining strong security assurance through continuous monitoring and standardized authorization processes.

---

Scope of Analysis
This report evaluates whether RFC-0026 operational requirements align with:
• OMB M-24-15 modernization direction
• FedRAMP governance structure
• NIST RMF responsibilities
• NIST SP 800-53 Rev. 5 CA-7 control expectations
• Federal cloud reuse and automation objectives

---

Key Findings
Finding 1
Reintroduction of Structural Oversight Distinctions
Observation
RFC-0026 introduces collaborative continuous monitoring processes that effectively recreate operational distinctions between agency-led oversight and centralized governance models.
Examples include:
• Mandated monthly collaboration across agencies
• Default agency oversight of monitoring data
• Required multi-agency coordination processes
Policy Context
OMB M-24-15 explicitly removed legacy distinctions between Joint Authorization Board (JAB) and agency authorization pathways to standardize oversight responsibilities and modernize governance structures.
Risk
This operational differentiation may:
• Reintroduce fragmented oversight models
• Increase administrative complexity
• Reduce the scalability of the authorization framework

---

Finding 2
Prescriptive Monthly Reporting Requirements
Observation
RFC-0026 mandates recurring monthly deliverables, including:
• Monthly vulnerability scanning reports
• Monthly POA&M updates
• Monthly continuous monitoring meetings
• Monthly corrective-action reviews
Policy Context
Federal modernization policy emphasizes:
• Automation
• Efficiency
• Reduced manual reporting burden
• Scalable authorization processes
Risk
Rigid reporting cycles may:
• Increase operational overhead
• Create redundant manual processes
• Limit scalability across multi-agency cloud services

---

Finding 3
Expanded Cross-Agency Artifact Sharing Requirements
Observation
RFC-0026 requires continuous monitoring artifacts to be shared across all agency customers.
Policy Context
Federal cloud governance frameworks emphasize:
• Reusable authorizations
• Need-to-know access principles
• Contractual and mission-based segmentation
Risk
Mandatory universal sharing may:
• Expose sensitive mission information
• Increase legal and contractual complexity
• Expand data distribution risk

---

Finding 4
Centralized Enforcement Mechanisms
Observation
RFC-0026 establishes a structured escalation process that includes:
• Public remediation designations
• Public reporting of failures
• Revocation after repeated non-compliance
Policy Context
Federal governance models emphasize:
• Collaborative oversight
• Shared responsibility across agencies
• Board-level governance structures
Risk
A highly punitive enforcement approach may:
• Reduce collaboration between stakeholders
• Increase operational risk for providers
• Create inconsistent governance practices

---

Finding 5
Conflict with NIST RMF Authorization Authority
Observation
RFC-0026 introduces shared monitoring processes that may override system-specific authorization authority decisions.
Policy Context
NIST RMF establishes that:
• Authorizing Officials retain responsibility for risk acceptance
• Monitoring activities are scoped to system mission and risk tolerance
Risk
Uniform monitoring mandates may:
• Reduce flexibility in risk management
• Undermine mission-specific authorization decisions

---

Finding 6
Fixed Monitoring Cadence Requirements
Observation
RFC-0026 establishes mandatory monthly monitoring activities.
Policy Context
NIST SP 800-53 Rev. 5 CA-7 specifies:
• Continuous monitoring must be risk-based
• Monitoring cadence should be determined by organizational risk tolerance
Risk
Fixed monitoring intervals may:
• Reduce risk-based flexibility
• Increase unnecessary operational workload
• Create compliance-driven rather than risk-driven security practices

---

Finding 7
Divergence from Commercial Cloud Reuse Strategy
Observation
RFC-0026 introduces requirements unique to federal environments, including:
• Federal-specific reporting formats
• Multi-agency coordination processes
• Unique operational workflows
Policy Context
Federal modernization strategy emphasizes:
• Leveraging commercial cloud capabilities
• Reducing government-specific customization
• Enabling reuse of commercial security services
Risk
Unique federal operational requirements may:
• Increase costs
• Reduce interoperability with commercial platforms
• Slow cloud adoption

---

Finding 8
Misalignment with Automation and Machine-Readable Security Initiatives
Observation
RFC-0026 relies heavily on manual reporting and human-driven processes.
Examples include:
• Manual POA&M submissions
• Scheduled meetings for monitoring coordination
• Human-generated reporting outputs
Policy Context
Federal security modernization initiatives emphasize:
• Machine-readable security data
• Automated validation processes
• Standardized security interfaces
Risk
Manual workflows may:
• Reduce efficiency
• Increase human error
• Limit automation adoption

---

Systemic Impact Assessment
Operational Impact
• Increased administrative workload
• Reduced scalability of continuous monitoring
• Higher operational costs

---

Governance Impact
• Potential role confusion between oversight bodies
• Increased complexity in authorization management
• Reduced consistency across agencies

---

Security Impact
• Overemphasis on compliance activities
• Reduced flexibility in risk-based decision-making
• Increased likelihood of reporting fatigue

---

Strategic Risk Summary
The cumulative effect of RFC-0026 requirements may:
• Increase operational burden without proportional security benefit
• Reduce alignment with federal modernization initiatives
• Create friction between agencies and cloud service providers
• Slow adoption of automated security monitoring

---

Recommendations
Policy Alignment
Clarify governance roles and responsibilities to ensure consistency with federal modernization frameworks.

---

Operational Flexibility
Allow monitoring cadence to be determined by risk rather than fixed schedules.

---

Data Governance
Define clear boundaries for cross-agency information sharing based on mission requirements and contractual obligations.

---

Automation Enablement
Prioritize machine-readable security reporting and automated validation processes.

---

Governance Coordination
Ensure enforcement mechanisms align with collaborative oversight models.

---

Conclusion
RFC-0026 introduces valuable structure for continuous monitoring coordination but may inadvertently diverge from the federal government's broader modernization strategy. Aligning implementation requirements with risk-based, automated, and scalable practices will help ensure that continuous monitoring remains effective without introducing unnecessary operational burden.
The opportunity moving forward is not to reduce monitoring rigor, but to ensure that monitoring practices remain adaptable, efficient, and aligned with evolving federal cloud governance principles.

[wisecryptic]

@lewisrcombs78 I'm having a hard time tracking the plot on your comment. Is there a way we could shorten this AI output down to some cause-and-effect or return-on-investment type punchlines? Or is this meant to be broad commentary, not suggestive of any changes to the rfc itself?

[christopherleetingen-stack]

More information understanding procedure is my goal to accomplish.

[lrSpriggs]

I concur with all the components of RFC 0026 with the exception of "Corrective Actions for All RV5-CV07 Requirements". This RFC on its face is providing CSP advanced notice that effective December 31 2026, any CSP that is not actively participating in Collaborative ConMons will be subjected to corrective actions: **Given that CSP have until the December to self-assess and come into compliance, 8 months in my opinion is more than sufficient. ** Suggest the following: If it is determined after the December deadline, they still are not in compliance the CSP should be given One opportunity to explain why they have not engaged in Collaborative ConMons and along with a get-well plan to come into compliance within 45 days. If they do not meet that 45-day window, step 5 under the Corrective Action (Fifth failure: FedRAMP will notify the provider and revoke their FedRAMP Certification.) should be enforced.

Respectfully

[christopherleetingen-stack]

My past ignorance will not over come my future of compliance. Please keep in mind! I may have few questions along the way to learn and accomplish full compliance. Team work is A+ accomplished goal is my rule of life.

[austinsonger]

1. Define “traditional monthly ConMon meeting” more precisely
   • Consider adding minimum expectations: required attendees (all agency customers + FedRAMP), agenda/topics, artifact sharing timing, and what qualifies as “hosted” vs “attempted but no attendees.”
   • This helps CSPs avoid accidental “failures” due to interpretation differences.
2. Clarify scope triggers: “more than one agency ATO”
   • Spell out whether this is triggered by:
     • more than one leveraging agency ATO for the same CSO,
     • any combination of “in-process” + ATO,
     • or only once multiple ATOs are active.
   • Also clarify how this applies to newly multi-agency offerings (e.g., the month the second ATO is granted).
3. Be explicit about what “share with all agency customers and FedRAMP” means operationally
   • If the expectation is “everyone can access artifacts in a common repository,” say so plainly and include:
     • acceptable mechanisms (e.g., repository posting + notification),
     • timing expectations (e.g., within X days of month-end),
     • handling of agency-specific restrictions (need-to-know, export control, etc.).
4. Reinforce “collaborative means collaborative” (good point raised in comments)
   • Recommend adding one or two sentences to prevent a single agency from turning “collaborative ConMon” into agency-unique oversight that defeats reuse.
   • A simple guardrail could be: collaborative ConMon artifacts and cadence should be uniform and reusable across agency customers, with agency-specific deltas handled separately.
5. 3PAO handling as “high impact findings”
   • This is a big change. Consider adding:
     • what evidence 3PAOs should look for (meeting invites/attendance, artifact timestamps, distribution lists, repository logs),
     • whether repeated administrative misses are treated equivalently to missing security-relevant artifacts,
     • whether a “make-up” window exists inside the month.
6. 12-month “resets after each failure” needs an example
   • The reset concept is reasonable, but it’s easy to misunderstand. Add a short example timeline (e.g., failure in Feb resets the clean-period clock, etc.). That will reduce disputes later.
7. Address CSPs not maintaining POA&Ms under the Vulnerability Detection & Response BIR
   • Since the text notes that some providers won’t maintain POA&Ms under that approach, consider explicitly stating what replaces the POA&M signal for agencies (e.g., machine-readable vulnerability status, exception tracking, remediation evidence, etc.), so agencies still have comparable risk visibility.

ALSO: Define a “minimum viable” shared ConMon dataset that supports reuse across agencies without extra customization.

[vedigaurav]

Gap #1: Undefined Expectations for Data Timeliness
Issue: Although monthly sharing is required, the RFC does not clarify acceptable latency for critical updates (e.g., high/critical vulnerabilities discovered mid-cycle).
Recommendation: Establish timeliness SLAs for different severity levels (e.g., critical vulnerabilities shared within 72 hours).

Gap #2: No Clarification on Agency Consumption Responsibility
Issue: The RFC emphasizes CSP obligations but does not address agency-side responsibilities for reviewing and acting on shared data.
Recommendation: Include guidance outlining agency expectations for consumption, review cadence, and response actions to ensure shared data is effectively used.

Gap #3: Missing Scalability Considerations for High-Customer CSPs
Issue: CSPs with a large number of agency customers may face operational strain in hosting and managing monthly collaboration sessions.
Recommendation: Allow scalable alternatives (e.g., tiered briefings, recorded sessions, or asynchronous collaboration models) that still meet transparency requirements.

Gap #4: No Metrics for “Adequate Authorization Data”
Issue: The RFC states that failure to share data equates to inadequate authorization support but does not define measurable criteria for adequacy.
Recommendation: Define quantitative and qualitative metrics (e.g., completeness, accuracy, timeliness) to objectively assess compliance.

Gap #5: Limited Guidance on Handling Sensitive or Restricted Data
Issue: Sharing detailed vulnerability data across multiple agencies may raise security and data sensitivity concerns, especially for exploitable findings.
Recommendation: Provide guidance on data segmentation, redaction, and need-to-know controls while maintaining transparency.

Gap #6: No Transition Guidance for Existing Tooling
Issue: CSPs may already use legacy tooling that does not support expanded sharing requirements, but the RFC lacks transition or migration guidance.
Recommendation: Include a transition framework or reference architecture to help CSPs adapt existing tooling to meet new expectations.

[christopherleetingen-stack]

I have been learning what all has happened to my identity and data. You say I commented! I never commented to my identity and personal data being unlawfully internationally transfered. Keep in mind there is a a double controller accessible to my devices and stealing all my finances, bitcoin i have no privacy to nothing everything is being stolen like the past 13 years of my life. I'm totally commented to helping in all ways but something has to give were the theft of my personal everything will stop.

…

On Thursday, April 2, 2026, Gaurav Vedi ***@***.***> wrote: Gap #1 <#1>: Undefined Expectations for Data Timeliness Issue: Although monthly sharing is required, the RFC does not clarify acceptable latency for critical updates (e.g., high/critical vulnerabilities discovered mid-cycle). Recommendation: Establish timeliness SLAs for different severity levels (e.g., critical vulnerabilities shared within 72 hours). Gap #2 <#2>: No Clarification on Agency Consumption Responsibility Issue: The RFC emphasizes CSP obligations but does not address agency-side responsibilities for reviewing and acting on shared data. Recommendation: Include guidance outlining agency expectations for consumption, review cadence, and response actions to ensure shared data is effectively used. Gap #3 <#3>: Missing Scalability Considerations for High-Customer CSPs Issue: CSPs with a large number of agency customers may face operational strain in hosting and managing monthly collaboration sessions. Recommendation: Allow scalable alternatives (e.g., tiered briefings, recorded sessions, or asynchronous collaboration models) that still meet transparency requirements. Gap #4 <#4>: No Metrics for “Adequate Authorization Data” Issue: The RFC states that failure to share data equates to inadequate authorization support but does not define measurable criteria for adequacy. Recommendation: Define quantitative and qualitative metrics (e.g., completeness, accuracy, timeliness) to objectively assess compliance. Gap #5 <#5>: Limited Guidance on Handling Sensitive or Restricted Data Issue: Sharing detailed vulnerability data across multiple agencies may raise security and data sensitivity concerns, especially for exploitable findings. Recommendation: Provide guidance on data segmentation, redaction, and need-to-know controls while maintaining transparency. Gap #6 <#6>: No Transition Guidance for Existing Tooling Issue: CSPs may already use legacy tooling that does not support expanded sharing requirements, but the RFC lacks transition or migration guidance. Recommendation: Include a transition framework or reference architecture to help CSPs adapt existing tooling to meet new expectations. — Reply to this email directly, view it on GitHub <#130?email_source=notifications&email_token=B5Q6XKD37U6OFVQY2LUWIKD4T2HRXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRUGI2TOMZZUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16425739>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5Q6XKHWBCTGEZGB2CYQWQD4T2HRXAVCNFSM6AAAAACWYFVRX6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBSGU3TGOI> . You are receiving this because you commented.Message ID: ***@***.***>

[rhoesing]

Comment from Raj P.

Please find below my public comments on RFC-0026: Clarifying CA-7 Continuous Monitoring Expectations for Rev5 Providers.

Comment 1 — General / Meeting Standards

Generally Supportive of this RFC. The proposed corrective action ladder is a step towards clarity from the current gray area. However there is one gap I wanted to highlight. The failure metric for RV5-CA07-CCM states Providers shall host a monthly meeting open to all agency customers, but there is no definition of what "hosting a meeting" entails, what baseline content/topics must be covered in the meeting, or how a provider can document that the meeting took place. Without clarity on those 3 aspects it will be difficult for 3PAOs to consistently evaluate and providers have no clear bar to work towards. Would recommend adding minimum expectations for meeting content and how it should be documented before this is finalized.

Comment 2 — Agency Perspective

Supportive of this RFC. The proposed corrective action "framework" definitely moves the ball forward when it comes to holding CSP's accountable. However from an agency perspective there is a gap in that when a CSP reaches each "strike", the onus is solely on them to take action to correct and retry. If an agency receives a "strike three" and logs into the Marketplace to see their provider is now in Remediation, there is no explanation of what that means for them moving forward. Are they expected to reassess their determination, suspend use of AWS.org, or just wait for AWS to meet any required remediation criteria? This RFC does a good job of putting the burden of information sharing on the CSP but leaves agencies in the dark about their own responsibilities. Would recommend that the final rule mention at minimum that agencies have a set of responsibilities they need to meet when they receive failure notifications.

Comment 3 — Provider Perspective

In Support of this RFC and appreciate the increase in transparency the corrective action ladder will provide. Enforcement concern: Due to the 12 month window resetting after each failure, a CSP needs to go 12 consecutive months without any failure to clear their slate. All failure measures will apply to all agency customers at once with no partial points awarded. So if your provider has 30 agency customers and meets the requirement to share ConMon data with 29 of them but fails to due to a technical glitch or admin oversight on 1, you still fail and are treated the same as a provider who didn't share with any agencies. Considering the fact that the motivation of this RFC admits the requirements were changed with little notice in July of 2024, some leeway for partial compliance or a cure period of less than 30 days would better balance the framework risk without losing the strength of enforcing this requirement.

Thank you for the opportunity to comment on this RFC.

[WhalerMike]

Supportive of this RFC. The five-strike corrective action framework is a meaningful step toward accountability, and the distinction between RV5-CA07-VLN and RV5-CA07-CCM correctly separates the data-sharing obligation from the collaborative engagement obligation.

One intersection I haven't seen raised in the comments: BOD 25-01 now requires FCEB agencies to deploy CISA's ScubaGear to assess M365 tenant configuration against SCuBA Secure Configuration Baselines and report results into CyberScope. ScubaGear is a point-in-time assessment tool. This RFC is formalizing the continuous monitoring expectation above that assessment. But there's a practical gap between "ScubaGear scanned clean last Tuesday" and "the tenant is still compliant today" that neither tool nor policy currently fills.

Configuration drift in a multi-admin GCC Moderate tenant can happen hours after a clean scan -- a Conditional Access policy change, a SharePoint external sharing default, a Defender policy override. The monthly ConMon cadence this RFC establishes is the right governance rhythm for collaborative reporting, but it doesn't address what happens to configuration state between those monthly checkpoints.

Building on @austinsonger's point about a "minimum viable shared ConMon dataset" -- I'd argue that dataset needs to include canonical desired-state definitions (what the tenant configuration should look like per the applicable SCuBA baseline) alongside continuous drift detection evidence, not just vulnerability and POA&M status. That gives agencies an ongoing authorization signal they can act on, rather than a monthly snapshot that may already be stale.

We've been working on this exact problem in GCC Moderate environments -- a governance layer that consumes ScubaGear output as the assessment baseline, maintains canonical desired state, runs continuous drift detection, and tracks remediation with owner accountability and SLA timelines. The enforcement teeth this RFC adds will create real demand for that kind of persistent compliance evidence. CSPs and agencies will need more than periodic scans and monthly meetings to stay on the right side of the corrective action ladder -- they'll need machine-trackable proof that configuration state was maintained between touchpoints.