Controls

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.

Providers MUST establish and maintain an email address to receive messages from FedRAMP; this inbox is a FedRAMP Security Inbox (FSI). • Unless otherwise notified, FedRAMP will use the listed Security Email on the Marketplace for these notifications. • If a provider establishes a new inbox in reaction to this guidance that is different from the Security Email then they must follow the AFC-CSO-NOC (Notification of Changes) rules to notify FedRAMP.

Providers MUST immediately notify FedRAMP of any changes to the email address for their FedRAMP Security Inbox.

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

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 the FedRAMP Security Inbox rules no longer apply.

Providers MUST supply an anonymized and desensitized summary of the feedback, questions, and answers about each Ongoing Certification Report as an addendum to the Ongoing Certification Report OR in the next Ongoing Certification Report.

Providers MUST supply an Ongoing Certification Report to all necessary parties every 3 months, covering the entire period since the previous summary, in a consistent format that is human readable; this report MUST include high-level summaries of at least the following information: • Changes to FedRAMP Certification Data • Planned changes to FedRAMP Certification 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 • A list of all agencies that are directly using the product • FedRAMP Reportable Incidents or an attestation that no such incidents occurred • Lessons learned and changes planned or made as a result of FedRAMP Reportable Incidents (if such occurred)

Providers MUST supply an asynchronous mechanism for all necessary parties to provide feedback or ask questions about each Ongoing Certification Report.

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

Providers MUST supply the target date for their next Ongoing Certification Report with other public FedRAMP Certification Data.

Providers MAY responsibly supply some or all of the information an Ongoing Certification Report to the public or other parties if the provider determines doing so will NOT likely have an adverse effect on the cloud service offering.

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

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

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

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 publicly supply the target date for their next Quarterly Review with other public FedRAMP Certification Data.

Providers MUST supply either a registration link or a downloadable calendar file with meeting information for Quarterly Reviews to all necessary parties.

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 supply them to all necessary parties.

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

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

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

Providers with Class C Certifications MUST maintain a web service, available to all necessary parties, that indicates current and historical availability of core services within the cloud service offering over at least the past 30 days, including availability incidents, in both human-readable and machine-readable formats; this service MUST be available even if the primary cloud service offering is unavailable.

Providers MUST use automation to ensure information remains consistent between human-readable and machine-readable formats when FedRAMP Certification Data is provided in both formats.

Providers MUST always include the FedRAMP ID of the related cloud service offering in all FedRAMP Certification Data once assigned, including all reports, notifications, and other communication that results from FedRAMP rules. • The FedRAMP ID is supplied by FedRAMP after a cloud service offering is registered to be listed on the FedRAMP Marketplace - providers will need to use a placeholder until the FedRAMP ID is assigned. • Many providers have multiple cloud service offerings or use internal names that don't align to public materials; using the FedRAMP ID ensures we can easily align the communication with a specific cloud service offering.

Providers MUST include FedRAMP Certification Reports with their FedRAMP Certification Data without inappropriate modifications, and make such reports available within 2 weeks of receiving the materials from FedRAMP.

Providers MUST supply snapshots of FedRAMP Certification Data aligned to Ongoing Certification Reports to all necessary parties; these snapshots MUST be available for the duration of FedRAMP Certification.

Providers MUST supply all relevant policies and procedures in the FedRAMP Certification Data, including a human-readable and machine-readable reference that explains at least the following about each included policy and procedure: • Name of policy or procedure • Name of file, document, web page, etc. • Brief summary of policy or procedure • Word count of document • Current version • Date of last update • Related FedRAMP Practices (if applicable)

Providers with Class C Certifications MAY supply per-service FedRAMP Certification materials.

Providers MUST publicly share up-to-date information about the cloud service offering in both human-readable and JSON formats, including at least the following information that is available and applicable: • FedRAMP ID • Service Model • Deployment Model • Business Category • UEI Number • Sales Contact Information • Security Contact Information • Product Website Link • Link to Product Logo • Overall Service Description • Detailed list of specific services and their security categories (see CDS-CSO-SVC (Public Service List) (Service List)) • Link to Secure Configuration Guidance • Overview of documentation supplied by the provider for the cloud service offering • Link to Trust Center landing page that includes instructions on accessing information in the trust center • Next Ongoing Certification Report date (see CCM-OCR-NRD (Next Report Date)) • Current FedRAMP Recognized independent assessment service

Providers MUST provide sufficient information in FedRAMP Certification Data to support agency authorization decisions but SHOULD NOT include sensitive information that would likely enable a threat actor to gain unauthorized access, cause harm, disrupt operations, or otherwise have a negative adverse impact on the cloud service offering.

Providers MAY responsibly share some or all of the information in a FedRAMP Certification Package publicly or with other parties if the provider determines doing so will NOT likely have an adverse effect on the cloud service offering.

Providers MUST publicly share a detailed list of specific services and their security categories 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 Minimum Assessment Scope without requesting access to underlying FedRAMP Certification Data.

Providers MUST use a FedRAMP-compatible trust center to store and share FedRAMP Certification Data with all necessary parties.

Trust centers MUST maintain an inventory and history of federal agency users or systems with access to FedRAMP Certification Data and MUST make this information available to FedRAMP upon request.

Trust centers MUST log access to FedRAMP Certification 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 make FedRAMP Certification Data available to view and download in both human-readable and machine-readable formats.

Trust centers MUST provide documented programmatic access to all FedRAMP Certification Data, including programmatic access to human-readable materials.

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

Trust centers MUST share FedRAMP Certification Data with all necessary parties without interruption.

Providers MUST notify FedRAMP within 5 business days of denying an agency access request for FedRAMP Certification Data.

Providers SHOULD supply access to the FedRAMP Certification Package with agencies upon request.

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 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 with Class C Certifications 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 also include the following basic metadata in their Certification Package Overview: • Name, title, and contact information of official that is responsible and accountable for the FedRAMP Certification Package • Version • Date and time of last update • Source of update

Providers seeking Class C Certification MUST also include the overall summary of their FedRAMP independent assessment, supplied by the assessor per IVV-IAS-OSA (Overall Summary of Assessment), in their Certification Package Overview.

Providers MUST supply a Certification Package Overview within their FedRAMP Certification Package, in both human-readable and JSON formats, that includes at least all of the information required by the following rules: • Certification Package Overview: CPO-CSO-MTD (Certification Package Overview Metadata) • Certification Data Sharing: CDS-CSO-PUB (Public Information) • Certification Data Sharing: CDS-CSO-SVC (Public Service List) • Certification Data Sharing: CDS-CSO-IRP (Include Relevant Policies) • Minimum Assessment Scope: MAS-CSO-IIR (Identify Information Resources) • Minimum Assessment Scope: MAS-CSO-FLO (Information Flows and Security Categories) • Minimum Assessment Scope: MAS-CSO-TPR (Third-Party Information Resources) • Using Cryptographic Modules: CMU-CSO-CMD (Cryptographic Module Documentation) • Independent Verification and Validation: IVV-CSO-ICP (Inclusion in Certification Package)

Providers with 20x Class C Certifications MUST persistently maintain their FedRAMP Certification Package to ensure it is up to date and complete at least once every 2 weeks.

Providers MUST complete the FedRAMP Certification Application Form in full to request an initial assessment by FedRAMP.

Providers MUST supply a fresh initial FedRAMP Certification Package that shows the current status of the cloud service offering as verified and validated by the provider within the previous 7 days.

Providers seeking Class C Certification MUST supply a fresh initial FedRAMP independent assessment that was completed by a FedRAMP Recognized independent assessment service within the previous 3 months.

Providers MUST be listed in the FedRAMP Marketplace before applying for FedRAMP Certification, including: • FedRAMP Marketplace: MKT-CSO-MLR (Marketplace Listing Requirements), • FedRAMP Marketplace: MKT-CSO-PML (Provider Marketplace Listing Requests) • FedRAMP Marketplace: MKT-IIP-AGU (Agency Use Cases) • FedRAMP Marketplace: MKT-IIP-DCP (Demonstrating Continuous Progress)

Providers MUST NOT use a third party to apply for a FedRAMP Certification on their behalf; this includes independent assessment services. • FedRAMP previously allowed independent assessment services to submit applications on behalf of providers, but this caused confusion about who was responsible for the application and the information in it. Providers should apply directly to ensure clear accountability. • Providers may use third parties to help them prepare their application and assessment materials for submission.

Providers MAY freshen a stale initial independent verification and validation assessment by having a FedRAMP Recognized independent assessment service review any changes between the original assessment and the current status of the cloud service offering in place of a full re-assessment, UNLESS the stale assessment is more than 9 months old.

Providers MUST identify a target FedRAMP Certification Profile and apply all relevant FedRAMP Practices to the cloud service offering.

Providers MUST supply machine-readable information in JSON documents that are valid against the corresponding JSON schema when a rule contains a FedRAMP JSON schema, UNLESS otherwise specified in the rule.

Providers MUST maintain responsibility and accountability for the accuracy and completeness of all information in the FedRAMP Certification Package, especially when they engage a third party (such as an independent assessor, advisory service, or external tools) to supply information on their behalf.

Providers seeking a Certification MUST supply a complete FedRAMP Certification Package to FedRAMP for initial certification; the FedRAMP Certification Package MUST include at least the following information: • Information about the Cloud Service Offering following CPO-CSO-OVR (Overview of the Cloud Service Offering) • Implementation, Validation, and Assessment information for each relevant FedRAMP requirement/control/ksi as defined in SDR-CSO-FRR (FedRAMP Rules) • A real or example Ongoing Certification Report following CCM-OCR-AVL (Report Availability)

Providers MUST NOT seek both FedRAMP Rev5 Program Certification and FedRAMP 20x Program Certification for the same cloud service offering; pick one type.

Providers SHOULD apply ALL Key Security Indicators to ALL aspects of their cloud service offering that are within the FedRAMP Minimum Assessment Scope.

Providers seeking 20x Class C Certification MUST supply historical metrics including status from persistent validation over at least the past 6 months for all Key Security Indicators.

Providers seeking 20x Class C Certification MUST implement automated methods to persistently verify and validate the accuracy and completeness of Key Security Indicators with at least 2 automated methods for each Key Security Indicator.

Providers seeking 20x Class C Certification SHOULD implement automated methods to persistently verify and validate the accuracy and completeness of the Security Decision Record for FedRAMP rules when applicable.

Providers SHOULD use automation to minimize human intervention in the process of reporting FedRAMP Reportable Incidents to all affected parties.

Providers MUST treat FedRAMP Reportable Incidents as if they have a Potential Agency Impact N-rating (PAIN) of 5 UNLESS they promptly estimate the PAIN rating following the rule in IEC-CSO-EFI (Estimate Federal Impact).

Providers SHOULD promptly estimate the likely adverse impact of an incident on agency customers to assign a Potential Agency Impact N-rating; this step is called Incident Rating. • N1 for a likely minimal customer effect on 1 or more agencies. • N2 for a likely narrow customer effect on 1 or more agencies. • N3 for a likely disruptive customer effect on 1 agency. • N4 for a likely debilitating customer effect on 1 agency or a likely disruptive customer effect on more than 1 agency. • N5 for a likely debilitating customer effect on more than 1 agency.

Providers MUST promptly evaluate incidents to determine if they affect confidentiality or integrity of federal customer data or are likely to affect confidentiality or integrity of federal customer data; such incidents are FedRAMP Reportable Incidents and must be reported following the FedRAMP Incident Evaluation and Communication rules.

Providers with Class C Certifications MUST responsibly notify all affected parties by providing a Final Incident Report once the incident has been resolved and recovery is complete, including final updates to all previously reported information. PAIN Rating Timeframes: • PAIN 1: 1 business day • PAIN 2: 1 business day • PAIN 3: 6 hours • PAIN 4: 6 hours • PAIN 5: 6 hours

Providers with Class C Certifications MUST responsibly notify all affected parties after identifying FedRAMP Reportable Incidents by providing an Initial Incident Report with as much of the following information that is available at the time of reporting and/or the current relevant status for each item: • Contact information for the federal incident response [ coordinator ] • Provider's internally assigned tracking identifier • Description of the incident • Timeline of the incident, including start time, time and source of detection, time of completed FedRAMP Reportable Incident evaluation, and other major incident milestones determined by the provider • Historically and currently estimated Potential Agency Impact N-rating (PAIN) of the incident, including an explanation of the evaluation following the requirements in IEC-CSO-EFI (Estimate Federal Impact) (if applicable) • Functional impact to federal agency customers (include impact to confidentiality and/or integrity and the impacted federal customer data types) • Estimated recovery plan, milestones, and timelines • List of likely affected customer agencies PAIN Rating Timeframes: • PAIN 1: 1 business day • PAIN 2: 24 hours • PAIN 3: 1 hour • PAIN 4: 1 hour • PAIN 5: 1 hour

Providers with Class C Certifications MUST responsibly notify all affected parties of ongoing activity as new information becomes available during incident response for FedRAMP Reportable Incidents, including updates (or lack of updates) to all previously reported information and as much of the the following additional information that is available and/or the current relevant status for each item: • Observed incident activity • Indicators of compromise • Related Common Vulnerabilities and Exposures (CVE) identifier, if applicable • Root cause • Response and recovery activities PAIN Rating Timeframes: • PAIN 1: 1 business day • PAIN 2: 24 hours • PAIN 3: 6 hours • PAIN 4: 6 hours • PAIN 5: 6 hours

Providers MUST document and explain the use of representative samples during verification and validation when using representative samples as allowed by IVV-CSO-USR (Use Representative Samples).

Providers with Class C Certifications MUST persistently complete an independent verification and validation assessment of all applicable FedRAMP rules with a FedRAMP Recognized independent assessment service OR FedRAMP at least once per year; this is a FedRAMP independent assessment.

Providers MUST supply the results of FedRAMP independent assessments in their FedRAMP Certification Package without inappropriate modification. • Inappropriate modification in this context means changing the underlying intent/etc. of the content provided by the independent assessment service - the content itself may be modified for presentation, formatting, etc. as needed. • This rule is related to IVV-IAS-VIP (Verify Inclusion in Certification Package).

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 verification, validation and reporting procedures, UNLESS doing so is likely to compromise the objectivity and integrity of the assessment.

Providers MUST supply evidence to all necessary assessors of the effectiveness of the measures that have been implemented to meet FedRAMP Practices; this evidence is the result of validation.

Providers MUST supply evidence to all necessary assessors of the implementation of the measures that have been documented to meet FedRAMP Practices; this evidence is the result of verification.

Providers SHOULD supply all necessary assessors with technical explanations, demonstrations, and other relevant supporting information about the technical capabilities they employ to address FedRAMP rules; this SHOULD be supplied as necessary to ensure the assessor can effectively complete verification and validation.

Providers MAY use representative samples as appropriate during verification and validation.

Providers with 20x Class C Certifications MUST include all Key Security Indicators in a FedRAMP independent assessment at least once per year.

The effectiveness of relevant cybersecurity education and training is persistently reviewed, including at least general training for all employees, role-specific training for employees in high risk roles, training for development and engineering staff on secure software delivery, and training for staff involved with incident response or disaster recovery.

Modifications to the cloud service offering are logged and monitored.

Changes to machine-based information resources are executed through the redeployment of version controlled resources rather than direct modification wherever reasonable.

The effectiveness of documented change management procedures is persistently reviewed.

Persistent testing and validation of changes throughout deployment is automated.

The functionality and privileges for infrastructure and services are strictly defined.

Automated services are used to persistently assess the security of all machine-based information resources and automatically enforce their intended operational state.

The use and configuration of third-party machine-based information resources is persistently compared against the original provider's best practices and guidance.

Machine-based information resources are persistently reviewed to ensure they have a minimal attack surface and that lateral movement is minimized if compromised.

Machine-based information resources are persistently reviewed to ensure they are appropriately optimized for high availability and rapid recovery.

Machine-based information resources are persistently reviewed to ensure they are appropriately configured to limit inbound and outbound network traffic.

The effectiveness of protection against denial of service attacks and other unwanted activity for machine-based information resources is persistently reviewed.

Logical networking and related capabilities are used and persistently reviewed to enforce traffic flow controls.

The lifecycle and privileges of all accounts, roles, and groups are securely managed using automation.

Secure passwordless methods are used for user authentication and authorization when feasible, otherwise strong passwords with phishing-resistant MFA is used.

Identity and access management measures are used and persistently reviewed to ensure each user or device can only access the resources they need.

A least-privileged, role and attribute-based, and just-in-time security authorization model is used and persistently reviewed for all user and non-user accounts and services.

Appropriately secure authentication methods are used and persistently reviewed for non-user accounts and services.

Accounts with privileged access are disabled or otherwise secured in response to suspicious activity.

Incident after action reports are generated and lessons learned are persistently incorporated.

The effectiveness of documented incident response procedures is persistently reviewed.

Past incidents are persistently reviewed for patterns or vulnerabilities that were not previously apparent or identified.

A least-privileged, role and attribute-based, and just-in-time access authorization model is used and persistently reviewed for access to log data based on organizationally defined data sensitivity.

The configuration of machine-based information resources, especially infrastructure as code, is persistently evaluated and tested.

A list of information resources and event types that will be logged, monitored, and audited is maintained and persistently reviewed to ensure these activities occur.

A Security Information and Event Management (SIEM) or similar system(s) is used and persistently reviewed for centralized, tamper-resistant logging of events, activities, and changes.

Logs are persistently reviewed and audited.

Authoritative sources are used to automatically generate real-time inventories of all information resources when needed.

Executive support for achieving the provider's security goals is persistently reviewed and demonstrated.

The effectiveness of the provider's investments in achieving security goals is persistently reviewed.

The effectiveness of building security and privacy considerations into the Software Development Lifecycle and aligning with CISA Secure By Design principles is persistently reviewed.

The effectiveness of the provider's vulnerability disclosure program is persistently reviewed.

The alignment of machine-based information resource backups with defined recovery objectives is persistently reviewed.

The alignment of recovery plans with defined recovery objectives is persistently reviewed.

The desired Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) are defined and persistently reviewed for alignment with the provider's business needs and capabilities.

The capability to recover from incidents and contingencies aligned with defined recovery objectives is persistently tested.

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

Third party software information resources are automatically monitored for upstream vulnerabilities using mechanisms that may include contractual notification requirements or active monitoring services.

The configuration of machine-based information resources is managed using automation and persistently reviewed for drift.

Management, protection, and regular rotation of digital keys, certificates, and other secrets is automated and persistently reviewed.

Information resources are persistently evaluated for opportunities to improve security and those improvements are persistently made.

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

Unwanted federal customer data is removed 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.

Information is encrypted or otherwise secured from unwanted access or modification.

The authenticity and integrity of communications between machine-based information resources is persistently validated using automation.

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

Providers MUST clearly identify, document, and explain information flows and security categories for ALL information resources or sets of information resources in the cloud service offering.

Providers MUST identify a set of information resources to assess for FedRAMP Certification 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; this set of information resources is the cloud service offering. • 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 Certification Act. All such software is therefore not included in the cloud service offering for FedRAMP. For more, see https://fedramp.gov/scope. • All aspects of the cloud service offering are determined and maintained by the cloud service provider in accordance with related FedRAMP Certification rules and documented by the cloud service provider in their FedRAMP Certification Package.

Providers MUST include metadata (including metadata about federal customer data) in the Minimum Assessment Scope ONLY IF MAS-CSO-IIR (Identify Information Resources) APPLIES.

Providers MAY include additional materials about other information resources that are not part of the cloud service offering in a FedRAMP Certification Package supplement; these resources will not be FedRAMP Certified and MUST be clearly marked and separated from the cloud service offering.

Providers MUST address the potential impact to federal customer data from third-party information resources used by the cloud service offering, ONLY IF MAS-CSO-IIR (Identify Information Resources) APPLIES, by documenting the following information about each applicable third-party information resource: • General usage and configuration • Explanation or justification for use • Mitigation measures in place to reduce the potential impact to federal customer data • Compensating controls in place to reduce the potential impact to federal customer data

Providers MUST address at least these FedRAMP rules to apply for a new FedRAMP Marketplace listing OR to request updates to an existing listing: • Certification Data Sharing: CDS-CSO-PUB (Public Information)

Providers MUST notify FedRAMP using the FedRAMP Marketplace Providing Listing Request Form to request a listing in the FedRAMP Marketplace.

Providers MUST demonstrate that a cloud service offering is intended for one of the following use cases: • Direct Use: The product will be used directly by agency customers for integration into a federal information system that falls within the scope of 44 USC § 3506 and will receive an agency Authorization to Operate. • Indirect Use: The product will be included as a third-party information resource in other cloud service offerings that are directly used by agency customers.

Providers MUST demonstrate continuous progress towards a FedRAMP Certification, documented in their Trust Center or website and updated at least quarterly; progress is measured by the provider against documented goals and milestones.

Providers MUST demonstrate that an assessment for a FedRAMP Certification Class B, C, or D has been scheduled within 2 years of initial listing in the Initial Implementation Phase.

Providers MUST include instructions in the FedRAMP Certification Package that explain how to obtain and use the Secure Configuration Guide.

Providers SHOULD make the Secure Configuration Guide available publicly.

Providers MUST create, maintain, and make available recommendations for securely configuring their cloud services (the Secure Configuration Guide) that includes at least the following information: • Required: Instructions on how to securely access, configure, operate, and decommission top-level administrative accounts that control enterprise access to the entire cloud service offering. • Required: Explanations of security-related settings that can be operated only by top-level administrative accounts and their security implications. • Recommended: Explanations of 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 view and adjust security settings via an API or similar capability.

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 also provide the Secure Configuration Guide in a machine-readable format that can be used by customers or third-party tools to compare against current settings.

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 within 10 business days after finishing adaptive changes, also including the following information: • Summary of any new risks identified and/or vulnerabilities resulting from the change (if applicable)

Providers MAY include additional relevant information in Significant Change Notifications.

Providers MAY execute significant changes (including transformative changes) during an emergency or incident without following the Significant Change Notification rules in advance. 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 evaluate all potential significant changes to determine the type of significant change and follow the appropriate Significant Change Notification rules. • Is it a significant change? --> Continue evaluation and follow the Significant Change Notification rules. • If it is, is it an FedRAMP Certification class change? --> This requires a new assessment and cannot be done under the Significant Change Notification rules. • If it is not, is it a routine recurring change? --> Follow the Routine Recurring Change rules (SCN-RTR Routine Recurring Changes). • If it is not, is it a transformative change? --> Follow the Transformative Change rules (SCN-TRF Transformative Changes). • If it is not, then it is an adaptive change --> Follow the Adaptive Change rules (SCN-ADP Adaptive Changes).

Providers MUST keep 12 months of historical Significant Change Notifications available with their FedRAMP Certification Data.

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

Providers MUST include at least the following information in Significant Change Notifications: • Service Offering FedRAMP ID • Assessor Name (if applicable) • Related Vulnerability (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 Rev5 Controls • Copy of the business or security impact analysis • Name and title of approver

Providers MUST maintain auditable records of the significant change evaluation activities required by SCN-CSO-EVA (Evaluate Changes) and make them available to FedRAMP as requested.

Providers MAY notify necessary parties in a variety of ways as long as the mechanism for notification is clearly documented in the FedRAMP Certification Package and easily accessible. • The sharing mechanism should be designed based on the needs of the provider and their customers and may vary between providers. • The default sharing mechanism for most providers during the SCN beta was to send an email to agency customers and upload a copy of the notification to the provider's secure sharing location.

Providers SHOULD NOT make formal Significant Change Notifications for routine recurring changes; this type of change is exempted from notification requirements. • Activities that match the routine recurring significant change type are performed regularly and routinely by cloud service providers to address flaws or vulnerabilities, address incidents, and generally perform the typical maintenance and service delivery changes expected during day-to-day operations. • These changes leverage mature processes and capabilities to identify, mitigate, and remediate risks as part of the change. They are often entirely automated and may occur without human intervention, even though they have an impact on security of the service. • If the activity does not occur regularly and routinely then it cannot be a significant change of this type (e.g., replacing all physical firewalls to remediate a vulnerability is obviously not regular or routine).

Providers MUST notify all necessary parties within 5 business days after finishing transformative changes, including 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 vulnerabilities resulting from the change (if applicable) • Copy of the security assessment report (if applicable)

Providers MUST notify all necessary parties of final plans for transformative changes at least 10 business days before starting transformative changes, including updates to all previously sent information.

Providers MUST notify all necessary parties of initial plans for transformative changes at least 30 business days before starting transformative changes, including a summary of any likely security impacts or changes in risk.

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; such reviews SHOULD be limited to security decisions that require human validation.

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

Providers MUST supply a Security Decision Record, in both human-readable and JSON formats, that includes at least all of the following information for each applicable FedRAMP rule: • Explanation of how the rule is followed, or an explanation of the reason and resulting risk to customers for not following the rule. • Verification that the implementation is appropriate for the rule, or that the reason for not implementing is accepted by a senior official. • Validation that the implementation is in place and working as intended, or that the reason for not implementing is accepted by a senior official. • Independent verification. • Independent validation. • Any responses or clarifications to the comments in the independent verification or validation. • Rule-specific artifacts (if applicable).

Providers MUST also include the following basic metadata in their Security Decision Record: • Version • Date and time of last update • Source of update

Providers with 20x Class C Certifications MUST also include historical metrics in their Security Decision Record, supplying at least the following information for each applicable Key Security Indicator: • Summary of each metric over the past 30 days • Summary of metric up to the past year (where available) • All daily metric data up to the past year (where available)

Providers MUST also include short and simple high-level summaries of at least the following for each applicable Key Security Indicator: • Explanation of measures (and their objectives) that demonstrate the Key Security Indicator, or an explanation of the reason and resulting risk to customers for not having measures available for that Key Security Indicator. • Explanation of the cycle for any measures that are implemented persistently (if applicable). • Verification that the measures demonstrate the Key Security Indicator, or that the reason for not having them is accepted. • Verification that the automation in place is accurate and sufficient to demonstrate appropriate measures for the Key Security Indicator, or that automation is not necessary for each measure. • Validation that the measures are accurately produced and are in place and working as intended, or that the reason for not having them is valid.

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

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

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

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, penetration testing, incident response, automated control testing, supply chain monitoring, and other relevant capabilities; this process is called vulnerability detection. Vulnerability detection includes persistently verifying and validating that information resources and processes are operating as intended and documented for FedRAMP Practices. • FedRAMP's vulnerability detection (and response) rules are intended to set modern expectations for maintaining the security of a cloud service. Historical FedRAMP guidance on vulnerability scanning or continuous monitoring generally focused only on CVE-type vulnerabilities while leaving other types of vulnerabilities and exposures unaddressed. • Providers are encouraged to leverage their existing holistic security review, architecture review, and similar processes to meet these requirements. FedRAMP strongly discourages providers from implementing separate vulnerability detection and response processes for FedRAMP reporting that are operated by independent compliance branches unless these processes are consuming data directly from the areas of the cloud service that actively maintain it.

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 MUST treat problems or failures with their vulnerability detection and response processes as vulnerabilities.

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

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. • If it is not possible to fully mitigate vulnerabilities or remediate vulnerabilities, providers SHOULD instead partially mitigate vulnerabilities promptly, progressively, and persistently. • FedRAMP does not use the terms "mitigation" and "remediation" interchangeably. Mitigation is the process of reducing the risk and impact of a vulnerability through partial mitigation and even full mitigation; remediation is the process of entirely eliminating the vulnerability. A fully mitigated vulnerability will still exist (with negligible risk) until it has been remediated. This separation is based on the plain language definitions of these words. • Please refer to FedRAMP Definitions for strict interpretation in the FedRAMP context.

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 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) 26-04 or any successor guidance from CISA.

Providers of FedRAMP 20x Class C offerings MUST verify and validate the status of machine-based information resources at least once every 3 days.

Providers MUST verify and validate the status of non-machine-based information resources at least once every 3 months.

Providers with Class C Certifications SHOULD persistently perform vulnerability detection on all information resources that are NOT likely to drift, at least once every month.

Providers with Class C Certifications SHOULD persistently perform vulnerability detection on all information resources that are likely to drift, at least once every 14 days.

Providers with Class C Certifications SHOULD persistently perform vulnerability detection on representative samples of similar machine-based information resources, at least once every 3 days.

Providers with Class C Certifications SHOULD partially mitigate vulnerabilities, fully mitigate vulnerabilities, or remediate vulnerabilities to a lower Potential Agency Impact N-rating within the timeframes from evaluation shown below, factoring for the current Potential Agency Impact N-rating as defined in VER-EVA-EPA (Estimate Potential Agency Impact), internet reachability, and likely [ exploitability ]. PAIN Rating Timeframes: • PAIN 1: No specific timeframe defined • PAIN 2: 48 days (Internet-Reachable Vulnerability + Likely Exploitable Vulnerability); 128 days (Not Internet-Reachable Vulnerability + Likely Exploitable Vulnerability); 192 days (Not Likely Exploitable Vulnerability) • PAIN 3: 16 days (Internet-Reachable Vulnerability + Likely Exploitable Vulnerability); 32 days (Not Internet-Reachable Vulnerability + Likely Exploitable Vulnerability); 128 days (Not Likely Exploitable Vulnerability) • PAIN 4: 4 days (Internet-Reachable Vulnerability + Likely Exploitable Vulnerability); 8 days (Not Internet-Reachable Vulnerability + Likely Exploitable Vulnerability); 64 days (Not Likely Exploitable Vulnerability) • PAIN 5: 2 days (Internet-Reachable Vulnerability + Likely Exploitable Vulnerability); 4 days (Not Internet-Reachable Vulnerability + Likely Exploitable Vulnerability); 16 days (Not Likely Exploitable Vulnerability)

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

Providers MUST assume the exploitation of vulnerabilities can be automated UNLESS they have evidence proving otherwise.

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 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 internet-reachable vulnerabilities. • FedRAMP focuses on internet-reachable (rather than internet-accessible) to ensure that any service that might receive a payload from the internet is prioritized if that service has a vulnerability that can be triggered by processing the data in the payload. • The simplest way to prevent exploitation of internet-reachable vulnerabilities is to intercept, inspect, filter, sanitize, reject, or otherwise deflect triggering payloads before they are processed by the vulnerable resource; once this prevention is in place the vulnerability should no longer be considered an internet-reachable vulnerability. • A classic example of an internet-reachable vulnerability on systems that are not typically internet-accessible is SQL injection, where an application stack behind a load balancer and firewall with no ability to route traffic to or from the internet can receive a payload indirectly from the internet that triggers the manipulation or compromise of data in a database that can only be accessed by an authorized connection from the application server on a private network. • Another simple example is the infamous Log4Shell (https://en.wikipedia.org/wiki/Log4Shell) vulnerability from 2021, where exploitation was possible via vulnerable internet-reachable resources deep in the application stack that were often not internet-accessible themselves.

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities. • The simple reality is that most traditional vulnerabilities discovered by scanners or during assessment are not likely to be exploitable; exploitation typically requires an unrealistic set of circumstances that will not occur during normal operation. The likelihood of exploitation will vary depending on so many factors that FedRAMP will not recommend a specific framework for approaching this beyond these rules. • The proof, ultimately, is in the pudding - providers who regularly evaluate vulnerabilities as not likely exploitable without careful consideration are more likely to suffer from an adverse impact where the root cause was an exploited vulnerability that was improperly evaluated. If done recklessly or deliberately, such actions will have a negative impact on a provider's FedRAMP Certification.

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the potential agency impact of exploitation on government customers AND assign one of the following Potential Agency Impact N-ratings (PAIN): • N1: Exploitation could be expected to have minimal customer effects on one or more agencies that use the cloud service offering. • N2: Exploitation could be expected to have narrow customer effects on one or more agencies that use the cloud service offering. • N3: Exploitation could be expected to have a disruptive customer effect on one agency that uses the cloud service offering. • N4: Exploitation could be expected to have a debilitating customer effect on one agency that uses the cloud service offering OR a disruptive customer effect on more than one federal agency that uses the cloud service offering. • N5: Exploitation could be expected to have a debilitating customer effect on more than one agency that uses the cloud service offering.

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; FedRAMP Vulnerability Detection and Response rules are then applied to these consolidated groupings of vulnerabilities instead of each individual detected instance.

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 Agency Impact N-rating • 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 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 MUST report vulnerability detection and response activity (including persistent verification and validation) to all necessary parties persistently, summarizing ALL activity since the previous report; these reports are FedRAMP Certification Data and are subject to FedRAMP Certification Data Sharing rules.

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 Agency Impact N-rating of exploitation • Time and Potential Agency Impact N-rating of each completed and evaluated reduction in Potential Agency Impact N-rating • Estimated time and target Potential Agency Impact N-rating of next reduction in Potential Agency Impact N-rating • 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 with Class C Certifications SHOULD evaluate ALL vulnerabilities as required by VER-EVA (Evaluation) within 5 days of detection.

Providers with Class C Certifications SHOULD treat internet-reachable likely exploitable vulnerabilities where Potential Agency Impact N-rating > 3 as a FedRAMP Reportable Incident until they are partially mitigated vulnerabilities at N3 or below.

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 MUST report vulnerability detection and response activity to all necessary parties in a consistent format that is human readable at least monthly.

Providers with Class C Certifications SHOULD make all recent historical vulnerability detection and response activity available in JSON 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 with Class C Certifications MAY treat likely exploitable vulnerabilities that are NOT internet-reachable where Potential Agency Impact N-rating = 5 as a FedRAMP Reportable Incident until they are partially mitigated vulnerabilities at N4 or below.