The FedRAMP® Program Management Office (PMO) used to publish monthly Tips and Cues that provided helpful information about FedRAMP to Agencies, CSPs, 3PAOs, and other stakeholders. Tips and Cues have been integrated into FAQs. Please reach out to firstname.lastname@example.org with any questions.
How Can We Help You?
Search the FAQs by keyword or browse the topics below.
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.
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 email@example.com, 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 firstname.lastname@example.org 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 email@example.com 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 Collaborative ConMon Quick Guide. 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 firstname.lastname@example.org, 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 on the About FedRAMP Marketplace page.
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 email@example.com.
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 firstname.lastname@example.org 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).
- 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. Note: This exemption does not apply to CSP personnel. The FIPS 140 requirement still applies to CSP employee and contractor authenticators.
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.
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 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.
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 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.
- 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.
The PMO recognizes that the timeline for issuing “In Process” requests differs from agency to agency. Cloud Service Providers (CSPs) can proceed with the assessment against the Rev. 4 baseline under the following conditions:
- The CSP provides evidence they are under contract with a 3PAO (with a defined assessment start date) or are actively undergoing an assessment
- The CSP has received approval from the Agency partner to proceed with the assessment against the Rev. 4 baseline. This approval should be noted in the In Process request when is it submitted by the Agency
No, if your annual assessment is scheduled to occur between July 3, 2023 and December 15, 2023 you can proceed with your 2023 annual assessment using the Rev. 4 baseline. You must implement the Rev. 5 baseline prior to your 2024 annual assessment, during which your Rev. 5 implementation will be tested.
Cloud Service Providers (CSPs) will be implementing Rev. 5 controls based on the plans created from their Rev. 4 to Rev. 5 gap analysis. SCRs will be based on Rev. 4 or Rev. 5 determined by those CSP-specific implementation plans, and as coordinated with your Authorizing Official (AO).
Please refer to the "FedRAMP Baseline Rev. 5 Transition Schedule" section of the FedRAMP Baseline Revision 5 Transition Plan to determine your place in the transition schedule and what guidance you should follow in coordination with guidance from your Authorizing Official (AO).
If a Security Technical Implementation Guide (STIG) configuration parameter is more restrictive than the associated FedRAMP Rev. 5 baseline requirement, the Cloud Service Provider is under no obligation to implement the STIG parameter unless it is covered under an Executive Order or DHS Emergency Directive.
Yes, Cloud Service Providers in Continuous Monitoring (ConMon) are required to utilize automated scanning tools to perform service configuration scans monthly and provide the scan results to the FedRAMP documentation repository as part of the monthly ConMon deliverable. 3PAOs will ensure that service configuration scans are performed during annual assessments and provide those scans as part of the SAR.
While a WBS is not required, it may be requested by your Authorizing Official (AO). Please confirm your AO's expectations. However, the POA&M should have sufficent detail so that the AO can track the activities and progress made.
Each control should be tracked separately as a unique POA&M so that they can be managed separately.
Cloud Service Providers must manage their Plan of Actions and Milestones (POA&Ms) the same way they manage POA&Ms during continuous monitoring.
As a companion document to the Rev. 5 transition plan, the Control Selection Guide is scheduled for release in the coming weeks. Cloud Service Providers, 3PAOs, and Agencies will use the guide to determine which controls need to be assessed during that annual assessment.
POA&Ms created to document Rev. 5 control gaps can be captured as Low severity "manual findings." Once the Rev. 5 control is fully implemented, the CSP will identify the evidence that supports POA&M closure in column Y "Supporting Documents" of the POA&M. For CSPs in Continuous Monitoring, we recognize this may result in a spike of past due POA&Ms during the transition. Please work with your AO determine the appropriate course of action.
CSPs with a FedRAMP Authorization must utilize the Rev. 5 SSP template to identify the gaps between their Rev. 4 control implementations and the Rev. 5 requirements. CSPs should have already documented Rev. 4 to Rev. 5 gaps within the POA&M and the Rev. 5 CIS/CRM template. This provides stakeholders visibility into the Rev. 4 controls that have changed and what the CSP will do to implement the Rev. 5 requirements while also documenting the entire Rev. 5 gap.
Each control that the CSP is documenting a gap for should be a separate POA&M entry. CSPs should not group individual controls together so that the AO and leveraging systems have the necessary fidelity to understand each Rev. 5 control status.
For CSPs pursuing an initial FedRAMP authorization, deviations from the FedRAMP Baseline Revision 5 Transition Plan must approved by the AO. For CSPs in Continuous Monitoring, deviations must be documented in the CSP's transition plan (due on 9/1/2023) AND approved by the AO.
Yes. The FedRAMP PMO is not providing a template.
FedRAMP is not providing a SCRM template at this time; however, NIST SP 800-161 includes sample SCRM templates in Appendix D.
CSPs are required to perform (or acquire 3PAOs to perform) Red Team exercises in accordance with CA-8(2) and must provide evidence in the form of a Red Team Test Plan that documents the scope, methodology and approach of the exercise. CSPs must also provide the results of the exercise in the form of a Red Team Test Report. 3PAOs are required to validate and attest to the Red Team Test Plan and Report during the initial SAR testing and during annual assessment testing.
Not at this time. However, we will continue to have discussions to determine whether this is a capability to include in the future.
CSPs will document all operational requirements and false positives from configuration checks the same way that they do vulnerabilities identified from automated scanning tools. Please consult the POA&M Template Completion Guide for further guidance. Not applicable and alternative implementations for configuration settings should be discussed with your AO to determine the appropriate course of action.
Since your Readiness Assessment was already underway when the new baselines and RAR templates were released, you will still be able to acheive FedRAMP Ready based on the Rev 4 RAR templates and controls.
There are some privacy-related controls in the FedRAMP baselines; however, like with Rev 4, FedRAMP did not include the privacy overlay (Privacy Control Baseline) that NIST has defined in SP 800-53B or any PT controls as part of the FedRAMP baselines. It is the responsibility of each agency to determine their own privacy-related requirements and work with the CSP to make sure those controls are implemented. Privacy controls can flucuate greatly depending on the data types, which is why these are not included as part of the FedRAMP baselines.CSPs should work with their AO to determine if the Agency has privacy requirements above and beyond what is specificed in the Rev. 5 FedRAMP baselines. There are no current plans to provide a Rev. 5 PTA/PIA template for CSPs to complete. Agencies should execute a PTA/PIA to ensure that they are meeting their privacy requirements.
FedRAMP will leverage NIST SP 800-161 as the requirements for supply chain considerations for all commercial, proprietary, and open source sources in Cloud Service Offerings (CSO)s. If the technology is being used or leveraged by the CSO, the supply chain controls apply. The Supply Chain Risk Management Plan should enumerate all the products and the plan for managing any risks including open source. According to the supply chain controls, CSPs need to document the scope, methodology and the depth of documenting, managing and testing for the source of products or code being used. The supply chain controls are in scope for audits for FedRAMP but the supplier management is the responsibility of the CSP. 3PAOs will be examining the records and documents, not the individual suppliers.
While the supplemental guidance states that security awareness and security literacy training are two separate training activities, there is no requirement for giving separate trainings, only that the training covers both the topic categories. There is no requirement to provide distinct basic and advanced training. However, organizations may decide to separate basic and advance concepts or combine them. Organizations determine the content of literacy training and awareness based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework).
Control plane traffic in the context of external telecommunications systems are the exchanges with the telecommunication providers that allow for the use of data and voice services and include, for example, management protocols, Domain Name Services (DNS) and Border Gateway Protocol (BGP). The term management plane is not a NIST term and not mentioned in this control but in this context it would be the plane where device management and monitoring takes place inside the authorization boundary. While there would not be a prescribed implementation detecting changes the protocols that defined network level changes do have safeguards built. How the CSP chooses to monitor for changes will be dependent on the implementation.
CSPs can assess the Baseline Risk Factors defined in NIST SP 800-161, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, Appendix E Table E-1. CSPs will need to work with their vendors to gain access to the necessary documentation that the CSP can review to determine whether the vendor is in alignment with NIST 800-171 or equivalent framework. That may be an internal assessment performed by the supplier, a third-party, or in support of a framework such as PCI or ISO/IEC 27001 and others.
Network connections are represented in several areas of an SSP. The reference number assigned in the Data in Transit (DIT) table of Appendix Q should be used to align these entries to the Ports, Protocols, Service (PPS) table, and DIT lines on the Data Flow Diagram (DFD).
All DIT connections should be included in all three places and are consistently aligned.The Rev. 5 templates address this by:
- Ensuring all DIT is represented in all three locations
- Provides a reference number for traceability from one to another
- Reduces clutter on the DFD by requiring only the reference number on each line
It is expected that a single entry in the Appendix Q DIT table will have the same properties in the PPS table, and on the DFD. CSPs are encouraged to consolidate the DIT table to unique entries rather than a row for every connection in the CSO.
This control does not prescribe the use of any specific tool or technology. Understanding data types and location, and when the data is transmitted internally and outside of the boundary can be accomplished through multiple implementations. This functionality should be in place in operations and can inform design and architecture decisions. If there is a single solution or there are multiple technologies that use automated mechanisms to identify the location and type of data and protect the organizational and privacy data, that meets the intent of the control. The solution should be documented in the SSP. Ultimately, the authorizing official will determine if the documented solution meets the intent of the control and properly identifies and protects the organizational and privacy information.