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 Type 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.

Step Nine: CSP Submission

A pilot participant might choose to submit their package in any way they like as long as FedRAMP is not required to create accounts to access the package.

Some examples of possible submission methods include:

A CSP publicly hosts their package in a repository on GitHub
A CSP writes an API that grants access to the package
A CSP hosts the package in a secure portal and grants FedRAMP an API key
A CSP provides a time-limited url token with a separate encrypted passcode