Which compliance obligation includes security requirements that apply specifically to federal government agencies in the United States?

General

The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that promotes the adoption of secure cloud services across the federal government by providing a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. FedRAMP empowers agencies to use modern cloud technologies, with an emphasis on security and protection of federal information.

FedRAMP eliminates duplicative efforts by providing a common security framework. Agencies review their security requirements against a standardized baseline. A Cloud Service Provider (CSP) goes through the authorization process once, and after achieving an authorization for their Cloud Service Offering (CSO), the security package can be reused by any federal agency.

FedRAMP enables the federal government to accelerate the adoption of cloud computing by creating transparent standards and processes for security authorizations and allowing agencies to leverage security authorizations on a government-wide scale.

Yes, FedRAMP is mandatory for all executive agency cloud deployments and service models at the Low, Moderate, and High risk impact levels. Please refer to the FedRAMP Policy memo for further information pertaining to FedRAMP’s applicability.

All official FedRAMP documentation is maintained on FedRAMP.gov. Opportunities for large-scale public comment periods will be messaged via a number of channels and methods, including the FedRAMP.gov website, "Focus on FedRAMP" blog, or by subscribing to FedRAMP email updates.

TIC modernization aligned with the Office of Management and Budget (OMB) M-19-26 provides flexibility for TIC capabilities and architectures supporting cloud implementations. Generally, TIC controls are aligned with the National Institute of Standards and Technology (NIST) SP 800-53 and should be aligned and evaluated to support the appropriate FedRAMP security control baselines. Determining the applicable and appropriate controls is a responsibility of both CSPs and agencies to establish a solution architecture that supports TIC policy enforcement points and other protections described in the TIC 3.0 Reference Architecture and TIC 3.0 Security Capabilities Catalog.

FedRAMP is FISMA for the cloud. Per FISMA, the National Institute of Standards and Technology (NIST) is responsible for establishing “policies which shall set the framework for information technology standards for the Federal Government.” Based on this law, NIST developed the Risk Management Framework .

Both FedRAMP and FISMA use the NIST SP 800-53 security controls. The FedRAMP security controls are based on NIST SP 800-53 baselines and contain controls, parameters and guidance above the NIST baseline that address the unique elements of cloud computing.

There is a shared security responsibility model when using cloud products. Cloud Service Providers (CSPs) and agencies (customers) both assume important security roles and responsibilities to ensure data is protected within cloud environments. CSPs are required to submit a Control Implementation Summary (CIS) workbook as an attachment to the System Secruity Plan (SSP). The CIS workbook identifies security controls that the CSP is responsible for implementing, security controls that the agency (customer) is responsible for implementing, security controls where there is a shared CSP/agency responsibility, and security controls that are inherited from an underlying FedRAMP Authorized Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS). The CIS workbook also includes a Customer Responsibility Matrix (CRM) worksheet tab. CSPs must use the CRM to describe the specific elements of each control where the responsibility lies with the customer. Further details are also provided within the CSP’s SSP.

FedRAMP provides two CIS Workbook templates: one for Low and Moderate systems and one for High systems. Both are available on FedRAMP.gov’s Documents & Templates page.

Federal Agencies

The FedRAMP approver that can sign a Package Access Request Form [PDF - 278KB] is either the agency’s Chief Information Security Officer (CISO), Authorizing Official (AO), Authorizing Official Designated Representative (AODR) or Designated Approving Authority (DAA). If the form is signed by a DAA, that person must be at a level that has the authority to grant an Authority to Operate (ATO) for an information system.

If a Cloud Service Offering (CSO) is listed as FedRAMP Authorized on the FedRAMP Marketplace, it has successfully completed the FedRAMP Authorization process with the Joint Authorization Board (JAB) or a federal agency. The FedRAMP Authorized designation indicates FedRAMP requirements are being met and a CSO’s security package is available for agency reuse. This means that any agency can request access to the security package for a FedRAMP Authorized CSO, review the security package, and issue their own Authority to Operate (ATO) for the product.

When reusing FedRAMP security packages, agencies should complete and sign the FedRAMP Package Access Request Form [PDF - 278KB] and if the requestor is not a federal employee they must also complete the associated Non-Disclosure Agreement for the FedRAMP Authorized CSO, conduct a package review and risk analysis, understand and implement customer responsibilities, issue an ATO and send ATO letters to , and perform continuous monitoring responsibilities. More guidance can be found in the Reusing Authorizations for Cloud Products Quick Guide [PDF - 72KB].

As a registered OMB MAX user, you have the ability to “watch” a page. To watch a page, click the icon labeled “watchers” in the upper-right corner of the screen. When a page is being watched, you will be notified via email of changes made to that page. This can be particularly helpful for Cloud Service Providers (CSPs), agencies, or Third Party Assessment Organizations (3PAOs) as they anticipate the uploading of key documents, like a System Security Plan (SSP) or Security Assessment Report (SAR). To stop watching a page, simply click again on the icon in the upper-right corner of the screen.

Simply email to request access extensions. Agencies can work directly with Cloud Service Providers (CSP) to obtain a copy of the package and request permissions to save, print, email, post, publish, or reproduce. If your agency has already issued an Authority to Operate (ATO) you can submit the ATO to and receive permanent access to the package as long as an ATO is on file with the FedRAMP Program Management Office (PMO).

An Initial Agency Partner or initial authorizing agency refers to the first agency to grant an Authority to Operate (ATO) using FedRAMP standards and baselines for the Cloud Service Offering (CSO). Some stakeholders use the term "Agency Sponsor.” FedRAMP does not recognize the concept of an agency sponsor because the ATO granted by the initial authorizing agency is not a government-wide risk acceptance. As described in FedRAMP's Reuse Quick Guide, OMB Circular A-130 requires agencies to individually authorize operation of an information system and to explicitly accept the risk. Each agency that wishes to use the CSO will conduct its own risk review of the authorization package and grant its own ATO.

It depends on the quality of the authorization package. Because the initial authorizing agency is the first agency to review the authorization package, the process for getting to an informed risk-based decision may take longer and require more effort if there are aspects of the authorization package that are unclear, incomplete, inaccurate, or inconsistent.

The FedRAMP Program Management Office (PMO) provides guidance to Cloud Service Providers (CSPs) and Third Party Assessors (3PAOs) on how to deliver a high quality authorization package, but if the agency team is unable to determine the actual security posture of the Cloud Service Offering (CSO) due to poor quality, the agency will provide feedback. The feedback may result in modifications to the package deliverables and/or additional testing, and additional review cycles.

No. It is not the initial authorizing agency’s responsibility to conduct ConMon oversight on behalf of all other agencies. OMB Circular A-130 requires federal agencies to implement the Risk Management Framework (RMF) described in NIST SP 800-37. The RMF process includes a Monitor step. The purpose of this step is to maintain ongoing situational awareness about the security posture of the system in support of risk management decisions. Each agency that issues an ATO or ATU for a cloud offering must review the Cloud Service Provider’s (CSP’s) ConMon activities to ensure the security posture remains sufficient for its own use and supports an ongoing authorization. This includes reviewing the monthly Plan of Action and Milestones (POA&M), approving deviation requests and significant change requests, and reviewing the results of the annual assessment. The FedRAMP Program Management Office (PMO) encourages CSPs who have more than one customer agency to streamline the ConMon process and potentially minimize duplicative efforts in a way that helps each agency still perform their due diligence related to ConMon. The PMO developed a recommended Collaborative ConMon approach. This approach is described in the Guide for Multi-Agency Continuous Monitoring. Collaborative ConMon benefits agencies by allowing them to share responsibility for ConMon oversight, and it benefits the CSP by creating a central forum for addressing questions and achieving consensus related to deviation requests, significant change requests and the annual assessment - versus having to coordinate with each agency separately.

NIST SP 800-37 describes the ATO and ATU as very similar in that they both are the mechanisms for documenting and accepting risk of information systems, and approving the use of the system by the agency. ATUs are intended to be used for shared systems, but still document accepting risk and approving use (based on an external security assessment). Though FedRAMP accepts both ATOs and ATUs, there must be at least one ATO on file for the Cloud Service Offering (CSO) in order for FedRAMP to accept an ATU.

Agencies should first notify the Cloud Service Provider (CSP) that they plan to rescind their Authorization to Operate (ATO) as they no longer are using the service. After they have notified the CSP, the agency should send an email to , CCing their CSP, which notifies the FedRAMP Program Management Office (PMO) that the service is no longer in use at the agency, and indicates the agency will rescind the ATO letter by a specific date.

A CSO must have at least one active Authorization to Operate (ATO) from a federal agency on file with the FedRAMP Program Management Office (PMO) to maintain an Authorized designation on the FedRAMP Marketplace. Having an ATO on file with FedRAMP ensures at least one agency is conducting oversight of the Cloud Service Provider’s (CSPs) Continuous Monitoring (ConMon) activities.

If a CSP's service offering loses its only ATO on file with FedRAMP, the service offering may remain listed on the FedRAMP Marketplace as FedRAMP Ready for a maximum of 12 months while the CSP works to obtain a new ATO from a federal agency. If a new ATO is obtained during this period, the CSO will regain its FedRAMP Authorized designation. If an ATO is not achieved within 12 months, the CSP may pursue a Readiness Assessment Report to maintain its FedRAMP Ready designation, or transition to In Process by fulfilling the requirements described in FedRAMP’s Marketplace guidance. This provision does not apply to service offerings that lose their only ATO due to lack of maintaining an acceptable security posture.

Please review page 8 of FedRAMP’s Marketplace Designations for Cloud Service Providers for a full explanation of the provision for CSPs that lose their only ATO on file.

The FedRAMP Policy Memo does not apply to private clouds intended for a single organization that are implemented on premises (i.e., within a federal facility). In this scenario, agencies continue to follow the FISMA process and use the appropriate NIST security standards and guidelines for their private cloud-based information systems.

In the scenario where a dedicated private cloud application is deployed on top of another cloud (IaaS, PaaS) versus within a federal facility, the agency should use the FedRAMP process and baselines to authorize the cloud service. However, the FedRAMP PMO does not review packages for private clouds, grant a FedRAMP Authorized designation, or list them on the Marketplace because the concept of “reuse” does not apply.

Cloud Service Providers

There are three listing designations available on the FedRAMP Marketplace: FedRAMP Ready, In Process, or Authorized.

• FedRAMP Ready indicates that a Third Party Assessment Organization (3PAO) attests to a CSP’s readiness for the authorization process, and that a Readiness Assessment Report (RAR) has been reviewed and approved by the FedRAMP Program Management Office (PMO). The RAR documents the CSP’s capability to meet FedRAMP security requirements.
• In Process is a designation provided to CSPs that are actively working toward a FedRAMP Authorization with either the Joint Authorization Board (JAB) or a federal agency.
• The Authorized designation is provided to CSPs that have successfully completed the FedRAMP Authorization process with the JAB or a federal agency. This designation indicates the CSPs security package is available for agency review and reuse. Private cloud offerings are not listed on the FedRAMP Marketplace as they do not meet the intent of “do once, use many times” and thus the security packages are not considered reusable.

More detail about these designations and how to be listed on the Marketplace can be found in the FedRAMP Marketplace: Designations for Cloud Service Providers [PDF - 652KB] guidance document.

As a first step, please complete the FedRAMP Program Management Office’s (PMO’s) Cloud Service Provider (CSP) Information Form to notify our team of your intent to pursue FedRAMP Authorization with a federal agency and to initiate scheduling of an intake call with the PMO. During this call, the PMO will walk you through the Agency Authorization process. Additionally, please review the Get Authorized: Agency page and the FedRAMP Agency Authorization Playbook [PDF - 1.24MB]. This document provides an overview of every aspect of the Agency Authorization process, including roles and responsibilities for the CSP and agency at each step. If you have any questions after reviewing guidance materials, please forward them to .

FedRAMP recognized Third Party Assessment Organizations (3PAOs) and FedRAMP Authorized CSPs may use the FedRAMP logo. Use of the FedRAMP logo, in conjunction with qualified products, services, or organizations, does not require approval. The FedRAMP Program Management Office (PMO) must approve any major educational or promotional campaigns that feature the FedRAMP logo prior to use. The submitted materials will be reviewed for consistency with these guidelines within two weeks of receipt of the materials. Materials should be submitted to with the following in the subject line: “FedRAMP Branding Review.”

Please review the FedRAMP Branding Guidance [PDF - 932KB] for more answers to your FedRAMP logo questions.

To achieve a FedRAMP Ready designation, a CSO’s MFA solution must comply with NIST Special Publication (SP) 800-63B, which requires the use of FIPS 140 validated encryption for MFA tools. While agencies may accept risk by allowing a CSP to work through POA&M actions to achieve compliance with NIST SP 800-63B requirements, a Readiness Assessment Report (RAR) has no authorizing official to accept and approve risk for open POA&Ms. A FedRAMP Ready designation indicates to agencies that a cloud service can be authorized without significant risk or delay due to noncompliance. The use of FIPS 140 validated cryptographic modules, where encryption is required, is a federal mandate, as indicated in the RAR template. This applies to MFA tools as well.

The FedRAMP PMO has provided additional resources below that apply to all MFA tools, where required (authenticators and verifiers).

MFA resources:

• On low baseline systems, FIPS 140 validated crypto modules are only required for MFA verifiers, not authenticators.
• On Moderate baseline systems, user-provided (“bring-your-own”) authenticators are exempt from having to meet FIPS 140 requirements, particularly in the government-to-public use case.

Third Party Assessors

3PAOs play a critical role in the authorization process by assessing the security of a Cloud Service Offering (CSO). As independent third parties, they perform initial and periodic assessments of cloud systems to ensure they meet FedRAMP requirements. The federal government uses 3PAO assessments as the basis for making informed, risk-based authorization decisions for the use of cloud products and services. 3PAOs are accredited by the American Association for Laboratory Accreditation (A2LA). A list of FedRAMP recognized 3PAOs can be found on the FedRAMP Marketplace under the “Assessors” tab.

In addition to the critical role that 3PAOs play in assessing cloud services, some Cloud Service Providers (CSPs) use 3PAOs as consultants to help prepare security documentation or provide security advisory services. When CSPs use 3PAO advisors, they must select a different 3PAO to conduct an assessment of their cloud service to ensure that the assessor maintains impartiality.

In order to become a FedRAMP recognized 3PAO, the American Association for Laboratory Accreditation (A2LA) must perform an initial assessment of the 3PAO and provide an initial assessment recommendation to FedRAMP for approval. For a 3PAO to maintain its FedRAMP recognition, A2LA must perform a favorable annual review and a full on-site reassessment every two years. A2LA assessments ensure 3PAOs meet the requirements of ISO/IEC 17020 (as revised) and FedRAMP-specific knowledge requirements. More information on becoming an accredited 3PAO may be found on the A2LA website .

For the JAB Authorization process, the assessment organization must be a FedRAMP recognized 3PAO. For the Agency Authorization process, a 3PAO is recommended, but not required. A CSP’s agency partner may choose to use their own Independent Verification and Validation (IV&V) organization to assess the system. If an agency chooses to use their own IV&V team, they must submit an attestation regarding the team’s independence, and the IV&V team must use FedRAMP templates for the assessment and follow all FedRAMP requirements.

For the JAB Authorization process, Cloud Service Providers (CSPs) must use a FedRAMP recognized 3PAO for annual assessments of its cloud system and to evaluate the impact of some changes a CSP makes to its cloud system. For the Agency Authorization process, a 3PAO is recommended, but not required. Additionally, some CSPs may acquire 3PAO services for monthly Continuous Monitoring.

Cloud Service Offerings (CSOs) can obtain an ATO or P-ATO one of two ways:

P-ATO through the Joint Authorization Board (JAB): a JAB P-ATO is an initial approval of the Cloud Service Provider (CSP) authorization package by the JAB that any federal agency can leverage to grant an ATO for the use of the cloud service within their agency. The JAB consists of the Chief Information Officers (CIOs) from the Department of Defense (DoD), the Department of Homeland Security (DHS), and the General Services Administration (GSA), supported by designated technical representatives (TRs) from their respective member organizations. The JAB P-ATO is called a provisional ATO because there is no risk accepted by JAB CIOs. The JAB P-ATO signifies all three JAB agencies reviewed the security package and deemed it acceptable for the federal community. In turn, agencies review the JAB P-ATO and the associated security package and clear it for their agency’s use. In doing so, the agency issues their own authorization to use the product. Additionally, the JAB will conduct continuous monitoring for systems that have earned a P-ATO.

Agency ATO through the Agency Authorization process: a CSP works directly with the agency partner who reviews the cloud service’s security package. After completing a security assessment, the agency Authorizing Official (or their designee) can issue an ATO.

For more information about these two authorization paths, please visit our Agency Authorization and JAB Authorization pages.

No, using a FedRAMP Authorized infrastructure does not automatically make your service FedRAMP compliant. Each layer (i.e., IaaS, PaaS, and SaaS) must be evaluated on its own and become FedRAMP Authorized. However, when your software sits on a FedRAMP Authorized infrastructure, it will inherit controls from that authorized system and you can explain this in your documentation.

Yes, a FedRAMP-accredited Third Party Assessment Organization (3PAO) must perform an announced penetration test as part of the assessment/testing process for Moderate and High systems. For more information, please refer to the FedRAMP Penetration Test Guidance [PDF - 984KB].

Continuous Monitoring

Continuous Monitoring ensures a service offering maintains an appropriate security posture for the life of the system at an agency. Cloud Service Providers (CSPs) maintain and validate the security posture of their service offering through vulnerability management, including monthly operating system, database, and web application scanning reports. They also conduct an Annual Assessment and report incidents. Please refer to the FedRAMP Continuous Monitoring Strategy Guide [PDF - 1.11MB] for a list of all continuous monitoring deliverable requirements and to the FedRAMP Continuous Monitoring Performance Management Guide [PDF - 800KB] for guidance on continuous monitoring and ongoing authorization in support of maintaining a security authorization that meets the FedRAMP requirements.

All of the false positives found during the Annual Assessment should be added to the Plan of Action and Milestones (POA&M). If they are approved before the SAR is closed/signed, they are moved to the “Closed POA&M Items” tab. If they have not been approved, they should remain in the “Open POA&M Items” tab until approved. Then, at least annually during assessment, the false positives should be evaluated for continued false positive status. For more information on handling the Annual Assessment and scan findings review the FedRAMP Continuous Monitoring Strategy Guide [PDF - 1.11MB].

A change in infrastructure would be considered a significant change that would need to be evaluated for the scope of the change, impact on the risk posture, and could possibly result in the need for re-authorization. See the FedRAMP Program Management Office’s (PMO’s) Significant Change Policies and Procedures guidance [WORD - 563KB] for more information.

Acquisition

No. Agencies cannot require a JAB P-ATO as a requirement to bid on a federal contract. Federal agencies cannot include a JAB P-ATO as a condition of the contract as no agency can commit the JAB to issuing a P-ATO.

Program offices seeking to expedite a FedRAMP Authorization can consider source selection criteria that can be used in evaluating Cloud Service Offerings (CSOs) that may already have a JAB P-ATO. Inclusion of such evaluation criteria should be discussed with the agency acquisition integrated project team (IPT), including appropriate legal representation.

FedRAMP requirements apply to all federal agencies when federal information is collected, maintained, processed, disseminated, or disposed of by Cloud Service Providers (CSPs). Federal agencies are responsible for ensuring the FedRAMP requirements are met. Contractors are held accountable for performance written into a contract. Program and project managers must include FedRAMP requirements in performance criteria, deliverables, and other appropriate performance outcomes to facilitate inclusion in contract awards.

No. The FedRAMP process builds on the National Institute of Standards and Technology (NIST) FISMA baseline controls by removing requirements that are not applicable to commercial entities and replacing those with controls more appropriate for ensuring security related to protecting information maintained on behalf of the federal government.

Perhaps. FedRAMP Ready means a CSP has expressed an interest in becoming a federal provider by sharing information with the federal government that indicates they can meet several of the baseline FedRAMP criteria. FedRAMP Ready does not mean the vendor has achieved FedRAMP Authorization via the Joint Authorization Board (JAB) or an agency.

In some cases, but only if there are an adequate number of vendors to allow for effective competition. Inclusion of FedRAMP Authorization as a condition of contract award or use as an evaluation factor should be discussed with the agency acquisition integrated project team (IPT), including appropriate legal representation.

Yes. If an agency has constraints and/or requirements for specific data locations (e.g., data-at-rest), the agency should make those specific requirements known through the solicitation process. FedRAMP does specify data location requirements in the High baseline as part of control SA-9 (5); however, FedRAMP does not provide or specify data location requirements for the other baselines. Beyond FedRAMP, other federal statutes, regulations, or policies may apply.

No. Federal agencies have the responsibility and discretion to include any requirements necessary to protect information. FedRAMP sets a baseline for protecting federal information in a cloud environment.

FedRAMP requires CSPs to describe their organization’s personnel screening requirements. If an agency has requirements for federal background investigations, or additional screening and/or citizenship and physical location (e.g., U.S. citizens in Continental United States [CONUS] offices only), then those requirements would need to be specified in the solicitation language, which may affect bid pricing.

Security

Security Control-13 (SC-13) requires that FIPS 140-validated or NSA-approved cryptographic modules (CMs) are used where cryptography is required. For example, encryption is required for federal data at-rest [SC-28], data in-transit [SC-8(1)], and authentication [IA-2(11)] for FedRAMP Moderate and High systems.

SC-13 applies to all required cryptographic functions. Cryptography encompasses more than just encryption. It includes digital signatures, encryption, key management, message authentication, random number generation, and secure hashing.

The status of a cryptographic module (CM) submitted for testing and validation can be found at the National Institute of Standards and Technology (NIST) website.

Usually not. Some vendors may use terms such as FIPS-compliant or FIPS-approved because the product is using a FIPS-approved algorithm, but not using a National Institute of Standards and Technology (NIST)-tested cryptographic module (CM). The product must actually be submitted for testing and validated through the NIST Cryptographic Module Validation Program (CMVP) to be considered FIPS-validated. Non-validated cryptography is viewed by NIST as providing no protection to the information or data - in effect, the data would be considered unprotected plaintext. Other important considerations:

• FIPS-validated CMs must be configured in an approved mode, which is documented in the associated security policy.
• Many FIPS-validated CMs also include non-approved algorithms even when run in FIPS mode. Only algorithms listed as approved in the CM’s Security Policy should be used.
• Third Party Assessment Organizations (3PAOs) validate the use of a FIPS-validated CM by checking the certificate number, validating that the CM is configured in an approved mode, and only uses algorithms listed as approved in the CM’s Security Policy. Agencies and FedRAMP reviewers will also check the certificate number for each CM listed in the FedRAMP System Security Plan (SSP) and other documents to confirm validation status.

National Security Agency (NSA)-tested and approved cryptographic modules (CMs) are also acceptable. The NSA validation status of a CM can be found at the National Information Assurance Partnership (NIAP) website. Since FIPS 140-validated CMs are by far more commonly used in Cloud Service Offerings (CSOs) than NSA-approved CMs, we will refer to FIPS mode from here on.

Any FIPS certificate with a status of Active is acceptable. Active FIPS 140-2 certificates can be accepted by federal agencies until September 22, 2026. After that time, the Cryptographic Module Validation Program (CMVP) will place the FIPS 140-2 validated modules on the Historical List, allowing agencies to continue using these modules for existing applications only. Active FIPS 140-3 certificates are acceptable now.

No. The SC-13 requirement applies to cryptographic modules (CMs) used to implement TLS; the use of TLS alone does not satisfy the requirement. While TLS 1.2 and above are required at the protocol level, it is necessary to demonstrate that FIPS 140-validated CMs are used to implement the protocol. It is worth noting that some FIPS 140-2 validated modules may not support cryptographic algorithms to allow for TLS 1.3. In addition to listing ports and protocols, CSPs must also identify the component that performs the encryption function along with the FIPS validation certificate number. For each component and data flow, the SSP Data Flow Diagram(s) and control implementation statements should clearly depict one of the following:

• FIPS-validated CM is implemented [with certificate number in SC-13 control description]
• Encryption is implemented, but not FIPS-validated
• Encryption is not implemented

Documentation that lacks accounting of FIPS status for each component delays the authorization process.

• For Cloud Service Offerings (CSOs) pursuing FedRAMP Ready (required for a FedRAMP JAB authorization), all federal mandates must be met. This means FIPS 140-validated modules must be implemented where encryption is required. Gaps cannot be addressed within a Plan of Action and Milestones (POA&M).
• For CSOs pursuing a FedRAMP authorization via the Agency path, Agency Authorizing Officials (AOs) may risk-accept FIPS 140 gaps under some circumstances. The first step is for the 3PAO to fully document and validate the FIPS status and document gaps in the POA&M to inform the AO’s risk-based authorization decision.

• CSP should take the approach that FIPS-validated CMs need to be implemented everywhere cryptography is required, and not look for exceptions.
• FedRAMP documentation should clearly show encryption and FIPS validation status for every data store, every data flow and authentication method.
• Plan of Action and Milestones (POA&M) should be established where gaps exist. The POA&M should include the reason for using non-compliant modules, for example:
• Migrated to a new version of the product; CM is undergoing National Institute of Standards and Technology (NIST) FIPS validation
• FIPS certificate for current version of the product is now “historical”; vendor seeking FIPS validation for new product
• Product does not support FIPS-validated encryption
• Component breaks in FIPS-mode, waiting for vendor patch

• POA&Ms should include a clear remediation plan and timeline to help inform the AO’s decision, for example:
• Replace component with FIPS-validated module prior to authorization
• Patch when compliant version available from vendor
• Remain on historic version of the module while awaiting migration to compliant version of the product
• Remain on historic version of the module while awaiting migration to compliant version of CM or product provided by different vendor

Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 control for Configuration Settings is CM-6; however, compliance check findings often map directly to specific 800-53 controls.

Cloud Service Providers (CSPs) and Third Party Assessment Organizations (3PAOs) typically combine compliance check findings into a single CM-6 finding, which is acceptable. However, for initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, of where risks exist. Therefore, 3PAOs must also analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding Security Assessment Reports (SAR) Risk Exposure Table (RET), which are then documented in the CSP’s Plan of Action and Milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.

During monthly continuous monitoring, new findings from CSP compliance checks may be combined into a single CM-6 POA&M item. CSPs are not required to map the findings to specific controls because controls are only assessed during initial assessments, annual assessments, and significant change requests.