FedRAMP System Security Plan (SSP)


Adopting OSCAL for SSP Representation


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

If you need to convert legacy documentation to OSCAL, follow the 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.

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

Adopting OSCAL for SSP Representation

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.

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.

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)

During transition, any portion of the Word SSP not yet converted to OSCAL should be attached to the OSCAL SSP content.

INTERMEDIATE

ADAVANCED

NORMALIZED

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.

---
Adopting OSCAL for SSP Representation

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.

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.

Native_Adoption_Path.png

CORE

DETAIL

CONTROLS

NORMALIZED

OSCAL Requirements

All OSCAL Core Requirements must be met for all OSCAL artifacts.

This chapter contains information about OSCAL SSP requirements that are not explicit FedRAMP SSP requirements.

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

OSCAL Representation

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:

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, Prepared by/for, Approvers

Title Page

system security plan title page image

The SSP title page follows the Title Pages pattern.

Title Page, Prepared by/for, Approvers

Prepared By/For

system security plan prepared by, prepared for page image

Prepared By and Prepared For follow the Roles pattern, using the prepared-by and prepared-for roles.

For an SSP:

Defined Identifiers Required Role IDs:

Prepared By - CSP or Self‑Prepared

When the SSP is preapred by the CSP the metadata must include:

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:

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:

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
To include location, log or other details for a Party, see Parties and Locations.
Title Page, Prepared by/for, Approvers

System Security Plan Approvals

system security plan approvals page image

SSP Approvals follow the Roles pattern, using the content-approver role.

Defined Identifiers Required Role IDs:

Sections 1 - 11

Sections 1 - 11

1. Introduction

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

Sections 1 - 11

2. Purpose

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

Sections 1 - 11

3. System Information

system security plan system information page image

System Information

CSP Name

The cloud service provider (CSP) name and abbreviation are represented in the SSP metadata.

OSCAL Representation

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.

OSCAL Representation


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.

OSCAL Representation


system-security-plan:
  system-characteristics:
    system-ids:
    - identifier-type: http://fedramp.gov/ns/oscal
      id: F00000000

FedRAMP Allowed Value

Required Identifier Type:

Service Model

The Service Model is represented in system-characteristics.

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


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:

Digital Identity Level (DIL) Determination

See Appendix E for appropriate OSCAL representation.

FIPS PUB 199 Level

See Appendix K for appropriate OSCAL representation.

Fully Operational as of

The fully operational date is represented in system-characteristics.

Although the value field is a string, the date should be treated as an OSCAL date-time-with-timezone data type.

OSCAL Representation

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.

If the deployment model is hybrid or other, the remarks field is required. Otherwise, it is optional.

OSCAL Representation

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:

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.

OSCAL Representation

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.)\].'
Sections 1 - 11

4. System Owner

system security plan system owner page image

System Owner follows the Roles pattern, using the system-owner role.

Defined Identifiers Required Role ID:

Sections 1 - 11

5. Assignment of Security Responsibility

system security plan ISSO page image

Information System Security Officer (ISSO) follows the Roles pattern, using the information-system-security-officer role.

Defined Identifiers Required Role ID:

Sections 1 - 11

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.

system security plan leveraged authoriations page image

For each row in Table 6.1 there must be:

parties Entry

A parties entry to indicate the organizaiton that owns the leveraged system or external service

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:

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.

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:

components Entry

The components entry must include:

OSCAL Representation

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 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 section for more information.

Sections 1 - 11

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.

system security plan external systems and services page image

OSCAL Representation

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):

When documenting multiple external services, each service is treated as a separate instance of an interconnection component within the OSCAL file.

Sections 1 - 11

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.

system security plan architecture page image

OSCAL Representation

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:

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 diagram, except the content is placed under network-architecture instead of authorization-boundary.

OSCAL Representation

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 diagram, except the content is placed under data-flow instead of authorization-boundary.

OSCAL Representation

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
Sections 1 - 11

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.

system security plan services, ports and protocols page image

OSCAL Representation

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:

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.

Sections 1 - 11

10. Cryptographic Modules Implemented for DAR and DIT

system security plan cryptographic modules page image

This is address in Appendix Q: Cryptographic Modules.

Sections 1 - 11

11. Seperation of Duties Matrix

system security plan separation of duties page image

The metadata / roles array must have one entry for each column

The system-implementation / users array must have one entry for each row:

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


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 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 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 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 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 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 section.
Appendices A - Q

Appendix A: FedRAMP Security Controls

See the FedRAMP Security Controls chapter.

Appendices A - Q

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 for details.

Appendices A - Q

Appendix C: Security Policies and Procedures

See Control Response: Policies and Procedures.

Appendices A - Q

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:

This is not normalized and is only for legacy conversion MVP

Normalized Key points include:

Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.

Appendices A - Q

Appendix E: Digital Identity Level (DIL) Determination

The Digital Identity Level (DIL) is represented on the page below.

system security plan digital identity level page image

Within system-characteristics there must be three entries to the props array as follows:

OSCAL Representation

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):

Appendices A - Q

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:

This is not normalized and is only for legacy conversion MVP

Normalized Key points include:

Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.

Appendices A - Q

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:

This is not normalized and is only for legacy conversion MVP

Normalized Key points include:

Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.

Appendices A - Q

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:

This is not normalized and is only for legacy conversion MVP

Normalized Key points include:

Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.

Appendices A - Q

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:

This is not normalized and is only for legacy conversion MVP

Normalized Key points include:

Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.

Appendices A - Q

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

Appendices A - Q

Appendix K: FIPS-199 Worksheet

The system's overall FIPS-199 impact level is determined primarily by the sensitivity of the information it processes.

system security plan FIPS-199 categorization page image

The overall FIPS-199 impact level is represented under system-characteristics:

The FIPS-199 Categorization worksheet is an inventory of information types in the system, based on NIST SP 800-60 Volume 2.

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

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:

Valid values for security-sensitivity-level, base and selected fields:

Appendices A - Q

Appendix L: CSO-Specific Required Laws and Regulations

Needs Work

For MVP:

For Normalized:

Appendices A - Q

Appendix M: Integrated Inventory Workbook

See Inventory Approaches for guidance.

Appendices A - Q

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:

This is not normalized and is only for legacy conversion MVP

Normalized Key points include:

Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.

Appendices A - Q

Appendix O: POA&M

See the FedRAMP POA&M book.

Appendices A - Q

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:

This is not normalized and is only for legacy conversion MVP

Normalized Key points include:

Reference Components [need citation - there may be a page for document-type compnents ] and Attachments pages. Don't duplicate those explanations here.

Appendices A - Q

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

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.

system security plan cryptographic modules page image
Component Representation: Data-In-Transit Example Product with FIPS 140-2 Validation
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.

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

ssp-figure-22.png

Component Representation: Data-At=Rest Example Product with FIPS 140-2 Validation
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.

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


System Components and Inventory

Inventory Approaches

OSCAL makes two approaches available for depicting the system inventory:

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

System Components and Inventory

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.

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.

ssp-figure-25.png

Flat Representation
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.

System Components and Inventory

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

ssp-figure-26.png

Component-based Representation
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:

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.

All Inventory

OS Infrastructure Inventory

Software and Database Inventory

Any Inventory

FedRAMP Security Controls


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:

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

FedRAMP Security Controls

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.

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


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:

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.

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.

FedRAMP Security Controls

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

controls-normalized.png

system-security-plan:
FedRAMP Security Controls

Responding to Control Baselines

system security plan control definitions page image

OSCAL references controls in baselines and catalogs. The statements are not duplicated into an OSCAL SSP the way they are with a Word SSP.

Conrol baseline requirements are imported by an OSCAL SSP and referenced as needed.

Importing a Baseline

Import the appropriate FedRAMP Baseline, either as an OSCAL profile or as an OSCAL reserved profile catalog.

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 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:

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]
FedRAMP Security Controls

Responsible Roles

Every control should have one or more responsible roles identified.

ssp-r5-control.png

In OSCAL, there are three possible sources for responsible roles:

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
FedRAMP Security Controls

Parameter Assignments

SSP Template Security Control Parameter Assignments

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:

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. 

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:

The set-parameters array would be:


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.

FedRAMP Security Controls

Implementaiton Status

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

If the implementation-status is partial, the gap must be explained in the remarks field.

If the implementation-status is planned, a brief description of the plan to address the gap, including major milestones must be explained in the remarks field. There must also be a prop (name="planned-completion-date" ns="http://fedramp.gov/ns/oscal") field containing the intended completion date. With XML, prop fields must appear before other sibling fields (such as set-parmeter, responsible-role, etc.), even though that sequence is counter-intuitive in this situation.

If the implementation-status is alternative, the alternative implementation must be summarized in the remarks field.

If the implementation-status is not-applicable, the N/A justification must be provided in the remarks field.

SSP Template Security Control Implementation Status"

Representation
<!-- system-implementation -->
<control-implementation>
    <implemented-requirement uuid="uuid-value" control-id="ac-1">
        <prop name="planned-completion-date" 
            ns="http://fedramp.gov/ns/oscal" value="2021-01-01Z"/>
        <prop name="implementation-status" 
            ns="http://fedramp.gov/ns/oscal" value="implemented" />
        <prop name="implementation-status"
            ns="http://fedramp.gov/ns/oscal" value="partial" />
        <prop name="implementation-status" 
            ns="http://fedramp.gov/ns/oscal" value="planned" />
        <prop name="implementation-status" 
            ns="http://fedramp.gov/ns/oscal" value="not-applicable"/>      
        <!-- responsible-role, statement, by-component -->
    </implemented-requirement>  
</control-implementation>
<!-- back-matter -->

The FedRAMP implementation-status property at the control's implemented-requirement level is a summary of all statement and/or component level core OSCAL implementation-status designations. It must be set appropriately based on the least value of child statement or component level implementation-status designations. When a statement and/or component level implementation-status designation is not specified, the FedRAMP implementation-status value is assumed. Individual statements and/or components may override implementation-status locally.

FedRAMP Security Controls

Control Origination

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

If the control origination is inherited, there must also be a FedRAMP extension (prop name="leveraged-authorization-uuid" ns="http://fedramp.gov/ns/oscal") field containing the UUID of the leveraged authorization as it appears in the /*/system-implementation/leveraged-authorization assembly.

SSP Template Security Control Origination

Representation
<system-implementation>
    <!-- status -->
    <leveraged-authorization uuid="uuid-of-leveraged-authorization"> 
        <!-- details cut - see Leveraged Authorizations Section -->
    </leveraged-authorization>
</system-implmentation>

<control-implementation>
    <implemented-requirement uuid="uuid-value" control-id="ac-2">
        <prop name="leveraged-authorization-uuid" 
            value="uuid-of-leveraged-authorization"/>
        <prop ns="http://fedramp.gov/ns/oscal" name="control-origination" 
            value="sp-corporate" />
        <prop ns="http://fedramp.gov/ns/oscal" name="control-origination" 
            value="sp-system" />
        <prop ns="http://fedramp.gov/ns/oscal" name="control-origination" 
            value="customer-configured" />
        <prop ns="http://fedramp.gov/ns/oscal" name="control-origination" 
            value="inherited" />
        <!-- responsible-role -->
    </implemented-requirement>
</control-implementation>
<!-- back-matter -->
FedRAMP Security Controls

Responding By Component

ssp_control_response_3_crop.png

OSCAL SSPs represent control responses in control-implementation / implemented-requirements / statements.

See Control Implementation Statements to understand how to associate control responses with specific baseline controls and control statements.

Within statements, all responses must be assocaited with one or more components via the by-components array.

OSCAL enables you to be as granular as you wish. Individual components may be added for operating systems, container images, firewalls, policies, procedures and plans. There is always a "this-system" component representing the entire system / authorization-boundary.

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:

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.

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:

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 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 for more information.

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:

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:

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.

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:

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.

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.

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.

If authentication is successful, KeyCloak generates an access token and passes it back to the compnent requesting authentication.

The enterprise directory reports the user's authentication success or failure back to KeyCloak.

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.

This is now fully normalized.

FedRAMP Security Controls

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 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:

Multi-Part Statement Representation
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

ssp_control_response_1_crop.png

A single-statement representation is identical to a typical multi-part statement representation, except for the following:


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]
FedRAMP Security Controls

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.

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 Document

Attach each document as back-matter / resources entries and include a props array with:


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 for each document in system-implementation / components and include:

All other fields depicted in the example are required by OSCAL to be present.


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.


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
FedRAMP Security Controls

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

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

ssp-figure-41.png

Representation

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 for more information.

FedRAMP Security Controls

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:

For every control in the FedRAMP baselines there is exactly one parts entry where name = statement. This is the statement part.


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


      - 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:

Each control in the FedRAMP OSCAL baselines has a parts array at the root of the control. Each parts entry includes:

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:


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