# FedRAMP System Security Plan (SSP)
# Adopting OSCAL for SSP Representation
# SSP Adoption Strategies
The best way to adopt OSCAL for your system depends on your circumstances. The OSCAL Foundation defines two adoption strategies:
- **Retrofit Adoption Path**: Converting Legacy Documentation
- **Native Adoption Path**: Creating New Documentation
---
### Retrofit Adoption Path
If you need to convert legacy documentation to OSCAL, follow the [Retrofit Adoption Path](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/retrofit-adoption-path).
Migrate existing content to OSCAL with the minimum necessary refactoring, and normalize content over time.
---
### Native Adoption Path
If you are approaching OSCAL to intially create your system security plan and do not have legacy documentaiton to convert, follow the [Native Adoption Path](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/native-adoption-path).
The FedRAMP PMO prefers new systems follow the FedRAMP 20x Authorization Path. We will prioritize 20x representation in OSCAL based on demand from CSPs and Agency Authorizing Officials (AO).
# Retrofit Adoption Path
If you need to convert legacy documentation to OSCAL, follow this path.
If you are approaching OSCAL to intially create your system security plan and do not have legacy documentation to convert, follow the [Native Adoption Path](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/native-adoption-path).
---
Organizations with existing Word and Excel based authorization packages must first migrate their content to OSCAL with only the minimum necessary refactoring. The _Retrofit Adoption Path_ starts with a minimum viable product (MVP) and evolves to more comprehensive use cases in phases.
This approach initially sacrifices data normalization in favor of a more rapid transition to OSCAL. It allows conversion of content as-is, then gradually eliminates redundancy and normalizes data in subsequent phases. This is possible because OSCAL is designed to meet you where you are, and it allows gradual progress toward its more normalized ideal representation.
## SSP Retrofit Adoption Overview
The OSCAL Foundation recommends the following addoption path for migrating legacy FedRAMP SSP content to OSCAL.
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-04/retro-adoption-path.png)
To facilitate conversion of legacy Word content, OSCAL allows legacy control responses to be associated with the "this-system" component. CSPs can migrate slowly over time to the OSCAL's preferred per-component responses.
---
## SSP Adoption Path
#### MINIMUM VIABLE PRODUCT (MVP)
- **Import Baselines as _Resolved Profile Catalogs_**
- Get started with Use pre-processed control baselines.
- See [Baselines](https://patterns.rufrisk.com/books/supporting-resources-and-valid-content/page/baselines) for more information.
- **Minimum Required Fieldss and Basic CSP and System Details.**
- **`metadata`** includes:
- `title`, `published`, `last-modified`, `version`, `oscal-version`
- `roles`: `cloud-service-provider`, `information-system-security-officer`, others as cited in controls.
- See _[Roles](https://patterns.rufrisk.com/books/fedramp-common/page/roles)_ for more information on roles.
- `parties`: the CSP, the ISSO.
- See _[Parties and Locations](https://patterns.rufrisk.com/books/fedramp-common/page/parties-and-locations)_ for more information on defining parties.
- `responsible-parties`: exactly one, linking the CSP party to the CSP role
- See _[Roles](https://patterns.rufrisk.com/books/fedramp-common/page/roles)_ for more information on associating parties with roles.
- **`system-characteristics`** includes:
- `system-id`, `system-name`, `system-name-short`, `description`, _cloud-service-model_ `prop` and _cloud-deployment-model_ `prop`
- See _[3. System Information](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/3-system-information)_ for more information
- `security-sensitivity-level` (`fips-199-high`, `fips-199-moderate`, `fips-199-low`)
- `system-information`: exactly one entry with Appendix K pasted into the `description`
- `status` set to `operational` (required OSCAL fields)
- See _[System Status](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/system-status)_ for more information.
- `authorization-boundary`, `network-architecture` and `data-flow`: `description` and `links` entry identifying the external attachment.
- See _[8. Illustratred Architecture and Narratives](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/8-illustratred-architecture-and-narratives)_ for more information.
- **`system-implementation`** includes:
- `components:
- Exactly one, with `type`= _`this-system`_ (Known as the "this-system" component, which represents the system as a whole.)
- See _[Components](https://patterns.rufrisk.com/books/system-security-plans/page/components)_ for more information.
- **Flat Inventory Migration**
- Convert directly from spreadsheet.
- Non-normalized. No corrisponding components.
- **`system-implementation`:**
- `inventory-items`: All inventory converted from Excel spreadsheet
- **Migrate Control Response**
- Minimum-necessary adjustments for OSCAL.
- All response statements in the "this-system" component.
- `control-implementation`
- `implemented-requirement` (AC-1, AC-2, etc.)
- `set-parameters`: set parameters as needed
- `statement` (part a, part b, etc.
- `by-component` ("this system")
- `description`: Content directly from legacy Word SSP (part a, part b, etc.)
- `implementation-status`
- `responsible-roles`: One entry per role. Use `role-id`. Must match `metadata/roles/id`.
During transition, any portion of the Word SSP not yet converted to OSCAL should be attached to the OSCAL SSP content.
---
#### INTERMEDIATE
- **Required Attachments**
- Add direct `links` from the appropriate controls to identify relevant attachments
- **Required SSP Roles**
- `metadata/roles` The roles required by SSP (System owner, ISSO, AO, etc.)
- `metada/parties`: the people, teams and organizations responsible for the above roles
- `metadata/responsible-parties`: links the above `roles` and `parties`
- **Information Types**
- `system-characteristics/system-information/information-types`
- a single entry for each row in appendix K.
- **Leveraged Authorizations**
- `system-implementation/leveraged-authorizations`:
- one entry for leveraged authorization
- corrisponding `metadata/parties` entry for each
- corrisponding `system-implementation/components` for each.
- **Separation of Duties Matrix**
- `system-implementation/users`
- one entry per row in Table 11.1
- `./authorized-privilege/functions-performed`: SSP Table 11.1 Duty Description (just one entry in the array)
- `./authorized-privilege/title`: Required by OSCAL, not by FedRAMP. Recommend duplicating the `functions-performed` content.
- `role-ids`: links `metadata/roles` to `functions-performed`
- **Customer Responsibility and Inheritance**:
- Move customer responsibility statements to `//by-components/export/responsibilities`
---
#### ADAVANCED
- **Normalize Inventory**: Transition flat inventory to component-based inventory.
- Use `components` to the greatest degree practical
- `inventory-items` become implemented instances of components
- **External Systems and Services**
- `system-implementation/components` entries for each
- **Transition to `resources`**
- Where practical, use URI fragments in `links` to reference resources instead of direct links. See _[section citation and link]_ for more information.
- **Components for Required Documents**
- One for each required document (policies, procedures, plans, user guides, Rules of Behavior)
- See _[Section citation and link]_ for more information.
---
#### NORMALIZED
- **Import Baselines as Profiles**
- Eliminate reliance on _resolved profile catalogs_
- Ensure your tools have the ability to process profiles by this phase.
- Ensure consumers of your SSP are able to process profiles.
- **Services, Ports and Protocols**
- **Migrate to component-based control responses**
- Add `components` entries as needed to support normalized inventory
- Add `by-components` entries to `implemented-requirements` for each relevant component
- Add/move component-specific control responses to their associated `by-components` response.
- Migrate slowly over time.
- **Cryptographic Modules (App Q table)**
#### Profile Imports
The decision to import a _profile_ or _resolved profile catalog_ is dependent on the profile processing capability of your tools and the tools of any receiving party.
Pre-processed _resolved profile catalogs_ are a simplified way to get started; however, OSCAL tools must ultimately process profiles. Processing OSCAL profiles is the only way tools can handle control overlays and multiple frameworks.
If you elect to start with _resolved profile catalogs_, migrate to _profiles_ as soon as yoru tools and your recipients tools can perform this processing.
#### Easy Migration
Within an OSCAL SSP, migration is performed simply by changing the `import-profile` statement to reference the appropriate _profile_ instead of a _resolved profile catalog_.
---
# Native Adoption Path
If you are approaching OSCAL to intially create your system security plan and do not have legacy documentation to convert, follow this path.
If you need to convert legacy documentation to OSCAL, follow the [Retrofit Adoption Path](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/retrofit-adoption-path).
The FedRAMP PMO prefers new systems follow the FedRAMP 20x Authorization Path. We will prioritize 20x representation in OSCAL based on demand from CSPs and Agency Authorizing Officials (AO).
---
Organizations adopting OSCAL for initial SSP creation must be mindful of OSCAL's relational dependencies to ensure efficient content population. The _Native Adoption Path_ starts with `components` and other core system details, then builds on those components in later phases to achieve highly normalized and complete SSP content.
This approach prioritzes data normalization from the start. It establishes foundational data elements on which later phases build. This ensures logical sequencing of activties and efficient progression of SSP detail.
## SSP Native Adoption Overview
The OSCAL Foundation recommends the following addoption path when creating an OSCAL-based FedRAMP SSP from scratch.
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-04/new-adoption-path.png)
### CORE
- **Import _Resolved Profile Catalogs_**
- Get started with Use pre-processed control baselines.
- See [Baselines](https://patterns.rufrisk.com/books/supporting-resources-and-valid-content/page/baselines) for more information.
- **Minimum Required Fields and Basic CSP and System Details**
- **`metadata`** includes:
- `title`, `last-modified`, `version`, `oscal-version` (required OSCAL fields)
- `roles`: `cloud-service-provider`
- `parties`: the CSP
- `responsible-parties`: exactly one, linking the CSP party to the CSP role.
- **`system-characteristics`** includes:
- `system-id`, `system-name`, `system-name-short`, `description` (required OSCAL fields)
- _cloud-service-model_ and _cloud-deployment-model_ `props`
- `status` set to `operational` (required OSCAL fields)
- `authorization-boundary/description`: Only a brief description is required.
- **Information Types and System Categorization**
- **`system-characteristics`** includes:
- `system-information`
- `security-sensitivity-level` (`fips-199-high`, `fips-199-moderate`, `fips-199-low`)
- See [Appendix K: FIPS-199 Worksheet](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/appendix-k-fips-199-worksheet) for more information.
- **OSCAL Components for Required Documents and System Elements**
- **`system-implementation`**
- **`components`**:
- Exactly one "this system" component (`type`= _`this-system`_) (Represents the system as a whole.)
- One for each technical element (hardware, software, virtual appliance, service) used in the system
- One for each required document (policies, procedures, plans, user guides, Rules of Behavior)
- See _[Section citation and link]_ for more information.
### DETAIL
- **SSP-Required Roles and Parties**: See _[Seciton citation and link]_
- **Leveraged Authorizations**: See _[Seciton citation and link]_
- **External Systems and Services**: See _[Seciton citation and link]_
- **Ports and Protocols**: See _[Seciton citation and link]_
- **Separation of Duties**: See _[Seciton citation and link]_
- **Cryptographic Modules**: See _[Seciton citation and link]_
- **Diagrams**: See _[Seciton citation and link]_ See _[Seciton citation and link]_
- Boundary/Architecture Diagram and Narriative
- Network Architecture Diagram and Narriative
- Data Flow Diagram and Narriative
### CONTROLS
- **Align Components to Controls**: See _[Seciton citation and link]_
- **Respond to Controls per-Component**: See _[Seciton citation and link]_
### NORMALIZED
- **Import Baselines as Profiles**
- Eliminate reliance on _resolved profile catalogs_
- Ensure your tools have the ability to process profiles by this phase.
- Ensure consumers of your SSP are able to process profiles.
- **Component-Based Inventory Representation**: See _[Seciton citation and link]_
- **Verify/Adjust Control Origin and Aggregated Status**: See _[Seciton citation and link]_
- **Add Customer Responsibilities**: See _[Seciton citation and link]_
---
# OSCAL Requirements
All [OSCAL Core Requirements](https://patterns.rufrisk.com/books/core-requirements) must be met for all OSCAL artifacts.
This chapter contains information about OSCAL SSP requirements that are not explicit FedRAMP SSP requirements.
# System Status
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 values.
- A `remarks` field is optional if the `state` is `operational`. Otherwise, the `remarks` field must be present.
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
status:
state: operational
remarks: 'Remarks are optional if status/state is "operational".
Remarks are required otherwise.'
```
**OSCAL Allowed Values**
Valid `state` values:
- `operational` (`remarks` optional)
- `under-major-modification` (`remarks` required)
- `other` (`remarks` required)
Although core OSCAL also allows `under-development` and `disposition` (retired), these values do not make sense in a FedRAMP authorization package.
# Title Page, Prepared by/for, Approvers
# Title Page
The SSP title page follows the [Title Pages](https://patterns.rufrisk.com/books/fedramp-common/page/title-pages) pattern.
---
# Prepared By/For
_Prepared By_ and _Prepared For_ follow the [Roles](https://patterns.rufrisk.com/books/fedramp-common/page/roles) pattern, using the `prepared-by` and `prepared-for` roles.
For an SSP:
- `prepared-by` may identify the cloud service provider or a thrid party advisory organization
- `prepared-for` always identifes the cloud service provider
**Defined Identifiers**
Required Role IDs:
- `prepared-by`
- `prepared-for`
##### Prepared By - CSP or Self‑Prepared
When the SSP is preapred by the CSP the `metadata` must include:
- a `roles` entry with an `id` of `prepared-by`
- a `parties` entry that represents the CSP
- a `responsible-parties` entry with:
- a `role-id` of `prepared-by`
- a `parties-uuid` array with one entry:
- the `uuid` value of the CSP entry in the `parties` array above.
```yaml
metadata:
roles:
- id: prepared-by
title: Prepared By
parties:
- uuid: d865602c-9d3b-49d7-8125-ce3f1ca04231
type: organization
name: CSP Name
responsible-parties:
- role-id: prepared-by
party-uuids:
- d865602c-9d3b-49d7-8125-ce3f1ca04231
```
##### Prepared By - Third Party
When the SSP is preapred by an advisory firm, the `metadata` must include:
- a `roles` entry with an `id` of `prepared-by`
- a `parties` entry that represents the third party firm
- a `responsible-parties` entry with:
- a `role-id` of `prepared-by`
- a `parties-uuid` array with one entry:
- the `uuid` value of the third party firm's entry in the `parties` array above.
```yaml
metadata:
roles:
- id: prepared-by
title: Prepared By
parties:
- uuid: d865602c-9d3b-49d7-8125-ce3f1ca04231
type: organization
name: Third Party Firm Name
responsible-parties:
- role-id: prepared-by
party-uuids:
- d865602c-9d3b-49d7-8125-ce3f1ca04231
```
##### Prepared For
The SSP is always prepared for the CSP. The `metadata` must include:
- a `roles` entry with an `id` of `prepared-for`
- a `parties` entry that represents the CSP
- a `responsible-parties` entry with:
- a `role-id` of `prepared-for`
- a `parties-uuid` array with one entry:
- the `uuid` value of the CSP entry in the `parties` array above.
```yaml
metadata:
roles:
- id: prepared-for
title: Prepared For
parties:
- uuid: d865602c-9d3b-49d7-8125-ce3f1ca04231
type: organization
name: CSP Name
responsible-parties:
- role-id: prepared-for
party-uuids:
- d865602c-9d3b-49d7-8125-ce3f1ca04231
```
# System Security Plan Approvals
SSP Approvals follow the [Roles](https://patterns.rufrisk.com/books/fedramp-common/page/roles) pattern, using the `content-approver` role.
**Defined Identifiers**
Required Role IDs:
- `content-approver`
---
# Sections 1 - 11
# 1. Introduction
This entire chapter is FedRAMP PMO boilerplate and does not need to be represented in OSCAL content.
# 2. Purpose
This entire chapter is FedRAMP PMO boilerplate and does not need to be represented in OSCAL content.
# 3. System Information
## System Information
### CSP Name
The cloud service provider (CSP) name and abbreviation are represented in the SSP `metadata`.
- A `roles` extry must exist with `id` = `cloud-service-provider`
- A `parties` entry must exist with the CSP's `name` and `short-name`.
- A `responsible-parties` entry must exist to link the `parties` UUID value to the `cloud-service-provider` role.
#### OSCAL Representation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
metadata:
roles:
- id: cloud-service-provider
title: Cloud Service Provider
short-name: CSP
parties:
- uuid: 11111111-2222-4000-8000-004000000001
type: organization
name: Cloud Service Provider (CSP) Name
short-name: CSP Acronym/Short Name
responsible-parties:
- role-id: cloud-service-provider
party-uuids:
- 11111111-2222-4000-8000-004000000001
```
---
### CSO Name
The CSO name and abbreviation are represented in `system-characteristics`.
- The `system-name` field contains the CSO Name
- The `system-name-short` field contains the CSO abbreviation.
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
system-name: System's Full Name
system-name-short: System's Short Name or Acronym
system-ids:
- identifier-type: http://fedramp.gov/ns/oscal
id: F00000000
```
---
### FedRAMP Package ID
The FedRAMP Package ID is represented in `system-characteristics`.
- A `system-ids` entry must exist that includes:
- `identifier-type` set to `http://fedramp.gov/ns/oscal`
- `id` set to the FedRAMP Package ID
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
system-ids:
- identifier-type: http://fedramp.gov/ns/oscal
id: F00000000
```
**FedRAMP Allowed Value**
Required Identifier Type:
- identifier-type="https://fedramp.gov"
---
### Service Model
The Service Model is represented in `system-characteristics`.
- A `system-characteristics` property (`prop`) entry must exist that includes:
- A `name` set to `cloud-service-model`
- A `value` set to one of the allowed service model values below.
- If the `value` is set to `other`, `remarks` is used to explain.
If more than one service model type is applicable (IaaS and PaaS; IaaS and PaaS and SaaS; PaaS and SaaS), use one "cloud-service-model" prop for _each_ applicable cloud service model.
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
props:
- name: cloud-service-model
value: iaas
- name: cloud-service-model
value: paas
- name: cloud-service-model
value: other
remarks: Remarks are required if service model is "other". Optional otherwise.
```
**OSCAL Allowed Values**
Valid `cloud-service-model` property values:
- `saas`
- `paas`
- `iaas`
- `other`
---
### Digital Identity Level (DIL) Determination
See [Appendix E](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/appendix-e-digital-identity-level-dil-determination) for appropriate OSCAL representation.
---
### FIPS PUB 199 Level
See [Appendix K](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/appendix-k-fips-199-worksheet) for appropriate OSCAL representation.
---
### Fully Operational as of
The fully operational date is represented in `system-characteristics`.
- A `system-characteristics` property (`prop`) entry must exist that includes:
- A `name` set to `fully-operational-date`
- A `ns` set to `http://fedramp.gov/ns/oscal`
- A `value` set to the operational date.
Although the `value` field is a string, the date should be treated as an OSCAL [date-time-with-timezone](https://pages.nist.gov/metaschema/specification/datatypes/#date-time-with-timezone) data type.
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
props:
- name: fully-operational-date
ns: http://fedramp.gov/ns/oscal
value: '2023-12-31T00:00:00Z'
```
---
### Deployment Model
The Deployment Model is represented in `system-characteristics`.
- A `system-characteristics` property (`prop`) entry must exist that includes:
- A `name` set to `deployment-model`
- A `value` set to one of the allowed deployment model values below.
- If the `value` is set to `other`, `remarks` is used to explain.
- Only one `cloud-deployment-model` property is permitted.
If the deployment model is `hybrid` or `other`, the remarks field is required. Otherwise, it is optional.
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
props:
- name: cloud-deployment-model
value: hybrid-cloud
remarks: Remarks are required if deployment model is "hybrid-cloud" or "other". Optional otherwise.
```
**FedRAMP Accepted Values**
Valid `cloud-deployment-model` property values:
- `public-cloud`
- `private-cloud`
- `government-only-cloud`
- `hybrid-cloud`
- `other`
Although core OSCAL also allows `community-cloud`, FedRAMP authorizations do not include community clouds.
---
### Authorization Path
This is an obsolete concept and does not need to be represented in OSCAL.
---
### General System Description
The General System Description is represented in `system-characteristics`.
- The `description` field contains the general system description.
- This is a [markup-multiline](https://pages.nist.gov/metaschema/specification/datatypes/#markup-multiline) field.
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
description: '\[Insert CSO Name\] is delivered as \[a/an\] \[insert based on the Service Model above\] offering using a multi-tenant \[insert based on the Deployment Model above\] cloud computing environment. It is available to \[Insert scope of customers in accordance with instructions above (for example, the public, federal, state, local, and tribal governments, as well as research institutions, federal contractors, government contractors etc.)\].'
```
# 4. System Owner
_System Owner_ follows the [Roles](https://patterns.rufrisk.com/books/fedramp-common/page/roles) pattern, using the `system-owner` role.
**Defined Identifiers**
Required Role ID:
- `system-owner`
---
# 5. Assignment of Security Responsibility
_Information System Security Officer (ISSO)_ follows the [Roles](https://patterns.rufrisk.com/books/fedramp-common/page/roles) pattern, using the `information-system-security-officer` role.
**Defined Identifiers**
Required Role ID:
- `information-system-security-officer`
---
# 6. Leveraged FedRAMP-Authorized Services
The leveraged FedRAMP-Authorized services table is used to list both underlying leveraged authorizations, such as a SaaS running on an IaaS, and use of external cloud services with FedRAMP authorizations, such as a FedRAMP-authorized third party identity management service.
For each row in Table 6.1 there must be:
- a `parties` entry
- a `leveraged-authorizations` entry
- a `components` entry
### `parties` Entry
A `parties` entry to indicate the organizaiton that owns the leveraged system or external service
```yaml
system-security-plan:
metadata:
parties:
- uuid: 22222222-2222-4000-8000-004000000001
type: organization
name: Leveraged System Provider's Name
short-name: LSPN
```
### `leveraged-authorizations` Entry
The `leveraged-authorizations` entry must include:
- a `uuid`
- a `title` with the name of the system or service exactly as it appears in the FedRAMP Marketplace
- a `props` entry with:
- `name` set to `package-id`
- `ns` set to `http://fedramp.gov/ns/oscal`
- `value` set to the package ID exactly as it appears in the FedRAMP Marketplace
- a `props` entry with:
- `name` set to `security-sensitivity-level`
- `ns` set to `http://fedramp.gov/ns/oscal`
- `value` set to `fips-199-low`, `fips-199-modarete` or `fips-199-high` consistent with the FedRAMP Marketplace Information
- a `party-uuid` with the UUID of the `parties` entry above
- a `date-authorized` with the date listed in the FedRAMP Marketplace, expressed in [OSCAL `date` format](https://pages.nist.gov/metaschema/specification/datatypes/#date).
**FedRAMP Extensions**
FedRAMP Extensions are defined when there is no way to represent required information using core OSCAL. They are depicted as propterties (`props` entries) with a namespace (`ns`) value set to `http://fedramp.gov/ns/oscal`. Without the namespace, these properties may be ignored or flagged as invalid.
```yaml
system-security-plan:
system-implementation:
leveraged-authorization:
- uuid: 11111111-2222-4000-8000-019000000001
title: CSO Name
props:
- name: package-id
ns: http://fedramp.gov/ns/oscal
value: F9999999999
- name: security-sensitivity-level
ns: http://fedramp.gov/ns/oscal
value: fips-199-high
party-uuid: 22222222-2222-4000-8000-004000000001
date-authorized: '2015-01-01'
```
**Allowed Values**
The FedRAMP extension `security-sensitivity-level`:
- `fips-199-high`
- `fips-199-moderate`
- `fips-199-low`
### `components` Entry
The `components` entry must include:
- a `uuid `
- a `type` set to `system`
- a `title` set to the name of the leveraged system
- a `description` of the system. This is a core OSCAL requirement. FedRAMP has no specific requirement for the content of this field.
- a `props` entry with:
- `name` set to `leveraged-authorization-uuid`
- `value` set to the UUID of the `leveraged-authorization` entry above
- a `props` entry with:
- `name` set to `nature-of-agreement`
- `ns` set to `http://fedramp.gov/ns/oscal`
- `value` set to `sla`, `contract` [needs more definition]
- a `props` entry with:
- `name` set to `authentication-method`
- `ns` set to `http://fedramp.gov/ns/oscal`
- `value` set to the package ID exactly as it appears in the FedRAMP Marketplace
- One `props` entry for each "Data Type":
- `name` set to `information-type`
- `ns` set to `http://fedramp.gov/ns/oscal`
- `value` set to the NIST SP 800-60 Volume 2 information ID
- `class` set to `incoming` or `outgoing`
- If the same information type is exchanged in both directions, there must be one `props` entry for incoming and a separate props entry for outgoing.
- The `status` assembly with the `state` field set to `operational`
- For FedRAMP the value must always be operational; however, this is a required OSCAL field and cannot be omitted.
- One or more `responsible-roles` entries:
- Identify the Provider (Required):
- `role-id` set to `provider` (ensure `metadata` has a `roles` entry with `id` set to `provider`)
- a `party-uuids` entry with the UUID of the `parties` entry defined above.
- _Authorized Users_: One entry per authorized user type:
- `role-id`
- Use OSCAL-defined canonical values where appropriate.
- If no canonoical value exists, create an appropriate value that conforms with the [OSCAL `token` data type](https://pages.nist.gov/metaschema/specification/datatypes/#token).
- The value must also exist in the `metadata`/`roles` entries.
#### OSCAL Representation
```yaml
system-security-plan:
system-implementation:
component:
- uuid: 11111111-2222-4000-8000-009000100001
type: system
title: Leveraged Authorized System
description: Briefly describe the leveraged system.
props:
- name: leveraged-authorization-uuid
value: 11111111-2222-4000-8000-019000000001
- name: nature-of-agreement
ns: http://fedramp.gov/ns/oscal
value: sla
- name: authentication-method
ns: http://fedramp.gov/ns/oscal
value: 'yes'
- name: information-type
ns: http://fedramp.gov/ns/oscal
value: C.3.5.1
class: incoming
- name: information-type
ns: http://fedramp.gov/ns/oscal
value: C.3.5.8
class: outgoing
status:
state: operational
responsible-roles:
- role-id: provider
party-uuids:
- 11111111-2222-4000-8000-c0040000000a
- role-id: asset-administrator
party-uuids:
- 11111111-2222-4000-8000-c0040000000a
```
### FedRAMP Marketplace Information Matching
Information about _Leveraged FedRAMP Authorized Services_ must match the content in the FedRAMP Marketplace. GSA updates a [JSON file](https://raw.githubusercontent.com/18F/fedramp-data/master/data/data.json) nightly that is used to render the FedRAMP Marketplace data.
| OSCAL Field | GSA Field |
|-------------|-------------------|
| CSP Name | `/data/Providers/[#]/Cloud_Service_Provider_Name` |
| CSO Name | `/data/Providers/[#]/Cloud_Service_Provider_Package` |
| Package ID | `/data/Providers/[#]/Package_ID` |
| Authorization Date | `/data/Providers/[#]/Original_Authorization_Date` |
| Impact Level | `/data/Providers/[#]/Impact_Level` |
**IMPORTANT FOR LEVERAGED SYSTEMS:**
While a leveraged system has no need to represent content here, its SSP SHOULD include special inheritance and responsibility information in the individual controls. See the [*Response: Identifying Inheritable Controls and Customer Responsibilities*](/documentation/ssp/6-security-controls/#response-identifying-inheritable-controls-and-customer-responsibilities) section for more information.
---
# 7. External Systems and Services Not Having FedRAMP Authorization
FedRAMP authorized services should be used, whenever possible, since their risk is defined. However, there are instances where CSOs have external systems or services that are not FedRAMP authorized. In OSCAL, these external systems and services must be identified using `component` assemblies with additional FedRAMP namespace and class properties as shown in the OSCAL representation below.
#### OSCAL Representation
```yaml
system-security-plan:
system-implementation:
component:
uuid: 11111111-2222-4000-8000-009000200001
type: interconnection
title: "[EXAMPLE]External System / Service Name"
description: "Briefly describe the interconnection details."
prop:
- ns: "https://fedramp.gov/ns/oscal"
name: service-processor
value: "[SAMPLE] Telco Name"
- ns: "https://fedramp.gov/ns/oscal"
name: interconnection-type
value: "1"
- name: direction
value: incoming
- name: direction
value: outgoing
- ns: "https://fedramp.gov/ns/oscal"
name: nature-of-agreement
value: contract
- ns: "https://fedramp.gov/ns/oscal"
name: still-supported
value: yes
- ns: "https://fedramp.gov/ns/oscal"
class: fedramp
name: interconnection-data-type
value: "C.3.5.1"
- ns: "https://fedramp.gov/ns/oscal"
class: fedramp
name: interconnection-data-type
value: "C.3.5.8"
- ns: "https://fedramp.gov/ns/oscal"
class: "C.3.5.1"
name: interconnection-data-categorization
value: low
- ns: "https://fedramp.gov/ns/oscal"
class: "C.3.5.8"
name: interconnection-data-categorization
value: moderate
- ns: "https://fedramp.gov/ns/oscal"
name: authorized-users
value: "SecOps engineers"
- ns: "https://fedramp.gov/ns/oscal"
class: fedramp
name: interconnection-compliance
value: "PCI SOC 2"
- ns: "https://fedramp.gov/ns/oscal"
class: fedramp
name: interconnection-compliance
value: "ISO/IEC 27001"
- ns: "https://fedramp.gov/ns/oscal"
name: interconnection-hosting-environment
value: PaaS
- ns: "https://fedramp.gov/ns/oscal"
name: interconnection-risk
value: None
- name: isa-title
value: "system interconnection agreement"
- name: isa-date
value: "2023-01-01T00:00:00Z"
- name: ipv4-address
class: local
value: "10.1.1.1"
- name: ipv4-address
class: remote
value: "10.2.2.2"
- name: ipv6-address
value: "::ffff:10.2.2.2"
- ns: "https://fedramp.gov/ns/oscal"
name: information
value: "Describe the information being transmitted."
- ns: "https://fedramp.gov/ns/oscal"
name: port
class: remote
value: "80"
- ns: "https://fedramp.gov/ns/oscal"
name: interconnection-security
value: ipsec
link:
- href: "#uuid-of-ICA-resource-in-back-matter"
rel: isa-agreement
back-matter:
resource:
uuid: "11111111-2222-4000-8000-001000000050"
title: "[SAMPLE]Interconnection Security Agreement Title"
props:
- name: published
value: '2023-01-01T00:00:00Z'
- name: version
value: Document Version
- name: type
value: agreement
class: interconnection-security-agreement
rlinks:
- href: ./attachments/ISAs/ISA-1.docx
```
### External System and Services
To map the legacy FedRAMP SSP table for **External Systems and Services** into a machine-readable OSCAL format, the data is primarily stored within the `system-implementation` section, specifically under `component` definitions where the `type` is set to `interconnection`.
The following data points are captured using various OSCAL fields and FedRAMP-specific properties (`prop`):
* **Identity & Nature:** The system, service, or API name is defined by the component `title`, while the specific `interconnection-type` (e.g., dedicated line, VPN) and the `nature-of-agreement` (e.g., MOU, ISA) are captured as properties.
* **Operational Details:** Connection characteristics are recorded via properties for `direction` (inbound/outbound), whether the service is `still-supported` (Y/N), and a general `description` of the interface.
* **Data Characteristics:** The `data-type` and its associated `data-categorization` (Security Impact Level) are explicitly defined to track what information is leaving or entering the boundary.
* **User Access:** Information regarding `authorized-users` and their specific `privilege-level` is linked back to the `user` definitions within the system implementation.
* **Compliance & Risk:** Any `other-compliance-programs` (like SOC2 or ISO), the specific `hosting-environment`, and a summary of the `risk-impact-mitigation` strategies are all stored as specific metadata properties attached to the interconnection component.
When documenting multiple external services, each service is treated as a separate instance of an interconnection component within the OSCAL file.
---
# 8. Illustratred Architecture and Narratives
The Architecture, Network and Data Flow Diagramss are each represented using the same OSCAL patterns, with only the top level assemby name changing.
### Authorization Boundary
The OSCAL approach to this type of diagram is to treat the image data as either a linked or base64-encoded `resource` in the `back-matter` section of the OSCAL file, then reference the diagram using the `link` field. The narrative describing the system architecture must be provided in the `description` field of the `authorization-boundary` assembly.
#### OSCAL Representation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-characteristics:
authorization-boundary:
description: A holistic, top-level explanation of the FedRAMP authorization boundary.
diagrams:
- uuid: 11111111-2222-4000-8000-007000000001
description: A diagram-specific explanation.
links:
- href: '#11111111-2222-4000-8000-001000000054'
rel: diagram
caption: Authorization Boundary Diagram
back-matter:
resources:
- uuid: 11111111-2222-4000-8000-001000000054
title: Boundary Diagram
description: The primary authorization boundary diagram.
props:
- name: type
value: image
class: authorization-boundary
rlinks:
- href: ./attachments/diagrams/boundary.png
```
To represent the **Authorization Boundary** from the legacy SSP in an OSCAL-based System Security Plan, the data is centered within the `system-characteristics` section under the `authorization-boundary` element.
The following elements and structures are used to capture the boundary definition:
* **Boundary Narrative:** An `overall-description` is used to provide a high-level technical and functional summary of the system's limits.
* **Visual Documentation:** The model tracks the total number of boundary diagrams present to ensure compliance with the minimum requirement of at least one visual representation.
* **Diagram Linking:** Each diagram is referenced via a `link` containing a unique identifier or path. This link either points to an external URI or a local reference within the OSCAL document.
* **Resource Storage:** The actual image data or file location for a diagram is stored in the `back-matter` section. This is handled as a `resource` which can either contain the raw `base64` encoded image data or a remote link (`rlink`) to the hosted file.
* **Contextual Details:** Individual diagrams can also include their own specific `description` to clarify the components, data flows, or sub-networks depicted in that particular view.
When multiple diagrams are required to show different perspectives of the boundary, each is listed as a sequential entry within the authorization boundary array.
---
### Network Architecture
The network architecture diagram follows the same patter as the [*Authorization Boundary*](#authorization-boundary) diagram, except the content is placed under `network-architecture` instead of `authorization-boundary`.
#### OSCAL Representation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-characteristics:
network-architecture:
description: A holistic, top-level explanation of the network architecture.
diagrams:
- uuid: 11111111-2222-4000-8000-007000000002
description: A diagram-specific explanation.
links:
- href: '#11111111-2222-4000-8000-001000000055'
rel: diagram
caption: Network Diagram
back-matter:
resources:
- uuid: 11111111-2222-4000-8000-001000000055
title: Network Diagram
description: The primary network diagram.
props:
- name: type
value: image
class: network-architecture
rlinks:
- href: ./attachments/diagrams/network.png
```
---
### Data Flow
The data flow diagram follows the same pattern as the [*Authorization Boundary*](#authorization-boundary) diagram, except the content is placed under `data-flow` instead of `authorization-boundary`.
#### OSCAL Representation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-characteristics:
data-flow:
description: A holistic, top-level explanation of the system's data flows.
diagrams:
- uuid: 11111111-2222-4000-8000-007000000003
description: A diagram-specific explanation.
links:
- href: '#11111111-2222-4000-8000-001000000056'
rel: diagram
caption: Data Flow Diagram
back-matter:
resources:
- uuid: 11111111-2222-4000-8000-001000000056
title: Data Flow Diagram
description: The primary data flow diagram.
props:
- name: type
value: image
class: data-flow
rlinks:
- href: ./attachments/diagrams/dataflow.png
```
# 9. Services, Ports and Protocols
Entries in the services, ports, and protocols table are represented as component assemblies, with the component-type flag set to "service". Use a protocol assembly for each protocol associated with the service. For a single port, set the port-range start flag and end flag to the same value.
#### OSCAL Representation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000500004
type: service
title: API Service
description: 'A service offered by this system to external systems, such as
an API. As a result, communication crosses the boundary.
Describe the service and what it is used for.'
props:
- name: implementation-point
value: internal
- name: public
value: 'yes'
- name: information-type
ns: http://fedramp.gov/ns/oscal
value: C.3.5.1
class: incoming
- name: information-type
ns: http://fedramp.gov/ns/oscal
value: C.3.5.8
class: outgoing
- name: connection-security
ns: http://fedramp.gov/ns/oscal
value: tls-1.3
- name: authentication-method
ns: http://fedramp.gov/ns/oscal
value: 'yes'
- name: nature-of-agreement
ns: http://fedramp.gov/ns/oscal
value: other
- name: allows-authenticated-scan
value: 'no'
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: infrastructure
links:
- href: '#11111111-2222-4000-8000-009000100003'
rel: used-by
- href: '#11111111-2222-4000-8000-009000100004'
rel: used-by
- href: '#11111111-2222-4000-8000-001000000048'
rel: poam-item
resource-fragment: 11111111-3333-4000-8000-000000000004
- href: https://api.example.com/v1
rel: api
status:
state: operational
responsible-roles:
- role-id: administrator
props:
- name: privilege-uuid
ns: http://fedramp.gov/ns/oscal
value: 11111111-2222-4000-8000-008000000004
party-uuids:
- 11111111-2222-4000-8000-004000000010
- 11111111-2222-4000-8000-004000000011
- 11111111-2222-4000-8000-004000000012
- role-id: provider
party-uuids:
- 11111111-2222-4000-8000-004000000001
protocols:
- uuid: 11111111-2222-4000-8000-010000000002
name: tls
title: API Service
port-ranges:
- start: '443'
end: '443'
transport: TCP
```
To represent **Network Services and Ports** within an OSCAL System Security Plan, the data is organized under the `system-implementation` section, specifically categorized by components where the `type` is defined as `service`, `hardware` or `software`.
The mapping for each service entry includes the following technical details:
* **Service Identity:** Each entry starts with a `title` that identifies the specific service or application name (e.g., "HTTPS" or "SSH").
* **Protocol Configuration:** The specific network `protocol` name (such as TCP or UDP) is identified to define how the service communicates.
* **Port Management:** Detailed port information is captured within a `port-range`, specifying the exact `start` and `end` values. This also includes the `transport` layer designation to ensure the specific communication path is fully defined.
* **Functional Justification:** A dedicated `purpose` field provides the business or technical rationale for why the service is required within the system boundary.
* **Component Relationships:** The model tracks which internal system elements are utilizing the service by linking to the `title` of other defined components via their unique identifiers (UUIDs).
For systems with multiple services, each is documented as an individual service component, with the ability to define multiple protocols and port ranges within each entry to maintain a complete and granular inventory.
---
# 10. Cryptographic Modules Implemented for DAR and DIT
This is address in [Appendix Q: Cryptographic Modules](/books/3-fedramp-system-security-plan-ssp/page/appendix-q-cryptographic-modules).
# 11. Seperation of Duties Matrix
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` (required)
- a `props` array with the following entry:
- a `name` with `separation-of-duties-matrix`
- a `ns` with `http://fedramp.gov/ns/oscal`
- a `value` with `yes`
- a `role-ids` array with each entry:
- the role ID token defined in `metadata` / `roles`
- Only for roles where an "X" would appear in the table
- an `authorized-privileges` array with one or more entries:
- a `title` with the text from the "Duty Description" column
- a `functions-performed` array with at least one string entry describing the function. (This is an OSCAL required field that is not required by FedRAMP.)
```yaml
system-security-plan:
metadata:
roles:
- id: asset-administrator
title: Asset Administrator
- id: admin-client
title: Customer-Designated Administrator
- id: admin-unix
title: Unix Administrator
system-implementation:
users:
- uuid: 11111111-2222-4000-8000-008000000002
props:
- name: separation-of-duties-matrix
ns: http://fedramp.gov/ns/oscal
value: 'yes'
role-ids:
- asset-administrator
authorized-privileges:
- title: Add/Remove Admins
functions-performed:
- This can add and remove admins.
- uuid: 11111111-2222-4000-8000-008000000003
props:
- name: separation-of-duties-matrix
ns: http://fedramp.gov/ns/oscal
value: 'yes'
role-ids:
- asset-administrator
- admin-client
authorized-privileges:
- title: Add/Remove Users
functions-performed:
- add/remove non-privliged users
- uuid: 11111111-2222-4000-8000-008000000004
props:
- name: separation-of-duties-matrix
ns: http://fedramp.gov/ns/oscal
value: 'yes'
role-ids:
- asset-administrator
authorized-privileges:
- title: Cloud-Native Service Deployment
functions-performed:
- Manage services and components within the virtual cloud environment.
- uuid: 11111111-2222-4000-8000-008000000005
props:
- name: separation-of-duties-matrix
ns: http://fedramp.gov/ns/oscal
value: 'yes'
role-ids:
- admin-client
authorized-privileges:
- title: Application User Admin
functions-performed:
- Add and remove users from the virtual cloud environment.
```
**The `props` entry is required in each `users` entry.** It identifies which `users` array entries are intended to represent the Separation of Duties Matrix. Tools processing OSCAL SSPs only for FedRAMP should ignore any `users` entry that does not include this `props` entry.
# Appendices A - Q
# Appendicies Overview
Most attachments required by FedRAMP are called out in the NIST SP 800-53 controls appearning in FedRAMP baselines.
Where a legacy FedRAMP attachment is handled as machine-readable content, you have the option of attaching the legacy attachment or representing the content as machine-readable content.
See the [Document Attachments](/books/2-fedramp-common/page/attachments) section for general attachment patterns as OSCAL `resources`.
The following table describes how each attachment is handled:
|**Appendix Name** | **Machine Readable** | **How to Handle in OSCAL** |
| :-- | :---: | :-- |
| **Appendix A: FedRAMP Security Controls** | **Yes** | See the [FedRAMP Security Controls](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/chapter/fedramp-security-controls) section. |
| **Appendix B: Related Acronyms** | No | Attach using the `back-matter`, `resource` syntax.
For Acronyms, resource must include a `prop` with `@ns="http://fedramp.gov/ns/oscal"`, `@name="type"`, and `@value="fedramp-acronyms"`. |
| **Appendix C: Security Policies and Procedures** | No | From each `-1` control (i.e. AC-1, IA-1) use `links` to identify the related policy and procedure attachments. |
| **Appendix D: User Guide** | No | From SA-5 (`id`=`sa-5`) use `links` to identify this attachment. |
| **Appendix E: Digital Identity Worksheet** | **Yes** | See the [Digital Identity Determination](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/appendix-e-digital-identity-level-dil-determination) section. |
| **Appendix F: Rules of Behavior** | No | From PL-4 (`id`=`pl-4`) use `links` to identify this attachment. |
| **Appendix G: Information System Contingency Plan (ISCP)** | No | From CP-2 (`id`=`cp-2`) use `links` to identify this attachment. |
| **Appendix H: Configuration Management Plan (CMP)** | No | From CM-9 (`id`=`cm-9`) use `links` to identify this attachment. |
| **Appendix I: Incident Response Plan (IRP)** | No | From IR-8 (`id`=`ir-8`) use `links` to identify this attachment. |
| **Appendix J: CIS and CRM Workbook** | Yes | This is generated from the content in the Security Controls section and does not need to be maintained separately nor attached. |
| **Appendix K: FIPS 199 Worksheet** | **Yes** | See the [Appendix K: FIPS-199 Worksheet](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/appendix-k-fips-199-worksheet) section. |
| **Appendix L: CSO-Specific Required Laws and Regulations** | No | Attach using the `back-matter`, `resource` syntax.
For CSO-Specific Required Laws and Regulations, resource must include a `prop` with `@name=”type”` and `@value=”law”`. |
| **Appendix M: Integrated Inventory Workbook** | **Yes** | See the [Inventory Approaches](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/inventory-approaches) section. |
| **Appendix N: Continuous Monitoring Plan** | No | From CA-7 (`id`=`ca-7`) use `links` to identify this attachment. |
| **Appendix O: POA&M** | **Yes** | From CA-5 (`id`=`ca-5`) use `links` to identify this attachment. |
| **Appendix P: Supply Chain Risk Management Plan (SCRMP)** | No | From SR-2 (`id`=`sr-2`) use `links` to identify this attachment. |
| **Appendix Q: Cryptographic Module Table** | **Yes** | See the [Appendix Q: Cryptographic Modules](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/appendix-q-cryptographic-modules) section. |
---
# Appendix A: FedRAMP Security Controls
See the [FedRAMP Security Controls](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/chapter/fedramp-security-controls) chapter.
# Appendix B: Related Acronyms
There is no OSCAL construct for representing an acronyms list.
Attach a document (e.g., Word, Excel, PDF) with acronyms using a `back-matter`, `resources` entry.
See [Attachments](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) for details.
# Appendix C: Security Policies and Procedures
See [Control Response: Policies and Procedures](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/control-response-policies-procedures-plans-rob-and-guides).
# Appendix D: User Guide
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
---
MVP Key Points Include:
- The SA-5 (`id`=`sa-5` control should have `links` entries to the user guide
This is not normalized and is only for legacy conversion MVP
---
Normalized Key points include:
- attach the user guide as a back-matter/`resources` entry
- create a component for the user guide
- From the componet, add a `links` entry that references the `resource` (#uuid-value)
- The SA-5 control has `by-components` entrys that cite the user guide component
Reference Components [need citation - there may be a page for document-type compnents ] and [Attachments](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) pages. Don't duplicate those explanations here.
# Appendix E: Digital Identity Level (DIL) Determination
The Digital Identity Level (DIL) is represented on the page below.
Within `system-characteristics` there must be three entries to the `props` array as follows:
- `name` set to `identity-assurance-level` and a `value` set to `1`, `2` or `3`.
- `name` set to `authenticator-assurance-level` and a `value` set to `1`, `2` or `3`.
- `name` set to `federation-assurance-level` and a `value` set to `1`, `2` or `3`.
- The value of all three should match each other and align with the FIPS-199 impact level of the system.
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
props:
- name: identity-assurance-level
value: '2'
- name: authenticator-assurance-level
value: '2'
- name: federation-assurance-level
value: '2'
```
**OSCAL Allowed Values**
Valid IAL, AAL, and FAL values (as defined by NIST SP 800-63):
- 1
- 2
- 3
# Appendix F: Rules of Behavior (RoB)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
---
MVP Key Points Include:
- The PL-4 (`id`=`pl-4` control should have `links` entries to the RoB
This is not normalized and is only for legacy conversion MVP
---
Normalized Key points include:
- attach the RoB as a back-matter/`resources` entry
- create a component for the RoB
- From the componet, add a `links` entry that references the `resource` (#uuid-value)
- The PL-4 control has `by-components` entrys that cite the RoB component
Reference Components [need citation - there may be a page for document-type compnents ] and [Attachments](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) pages. Don't duplicate those explanations here.
# Appendix G: Information System Contingency Plan (ISCP)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
---
MVP Key Points Include:
- The CP-2 (`id`=`cp-2` control should have `links` entries to the RoB
This is not normalized and is only for legacy conversion MVP
---
Normalized Key points include:
- attach the ISCP as a back-matter/`resources` entry
- create a component for the ISCP
- From the componet, add a `links` entry that references the `resource` (#uuid-value)
- The CP-2 control has `by-components` entrys that cite the ISCP component
Reference Components [need citation - there may be a page for document-type compnents ] and [Attachments](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) pages. Don't duplicate those explanations here.
# Appendix H: Configuration Management Plan (CMP)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
---
MVP Key Points Include:
- The CM-9 (`id`=`cm-9` control should have `links` entries to the RoB
This is not normalized and is only for legacy conversion MVP
---
Normalized Key points include:
- attach the CMP as a back-matter/`resources` entry
- create a component for the CMP
- From the componet, add a `links` entry that references the `resource` (#uuid-value)
- The CM-9 control has `by-components` entrys that cite the CMP component
Reference Components [need citation - there may be a page for document-type compnents ] and [Attachments](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) pages. Don't duplicate those explanations here.
# Appendix I: Incident Response Plan (IRP)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
---
MVP Key Points Include:
- The IR-8 (`id`=`ir-8` control should have `links` entries to the RoB
This is not normalized and is only for legacy conversion MVP
---
Normalized Key points include:
- attach the IRP as a back-matter/`resources` entry
- create a component for the IRP
- From the componet, add a `links` entry that references the `resource` (#uuid-value)
- The IR-8 control has `by-components` entrys that cite the IRP component
Reference Components [need citation - there may be a page for document-type compnents ] and [Attachments](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) pages. Don't duplicate those explanations here.
# Appendix J: CIS and CRM Workbook
The FedRAMP Control Information Summary (CIS) and Customer Responsibility Matrix (CRM) are derived directly from the OSCAL control responses.
There is no need to maintain a separate CIS/CRM artifact; however, this information must be properly represented in the control responses. Tools can then summarize control information into the CIS and produce a list of customer responsibilities consistent with the CRM.
# Needs Work
- It needs an App J page image
- It needs to reference and link to the customer respopnsibility topic in controls
# Appendix K: FIPS-199 Worksheet
The system's overall FIPS-199 impact level is determined primarily by the sensitivity of the information it processes.
The overall FIPS-199 impact level is represented under `system-characteristics`:
- `security-sensitivity-level`
- The value must be one of `fips-199-low`, `fips-199-moderate` or `fips-199-high`
The FIPS-199 Categorization worksheet is an inventory of information types in the system, based on [NIST SP 800-60 Volume 2](https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-60v2r1.pdf).
- Create one entry under `information-types` for each information type.
- For each information type:
- Assign a `uuid`
- Assign the NIST SP 800-63 information type name to the `title`
- `description` is a required OSCAL field that is not acknowledged by FedRAMP. Consider offering context or citing 800-60.
- The `categorizations` array should have one entry that includes:
- `system` set to "http://doi.org/10.6028/NIST.SP.800-60v2r1"
- the `information-type-ids` arraqy should have one entry
- Use the NIST SP 800-60 invormation type ID
- Exactly match the case as it appears in 800-60. (e.g., `C.2.3.1` or `D.15.5`)
- The `confidentiality-impact` must have:
- a `base` field with the value defined in 800-60.
- a `selected` field with the value selected by the CSP.
- If the value in `selected` does not match the value in `base`, use `adjustment-justification` to capture the "Statement for Impact Adjustment Justification"
- `base` and `selected` values must be one of `fips-199-low`, `fips-199-moderate` or `fips-199-high`
- `integrity-impact and `availability-impact` are treated the same as `confidentiality-impact` above.
Other information types or categorizations may be present if the SSP also represents compliance with other frameworks; however, the US Government must operate under NIST RMF and will only recognize the NIST SP 800-60 types.
#### OSCAL Representation
```yaml
system-security-plan:
system-characteristics:
security-sensitivity-level: fips-199-high
system-information:
information-types:
- uuid: 11111111-2222-4000-8000-006000000001
title: Information Type Name
description: A description of the information.
categorizations:
- system: http://doi.org/10.6028/NIST.SP.800-60v2r1
information-type-ids:
- C.2.4.1
confidentiality-impact:
base: fips-199-moderate
selected: fips-199-moderate
adjustment-justification: Required if the base and selected values do not
match.
integrity-impact:
base: fips-199-moderate
selected: fips-199-low
adjustment-justification: Required if the base and selected values do not
match.
availability-impact:
base: fips-199-moderate
selected: fips-199-moderate
adjustment-justification: Required if the base and selected values do not
match.
```
**OSCAL Allowed Values**
Reqired value for `system`:
- `http://doi.org/10.6028/NIST.SP.800-60v2r1`
Valid values for `security-sensitivity-level`, `base` and `selected` fields:
- `fips-199-low`
- `fips-199-moderate`
- `fips-199-high`
# Appendix L: CSO-Specific Required Laws and Regulations
# Needs Work
- Content cleanup
- YAML Example
For MVP:
- attach a Word or PDF document enumerating the applicable laws and regulations.
For Normalized:
- Provide one back-matter/`resources` entry per applicable law or regulation that includes:
- a `title` with the title of the law or regulation
- a `props` entry with:
- `name`=`type`
- `value` = `law`
- `rlinks` entry that links to the law or regulation
# Appendix M: Integrated Inventory Workbook
See [Inventory Approaches](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/inventory-approaches) for guidance.
# Appendix N: Continuous Monitoring Plan
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
---
MVP Key Points Include:
- The CA-7 (`id`=`ca-7` control should have `links` entries to the RoB
This is not normalized and is only for legacy conversion MVP
---
Normalized Key points include:
- attach the Continuous Monitoring Plan as a back-matter/`resources` entry
- create a component for the Continuous Monitoring Plan
- From the componet, add a `links` entry that references the `resource` (#uuid-value)
- The CA-7 control has `by-components` entrys that cite the Continuous Monitoring Plan component
Reference Components [need citation - there may be a page for document-type compnents ] and [Attachments](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) pages. Don't duplicate those explanations here.
# Appendix O: POA&M
See the [FedRAMP POA&M](https://patterns.rufrisk.com/books/fedramp-poam) book.
# Appendix P: Supply Chain Risk Management Plan (SCRMP)
This needs work that may have been completed elsewhere and nees to be moved into here.
This needs MVP and Normalized content examples
---
MVP Key Points Include:
- The SR-2 (`id`=`sr-2` control should have `links` entries to the user guide
This is not normalized and is only for legacy conversion MVP
---
Normalized Key points include:
- attach the SCRMP as a back-matter/`resources` entry
- create a component for the SCRMP
- From the componet, add a `links` entry that references the `resource` (#uuid-value)
- The SR-2 control has `by-components` entrys that cite the SCRMP component
Reference Components [need citation - there may be a page for document-type compnents ] and [Attachments](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) pages. Don't duplicate those explanations here.
# Appendix Q: Cryptographic Modules
## Cryptographic Modules Implemented for Data-in-Transit (DIT)
OSCAL's component model treats independent validation of products and services as if that validation were a separate component. This means when using components with FIPS 140 validated cryptographic modules, there must be two component assemblies:
- **The Validation Definition**: A component that provides details about the validation.
- **The Product Definition**: A component that describes the hardware or software product.
The validation definition is a component that provides details about the independent validation. Its type must have a value of "validation". In the case of FIPS 140 validation, this must include a link field with a rel value set to "validation-details". This link must point to the cryptographic module's entry in the NIST Computer Security
Resource Center (CSRC) [Cryptographic Module Validation Program Database](https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search).
The product definition is a product with a cryptographic module. It must contain all of the typical component information suitable for reference by inventory-items and control statements. It must also include a link field with a rel value set to "validation" and an href value containing
a URI fragment. The fragment must start with a hashtag (#) and include the UUID value of the validation component. This links the two together.
##### Component Representation: Data-In-Transit Example Product with FIPS 140-2 Validation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000300003
type: software
title: OpenSSL
description: 'Provide a description and any pertinent note regarding the use
of this CM.'
props:
- name: asset-type
value: cryptographic-module
- name: version
value: 3.0.8
- name: vendor-name
ns: http://fedramp.gov/ns/oscal
value: OpenSSL FIPS Provider
- name: function
ns: http://fedramp.gov/ns/oscal
value: data-in-transit
remarks: Usage statement
links:
- href: '#11111111-2222-4000-8000-009001200002'
rel: validation
text: A link to the 3rd party validation information related to this cryptographic
module.
status:
state: operational
- uuid: 11111111-2222-4000-8000-009001200002
type: validation
title: OpenSSL FIPS 140-2 Validation
description: Describe any relevant information regarding this validation of
the CM.
props:
- name: asset-type
value: cryptographic-module
- name: validation-type
value: fips-140-2
- name: validation-reference
value: '4811'
status:
state: operational
```
##### Understanding the Data-in-Transit (DIT) Mapping
When documenting cryptographic protections for data-in-transit, the OSCAL model focuses on the relationship between the specific software provider and its validated state.
* **Software Component & Function:** The first block defines the actual implementation (e.g., **OpenSSL**). The property `name: function` with the value `data-in-transit` explicitly categorizes the module’s role. This allows auditors and automated tools to identify which software is responsible for protecting communication channels, such as TLS or SSH connections, across the system boundary.
* **Decoupled Validation Metadata:** Rather than burying version-specific details in a text field, OSCAL uses a `link` to connect the software component to a separate `validation` component. This second component (highlighted by the `validation-reference` value **4811**) points directly to the NIST CMVP certificate.
* **Operational Status:** The `state: operational` field confirms that the module is currently in use within the environment. If a module were undergoing an update or was in a "historical" state, this status could be updated to reflect the current risk posture without needing to rewrite the entire narrative.
By structuring the SSP this way, you ensure that every cryptographic module used for DIT is traceable to a specific FIPS 140-2 or 140-3 certificate, satisfying the requirements for **SC-13 (Cryptographic Protection)** in a machine-verifiable format.
---
## Cryptographic Modules Implemented for Data-at-Rest (DAR)
The approach is the same as in the [*cryptographic module data-in-transit*](#cryptographic-modules-implemented-for-data-in-transit-dit) section.
[](h/uploads/images/gallery/2026-02/ssp-figure-22.png)
##### Component Representation: Data-At=Rest Example Product with FIPS 140-2 Validation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000300012
type: software
title: Database Row Encryption Module
description: Briefly describe the cryptographic module.
props:
- name: asset-type
value: cryptographic-module
- name: version
value: 1.2.3
- name: vendor-name
ns: http://fedramp.gov/ns/oscal
value: Databases-R-Us
- name: function
ns: http://fedramp.gov/ns/oscal
value: data-at-rest
remarks: Used to encrypt and decrypt rows in the database.
status:
state: operational
- uuid: 11111111-2222-4000-8000-009001200001
type: validation
title: Database Row Encryption Module (DREM)
description: Briefly describe the cryptographic module.
props:
- name: asset-type
value: cryptographic-module
- name: validation-type
value: fips-140-2
- name: validation-reference
value: '0000'
status:
state: operational
```
##### Understanding the Data-at-Rest (DAR) Mapping
In the OSCAL representation of data-at-rest protections, the focus shifts from communication protocols to the specific encryption mechanisms securing stored information.
* **Defining the Storage Function:** The property `name: function` with the value `data-at-rest` explicitly categorizes the module’s role. The accompanying `remarks` field—such as "Used to encrypt and decrypt rows in the database"—provides the necessary context for human reviewers to understand the scope of the encryption (e.g., full-disk vs. application-layer encryption).
* **Asset Categorization:** By using the `asset-type: cryptographic-module` property, the component is tagged for automated compliance auditing. This allows the system to verify that every component handling sensitive federal data is linked to a valid cryptographic implementation, directly supporting **SC-28 (Protection of Information at Rest)**.
* **Validation Linkage:** Similar to the data-in-transit model, the software component is linked to a `validation` component that holds the NIST CMVP metadata. The `validation-reference` (e.g., **0000**) acts as the source of truth for the FIPS 140-2 or 140-3 certificate number, ensuring that the module meets the mandatory federal security standards for data storage.
By organizing DAR in this manner, the SSP provides a granular inventory of encryption at every layer of the technology stack—from the database row level up to the storage volume—while maintaining a clear audit trail to the validated cryptographic provider.
---
NOTE:
While the examples show FIPS 140-2, the same OSCAL structure applies to FIPS 140-3. Simply update the `validation-type` property to reflect the current standard.
# System Components and Inventory
# Inventory Approaches
OSCAL makes two approaches available for depicting the system inventory:
- **Flat Approach**: Aligns with today's FedRAMP Integrated inventory workbook where all of the information on a spreadsheet row is captured in a single assembly.
- **Normalized Approach**: Common information is normalized as OSCAL components. inventory-items point to components for common information.
With the **flat approach**, all content on a spreadsheet row appears in a single OSCAL inventory-item assembly. This results in a great deal of redundant information but is a simple transition from the current spreadsheet approach.
See [Inventory: Flat Approach](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/inventory-flat-approach) for more information.
### Retrofit Adoption Path: MVP
If you have an existing FedRAMP authorization and are using the FedRAMP inventory spreadsheet template, start with the flat approach, and migrate over time to the normalized approach.
With the **Normalized approach**, common information is captured once in a component assembly. Each instance of that component has its own inventory-item assembly, which cites the relevant component and only includes information unique to that instance.
See [Inventory: Normalized Approach](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/inventory-normalized-approach) for more information.
### New Adoption Path: Core
If you are adopting OSCAL at the beginning of your FedRAMP journey, define components first, then regerence those components as you generate inventory.
#### Example
The same Linux operating system is used as the platform for all database and web servers. Most details about operating system are captured once as a component, including OS name, version number, and patch level.
If four Linux instances are used, each instance is an inventory item with a unique IP address and MAC address. Only those unique pieces are captured at the inventory level. All four inventory-items are linked to the component.
# Inventory: Flat Approach
The flat approach to inventory is only intended as a starting point for service providers converting from a legacy FedRAMP inventory spreadsheet template.
If you are not converting legacy inventory, use the [Inventory: Normalized Approach](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/inventory-normalized-approach).
---
With the **flat approach**, all content on a spreadsheet row appears in a single OSCAL inventory-item assembly. This results in a great deal of redundant information but is a simple transition from the current spreadsheet approach.
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-figure-25.png)
##### Flat Representation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
inventory-items:
- uuid: 11111111-2222-4000-8000-011000000001
description: Legacy Example (No implemented-component).
props:
- name: asset-id
value: unique-asset-ID-01
- name: ipv4-address
value: 10.1.1.1
- name: ipv6-address
value: 2001:db8:3333:4444:5555:6666:7777:8888
- name: virtual
value: 'no'
- name: public
value: 'no'
- name: fqdn
value: dns.name
- name: uri
value: uniform.resource.identifier
- name: netbios-name
value: netbios-name
- name: mac-address
value: 00:00:00:00:00:00
- name: asset-type
value: operating-system
- name: serial-number
value: 'Serial #'
- name: asset-tag
value: Asset Tag
- name: vlan-id
value: VLAN Identifier
- name: network-id
value: Network Identifier
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: infrastructure
- name: vendor-name
ns: http://fedramp.gov/ns/oscal
value: Big Vendor, Inc.
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: database
- name: allows-authenticated-scan
value: 'no'
remarks: If no, explain why. If yes, omit remarks field.
- name: physical-location
value: Physical location of Asset
- name: is-scanned
value: 'yes'
remarks: If no, explain why. If yes, omit remarks field.
- name: function
value: Required brief, text-based description.
remarks: Optional, longer, formatted description.
links:
- href: '#11111111-2222-4000-8000-009000000002'
rel: validation
- href: '#11111111-2222-4000-8000-001000000059'
rel: baseline
responsible-parties:
- role-id: asset-owner
party-uuids:
- 11111111-2222-4000-8000-004000000016
- role-id: asset-administrator
party-uuids:
- 11111111-2222-4000-8000-004000000017
remarks: 'COMMENTS: Additional information about this item.
This links to a FIPS 140-2 validated software component that is used by this
inventory item. This type of linkage to a validation through the component
is preferable to the link[rel=''validation''] example above.'
```
**Notes:**
The value of asset-type determines whether the identified
asset-administrator is managing a system or an application. Currently, any FedRAMP-defined asset-type implies the management of a system, and therefore, is to be scanned as infrastructure.
# Inventory: Normalized Approach
The normalized approach is prefered. Organizations starting new with no legacy inventory reporting should use this.
For organizations converting from a legacy FedRAMP inventory spreadsheet template, consider starting with the [Inventory: Flat Approach](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/inventory-flat-approach) and migrating to the normalized approach over time.
---
With the **Normalized approach**, common information is captured once in a component assembly. Each instance of that component has its own inventory-item assembly, which cites the relevant component and only includes information unique to that instance.
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-figure-26.png)
##### Component-based Representation
```yaml
system-security-plan:
uuid: 11111111-2222-4000-8000-000000000000
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000300300
type: software
title: Linux Operating System
description: This is a web server that communicates with a database via an encrypted connection
props:
- name: asset-type
value: operating-system
- name: allows-authenticated-scan
value: 'yes'
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: web
links:
- href: '#11111111-2222-4000-8000-001000000059'
rel: baseline
status:
state: operational
inventory-items:
- uuid: 11111111-2222-4000-8000-011000000023
description: Instance of the Linux Operating System
props:
- name: asset-id
value: unique-asset-ID-23
- name: asset-type
value: operating-system
- name: ipv4-address
value: 10.23.23.23
- name: ipv6-address
value: 0000:0000:0000:0000:0000:ffff:0a17:1717
- name: virtual
value: 'yes'
- name: public
value: 'no'
- name: fqdn
value: linux-host.example.internal
- name: physical-location
value: Primary Data Center
- name: is-scanned
value: 'yes'
- name: scan-type
ns: http://fedramp.gov/ns/oscal
value: infrastructure
responsible-parties:
- role-id: asset-owner
party-uuids:
- 11111111-2222-4000-8000-004000000010
- role-id: asset-administrator
party-uuids:
- 11111111-2222-4000-8000-004000000017
implemented-components:
- component-uuid: 11111111-2222-4000-8000-009000300300
```
**Notes:**
- If component-sample is an image of a Linux virtual machine (VM), and 10 instances of that VM are in use, there would be one (1) component assembly and ten (10) inventory-item assemblies, all referencing the same component.
---
#### Inventory Data Locations and XPath Queries
The following queries are intended to show where to find each piece of information within the system inventory template.
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-figure-26-1.png)
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-figure-26-2.png)
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-figure-26-3.png)
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-figure-26-4.png)
#
# FedRAMP Security Controls
# Control Response: Approaches
OSCAL offers a great deal of flexibility for controls responses. To balance consistency, interoperability and ease of adoption, the OSCAL Foundation recommends two approaches:
- **Flat Approach**: Aligns with FedRAMP's SSP Word template where control responses are at the statement level, and the narriative alone distinguishes between compoents within the response.
- **Normalized Approach**: Control responses are decomposed to align with relevant components.
With the **flat approach**, the entire statement-level response from a FedRAMP Word-based SSP is represented "as-is" in a single `by-component` assembly in OSCAL.
See [Control Response: Flat Approach](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/control-response-flat-approach) for more information.
#### Retrofit Adoption Path: MVP
If you have an existing FedRAMP authorization with an existing Word-based FedRAMP SSP, start with the flat approach and migrate over time to the normalized approach.
With the **normalized approach**, components are associated with control response statements. Responses are possible either for the whole statement or assocaited with a specific component relative to the statement response.
See [Control Response: Normalized Approach](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/control-response-normalized-approach) for more information.
#### New Adoption Path: Core
If you are adopting OSCAL at the beginning of your FedRAMP journey, respond to control statements at the component level as much as practical. Define OSCAL components ahead of time, and be prepared to add components as needed for control response authoring.
# Control Response: Flat Approach
The flat approach to control responses is only intended as a starting point for service providers converting from a legacy FedRAMP SSP Word template.
If you are not converting a legacy SSP, use the [Control Response: Normalized Approach](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/control-response-normalized-approach).
---
With the flat approach, the entire statement-level response from a FedRAMP Word-based SSP is represented "as-is" in a single `by-component` entry in OSCAL.
## Retrofit Adoption Path: MVP
With OSCAL SSPs, all control responses must be assocaited with a component. To ensure this is always possible, OSCAL SSPs also require the existence of a `this system` component, which represents the entire system.
When converting from a legacy Word-based SSP, the simpelest form of OSCAL adoption is to move the text from each control statement response into the "this system" component response.
### Transition to Normalized
Over time, components can be added to the `components` array in `system-characteristics`. Some components will be added in order to represent SSP tables, such as leveraged authorizations, external services and cryptographic modules. Others may be added to support [inventory normalization](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/inventory-normalized-approach). Add any additional components you need to support or control responses.
At any time, additional `by-components` entries can be added to a `statements` entry, and linked to a component. This may occur one component at a time.
## Example Transition
The legacy Word-Based SSP, response to AC-1, Statement a is:
The Trust an Compliance Team developed, maintains and disseminates the XYZ Corp Access Control Policy, v2.3 dated January 5th 2024 to all management, administrators and users of the PDQ Cloud System.
Chapters 1 and 2 define purpose and scope, while chapter 3 defines roles. Chapters 4 - 8 define responsibilities and coordination, and chapter 9 confirms maangement commitment and potential penalties.
The PDQ Information System Security Officer developed, maintains and disseminates the PDQ Access Control Procedure, v 1.1 dated March 1, 2026, which defines access control operations for the system. The ISSO ensures all PDQ Cloud System managers and administrators receive a copy of this docuemnt
### MVP OSCAL Representation
The entire statement above is represented as follows:
- `metadata/roles` entries for the ISSO and Trust and Compliance Team.
- a `this-system` entry in the `components` array
- an `implemented-requirements` entry for AC-1 (`ac-1`)
- a `statements` entry for AC-1, part a (`ac-1_smt.a`)
- a `by-components` entry with the `component-uuid` value of the `this-system` entry in the `components` array
- a `description` field with the statement from the Word-based SSP.
```yaml
system-security-plan:
metadata:
roles:
- role-id: information-system-security-officer
title: ISSO
- role-id: trust-and-compliance
title: Corporate Trust and Compliance Team
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000000000
type: this-system
title: This System
description: 'This component represents the entire system or authorization boundary.'
control-implementation:
description: 'OSCAL-required field.'
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010101
description: 'The Trust an Compliance Team developed, maintains and disseminates the XYZ Corp Access Control Policy, v2.3 dated January 5th 2024 to all management, administrators and users of the PDQ Cloud System.
Chapters 1 and 2 define purpose and scope, while chapter 3 defines roles. Chapters 4 - 8 define responsibilities and coordination, and chapter 9 confirms maangement commitment and potential penalties.
The PDQ Information System Security Officer developed, maintains and disseminates the PDQ Access Control Procedure, v 1.1 dated March 1, 2026, which defines access control operations for the system. The ISSO ensures all PDQ Cloud System managers and administrators receive a copy of this docuemnt.'
implementation-status:
state: implemented
responsible-roles:
- role-id: information-system-security-officer
- role-id: trust-and-compliance
```
### Transition
In moving to the _normalized_ approach, OSCAL components must eventually be defined for required documents. This will result in additional entries to the `components` array as follows:
- Additional entries to the `components` array
- a `type` set to `policy` or `process-procedure`
- a `title` with the title of the policy or procedure
- a `responsible-roles` array with the appropraite role-id cited.
```yaml
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000000001
type: policy
title: XYZ Access Control Policy
description: 'This is the corporate AC Policy.'
responsible-roles:
- role-id: trust-and-compliance
- uuid: 11111111-2222-4000-8000-009000000003
type: policy
title: PDQ Access Control Procedure
description: 'This is the system-specific AC Procedure.'
responsible-roles:
- role-id: information-system-security-officer
```
Once defined, additional by-component entries may be added to the AC-1, part a atatement; however they do not need to be added all at once. For example, the policy may be addressed in one pass and the procedures deferred.
- add one additional `by-components` entry for the policy
- move only the policy portion of the control response
- drop the `trust-and-compliance` role
- It is not necessary to move the `trust-and-compliance` role as it is defined for the component above.
```yaml
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010101
description: 'The PDQ Information System Security Officer developed, maintains and disseminates the PDQ Access Control Procedure, v 1.1 dated March 1, 2026, which defines access control operations for the system. The ISSO ensures all PDQ Cloud System managers and administrators receive a copy of this docuemnt.'
implementation-status:
state: implemented
responsible-roles:
- role-id: information-system-security-officer
- component-uuid: 11111111-2222-4000-8000-009000000001
uuid: 11111111-2222-4000-8000-012000010102
description: 'The Trust an Compliance Team developed, maintans and disseminates the XYZ Corp Access Control Policy, v2.3 dated January 5th 2024 to all management, administrators and users of the PDQ Cloud System.
Chapters 1 and 2 define purpose and scope, while chapter 3 defines roles. Chapters 4 - 8 define responsibilities and coordination, and chapter 9 confirms maangement commitment and potential penalties.'
implementation-status:
state: implemented
```
When all components have been added, the original `by-components` entry for `this-system` may still be used for providing information (control responses, status differences or additional roles) that do not fit specific component responses.
# Control Response: Normalized Approach
The normalized approach is prefered. Organizations starting new with no legacy SSP content should use this.
For organizations converting from a legacy FedRAMP SSP Word template, consider starting with the [Control Response: Flat Approach](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/control-response-flat-approach) and migrating to the normalized approach over time.
---
With the normalized approach, system elements are first defined as OSCAL `components`. Relvant components are then associated with control statements via `statements`/`by-components` entries. Control responses are then provided in the approrpiate `by-component` entry.
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-04/controls-normalized.png)
```yaml
system-security-plan:
```
---
# Responding to Control Baselines
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](#bkmrk-importing-a-baseline) by an OSCAL SSP and [referenced](#bkmrk-referencing-controls) as needed.
## Importing a Baseline
Import the appropriate FedRAMP Baseline, either as an OSCAL _profile_ or as an OSCAL _reserved profile catalog_.
```yaml
system-security-plan:
import-profile:
href: https://raw.githubusercontent.com/OSCAL-Foundation/fedramp-resources/refs/heads/main/baselines/rev5/yaml/FedRAMP_rev5_HIGH-baseline-resolved-profile_catalog.yaml
```
The OSCAL Foundation makes the FedRAMP baselines available as OSCAL _profiles_ and _resolved profile catalogs_ [on GitHub](https://github.com/OSCAL-Foundation/fedramp-resources/tree/main/baselines/rev5).
See [Baselines](https://patterns.rufrisk.com/books/supporting-resources-and-valid-content/page/baselines) for more information about those files.
## Referencing Controls
With the approprate baseline imported above, OSCAL SSP control responses simply cite the control `id` from the baseline.
For each control in the imported baseline there MUST be exactly one `implemented-requirements` entry that includes:
- a `uuid`
- a `control-id` with a value that matches a control in the imported baseline
- a `set-parameters` array, only if the control has one or more parameters that don't already have their `value` established in the baseline. See _[Parameter Assignments](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/parameter-assignments)_ for more information.
- a `statements` array contains the control responses. See _[Control Implementation Statements](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/control-implementation-statements)_ for more information.
```yaml
system-security-plan:
control-implementation:
description: 'This description field is required by OSCAL, but ignored by FedRAMP.'
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
set-parameters:
[content cut]
statements:
[content cut]
- uuid: 11111111-2222-4000-8000-012000010001
control-id: ac-2
[content cut]
- uuid: 11111111-2222-4000-8000-012000010002
control-id: ac-2.1
[content cut]
```
---
# Responsible Roles
Every control should have one or more responsible roles identified.
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-r5-control.png)
In OSCAL, there are three possible sources for responsible roles:
- **By Control**: (Retrofit MVP only) assign responsible roles to the `implemented-requirement` for the entire control
- **By Component (Implied)**: infer responsible roles from the components cited in the `by-component` array
- **By Component (Explicit)**: assign responsible roles to the `statement`/`by-component` array
### Retrofit Adoption Path: MVP
When initially converting a Word-based FedRAMP SSP to OSCAL, assign all roles _by control_ to the `implemented-requirements`/`responsible-roles` array. This aligns with the FedRAMP Word-based SSP template.
As the SSP is migrated to a normalized approach using components, the assignment of roles is moved from the entire control to statement-level, component responses.
With fully normalized OSCAL content, responsible roles are inferred via the components associated with a control via `statements`/`by-components`. Each assocaited component SHOULD have `owner` and `administrator` responsible roles and linked to specific parties (teams or individuals).
If additional roles need to be cited, they are explicilty assigned to `by-components`/`responsible-roles`. If an explicitly needed role does not associate cleanly to a specific component, it is assigned to the `by-components`/`responsible-roles` entry for _this system_ (component `type`=`this-system`).
# WORKING HERE
##### Representation
```yaml
```
---
# Parameter Assignments
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-figure-32.png)
##### Representation
If a FedRAMP control has one or more parameters, add a `set-parameters` array Within an `implemented-requirements` entry. There must be one `set-parameters` entry for each parameter in the control as follows:
- a `param-id` set to the parameter value from the OSCAL-based FedRAMP baselines
- a `values` array with:
- one string entry per response
- If the response is list, such as a list of user types to receive a procedure, add one entry per list item.
Only set parameters at the `implemented-requirements` level. While OSCAL also supports the ability to set parameters within `by-components` entries, this does not align with FedRAMP's handling of parameters and should not be used.
```yaml
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
set-parameters:
- param-id: ac-01_odp.01
values:
- all managers, administrators and users of the system
- param-id: ac-01_odp.02
values:
- all managers and administrators of the system
- param-id: ac-01_odp.03
values:
- System-level
- param-id: ac-01_odp.04
values:
- System Architect
- param-id: ac-01_odp.05
values:
- at least every 3 years
- param-id: ac-01_odp.06
values:
- change in organizational legal status or ownership
- param-id: ac-01_odp.07
values:
- at least annually
- param-id: ac-01_odp.08
values:
- change in policy or a security incident involving a failure of access control
mechanisms
```
### Selection Parameters and Nested Parameters
Some _select_ parameters contain one or more _assignment_ parameters. In this instance, simply provide the final selection value within the `set-parameters` entry for the _select_ and omit any `set-parameters` entries related to the _assignment_.
#### Example
AC-7_ part _(b)_ has three _assignment_ parameters nested within a single _selection_ parameter. Line breaks and bullets have been added below to better illustrate the nesting.
Automatically
- [**Selection** (one or more):
- lock the account or node for an [**Assignment**: organization-defined time period];
- lock the account or node until released by an administrator;
- delay next logon prompt per [**Assignment**: organization-defined delay algorithm];
- notify system administrator;
- take other [**Assignment**: organization-defined action]]
when the maximum number of unsuccessful attempts is exceeded.
Although the OSCAL controls will have four parameters, only the final value for the _selection_ parameter is assigned in the SSP. The other parameters are ignored.
If more than one choice is is applicable, add each as a separate entry in the `values` array. For example if the final choices are:
- lock the account or node for an [**Assignment**: 30 minutes];
- lock the account or node until released by an administrator;
The `set-parameters` array would be:
```yaml
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-7
set-parameters:
- param-id: ac-07_odp.03
values:
- lock the account or node for 30 minutes;
- lock the account or node until released by an administrator;
```
Parameters `ac-07_odp.01` and `ac-07_odp.02` belong to part (a). They would normally be included and are only omitted for the example.
Parameters `ac-07_odp.04`, `ac-07_odp.05` and `ac-07_odp.06` are part of `ac-07_odp.03` and are omitted.
### The "This System" Component
There must always be a **"This System"** component defined in the SSP. For control responses, this is used in several ways:
- **Holistic Overview**: The SSP author may wish to provide a more
holistic overview of how several components work together, even if
details are provided individually in other `by-component` assemblies.
- **Catch-all**: Any control response that does not cleanly align with
another system component may be described in the **"This System"**
component.
- **Legacy SSP Conversion**: When converting a legacy SSP to OSCAL,
the legacy control response statements may initially be associated
with the **"This System"** component until the SSP author is able
to provide responses for individual components.
responses occur within `by-components` / `description`.
In a legacy Word-based SSP, it was often necessary to provide narriative for each relevant component in a control response. The entire narriative for all components was captured in a single table cell as separate paragraphs.
With OSCAL, you have the option of keeping a single narriative block, or breaking out a control response by its discrete components.
---
### Retrofit Adoption Path MVP
When converting a Word-based FedRAMP SSP to OSCAL, move all control responses to the `this-system` component.
Every OSCAL SSP must have a `this-system` component defined. It is the only required component.
```yaml
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000000000
type: this-system
title: This System
description: 'Represents the entire authorization boundary'
status:
state: operational
```
Every `statements` / `by-components` array has exactly one entry that references the `this-system` component and includes the content from the Word-based SSP.
Each `statements` array entry includes:
- a required `uuid` field
- a required `by-components` array. Each array entry includes:
- a required `component-uuid` field that cites the `this-sytem` component from above.
- a required `uuid` field
- a required `description` field that contains the content from the Word-based SSP control response.
- a required `implementation-status` element with:
- a required `state` field with a value of of `implemented`.
```yaml
system-security-plan:
control-implementation:
description: n/a.
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010101
description: Word-based SSP AC-1, statement a response.
implementation-status:
state: implemented
- statement-id: ac-1_smt.b
uuid: 11111111-2222-4000-8000-012000010200
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010201
description: Word-based SSP AC-1, statement b response.
- statement-id: ac-1_smt.c
uuid: 11111111-2222-4000-8000-012000010300
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010301
description: Word-based SSP AC-1, statement c response.
implementation-status:
state: implemented
```
See the [Example](#bkmk-example) below.
---
### Native Adoption Path
When creating an SSP from scratch, ensure appropriate components are defined before authoring a control response. The `this-system` component must always be present. Other components are present baed on their use within the sytem. See [Components](https://patterns.rufrisk.com/books/system-security-plans/page/components) for more information.
```yaml
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000000000
type: this-system
title: This System
description: 'Represents the entire authorization boundary'
status:
state: operational
- uuid: 11111111-2222-4000-8000-009000600001
type: policy
title: Access Control and Identity Management Policy
description: 'A corporate policy used for the system.'
status:
state: operational
```
Every `statements` / `by-components` array has one or more entries that reference components describes how that component is satisfying that control requirement statement.
Each `statements` array entry includes:
- a required `uuid` field
- a required `by-components` array. Each array entry includes:
- a required `component-uuid` field that cites the appropriate component from above.
- a required `uuid` field
- a required `description` field that contains the content from the Word-based SSP control response.
- a required `implementation-status` element with:
- a required `state` field with a value of of `implemented`.
```yaml
system-security-plan:
control-implementation:
description: n/a.
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000600001
uuid: 11111111-2222-4000-8000-012000010102
description: Describe how this policy satisfies part a.
implementation-status:
state: implemented
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000010101
description: "Provide general context about satisfying part a that doesn't fit a defined component."
implementation-status:
state: implemented
```
#### Example
_IA-2 Identificaiton and Authentication (Organizational Users)_ is satisfied by a combination of:
- the IA Policy
- an IA Procedure
- a container running KeyCloak
- an enterprise directory capability
This was originally described in the the IA-2 narriative as:
> All components requiring authentication are configured to redirect users to KeyCloak. When a user supplies their ID and KeyCloak recognizes it as belonging to this organization, it redirects the user's authentication attempt to the enterprise directory capability for authentication. The enterprise directory reports the user's authentication success or failure back to KeyCloak. If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.
>
> The IA Policy requires use of the enterprise directory for authentication of organizational users. The system-level IA Procedure provides instructions for admins to configure their compoents to use KeyCloak for authentication.
Within the OSCAL SSP, this entire statement can initially be assocaited with the "this-system" component in the `by-component` response to AC-2.
- `by-component` (`this-system`)
> All components requiring authentication are configured to redirect users to KeyCloak. When a user supplies their ID and KeyCloak recognizes it as belonging to this organization, it redirects the user's authentication attempt to the enterprise directory capability for authentication. The enterprise directory reports the user's authentication success or failure back to KeyCloak. If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.
>
> The IA Policy requires use of the enterprise directory for authentication of organizational users. The system-level IA Procedure provides instructions for admins to configure their compoents to use KeyCloak for authentication.
---
##### Moving Toward Normalization
At a later date, the SSP author can define components for the IA Policy and system-level IA Procedure and associate them with AC-2. The content shifts to be represented like this:
- `by-component` (`this-system`)
> All components requiring authentication are configured to redirect users to KeyCloak. When a user supplies their ID and KeyCloak recognizes it as belonging to this organization, it redirects the user's authentication attempt to the enterprise directory capability for authentication. The enterprise directory reports the user's authentication success or failure back to KeyCloak. If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.
- `by-component` (`policy`)
>The IA Policy requires use of the enterprise directory for authentication of organizational users.
- `by-component` (`process-procedure`)
> The system-level IA Procedure provides instructions for admins to configure their compoents to use KeyCloak for authentication.
---
##### Fully Normalized
Eventually, components are added for KeyCloak and the enterprise directory; however, some of this narriative describes how the two work together. The `this-system` component can still be used for any narriative that doesn't fit cleanly in another component.
- `by-component` (`this-system`)
> All components requiring authentication are configured to redirect users to KeyCloak.
- `by-component` (`software` / KeyCloak)
> When a user supplies their ID and KeyCloak recognizes it as belonging to this organization, it redirects the user's authentication attempt to the enterprise directory capability for authentication.
>
> If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.
- `by-component` (`service` / enterprise directory)
> The enterprise directory reports the user's authentication success or failure back to KeyCloak.
- `by-component` (`policy`)
>The IA Policy requires use of the enterprise directory for authentication of organizational users.
- `by-component` (`process-procedure`)
> The system-level IA Procedure provides instructions for admins to configure their compoents to use KeyCloak for authentication.
This is now fully normalized.
---
# Control Implementation Statements
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 SSPs cite controls and control requirement statements in responses.
Within the OSCAL FedRAMP baselines, each control statement is assigned an identifier. Any lettered parts are also assigned identifiers.
Citing statement identifiers correctly is critical to automated processing.
See [Citing Control Statements](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/citing-control-statements) for important information.
### Typical
Most FedRAMP controls have two or more lettered parts. FedRAMP expects control responses at this level.
Within the `control-implementation` / `implemented-requirements` array, each entry includes:
- a required `uuid` field
- a required `control-id` field that cites the control [using its id from the baseline](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/citing-control-statements).
- a required `statements` array. Each array entry includes:
- a `statement-id` field that cites the control statement [using its id from the baseline](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/citing-control-statements).
- a `by-components` array
- See [Responding By Component](https://patterns.rufrisk.com/books/fedramp-system-security-plan-ssp/page/responding-by-component) for more information.
##### Multi-Part Statement Representation
```yaml
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
[content cut]
```
---
### Non-Typical
If there are no lettered parts in the control definition, such as with
AC-2 (1), there must be exactly one statement assembly.
##### Single-Statement Representation
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-04/ssp-control-response-1-crop.png)
A single-statement representation is identical to a typical multi-part statement representation, except for the following:
- there is only one entry in the `statements` array
- the `statement-id` value cites the baseline ID for the `statement` part itself instead of one of its child parts.
```yaml
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-2.1
statements:
- statement-id: ac-2.1_smt
uuid: 11111111-2222-4000-8000-012000010100
by-components:
[content cut]
```
---
# Control Response: Policies, Procedures, Plans, RoB, and Guides
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** | **Artifact to Link** | **Expected** |
| :---: | :-- | :--: |
| Each `-1` | **Policy** | 1 |
| Each `-1` | **Procedure(s)** | 1+ |
| SA-5 (`id`=`sa-5`) | **Appendix D: User Guide** | 1 |
| PL-4 (`id`=`pl-4`) | **Rules of Behavior** | 1 |
| CP-2 (`id`=`cp-2`) | **Information System Contingency Plan (ISCP)** | 1 |
| CM-9 (`id`=`cm-9`) | **Configuration Management Plan (CMP)** | 1 |
| IR-8 (`id`=`ir-8`) | **Incident Response Plan (IRP)** | 1 |
| CA-7 (`id`=`ca-7`) | **Continuous Monitoring Plan** | 1 |
| SR-2 (`id`=`sr-2`) | **Supply Chain Risk Management Plan (SCRMP)** | 1 |
## Retrofit MVP
For Retrofit MVP, simply use a `links` array in the `implemented-requirements` entry for each "-1" control.
```yaml
system-security-plan:
control-implementation:
description: There is one control in this example. Follow this pattern for each
additional control.
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
links:
- href: ./AC_Policy.docx
rel: policy
media-type: application/docx
- href: ./AC_Procedure.docx
rel: procedure
media-type: application/docx
```
## Normalized
For Retrofit Advanced, and all New adoption:
- Attach the document as a back-matter resource.
- Create a component that represents the document
- Specify the component in the control response
#### Attach Document
[Attach each document](https://patterns.rufrisk.com/books/fedramp-common/page/attachments) as `back-matter` / `resources` entries and include a `props` array with:
- `name` set to `type`
- `value` set to `policy`, `procedure`, `plan`, `users-guide` or `rules-of-behavior`
```yaml
system-security-plan:
back-matter:
resources:
- uuid: 11111111-2222-4000-8000-001000000005
title: Access Control and Identity Management Policy
description: A single policy that addresses both the AC and IA families.
props:
- name: type
value: policy
- name: published
value: '2023-01-01T00:00:00Z'
- name: version
value: '1.2'
rlinks:
- href: ./attachments/policies/sample_AC_and_IA_policy.pdf
media-type: application/pdf
```
#### Create Component
[Create a component](https://patterns.rufrisk.com/books/system-security-plans/page/components) for each document in `system-implementation` / `components` and include:
- a `props` array with one entry:
- `name` set to `implementation-point`
- `value` set to `internal` if the document is system-specific; or
- `value` set to `external` and `class` set to `corporate` if the document is Corporate
- a `links` array with one entry:
- `href` contains a URI fragment that cites the back-matter resource
- a hashtag (`#`) followed by the UUID of the back-matter resource.
- `rel` contains `attachment`
All other fields depicted in the example are required by OSCAL to be present.
```yaml
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000600001
type: policy
title: Access Control and Identity Management Policy
description: 'This is a corporate AC policy used for the system.'
props:
- name: implementation-point
value: external
class: corporate
links:
- href: '#11111111-2222-4000-8000-001000000005'
rel: attachment
status:
state: operational
```
#### Control Response
Use `implemented-requirements` / `statements` / `by-components` entries in every control response that cites the document.
```yaml
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000010000
control-id: ac-1
statements:
- statement-id: ac-1_smt.a
uuid: 11111111-2222-4000-8000-012000010100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000600001
uuid: 11111111-2222-4000-8000-012000010102
description: Describe how this policy satisfies part a.
implementation-status:
state: implemented
```
---
# Inheritence and Customer Responsibilities
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 details to be linked by tools for validation.
Within the appropriate `by-component` assembly, include an export assembly. Use `provided` to identify a capability that may be inherited by a leveraging system. Use `responsibility` to identify a `customer responsibility`. If a `responsibility` must be satisfied to achieve inheritance, add the `provided-uuid` flag to the `responsibility` field.
##### Representation
```yaml
system-security-plan:
control-implementation:
implemented-requirements:
- uuid: 11111111-2222-4000-8000-012000020000
control-id: ac-2
statements:
- statement-id: ac-2_smt.a
uuid: 11111111-2222-4000-8000-012000020100
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000000
uuid: 11111111-2222-4000-8000-012000020102
description: 'Confidential control response.'
implementation-status:
state: implemented
export:
provided:
- uuid: 11111111-2222-4000-8000-015000000001
description: This system's statement of capabilities which may be inherited
by a customer's leveraging systems toward satisfaction of AC-2, part a.
responsibilities:
- uuid: 11111111-2222-4000-8000-016000000001
provided-uuid: 11111111-2222-4000-8000-015000000001
description: 'Leveraged system''s statement of a leveraging system''s
responsibilities in satisfaction of AC-2, part a.'
responsible-roles:
- role-id: cloud-service-provider
party-uuids:
- 11111111-2222-4000-8000-004000000001
```
**See the [NIST OSCAL Leveraged Authorization Presentation](https://pages.nist.gov/OSCAL/presentations/oscal-leveraged-authorizations-v6a.pdf) for more information.**
---
## Leveraged Authorization Response: Inheriting Controls, Satisfying Responsibilities
When the current system is inheriting a control from or meeting customer responsibilities defined by an underlying authorization, the leveraged system must first be defined as described in the [*Response: Identifying Inheritable Controls and Customer Responsibilities*](#response-identifying-inheritable-controls-and-customer-responsibilities) section, and documented a `component` int the leveraging system SSP before it may be referenced in a control response. The `by-component` assembly references these components.
IMPORTANT: The leveraged system may provide a single `component` representing the entire leveraged system or may provide individual system components as well. In either case, the `inherited-uuid` property in the `component` must have the `value` flag set to the UUID of the leveraged system or component.
[](https://patterns.rufrisk.com/uploads/images/gallery/2026-02/ssp-figure-41.png)
##### Representation
```yaml
system-security-plan:
system-implementation:
components:
- uuid: 11111111-2222-4000-8000-009000100004
type: system
title: Leveraged Authorized System
description: Briefly describe the leveraged system.
status:
state: operational
control-implementation:
implemented-requirements:
statements:
by-components:
- component-uuid: 11111111-2222-4000-8000-009000000004
uuid: 11111111-2222-4000-8000-012000020104
description: For the portion inherited from an underlying FedRAMP-authorized
provider, describe **what** is inherited.
implementation-status:
state: implemented
inherited:
- uuid: 11111111-2222-4000-8000-017000000001
provided-uuid: 11111111-0000-4000-9009-002001002001
description: 'Optional description.'
satisfied:
- uuid: 11111111-2222-4000-8000-018000000001
responsibility-uuid: 11111111-0000-4000-9009-002001002002
description: 'Description of how the responsibility was satisfied.'
```
**See the [NIST OSCAL Leveraged Authorization Presentation](https://pages.nist.gov/OSCAL/presentations/oscal-leveraged-authorizations-v6a.pdf) for more information.**
# Citing Control Statements
OSCAL SSPs cite OSCAL baseline statement identifiers when representing control implementation responses. Citing the identifiers correctly is critical to machine processing.
Within OSCAL baselines, identifiers are assigned to `statement` parts and `item` parts for reference by SSPs.
### The `statement` Part
All OSCal `parts` entries have:
- a required `id` field; and
- a required `name` field.
For every control in the FedRAMP baselines there is _exactly one_ `parts` entry where `name` = `statement`. This is the `statement` part.
```yaml
- id: ac-2.1
title: Automated System Account Management
parts:
- id: ac-2.1_smt
name: statement
```
### Simple Controls
For simple controls, the `statement` part has a `prose` field that includes the control requirement statement.
```yaml
- id: ac-2.1
title: Automated System Account Management
parts:
- id: ac-2.1_smt
name: statement
prose: 'Support the management of system accounts using {{ insert: param, ac-02.01_odp }}.'
```
The `id` value for the `statement` part (i.e. `ac-2.1_smt`) is cited by the SSP's `statements` array when responding to this control.
### Controls with Child Statements
For a control with child statements (a., b., etc.), the `statement` part includes a nested `parts` array. Every element in the nested `parts` array has:
- a required `id` field; and
- a required `name` field. Always with a value of `item`.
- a `prose` field that includes this part of the control requirement statement.
- an additional nested `parts` array **IF** this part has child parts.
Each control in the FedRAMP OSCAL baselines has a `parts` array at the root of the control. Each `parts` entry includes:
- a required `id`
- a required `name`.
```yaml
catalog:
groups:
controls:
- id: ac-1
title: Policy and Procedures
parts:
- id: ac-1_smt
name: statement
parts:
- id: ac-1_smt.a
name: item
props:
- name: label
value: 'a.'
prose: 'Develop, document, and disseminate to {{ insert: param, ac-1_prm_1 }}:'
```
For SSP authoring, ignore any `parts` entry in the baseline outside of the `statement` part and its child parts. Other part types are for control assessments.
### Response Point Properties
To aid SSP authoring tools in identifying the required statement level at which to respond, `response-point` properties are included in the FedRAMP baselines.
SSP authoring tools should limit the scope of `response-point` property searches to the `statement` part and its child parts. Ignore `response-point` properties in the parts related to assessments.
A `response-point` property appears in the `props` array and includes:
- a `name` set to `response-point`
- a `ns` set to `http://fedramp.gov/ns/oscal`
- a `value` with a value that is any string and can be ignored.
```yaml
- id: ac-2.1
title: Automated System Account Management
parts:
- id: ac-2.1_smt
name: statement
props:
- name: response-point
ns: http://fedramp.gov/ns/oscal
value: You must fill in this response point.
prose: 'Support the management of system accounts using {{ insert: param, ac-02.01_odp }}.'
```
When an SSP tool encounters a `parts` entry that contains this property, it should be presented to users of SSP authoring tools as the expected level of response for that control.