Skip to main content

New Adoption

If you are approaching OSCAL to intially create your system security plan and do not have legacy documentaiton to convert, follow this strategy.

If you need to convert legacy documentation to OSCAL, follow the Retrofit Adoption strategy.

[Placeholder -Page: CointentUnder to be developed here.Development.]

Component-first approach

Foundation

  • Critical system information
  • Components
    • this-system (Core OSCAL Mandatory)
    • technical components. Appropriate level of granularity for:
      • SSP control responses: If you need to reference an element of the system in a control response, there should be a defined OSCAL component.
      • normalizing inventory reporting: for any item appearing in the inventory, details about its vendor, product/service name, version or other details should be a defined component.
    • Document Components for Policies, Procedures, Plans, RoB, User Guides

Details

  • Required SSP Roles
  • Information Types / FIPS-199 Categorization
  • Leveraged Authorizations and External Services (needed for Controls below.)
  • Cryptographic Module representation

Controls

  • Assign Components
  • Responses at the Component Level
  • Derived from included components:
    • Roles
    • Implementaiton Status
  • Add roles where they are not inherited from cited components
  • Override implementation status only where necessary. Examples:
    • Cited components don't represent all components.
    • Planned upgrades or replacement of components
Back to top