Search Results

FedRAMP only accepts only one of five values for implementation-status: implemented, partial, planned, alternative, and not-applicable. A control may be marked "partial" and "planned" (using two separate implementation-status fields). All other choices are mut...

FedRAMP accepts only one of five values for control-origination: sp-corporate, sp-system, customer-configured, customer-provided, and inherited. Hybrid choices are expressed by identifying more than one control-origination, each in a separate prop field. For c...

OSCAL SSPs represent control responses in control-implementation / implemented-requirements / statements. See Control Implementation Statements to understand how to associate control responses with specific baseline controls and control statements. Within sta...

Most FedRAMP-required attachments derive their requirement from one or more NIST SP 800-53 controls. With an OSCAL SSP, the attachment is linked directly from the control. This is how tools know which attachment satisfies each requirement. Control ID Artifa...

Typically, the controls in the FedRAMP baselines have lettered parts (a., b., etc.). A few only have a top-level statement with no parts. Current FedRAMP templates expect responses at the lettered part level when present and at the top-level otherwise. OSCAL S...

OSCAL references controls in baselines and catalogs. The statements are not duplicated into an OSCAL SSP the way they are with a Word SSP. Conrol baseline requirements are imported by an OSCAL SSP and referenced as needed. Importing a Baseline Import the appr...

For systems that may be leveraged, OSCAL enables a robust mechanism for providing both inheritance details as well as customer responsibilities (referred to as consumer responsibilities by NIST). OSCAL is designed to enable leveraged and leveraging system SSP ...

This content uses YAML for examples. All examples are derived from complete example OSCAL content, which is available in all three OSCAL formats and published in the OSCAL Foundation's fedramp-resources GitHub repository: FedRAMP OSCAL Artifact Status ...

The metadata / roles array must have one entry for each column an id with a token (use pre-defined ID values whenever possible) a title with a human-readable role name The system-implementation / users array must have one entry for each row: a uuid (requir...

The OSCAL Foundation's FedRAMP Technical Focus Group (TFG) is enabling FedRAMP stakeholders to adopt OSCAL for FedRAMP package deliverables. The following is our plan of work: Milestones Phase 0: Form Team and Establish Resources [Complete] Phase 1: FedRAMP S...

The SSP title page follows the Title Pages pattern.

Core OSCAL requires somne content to be present all OSCAL artifacts. This is crtical to consistent processing. Root Element and Root-Level Universally Unique Identifier The root element must be one of the case-sensitive OSCAL model names: catalog profile mapp...

FedRAMP no longer includes System Status in the SSP template; however core OSCAL requires the system status to be identified. The system statys is represented in system-characteristics. A status entry that includes: state field set to one of the allowed val...

Every FedRAMP assessment package must identify the party (individual, team or organization) responsible for pre-defined roles, such as system owner and information system security officer (ISSO). Representing this information in OSCAL requires four important e...

Attachments All OSCAL models handle attachments the same way. The following is used to attach files to OSCAL-based FedRAMP artifacts, such as when attaching policies and plans to a System Security Plan (SSP) or evidence to a Security Assessment Report (SAR). I...

This entire chapter is FedRAMP PMO boilerplate and does not need to be represented in OSCAL content.

This entire chapter is FedRAMP PMO boilerplate and does not need to be represented in OSCAL content.

System Owner follows the Roles pattern, using the system-owner role. Defined Identifiers Required Role ID: system-owner