Evidence & Artifact Planner

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

• —Configuration settings for FSI mailbox
• —Automated validation to check FSI mailbox configuration

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

• —Email address to receive messages from FedRAMP

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

• —Process, manual or automated, to notify FedRAMP of changes in the FedRAMP Security Inbox

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

• —Configuration settings for FSI mailbox
• —Automated validation to check FSI mailbox configuration

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.

• —How the summary will be delivered

Providers MUST supply an Ongoing Certification Report to all necessary parties every 3 months, covering the entire period since the previous summary, in a consistent format that is human readable; this report MUST include high-level summaries of at least the following information:

• —Most recent Ongoing Certification Report. If the report is not available, the provider MUST provide a sample report that includes all required information.
• —How the report will be delivered

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

• —How to access the feedback mechanism.

• Aselected ordinal recurrence for the synchronous Quarterly Review cycle if applicable.
• Bselected ordinal recurrence for the Ongoing Certification Report cycle if applicable OR explanation for why Ongoing Certification Reports are not being delivered.
• Cselected ordinal recurrence for the Ongoing Certification Report cycle.
• Dselected ordinal recurrence for the Ongoing Certification Report cycle.

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

• —URL to the registration page or calendar file.

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.

• —Explanation of how to access this information.

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:

• —Explanation of how to access this information.

• AExplanation of the supplied materials, including how to access and use them.
• BExplanation of the supplied materials, including how to access and use them.
• CExplanation of the supplied materials, including how to access and use them.
• DExplanation of the supplied materials, including how to access and use them.

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:

• —URL to the human-readable data.
• —URL to the machine-readable data.

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.

• —Explanation of if and how this information is shared with other parties.

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

• —URL to the human-readable data.
• —URL to the machine-readable data (if applicable).

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.

• —Explanation of how FedRAMP can obtain this information.

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.

• —Explanation of how the appropriate parties can obtain this log information.

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

• —URL to the documentation for programmatic access.

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.

• —URL or explanation how to access documentation of these features and capabilities.

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

• —URL or explanation of how to request these materials.
• —Explanation of how the provider decides whether or not to share these materials or other related policies.

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

• —List of cryptographic modules used by default including whether these modules are validated under the NIST Cryptographic Module Validation Program or are update streams of such modules.

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

• —List of cryptographic modules including whether these modules are validated under the NIST Cryptographic Module Validation Program or are update streams of such modules.

• AList of cryptographic modules including whether these modules are validated under the NIST Cryptographic Module Validation Program or are update streams of such modules.
• BList of cryptographic modules including whether these modules are validated under the NIST Cryptographic Module Validation Program or are update streams of such modules.
• CList of cryptographic modules including whether these modules are validated under the NIST Cryptographic Module Validation Program or are update streams of such modules.
• DList of cryptographic modules including whether these modules are validated under the NIST Cryptographic Module Validation Program or are update streams of such modules.

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.

• —An incident log showing an example of one or more incidents being evaluated including the reason for the determination. The log can be from real incidents, simulated incidents, or a combination of sources.

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

• —An incident log showing an example of one or more incidents being evaluated including the reason for the determination. The log can be from real incidents, simulated incidents, or a combination of sources.

• AAn Final Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• BAn Final Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• CAn Final Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• DAn Final Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.

• AAn Initial Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• BAn Initial Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• CAn Initial Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• DAn Initial Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.

• AAn Ongoing Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• BAn Ongoing Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• CAn Ongoing Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.
• DAn Ongoing Incident Report for one or more incidents. The report can be from real incidents, simulated incidents, or a combination of sources.

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.

• —A machine readable output containing all required data of the permitted connections between components of the cloud service offering that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering.
• —A human readable explanation of how the machine readable output is derived.
• —The code for the automated process used to generate the machine readable output.

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

• —A machine readable output containing all required data of the components of the cloud service offering that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering.
• —A human readable explanation of how the machine readable output is derived.
• —The code for the automated process used to generate the machine readable output.

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

• —A machine readable output containing all required data of the metadata collected or maintained by the cloud service offering that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering.
• —A human readable explanation of how the machine readable output is derived.
• —The code for the automated process used to generate the machine readable output.

Providers MUST address the potential impact to federal customer data from third-party information resources used by the cloud service offering, ONLY IF MAS-CSO-IIR (Identify Information Resources) APPLIES, by documenting the following information about each applicable third-party information resource:

• —A machine readable output containing all required data of the third-party information resources of the cloud service offering that are likely to handle federal customer data or likely to impact the confidentiality, integrity, or availability of federal customer data handled by the cloud service offering.
• —A human readable explanation of how the machine readable output is derived.
• —The code for the automated process used to generate the machine readable output.

Advisors MUST have an appropriate web site that publicly supplies at least the following information in consistent machine-readable and human-readable formats:

• —URL to the human-readable data.
• —URL to the machine-readable data.

Assessors MUST have an appropriate web site that publicly supplies at least the following information in human-readable and JSON formats:

• —URL to the human-readable data.
• —URL to the machine-readable data.

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

• —URL or explanation of how to request these materials.
• —Explanation of how the provider decides whether or not to share these materials or other related policies.

Providers SHOULD make the Secure Configuration Guide available publicly.

• —Explanation of how to access this information
• —or explanation why this functionality is not available

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:

• —URL to the human-readable data.
• —URL to the machine-readable data.

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

• —Explanation of how to access this information
• —or explanation why this functionality is not available

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

• —Explanation of how to access this information
• —or explanation why this functionality is not available

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

• —Explanation of how to access this information
• —or explanation why this functionality is not available

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

• —Explanation of how to access this information
• —or explanation why this functionality is not available

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.

• —Explanation of how to access this information
• —or explanation why this functionality is not available

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.

• —Explanation of how to access this information
• —or explanation why this functionality is not available

Providers MUST notify all necessary parties within 10 business days after finishing adaptive changes, also including the following information:

• —At least the most recent SCN notification including the date it was sent and the date the change was applied. Additional examples may be provided. If no SCN notifications have been sent then this artifact is not required.

Providers MUST evaluate all potential significant changes to determine the type of significant change and follow the appropriate Significant Change Notification rules.

• —Evidence of significant change evaluation including a description fo the change, the determined type, and an explanation for the decision. At least one example must be provided for each type of change. Real examples are prefered but the provider may use fictitious examples as long as the example provides evidence of the decision making process.

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

• —Explanation of how FedRAMP can obtain this information.

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

• —URL or explanation of how to request these materials.
• —Explanation of how the provider decides whether or not to share these materials or other related policies.

Providers MUST include at least the following information in Significant Change Notifications:

• —A recent Significant Change Notification or sample Significant Change Notification

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.

• —Explanation of how FedRAMP can obtain this information.

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.

• —Current list of available notification mechanisms

Providers MUST notify all necessary parties within 5 business days after finishing transformative changes, including updates to all previously sent information.

• —At least the most recent post deployment SCN notification for a transformative change including the date it was sent and the date the change was applied. Additional examples may be provided. If no transformative SCN notifications have been sent then this artifact is not required.

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:

• —At least the most recent after verification SCN notification for a transformative change including the date it was sent and the date the change was applied. Additional examples may be provided. If no transformative SCN notifications have been sent then this artifact is not required.

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.

• —At least the most recent final SCN notification for a transformative change including the date it was sent and the date the change was applied. Additional examples may be provided. If no transformative SCN notifications have been sent then this artifact is not required.

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.

• —At least the most recent initial SCN notification for a transformative change including the date it was sent and the date the change was applied. Additional examples may be provided. If no transformative SCN notifications have been sent then this artifact is not required.

Providers SHOULD engage a third-party assessor to review the scope and impact of the planned change before starting transformative changes if human validation is necessary; such reviews SHOULD be limited to security decisions that require human validation.

• —Third Party assesment report OR explanation why a third party assessor was not engaged

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

• —Date of the most recent transformative change and the date of the corresponding documentation update. If no documentation updates were required as the result of this change, explain how this was determined.

Providers MUST include the following information on accepted vulnerabilities when reporting on vulnerability detection and response activity:

• —A recent vulnerability report or a sample vulnerability report

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:

• —A recent vulnerability report or a sample vulnerability report

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

• —A recent vulnerability report or a sample vulnerability report

• AURL and access instructions for historical vulnerability detection and response activity in machine readable format
• BURL and access instructions for historical vulnerability detection and response activity in machine readable format
• Bor an explanation of why machine readable content is not being provided
• CURL and access instructions for historical vulnerability detection and response activity in machine readable format
• Cor an explanation of why machine readable content is not being provided
• DURL and access instructions for historical vulnerability detection and response activity in machine readable format
• Dor an explanation of why machine readable content is not being provided