Pilot Participation Example

This example describes how a participant might approach each step of the pilot process.

Step One: Lightweight Documentation

A pilot participant might begin by putting together a summary of the cloud service provider and cloud service offering.

Step Two: Key Security Indicators and Validations

A pilot participant might review the most updated version of the FedRAMP Key Security Indicators. Each KSI defines a security objective and lists multiple KSI Validations which, when met, demonstrate that a system has achieved the security objective. A pilot participant might provide a true/false/partial assertion to each KSI Validation.

Step Three: Validation Evidence

A pilot participant might provide evidence to support each Key Security Indicator Validation with an assertion of “true”. For this initial pilot, there is no prescribed list of acceptable evidence, and supporting evidence can be provided in many ways. For example:

• The host infrastructure or a compliance service might provide a technical attestation that an offering is configured in a way that meets a KSI Validation
• Materials for an existing SOC 2 audit might demonstrate compliance with the KSI Validation
• A 3PAO might assess the service offering and validate that the KSI Validation is implemented
• Another method proposed by the cloud service provider

Step Four: Automation and Machine Readable Data Requirements

A pilot participant might produce a machine-readable file that addresses each Key Security Indicator Validation. This file includes the KSI Validation assertions from Step Two, and their associated evidence from Step Three. They assemble this file in a machine-readable format of their choosing and design, with the following criteria:

• The file can be regenerated on demand
• The file includes a data definition or data schema explaining how the submission maps to the KSI elements

Step Five: 3PAO Review

The pilot participant’s 3PAO reviews their submission and adds attestations to the machine-readable file for each Key Security Indicator validation, including a digital signature. The 3PAO provides a summary explaining the approach used for assessment.

Step Six: Continuous Reporting Indication

The machine-readable file might indicate which of the pilot participant’s Key Security Indicator Validations can be reported on continuously. This might involve identifying which KSI Validation evidence is generated by an automated process that executes continuously without human intervention.

Preferably, this indication would appear in the machine-readable data format, and would include meta-data of where and when the evidence was collected.

Step Seven: Prototype for Continuous Reporting

Pilot participants might use the indications developed in Step Six to develop a proposal or prototype for continuously reporting on those KSI Validations. This could look like:

• Designing an API interface that serves the latest security status of the system
• Deploying a static URL endpoint that can serve the latest security status of a system

Step Eight: CSP Rationale and Summary

A pilot participant might produce a summary of and rationale for the approach used to generate the machine-readable file, including their evidence generation methods.