# 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. system security plan digital identity level page image 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. system security plan FIPS-199 categorization page image 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. system security plan cryptographic modules page image ##### 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. [![ssp-figure-22.png](/uploads/images/gallery/2026-02/scaled-1680-/ssp-figure-22.png)](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.