FedRAMP RFC-0008: Continuous Reporting Standard (CLOSED)

[rpalmer-gsa]

RFC-0008 Continuous Reporting Standard

• Status: Closed
• Created By: FedRAMP PMO
• Start Date: 2025-05-09
• Closing Date: 2025-06-09
• Short Name: rfc-0008-continuous-reporting

Where to Comment

• Discussion Thread: https://github.com/FedRAMP/rfcs/discussions/27
• Public Comment Form: https://forms.gle/f5Aiu8chadAAQj8S6
• Email: pete@fedramp.gov with the subject "RFC-0008 Feedback"

FedRAMP Guidance Types

• Standards are base requirements that can be applied in any environment and will change rarely
• Best Practices support standards with methods, techniques, or examples and may change often
• Technical Assistance supports standards with additional technical nuance to support decision making and may change often

Summary

The Continuous Reporting Standard identifies Key Security Metrics that must be monitored by cloud service providers and made available to agencies and FedRAMP to maintain FedRAMP authorization. This standard is based on historical FedRAMP Rev 5 continuous monitoring standards that focused on direct scanning.

This standard also includes guidance on application, including requirements for how frequently Key Security Metrics should be reported. The standard does not propose specific formats or mechanisms for reporting this information at this time to encourage initial innovation by industry, but future updates may align towards best practices on presentation.

No action will be required of any cloud service provider without supporting guidance based on this FedRAMP Standard.

Motivation

To ensure maximum reusability across agencies and encourage private sector innovation, continuous monitoring reporting must follow an objective data-driven approach that makes key security metrics easy for providers to collect and easy for agencies to monitor.

Continuous Reporting should focus on information agencies need to know and will benefit from reviewing. The entire continuous monitoring and reporting process should encourage and empower engineering and security teams at providers to focus on maintaining and improving the security of their systems.

This standard begins a shift away from the government requiring cloud service providers to upload scan logs and create bespoke materials only for federal agencies. Reports following FedRAMP’s Continuous Reporting Standard should mostly reuse information already monitored by provider security teams and can be made available to both commercial and government customers via the same mechanisms.

Explanation

The full draft technical assistance is approximately 5 pages and is available for review in the following formats:

• Basic web formatting on fedramp.gov
• Basic text markdown on GitHub
• PDF file: rfc-0008-continuous-reporting-standard.pdf
• DOCX file: rfc-0008-continuous-reporting-standard.docx

Discussion Requested

This draft standard is open for any public comment. FedRAMP encourages fast, informal comments from any member of the public. The public may submit multiple comments and may respond to other public comments. All comments from the public sent via email will be made public.

The FedRAMP Rev 5 Continuous Monitoring Working Group will simultaneously host discussions on potential best practices and implementation of the Continuous Reporting Standard.

FedRAMP is particularly interested in comments regarding:

• The reporting requirements are intended to be reasonable for both providers and agencies, facilitating innovation and informed risk analysis and acceptance. Do they strike the right balance between security oversight and operational efficiency?
• This standard explicitly encourages that mitigated vulnerabilities be reported and tracked at their estimated risk rating after mitigation rather than their original risk rating. Is this a change in the right direction?
• This approach is intended to give agencies adequate visibility into the overall security posture of a cloud service offering. What additional information might agencies need to maintain their risk awareness?
• Standards will be supported separately by templates, best practices, technical assistance, and other materials. What materials might be prioritized for production to support this standard?

---

RFC-0008 Continuous Reporting Standard

Friday, May 9th, 2025

---

Background

OMB Circular A-130: Managing Information as a Strategic Resource defines continuous monitoring as “maintaining ongoing awareness of information security, vulnerabilities, threats, and incidents to support agency risk management decisions.”

The FedRAMP Authorization Act (44 USC § 3609 (a) (1)) directs the Administrator of the General Services Administration to “... develop, coordinate, and implement a process to support agency review, reuse, and standardization, where appropriate, of security assessments of cloud computing products and services, including, as appropriate, oversight of continuous monitoring of cloud computing products and services…” This responsibility is delegated to the FedRAMP Director.

Introduction

This FedRAMP standard establishes an updated continuous monitoring reporting process for FedRAMP authorized cloud service providers that requires cloud service providers to maintain direct relationships with their customers for reporting purposes and reduce the burden for continuous monitoring by agencies. Agencies must follow OMB policy and NIST standards when adopting FedRAMP authorized cloud services, including maintaining an ongoing awareness of the security posture of services they use. Providers must ensure such information is available directly to agencies and regularly review it with all participating agencies.

To ensure maximum reusability across agencies and encourage private sector innovation, continuous monitoring reporting must follow an objective data-driven approach that makes key security metrics easy for providers to collect and easy for agencies to monitor. Reporting should focus on information agencies need to know and will benefit from reviewing. The entire continuous monitoring and reporting process should encourage and empower engineering and security teams at providers to focus on maintaining and improving the security of their systems.

This updated standard creates a new Continuous Reporting Standard that replaces some parts of previous FedRAMP guidance related to reporting on continuous monitoring activities for all FedRAMP authorizations and certifications, including the current Rev 5 Agency Authorization process and FedRAMP 20x. Best practices and technical assistance to help stakeholders follow this standard will be provided separately.

This standard does not change the continuous monitoring requirements identified in a provider’s security plan; it only changes the reporting requirements. Additional information on how these requirements will change overall and align to emerging standards such as the Significant Change Notification Standard will be provided prior to final formalization of this standard.

No action will be required of any cloud service provider without supporting guidance based on this FedRAMP Standard.

Continuous Reporting

The FedRAMP Continuous Reporting Standard establishes requirements for continuous reporting that cloud service providers MUST follow to maintain FedRAMP authorization.

At least the following Key Security Metrics MUST be included in continuous monitoring reports:

1. Unmitigated Vulnerabilities - A list of unmitigated vulnerabilities or vulnerability groupings, broken down by risk rating, including at least the following information:

   1. Total number of unmitigated items
   2. Common Vulnerabilities and Exposures (CVE) ID, other unique ID if CVE is unavailable, or N/A
   3. Provider’s unique tracking identifier for this occurrence
   4. Component or Services impacted
   5. Original FedRAMP remediation window end date
   6. Known Exploited Vulnerability status
   7. Remediation and/or mitigation plans, including dates

2. Mitigated Vulnerabilities - A list of mitigated vulnerabilities or vulnerability groups, broken down by estimated risk rating after mitigation, including at least the following information:

   1. Total number of mitigated items
   2. Common Vulnerabilities and Exposures (CVE) ID, other unique ID if CVE is unavailable, or N/A
   3. Provider’s unique tracking identifier for this occurrence
   4. Component or Services impacted
   5. Original risk rating prior to mitigation
   6. Explanation of mitigation measures
   7. Date mitigation took effect
   8. Original FedRAMP remediation window end date
   9. Known Exploited Vulnerability status
   10. Remediation plan, including dates

3. Incidents - Information about any incident-related activities in the past reporting period or past 30 days (whichever is longer)

4. Significant Change Notifications - Information about any Significant Change Notifications in the past reporting period or past 30 calendar days (whichever is longer)

5. Upcoming Milestones - Information about any upcoming planned service milestones and third-party assessment activities within the next 60 calendar days that are not included in Significant Change Notifications

6. Overall Scan Coverage - Overall numbers and percentage of distinct component configurations covered by the service’s security scanning activities

7. Detailed Component Scan Coverage - Numbers and percentage of components covered by the services’s security scanning activities grouped by distinct component type and scan type

Application of the Continuous Reporting Standard

1. Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats. These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability.

2. Providers MUST update Key Security Metrics at least monthly.

3. Providers MUST keep Key Security Metrics available to agencies and FedRAMP for 24 months after initial reporting.

4. Providers SHOULD update Key Security Metrics one week before monthly monitoring meetings to ensure information is timely and agencies and FedRAMP have the opportunity to review in advance.

5. Providers SHOULD make Key Security Metrics available within their standard customer portals, protected with appropriate controls to ensure agencies and FedRAMP can make this information available to their information security staff.

6. Providers SHOULD mitigate vulnerability risk as quickly as possible. Providers SHOULD adjust vulnerability severity based on documented mitigation.

7. Providers, third-party assessment organizations, agencies, and FedRAMP SHOULD consider mitigated vulnerabilities at their mitigated risk rating. Providers MAY carry mitigated vulnerabilities beyond FedRAMP remediation windows for the original risk rating without penalty but MUST remediate such vulnerabilities once it is reasonable to do so.

8. Providers SHOULD NOT include validated false positives in security reporting to agencies and FedRAMP. Providers MUST maintain documented evidence for determinations of false positives for the duration of their existence.

9. Providers MAY make Key Security Metrics available to other customers or the public if they determine doing so will not have a likely impact on the confidentiality, integrity, or availability of federal information.

10. Providers MAY provide additional security relevant metrics in their reporting as they deem appropriate for sharing with agencies and FedRAMP.

11. All parties SHOULD follow FedRAMP’s best practices and technical assistance on continuous reporting where applicable.

Exceptions to the Continuous Monitoring Reporting Requirements

Providers MAY be required to provide additional metrics beyond those identified above as a condition of a formal FedRAMP Corrective Action Plan or other agreements with federal agencies.

[rgutwein]

A few considerations:

•	Monthly reporting cadence is appropriate, but consideration should be given to aligning with automated CI/CD pipelines. Allowing for GitOps or DevSecOps integration will reduce manual reporting fatigue and promote engineering-driven security ownership.
•	Human + Machine-readable formats are ideal—standardizing on JSON or OSCAL-based outputs (e.g., via NIST 800-53 Component Definitions or vulnerability POA&M schema) can enable automation pipelines.

Mitigated Risk-Based Vulnerability Reporting

Strongly agree that encouraging mitigated risk-based reporting is a positive direction. This reflects real-world operational risk more accurately than original severity alone. To support this change:

•	Recommend publishing a scoring rubric or example scenarios showing acceptable mitigation techniques (e.g., compensating controls like WAFs, network segmentation, exploit path reduction).
•	Include optional fields in reporting templates to show the rationale for adjusted risk scores (e.g., threat intelligence, vulnerability reachability analysis).

Additional Data for Agency Risk Awareness

Agencies may benefit from supplemental metrics such as:

•	Exploitability trends (e.g., Known Exploited Vulnerabilities per month).
•	Coverage gaps between inventory and scanning tools.
•	Mean Time to Mitigation (MTTM) or trend lines for aging vulnerabilities.
•	Integration with API-based dashboards (e.g., Power BI, Elastic, or custom security portals) could allow agencies to visualize Key Security Metrics over time.

Suggested Support Materials

To enable widespread adoption, the following artifacts should be prioritized:

1.	GitHub-based open-source reference implementation using Terraform, AWS, Azure, or Kubernetes components mapped to KSM outputs.
2.	JSON Schema definitions for each KSM metric and validation tools.
3.	Sample CI/CD pipeline YAMLs (e.g., GitLab, GitHub Actions) demonstrating automated KSM generation, export, and visualization.
4.	Maturity model or self-assessment guide for CSPs to evaluate readiness to adopt the Continuous Reporting Standard.

Final Notes

To further reinforce success:

•	Recommend tie-in with FedRAMP 20x and FedRAMP OSCAL adoption timelines.
•	Consider a phased rollout with voluntary participation before full enforcement.
•	Encourage shared services providers to publish anonymized aggregated metrics to promote industry benchmarking and transparency.

Thank you again for leading this forward-looking shift in continuous monitoring.

[p4gs]

1. Vulnerability reachability context has become increasingly important in understanding real vulnerability risk (and thus the necessity of urgent/non-urgent remediation or mitigation). How should providers account for "vulnerability reachability?" Is it appropriate to document that as part of an "Explanation of mitigation measures" (even if it isn't explicitly a mitigation measure that was intentionally applied?")
2. Including KEV context is useful for better understanding vulnerability risk. What about also requiring the inclusion of EPSS when it's available, since it is becoming more widely adopted in the industry (both in terms of internal security teams using it more and also vulnerability management products incorporating them more)?
3. What are relevant examples of "vulnerability groupings" or "vulnerability groups?" This seems too open to interpretation and could result in wildly different approaches being used by providers that could create excessive complexity for assessors to understand across their portfolio of providers
4. This standard seems excessively focused on vulnerability scanning. What about other essential and common security controls types, such as threat detection/monitoring controls, data encryption controls, etc? It would be beneficial to enumerate other universally-relevant baseline security controls for providers to include Key Security Metrics about
5. It would be beneficial to provide a general taxonomy of Key Security Metric Types to make it easier to describe what kinds of metrics should be provided for different concerns. For example: Control Coverage Metrics (what percentage of in-scope components are being scanned/monitored/protected by this control vs. not), Risk Reduction metrics (what percentage of security "findings" for this control type were remediated/mitigated/resolved within a defined SLA?), etc.

[ChanceofClouds]

4. In the same idea as that, should there be something added to account for Federal data calls?

[bernieleung]

"AI" is the new buzz phrase and is very obvious during the recent RSAC. Every vendor has its own risk rating based on its own proprietary AI model. But I do not believe most models have enough data to provide a true and realistic risk rating. Hence we see rapid up/down changes in patching requirements. I suggest we focus on remediation trends such as coverage, patching timeliness over 3, 6 or 12 months. Vulnerability management can then receive the same scrutiny as the other manual control findings. After all, RA-5 is only a part of the CSP's complete security posture.

[wisecryptic]

Detailed Component Scan Coverage - Numbers and percentage of components covered by the services’s security scanning activities grouped by distinct component type and scan type

I have questions on why this is included. This requires a deeper level of sophistication to implement and manage in a dynamic environment than I expected of a monthly metric. It also feels like a more forensic metric, not a continuous monitoring metric.
Was this a specific request from agencies? Or was it added in as a nice-to-have? If agencies requested it, What value is being derived from this monthly view that isn't derived from 6 or other mtetrics? Does that value tie to direct security outcomes or to customer perception? I would further ask if the value derived justifies the breakdown, automation, and reporting required to support this metric.

My recommendation given the above is to remove this point but interested to hear if there are other points of view on this.

[ChanceofClouds]

My thoughts: This likely stems from in the FedRAMP Rev. 5 SARs, FedRAMP PMO would compare the inventory (asset's IP addresses or unique identifiers) to the raw scan files to make sure that all of the inventory is being scanned. Purpose is to ensure not only some assets/asset types are being scanned.

[Rene2mt]

The reporting requirements are intended to be reasonable for both providers and agencies, facilitating innovation and informed risk analysis and acceptance. Do they strike the right balance between security oversight and operational efficiency?

The proposed reporting contents (e.g., Key Security Metrics) seem reasonable and feasible. Some additional metrics like mean time to remediate and patch rate could be very insightful.

This standard explicitly encourages that mitigated vulnerabilities be reported and tracked at their estimated risk rating after mitigation rather than their original risk rating. Is this a change in the right direction?

Some documented guidance, standards, etc. for risk adjustment approaches will be very helpful to ensure providers, 3PAOs, agencies are in alignment.

This approach is intended to give agencies adequate visibility into the overall security posture of a cloud service offering. What additional information might agencies need to maintain their risk awareness?

The proposed reporting standard provides a point-in-time snapshot but historical trends would be useful. The standard requires that providers keep the metric available for 24 month, so technically, agencies could develop trends, but it may be more efficient if the providers can produce key security metrics data series (e.g., ability to query and retrieve metrics over the last X months).

Standards will be supported separately by templates, best practices, technical assistance, and other materials. What materials might be prioritized for production to support this standard?

It will be very helpful for agencies if there is a standardized reporting template and for machine-readable formats, a clear standard. Otherwise, we could have providers producing their continuous reporting data in various formats, which will make it more difficult for agencies to consume in an efficient and consistent way.

Other Comments

This standard begins a shift away from the government requiring cloud service providers to upload scan logs

What assurance do agencies have regarding the completeness and accuracy of reported metrics without some of the underlying data (e.g., scans)? Does this become part of a periodic (sample) review by 3PAOs (e.g., during annual assessments)?

Providers SHOULD update Key Security Metrics one week before monthly monitoring meetings ...

Providers may have multiple monthly meetings with various customers. It may be more practical to schedule such meetings to coincide with an established reporting frequency. For example, if metrics are updated monthly, agencies and providers can simply coordinate to ensure their meeting occurs at least X days after the monthly key security metrics updates but no more than 30 days after.

Providers MAY carry mitigated vulnerabilities beyond FedRAMP remediation windows for the original risk rating without penalty but MUST remediate such vulnerabilities once it is reasonable to do so.

Seems like this could lead to long-standing, unmitigated vulnerabilities. Need a way do disincentivize that.

[kcarr91]

I think the Technical Assistance doc (and Templates) will be very interesting to see how this is standard implemented. The Technical Assistance document could then make us look a bit harder at this standard and suggest further updates.

For example that Technical Assistance doc could change what I think should or shouldn't fall under Unmitigated Vulnerabilities and Mitigated Vulnerabilities. Also I am wondering is it really worth splitting Unmitigated Vulnerabilities and Mitigated Vulnerabilities vs just grouping them together? However, this might have already been addressed in the Technical Assistance document, i would just want to have 1 list of Vulnerabilities and then in that list note which ones are Unmitigated vs Mitigated.

[GurkhaShieldForce]

What additional information might agencies need for risk awareness:

For the Unmitigated Vulnerabilities reporting, consider adding environmental risk context fields such as EPSS, and Asset Criticality Rating - which can be derived from various factors like network exposure level, data sensitivity classification of affected systems. This would help agencies understand why a CSP might prioritize a Medium vulnerability over a High one based on actual organizational risk.

[sfc-gh-schaudhry]

Discussion Requested

The reporting requirements are intended to be reasonable for both providers and agencies, facilitating innovation and informed risk analysis and acceptance. Do they strike the right balance between security oversight and operational efficiency?

For providers that do not or cannot have most of the metrics or data collection for metrics automated, there will be considerable overhead. A better balance could be achieved by focusing on higher risk vulnerabilities that exceed general risk thresholds for agencies, rather than listing all unmitigated vulnerabilities. Additionally, for lower risk vulnerabilities, reporting could be limited to overdue (past SLA) vulnerabilities and vulnerabilities with exceptions.

This standard explicitly encourages that mitigated vulnerabilities be reported and tracked at their estimated risk rating after mitigation rather than their original risk rating. Is this a change in the right direction?

Mitigation should be reworded or defined in this document. It should be risk adjusted due to mitigating factors as a misunderstanding could occur meaning remediation.
The risk reporting SLA should be based on mitigating factors and not the original risk rating. CSP’s should have the ability to take into account external vendor recommendations (e.g., RedHat, Microsoft, Google, etc.) and risk downgrades/ratings, compensating controls, location of the affected assets within the system architecture, additional protections in place, and available attack vectors to exploit the vulnerability on the asset. For instance, CVE-2024-36896 can be considered as a “Critical” risk on the NVD site (https://nvd.nist.gov/vuln/detail/cve-2024-36896), however, vendors with additional information in regards to the CVE could consider the risk at a lower level such as “Low” (https://access.redhat.com/security/cve/cve-2024-36896)
Evaluating risk based on current vulnerability status (mitigated, unmitigated, etc.) enables more relevant decision making concerning risk acceptance or whether post-mitigated vulnerabilities persist as high risks that require additional mitigation efforts or if adequate protections for both the CSP environment and customer data are implemented to limit any risk or exposure.

This approach is intended to give agencies adequate visibility into the overall security posture of a cloud service offering. What additional information might agencies need to maintain their risk awareness?

How often scans are conducted, how many OS and container images a CSP is managing, how often vulnerabilities are out of SLA, when a fix was made available from the vendor, and most important how many vendor dependencies. An aggregate number compiled about a vendor who does not release a patch will help with removal of / ban of specific packages (supply chain risk).

Standards will be supported separately by templates, best practices, technical assistance, and other materials. What materials might be prioritized for production to support this standard?

For agencies, guidance on how continuous reporting informs their risk assessment and management processes. For CSPs, what APIs or connections will be required to share with the agencies or the PMO. The biggest change will be the lack of structure/standardization which ultimately helps streamline how the right data is provided. The list of the data an agency or the PMO will need, will allow the CSPs to craft a methodology to provide it.

Continuous Reporting

Number of vendor dependencies - the PMO should aggregate a number of vendors

[Telos-sa]

Continuous Reporting FedRAMP RFC-0008 - Discussion and feedback.

Vulnerabilities (Details for mitigated and unmitigated) Review

This section seems like a modification of the current reporting features (POAM TRACKER) with a few key differences. Would like to validate the differences:

Differences

Reporting for DR types and Vendor Dependencies:
from: Application of the Continuous Reporting Standard
Providers SHOULD NOT include validated false positives in security reporting to agencies and FedRAMP. Providers MUST maintain documented evidence for determinations of false positives for the duration of their existence.

Removing the bloat is great, but leaves on the table requirements for how the false positives that have not been approved, be reported (as with a mitigation or without a mitigation). It is requesting evidence. Is that to be submitted in another reporting format? (Supporting documents was not listed as requirement for mitigation findings.

Recommend detailing the accepted mitigation types, and provide structured requirements on how to handle the in-process false positives.

Reporting only for active
Confirm that the KSI reporting only requires active findings.

Asset identifier - converted to count:
Based on the new Requirement: Total number of unmitigated items, it should instead be just a count.
This is great!

Additional reduced reporting: Columns from FedRAMP POA&M Tracker that are no-longer required:
confirmation that these no longer have a use case. While the requirement states that additional detail can be provided, these are NOT covered under the reporting requirements. Assuming they can be removed.

• Controls
• Point of Contact
• Resources Required
• Status Date
• Supporting Documents
• Comments
• Auto-Approve
• Vendor Dependency
• Last Vendor Check-in Date
• Vendor Dependent Product Name

Sections 3-5 (Incidents, Significant Change Notifications, Upcoming Milestones)

While this is good for a directive, or a policy. It does not contain enough details for explicit requirements.

To support standardized data deliverables, recommending that these sections are clarified with additinal detail, like what was provided in sections 1 and 2, to ensure Application Standards and requirements are met.

In Incidents, it says incident-related activities does that mean training and exercises?
Or, are you only looking for what is currently reported in the FedRAMP Monthly ConMon Executive Summary.

Sections 6-7 (Scan Coverage)

I like where this is going, but would like some additional clarity on the component definitions.

Recommend Leveraging the OSCAL definitions for component types to standardize and support reciprocity
https://pages.nist.gov/OSCAL-Reference/models/v1.1.3/plan-of-action-and-milestones/json-reference/#/plan-of-action-and-milestones/local-definitions/components/type

Overall Questions/Comments:

• Are Operational Requirements no longer supported (will they just be open and overdue and only mitigations if included in a Risk Adjustment) or will Operational Requirements be mitigations with an an expiration date?
• Any requirements for evidence files/ supporting documentation (scan files) or just coverage? Are you requesting the artifacts in a specific format to support computer readable?
• Bundling compliance findings under a single POAM,

OSCAL Submission (Computer readable requirement)

With the above as assumptions, this could be a way of programmatically submitting the reporting requirement, using the NIST OSCAL format. Below is a build out of Continuous Reporting Requirements 1-7. Some have blank props or links, that could/should be built out with requirements.

{
    "plan-of-action-and-milestones": {
        "uuid": "Identifies unique report",
        "metadata": {
            "title": "CSP/CSO name",
            "last-modified": "Date Created"
        },
        "local-definitions": {
            // Record of all component types, so that we can capture scan coverage and failed assets.
            "components": [
                // Continuous Reporting coverage for sections 6 and partial 7
                {
                    "uuid": "uuid to reference in risks",
                    "type": "pre-set list of component types",
                    "title": "component name", // supports human readable
                    "description": "component description",
                    "purpose": "why component is in boundary (helps with scope)",
                    "props": [
                        { // Supporting section 6 & 7
                        "name": "inventory-count",
                        "ns": "https://fedRAMP.ns",
                        "value": "number"
                        },
                        { // Supporting section 6 & 7
                        "name": "scanned-count",
                        "ns": "https://fedRAMP.ns",
                        "value": "number"
                        }
                    ]
                }
            ],
            "assessment-assets": [
                // Continuous Reporting coverage for sections 7 (partial coverage)
                {
                    "components": {
                        "uuid": "uuid of scanner tool",
                        "title": "Scan Configuration",
                        "description": "Describe Scan configuration",
                        "purpose": "Describe why it is used in boundary",
                        "links": [
                            {"href": "# uuid from localdefinition/components"}// entry for each component covered by scanner
                        ]
                    }
                },
                {
                    "assessment-platforms": [
                        "uuid": "unique identifier",
                        "title": "name of assessment tool",
                        // may want a prop that describes purpose, and/or scan type, etc.
                        "uses-components": [
                            {"component-uuid": "uuid from assessment-assets/components"}
                        ]
                    ]
                }
            ]
        },
        "observations": [
            // reporting for 3, 4, 5, 6, 7
            { // record of each incident
                "uuid": "uuid for tracking",
                "title": "incident-response",
                "description": "overview of incident activity",
                "props": [
                    // list of props based on the reporting requirements when expanded on
                ],
                "relevant-evidence": [
                    // links to evidence (can also use links) but this has props and additional elements
                ],
                "collected": "date of incident activity"
            },
            { // record for incident response
                "uuid": "uuid for tracking",
                "title": "significant-change-notifications",
                "description": "overview of reporting period",
                "props": [
                    // list of props based on the reporting requirements when expanded on
                ]
            },
            { // record for each significant change
                "uuid": "uuid for tracking",
                "title": "significant-change-notifications",
                "description": "overview of reporting period",
                "props": [
                    // list of props based on the reporting requirements when expanded on
                    // Like deployment Date, comments, etc...
                    // links to artifacts (SAP, SAR, etc)
                ],
                "links": [
                    // include links to media
                    // include links to components that are impacted by the change
                ],
                "collected": "Date notification was released"
            },
            { // record for each upcoming milestone
                "uuid": "uuid for tracking",
                "title": "upcoming milestones",
                "description": "overview of reporting period",
                "props": [
                    // list of props based on the reporting requirements when expanded on
                    // Like deployment Date, comments, etc...
                ],
                "links": [
                    // include links to media
                    // include links to components that are impacted by the change
                ],
                "collected": "date data was provided"
            },
            { // record of scan coverage
                "uuid": "uuid for tracking",
                "title": "scan coverage",
                "description": "overview of reporting period",
                "props": [
                    // which ever props are required here
                ],
                "relevant-evidence":[
                    // reporting of calculations from coverage in local definitions
                    // for each component
                    {
                        "href": {uuid of component},
                        "description": "Overview of findings",
                        "props": [
                            // props to calculate coverage of component and configuration from scanners
                        ],
                        "links":[
                            // links to scan files as supporting evidence (uuid based)
                        ]
                    }
                ],
                "collected": "date of most recent scans that would impact calculations"
            }
        ],
        "risks": [// Simplify TRACKER to report on open findings 
            // Continuous Reporting coverage for sections 1 & 2
            {
                "uuid": "unique identifier to link to other elements",
                "title": "Weakness Name", // From POAM Tracker,
                "description": "Weakness Description", // From POAM Tracker,
                "props": [
                    { // create ns for poamID To maintain historical submissions
                        "name": "poam-id",
                        "ns": "https://fedRAMP.ns",
                        "value": "POAM ID" // From POAM Tracker
                    },
                    { // risk Rating
                        "name": "original-risk-rating",
                        "ns": "https://fedRAMP.ns",
                        "value": "original Risk" 
                    },
                    { // Total number of vulnerable components
                        "name": "impacted-components",
                        "ns": "https://fedRAMP.ns",
                        "value": "Count of failed"
                    },
                    { // if exists, include KVE
                        "name": "known-exploit-due-date",
                        "ns": "https://fedRAMP.ns",
                        "value": "date from KVE list"
                    }
                ],
                "links": [
                    // supports 
                    {"href": "# uuid from local-definitions for each vulnerable component"}// entry for each component
                ],
                "status": "select one: ['open', 'deviation-requested']", // scoped list based on Discussion Requirements
                "threat-ids": [
                    // Add CVE, plugin ID, CWE, dict for each related to POAM
                    {
                        "system": "uri back to the source (mitre, scanner, etc)",
                        "id": "plugin-id/cve/cwe"
                    }
                ],
                "mitigating-factors": [
                    // Collection of Deviation Requests.
                    {
                        "uuid": "tracking number of DR",
                        "description": "Explanation of mitigation measures",
                        "props": [
                            {
                                "name": "adjusted-risk-rating",
                                "ns": "https://fedRAMP.ns",
                                "value": "new Risk rating" // for mitigations
                            }
                        ]
                    }
                ],
                "deadline": "original due date",
                "remediations": [
                    // Remediation and/or mitigation plans, including dates
                ]
            }
        ],
        "back-matter": {
            // dictionaries of all supporting data and artifacts
        } 
    }
}

[Christcpd]

This may create a burden on the organization to gather and manage. "Mitigated Vulnerabilities - A list of mitigated vulnerabilities or vulnerability groups, broken down by estimated risk rating after mitigation, including at least the following information:" If the goal here is to track vulns that were mitigate and not remediated, then I understand the inclusion. But if mitigated includes remediated, then there is a large burden.

For example, MS Patch Tuesday and Vuln Scan run on Friday. Those vulns are listed. Next month, MS Patch Tuesday and now the organization has to gather information on vulns that were automatically patched by MS? That's a ton of MANUAL work.

Hopefully I am wrong and remediated vulns are not included in mitigated vulns. If so, additional language would help clarify that. Or a reference to a doc or TA.

[pete-gov]

Public comment submitted via email by Adobe (plain text copy/paste from a PDF, apologies for formatting):

Adobe appreciates the opportunity to provide feedback on RFC-0008, the proposed Continuous Reporting
Standard.1 We commend the FedRAMP PMO for its continued efforts to modernize and streamline the reporting
process in ways that support both agency oversight and cloud service provider (CSP) innovation. Below are
Adobe’s comments on the draft standard.

1. Vulnerability Groupings

Adobe supports the inclusion of vulnerability groupings in Sections 1 and 2 of the Key Security Metrics. Grouping
vulnerabilities by shared characteristics—such as common root cause, affected component, or remediation
strategy—improves clarity, reduces administrative overhead, and enhances the actionability of reports. This
approach aligns with how many modern security teams manage vulnerabilities.

2. Component and Mitigation Reporting

Sections 1(4) and 2(4) of the Key Security Metrics require reporting on “components or services impacted,” and
Section 2(6) requires an “explanation of mitigation measures.” We recommend the PMO clarify the expected
level of specificity for these fields while considering: 1) Overly detailed disclosures may inadvertently expose
sensitive architectural information; and 2) Mitigation explanations may include proprietary or security-sensitive
details that a bad actor could misuse.

Alternatively, referencing component categories (e.g., “application tier” or “database service”) may be sufficient
for agency risk analysis without disclosing sensitive implementation details. If categories are not deemed
sufficient, we suggest the PMO add flexibility to the language in Section 1(4), 2(4) and 2(6) such as “to the extent
such reporting is not reasonably expected to enable misuse by parties that could harm CSPs or its customers".
We recommend that the PMO provide guidance or examples in best practice materials to help CSPs balance
transparency with operational security.

3. Scan Coverage Metrics

Sections 6 and 7 of the Key Security Metrics require reporting on scan coverage, including the percentage of
components covered by security scanning. This is an expansion on current FedRAMP POA&M reporting, which
does not include scan coverage metrics. While we understand the intent to provide agencies with a broader
view of system health, we recommend clarifying how these metrics will be interpreted and used in risk
assessments.

In general, scan coverage data is not always a reliable proxy for organizations’ security posture. Scan coverage
data can vary significantly depending on an organization’s system architecture, scanning tool capabilities,
accessibility of hosts by the scanner, use of ephemeral technologies, and other factors. As a result, scan
coverage data can be very system-specific and not easy to generalize to an industry threshold. Without context,
these metrics may be misinterpreted or lead to inconsistent expectations across agencies. We suggest that scan
coverage reporting be accompanied by guidance developed with industry input regarding acceptable thresholds,
potentially based on qualitative rather than quantitative methodology.

4. Reporting of Mitigated Vulnerabilities

We support the shift in Section 2 of the Key Security Metrics toward reporting mitigated vulnerabilities at their
estimated post-mitigation risk rating rather than their original severity. This change reflects a more mature, risk-
informed approach to vulnerability management and aligns with industry practices. It also reduces the likelihood of inflated POA&M inventories that do not accurately reflect residual risk.
We encourage the PMO to reinforce this approach in future updates to the POA&M template and related
guidance, designed to ensure consistency across reporting mechanisms.

5. False Positive Reporting

Section 8 of the Application of the Continuous Reporting Standard instructs CSPs to not include validated false
positives in security reporting. We encourage the PMO to clarify that false positives should be absent from any
reporting after validation, and not appear in the “Closed Item” tab of the POA&M.

6. Incident Reporting

Section 3 of the Key Security Metrics would establish a new requirement to include “information about any
incident-related activities” in continuous monitoring reports. This is very broad language that should be
balanced against unnecessary over-reporting as well as the security risks of disclosing sensitive information. It is
unclear why this requirement is included when CSPs have existing incident reporting requirements to authorized
agencies via contract and other regulatory frameworks. We encourage the PMO to remove this requirement, or
to significantly narrow the scope of the details required and allow for reciprocity with other incident reporting
requirements. We recommend the PMO consider adding a carveout to the language in Section 3 such as “to the
extent such reporting is not reasonably expected to enable misuse by parties that could harm CSPs or its
customers".

7. Customer Portal

Under the current continuous reporting process, CSPs typically upload POA&Ms to connect.gov. Section 5 of the
Application of the Continuous Reporting Standard instructs CSPs to make the Key Security Metrics available
within their standard customer portals. We appreciate that the PMO envisions enabling CSPs to have additional
flexibility in how Key Security Metrics are made available. However, the PMO should clarify whether this would
require that the customer portal also be FedRAMP authorized to securely store this type of data, as connect.gov
presently is. We also encourage the PMO to continue to consider connect.gov as a viable alternative for CSPs
whose customer portals are not FedRAMP authorized.

8. Balancing Oversight and Efficiency

Overall, we believe RFC-0008 strikes a reasonable balance between security oversight and operational
efficiency. The emphasis on reuse across agencies, grouping vulnerabilities, machine-readable formats, and
risked-based reporting is especially welcome. However, as noted above, we recommend that the PMO prioritize
the following clarifications to the standard or supporting materials designed to ensure successful
implementation:

• Guidance for scan coverage reporting;
• Updating POA&M guidance to reflect risk-based reporting of mitigated vulnerabilities;
• Provide details regarding treatment of validated false positives;
• Narrowing the scope of incident reporting and providing for reciprocity with other reporting
requirements; and
• Maintaining connect.gov as a continuous reporting channel.

---

Adobe appreciates the PMO’s thoughtful approach to modernizing continuous monitoring. We believe RFC-0008
is a step in the right direction and look forward to collaborating further as the standard is finalized and
implemented.

[jkdean]

Thank you for the opportunity to comment on the Continuous Reporting Standard. 
FedRAMP’s 20x vision of objective, real time, evidence driven oversight, is exactly what Cybersecurity Performance Management (CPM) was designed to deliver. First highlighted by Gartner® as a high benefit approach for dynamically reducing and communicating cyber risk, CPM complements, and scales with, established frameworks such as RMF, ISO 27001, NIST CSF, CMMC, CIS Controls, and CISA CPGs. It gives organizations a practical, performance centric layer that unifies those standards into a single, continuously managed picture of cyber readiness. To operationalize CPM, TDI has developed a rich catalogue of Cybersecurity Performance Indicators (CPIs), quantitative, goal based metrics that stream telemetry from existing tools into actionable insight on risk, compliance, maturity, and ROI.

The current proposed metric set is largely volume based. To complete the picture, we suggest adding at least one timeliness or performance metric, such as Mean Time to Remediate critical CVEs (MTTR CVE). Including a speed of fix indicator allows agencies to see how quickly issues are resolved, not just how many exist, and highlights providers that actively drive down risk.

We endorse FedRAMP’s intent to reuse continuous monitoring data across frameworks, particularly DoD’s Software Fast Track (SWFT). True reciprocity, however, depends on identical metric definitions and thresholds. We encourage the PMO to engage early with SWFT and civilian agency stakeholders to harmonize terminology (e.g., “scan coverage”) so providers can maintain a single data pipeline for multiple authorizations.

To maintain full risk awareness, agencies might also benefit from trend views (e.g., 90 day trajectories of high severity vulnerabilities) and brief incident outcome summaries that demonstrate lessons learned. These additions would complement the required metrics and bolster situational awareness.

We find the Continuous Reporting Standard to be a well considered step toward real time, performance based security oversight. With the addition of a timeliness metric and early coordination on metric definitions across programs, FedRAMP can deliver meaningful insight while keeping provider overhead reasonable. TDI looks forward to supporting and collaborating on making this model a success. Thank you for considering our feedback.

[abowers-elastic]

Overall, we appreciate this standard because it enables providers to design their own reporting format(s) to share with agencies. In practice, this may be something that is developed in coordination with the agencies because they sometimes have their own reporting templates they expect providers to complete each month.

1. Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats.

Will the FedRAMP PMO be identifying which machine-readable formats are acceptable?

6. Providers SHOULD mitigate vulnerability risk as quickly as possible. Providers SHOULD adjust vulnerability severity based on documented mitigation.

We appreciate the recognition of compensating or mitigating controls here which enables providers to adjust risk based on their environment.

7. Providers, third-party assessment organizations, agencies, and FedRAMP SHOULD consider mitigated vulnerabilities at their mitigated risk rating. Providers MAY carry mitigated vulnerabilities beyond FedRAMP remediation windows for the original risk rating without penalty but MUST remediate such vulnerabilities once it is reasonable to do so.

Our interpretation of "mitigated vulnerabilities" are issues that are historically submitted for risk adjustment or as an operational requirement. Handling mitigated vulnerabilities in this manner could result in risk being carried for far longer than they feasibly should by both the CSP and agency. Compliance teams within CSPs often need to rely on firm requirements to ensure issues are mitigated/remediated in a timely manner. These teams may have a difficult time getting adequate prioritization internally because there aren't firm requirements and once it's reasonable to do so could be easily taken advantage of to buy more time or simply avoid addressing the issue.

In short, the way this is defined would give compliance teams less leverage internally to have risks addressed in a timely manner.

[austinsonger]

1. Include a Required Field for ‘Mitigation Type’ - Agencies would benefit from knowing whether mitigation was technical (e.g., WAF), administrative, or compensating.
   - Recommendation: Add a field to Mitigated Vulnerability reports:

   • {{MITIGATION_TYPE}}: (e.g., Patch, Configuration Change, Network Segmentation, WAF, Documentation Only)

2. Define a Minimum Set of Machine-Readable Schema Fields - While innovation is encouraged, lack of even a basic schema risks wild inconsistency.

   • Recommendation: Provide a minimum recommended JSON/YAML schema, e.g., for:
     • component_id
     • cve_id
     • risk_rating
     • mitigation_date
     • exploitability
     • fedramp_due_date

3. Clarify How “Monthly” Updates Are Calculated - CSPs have differing interpretations of “monthly”—calendar vs rolling vs 30-day windows.

   • Ask: Can FedRAMP clarify whether updates must occur by the same day each month, or allow flexibility (e.g., every 30–35 days)?
   • Suggestion: Align this with typical POA&M and vulnerability scan cycles for easier adoption.

4. Add a Requirement to Timestamp All Metric Updates - Without explicit update timestamps, agencies may assume data is stale.

   • Recommendation: Require a last_updated field for each metric bundle/report.

5. Publish a GitHub-Based Reference Format Repo -

   • To reduce friction and encourage innovation, publish a reference format repo with:
     • Sample JSON reports
     • MITRE KEV integration tips
     • Redacted real-world report templates
     • Parsing logic for converting traditional scans to FedRAMP continuous reports

6. Encourage Reporting of SLA/Availability Metrics

   • Suggestion: Recommend optional reporting of
     • Uptime % (monthly/quarterly)
     • Unplanned outages
     • SLA breach metrics

[pete-gov]

Comment received via email:

Clarification on Mitigated Vulnerabilities vs. Existing Risk Adjustment Process

We request clarification on the distinction between "Mitigated Vulnerabilities" as defined in RFC-0008 and the current risk adjustment process. Specifically, how does this new concept differ from the existing practice where compensating or mitigating controls are documented to adjust a vulnerability's risk level (e.g., from High to Moderate)?

Integration of Vendor Dependencies and Operational Requirements

Could you please elaborate on how the concepts of Vendor Dependencies or Operational Requirements are incorporated into the new paradigm of reporting on Mitigated and Unmitigated Vulnerabilities?

Reporting Status of Manual Control Findings

Will providers continue to report on the status of manual control findings as part of the new continuous monitoring standard outlined in RFC-0008?

Scope of Vulnerability Reporting and Management of Closed Items

For clarity, please confirm that under the new standard, providers will primarily report on open, existing security vulnerabilities. Does this imply that the practice of reporting on 'Closed' POA&M items and tracking them indefinitely will be discontinued?

Standardization of Machine-Readable Formats

We recommend the explicit detailing and enforcement of a specific machine-readable format (or formats) that all participating agencies must accept. Without a mandated standard, there is a risk of an unmanageable proliferation of formats across the industry. This could lead to a situation where providers must generate artifacts in numerous different formats to satisfy the varying maturity levels and ingestion capabilities of their customer agencies.

Guidance on Vulnerability Groupings

RFC-0008 mentions that vulnerabilities may be provided individually or in vulnerability groupings. We request further guidance on how providers may group vulnerabilities to prevent significant disparities in implementation across the industry. Additionally, does the concept of "vulnerability grouping" imply that a single POA&M item can address multiple related CVEs?

Definition of "Percentage of Distinct Component Configurations"

We request clarification on the term "percentage of distinct component configurations" as it relates to "Overall Scan Coverage." Specifically, are these considered unique assets/components, or is a more granular definition intended?

Carrying Mitigated Vulnerabilities Beyond Remediation Windows

RFC-0008 states, "Providers MAY carry mitigated vulnerabilities beyond FedRAMP remediation windows for the original risk rating without penalty but MUST remediate such vulnerabilities once it is reasonable to do so." We seek clarification on the guardrails defining what FedRAMP considers "reasonable" in this context. Furthermore, if a POA&M is carried past its due date because it has been deemed "reasonable" to do so, will this POA&M still be categorized as "overdue" and potentially contribute to FedRAMP escalatory actions, such as a Detail Findings Review or a Corrective Action Plan?

Availability and Reporting of Key Security Metrics

RFC-0008 states, "Providers MUST keep Key Security Metrics available to agencies and FedRAMP for 24 months after initial reporting" and "Providers SHOULD make Key Security Metrics available within their standard customer portals, protected with appropriate controls to ensure agencies and FedRAMP can make this information available to their information security staff." We note that some of this information may already be addressed via existing ConMon Package uploads (e.g., to USDA Connect). If KSMs are maintained within USDA Connect, do providers need to maintain additional copies elsewhere in order to satisfy 24 month retention requirements?

[pete-gov]

Public comment received via email (this has some strikethrough stuff that might not carry over):

Google appreciates the reusability and enhanced efficiency that the updated Continuous Reporting Standard presents, including the reporting of vulnerabilities at their mitigated risk level and removal of raw scan submissions. Google would like to raise the below suggestions and proposed changes to the standard:

1. Clear definition for “Mitigated Vulnerabilities”: We would like to seek clearer definitions and guidance for “documented mitigations” / “mitigated vulnerabilities”. Google’s interpretation of the standard defines “mitigated vulnerabilities” as risk adjustments. This should be defined to ensure consistency across cloud service providers and a common understanding by federal agency information security personnel.
2. Clear definition of “Security Incidents”: We would like to seek a clear definition and examples of the types of incident-related activities that FedRAMP is seeking in continuous reporting. Google proposes leveraging the NIST definition of security incidents as outlined here: https://csrc.nist.gov/glossary/term/security_incident
3. Prioritize Supporting Materials: We suggest FedRAMP prioritize the development of the mentioned templates and materials within a reasonable timeline and communicate the scheduled delivery date of the supporting materials at the time of the standard being published.

Proposed revisions to the Standard sections:

Section title:	Current text:	Google Proposed changes:
Introduction	Providers must ensure such information is available directly to agencies and regularly review it with all participating agencies.	Google recommends the below revision: Providers must ensure such information is available directly to agencies and regularly (i.e., no more than monthly) review it with all participating agencies.
	This updated standard creates a new Continuous Reporting Standard that replaces some \parts of previous FedRAMP guidance related to reporting on continuous monitoring activities for all FedRAMP authorizations and certifications, including the current Rev 5 Agency Authorization process and FedRAMP 20x.	Google requests FedRAMP to define what “some” Continuous Reporting Standards are being replaced. This updated standard creates a new Continuous Reporting Standard that replaces some (including x, y, z) parts of previous FedRAMP guidance related to reporting on continuous monitoring activities for all FedRAMP authorizations and certifications, including the current Rev 5 Agency Authorization process and FedRAMP 20x.
Continuous Reporting	1. Unmitigated Vulnerabilities - A list of unmitigated vulnerabilities or vulnerability groupings, broken down by risk rating, including at least the following information:	Google agrees with CSP-AB’s suggested revision: Unmitigated Vulnerabilities - A list of unmitigated vulnerabilities or vulnerability groupings, including those pending resolution due to operational constraints or vendor dependencies...
	1. vi. Known Exploited Vulnerability status 2. ix. Known Exploited Vulnerability status	Google recommends the below revision: 1. vi. CISA’s Known Exploited Vulnerability status 2. ix. CISA’s Known Exploited Vulnerability status
	2. Mitigated Vulnerabilities - A list of mitigated vulnerabilities or vulnerability groups, broken down by estimated risk rating after mitigation, including at least the following information:	Google agrees with CSP-AB’s suggested revision:�Mitigated Vulnerabilities - A list of vulnerabilities or groups with mitigations applied, presented with adjusted estimated risk ratings post-mitigation...
	2. x. Remediation plan, including dates	Google recommends the below revision: 2. x. Remediation plan (if further action is required post-mitigation), including dates
	6. Overall Scan Coverage - Overall numbers and percentage of distinct component configurations covered by the service’s security scanning activities	Google recommends the below revision: 6. Overall Scan Coverage - Overall numbers and percentage of distinct component configurations covered by the service’s security scanning activities This is because scans can and should occur at different layers of the stack so they may not always align to a specific service.
Application of the Continuous Reporting Standard	5. Providers SHOULD make Key Security Metrics available within their standard customer portals, protected with appropriate controls to ensure agencies and FedRAMP can make this information available to their information security staff.	Google recommends the below revision to limit access to key staff: 5. Providers SHOULD make Key Security Metrics available within their standard customer portals, protected with appropriate controls to ensure agencies and FedRAMP can make this information available to their information security staff (i.e., no more than 2-3 agency staff).
	6. Providers SHOULD mitigate vulnerability risk as quickly as possible. Providers SHOULD adjust vulnerability severity based on documented mitigation.	Google recommends the below revision: 6. Providers SHOULD mitigate vulnerability risk as quickly as possible. Providers SHOULD adjust vulnerability severity based on documented mitigation (i.e., risk adjustment).

[pete-gov]

public comment received via email (formatting may not carry over):

Qualys Response to FedRAMP RFC-0008

Making Security Productive Again Through Risk-Based Continuous Monitoring

![][image1]
Background

Qualys is a FedRAMP authorized platform that natively addresses approximately 65% of FedRAMP High technical controls and supports thousands of government and Cloud Service Provider (CSP) environments. Our recommendations reflect the operational reality of running secure cloud services at scale and our experience as a global SaaS running Continuous Monitoring (ConMon) for more than a decade. As a result of this lived experience, Qualys, a leading vulnerability management company, has extended its focus to execute on risk-based methods for managing cybersecurity risk. This analysis explains why, and how we might work together to realize the vision and strategy of FedRAMP 20X.

Executive Summary

Current ConMon practices place outsized emphasis on vulnerability management, driven entirely by CVSS scores. This narrow focus undermines broader risk management goals and consumes scarce engineering resources that should be allocated to activities with higher security returns: architecture reviews, secure design, threat modeling, and control implementation.

FedRAMP should evolve ConMon and POA&M guidance to reflect a holistic approach to security posture monitoring that drives increased risk reduction for the government by focusing on hardening (secure configurations, defense-in-depth, resiliency engineering) and increasing the continuous monitoring scope to assess other critical controls through automation. This includes integrating configuration management, asset management, software security, and modern risk-based prioritization capabilities to identify the risks that truly matter. ConMon should also evolve to include continuous monitoring of threat exposures that are not identified as vulnerabilities – e.g.,

![][image2]
databases exposed to the Internet, week credentials that lack multi factor authentication, etc.

The government benefits when CSPs can shift to strategies that reduce noise from non-exploitable vulnerabilities and pull in additional signals that present weaknesses in the context of risk. This allows CSPs to unlock time which is otherwise wasted on remediation of non-exploitable issues at the expense of architecture reviews, threat modeling, secure by design initiatives, and control

enhancements, and other risk reducing activities.

Problem

Vulnerability volume continues to grow—over 19,000 CVEs in 2025 alone—but only ~6% are exploited.1 More impactful, 78% were still ranked High/Critical by CVSS.2 On average, attackers have 11.1 days of exploitation opportunities before organizations begin patching,3 largely due to a growing bottomless backlog of CVEs. Yet ConMon requires CSPs to address vulnerabilities as if all pose equal risk in the same classification level (For example, a high finding of Log4j should carry higher weight than a high finding , leading to the elimination of capacity for initiatives outside vulnerability management. Teams spend the bulk of their limited security time remediating non exploitable issues rather than investing in high-value security outcomes like system hardening and Secure by Design.

If we leverage the MITRE ATT&CK Framework as a model, we can see that tactics, techniques, and procedures (TTPs) used by adversaries

1 Cyentia Institute: https://www.cyentia.com/wp-content/uploads/2024/07/EPSS-Exploration Of-Exploits.pdf 2 Forum of Incident Response and Security Teams: https://www.first.org/epss/data\_stats 3 Qualys TruRisk Research Report 2023: https://www.qualys.com/forms/tru-research-report/![][image3]
are most mapped to controls in the SI, SC, and AC control families. Yet, POA&Ms narrowly focus on CVE management.

A CVSS-driven model has proven insufficient. It lacks business context, does not reflect real-world exploitability, and encourages activity without delivering a true security impact. Security should not be measured in the volume of closed tickets, but in risk reduced.

Today’s ConMon and POA&M processes are not just unproductive— they are often counterproductive. They divert critical security and remediation capacity away from high-impact activities such as secure-by-design, threat modeling, and control implementation. When teams are forced to remediate issues solely to satisfy compliance—despite clear evidence of negligible or no risk—it undermines the broader mission of hardening systems and software. To deliver meaningful security outcomes, organizations must reclaim time budgets currently consumed by checklist-driven reporting and reinvest them into efforts that actually reduce risk.

Where Do We Want To Go?

The goal of ConMon should be to eliminate or mitigate risk, not to simply drive down vulnerabilities that pose little risk to loss exposure. Agencies need adequate visibility into the overall security posture of a cloud service offering – CVEs are only part of the story. We encourage the FedRAMP 20X initiative to set a bold vision for risk management. Below is a possible model to do just that, which can be complimented through open APIs and standard reporting formats.

![][image4]
![][image5]A Call to Modernize ConMon Security posture is broader than vulnerability counts. FedRAMP should expand the POA&M and ConMon scope to require evidence of:

• Configuration management conformance (e.g., DISA STIGs, CIS Benchmarks)

• Security Content Automation Protocol (SCAP)4 and/or Cloud Security Posture Management (CSPM) capabilities to address hardening, configuration management, and asset management.

• Software security and test automation practices (e.g., NIST SSDF) • Application Security posture, because everything is software. • Software provenance and build system security (e.g. SLSA)5 • Policy mandate enforcement and asset discovery + intelligence • Contextual threat modeling using frameworks like MITRE ATT&CK

4 Security Content Automation Protocol: https://csrc.nist.gov/projects/security-content automation-protocol 5 Supply-chain Levels for Software Artifacts: https://slsa.dev/

![][image6]
• Improved communication on the disposition of vulnerabilities (e.g. Vulnerability-Exploitability eXchange (VEX))6

CSPs need flexibility to prioritize. This is not a call to lower the bar – but to raise it in ways that drive real security outcomes. Vulnerability management is only part of the puzzle.

From Output to Outcome

Tools like Qualys TruRisk provide a model for this shift. By combining CVSS with exploitability data (EPSS), threat intelligence, asset details, business criticality, and exposure context, TruRisk enables:

• Deprioritizing low-risk CVEs with high CVSS but no exploit path • Elevating real threats with low CVSS but high mission impact • POA&M export with risk justification based – not static - scores

TruRisk delivers defensible prioritization and unlocks security capacity for CSPs to do the work that makes a difference.

Recommendations

Qualys recommends a two-pronged approach to advance the objectives outlined in RFC-0008.

First, we support the FedRAMP PMO moving forward with policy updates that formally align to the intent of RFC-0008—shifting from a CVSS-driven model to one grounded in real-world risk prioritization.

Second, we propose that FedRAMP launch a pilot program—with participation from Qualys and other industry leaders—to:

6 Vulnerability-Exploitability eXchange:

https://www.ntia.gov/sites/default/files/publications/vex\_one-page\_summary\_0.pdf![][image7]
• Establish a minimum standard for risk operations management platforms that incorporate risk based scoring and remediation across multiple dimensions of technology risk – cloud, infrastructure, software;

• Define reporting formats such as Open Security Controls Assessment Language (OSCAL) and/or Open Cybersecurity Schema Framework (OCSF); and

• Define validation criteria for 3PAOs to assess both the technical capabilities and procedural integration of these platforms.

This model builds directly on FedRAMP’s current approach to vulnerability scanning, where CSPs retain flexibility in tool selection but are held accountable for capability. Just as 3PAOs validate that RA-5 compliant scanning tools meet technical and operational requirements, they should likewise validate risk-based platforms— such as Qualys TruRisk—against clearly defined standards. Extending this proven model to risk operations management is a logical and necessary evolution.

Conclusion

Qualys applauds the goals of FedRAMP 20x to make security productive again by evolving how we ConMon. Approaches, such as those in this response, allow security to reclaim their time, unlock capacity, and drive Secure by Design. We must stop patching what doesn’t matter and focus on mitigating what does. Incorporating risk based prioritization allows us to expand ConMon scope without creating the overhead that stops security efficiencies dead in their tracks. This will lead to safer systems, better outcomes, and more efficient use of government and CSP resources. Strategies like this provide verifiable broad-spectrum control with streamlined efficiencies and provable risk-based decision-making. Automation is

![][image8]
available today to report on these recommendations, ensuring we can measure, communicate, and eliminate cyber risk.

![][image9]
Appendix A: Demonstration of Alignment

We summarized RFC-0008 and aligned it against a CVSS-based

approach and Qualys TruRisk to demonstrate alignment and to set an expectation that all of what this RFC proposes is available today.

Criteria	CVSS (Traditional)	Qualys TruRisk	FedRAMP RFC-0008 Recommendation
Scoring Basis	Static formula based on vulnerability characteristics	Dynamic score combining CVSS, exploitability, asset exposure, compensating controls	Move to contextual scoring based on real world risk factors
Exploit Likelihood (EPSS)	Not considered	Integrated into scoring	Must factor EPSS or similar predictive models
In-the-Wild Exploits	Not included	Informed by multiple threat intelligence feeds	Must consider real-world exploitation evidence
Asset Criticality	Not included	Custom asset tagging and weighting (e.g., “crown jewel” assets)	Requires scoring that accounts for system or data criticality
Business Context	Not considered	Scoring adjusts based on asset function, owner, environment	Scoring must reflect business impact and mission relevance
Exposure / Reachability	Not included	Vulnerability risk adjusts if service is internet facing or isolated	Include exposure level in prioritization decisions
Support for Deprioritizing Low Risk CVEs	No (e.g., CVSS 9.8 must be remediated in 30 days)	Yes, e.g., CVSS 9.8 + no exploit + low exposure = low TruRisk	Supports deferral with justification based on low real-world risk
Elevating Low CVSS, High-Risk Issues	No (e.g., CVSS 4.3 not prioritized)	Yes, e.g., active exploit + high business impact = high TruRisk	Supports accelerating remediation if threat is real, regardless of CVSS
Reporting Format	Static severity-based	Dynamic dashboards, POA&M export, SLA tracking	Encourages automated, risk-based dashboards and evidence-driven POA&M
POA&M Flexibility	Limited — tied to CVSS score	Dependent on allowability	Timeline response to risk-based prioritization

[pete-gov]

Public comment received via email:

Outer pipes Cell padding

RFC-0005: Minimum Assessment Scope Standard
Current Language/ Section
Likely impact confidentiality, integrity, or availability of federal information
Handle federal information; and/or
RFC-0006: 20x Key Security Indicators
Current Language/ Section
Cloud Native Architecture
Identity and Access Management: Use a least-privileged, role-based, and just-in-time security model
Monitoring, Logging, and Auditing: Perform Infrastructure as Code (IaC) and configuration scanning
Third Party Information Resources: Obtain a Software Bill of Materials (SBOM) for third party commercial software components
RFC-0007: Significant Change Notification Standard
Current Language/ Section
The FedRAMP Significant Change Notification (SCN) Standard establishes standard requirements that cloud service providers MUST follow to maintain FedRAMP authorization when making significant changes to FedRAMP authorized cloud services.
If the significant change is an adaptive change, also: Providers MUST notify FedRAMP and agency customers within 14 calendar days AFTER making adaptive changes.
If the significant change is a transformative change, also: Providers MUST have a 3PAO review the scope and impact of the planned change BEFORE making significant changes; providers MUST NOT proceed with significant changes without 3PAO concurrence.
If the significant change is a transformative change, also: Providers MUST work with a 3PAO to develop a security assessment plan BEFORE making transformative changes.
If the significant change is a transformative change, also: Providers MUST discuss the planned change during two sequential monthly monitoring meetings BEFORE making transformative changes.
If the significant change is a transformative change, also: Providers MUST have a 3PAO begin assessment of the results no later than 1 calendar day AFTER making transformative changes; this assessment SHOULD be completed within 7 calendar days AFTER making transformative changes.
If the significant change is a transformative change, also: Providers SHOULD automatically OPT OUT agency customers of transformative changes where possible and appropriate
RFC-0008: Continuous Reporting Standard
Current Language/ Section
Mitigated Vulnerabilities - A list of mitigated vulnerabilities or vulnerability groups, broken down by estimated risk rating after mitigation, including at least the following
Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats. These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability.
Providers SHOULD mitigate vulnerability risk as quickly as possible. Providers SHOULD adjust vulnerability severity based on documented mitigation.
RFC-0009: Significant Change Notification Technical Assistance
Current Language/ Section
Is it an impact categorization change? Impact categorization changes are perhaps the simplest to identify in the current framework - if the intent of the change is to increase or decrease the FIPS 199 security categorization (impact level) of the entire system (such as from Low to Moderate or from High to Moderate) then it is an impact categorization change.
RFC-0010: FedRAMP Scope Interpretation Technical Assistance
Current Language/ Section
Social media and communications platforms used in accordance with agency social media policies
This technical assistance is designed for reasonable people to have reasonable discussions about FedRAMP applicability based on their specific use of a cloud service.
When FedRAMP Doesn’t Apply: The service is not an authoritative repository for federal information, and its unavailability would not result in the loss of federal information.
Out of Scope Detailed Example - AI search chatbot: An agency uses a public AI Chatbot search to troubleshoot technical issues with a video conferencing system. Search queries of public or non-sensitive federal information may be logged by the vendor, but not FOR the agency. Because no internal data is accessed or trained on, FedRAMP doesn’t apply

[pete-gov]

public comment received via email

1 Continuous Reporting At least the following Key Security Metrics MUST be included in continuous monitoring reports:

• Unmitigated Vulnerabilities
• Mitigated Vulnerabilities
• Incidents
• Significant Change Notifications
• Upcoming Milestones
• Overall Scan Coverage
• Detailed Component Scan Coverage Our understanding is that the intent behind the Continuous Reporting Standard is to begin a shift away from the government requiring CSPs to upload scan logs and create bespoke materials for only federal agencies. However, CSPs are already responsible for maintaining a POA&M based on their continuous monitoring activities. This standard appears to be additional reporting beyond what is already required via the POA&M process.

Further, these KSMs do not appear to align with the FedRAMP 20x KSIs. The FedRAMP PMO should consider re-visiting the POA&M process in the context of the Continuous Reporting Standard as it may be more efficient to add Key Security Metrics to the POA&M template. In addition, the FedRAMP PMO should consider aligning the KSMs with the 20x KSIs to ensure better awareness of gaps across Rev. 5 agency ATOs and 20x authorizations.
2 Application of the Continuous Reporting Standard Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats. These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability. Our understanding is that the PMO will no longer maintain a centralized repository for a CSP's FedRAMP-related artifacts. Does this indicate that individuals from the PMO would need access to every CSP's documentation repository? If so, how would that be managed? The FedRAMP PMO should clarifying expectations for making the Key Security Metrics available to agencies and FedRAMP.
3 Application of the Continuous Reporting Standard Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats. These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability.

Providers MUST update Key Security Metrics at least monthly.

Providers MUST keep Key Security Metrics available to agencies and FedRAMP for 24 months after initial reporting. The standard includes actions that CSPs are required to take. Will these requirements be built into an existing FedRAMP control / parameter? The FedRAMP PMO should consider clarifying how compliance with the standard would be enforced.
4 Application of the Continuous Reporting Standard Providers SHOULD mitigate vulnerability risk as quickly as possible. Providers SHOULD adjust vulnerability severity based on documented mitigation. Traditionally, risk adjustments have required CSPs to submit deviation requests to their sponsoring / partnering agency. Does this indicate that CSPs have the ability to lower the risk of a vulnerability with documented mitigations? The FedRAMP PMO should clarify the process to mitigate vulnerability risk as part of the continuous monitoring process.
5 Application of the Continuous Reporting Standard Providers, third-party assessment organizations, agencies, and FedRAMP SHOULD consider mitigated vulnerabilities at their mitigated risk rating. Providers MAY carry mitigated vulnerabilities beyond FedRAMP remediation windows for the original risk rating without penalty but MUST remediate such vulnerabilities once it is reasonable to do so.
The standard notes that CSPs should remediate vulnerabilities once it is reasonable to do so. This does not set expectations for vulnerability remediation as it's not clear what would be considered reasonable. The FedRAMP PMO should clarify the expectations for vulnerability remediation.
6 Application of the Continuous Reporting Standard Providers SHOULD NOT include validated false positives in security reporting to agencies and FedRAMP. Providers MUST maintain documented evidence for determinations of false positives for the duration of their existence. The standard does not clarify the validation process for false positives. Do false positives need to be validated by a third-party? Where should the false positive documentation be stored if not required to be included in security reporting to agencies and FedRAMP. Further, the POA&M template has a column for "False Positive". Will this column be removed if it's not required to report false positives to agencies and FedRAMP? The FedRAMP PMO should consider clarifying expectations around the validation and tracking of false positives.
7 Exceptions to the Continuous Monitoring Reporting Requirements Providers MAY be required to provide additional metrics beyond those identified above as a condition of a formal FedRAMP Corrective Action Plan or other agreements with federal agencies. The Corrective Action Plan was an escalation process used by the JAB. It's not clear if a Corrective Action Plan would apply to a CSO with an agency ATO. The FedRAMP PMO should consider clarifying the applicability of a Corrective Action Plan for agency authorizations.

[pete-gov]

public comments submitted via google form:

Outer pipes Cell padding

Ignyte platform	3PAO	A few considerations: • Monthly reporting cadence is appropriate, but consideration should be given to aligning with automated CI/CD pipelines. Allowing for GitOps or DevSecOps integration will reduce manual reporting fatigue and promote engineering-driven security ownership. • Human + Machine-readable formats are ideal—standardizing on JSON or OSCAL-based outputs (e.g., via NIST 800-53 Component Definitions or vulnerability POA&M schema) can enable automation pipelines. Mitigated Risk-Based Vulnerability Reporting Strongly agree that encouraging mitigated risk-based reporting is a positive direction. This reflects real-world operational risk more accurately than original severity alone. To support this change: • Recommend publishing a scoring rubric or example scenarios showing acceptable mitigation techniques (e.g., compensating controls like WAFs, network segmentation, exploit path reduction). • Include optional fields in reporting templates to show the rationale for adjusted risk scores (e.g., threat intelligence, vulnerability reachability analysis). Additional Data for Agency Risk Awareness Agencies may benefit from supplemental metrics such as: • Exploitability trends (e.g., Known Exploited Vulnerabilities per month). • Coverage gaps between inventory and scanning tools. • Mean Time to Mitigation (MTTM) or trend lines for aging vulnerabilities. • Integration with API-based dashboards (e.g., Power BI, Elastic, or custom security portals) could allow agencies to visualize Key Security Metrics over time. Suggested Support Materials To enable widespread adoption, the following artifacts should be prioritized: 1. GitHub-based open-source reference implementation using Terraform, AWS, Azure, or Kubernetes components mapped to KSM outputs. 2. JSON Schema definitions for each KSM metric and validation tools. 3. Sample CI/CD pipeline YAMLs (e.g., GitLab, GitHub Actions) demonstrating automated KSM generation, export, and visualization. 4. Maturity model or self-assessment guide for CSPs to evaluate readiness to adopt the Continuous Reporting Standard. Final Notes To further reinforce success: • Recommend tie-in with FedRAMP 20x and FedRAMP OSCAL adoption timelines. • Consider a phased rollout with voluntary participation before full enforcement. • Encourage shared services providers to publish anonymized aggregated metrics to promote industry benchmarking and transparency. Thank you again for leading this forward-looking shift in continuous monitoring.
Zoom Communications Inc.	Cloud Service Provider (CSP)	Zoom would intend to provide a agency and stakeholder dashboard within our secure GRC system that would at a minimum cover the Key Security Metrics outline in the 0008-continuous-reporting-standard document . Thereby presenting a continuous reporting capability on the compliance of our cloud offerings that exist under FedRAMP. Moving away from POAM and FIIW . raw scan data that was shared via max.gov. Then allow agencies to contact us directly with any concerns or questions	Continuous Reporting
Salesforce	Cloud Service Provider (CSP)	"Section: Continuous Reporting Text: ""Unmitigated Vulnerabilities:"" Comment: We'd like clarity on when a vulnerability moves from unmitigated to closed (and gets removed from reporting). We're proposing that this standard (or technical assistance) defines when a vulnerability is considered ""closed"", such as upon it disappearing from a re-scan or multiple re-scans. Additionally, we'd more broadly like to get clearer definitions on what ""mitigated"" vs. ""closed"" means in this context. Proposing that mitigated means risk is reduced (via deviation or risk adjustment) while closed means no longer appearing in scans."
Salesforce	Cloud Service Provider (CSP)	"Section: Continuous Reporting Text: ""Key Security Metrics MUST..."" Comment: We'd like to confirm the difference between ""Key Security Metrics"" and ""Key Security Indicators"", as they are similar but different. We're proposing that this standard (or technical assistance) defines the two and clarifies how they are different from each other. Additionally, metrics are measurable, but only 1.i. and 2.i are measurable here - the rest are not ""metrics"". Proposing to rename ""...Metrics"" to ""...Information"" or something similar."
Salesforce	Cloud Service Provider (CSP)	"Section: Continuous Reporting Text: ""...Total number of unmitigated items"" Comment: It sounds like each ""row"" in the list here (for unmitigated vulnerabilities) has a unique identifier of the CVE ID. If that's the case, that should be first in the list here (CVE ID), then this line item should be ""Total number of unmitigated vulnerabilities with this CVE ID"". In other words - are we asking for an overall number of unmitigated CVEs at the top of the report, then individual rows with information on ii-vii for each CVE ID, or are we asking for the number of instances of each unmitigated CVE as part of each row per CVE ID?"
Salesforce	Cloud Service Provider (CSP)	"Section: Continuous Reporting Text: ""...Original FedRAMP remediation window end date"" Comment: Is this referring to FedRAMP's Rev. 5 RA-5 remediation SLAs that each CSP's security plan currently references? Or is this referring to something else? Proposing that this is clarified here."
Salesforce	Cloud Service Provider (CSP)	"Section: Continuous Reporting Text: ""...Known Exploited Vulnerability status"" Comment: There are other signals that indicate if a vulnerability is being exploited by CISA KEV. Is this referring to those as well? If not, we are proposing that this is broadened to include EPSS, Threat Intel, etc."
Salesforce	Cloud Service Provider (CSP)	"Section: Continuous Reporting Text: ""Incidents - Information about any..."" Comment: We'd like Technical Assistance for this standard to include a definition on what CSPs should consider an incident to be. Proposing that the FISMA definition is used - ""An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies."""
Salesforce	Cloud Service Provider (CSP)	"Section: Continuous Reporting Text: ""Incidents - Information about any incident-related activities"" Comment: We'd like Technical Assistance for this standard to clarify what information needs to be provided - is this asking us to report the incident activity itself, or all of the CSP's actions related to the activity?"
Salesforce	Cloud Service Provider (CSP)	"Section: Continuous Reporting Text: ""Detailed Component Scan Coverage"" Comment: This seems like a subset of ""Overall Scan Coverage"". Proposing the information here gets folded into the previous line item."
Salesforce	Cloud Service Provider (CSP)	"Section: Application of the Continuous Reporting Standard Text: ""...similar human-readable and compatible machine-readable formats."" Comment: Proposing that machine-readable is more clearly spelled out. There may be confusion as to whether .csv files are considered machine-readable or not."
Salesforce	Cloud Service Provider (CSP)	"Section: Application of the Continuous Reporting Standard Text: ""These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability."" Comment: If 11. is kept, then proposing this line gets removed, as it may be redundant."
Salesforce	Cloud Service Provider (CSP)	"Section: Application of the Continuous Reporting Standard Text: ""Providers SHOULD update Key Security Metrics one week before monthly monitoring meetings"" Comment: In line with other standards and just as a general best practice, proposing ""one week"" gets converted to ""five business days"". This will better account for holidays."
Salesforce	Cloud Service Provider (CSP)	"Section: Application of the Continuous Reporting Standard Text: ""... protected with appropriate controls to ensure agencies and FedRAMP..."" Comment: Based on the new Minimum Assessment Scope Standard, is Continuous Reporting information considered in-scope? Proposing that the technical assistance for either standard clarifies this."
Salesforce	Cloud Service Provider (CSP)	"Section: Application of the Continuous Reporting Standard Text: ""Providers SHOULD NOT include validated false positives in security reporting to agencies and FedRAMP."" Comment: Does this mean that CSPs do not need to get False Positives approved by Authorizing Officials? Proposing that this is clarified."
Netskope	Cloud Service Provider (CSP)	A list of unmitigated vulnerabilities or vulnerability groupings - can we explain what the difference between these are? It seems the POA&M is being replaced, but not sure. Continuous Reporting - 1. Unmitigated Vulnerabilities is the POA&M being replaced? When it says unmitigated items, this means non risk adjusted, correct? Why is the original detection date not included? Is a full list of unique CVEs listed with a tracking number (I assume this replaces the POA&M) 4. Component or services impacted replaces IP addresses, correct? Original FedRAMP remediation window end date is this based on the CVSS scoring and original detection date? Is there a recommended method or form to communicate all of the requested information It seems that FedRAMP is doing away with risk management deficiency triggers which is a refreshing change. The direction is Providers SHOULD make Key Security Metrics available within their standard customer portals. However, this is not required. What say does the Agency have here? Exceptions - FedRAMP Corrective Action Plan is mentioned? What are the conditions to receive one of these?	Application of the Continuous Reporting Standard, Exceptions to the Continuous Monitoring Reporting Requirements
Cloudflare	Cloud Service Provider (CSP)	-In agreement that adjusting risk rating according to mitigation techniques is a step in the right direction -Identify example acceptable mitigation techniques or guidance on risk adjustment approaches would be helpful -Include field in reporting templates for documenting mitigation techniques that allow for adjusted risk ratings -Include 'vulnerability reach' as a metric to determine the adjusted risk rating and the urgency of mitigation -Consider other risk rating scales, including EPSS in addition to KEV to determine accurate risk rating -Define vulnerability group use cases and the process to group vulns -"Detailed Component Scan Coverage" is noted as a required metric but implementing and managing this in a dynamic environment is complicated and not a useful monitoring metric -Providing machine readable versions of each metric could prove difficult. Is there an exception process if the CSP is unable to provide metrics in machine readable format? -Clarify bullet #8 regarding False Positives - If a vulnerability is reported and later identified as a false positive, is the recommendation to completely remove it from existing reporting? Or note it as a validated FP for historical reference.
Public	Private Sector - Other	None.	None.
AWS	Cloud Service Provider (CSP)	AWS Sentiment We support the overarching goal of making continuous monitoring more consistent, reusable, and data-driven. However, we recommend refinements to several proposed reporting elements to ensure they align with existing FedRAMP mechanisms, avoid unnecessary operational burdens, and scale effectively across cloud service environments. Additionally, several elements require clearer definitions to avoid inconsistent interpretations and ensure practical implementation. 1. Clarity and Scope of Key Security Metrics Definitions Key metrics—such as Unmitigated Vulnerabilities require clearer definition. For example, it is unclear whether “unmitigated vulnerabilities” includes all vulnerabilities or only those past SLA. Do the legacy patching SLA’s still exist if this reporting standard is approved? If the SLA’s continue to apply, we recommend that an unmitigated vulnerability is defined as a security vulnerability that meets either of these conditions: 1. Has not been remediated within FedRAMP required SLAs 2. Lacks an approved Deviation Request that documents alternative or compensating measures. We also recommend that metrics are reported as percentage of unmitigated vulnerabilities per component type = (Number of unmitigated vulnerabilities for a component type / Total number of components of that type) × 100. Defining these elements clearly will reduce interpretive variability and support consistent implementation across providers. 2. Little applied security value from tracking mitigated vulnerabilities Recommend not requiring tracking of mitigated vulnerabilities. The operational and resource costs of maintaining mitigated vulnerability records create an unsustainable burden that potentially diminishes overall security effectiveness: Complex Documentation Requirements: Each mitigated vulnerability requires tracking 10 distinct data points This information must be maintained indefinitely unless its considered a KSI which must be kept for 24 months. Monthly updates are required Both human-readable and machine-readable formats must be maintained Resource Allocation Impact: Security teams must divide attention between current threats and historical documentation Resources spent on maintaining historical records could be redirected to: Active threat hunting Real-time vulnerability management Current security improvements Proactive security measures Diminishing Returns: The value of historical mitigation data decreases over time The 24-month retention requirement means maintaining potentially outdated information Systems and threats evolve rapidly, making historical mitigation strategies less relevant 3. Monthly Monitoring Meetings Recommend changing Application of the Continuous Reporting Standard, paragraph 4 to substitute “monthly monitoring meetings” with “disseminating monthly reports”. AWS has implemented a continuous monitoring report on an approximately monthly cadence since December. While formal monitoring meetings are not currently held, a draft version is shared with DoD stakeholders for review and then posted to CapLinked for broader federal access. FedRAMP should allow for a similar approach across CSPs by: Defining a standardized monthly report format Requiring reports to be made available at least one week in advance of oversight activities Posting reports to a ConMon platform accessible to all federal customers. It is also important to clarify whether these expectations introduce changes to existing SLAs, such as those for vulnerability or POA&M reporting. Clear expectations for cadence, format, and delivery method will help ensure the reporting standard is scalable and sustainable across cloud environments of varying size and complexity.
CSP-AB	Cloud Service Provider (CSP)	Regarding "unmitigated vulnerabilities", it is unclear if this includes operational limitations or vendor dependencies (e.g. 3rd-party patching delays). We proposed the following wording: "Unmitigated Vulnerabilities - A list of unmitigated vulnerabilities or vulnerability groupings, including those pending resolution due to operational constraints or vendor dependencies..." Regarding "mitigated vulnerabilities", we believe it should be clearer that this refers specifically to adjusted risk ratings, not full remediation. Regarding "Application of the Continuous Reporting Standard" point 6 - we propose updating "mitigation" to "risk adjustment".	Included above.
EY	Private Sector - Other	General Support The proposed approach to disclose unresolved high-risk vulnerabilities after missed remediation deadlines introduces valuable accountability and aims to protect federal data and missions. Transparency, when balanced correctly with operational security, is essential for the federal cloud ecosystem. Recommendation: Model Disclosure After CISA’s CDM Program The FedRAMP program should consider aligning their vulnerability reporting framework with principles from CISA’s Continuous Diagnostics and Mitigation (CDM) program. CDM fosters shared situational awareness across federal agencies without compromising the operational security of cloud service providers (CSPs). CDM’s dashboards and scoring mechanisms allow agencies to prioritize remediation based on criticality and system context. A similar tiered disclosure or notification model could be implemented within FedRAMP. For example: • Internal alerts could be prioritized for authorizing officials and agency security teams. • Non-public interagency dashboards could highlight high-risk vulnerabilities and affected CSPs, without full public exposure. • Public disclosures should only occur in cases where the vulnerability poses an immediate and substantial risk, and only after all other remediation and coordination channels are exhausted. Security and Market Considerations While timely vulnerability remediation is essential, public disclosure of unresolved vulnerabilities may unintentionally expose CSPs to adversarial exploitation. Many CSPs deliver complex, multi-tenant SaaS platforms where zero-day remediation may require more than a 30-day window to deploy the appropriate fix. Therefore, the FedRAMP program should consider: • Incorporating context-aware timelines for certain classes of vulnerabilities (e.g., supply chain, third-party dependencies). • Establishing a formal appeals or exemption process for valid remediation delays that do not significantly raise operational risk. • Ensuring any shared information is protected under appropriate federal information sharing agreements to prevent its misuse or weaponization. Conclusion FedRAMP’s intent to improve system security through transparency is commendable. However, the implementation should build upon proven practices from CISA’s CDM program and include risk-adjusted safeguards to avoid unintended harm to cloud providers or disruption to government operations. Thank you again for the opportunity to contribute. We look forward to seeing a finalized policy that achieves both improved visibility and sustained security for all FedRAMP-authorized systems.
Coalfire	3PAO	---Continuous Reporting section --- Significant Change Notification (4): We recommend adding a requirement for CSPs to identify new assets added due to significant changes for agencies and others to quickly identify net new assets that could impact security for review and evaluation. Overall Scan Coverage (6): What is an acceptable level of scan coverage per month? 100% of the inventory? 90%? 75%? ---Application of the Continuous Reporting Standard section --- 6-7: Does this mean CSPs can start leveraging the CVSS temporal or environmental scoring as rationale for vulnerability mitigations? ---General questions--- Will the Continuous Monitoring Performance Management Guide remain? Or are there plans to release a new version to better align with this new Reporting Standard? While the Key Security Metrics outlined required information, ideally a required template for human-readable and machine-readable formats would ensure consistency for agency and other stakeholder review and evaluation. Maybe provide a required format with optional/custom fields to provide consistency with flexibility.	Continuous Reporting (4,6); Application of the Continuous Reporting Standard (6,7)
CSP-AB	Cloud Service Provider (CSP)	Section: Incidents - Information about any incident-related activities in the past reporting period or past 30 days (whichever is longer). AND Significant Change Notifications - Information about any Significant Change Notifications in the past reporting period or past 30 calendar days (whichever is longer). Comment: What information about incidents and Significant changes need to be present in the ConMon Reporting? It is important for CSPs to understand the minimum information needed when looking at automation. The sources for these activities might not be easily automatable. Section: Upcoming Milestones - Information about any upcoming planned service milestones and third-party assessment activities within the next 60 calendar days that are not included in Significant Change Notifications. Comment: Please define a service milestone and the depth to which they need to reported. Section: Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats. These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability. Comment: Who decides what machine readable formats are compatible? Will each individual agency have a format that they support? Will the PMO provide a template so tha tools can be developed to meet the requirements for both machine and human readable formats? Section: Providers MAY make Key Security Metrics available to other customers or the public if they determine doing so will not have a likely impact on the confidentiality, integrity, or availability of federal information. Comment: Does FedRAMP PMO consider public disclosure of vulnerabilities as likely to impact to federal information systems? By nature of the business CSPs do have to send vulnerability information and information about incidents to stakeholders outside the federal government. Is there a difference between sharing with customers and auditors and generally vulnerability disclosure programs? Section: Providers MAY be required to provide additional metrics beyond those identified above as a condition of a formal FedRAMP Corrective Action Plan or other agreements with federal agencies. Comment: This states that there are more formal "FedRAMP" CAPs. Are there documented triggers and process for defining mitigation plans and authority for release from CAPs? Section: Total number of unmitigated items. Comment: Please define "items" here. Is it each instance? For partially mitigated vulnerabilities how should progress be measured and communicated? If the original detection was 1000 instances and 500 have been mitigated how should this be communicated if at all? This relates to the comment below about how to count services and components. Since reporting needs to be automated and machine readable there has to be some binary way to identify issues, map them to the appropriate assets and how to show progress to customers. Section: Impacted service or component Comment: Does a single vulnerability make a service or component "impacted"? If a single ID is seen across several components or services how should it be noted so that customers can see which services are impacted? For instance if there are 100 instances of a vulnerability should the reporting be 25/100 are associated with a certain while 75/100 are associated with another service?	Included above.
CGI Federal	Cloud Service Provider (CSP)	The reporting requirements are reasonable overall and the majority apply to current requirements. In the case of reporting, it could be beneficial to limit flexibility and create standardized reporting that can be more easily automated and consumed. Maintaining a mandatory FedRAMP template for the Continuous Monitoring deliverables provides the standard format and minimum reporting requirements across all providers. Flexibility in reporting may result in agencies needing to analyze various report formats or CSOs being required to provide customized formats to individual clients. - Recommend updating the current POA&M template and/or One-Pager template to align with new standard and change bullet #1 of Application of Continuous Reporting Standard section to state providers MUST use standard template to enforce consistency across FedRAMP program. - Bullet #1 of Application of Continuous Reporting Standard section states providers MUST make metrics available in human-readable and machine-readable formats. Please provide clarification on when machine-readable formats beyond CSV files will be required to meet standards. - Please identify the acceptable machine-readable formats as part of the standard to create consistency across all CSOs allowing both providers and consumers to more easily implement automation of processes throughout application portfolios. If included in FedRAMP best practices and technical assistance will fall under the SHOULD statement. - Recommend standardizing reporting cadence in bullet #2 of Application of Continuous Reporting Standard section to monthly vice “at-least monthly”. This flexibility will create various requirements/expectations from agencies - Recommend changing bullet #5 of Application of Continuous Reporting Standard section to a MUST statement. This is a reasonable requirement that provides visibility of current risk profile to agencies. Tracking and reporting mitigated vulnerabilities at the adjusted risk rating is a step in the right direction. This allows for a single risk rating to be used in a single column vice possibility of missing adjusted rating since that requires scrolling across a complex spreadsheet. - Please specify if mitigated vulnerability listing only applies to vulnerabilities with a risk adjusted deviation request previously identified in the unmitigated list vice vulnerabilities corrected during routine patching or corrected during standard timeframe (30, 90, 180 days) - Please specify if mitigated vulnerabilities are intended to be a running list and for how long they should be reported The unmitigated vulnerabilities reporting standard identifies reasonable and appropriate metrics to be included. - Please specify if this list includes all unmitigated vulnerabilities or only those that are past due or include a deviation request. Limiting to past due and deviation request vulnerabilities aligns with current POA&M guidance and provides a more concise view of risk posture. Including vulnerabilities that will be corrected as part of normal patching schedule does not add value to the report. - Recommend considering ways to reduce reporting requirements. Several widely used industry products no longer prioritize correction of moderate or low findings due to cost and time constraints. Additionally, FedRAMP does not have a trigger associated with low findings. Recommend eliminating requirement to report and mitigate low findings or establishing a new minimum CVSS score that constitutes a reportable finding. This would reduce effort and cost for both CSP and agencies. - Recommend ability for CSPs to suspend continuous monitoring activities while remaining in an authorized status if not actively hosting a client. The CSPs being authorized via pilot programs may experience a significant period of time before onboarding a new client. Currently authorized CSPs may also have periods between contracted agencies. Continuous monitoring during those periods creates significant costs to CSPs and removal from marketplace reduces ability for agencies to rapidly leverage products. Regarding overall scan coverage and detailed component scan coverage, the current FedRAMP inventory report template is intended to provide a comprehensive list of all components in environment along with an indication of whether the specific device has been scanned for the current monthly report. Recommend updating the current inventory template to include new standard requirements. If this or other requirements are intended only for automated machine-readable reports, please specify since current Rev 5 authorizations do not have requirement for automated testing.

[pete-gov]

Commments received via email from Schellman:

Comment #	Section	Quote	Comment	Recommendation
1	Continuous Reporting	At least the following Key Security Metrics MUST be included in continuous monitoring reports: - Unmitigated Vulnerabilities - Mitigated Vulnerabilities - Incidents - Significant Change Notifications - Upcoming Milestones - Overall Scan Coverage - Detailed Component Scan Coverage	Our understanding is that the intent behind the Continuous Reporting Standard is to begin a shift away from the government requiring CSPs to upload scan logs and create bespoke materials for only federal agencies. However, CSPs are already responsible for maintaining a POA&M based on their continuous monitoring activities. This standard appears to be additional reporting beyond what is already required via the POA&M process. Further, these KSMs do not appear to align with the FedRAMP 20x KSIs.	The FedRAMP PMO should consider re-visiting the POA&M process in the context of the Continuous Reporting Standard as it may be more efficient to add Key Security Metrics to the POA&M template. In addition, the FedRAMP PMO should consider aligning the KSMs with the 20x KSIs to ensure better awareness of gaps across Rev. 5 agency ATOs and 20x authorizations.
2	Application of the Continuous Reporting Standard	Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats. These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability.	Our understanding is that the PMO will no longer maintain a centralized repository for a CSP's FedRAMP-related artifacts. Does this indicate that individuals from the PMO would need access to every CSP's documentation repository? If so, how would that be managed?	The FedRAMP PMO should clarifying expectations for making the Key Security Metrics available to agencies and FedRAMP.
3	Application of the Continuous Reporting Standard	Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats. These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability. Providers MUST update Key Security Metrics at least monthly. Providers MUST keep Key Security Metrics available to agencies and FedRAMP for 24 months after initial reporting.	The standard includes actions that CSPs are required to take. Will these requirements be built into an existing FedRAMP control / parameter?	The FedRAMP PMO should consider clarifying how compliance with the standard would be enforced.
4	Application of the Continuous Reporting Standard	Providers SHOULD mitigate vulnerability risk as quickly as possible. Providers SHOULD adjust vulnerability severity based on documented mitigation.	Traditionally, risk adjustments have required CSPs to submit deviation requests to their sponsoring / partnering agency. Does this indicate that CSPs have the ability to lower the risk of a vulnerability with documented mitigations?	The FedRAMP PMO should clarify the process to mitigate vulnerability risk as part of the continuous monitoring process.
5	Application of the Continuous Reporting Standard	Providers, third-party assessment organizations, agencies, and FedRAMP SHOULD consider mitigated vulnerabilities at their mitigated risk rating. Providers MAY carry mitigated vulnerabilities beyond FedRAMP remediation windows for the original risk rating without penalty but MUST remediate such vulnerabilities once it is reasonable to do so.	The standard notes that CSPs should remediate vulnerabilities once it is reasonable to do so. This does not set expectations for vulnerability remediation as it's not clear what would be considered reasonable.	The FedRAMP PMO should clarify the expectations for vulnerability remediation.
6	Application of the Continuous Reporting Standard	Providers SHOULD NOT include validated false positives in security reporting to agencies and FedRAMP. Providers MUST maintain documented evidence for determinations of false positives for the duration of their existence.	The standard does not clarify the validation process for false positives. Do false positives need to be validated by a third-party? Where should the false positive documentation be stored if not required to be included in security reporting to agencies and FedRAMP. Further, the POA&M template has a column for "False Positive". Will this column be removed if it's not required to report false positives to agencies and FedRAMP?	The FedRAMP PMO should consider clarifying expectations around the validation and tracking of false positives.
7	Exceptions to the Continuous Monitoring Reporting Requirements	Providers MAY be required to provide additional metrics beyond those identified above as a condition of a formal FedRAMP Corrective Action Plan or other agreements with federal agencies.	The Corrective Action Plan was an escalation process used by the JAB. It's not clear if a Corrective Action Plan would apply to a CSO with an agency ATO.	The FedRAMP PMO should consider clarifying the applicability of a Corrective Action Plan for agency authorizations.

[pete-gov]

comments received from microsoft via email:

Current Language/ Section	Proposed Language/Comment
Mitigated Vulnerabilities - A list of mitigated vulnerabilities or vulnerability groups, broken down by estimated risk rating after mitigation, including at least the following	Suggest just changing the title to "Risk Adjusted Vulnerabilities"
Providers MUST make Key Security Metrics available to agencies and FedRAMP in similar human-readable and compatible machine-readable formats. These formats SHOULD follow FedRAMP best practices and technical assistance to ensure maximum reusability.	We would like FedRAMP to provide a "suggested template" for reference.
Providers SHOULD mitigate vulnerability risk as quickly as possible. Providers SHOULD adjust vulnerability severity based on documented mitigation.	We propose updating "mitigation" to "risk adjustment".