FedRAMP Consolidated Rules (2026) 2026.10.13.01
AllAFC: Addressing FedRAMP CommunicationAGU: Agency Use of FedRAMP Certified Cloud ServicesCCM: Collaborative Continuous MonitoringCDS: Certification Data SharingCMU: Cryptographic Module UseCPO: Certification Package OverviewCTL-AC: FedRAMP parameters and guidance, ACCTL-AU: FedRAMP parameters and guidance, AUCTL-CA: FedRAMP parameters and guidance, CACTL-CM: FedRAMP parameters and guidance, CMCTL-CP: FedRAMP parameters and guidance, CPCTL-IA: FedRAMP parameters and guidance, IACTL-IR: FedRAMP parameters and guidance, IRCTL-MA: FedRAMP parameters and guidance, MACTL-PS: FedRAMP parameters and guidance, PSCTL-RA: FedRAMP parameters and guidance, RACTL-SA: FedRAMP parameters and guidance, SACTL-SC: FedRAMP parameters and guidance, SCCTL-SI: FedRAMP parameters and guidance, SICTL-SR: FedRAMP parameters and guidance, SRFRC: FedRAMP CertificationFRD: DefinitionsIEC: Incident Evaluation and CommunicationIVV: Independent Verification and ValidationKSI-CED: Cybersecurity EducationKSI-CMT: Change ManagementKSI-CNA: Cloud Native ArchitectureKSI-IAM: Identity and Access ManagementKSI-INR: Incident ResponseKSI-MLA: Monitoring, Logging, and AuditingKSI-PIY: Policy and InventoryKSI-RPL: Recovery PlanningKSI-SCR: Supply Chain RiskKSI-SVC: Service ConfigurationMAS: Minimum Assessment ScopeMKT: Marketplace ListingREC: FedRAMP Recognition of Independent Assessment ServicesSCG: Secure Configuration GuideSCN: Significant Change NotificationSDR: Security Decision RecordVDR: Vulnerability Detection and ResponseVER: Vulnerability Evaluation and Reporting
| Ref | Title | Text | |
|---|---|---|---|
| AFC-CSO-ACK | Acknowledge Receipt | Providers SHOULD promptly and automatically acknowledge the receipt of messages received from FedRAMP in their FedRAMP Security Inbox. | |
| AFC-CSO-CRA | Complete Required Actions | Providers MUST complete the required actions in Emergency or Emergency Test designated messages sent by FedRAMP within the timeframe included in the message. | |
| AFC-CSO-EMR | Emergency Message Routing | Providers MUST route Emergency designated messages sent by FedRAMP to a senior security official for their awareness. | |
| AFC-CSO-IMA | Important Message Actions | Providers SHOULD complete the required actions in Important designated messages sent by FedRAMP within the timeframe specified in the message. | |
| AFC-CSO-INB | Maintain a FedRAMP Security Inbox | Providers MUST establish and maintain an email address to receive messages from FedRAMP; this inbox is a FedRAMP Security Inbox (FSI). | changed here |
| AFC-CSO-NOC | Notification of Changes | Providers MUST immediately notify FedRAMP of any changes to the email address for their FedRAMP Security Inbox. | |
| AFC-CSO-RCV | Receive Email Without Disruption | Providers MUST receive and react to email messages from FedRAMP without disruption and without requiring additional actions from FedRAMP. | |
| AFC-CSO-TFG | Trust @fedramp.gov and @gsa.gov | 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 | |
| AFC-FRP-CDS | Criticality Designators | FedRAMP MUST convey the criticality of the message in the subject line, IF the message requires an elevated reaction, using one of the following designators: - **Emergency:** There is a potential incident or crisis such that FedRAMP require | |
| AFC-FRP-COR | Explain Corrective Actions | FedRAMP MUST clearly specify the corrective actions that will result from failure to complete the required actions in the body of messages that require an elevated reaction; such actions may vary from negative ratings in the FedRAMP Marketp | |
| AFC-FRP-ERT | Elevated Reaction Timeframes | FedRAMP MUST clearly specify the expected timeframe for completing required actions in the body of messages that require an elevated reaction; timeframes for actions will vary depending on the situation but the default timeframes to provide | |
| AFC-FRP-PNT | Public Notice of Emergency Tests | FedRAMP MUST post a public notice at least 10 business days in advance of sending an Emergency Test message; such notices MUST include explanation of the likely expected actions and timeframes for the Emergency Test message. | |
| AFC-FRP-RPM | Reaction Metrics | FedRAMP MAY track and publicly share the time required by cloud service providers to take the actions specified in messages that require an elevated reaction. | |
| AFC-FRP-RQA | Required Actions | FedRAMP MUST clearly specify the required actions in the body of messages that require an elevated reaction. | |
| AFC-FRP-UFS | Use FedRAMP_Security Email in Emergencies | FedRAMP MUST send Emergency and Emergency Test designated messages from [email protected] OR [email protected]. | |
| AFC-FRP-VRE | Verified Emails | FedRAMP MUST send messages to cloud service providers using an official @fedramp.gov or @gsa.gov email address with properly configured Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authenticatio | |
| AGU-AGC-AIP | Agency Internal Policies | Agencies MUST maintain agency-wide policy that aligns with the requirements in OMB Memorandum M-24-15. | |
| AGU-AGC-GRC | Governance, Risk, and Compliance Tools | Agencies MUST ensure that internal governance, risk, compliance, and inventory tools can produce and ingest machine-readable artifacts using formats identified by FedRAMP, including at least: - Open Security Controls Assessment Language (OS | |
| AGU-AGC-LIA | Agency Liaison Program | Agencies SHOULD assign at least 1 federal employee to be an active participant in the FedRAMP Agency Liaison program. | |
| AGU-AGC-NAA | Notify FedRAMP After Authorization | Agencies MUST notify FedRAMP upon authorizing the use of a cloud service within the scope of FedRAMP, supplying at least the following information: - A copy of the agency's Authorization to Operate letter for the information system leveragi | |
| AGU-AGC-NAI | Notify Additional Information Requests | Agencies MUST notify FedRAMP after requesting any additional information or materials from a FedRAMP Certified cloud service offering beyond those required by FedRAMP. | |
| AGU-AGC-NAR | No Additional Security Requirements | Agencies MUST NOT require additional information or materials from FedRAMP Certified cloud service offerings beyond those required by FedRAMP UNLESS the head of the agency or an authorized delegate determines there is a demonstrable need an | |
| AGU-AGC-SIN | Shared FedRAMP Inbox | Agencies SHOULD establish and maintain a dedicated shared FedRAMP agency inbox to serve as the official point of contact for communications between FedRAMP and the agency. | |
| AGU-AGC-TPP | No Certification Type or Path Preferences | Agencies MUST NOT require cloud service offerings to obtain or maintain a specific FedRAMP Certification Type or FedRAMP Certification Path, UNLESS the head of the agency or an authorized delegate determines there is a demonstrable need and | |
| AGU-AGC-WKG | FedRAMP Working Groups | Agencies SHOULD participate in FedRAMP working groups, communities of practice, and stakeholder engagements to supply feedback and align practices across government. | |
| AGU-SPN-MRC | Most Recent Consolidated Rules | Agencies MUST follow the most recent FedRAMP Consolidated Rules when initiating agency-sponsored FedRAMP Certification. | |
| AGU-USE-ABU | Authorization Before Use | Agencies MUST complete the Authorization to Operate process for federal information systems that use FedRAMP Certified cloud service offerings. | |
| AGU-USE-AFR | Accept FedRAMP Rules | Agencies MUST allow FedRAMP Certified cloud service offerings to follow FedRAMP rules. | |
| AGU-USE-CLA | Using FedRAMP Class A Certifications | Agencies SHOULD NOT authorize the use of a FedRAMP Class A Certified cloud service offering for more than 12 months UNLESS the cloud service offering is actively seeking a FedRAMP Class B, C, or D Certification. | |
| AGU-USE-DSO | Designate Senior Official | Agencies SHOULD designate a federal senior information security official to review Ongoing Certification Reports and represent the agency at Quarterly Reviews for cloud service offerings included in agency information systems. | |
| AGU-USE-NFC | Notify FedRAMP of Monitoring Concerns | Agencies MUST notify FedRAMP if information presented in an Ongoing Certification Report, Quarterly Review, or other FedRAMP Certification Data causes significant concerns for the authorizing official that would likely result in rescission | |
| AGU-USE-NPC | Notify Provider of Concerns | Agencies SHOULD formally notify the cloud service provider if information presented in an Ongoing Certification Report, Quarterly Review, or other FedRAMP Certification Data causes significant concerns for the authorizing official that woul | |
| AGU-USE-RCF | Resolve Certification Package Conflicts | Agencies MUST collaborate with FedRAMP when discrepancies or conflicts arise between agency-specific security determinations and the FedRAMP Certification Package. | |
| AGU-USE-RIR | Review All Information Resources | Agencies SHOULD consider third-party information resources used by the cloud service offering during initial and ongoing authorization activities. | |
| AGU-USE-ROR | Review Ongoing Certification Reports | Agencies SHOULD review each Ongoing Certification Report to understand how changes to the cloud service offering may impact the risk tolerance documented in the agency Authorization to Operate for the federal information system that include | |
| AGU-USE-RSG | Review Secure Configuration Guides | Agencies MUST review the Secure Configuration Guides supplied by Providers and configure relevant security settings. | changed here |
| CCM-AGM-CSC | Consider Security Category | Agencies SHOULD consider the Security Category noted in their Authorization to Operate of the federal information system that includes the cloud service offering in its boundary and assign appropriate information security resources for revi | |
| CCM-AGM-ROR | Review Ongoing Reports | Agencies MUST review each Ongoing Certification Report to understand how changes to the cloud service offering may impact the previously agreed-upon risk tolerance documented in the agency's Authorization to Operate of a federal information | |
| CCM-OCR-AFS | Anonymized Feedback Summary | 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. | |
| CCM-OCR-AVL | Report Availability | 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 summari | changed here |
| CCM-OCR-FBM | Feedback Mechanism | Providers MUST supply an asynchronous mechanism for all necessary parties to provide feedback or ask questions about each Ongoing Certification Report. | |
| CCM-OCR-LSI | Limit Sensitive Information | Providers MUST NOT irresponsibly disclose sensitive information in an Ongoing Certification Report that would likely have an adverse effect on the cloud service offering. | |
| CCM-OCR-NRD | Next Report Date | Providers MUST supply the target date for their next Ongoing Certification Report with other public FedRAMP Certification Data. | |
| CCM-OCR-RPS | Responsible Public Certification Report Sharing | 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. | |
| CCM-OCR-SOR | Spread Out Reports | 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. | |
| CCM-QTR-ACT | Additional Content | Providers SHOULD supply additional information in Quarterly Reviews that the provider determines is of interest, use, or otherwise relevant to agencies. | changed here |
| CCM-QTR-MTG | Quarterly Review Meeting | changed here | |
| CCM-QTR-NID | No Irresponsible Disclosure | Providers MUST NOT irresponsibly disclose sensitive information in a Quarterly Review that would likely have an adverse effect on the cloud service offering. | |
| CCM-QTR-NRD | Next Review Date | Providers MUST publicly supply the target date for their next Quarterly Review with other public FedRAMP Certification Data. | |
| CCM-QTR-REG | Meeting Registration Info | Providers MUST supply either a registration link or a downloadable calendar file with meeting information for Quarterly Reviews to all necessary parties. | |
| CCM-QTR-RTP | Restrict Third Parties | Providers SHOULD NOT invite third parties to attend Quarterly Reviews intended for agencies unless they have specific relevance. | |
| CCM-QTR-RTR | Record/Transcribe Reviews | Providers SHOULD record or transcribe Quarterly Reviews and supply them to all necessary parties. | |
| CCM-QTR-SAR | Schedule Around Reports | 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. | |
| CCM-QTR-SCR | Share Content Responsibly | 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. | |
| CCM-QTR-SRR | Share Recordings Responsibly | 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 | |
| CDS-CSO-AVR | Availability Reporting | ||
| CDS-CSO-CBF | Consistency Between Formats | 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. | |
| CDS-CSO-FID | Always Include FedRAMP ID | 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. | |
| CDS-CSO-FRC | FedRAMP Certification Reports | 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. | |
| CDS-CSO-HAD | Historical FedRAMP Certification Data | 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. | |
| CDS-CSO-IRP | Include Relevant Policies | 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 | |
| CDS-CSO-PSM | Per-Service Certification Materials | Providers determine what they consider to be separate services, based on maximizing the customer experience for agencies who may only adopt some services and not others. Providers are encouraged to provide a single comprehensive set of mate | |
| CDS-CSO-PUB | Public Information | 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 - Dep | |
| CDS-CSO-RIS | Responsible Information Sharing | 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 ha | |
| CDS-CSO-RPS | Responsible Public Package Sharing | 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. | |
| CDS-CSO-SVC | Public Service List | 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 | |
| CDS-CSO-UTC | Use Trust Centers | Providers MUST use a FedRAMP-compatible trust center to store and share FedRAMP Certification Data with all necessary parties. | |
| CDS-TRC-AAI | Agency Access Inventory | 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. | |
| CDS-TRC-ACL | Access Logging | 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. | |
| CDS-TRC-HMR | Human and Machine-Readable Certification Data | Trust centers SHOULD make FedRAMP Certification Data available to view and download in both human-readable and machine-readable formats. | |
| CDS-TRC-PAC | Programmatic Access | Trust centers MUST provide documented programmatic access to all FedRAMP Certification Data, including programmatic access to human-readable materials. | |
| CDS-TRC-SSM | Self-Service Access Management | 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. | |
| CDS-TRC-USH | Uninterrupted Sharing | Trust centers MUST share FedRAMP Certification Data with all necessary parties without interruption. | |
| CDS-UTC-AAD | Agency Access Denial | Providers MUST notify FedRAMP within 5 business days of denying an agency access request for FedRAMP Certification Data. | |
| CDS-UTC-AGA | Agency Access | Providers SHOULD supply access to the FedRAMP Certification Package with agencies upon request. | |
| CMU-CSO-CAT | Configuration of Agency Tenants | 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 | |
| CMU-CSO-CMD | Cryptographic Module Documentation | 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 u | changed here |
| CMU-CSO-UVM | Using Validated Cryptographic Modules | Cryptographic modules include specific algorithms by definition; if an update stream of a cryptographic module adds new algorithms that were not previously validated then those algorithms can not be considered within the scope of update str | changed here |
| CPO-CSO-MTD | Certification Package Overview Metadata | 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 | |
| CPO-CSO-OSA | Overall Summary of Assessment in Certification Package | changed here | |
| CPO-CSO-OVR | Overview of the Cloud Service Offering | 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 Packa | |
| FRC-APP-AFC | Applying for FedRAMP Certification | Providers MUST complete the FedRAMP Certification Application Form in full to request an initial assessment by FedRAMP. | |
| FRC-APP-FCP | Fresh FedRAMP Certification Package | 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. | |
| FRC-APP-FIA | Fresh Independent Assessment | ||
| FRC-APP-MLF | Marketplace Listing First | 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 Listin | |
| FRC-APP-NTP | No Third-Party Applicants | Providers MUST NOT use a third party to apply for a FedRAMP Certification on their behalf; this includes independent assessment services. | |
| FRC-APP-USA | Updating Stale Assessments | 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 se | |
| FRC-APS-ATO | Agency Authorization to Operate | Providers seeking a FedRAMP Rev5 Agency Certification MUST have completed the Authorization to Operate (ATO) process with their agency sponsor for the cloud service offering, concluding with a formal signed ATO letter that the agency has se | |
| FRC-CCL-DCC | Downgrading Certification Class | Providers MUST apply for a new FedRAMP Certification to downgrade their Certification Class. | |
| FRC-CCL-DNP | Downgrade Notification Period | Providers SHOULD notify all necessary parties at least 120 days in advance of an intended downgrade or cancellation of FedRAMP Certification. | |
| FRC-CCL-UCC | Upgrading Certification Class | Providers MUST apply for a new FedRAMP Certification to upgrade their Certification Class; all applicable requirements MUST be met in advance. | |
| FRC-CLA-ASF | Approved Alternative Security Frameworks | Providers seeking a FedRAMP Class A Certification MUST have completed a certification or equivalent process, including an independent assessment if applicable, from one of the following alternative security frameworks within the past 12 mon | |
| FRC-CLA-EAM | External Assessment Materials | Providers seeking a FedRAMP Class A Certification MUST supply the following materials from their alternative security framework assessment to all necessary parties: - SOC 2 Type II: Complete report, bridge or gap letter (if applicable), ver | |
| FRC-CLA-IVV | Optional Independent Verification and Validation | Providers seeking a FedRAMP Class A Certification MAY have the FedRAMP Certification Package independently verified and validated by a FedRAMP Recognized assessor before submission to FedRAMP. | |
| FRC-CLA-MFR | Mandatory FedRAMP Rules for Class A | Providers seeking a Class A FedRAMP Certification MUST address all rules in this FedRAMP Class A Certification subset (FRC-CLA) AND the following additional FedRAMP Class A rules; the appropriate artifacts or information mapping for all rul | |
| FRC-CLA-OFR | Address Optional FedRAMP Rules for Class A | Providers seeking a Class A FedRAMP Certification MAY address the following additional optional FedRAMP Class A rules (if applicable): - Collaborative Continuous Monitoring: CCM-QTR-MTG (Quarterly Review Meeting) - Certification Data Sharin | |
| FRC-CLA-RFR | Recommended FedRAMP Rules for Class A | Providers seeking a Class A FedRAMP Certification SHOULD address the following additional recommended FedRAMP Class A rules (if applicable): - Certification Data Sharing: CDS-CSO-AVR (Availability Reporting) - Certification Package Overview | |
| FRC-CSO-FCP | FedRAMP Certification Profile | Providers MUST identify a target FedRAMP Certification Profile and apply all relevant FedRAMP Practices to the cloud service offering. | |
| FRC-CSO-JSN | FedRAMP JSON Schemas | 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; public JSON data MUST be supplied | |
| FRC-CSO-MRA | Maintain Responsibility and Accountability | 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 servic | |
| FRC-CSO-PKG | FedRAMP Certification Package | 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 Se | |
| FRC-CSO-POP | Pick One Program Certification Type | Providers MUST NOT seek both FedRAMP Rev5 Program Certification and FedRAMP 20x Program Certification for the same cloud service offering; pick one type. | |
| IEC-CSO-AIR | Automated Incident Reporting | Providers SHOULD use automation to minimize human intervention in the process of reporting FedRAMP Reportable Incidents to all affected parties. | |
| IEC-CSO-DPR | Default PAIN Rating | 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). | |
| 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 ag | |
| IEC-CSO-EFR | Evaluate FedRAMP Reportability | 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 Reportabl | changed here |
| IEC-CSO-FIR | Final Incident Report | changed here | |
| IEC-CSO-IIR | Initial Incident Report | changed here | |
| IEC-CSO-OIR | Ongoing Incident Reports | changed here | |
| IEC-FRP-ORV | Ongoing Review | FedRAMP MUST periodically review FedRAMP Incident Evaluation and Communication implementation with providers based on lack of reporting or other information. | |
| IVV-CSO-DUS | Document Use of Representative Samples | 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). | |
| IVV-CSO-FIA | FedRAMP Independent Assessments | The first such completed assessment is typically called an "initial assessment" while following assessments are called "annual assessments." The specific requirements for independent verification and validation assessments are documented by | changed here |
| IVV-CSO-ICP | Inclusion in Certification Package | Providers MUST supply the results of FedRAMP independent assessments in their FedRAMP Certification Package without inappropriate modification. | |
| IVV-CSO-RAA | Receiving Assessor Advice | 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 rep | |
| IVV-CSO-SEE | Supply Evidence of Effectiveness | 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. | |
| IVV-CSO-SEI | Supply Evidence of Implementation | 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. | |
| IVV-CSO-STE | Supply Technical Explanations | 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 necessa | |
| IVV-CSO-USR | Use Representative Samples | Providers MAY use representative samples as appropriate during verification and validation. | |
| IVV-IAS-EPX | Engage Provider Experts | Assessors SHOULD engage provider experts in discussion to understand the decisions made by the provider and inform expert qualitative assessment, and SHOULD perform independent research to test such information as part of the expert qualita | |
| IVV-IAS-OSA | Overall Summary of Assessment | Assessors MUST supply the provider with an overall summary of the verification and validation assessment results, including any resulting failures or areas of dispute; this summary will be included by the provider in the FedRAMP Certificati | |
| IVV-IAS-SHA | Sharing Advice | Assessors MAY share advice with providers they are assessing about techniques and procedures that will improve the provider's security posture or the effectiveness, clarity, and accuracy of their verification, validation and reporting proce | |
| IVV-IAS-SUM | Assessment Summary | Assessors MUST supply the provider with a high-level summary of their assessment process and findings for each FedRAMP Practice; this summary will be included by the provider in the FedRAMP Security Decision Record for the cloud service off | |
| IVV-IAS-VEF | Validate Effectiveness | Assessors MUST validate the effectiveness of the implemented measures to ensure they have the intended outcome for meeting FedRAMP Practices. | |
| IVV-IAS-VIM | Verify Implementation | Assessors MUST verify that the measures implemented by the cloud service offering matches the measures they documented to meet FedRAMP Practices. | |
| IVV-IAS-VIP | Verify Inclusion in Certification Package | Assessors MUST verify that information supplied during a FedRAMP independent assessment is included in the FedRAMP Certification Package by the provider without inappropriate modification. | |
| MAS-CSO-FLO | Information Flows and Security Categories | 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. | changed here |
| MAS-CSO-IIR | Identify Information Resources | 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 availa | changed here |
| MAS-CSO-MDI | Metadata Inclusion | Providers MUST include metadata (including metadata about federal customer data) in the Minimum Assessment Scope ONLY IF MAS-CSO-IIR (Identify Information Resources) APPLIES. | |
| MAS-CSO-SUP | Supplemental Information | 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 ma | |
| MAS-CSO-TPR | Third-Party Information Resources | 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 infor | changed here |
| MKT-CAS-LRQ | Listing Requests for Advisors | Advisors MUST complete the Advisor Listing Request Form to request listing in the FedRAMP Marketplace. | |
| MKT-CAS-RFR | Advisor Responses to FedRAMP | Advisors MUST reply to all requests from @fedramp.gov or @gsa.gov email addresses sent to the contact information provided in their advisor listing within 5 business days. | |
| MKT-CAS-WEB | Website Requirements for Advisors | Advisors MUST have an appropriate web site that publicly supplies at least the following information in consistent machine-readable and human-readable formats: - General description of the consulting or advisory service - Contact informatio | |
| MKT-CSO-MLR | Marketplace Listing Requirements | 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) | |
| MKT-CSO-PML | Provider Marketplace Listing Requests | Providers MUST notify FedRAMP using the FedRAMP Marketplace Providing Listing Request Form to request a listing in the FedRAMP Marketplace. | |
| MKT-FRP-SOF | Scope of FedRAMP | FedRAMP MUST NOT list cloud service offerings in the Marketplace or perform any FedRAMP Certification activities unless it determines the cloud service offering is within the scope of FedRAMP. | |
| MKT-IAS-LRQ | Listing Requests for Assessors | Assessors MUST complete the Assessor Listing Request Form to request listing in the FedRAMP Marketplace. | |
| MKT-IAS-OFR | Only FedRAMP Recognized Assessors | Assessors MUST obtain and maintain FedRAMP Recognition to be listed in the FedRAMP Marketplace. | |
| MKT-IAS-WEB | Website Requirements for Assessors | Assessors MUST have an appropriate web site that publicly supplies at least the following information in human-readable and JSON formats: - General description of the independent assessment service - Contact information - Types of independe | |
| MKT-IIP-AGU | Agency Use Cases | 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 | |
| MKT-IIP-DCP | Demonstrating Continuous Progress | 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. | |
| MKT-IIP-DLA | Deadline for Assessment | 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. | |
| REC-FRP-DRD | Double Revocation Disqualification | FedRAMP MUST NOT restore FedRAMP Recognition for an assessor after FedRAMP has revoked that assessor's FedRAMP Recognition 2 times. | |
| REC-FRP-FOC | Foreign Ownership Collection | FedRAMP MUST maintain a process to collect foreign ownership, control, or influence declarations from FedRAMP Recognized assessors and updates to those declarations. | |
| REC-FRP-RAO | Recognized Assessors Only | FedRAMP MUST NOT accept verification, validation, or other attestations from independent assessors who are not FedRAMP Recognized. | |
| REC-IAS-ACC | A2LA Accreditation | Assessors MUST obtain and maintain accreditation through the American Association for Laboratory Accreditation (A2LA) Cybersecurity Inspection Body Program to qualify for FedRAMP Recognition. | |
| REC-IAS-ADA | Actually Do Assessments | Assessors MUST complete at least 2 initial or ongoing assessments for Class B, C, or D FedRAMP Certifications every 2 years to maintain FedRAMP Recognition. | |
| REC-IAS-AFI | Annual Foreign Interest Reports | Assessors MUST report information relating to any foreign interest, foreign influence, or foreign control of the independent assessment service to FedRAMP annually. | |
| REC-IAS-ANR | Annual Surveillance Assessment | Assessors MUST achieve a favorable annual surveillance assessment by the American Association for Laboratory Accreditation (A2LA) to maintain FedRAMP Recognition. | |
| REC-IAS-CAP | Corrective Action Plan | Assessors MUST supply a corrective action plan when FedRAMP requires one for performance standards deficiencies or organizational risks. | |
| REC-IAS-CFI | Changes in Foreign Interest | Assessors MUST report updated information relating to any foreign interest, foreign influence, or foreign control of the independent assessment service within 48 hours of any change in foreign ownership or control. | |
| REC-IAS-INV | Invalid Deliverables | Assessors MUST treat deliverables prepared, performed, or submitted by personnel who do not meet required role qualifications as invalid for FedRAMP purposes. | |
| REC-IAS-PSC | Policy and Standards Compliance | Assessors MUST maintain compliance with the latest American Association for Laboratory Accreditation (A2LA) R311 - Specific Requirements - Federal Risk and Authorization Management Program to maintain FedRAMP Recognition. | |
| REC-IAS-PST | Performance Standards | Assessors MUST meet FedRAMP performance standards for assessor deliverables to support independent, risk-based reviews by FedRAMP and federal agencies, including at least: - Complete Assessment Packages: Supplies complete and thoroughly pre | |
| REC-IAS-RAR | Re-entry after Revocation | Assessors MUST satisfy all American Association for Laboratory Accreditation (A2LA) re-entry conditions before regaining FedRAMP Recognition after revocation. | |
| REC-IAS-RAS | Full A2LA Reassessment | Assessors MUST achieve a favorable full reassessment by the American Association for Laboratory Accreditation (A2LA) at least once every 2 years to maintain FedRAMP Recognition. | |
| REC-IAS-RQU | Roles and Qualifications | Assessors MUST staff FedRAMP assessments with all roles required by the American Association for Laboratory Accreditation (A2LA) R311, including personnel who meet the qualifications for each role, unless FedRAMP publishes a specific except | |
| REC-IAS-SEP | Advisory Separation | Assessors MUST NOT perform a FedRAMP independent assessment of the same cloud service offering within 2 years after supplying advisory or consulting services for that offering, unless FedRAMP publishes a specific exception for a limited pil | |
| SCG-CSO-AUP | Use Instructions | Providers MUST include instructions in the FedRAMP Certification Package that explain how to obtain and use the Secure Configuration Guide. | |
| SCG-CSO-PUB | Public Secure Configuration Guidance | Providers SHOULD make the Secure Configuration Guide available publicly. | |
| SCG-CSO-RSC | Recommended Secure Configuration | 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 | changed here |
| SCG-CSO-SDF | Secure Defaults | Providers SHOULD set all settings to their recommended secure defaults for top-level administrative accounts and privileged accounts when initially provisioned. | |
| SCG-ENH-API | API Capability | Providers SHOULD offer the capability to view and adjust security settings via an API or similar capability. | |
| SCG-ENH-CMP | Comparison Capability | Providers SHOULD offer the capability to compare all current settings for top-level administrative accounts and privileged accounts to the recommended secure defaults. | |
| SCG-ENH-EXP | Export Capability | Providers SHOULD offer the capability to export all security settings in a machine-readable format. | |
| SCG-ENH-MRG | Machine-Readable Guidance | 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. | |
| SCG-ENH-VRH | Versioning and Release History | 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. | |
| SCN-ADP-NTF | Notification Requirements | 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 appli | |
| SCN-CSO-ARI | Additional Relevant Information | Providers MAY include additional relevant information in Significant Change Notifications. | |
| SCN-CSO-EMG | Emergency Changes | 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 pro | changed here |
| SCN-CSO-EVA | Evaluate Changes | 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 Sig | changed here |
| SCN-CSO-HIS | Historical Notifications | Providers MUST keep 12 months of historical Significant Change Notifications available with their FedRAMP Certification Data. | |
| SCN-CSO-HRM | Human and Machine-Readable Notifications | Providers MUST make ALL Significant Change Notifications and related audit records available in human-readable and JSON formats. | |
| SCN-CSO-INF | Required Information | 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 o | |
| SCN-CSO-MAR | Maintain Audit Records | 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. | |
| SCN-CSO-NOM | Notification Mechanisms | 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. | |
| SCN-FRP-CAP | Corrective Action Plan Conditions | FedRAMP MAY require providers to delay significant changes beyond the standard Significant Change Notification period and/or submit significant changes for approval in advance as a condition of a formal FedRAMP Corrective Action Plan or oth | |
| SCN-RTR-NNR | No Notification Requirements | Providers SHOULD NOT make formal Significant Change Notifications for routine recurring changes; this type of change is exempted from notification requirements. | |
| SCN-TRF-NAF | Notification After Finishing | Providers MUST notify all necessary parties within 5 business days after finishing transformative changes, including updates to all previously sent information. | |
| SCN-TRF-NAV | Notification After Verification | 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 inform | |
| SCN-TRF-NFP | Notification of Final Plans | 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. | |
| SCN-TRF-NIP | Notification of Initial Plans | 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. | |
| SCN-TRF-TPR | Third-Party Review | 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 h | |
| SCN-TRF-UPD | Update Documentation | Providers MUST publish updated service documentation and other materials to reflect transformative changes within 30 business days after finishing transformative changes. | |
| SDR-CSO-FRR | FedRAMP Rules | 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 explanatio | |
| SDR-CSO-MTD | Security Decision Record Metadata | Providers MUST also include the following basic metadata in their Security Decision Record: - Version - Date and time of last update - Source of update | |
| VDR-CSO-ADT | Automate Detection | Providers SHOULD use automated services to improve and streamline vulnerability detection and response. | changed here |
| VDR-CSO-AKE | Avoid KEVs | Providers SHOULD NOT deploy or otherwise activate new machine-based information resources with Known Exploited Vulnerabilities. | changed here |
| VDR-CSO-DAC | Detect After Changes | Providers SHOULD automatically perform vulnerability detection on representative samples of new or significantly changed information resources. | changed here |
| VDR-CSO-DET | Vulnerability Detection | 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 mec | changed here |
| VDR-CSO-DFR | Design For Resilience | 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. | |
| VDR-CSO-FAV | Failures Are Vulnerabilities | Providers MUST treat problems or failures with their vulnerability detection and response processes as vulnerabilities. | changed here |
| VDR-CSO-MSP | Maintain Security | Providers SHOULD NOT weaken the security of information resources to facilitate vulnerability scanning, detection, or assessment activities. | changed here |
| VDR-CSO-RES | Vulnerability Response | 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 | changed here |
| VDR-CSO-SIR | Sampling | 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 detect | changed here |
| VDR-TFR-KEV | Remediate KEVs | 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 | |
| VDR-TFR-NMV | Non-Machine Verification and Validation | Providers MUST verify and validate the status of non-machine-based information resources at least once every 3 months. | |
| VDR-TFR-PCD | Persistently Complete Detection | ||
| VDR-TFR-PDD | Persistent Drift Detection | changed here | |
| VDR-TFR-PSD | Persistent Sample Detection | ||
| VDR-TFR-PVR | Mitigation and Remediation Expectations | changed here | |
| VDR-TFR-RMN | Remaining Vulnerabilities | Providers SHOULD mitigate or remediate remaining vulnerabilities during routine operations as determined necessary by the provider. | |
| VER-AGM-MAP | Maintain Agency Plans of Action and Milestones | Agencies SHOULD use vulnerability information reported by the Provider to maintain Plans of Action and Milestones for agency security programs when relevant according to agency security policies (such as if the agency takes action to mitiga | |
| VER-AGM-RVR | Review Vulnerability Reports | Agencies SHOULD review the information provided in vulnerability reports at appropriate and reasonable intervals commensurate with the expectations and risk posture indicated by their Authorization to Operate, and SHOULD use automated proce | |
| VER-EVA-AIA | Assume It's Automatable | Providers MUST assume the exploitation of vulnerabilities can be automated UNLESS they have evidence proving otherwise. | |
| VER-EVA-EFA | Evaluation Factors | 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 | changed here |
| VER-EVA-EFP | Evaluate False Positives | Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are false positive vulnerabilities. | |
| VER-EVA-EIR | Evaluate Internet-Reachability | Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are internet-reachable vulnerabilities. | |
| VER-EVA-ELX | Evaluate Exploitability | Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities. | |
| VER-EVA-EPA | Estimate Potential Agency Impact | Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the likely potential agency impact of exploitation on government customers AND assign one of the following Potential Agency | changed here |
| VER-EVA-GRV | Group Vulnerabilities | 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 re | |
| VER-FRP-ADV | Sensitive Details | FedRAMP MAY require providers to share additional information or details about vulnerabilities, including sensitive information that would likely lead to exploitation, as part of review, response or investigation by necessary parties. | |
| VER-FRP-ARP | Additional Requirements | FedRAMP MAY require providers to share additional vulnerability information, alternative reports, or to report at an alternative frequency as a condition of a FedRAMP Corrective Action Plan or other agreements with federal agencies. | |
| VER-RPT-AVI | Accepted Vulnerability Info | 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 | |
| VER-RPT-HLO | High-Level Overviews | 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, penetrat | |
| VER-RPT-NID | Responsible Disclosure | 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 | |
| VER-RPT-PER | Persistent Reporting | 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 Cert | changed here |
| VER-RPT-RPD | Responsible Public Disclosure | Providers MAY responsibly disclose vulnerabilities publicly or with other parties if the provider determines doing so will NOT likely lead to exploitation. | |
| VER-RPT-VDT | Vulnerability Details | 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 | changed here |
| VER-TFR-EVU | Evaluate Vulnerabilities Quickly | ||
| VER-TFR-IRI | Internet-Reachable Incidents | ||
| VER-TFR-MAV | Mark Accepted Vulnerabilities | 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. | |
| VER-TFR-MHR | Monthly Activity Report | Providers MUST report vulnerability detection and response activity to all necessary parties in a consistent format that is human readable at least monthly. | |
| VER-TFR-MRH | Historical Activity | ||
| VER-TFR-NRI | Non-Internet-Reachable Incidents | ||
| KSI-CED-RAT | Reviewing All Training | 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 engine | changed here |
| KSI-CMT-LMC | Logging Changes | Modifications to the cloud service offering are logged and monitored. | changed here |
| KSI-CMT-RMV | Redeploying vs Modifying | Changes to machine-based information resources are executed through the redeployment of version controlled resources rather than direct modification wherever reasonable. | |
| KSI-CMT-RVP | Reviewing Change Procedures | The effectiveness of documented change management procedures is persistently reviewed. | |
| KSI-CMT-VTD | Validating Throughout Deployment | Persistent testing and validation of changes throughout deployment is automated. | changed here |
| KSI-CNA-DFP | Defining Functionality and Privileges | The functionality and privileges for infrastructure and services are strictly defined. | changed here |
| KSI-CNA-EIS | Enforcing Intended State | changed here | |
| KSI-CNA-IBP | Implementing Best Practices | The use and configuration of third-party machine-based information resources is persistently compared against the original provider's best practices and guidance. | changed here |
| KSI-CNA-MAT | Minimizing Attack Surface | Machine-based information resources are persistently reviewed to ensure they have a minimal attack surface and that lateral movement is minimized if compromised. | changed here |
| KSI-CNA-OFA | Optimizing for Availability | Machine-based information resources are persistently reviewed to ensure they are appropriately optimized for high availability and rapid recovery. | changed here |
| KSI-CNA-RNT | Restricting Network Traffic | Machine-based information resources are persistently reviewed to ensure they are appropriately configured to limit inbound and outbound network traffic. | changed here |
| KSI-CNA-RVP | Reviewing Protections | The effectiveness of protection against denial of service attacks and other unwanted activity for machine-based information resources is persistently reviewed. | changed here |
| KSI-CNA-ULN | Using Logical Networking | Logical networking and related capabilities are used and persistently reviewed to enforce traffic flow controls. | changed here |
| KSI-IAM-AAM | Automating Account Management | The lifecycle and privileges of all accounts, roles, and groups are securely managed using automation. | changed here |
| KSI-IAM-APM | Adopting Passwordless Methods | Secure passwordless methods are used for user authentication and authorization when feasible, otherwise strong passwords with phishing-resistant MFA is used. | changed here |
| KSI-IAM-ELP | Ensuring Least Privilege | Identity and access management measures are used and persistently reviewed to ensure each user or device can only access the resources they need. | changed here |
| KSI-IAM-JIT | Authorizing Just-in-Time | 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. | changed here |
| KSI-IAM-SNU | Securing Non-User Authentication | Appropriately secure authentication methods are used and persistently reviewed for non-user accounts and services. | changed here |
| KSI-IAM-SUS | Responding to Suspicious Activity | Accounts with privileged access are disabled or otherwise secured in response to suspicious activity. | changed here |
| KSI-INR-AAR | Generating After Action Reports | Incident after action reports are generated and lessons learned are persistently incorporated. | changed here |
| KSI-INR-RIR | Reviewing Incident Response Procedures | The effectiveness of documented incident response procedures is persistently reviewed. | changed here |
| KSI-INR-RPI | Reviewing Past Incidents | Past incidents are persistently reviewed for patterns or vulnerabilities that were not previously apparent or identified. | changed here |
| KSI-MLA-ALA | Authorizing Log Access | changed here | |
| KSI-MLA-EVC | Evaluating Configurations | The configuration of machine-based information resources, especially infrastructure as code, is persistently evaluated and tested. | changed here |
| KSI-MLA-LET | Logging Event Types | 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. | changed here |
| KSI-MLA-OSM | Operating SIEM Capability | 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. | changed here |
| KSI-MLA-RVL | Reviewing Logs | Logs are persistently reviewed and audited. | changed here |
| KSI-PIY-GIV | Generating Inventories | Authoritative sources are used to automatically generate real-time inventories of all information resources when needed. | changed here |
| KSI-PIY-RES | Reviewing Executive Support | Executive support for achieving the provider's security goals is persistently reviewed and demonstrated. | |
| KSI-PIY-RIS | Reviewing Investments in Security | The effectiveness of the provider's investments in achieving security goals is persistently reviewed. | changed here |
| KSI-PIY-RSD | Reviewing Security in the SDLC | The effectiveness of building security and privacy considerations into the Software Development Lifecycle and aligning with CISA Secure By Design principles is persistently reviewed. | changed here |
| KSI-PIY-RVD | Reviewing Vulnerability Disclosures | The effectiveness of the provider's vulnerability disclosure program is persistently reviewed. | |
| KSI-RPL-ABO | Aligning Backups with Objectives | The alignment of machine-based information resource backups with defined recovery objectives is persistently reviewed. | changed here |
| KSI-RPL-ARP | Aligning Recovery Plan | The alignment of recovery plans with defined recovery objectives is persistently reviewed. | |
| KSI-RPL-RRO | Reviewing Recovery Objectives | 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. | |
| KSI-RPL-TRC | Testing Recovery Capabilities | The capability to recover from incidents and contingencies aligned with defined recovery objectives is persistently tested. | changed here |
| KSI-SCR-MIT | Mitigating Supply Chain Risk | Persistently identify, review, and mitigate potential supply chain risks. | changed here |
| KSI-SCR-MON | Monitoring Supply Chain Risk | Third party software information resources are automatically monitored for upstream vulnerabilities using mechanisms that may include contractual notification requirements or active monitoring services. | changed here |
| KSI-SVC-ACM | Automating Configuration Management | The configuration of machine-based information resources is managed using automation and persistently reviewed for drift. | changed here |
| KSI-SVC-ASM | Automating Secret Management | Management, protection, and regular rotation of digital keys, certificates, and other secrets is automated and persistently reviewed. | changed here |
| KSI-SVC-EIS | Evaluating and Improving Security | Information resources are persistently evaluated for opportunities to improve security and those improvements are persistently made. | changed here |
| KSI-SVC-PRR | Preventing Residual Risk | changed here | |
| KSI-SVC-RUD | Removing Unwanted Data | changed here | |
| KSI-SVC-SIN | Securing Information | Information is encrypted or otherwise secured from unwanted access or modification. | changed here |
| KSI-SVC-VCM | Validating Communications | changed here | |
| KSI-SVC-VRI | Validating Resource Integrity | Use cryptographic methods to validate the integrity of machine-based information resources. | changed here |
| FRD-AAP | All Affected Parties | All federal entities whose interests are affected directly or are likely to be affected directly in the event of a vulnerability or incident related to federal customer data. This always includes FedRAMP and directly impacted federal custom | |
| FRD-ACV | Accepted Vulnerability | A vulnerability that the provider does not intend to fully mitigate or remediate, OR that has not or will not be fully mitigated or remediated within the maximum overdue period in FedRAMP Vulnerability Detection and Response rules. | |
| FRD-ADP | Adaptive Change | A type of significant change that does not routinely recur and does not introduce substantive potential security risks that need to be assessed in depth. | |
| FRD-ADV | Advisor | An entity that helps a provider understand, prepare for, or maintain FedRAMP Certification without replacing the provider's responsibility or the assessor's independence. | |
| FRD-AGY | Agency | Has the meaning given in 44 U.S. Code § 3502 (1), which is "any executive department, military department, Government corporation, Government controlled corporation, or other establishment in the executive branch of the Government (includin | |
| FRD-ANA | All Necessary Assessors | All entities who participate in the FedRAMP assessment of a cloud service offering in the context of a FedRAMP Certification. This always includes FedRAMP and any FedRAMP Recognized independent assessor contracted by a provider to perform a | |
| FRD-ANP | All Necessary Parties | All entities whose interests are affected directly by activity related to a specific cloud service offering in the context of FedRAMP Certifications. This always includes FedRAMP and any agency customer who is using the cloud service offeri | |
| FRD-ART | Artifacts | Security-related materials that supply information regarding or evidence of functions, policies, decisions, procedures, operations, or other such activities, for the purposes of obtaining and maintaining a FedRAMP Certification. All such ar | |
| FRD-ASR | Assessor | An assessor that performs assessment, verification, or validation activities for a cloud service offering seeking to obtain or maintain FedRAMP Certification; FedRAMP is the final assessor for FedRAMP Certification, but FedRAMP Recognized i | |
| FRD-CCC | Certification Class Change | A type of significant change that is likely to change the FedRAMP Certification class for the entire cloud service offering (e.g. from Class B to Class C or from Class D to Class C). | |
| FRD-CCL | Certification Class | The category of assurance that a cloud service offering supplies to federal government customers following FedRAMP Practices, increasing from minimal assurance at Class A to significant assurance at Class D; currently available categories a | |
| FRD-CPF | Certification Profile | The combination of a FedRAMP Certification Type (Rev5 or 20x), FedRAMP Certification Path (Program or Agency), and FedRAMP Certification Class (A, B, C, or D) for a cloud service offering. | |
| FRD-CPH | Certification Path | The underlying source of the FedRAMP Certification, either from a federal agency sponsored authorization to operate or directly from FedRAMP itself. The agency path is a legacy path that is only available for FedRAMP Rev5 and still requires | |
| FRD-CRD | Certification Data | The collective information required by FedRAMP for initial and ongoing FedRAMP Certification of a cloud service offering, including the FedRAMP Certification Package. | |
| FRD-CRP | Certification Package | Has meaning from 44 USC § 3607 (b)(8) given to "authorization package", which is "the essential information that can be used by an agency to determine whether to authorize the operation of an information system or the use of a designated se | |
| FRD-CSO | Cloud Service Offering | A specific, packaged cloud computing product or service supplied by a cloud service provider for use by customers, that is the subject of a FedRAMP Certification. | |
| FRD-CTY | Certification Type | The form of assurance that a cloud service offering supplies to federal government customers following FedRAMP Practices, either Rev5 or 20x. Rev5 follows a legacy approach based primarily on documented plans while 20x follows a modern appr | |
| FRD-DCE | Debilitating Customer Effect | An unwanted customer effect that interrupts use of the cloud service for most users or compromises the integrity or confidentiality of most federal customer data. If the adverse customer effect is unknown then it should be treated as if it | |
| FRD-DCF | Disruptive Customer Effect | An unwanted customer effect that interrupts use of the cloud service for many users for less than 24 hours, or that compromises the integrity or confidentiality of large amounts or many types of federal customer data. | |
| FRD-DFT | Drift | Changes to information resources that cause deviations from the intended and assessed state; common forms of drift include changes to configurations, deployed software, privileges, running processes, and availability. | |
| FRD-DTM | Deterministic Telemetry | Verifiable data collected directly from an authoritative source that represents a factual and reproducible observation of the attributes of a system such as the system's state, configuration, or behavior. | |
| FRD-FCD | Federal Customer Data | All electronic information, content, and materials that an agency or its authorized users upload, store, or otherwise supply to a cloud service for processing or storage. This does NOT include account information, service metadata, analytic | |
| FRD-FCR | FedRAMP Certification Report | A report that is produced by FedRAMP documenting the results of a FedRAMP Certification assessment. This report is typically produced after the initial FedRAMP Certification assessment on the Program Certification Path and updated as necess | |
| FRD-FCT | FedRAMP Certified | The status of a cloud service offering that has received FedRAMP Certification and meets the legal requirement to be FedRAMP authorized. | |
| FRD-FIN | FedRAMP Independent Assessment | An independent verification and validation assessment, performed by a FedRAMP Recognized independent assessment service or FedRAMP following FedRAMP rules. These assessments are typically first performed to obtain an initial FedRAMP Certifi | |
| FRD-FIR | Final Incident Report (FIR) | A final report after recovery from an incident that is supplied by FedRAMP Certified cloud service providers to FedRAMP and agency customers, following FedRAMP Incident Evaluation and Communication rules. | |
| FRD-FMV | Fully Mitigated Vulnerability | A vulnerability where the likelihood of exploitation or Potential Agency Impact N-rating has been reduced from the original evaluation until either are negligible, but the vulnerability is still detected. | |
| FRD-FPR | FedRAMP Practices | The security measures, safeguards, precautions, procedures, activities, policies, capabilities, mechanisms, etc. that are expected to be in place by FedRAMP to demonstrate that information resources are properly protected, expressed in FedR | |
| FRD-FPV | False Positive Vulnerability | A detected vulnerability that is not actually present in an exploitable state in the information resource | |
| FRD-FRA | FedRAMP Recognized | The status of independent assessment services that are recognized by FedRAMP to perform assessment activities on behalf of FedRAMP for cloud service offerings seeking to obtain or maintain FedRAMP Certification. | |
| FRD-FRI | FedRAMP Reportable Incident | An incident that affects the confidentiality or integrity of federal customer data or is likely to affect the confidentiality or integrity of federal customer data. | |
| FRD-FSI | FedRAMP Security Inbox | An email address that follows the FedRAMP Security Inbox rules. | |
| FRD-HAN | Handle | Has the plain language meaning inclusive of any possible action taken with information, such as access, collect, control, create, display, disclose, disseminate, dispose, maintain, manipulate, process, receive, review, store, transmit, use. | |
| FRD-IFA | Initial FedRAMP Assessment | The first full assessment of a cloud service offering obtaining FedRAMP Certification, coordinated by the provider with all necessary assessors, that results in a FedRAMP Certification. | |
| FRD-IIR | Initial Incident Report (IIR) | An initial report about an incident that is supplied by FedRAMP Certified cloud service providers to FedRAMP and agency customers, following FedRAMP FedRAMP Incident Evaluation and Communication rules. | |
| FRD-INC | Initial Certification | The first FedRAMP Certification of a cloud service offering based on the applicable FedRAMP Practices. | |
| FRD-INT | Incident | Has the meaning given in 44 USC § 3552 (b)(2) which is "an occurrence that (A) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (B) con | |
| FRD-IRS | Information Resource | Has the meaning from 44 USC § 3502 (6): "information and related resources, such as personnel, equipment, funds, and information technology." This includes any aspect of the cloud service offering, both technical and managerial, including e | |
| FRD-IRV | Internet-Reachable Vulnerability (IRV) | A vulnerability in a machine-based information resource that might be exploited or otherwise triggered by a payload originating from a source on the public internet. | |
| FRD-KEV | Known Exploited Vulnerability (KEV) | Has the meaning given in CISA Binding Operational Directive 26-04, which is any vulnerability identified in CISA's Known Exploited Vulnerabilities catalog. | |
| FRD-LEV | Likely Exploitable Vulnerability (LEV) | A vulnerability that is not fully mitigated AND is reachable by a likely threat actor; AND a likely threat actor with knowledge of the vulnerability would likely gain unauthorized access, cause harm, disrupt operations, or otherwise have an | |
| FRD-LKY | Likely | A reasonable degree of probability based on context. | |
| FRD-MAY | MAY | The rule is truly optional. Parties SHOULD address such rules in their security documentation by explaining their decisions about how they handle such rules. | |
| FRD-MBI | Machine-Based (Information Resources) | Any information technology information resource—including systems, processes, software, hardware, services, cloud-native capabilities, and any other such capability, component, or resource—that relies primarily on mechanical or electronic d | |
| FRD-MCE | Minimal Customer Effect | An unwanted customer effect that is only noticeable by some users. This includes minor inconveniences such as reduced performance. | |
| FRD-MGN | Machine-Generated | Automatically produced by a computer process, application, or other mechanism without the intervention or manipulation of a human during production. | |
| FRD-MNT | MUST NOT | The rule is an absolute prohibition. Parties MUST meet such rules and address them in their security documentation. Failure to follow the rule is a vulnerability likely requiring corrective action and/or the denial of initial or ongoing Fed | |
| FRD-MRD | Machine-Readable | Has the meaning from 44 U.S. Code § 3502 (18) which is "the term "machine-readable", when used with respect to data, means data in a format that can be easily processed by a computer without human intervention while ensuring no semantic mea | |
| FRD-MST | MUST | The rule is an absolute requirement. Parties MUST meet such rules and address them in their security documentation. Failure to follow the rule is a vulnerability likely requiring corrective action and/or the denial of initial or ongoing Fed | |
| FRD-NCE | Narrow Customer Effect | An unwanted customer effect that interrupts use of the cloud service for some users for less than 12 hours, or that compromises the integrity or confidentiality of an extremely limited amount and type of federal customer data. | |
| FRD-OCR | Ongoing Certification Report (OCR) | A regular report that is supplied by FedRAMP Certified cloud service providers to agency customers, following FedRAMP Collaborative Continuous Monitoring rules. | |
| FRD-ODV | Overdue Vulnerability | A vulnerability that the provider intends to fully mitigate or remediate but has not or will not do so within the time frames recommended or required by FedRAMP. | |
| FRD-OIR | Ongoing Incident Report (OIR) | A recurring report about an ongoing incident that is supplied by FedRAMP Certified cloud service providers to FedRAMP and agency customers, following the FedRAMP Incident Evaluation and Communication rules. | |
| FRD-ONC | Ongoing Certification | The continued FedRAMP Certification of a cloud service offering based on the applicable FedRAMP Practices. | |
| FRD-PAC | Privileged Account | An account with elevated privileges that enables administrative functions over some aspect of the cloud service offering that may affect the confidentiality, integrity, or availability of information beyond those given to normal users; leve | |
| FRD-PAI | Potential Agency Impact | The estimated cumulative effect of unauthorized access, disruption, harm, or other adverse impacts to all agencies using the cloud service that are likely to result from security incidents or the exploitation of vulnerabilities in the cloud | |
| FRD-PER | Persistently | Occurring in a firm, steady way that is repeated over a long period of time in spite of obstacles or difficulties. Persistent activities may vary between actors, may occur irregularly, and may include interruptions or waiting periods betwee | |
| FRD-PFA | Persistent FedRAMP Assessment | Follow-on assessments of a cloud service offering focused on Key Security Indicators, coordinated by the provider with all necessary assessors, to maintain FedRAMP Certification or change its FedRAMP Certification class. | |
| FRD-PMV | Partially Mitigated Vulnerability | A vulnerability where the likelihood or Potential Agency Impact N-rating has been reduced from the original evaluation but the risk of exploitation still exists and the vulnerability is still detected. | |
| FRD-PRO | Promptly | Without unnecessary delay. | |
| FRD-PRV | Provider | The cloud service provider responsible for a cloud service offering in the context of FedRAMP Certification. | |
| FRD-QTR | Quarterly Review | A regular synchronous meeting hosted by a FedRAMP Certified cloud service provider for agency customers, following FedRAMP Collaborative Continuous Monitoring rules. | |
| FRD-RGL | Regularly | Performing the activity on a consistent, predictable, and repeated basis, at set intervals, automatically if possible, following a documented plan. These intervals may vary as appropriate between different activities. | |
| FRD-RMV | Remediated Vulnerability | A vulnerability that has been neutralized or eliminated and is no longer detected. | |
| FRD-RSP | Responsibly | In a way that shows that you have good judgment and the ability to act correctly and make decisions on your own. | |
| FRD-RTR | Routine Recurring Change | The type of significant change that regularly and routinely recurs as part of ongoing operations, vulnerability mitigation, or vulnerability remediation. | |
| FRD-SCT | Security Category | Has the meaning from NIST FIPS 199, which is "The characterization of information or an information system based on an assessment of the potential impact that a loss of confidentiality, integrity, or availability of such information or info | |
| FRD-SDR | Security Decision Record (SDR) | A persistently maintained, verified, and validated record of the security decisions made by a provider over the lifecycle of a cloud service offering. The Security Decision Record replaces the traditional System Security Plan and documents | |
| FRD-SGC | Significant Change | Has the meaning given in NIST SP 800-37 Rev. 2 which is "a change that is likely to substantively affect the security or privacy posture of a system." | |
| FRD-SHD | SHOULD | There may exist valid reasons in particular circumstances to ignore this rule, but the full implications must be understood and carefully weighed. Parties MUST address such rules in their security documentation by explaining their decisions | |
| FRD-SNT | SHOULD NOT | There may exist valid reasons in particular circumstances when the particular action is acceptable or even useful, but the full implications must be understood and carefully weighed. Parties MUST address such rules in their security documen | |
| FRD-TLA | Top-Level Administrative Account | The most privileged account with the highest level of access within a cloud service offering for a customer organization, typically with complete control over all aspects of the cloud service offering, including managing resources, users, a | |
| FRD-TPR | Third-Party Information Resource | Any information resource that is not entirely included in the Minimum Assessment Scope for the cloud service offering obtaining FedRAMP Certification. | |
| FRD-TRC | Trust Center | A secure repository or service used by cloud service providers to store and share FedRAMP Certification Data. Trust centers are the complete and definitive source for FedRAMP Certification Data and must follow the FedRAMP Certification Data | |
| FRD-TRF | Transformative Change | The type of significant change that introduces substantive potential security risks that are likely to affect existing risk determinations and must be assessed in depth. | |
| FRD-VLD | Vulnerability Detection | The systematic process of discovering and identifying security vulnerabilities in information resources through assessment, scanning, threat intelligence, vulnerability disclosure mechanisms, bug bounties, supply chain monitoring, and other | |
| FRD-VLN | Validation | Confirmation through objective evidence that implemented security capabilities and related certification data are suitable for their intended FedRAMP Certification use and support the expected security outcomes for a cloud service offering. | |
| FRD-VLR | Vulnerability Response | The systematic process of tracking, evaluating, mitigating, monitoring, remediating, assessing exploitation, reporting, and otherwise managing detected vulnerabilities. | |
| FRD-VRF | Verification | Confirmation through objective evidence that specified FedRAMP Practices have been fulfilled for a cloud service offering. | |
| FRD-VUL | Vulnerability | Has the meaning given to "security vulnerability" in 6 USC § 650 (25), which is "any attribute of hardware, software, process, or procedure that could enable or facilitate the defeat of [...] management, operational, and technical controls | |
| AC-06-01 | AC-06-01 as FedRAMP applies it | ac-06.01_odp.02: all functions not publicly accessible ac-06.01_odp.05: all security-relevant information not publicly available | |
| AC-06-02 | AC-06-02 as FedRAMP applies it | ac-06.02_odp: all security functions | |
| AC-06-08 | AC-06-08 as FedRAMP applies it | ac-06.08_odp: any software except software explicitly documented | |
| AC-20 | AC-20 as FedRAMP applies it | The interrelated controls of AC-20, CA-3, and SA-9 should be differentiated as follows: AC-20 describes system access to and from external systems. CA-3 describes documentation of an agreement between the respective system owners when data | |
| AU-06 | AU-06 as FedRAMP applies it | This activity is considered vulnerability detection and is subject to the Vulnerability Detection and Response rules. | |
| AU-06-05 | AU-06-05 as FedRAMP applies it | This activity is considered vulnerability detection and is subject to the Vulnerability Detection and Response rules. | |
| AU-10 | AU-10 as FedRAMP applies it | au-10_odp: at least actions including the addition, modification, deletion, approval, sending, or receiving of data | |
| AU-12 | AU-12 as FedRAMP applies it | au-12_odp.01: at least all information system and network components where audit capability is deployed/available | |
| CA-02 | CA-02 as FedRAMP applies it | ca-02_odp.02: individuals or roles to include FedRAMP and agency customers | |
| CA-02-03 | CA-02-03 as FedRAMP applies it | ca-02.03_odp.01: any FedRAMP Recognized independent assessment service | |
| CA-07 | CA-07 as FedRAMP applies it | Follow the FedRAMP Continuous Collaborative Monitoring, Significant Change Notification, Vulnerability Detection and Response, and Vulnerability Evaluation and Reporting rules. | |
| CA-08 | CA-08 as FedRAMP applies it | Penetration testing is part of vulnerability detection and is subject to the Vulnerability Detection and Response rules. | |
| CM-01 | CM-01 as FedRAMP applies it | Follow the Significant Change Notification rules. | |
| CM-08 | CM-08 as FedRAMP applies it | Follow the FedRAMP Continuous Collaborative Monitoring, Significant Change Notification, Vulnerability Detection and Response, and Vulnerability Evaluation and Reporting rules. | |
| CM-11 | CM-11 as FedRAMP applies it | cm-11_odp.03: Continuously (via CM-7 (5)) | |
| CM-12 | CM-12 as FedRAMP applies it | Follow the FedRAMP Minimum Assessment Scope rules. | |
| CM-12-01 | CM-12-01 as FedRAMP applies it | Follow the FedRAMP Minimum Assessment Scope rules. | |
| CM-14 | CM-14 as FedRAMP applies it | If digital signatures/certificates are unavailable, alternative cryptographic integrity checks (hashes, self-signed certs, etc.) can be utilized. | |
| CP-02-03 | CP-02-03 as FedRAMP applies it | cp-02.03_odp.02: time period defined in service provider and organization Service Level Agreements | |
| CP-07-01 | CP-07-01 as FedRAMP applies it | The service provider may determine what is considered a sufficient degree of separation between the primary and alternate processing sites, based on the types of threats that are of concern. For one particular type of threat (i.e., hostile | |
| CP-10-04 | CP-10-04 as FedRAMP applies it | cp-10.04_odp: time period consistent with the restoration time-periods defined in the service provider and organization Service Level Agreements | |
| IA-02 | IA-02 as FedRAMP applies it | Multi-factor authentication must be phishing-resistant. In accordance with current CISA Guidance. Current CISA guidance can be found here: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa- | |
| IA-02-01 | IA-02-01 as FedRAMP applies it | Multi-factor authentication must be phishing-resistant. In accordance with current CISA Guidance. Current CISA guidance can be found here: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa- | |
| IA-02-02 | IA-02-02 as FedRAMP applies it | Multi-factor authentication must be phishing-resistant. In accordance with current CISA Guidance. Current CISA guidance can be found here: https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa- | |
| IA-02-06 | IA-02-06 as FedRAMP applies it | ia-02.06_odp.01: local, network and remote ia-02.06_odp.02: privileged accounts; non-privileged accounts | |
| IA-02-08 | IA-02-08 as FedRAMP applies it | ia-02.08_odp: privileged accounts; non-privileged accounts | |
| IA-04-04 | IA-04-04 as FedRAMP applies it | ia-04.04_odp: contractors; foreign nationals | |
| IA-05 | IA-05 as FedRAMP applies it | ||
| IR-01 | IR-01 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-02 | IR-02 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-02-01 | IR-02-01 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-02-02 | IR-02-02 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-03 | IR-03 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-03-02 | IR-03-02 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-04 | IR-04 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-04-01 | IR-04-01 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-04-02 | IR-04-02 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-04-04 | IR-04-04 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-04-06 | IR-04-06 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-04-11 | IR-04-11 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-05 | IR-05 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-05-01 | IR-05-01 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-06 | IR-06 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-06-01 | IR-06-01 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-06-03 | IR-06-03 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-07 | IR-07 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-07-01 | IR-07-01 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-08 | IR-08 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. | |
| IR-09 | IR-09 as FedRAMP applies it | Follow the FedRAMP Incident Evaluation and Communication rules. |
Showing 400 of 430; narrow with the search or a family.