# System Security Plans

# Components

OSCAL component are the backbone of an OSCAL System Security Plan (SSP), enabling data normalization of inventory, control responses and other key concepts.

Create an SSP component:
- **to normalize inventory data**
  - Example: instead of listing the same OS and its details in every inventory entry, define an OS compnent and link to it from inventory.
- **for control responses**
  - Example: if it is appropriate to discuss an Identity, Credential and Access Management (ICAM) solution within a control response, define a component for it. If it is also necessary to discuss just the enterprise directory portion of that solution, consider also defining a component for that capability.
- **to represent third party validation**
  - Example: For US Government systems required to use FIPS-140-2/3 validated cryptographic modules, create a component for module and a second component representing the validation of that component. Link the two.
- **to represent external or underlying (leveraged) systems and services**
  - Example: Create a component for each cloud-native service, underlying general support system (GSS), cloud system or external/third-party capability used by your system. 

### Component Types

All components have a required `type` field. Certain component types, such as `hardware` and `software` have sub-types represented using an `asset-type` property.


<div class="callout warning">
  Under Development
</div>