Controls

Providers MUST publicly share up-to-date information about the cloud service offering in both human-readable and machine-readable formats, including at least: • Direct link to the FedRAMP Marketplace for the offering • Service Model • Deployment Model • Business Category • UEI Number • Contact Information • Overall Service Description • Detailed list of specific services and their impact levels (see FRR-ADS-03) • Summary of customer responsibilities and secure configuration guidance • Process for accessing information in the trust center (if applicable) • Availability status and recent disruptions for the trust center (if applicable) • Customer support information for the trust center (if applicable)

Providers MUST use automation to ensure information remains consistent between human-readable and machine-readable formats when authorization data is provided in both formats; Providers SHOULD generate human-readable and machine-readable data from the same source at the same time OR generate human-readable formats directly from machine-readable data.

Providers MUST share a detailed list of specific services and their impact levels that are included in the cloud service offering using clear feature or service names that align with standard public marketing materials; this list MUST be complete enough for a potential customer to determine which services are and are not included in the FedRAMP authorization without requesting access to underlying authorization data.

Providers MUST publicly provide plain-language policies and guidance for all necessary parties that explains how they can obtain and manage access to authorization data stored in the trust center.

Providers SHOULD share at least the authorization package with prospective agency customers upon request and MUST notify FedRAMP within five business days if a prospective agency customer request is denied.

Providers of FedRAMP Rev5 Authorized cloud service offerings at FedRAMP High using a legacy self-managed repository for authorization data MAY ignore the requirements in this Authorization Data Sharing document until future notice.

Trust centers MUST be included as an information resource included in the cloud service offering for assessment if FRR-MAS-01 applies.

Trust centers SHOULD make authorization data available to view and download in both human-readable and machine-readable formats

Trust centers MUST provide documented programmatic access to all authorization data, including programmatic access to human-readable materials.

Trust centers SHOULD include features that encourage all necessary parties to provision and manage access to authorization data for their users and services directly.

Trust centers MUST maintain an inventory and history of federal agency users or systems with access to authorization data and MUST make this information available to FedRAMP without interruption.

Trust centers MUST log access to authorization data and store summaries of access for at least six months; such information, as it pertains to specific parties, SHOULD be made available upon request by those parties.

Trust centers SHOULD deliver responsive performance during normal operating conditions and minimize service disruptions.

Apply the FedRAMP Minimum Assessment Scope (MAS) to identify and document the scope of the cloud service offering to be assessed for FedRAMP authorization and persistently address all related requirements and recommendations.

Set security goals for the cloud service offering based on FedRAMP 20x Phase Two Key Security Indicators (KSIs - you are here), develop automated validation of status and progress to the greatest extent possible, and persistently address all related requirements and recommendations.

Determine how authorization data will be shared with all necessary parties in alignment with the FedRAMP Authorization Data Sharing (ADS) process and persistently address all related requirements and recommendations.

Document the vulnerability detection and vulnerability response methodology used within the cloud service offering in alignment with the FedRAMP Vulnerability Detection and Response (VDR) process and persistently address all related requirements and recommendations.

Determine how significant changes will be tracked and how all necessary parties will be notified in alignment with the FedRAMP Significant Change Notifications (SCN) process and persistently address all related requirements and recommendations.

Maintain a plan and process for providing Ongoing Authorization Reports and Quarterly Reviews for all necessary parties in alignment with the FedRAMP Collaborative Continuous Monitoring (CCM) process and persistently address all related requirements and recommendations.

Develop secure by default configurations and provide guidance for secure configuration of the cloud service offering to customers in alignment with the FedRAMP Recommended Secure Configuration (RSC) guidance process and persistently address all related requirements and recommendations.

Operate a secure inbox to receive critical communication from FedRAMP and other government entities in alignment with FedRAMP Security Inbox (FSI) requirements and persistently address all related requirements and recommendations.

Persistently validate, assess, and report on the effectiveness and status of security decisions and policies that are implemented within the cloud service offering in alignment with the FedRAMP 20x Persistent Validation and Assessment (PVA) process, and persistently address all related requirements and recommendations.

Integrate FedRAMP's Incident Communications Procedures (ICP) into incident response procedures and persistently address all related requirements and recommendations.

Ensure that cryptographic modules used to protect potentially sensitive federal customer data are selected and used in alignment with the FedRAMP 20x Using Cryptographic Modules (UCM) guidance and persistently address all related requirements and recommendations.

Providers MUST make an Ongoing Authorization Report available to all necessary parties every 3 months, in a consistent format that is human readable, covering the entire period since the previous summary; this report MUST include high-level summaries of at least the following information: • Changes to authorization data • Planned changes to authorization data during at least the next 3 months • Accepted vulnerabilities • Transformative changes • Updated recommendations or best practices for security, configuration, usage, or similar aspects of the cloud service offering

Providers SHOULD establish a regular 3 month cycle for Ongoing Authorization Reports that is spread out from the beginning, middle, or end of each quarter.

Providers MUST publicly include the target date for their next Ongoing Authorization Report with the authorization data required by FRR-ADS-01.

Providers MUST establish and share an asynchronous mechanism for all necessary parties to provide feedback or ask questions about each Ongoing Authorization Report.

Providers MUST maintain an anonymized and desensitized summary of the feedback, questions, and answers about each Ongoing Authorization Report as an addendum to the Ongoing Authorization Report.

Providers MUST NOT irresponsibly disclose sensitive information in an Ongoing Authorization Report that would likely have an adverse effect on the cloud service offering.

Providers MAY responsibly share some or all of the information an Ongoing Authorization Report publicly or with other parties if the provider determines doing so will NOT likely have an adverse effect on the cloud service offering.

Agencies MUST review each Ongoing Authorization Report to understand how changes to the cloud service offering may impact the previously agreed-upon risk tolerance documented in the agency's_ Authorization to Operate of a federal information system that includes the cloud service offering in its boundary.

Agencies SHOULD consider the Security Category noted in their Authorization to Operate of the federal information system that includes the cloud service offering in its boundary and assign appropriate information security resources for reviewing Ongoing Authorization Reports, attending Quarterly Reviews, and other ongoing authorization data.

Agencies SHOULD formally notify the provider if the information presented in an Ongoing Authorization Report, Quarterly Review, or other ongoing authorization data causes significant concerns that may lead the agency to remove the cloud service offering from operation.

Agencies MUST notify FedRAMP by sending a notification to info@fedramp.gov if the information presented in an Ongoing Authorization Report, Quarterly Review, or other ongoing authorization data causes significant concerns that may lead the agency to stop operation of the cloud service offering.

Agencies MUST NOT place additional security requirements on cloud service providers beyond those required by FedRAMP UNLESS the head of the agency or an authorized delegate makes a determination that there is a demonstrable need for such; this does not apply to seeking clarification or asking general questions about authorization data.

Agencies MUST inform FedRAMP after requesting any additional information or materials from a cloud service provider beyond those FedRAMP requires by sending a notification to info@fedramp.gov.

Providers MUST host a synchronous Quarterly Review every 3 months, open to all necessary parties, to review aspects of the most recent Ongoing Authorization Reports that the provider determines are of the most relevance to agencies.

Providers SHOULD regularly schedule Quarterly Reviews to occur at least 3 business days after releasing an Ongoing Authorization Report AND within 10 business days of such release.

Providers MUST NOT irresponsibly disclose sensitive information in a Quarterly Review that would likely have an adverse effect on the cloud service offering.

Providers MUST include either a registration link or a downloadable calendar file with meeting information for Quarterly Reviews in the authorization data available to all necessary parties required by FRR-ADS-06 and FRR-ADS-07.

Providers MUST publicly include the target date for their next Quarterly Review with the authorization data required by FRR-ADS-01.

Providers SHOULD include additional information in Quarterly Reviews that the provider determines is of interest, use, or otherwise relevant to agencies.

Providers SHOULD NOT invite third parties to attend Quarterly Reviews intended for agencies unless they have specific relevance.

Providers SHOULD record or transcribe Quarterly Reviews and make such available to all necessary parties with other authorization data required by FRR-ADS-06 and FRR-ADS07.

Providers MAY responsibly share recordings or transcriptions of Quarterly Reviews with the public or other parties ONLY if the provider removes all agency information (comments, questions, names, etc.) AND determines sharing will NOT likely have an adverse effect on the cloud service offering.

Providers MAY responsibly share content prepared for a Quarterly Review with the public or other parties if the provider determines doing so will NOT likely have an adverse effect on the cloud service offering.

Persistently review the effectiveness of training given to all employees on policies, procedures, and security-related topics.

Persistently review the effectiveness of role-specific training given to employees in high risk roles, including at least roles with privileged access.

Persistently review the effectiveness of role-specific training given to development and engineering staff that covers best practices for delivering secure software.

Persistently review the effectiveness of role-specific training given to staff involved with incident response or disaster recovery.

Log and monitor modifications to the cloud service offering.

Execute changes to machine-based information resources through redeployment of version controlled immutable resources rather than direct modification wherever possible.

Automate persistent testing and validation of changes throughout deployment.

Persistently review the effectiveness of documented change management procedures.

Persistently ensure all machine-based information resources are configured to limit inbound and outbound network traffic.

Persistently ensure machine-based information resources have a minimal attack surface and that lateral movement is minimized if compromised.

Use logical networking and related capabilities to enforce traffic flow controls.

Use immutable infrastructure with strictly defined functionality and privileges by default.

Persistently review the effectiveness of protection against denial of service attacks and other unwanted activity.

Appropriately optimize machine-based information resources for high availability and rapid recovery.

Persistently ensure cloud-native machine-based information resources are implemented based on the host provider's best practices and documented guidance.

Use automated services to persistently assess the security posture of all machine-based information resources and automatically enforce their intended operational state.

FedRAMP MUST send messages to cloud service providers using an official @fedramp.gov or @gsa.gov email address with properly configured Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication Reporting and Conformance (DMARC) email authentication.

FedRAMP MUST convey the criticality of the message in the subject line using one of the following designators if the message requires an elevated response: • **Emergency:** There is a potential incident or crisis such that FedRAMP requires an extremely urgent response; emergency messages will contain aggressive timeframes for response and failure to meet these timeframes will result in corrective action. • **Emergency Test:** FedRAMP requires an extremely urgent response to confirm the functionality and effectiveness of the FedRAMP Security Inbox; emergency test messages will contain aggressive timeframes for response and failure to meet these timeframes will result in corrective action. • **Important:** There is an important issue that FedRAMP requires the cloud service provider to address; important messages will contain reasonable timeframes for response and failure to meet these timeframes may result in corrective action.

FedRAMP MUST send Emergency and Emergency Test designated messages from fedramp_security@gsa.gov OR fedramp_security@fedramp.gov.

FedRAMP MUST post a public notice at least 10 business days in advance of sending an Emergency Test message; such notices MUST include explanation of the likely expected actions and timeframes for the Emergency Test message.

FedRAMP MUST clearly specify the required actions in the body of messages that require an elevated response.

FedRAMP MUST clearly specify the expected timeframe for completing required actions in the body of messages that require an elevated response; timeframes for actions will vary depending on the situation but the default timeframes to provide an estimated resolution time for Emergency and Emergency Test designated messages will be as follows: • **High Impact:** within 12 hours • **Moderate Impact:** by 3:00 p.m. Eastern Time on the 2nd business day • **Low Impact:** by 3:00 p.m. Eastern Time on the 3rd business day

FedRAMP MUST clearly specify the corrective actions that will result from failure to complete the required actions in the body of messages that require an elevated response; such actions may vary from negative ratings in the FedRAMP Marketplace to suspension of FedRAMP authorization depending on the severity of the event.

FedRAMP MAY track and publicly share the time required by cloud service providers to take the actions specified in messages that require an elevated response.

Providers MUST establish and maintain an email address to receive messages from FedRAMP; this inbox is a FedRAMP Security Inbox (FSI).

Providers MUST treat any email originating from an @fedramp.gov or @gsa.gov email address as if it was sent from FedRAMP by default; if such a message is confirmed to originate from someone other than FedRAMP then FedRAMP Security Inbox requirements no longer apply.

Providers MUST receive and respond to email messages from FedRAMP without disruption and without requiring additional actions from FedRAMP.

Providers MUST immediately notify FedRAMP of any changes in addressing for their FedRAMP Security Inbox by emailing info@fedramp.gov with the name and FedRAMP ID of the cloud service offering and the updated email address.

Providers SHOULD promptly and automatically acknowledge the receipt of messages received from FedRAMP in their FedRAMP Security Inbox.

Providers MUST complete the required actions in Emergency or Emergency Test designated messages sent by FedRAMP within the timeframe included in the message.

Providers MUST route Emergency designated messages sent by FedRAMP to a senior security official for their awareness.

Providers SHOULD complete the required actions in Important designated messages sent by FedRAMP within the timeframe specified in the message.

Enforce multi-factor authentication (MFA) using methods that are difficult to intercept or impersonate (phishing-resistant MFA) for all user authentication.

Use secure passwordless methods for user authentication and authorization when feasible, otherwise enforce strong passwords with MFA.

Enforce appropriately secure authentication methods for non-user accounts and services.

Use a least-privileged, role and attribute-based, and just-in-time security authorization model for all user and non-user accounts and services.

Persistently ensure that identity and access management employs measures to ensure each user or device can only access the resources they need.

Automatically disable or otherwise secure accounts with privileged access in response to suspicious activity

Securely manage the lifecycle and privileges of all accounts, roles, and groups, using automation.

Providers MUST responsibly report incidents to FedRAMP within 1 hour of identification by sending an email to fedramp_security@fedramp.gov or fedramp_security@gsa.gov.

Providers MUST responsibly report incidents to all agency customers within 1 hour of identification using the incident communications points of contact provided by each agency customer.

Providers MUST responsibly report incidents to CISA within 1 hour of identification if the incident is confirmed or suspected to be the result of an attack vector listed at https://www.cisa.gov/federal-incident-notification-guidelines#attack-vectors-taxonomy, following the CISA Federal Incident Notification Guidelines at https://www.cisa.gov/federal-incident-notification-guidelines, by using the CISA Incident Reporting System at https://myservices.cisa.gov/irf.

Providers MUST update all necessary parties, including at least FedRAMP, CISA (if applicable), and all agency customers, at least once per calendar day until the incident is resolved and recovery is complete.

Providers MUST make incident report information available in their secure FedRAMP repository (such as USDA Connect) or trust center.

Providers MUST NOT irresponsibly disclose specific sensitive information about incidents that would likely increase the impact of the incident, but MUST disclose sufficient information for informed risk-based decision-making to all necessary parties.

Providers MUST provide a final report once the incident is resolved and recovery is complete that describes at least: • What occurred • Root cause • Response • Lessons learned • Changes needed

Providers SHOULD use automated mechanisms for reporting incidents and providing updates to all necessary parties (including CISA).

Providers SHOULD make incident report information available in consistent human-readable and machine-readable formats.

Persistently review the effectiveness of documented incident response procedures.

Persistently review past incidents for patterns or vulnerabilities.

Generate incident after action reports and persistently incorporate lessons learned.

Providers MUST identify a set of information resources to assess for FedRAMP authorization that includes all information resources that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering.

Providers MUST include the configuration and usage of third-party information resources, ONLY IF FRR-MAS-01 APPLIES.

Providers MUST clearly identify and document the justification, mitigation measures, compensating controls, and potential impact to federal customer data from the configuration and usage of non-FedRAMP authorized third-party information resources, ONLY IF FRR-MAS-01 APPLIES.

Providers MUST include metadata (including metadata about federal customer data), ONLY IF FRR-MAS-01 APPLIES.

Providers MUST clearly identify, document, and explain information flows and impact levels for ALL information resources, ONLY IF FRR-MAS-01 APPLIES.

Certain categories of cloud computing products and services are specified as entirely outside the scope of FedRAMP by the Director of the Office of Management and Budget. All such products and services are therefore not included in the cloud service offering for FedRAMP. For more, see https://fedramp.gov/scope.

Software produced by cloud service providers that is delivered separately for installation on agency systems and not operated in a shared responsibility model (typically including agents, application clients, mobile applications, etc. that are not fully managed by the cloud service provider) is not a cloud computing product or service and is entirely outside the scope of FedRAMP under the FedRAMP Authorization Act. All such software is therefore not included in the cloud service offering for FedRAMP. For more, see fedramp.gov/scope.

Information resources (including third-party information resources) that do not meet the conditions in FRR-MAS-01 are not included in the cloud service offering for FedRAMP (FRR-MAS-02).

Information resources (including third-party information resources) MAY vary by impact level as appropriate to the level of information handled or impacted by the information resource (FRR-MAS-05).

All parties SHOULD review best practices and technical assistance provided separately by FedRAMP for help with applying the Minimum Assessment Scope as needed.

All aspects of the cloud service offering are determined and maintained by the cloud service provider in accordance with related FedRAMP authorization requirements and documented by the cloud service provider in their assessment and authorization materials.

Providers MAY include documentation of information resources beyond the cloud service offering, or even entirely outside the scope of FedRAMP, in a FedRAMP assessment and authorization package supplement; these resources will not be FedRAMP authorized and MUST be clearly marked and separated from the cloud service offering.

Operate a Security Information and Event Management (SIEM) or similar system(s) for centralized, tamper-resistent logging of events, activities, and changes.

Persistently review and audit logs.

Persistently evaluate and test the configuration of machine-based information resources, especially infrastructure as code.

Maintain a list of information resources and event types that will be monitored, logged, and audited, then do so.

Use a least-privileged, role and attribute-based, and just-in-time access authorization model for access to log data based on organizationally defined data sensitivity.

Use authoritative sources to automatically generate real-time inventories of all information resources when needed.

Persistently review the effectiveness of the provider's vulnerability disclosure program.

Persistently review the effectiveness of building security and privacy considerations into the Software Development Lifecycle and aligning with CISA Secure By Design principles.

Persistently review the effectiveness of the organization's investments in achieving security objectives.

Persistently review executive support for achieving the organization's security objectives.

Providers MUST persistently perform validation of their Key Security Indicators following the processes and cycles documented for their cloud service offering per FRR-KSI-02; this process is called persistent validation and is part of vulnerability detection.

Providers MUST treat failures detected during persistent validation and failures of the persistent validation process as vulnerabilities, then follow the requirements and recommendations in the FedRAMP Vulnerability Detection and Response process for such findings.

Providers MUST include persistent validation activity in the reports on vulnerability detection and response activity required by the FedRAMP Vulnerability Detection and Response process.

Providers MUST track significant changes that impact their Key Security Indicator goals and validation processes while following the requirements and recommendations in the FedRAMP Significant Change Notification process; if such significant changes are not properly tracked and supplied to all necessary assessors then a full Initial FedRAMP Assessment may be required in place of the expected Persistent FedRAMP Assessment.

Providers MUST have the implementation of their goals and validation processes assessed by a FedRAMP-recognized independent assessor OR by FedRAMP directly AND MUST include the results of this assessment in their authorization data without modification.

Providers MUST ensure a complete assessment of validation procedures (including underlying code, pipelines, configurations, automation tools, etc.) for the cloud service offering by all necessary assessors.

Providers SHOULD provide technical explanations, demonstrations, and other relevant supporting information to all necessary assessors for the technical capabilities they employ to meet Key Security Indicators and to provide validation.

Providers MAY ask for and accept advice from their assessor during assessment regarding techniques and procedures that will improve their security posture or the effectiveness, clarity, and accuracy of their validation and reporting procedures for Key Security Indicators, UNLESS doing so might compromise the objectivity and integrity of the assessment (see also FRR-PVA-09).

Assessors MAY share advice with providers they are assessing about techniques and procedures that will improve their security posture or the effectiveness, clarity, and accuracy of their validation and reporting procedures for Key Security Indicators, UNLESS doing so might compromise the objectivity and integrity of the assessment (see also FRR-PVA-08).

Assessors MUST evaluate the underlying processes (both machine-based and non-machine-based) that providers use to validate Key Security Indicators; this evaluation should include at least: • The effectiveness, completeness, and integrity of the automated processes that perform validation of the cloud service offering's_ security posture. • The effectiveness, completeness, and integrity of the human processes that perform validation of the cloud service offering's_ security posture • The coverage of these processes within the cloud service offering, including if all of the consolidated information resources listed are being validated.

Assessors MUST evaluate the implementation of processes derived from Key Security Indicators to determine whether or not the provider has accurately documented their process and goals.

Assessors MUST evaluate whether or not the underlying processes are consistently creating the desired security outcome documented by the provider.

Assessors MUST perform evaluation using a combination of quantitative and expert qualitative assessment as appropriate AND document which is applied to which aspect of the assessment.

Assessors SHOULD engage provider experts in discussion to understand the decisions made by the provider and inform expert qualitative assessment, and SHOULD perform independent research to test such information as part of the expert qualitative assessment process.

Assessors MUST NOT rely on screenshots, configuration dumps, or other static output as evidence EXCEPT when evaluating the accuracy and reliability of a process that generates such artifacts.

Assessors MUST assess whether or not procedures are consistently followed, including the processes in place to ensure this occurs, without relying solely on the existence of a procedure document for assessing if appropriate processes and procedures are in place.

Assessors MUST deliver a high-level summary of their assessment process and findings for each Key Security Indicator; this summary will be included in the authorization data for the cloud service offering.

Assessors MUST NOT deliver an overall recommendation on whether or not the cloud service offering meets the requirements for FedRAMP authorization.

Providers MUST complete the validation processes for Key Security Indicators of machine-based information resources at least once every 3 days.

Providers MUST complete the validation processes for Key Security Indicators of non-machine-based information resources at least once every 3 months.

Persistently review desired Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).

Persistently review the alignment of recovery plans with defined recovery objectives.

Persistently review the alignment of machine-based information resource backups with defined recovery objectives.

Persistently test the capability to recover from incidents and contingencies, including alignment with defined recovery objectives.

Providers MUST create and maintain guidance that includes instructions on how to securely access, configure, operate, and decommission top-level administrative accounts that control enterprise access to the entire cloud service offering.

Providers MUST create and maintain guidance that explains security-related settings that can be operated only by top-level administrative accounts and their security implications.

Providers SHOULD create and maintain guidance that explains security-related settings that can be operated only by privileged accounts and their security implications.

Providers SHOULD set all settings to their recommended secure defaults for top-level administrative accounts and privileged accounts when initially provisioned.

Providers SHOULD offer the capability to compare all current settings for top-level administrative accounts and privileged accounts to the recommended secure defaults.

Providers SHOULD offer the capability to export all security settings in a machine-readable format.

Providers SHOULD offer the capability to view and adjust security settings via an API or similar capability.

Providers SHOULD provide recommended secure configuration guidance in a machine-readable format that can be used by customers or third-party tools to compare against current settings.

Providers SHOULD make recommended secure configuration guidance available publicly.

Providers SHOULD provide versioning and a release history for recommended secure default settings for top-level administrative accounts and privileged accounts as they are adjusted over time.

Providers MUST notify all necessary parties when Significant Change Notifications are required, including at least FedRAMP and all agency customers. Providers MAY share Significant Change Notifications publicly or with other parties.

Providers MUST follow the procedures documented in their security plan to plan, evaluate, test, perform, assess, and document changes.

Providers MUST evaluate and type label all significant changes, then follow FedRAMP requirements for the type.

Providers MUST maintain auditable records of these activities and make them available to all necessary parties.

Providers MUST keep historical Significant Change Notifications available to all necessary parties at least until the service completes its next annual assessment.

All parties SHOULD follow FedRAMP's best practices and technical assistance on significant change assessment and notification where applicable.

Providers MAY notify necessary parties in a variety of ways as long as the mechanism for notification is clearly documented and easily accessible.

Providers MUST make ALL Significant Change Notifications and related audit records available in similar human-readable and compatible machine-readable formats.

Providers MUST include at least the following information in Significant Change Notifications: • Service Offering FedRAMP ID • Assessor Name (if applicable) • Related POA&M (if applicable) • Significant Change type and explanation of categorization • Short description of change • Reason for change • Summary of customer impact, including changes to services and customer configuration responsibilities • Plan and timeline for the change, including for the verification, assessment, and/or validation of impacted Key Security Indicators or controls • Copy of the business or security impact analysis • Name and title of approver

Providers MAY include additional relevant information in Significant Change Notifications.

Providers MUST notify all necessary parties within ten business days after finishing adaptive changes, also including the following information: • Summary of any new risks identified and/or POA&Ms resulting from the change (if applicable)

Providers MAY be required to delay significant changes beyond the standard Significant Change Notification period and/or submit significant changes for approval in advance as a condition of a formal FedRAMP Corrective Action Plan or other agreement.

Providers MAY execute significant changes (including transformative changes) during an emergency or incident without meeting Significant Change Notification requirements in advance ONLY if absolutely necessary. In such emergencies, providers MUST follow all relevant procedures, notify all necessary parties, retroactively provide all Significant Change Notification materials, and complete appropriate assessment after the incident.

Providers MUST follow the legacy Significant Change Request process or full re-authorization for impact categorization changes, with advance approval from an identified lead agency, until further notice.

Providers SHOULD NOT make formal Significant Change Notifications for routine recurring changes; this type of change is exempted from the notification requirements of this process.

Providers SHOULD engage a third-party assessor to review the scope and impact of the planned change before starting transformative changes if human validation is necessary. This review SHOULD be limited to security decisions that require human validation. Providers MUST document this decision and justification.

Providers MUST notify all necessary parties of initial plans for transformative changes at least 30 business days before starting transformative changes.

Providers MUST notify all necessary parties of final plans for transformative changes at least 10 business days before starting transformative changes.

Providers MUST notify all necessary parties within 5 business days after finishing transformative changes, also including the following information: • Updates to all previously sent information

Providers MUST notify all necessary parties within 5 business days after completing the verification, assessment, and/or validation of transformative changes, also including the following information: • Updates to all previously sent information • Summary of any new risks identified and/or POA&Ms resulting from the change (if applicable) • Copy of the security assessment report (if applicable)

Providers MUST publish updated service documentation and other materials to reflect transformative changes within 30 business days after finishing transformative changes.

Providers MUST allow agency customers to OPT OUT of transformative changes whenever feasible.

Implement improvements based on persistent evaluation of information resources for opportunities to improve security.

Encrypt or otherwise secure network traffic.

Manage configuration of machine-based information resources using automation.

Use cryptographic methods to validate the integrity of machine-based information resources.

Automate management, protection, and regular rotation of digital keys, certificates, and other secrets.

Persistently review plans, procedures, and the state of information resources after making changes to limit and remove unwanted residual elements that would likely negatively affect the confidentiality, integrity, or availability of federal customer data.

Persistently validate the authenticity and integrity of communications between machine-based information resources using automation.

Remove unwanted federal customer data promptly when requested by an agency in alignment with customer agreements, including from backups if appropriate; this typically applies when a customer spills information or when a customer seeks to remove information from a service due to a change in usage.

Persistently identify, review, and mitigate potential supply chain risks.

Automatically monitor third party software information resources for upstream vulnerabilities using mechanisms that may include contractual notification requirements or active monitoring services.

Providers MUST document the cryptographic modules used in each service (or groups of services that use the same modules) where cryptographic services are used to protect federal customer data, including whether these modules are validated under the NIST Cryptographic Module Validation Program or are update streams of such modules.

Providers SHOULD configure agency tenants by default to use cryptographic services that use cryptographic modules or update streams of cryptographic modules with active validations under the NIST Cryptographic Module Validation Program when such modules are available.

Providers SHOULD use cryptographic modules or update streams of cryptographic modules with active validations under the NIST Cryptographic Module Validation Program when using cryptographic services to protect federal customer data.

Providers MUST systematically, persistently, and promptly discover and identify vulnerabilities within their cloud service offering using appropriate techniques such as assessment, scanning, threat intelligence, vulnerability disclosure mechanisms, bug bounties, supply chain monitoring, and other relevant capabilities; this process is called vulnerability detection.

Providers MUST systematically, persistently, and promptly track, evaluate, monitor, mitigate, remediate, assess exploitation of, report, and otherwise manage all detected vulnerabilities within their cloud service offering; this process is called vulnerability response.

Providers MUST follow the requirements and recommendations outlined in FRR-VDR-TF regarding timeframes for vulnerability detection and response.

Providers MAY sample effectively identical information resources, especially machine-based information resources, when performing vulnerability detection UNLESS doing so would decrease the efficiency or effectiveness of vulnerability detection.

Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to identify logical groupings of affected information resources that may improve the efficiency and effectiveness of vulnerability response by consolidating further activity; requirements and recommendations in this process are then applied to these consolidated groupings of vulnerabilities instead of each individual detected instance.

Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are false positive vulnerabilities.

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities.

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are internet-reachable vulnerabilities.

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the potential adverse impact of exploitation on government customers AND assign one of the following potential adverse impact ratings:

Providers SHOULD consider at least the following factors when considering the context of the cloud service offering to evaluate detected vulnerabilities: • **Criticality**: How important are the systems or information that might be impacted by the vulnerability? • **Reachability**: How might a threat actor reach the vulnerability and how likely is that? • **Exploitability**: How easy is it for a threat actor to exploit the vulnerability and how likely is that? • **Detectability**: How easy is it for a threat actor to become aware of the vulnerability and how likely is that? • **Prevalence**: How much of the cloud service offering is affected by the vulnerability? • **Privilege**: How much privileged authority or access is granted or can be gained from exploiting the vulnerability? • **Proximate Vulnerabilities**: How does this vulnerability interact with previously detected vulnerabilities, especially partially or fully mitigated vulnerabilities?_ • **Known Threats**: How might already known threats leverage the vulnerability and how likely is that?

Providers MUST document the reason and resulting implications for their customers when choosing not to meet FedRAMP recommendations in this process; this documentation MUST be included in the authorization data for the cloud service offering.

Agencies SHOULD review the information provided in vulnerability reports at appropriate and reasonable intervals commensurate with the expectations and risk posture indicated by their Authorization to Operate, and SHOULD use automated processing and filtering of machine readable information from cloud service providers.

Agencies SHOULD use vulnerability information reported by the Provider to maintain Plans of Action & Milestones for agency security programs when relevant according to agency security policies (such as if the agency takes action to mitigate the risk of exploitation or authorized the continued use of a cloud service with accepted vulnerabilities that put agency information systems at risk).

Agencies SHOULD NOT request additional information from cloud service providers that is not required by this FedRAMP process UNLESS the head of the agency or an authorized delegate makes a determination that there is a demonstrable need for such.

Agencies MUST inform FedRAMP after requesting any additional vulnerability information or materials from a cloud service provider beyond those FedRAMP requires by sending a notification to [info@fedramp.gov](mailto:info@fedramp.gov).

If it is not possible to fully mitigate or remediate detected vulnerabilities, providers SHOULD instead partially mitigate vulnerabilities promptly, progressively, and persistently.

Providers SHOULD make design and architecture decisions for their cloud service offering that mitigate the risk of vulnerabilities by default AND decrease the risk and complexity of vulnerability detection and response.

Providers SHOULD use automated services to improve and streamline vulnerability detection and response.

Providers SHOULD automatically perform vulnerability detection on representative samples of new or significantly changed information resources.

Providers SHOULD NOT weaken the security of information resources to facilitate vulnerability scanning or assessment activities.

Providers SHOULD NOT deploy or otherwise activate new machine-based information resources with Known Exploited Vulnerabilities.

Providers MAY be required to share additional vulnerability information, alternative reports, or to report at an alternative frequency as a condition of a FedRAMP Corrective Action Plan or other agreements with federal agencies.

Providers MAY be required to provide additional information or details about vulnerabilities, including sensitive information that would likely lead to exploitation, as part of review, response or investigation by necessary parties.

Providers MUST NOT use this process to reject requests for additional information from necessary parties which also include law enforcement, Congress, and Inspectors General.

Providers MUST report vulnerability detection and response activity to all necessary parties persistently, summarizing ALL activity since the previous report; these reports are authorization data and are subject to the FedRAMP Authorization Data Sharing (ADS) process.

Providers SHOULD include high-level overviews of ALL vulnerability detection and response activities conducted during this period for the cloud service offering;_ this includes vulnerability disclosure programs, bug bounty programs, penetration testing, assessments, etc.

Providers MUST NOT irresponsibly disclose specific sensitive information about vulnerabilities that would likely lead to exploitation, but MUST disclose sufficient information for informed risk-based decision-making to all necessary parties.

Providers MAY responsibly disclose vulnerabilities publicly or with other parties if the provider determines doing so will NOT likely lead to exploitation.

Providers MUST include the following information (if applicable) on detected vulnerabilities when reporting on vulnerability detection and response activity, UNLESS it is an accepted vulnerability: • Provider's internally assigned tracking identifier • Time and source of the detection • Time of completed evaluation • Is it an internet-reachable vulnerability or not? • Is it a likely exploitable vulnerability or not? • Historically and currently estimated potential adverse impact of exploitation • Time and level of each completed and evaluated reduction in potential adverse impact • Estimated time and target level of next reduction in potential adverse impact • Is it currently or is it likely to become an overdue vulnerability or not? If so, explain. • Any supplementary information the provider responsibly determines will help federal agencies assess or mitigate the risk to their federal customer data within the cloud service offering resulting from the vulnerability • Final disposition of the vulnerability

Providers MUST include the following information on accepted vulnerabilities when reporting on vulnerability detection and response activity: • Provider's internally assigned tracking identifier • Time and source of the detection • Time of completed evaluation • Is it an internet-reachable vulnerability or not? • Is it a likely exploitable vulnerability or not? • Currently estimated potential adverse impact of exploitation • Explanation of why this is an accepted vulnerability • Any supplementary information the provider determines will responsibly help federal agencies assess or mitigate the risk to their federal customer data within the cloud service offering resulting from the accepted vulnerability

Providers MUST report vulnerability detection and response activity to all necessary parties in a consistent format that is human readable at least monthly.

Providers SHOULD remediate Known Exploited Vulnerabilities according to the due dates in the CISA Known Exploited Vulnerabilities Catalog (even if the vulnerability has been fully mitigated) as required by CISA Binding Operational Directive (BOD) 22-01 or any successor guidance from CISA.

Providers MUST categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability.

Providers SHOULD make all recent historical vulnerability detection and response activity available in a machine-readable format for automated retrieval by all necessary parties (e.g. using an API service or similar); this information SHOULD be updated persistently, at least once every 14 days.

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 persistently perform vulnerability detection on all information resources that are NOT likely to drift, at least once per month.

Providers SHOULD evaluate ALL vulnerabilities as required by FRR-VDR-07, FRR-VDR-08, and FRR-VDR-09 within 5 days of detection.

Providers SHOULD treat internet-reachable likely exploitable vulnerabilities with a potential adverse impact of N4 or N5 as a security incident until they are partially mitigated to N3 or below.

Providers SHOULD partially mitigate, fully mitigate,_ or remediate vulnerabilities to a lower potential adverse impact within the timeframes from evaluation shown below, factoring for the current potential adverse impact, internet reachability,_ and likely exploitability:

Providers SHOULD mitigate or remediate remaining vulnerabilities during routine operations as determined necessary by the provider.