RFC-0030 FedRAMP Rev5 Security Controls Baseline Update for RA, SA, SC, SI, and SR Control Families

[rhoesing]

RFC-0030 FedRAMP Rev5 Security Controls Baseline Update for RA, SA, SC, SI, and SR Control Families

❓ Please note that FedRAMP will not answer questions in this thread as it is reserved for public comment. If you would like to ask a question or generally discuss this RFC informally, please use the General discussion and Q&A for RFCs related to Rev5 Updates (RFCs 0026, 0027, 0028, 0029, & 0030) thread. Thank you!

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

Summary

This is a technical RFC that proposes updates to the Additional FedRAMP Security Technical Controls Requirements and Guidance for FedRAMP Rev5 baselines.

To save space and to limit the breadth of a single RFC, this technical document shows only the proposed changes to the current baseline document and is restricted to a few control families. If verbiage is being updated, only the specific wording that is to be changed is identified in the old verbiage section. If the verbiage to be added is not replacing previous verbiage, but being added, it will be identified as “NEW” in the old verbiage section.

Since this spreadsheet covers hundreds of controls across multiple tabs and sections, only those specific controls, sections, and tabs identified are being proposed for updates. If it is not mentioned below, changes are not being proposed.

Commenters are advised to please mention specific controls in their comments!

This RFC addresses controls in the following families:

• Risk Assessment (RA)
• System and Service Acquisition (SA)
• System and Communications Protection (SC)
• System and Information Integrity (SI)
• Supply Chain Risk Management (SR)

Motivation

Many Rev5 FedRAMP Requirements and Guidance statements are based on outdated approaches that predated the release of the FedRAMP Authorization Act and M-24-15. This set of Requirements and Guidance needs a refresh to match FedRAMP’s current rules and approach.

The updates formalized after this RFC will be included in the FedRAMP Consolidated Rules for 2026. That set of rules will be valid until December 31, 2028. FedRAMP will provide a transition plan for adopting any new guidance that will enable cloud service providers to update their approach as part of their annual assessment as appropriate.

These changes are designed to lower the burden for cloud service providers and eliminate previous pain points.

Additionally, NIST released 800-53 Rev 5.2.0 in August of 2025. While this update was minor, control updates from NIST will require updates to FedRAMP Security Control Baseline in order to reflect this update. These changes will happen without public comment through FedRAMP since these are direct reflections of NIST changes. As subsequent iterations of the FedRAMP Security Control Baseline are published, it is FedRAMP’s intent only to carry over the following information from NIST 800-53: Control Family, Control Name, and Control ID. Following this will be FedRAMP-Defined Assignment / Selection Parameters and additional FedRAMP Requirements and Guidance.

Proposed Changes to Risk Assessment Family

This section contains proposed changes to the FedRAMP Requirements and Guidance section for each of these controls.

RA-05: Vulnerability Monitoring and Scanning

Tabs Affected: High Baseline, Moderate Baseline, Low Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: RA-5 (a) [monthly operating system/infrastructure; monthly web applications (including APIs) and databases]
RA-5 (d) [high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low-risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery]
Proposed Change: RA-5 (a) [monthly operating system/infrastructure; monthly web applications (including APIs) and databases for traditional Rev 5 processes] [For those opting into the Vulnerability Detection and Response:

Low Systems
Providers SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once every 7 days.
Providers SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every month.
Providers SHOULD evaluate ALL vulnerabilities as required by VDR-TFR-EVU (Evaluation) within 7 days of detection.

Moderate
Providers SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once every 3 days.
Providers SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every 14 days.
Providers SHOULD evaluate ALL vulnerabilities as required by VDR-TFR-EVU (Evaluation) within 5 days of detection.

High
Providers SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once per day.
Providers SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every 7 days.
Providers SHOULD evaluate ALL vulnerabilities as required by VDR-TFR-EVU (Evaluation) within 2 days of detection.]

RA-5 (d) [high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low-risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery for traditional Rev 5 processes] [For those opting into the Vulnerability Detection and Response mitigation timelines requirements are laid out in section VDR-TFR-PVR and are based on a combination of impact categorization, potential for impact, internet reachability, and likely exploitability].
Rationale: Updated based on BIRs.

RA-05: Vulnerability Monitoring and Scanning

Tabs Affected: High Baseline, Moderate Baseline, Low Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: RA-5 Guidance: See the vulnerability scanning requirements defined in the FedRAMP Continuous Monitoring Playbook.
RA-5 (a) Requirement: an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
RA-5 (d) Requirement: If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
RA-5 (e) Requirement: to include all Authorizing Officials.
RA-5 Guidance: Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity, and for FedRAMP, does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any Significant Change Request or SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, the false positive is captured as a deviation request in the POA&M.
Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a “warning” as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs.
Proposed Change: RA-5 Guidance: See the vulnerability scanning requirements defined in the FedRAMP Continuous Monitoring Playbook for traditional Rev5 pathway. For those who have opted into the Vulnerability Detection and Response BIR, please see Vulnerability Detection and Response Guidance. Evaluation criteria is drastically different for Service Providers who opted into the BIR and should pay close attention to evaluation factors listed in section VDR-EVA-EFA of the Vulnerability Detection and Response Guidance.
RA-5 (a) Requirement: an accredited independent assessor scans operating systems/infrastructure, web applications, and databases once annually.
RA-5 (d) Requirement: If a vulnerability is listed among the CISA Known Exploited Vulnerability (KEV) Catalog (https://www.cisa.gov/known-exploited-vulnerabilities-catalog) the KEV remediation date supersedes the FedRAMP parameter requirement.
RA-5 (e) Requirement: to include all Authorizing Officials.
RA-5 Guidance: Informational findings from a scanner are detailed as a returned result that holds no vulnerability risk or severity and for FedRAMP does not require an entry onto the POA&M or entry onto the RET during any assessment phase.
Warning findings, on the other hand, are given a risk rating (low, moderate, high or critical) by the scanning solution and should be treated like any other finding with a risk or severity rating for tracking purposes onto either the POA&M or RET depending on when the findings originated (during assessments or during monthly continuous monitoring). If a warning is received during scanning, but further validation turns up no actual issue then this item should be categorized as a false positive. If this situation presents itself during an assessment phase (initial assessment, annual assessment or any SCR), follow guidance on how to report false positives in the Security Assessment Report (SAR). If this situation happens during monthly continuous monitoring, the false positive is captured as a deviation request in the POA&M.
Warnings are commonly associated with scanning solutions that also perform compliance scans, and if the scanner reports a “warning” as part of the compliance scanning of a CSO, follow guidance surrounding the tracking of compliance findings during either the assessment phases (initial assessment, annual assessment or any SCR) or monthly continuous monitoring as it applies. Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs.
Rationale: Updated based on BIRs.

RA-05: Vulnerability Monitoring and Scanning

Tabs Affected: High Baseline, Moderate Baseline, Low Baseline
Sections Affected: Continuous Monitoring Periodicity
Current Verbiage: RA-5 (a) [monthly operating system/infrastructure; monthly web applications (including APIs) and databases]
RA-5 (d) [high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low-risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery].
Proposed Change: RA-5 (a) [monthly operating system/infrastructure; monthly web applications (including APIs) and databases for traditional Rev 5 processes] [For those opting into the Vulnerability Detection and Response:

Low Systems
Providers SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once every 7 days.
Providers SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every month.
Providers SHOULD evaluate ALL vulnerabilities as required by VDR-TFR-EVU (Evaluation) within 7 days of detection.

Moderate Systems
Providers SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once every 3 days.
Providers SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every 14 days.
Providers SHOULD evaluate ALL vulnerabilities as required by VDR-TFR-EVU (Evaluation) within 5 days of detection.

High Systems
Providers SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once per day.
Providers SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every 7 days.
Providers SHOULD evaluate ALL vulnerabilities as required by VDR-TFR-EVU (Evaluation) within 2 days of detection.]

RA-5 (d) [high-risk vulnerabilities mitigated within thirty (30) days from date of discovery; moderate-risk vulnerabilities mitigated within ninety (90) days from date of discovery; low risk vulnerabilities mitigated within one hundred and eighty (180) days from date of discovery for traditional Rev 5 processes] [For those opting into the Vulnerability Detection and Response mitigation timelines requirements are laid out in section VDR-TFR-PVR and are based on a combination of impact categorization, potential for impact, internet reachability, and likely exploitability].
Rationale: Updated based on BIRs.

Proposed Changes to Systems and Services Acquisition Family

This section contains proposed changes to the FedRAMP Requirements and Guidance section for each of these controls.

SA-04(5): Acquisition Process | System, Component, and Service Configurations

Tabs Affected: High Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: SA-4 (5) (a) The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available.
Proposed Change: SA-4 (5) (a) The service provider shall use the DoD STIGs to establish configuration settings; Center for Internet Security up to Level 2 (CIS Level 2) guidelines shall be used if STIGs are not available; Custom baselines shall be used if CIS is not available and must be documented and validated during independent assessment.
Rationale: Updated to ensure custom baselines are documented and reviewed.

SA-05: System Documentation

Tabs Affected: High Baseline, Moderate Baseline, Low Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: NEW
Proposed Change: a. (1) in conjunction with the FedRAMP Security Configuration Guidance
Rationale: Updated based on SCG requirements.

SA-15: Development Process, Standards, and Tools

Tabs Affected: High Baseline, Moderate Baseline
Sections Affected: High Baseline, Moderate Baseline
Current Verbiage: SA-15 (b)-2 [FedRAMP Security Authorization requirements]
Proposed Change: SA-15 (b)-2 [FedRAMP Security Authorization/Certification requirements]
Rationale: Updated to reflection transition to a certification authority.

Proposed Changes to Systems and Communications Protection Family

This section contains proposed changes to the FedRAMP Requirements and Guidance section for each of these controls.

SC-07(5): Boundary Protection | Deny by Default — Allow by Exception

Tabs Affected: High Baseline, Moderate Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: SC-7 (5) [any systems]
Proposed Change: SC-7 (5) [all systems/services]
Rationale: More inclusive of cloud design.

SC-07(8): Boundary Protection | Route Traffic to Authenticated Proxy Servers

Tabs Affected: High Baseline, Moderate Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: SC-7 (8)-2 [any network outside of organizational control and any network outside the authorization boundary].
Proposed Change: SC-7 (8)-2 [any network outside of organizational control and any network outside of assessment scope (for those following MAS BIR), or established boundary (for those following traditional Rev 5).
Rationale: Take into account MAS.

SC-13: Cryptographic Protections

Tabs Affected: High Baseline, Moderate Baseline, Low Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: New
Proposed Change: For Cryptographic Modules list as "historical" in the CMVP database, please ensure Service Providers follow FedRAMP instructions here: https://www.fedramp.gov/archive/2022-12-22-crypto-modules-historical-status/
Rationale: This update was added to address a common issue seen during the authorization/certification process.

Proposed Changes to Systems and Information Integrity Family

This section contains proposed changes to the FedRAMP Requirements and Guidance section for each of these controls.

SI-02(2): Flaw Remediation | Automated Flaw Remediation Status

Tabs Affected: High Baseline, Moderate Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: SI-2 (2)-2 [at least monthly]
Proposed Change: SI-2 (2)-2 [at least monthly for those CSPs following traditional Rev 5 processes] [persistently for those CSPs participating in VDR BIR].
Rationale: Updated based on VDR requirements.

SI-03: Malicious Code Protection

Tabs Affected: High Baseline, Moderate Baseline, Low Baseline
Sections Affected: FedRAMP-Defined Assignment / Selection Parameters
Current Verbiage: SI-3 (c) (1)-1 [at least weekly]
Proposed Change: SI-3 (c) (1)-1 [at least weekly for those CSPs following traditional Rev 5 processes] [persistently for those CSPs participating in VDR BIR].
Rationale: Updated based on VDR requirements.

SI-05: Security Alerts, Advisories, and Directives

Tabs Affected: Low Baseline, Moderate Baseline, High Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: SI-5 Requirement: Service Providers must address the CISA Emergency and Binding Operational Directives applicable to their cloud service offering per FedRAMP guidance.This includes listing the applicable directives and stating compliance status.
Proposed Change: SI-5 Requirement: Service Providers must address the CISA Emergency Directives (EDs) and Binding Operational Directives (BODs) applicable to their cloud service offering per FedRAMP guidance. This includes listing the applicable directives and stating compliance status. EDs and BODs can be found here: https://www.cisa.gov/news-events/directives
EDs and BODs responses will be coordinated through the FedRAMP Secure Inbox (FSI) process. Service Providers are required to follow all response timelines in accordance with FSI guidance.
Rationale: Updated to reflect FSI process.

SI-08: Spam Protection

Tabs Affected: Moderate Baseline, High Baseline
Sections Affected: Additional FedRAMP Requirements and Guidance
Current Verbiage: SI-8 Guidance:
When CSO sends email on behalf of the government as part of the business offering, Control Description should include implementation of Domain-based Message Authentication, Reporting & Conformance (DMARC) on the sending domain for outgoing messages as described in DHS Binding Operational Directive (BOD) 18-01.
https://cyber.dhs.gov/bod/18-01/
SI-8 Guidance: CSPs should confirm DMARC configuration (where appropriate) to ensure that policy=reject and the rua parameter includes reports@dmarc.cyber.dhs.gov. DMARC compliance should be documented in the SI-08 control implementation solution description, and list the FROM: domain(s) that will be seen by email recipients.
Proposed Change: SI-8 Guidance:
When CSO sends email on behalf of the government as part of the business offering, Control Description should include implementation of Domain-based Message Authentication, Reporting & Conformance (DMARC) on the sending domain for outgoing messages as described in DHS Binding Operational Directive (BOD) 18-01.
https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security
SI-8 Guidance: CSPs should confirm DMARC configuration (where appropriate) to ensure that policy=reject and the rua parameter includes reports@dmarc.cyber.dhs.gov. DMARC compliance should be documented in the SI-08 control implementation solution description, and list the FROM: domain(s) that will be seen by email recipients.
Rationale: Updated old link.

Proposed Changes to Supply Chain Risk Management Family

No changes are being proposed

[jsbivens]

Editing issue: RFC 30 description and title don't match on FedRAMP.gov RFC page: https://fedramp.gov/rfcs

[paulagosta]

Thank you for the catch. While we don't normally comment here, this was a procedural/administrative issue and is in the process of being updated.

[jtpickering]

Editing issue
SA-15: Development Process, Standards, and Tools
Sections Affected:

• Current verbiage: High Baseline, Moderate Baseline
• Proposed verbiage: FedRAMP-Defined Assignment / Selection Parameters

[austinsonger]

1. Define key terms that affect compliance
   • “Persistently,” “representative samples,” “likely to drift,” and “evaluate” are high-impact terms. Consider concise definitions or pointers to the authoritative VDR sections so CSPs and 3PAOs don’t interpret them differently.
2. Minimize ambiguity for 3PAO testing
   • Where you introduce alternative constructs (e.g., “assessment scope” for MAS vs “established boundary” for traditional), add a short statement describing what evidence 3PAOs should use (e.g., inventory source of truth, sampling methodology, scan coverage proof, and evaluation SLA evidence).

[OG-of-the-realms]

This is already largely done here: https://www.fedramp.gov/docs/20x/fedramp-definitions/

https://www.fedramp.gov/docs/20x/fedramp-definitions/#persistently

https://www.fedramp.gov/docs/20x/fedramp-definitions/#drift

See also RFC 31 and FRD-RSP Responsibly

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

FedRAMP also uses common plain English definitions found in common English dictionaries.

[austinsonger]

RA-5 (Vulnerability Monitoring and Scanning)

What works

• Splitting traditional monthly scanning + 30/90/180 from VDR-based frequencies and VDR mitigation logic is helpful.

Suggestions

• Clarify what “representative samples of similar machine-based information resources” means operationally:
  • minimum sampling rate or statistical approach,
  • how “similar” is determined (e.g., image lineage, config profile, role, exposure),
  • how the CSP proves the sample remains representative as the environment changes.
• “Evaluate ALL vulnerabilities within X days of detection” is strong and useful, but it would help to specify whether “evaluate” means:
  • triage + impact determination,
  • exploitability/reachability determination,
  • assignment of remediation timeline category,
  • and/or documented acceptance/false-positive disposition.
• Confirm how KEV supersedence applies under VDR (i.e., does KEV always override VDR timelines, or is it incorporated into VDR’s categorization?).

SA-4(5) (Config baselines)

Suggestion

• Consider requiring documentation to include:
  • rationale for deviations from STIG/CIS,
  • mapping to control objectives,
  • and a repeatable validation method (so 3PAOs can assess consistently).

SA-5 (System Documentation)

Concern

• The proposed parameter “a. (1) in conjunction with the FedRAMP Security Configuration Guidance” is directionally good, but feels incomplete as written (it’s hard to implement or test as a standalone parameter).

Suggestion

• Consider explicitly stating what documentation artifacts are required “in conjunction with” SCG (e.g., configuration baseline artifacts, implementation evidence, or update cadence).

SA-15 (Authorization/Certification wording)

Suggestion

• Ensure consistent use across all baselines and templates to avoid mismatched language in SSP/SAR/POA&M narratives.

SC-7(5) (Deny by default—allow by exception)

Suggestion

• Consider explicitly acknowledging typical cloud constructs (“services,” managed control planes, serverless) so CSPs don’t get pushed into artificial “system” mappings.

SC-7(8) (Authenticated proxy routing) – MAS vs traditional

Suggestion

• The bracketed phrase appears to have an unmatched parenthesis in the proposed change; recommend tightening the grammar and explicitly defining what counts as:
  • “outside of assessment scope” under MAS, and
  • “outside the established boundary” under traditional,
    to reduce 3PAO interpretation risk.

SC-13 (Cryptographic modules in CMVP “historical” status)

Suggestion

• Add explicit expectations:
  • what evidence must be provided when a module becomes “historical,”
  • expected timelines or triggers for transition/remediation,
  • how FedRAMP will treat “historical” status during annual assessments vs significant changes.

SI-2(2), SI-3 (shift to “persistently” for VDR participants)

Suggestion

• Define the minimum acceptable evidence of “persistent” (e.g., continuous telemetry + alerting, near-real-time status reporting) so CSPs don’t overbuild and 3PAOs don’t under-test.

SI-5 (EDs/BODs via FedRAMP Secure Inbox)

Suggestion

• Add clarity on:
  • whether timelines are driven by the directive itself or FSI guidance (or both),
  • whether CSPs must maintain a standing ED/BOD tracker artifact and where it lives (SSP appendix vs ConMon deliverable).

SI-8 (DMARC link update)

Suggestion

• Consider a short note about scope:
  • applies when sending email “on behalf of the government,”
  • and whether subdomains / third-party senders used by the CSO must also meet policy=reject + reporting requirements.

[vedigaurav]

Gap #1 – Insufficient alignment with threat-informed defense practices
Issue: While RFC-0030 updates controls across RA, SA, SC, SI, and SR families, it does not explicitly incorporate threat-informed methodologies (e.g., adversary tactics or attack patterns) into risk assessment or control implementation expectations. This may limit the effectiveness of controls against evolving threats.
Recommendation: Integrate threat-informed guidance (e.g., mapping to adversary behaviors or attack frameworks) into RA and SI controls to ensure risk assessments and mitigations are grounded in real-world threat activity.

Gap #2 – Limited guidance on supply chain visibility and assurance depth
Issue: Updates to SR controls do not clearly define the expected depth of supply chain visibility (e.g., third-party vs. fourth-party dependencies), leading to inconsistent interpretations of responsibility.
Recommendation: Establish tiered expectations for supply chain risk management, including minimum requirements for visibility, monitoring, and assurance across different dependency levels.

Gap #3 – Lack of clarity on secure-by-design expectations in acquisition (SA)
Issue: The SA control updates emphasize security requirements but do not explicitly promote secure-by-design or secure-by-default principles during system acquisition and development.
Recommendation: Incorporate language requiring secure design principles (e.g., least privilege, default deny, resilience) to be embedded early in acquisition and development lifecycles.

Gap #4 – Ambiguity in boundary definition for system communications (SC)
Issue: The RFC does not sufficiently clarify how system boundaries should be defined in modern architectures (e.g., microservices, APIs, service meshes), which impacts the application of SC controls.
Recommendation: Provide updated boundary definition guidance and examples for cloud-native architectures to ensure consistent application of communications protection controls.

Gap #5 – Insufficient emphasis on data-centric security controls
Issue: The updates focus heavily on system and network protections but provide limited emphasis on protecting data itself (e.g., data classification, tagging, and flow tracking).
Recommendation: Expand SC and SI guidance to include data-centric security practices, ensuring protection persists regardless of infrastructure or location.

Gap #6 – Limited operational guidance for vulnerability and remediation timelines
Issue: SI control updates do not clearly define expectations for vulnerability remediation timelines or prioritization, which may lead to inconsistent risk responses across CSPs.
Recommendation: Introduce risk-based remediation timelines (e.g., tied to severity or exploitability) and require documented prioritization strategies.

Gap #7 – Lack of integration with DevSecOps pipelines
Issue: The RFC does not explicitly address how updated controls (especially SA and SI) should be implemented within automated CI/CD and DevSecOps pipelines.
Recommendation: Provide guidance on integrating security controls into development pipelines, including automated testing, code scanning, and deployment gating.

Gap #8 – Minimal consideration for cross-control data flows and dependencies
Issue: Controls across RA, SC, and SI rely on shared data (e.g., logs, telemetry, risk inputs), but the RFC does not address how these data flows should be standardized or integrated.
Recommendation: Define expectations for interoperability and data sharing between control implementations to enable cohesive security operations and analytics.

Gap #9 – No explicit expectations for validation of third-party security claims
Issue: While SR and SA controls emphasize supplier requirements, there is limited guidance on how CSPs should validate vendor security claims or attestations.
Recommendation: Include requirements or best practices for independent validation (e.g., third-party assessments, attestations, or continuous monitoring of vendors).

[paulagosta]

From a info@fedramp.gov submission.

RA-5 states "Guidance on compliance scan findings can be found by searching on “Tracking of Compliance Scans” in FAQs."

This guidance is no longer publicly visible in FedRAMP FAQs and was archived during the last FAQs update. Either turn the page back on or update the link to the new guidance.

[rhoesing]

Public comment from Raj P sent to pete@fedramp.gov:

Please find my public comments below on RFC-0030 FedRAMP Rev5 Security Controls Baseline Update for RA, SA, SC, SI, and SR Control Families.

Comment 1: RA-05: Vulnerability Monitoring and Scanning

Meeting both tracks of Rev 5 baselines while also allowing for VDR opt-in baselines is a sound idea. However each requirement for VDR opt-in whether scanning frequency, drift detection, or evaluation window for all three baselines use SHOULD instead of must. This means there is no actual requirement for a system designed for High baseline to actually scan daily and evaluate vulnerabilities within 2 days of detection. When comparing both tracks while looking at the self-assessment customers, CSPs, and assessors will see them as offering the same capabilities when this language clearly cannot be enforced. I believe this to be unintentional.

Comment 2: SA-04(5) and SI-02(2) / SI-03

The addition to SA-04(5) that requires custom baselines to be documented and validated as part of the independent assessment activity is an excellent (and extremely long needed) band-aid for High baseline systems.

The language used in SI-02(2) and SI-03 are very different from RA-05 because it simply states participants for VDR BIR must persistently review security alerts. There is no definition given for persistent or reference to a special number. RA-05 clearly defines what will be reviewed and how frequently (every 3 days, every 7 days, etc.). By not locking down these two controls CSPs who choose VDR leave participants with nothing they can actually document and assessors with nothing they can actually test.

Comment 3: SC-13 and SI-05

Including SC-13 for historic CMVP modules closes a long time authorization gap. Updating SI-05 to specifically state EDs and BODs, adding the CISA link and requiring all responses to flow through FSI are improvements. The proposed language falls short by not defining what qualifies as an adequate FSI response as well as what the repercussion is for missing FSI timelines. Will most likely lead to wild variance from CSP to CSP.

Thank you for the opportunity to comment on this RFC.

[OG-of-the-realms]

RFC-0030 is consistent with industry expectations, and aligned with expected implementations for Rev5 BIRs.

[cb-axon]

Overall, we welcome the updates proposed in this RFC. The alignment of RA-5 parameters with the VDR BIR, the cleanup of outdated references, and the clarifications around configuration baselines and operational directives represent meaningful progress in modernizing FedRAMP's Rev5 requirements. We appreciate FedRAMP's continued effort to reduce burden on CSPs while maintaining rigorous security expectations.

RA-5 - The proposed language for the traditional Rev5 path under RA-5(a) reads:

[monthly operating system/infrastructure; monthly web applications (including APIs) and databases for traditional Rev5 processes]

This same scan type enumeration appears repeatedly throughout this RFC — across the FedRAMP-Defined Assignment/Selection Parameters, Additional FedRAMP Requirements and Guidance, and Continuous Monitoring Periodicity sections — and the concern below applies to all instances.
Container scanning is absent from this language. This is not new — the original Rev5 baseline predated FedRAMP's separate container scanning guidance and was never updated to explicitly include containers alongside OS/infrastructure, web application, and database scans. This RFC represents an opportunity to correct that gap, and we strongly urge FedRAMP to do so.
FedRAMP should explicitly confirm in this RFC whether container scans are required for CSPs on the traditional Rev5 path. If they are — which we believe they should be given the prevalence of containerized workloads in modern cloud architectures and the existence of FedRAMP container scanning guidance — every instance of the traditional Rev5 scan type enumeration in this RFC must be updated to include containers explicitly. Implicit coverage under "infrastructure" is insufficient; OS/infrastructure, web applications, and databases are each called out as distinct scan types, and containers warrant the same explicit treatment.
Proposed language wherever this enumeration appears for the traditional Rev5 path:

[monthly operating system/infrastructure; monthly web applications (including APIs) and databases; monthly containers for traditional Rev5 processes]

Leaving containers unaddressed in this update would perpetuate an existing gap at exactly the moment FedRAMP has the opportunity to close it.

SI-8 - The SI-8 guidance — both current and proposed — addresses DMARC only in the context of outbound email sent on behalf of the government, but leaves several common CSO email scenarios unaddressed. We request FedRAMP explicitly clarify the following:

Spam protection (SI-8): Is spam protection required only when the CSO sends email, only when it receives email, or both? Is there any SI-8 obligation for CSOs that neither send nor receive email as part of their offering?
DMARC (outbound): Does the policy=reject requirement apply only when sending on behalf of the government, or also when the CSO sends email from CSP-owned domains for any purpose?
DMARC (inbound): If a CSO accepts inbound email and controls its own spam filtering — without delegating that control to customers — is the CSO expected to enforce DMARC rejection on inbound mail failures?

The existing guidance is explicit for the government-email-sending scenario but silent on these adjacent cases, creating inconsistency in how CSPs implement SI-8 and how 3PAOs assess it.

SC-13 - We applaud the addition of explicit guidance directing CSPs to follow FedRAMP instructions for cryptographic modules listed as "historical" in the CMVP database. This has been a recurring source of confusion during the authorization process, and surfacing it directly in the baseline makes compliance expectations more evident to both CSPs and assessors.