Adoption Strategy

Compliance frameworks vary greatly. Within a framework, the granularity of required information can also vary from one organization to the next.

OSCAL is designed to normalizes the variability between frameworks. It also offers flexibility to handle information at varying levels of granularity. As a result, representing content in OSCAL can be ambiguous to early adoptors.

As with any technology project, OSCAL adoption should start with the minimum viable product (MVP) and evolve to more comprehensive use cases.

SSP Adoption Path

1. Extreme MVP

   • Metadata includes only the CSP role and party
   • OSCAL syntax minimum necessary system information
     • paste App K table into a single information-types entry
     • Link directly to architecture, network and data flow diagrams
     • plus service-model, deployment-model
   • Only a this-system component
   • Control Responses (representing 90% of legacy SSP content)
     • All responses at this-system component
     • Only responsible-roles, no child party-uuids

2. Flat Inventory

   • convert legacy excel file and/or begin generating inventory as OSCAL inventory-items

3. Architecture, network, data flow diagrams

   • add links

4. Required attachments

   • Add direct links from the appropriate controls to identify relevant attachments

5. Required SSP roles (System owner, ISSO, AO, etc.)

6. The following in any order:

   • Information types
   • leveraged authorizations
   • external systems and services
   • Separation of Duties Matrix

7. Normalize Inventory (depends on "Add Flat Inventory") [MAJOR TRANSITION POINT]

   • Use components to the greatest degree practical
   • inventory-items become implemented instances of components

8. The following in any order:

   • Services, Ports and Protocols (depends on normalized inventory)
   • Cryptographic Modules (App Q table) (depends on nornalized inventory)

9. Transition to resources

   • all attachments are represented as resources
   • links use URI fragments to reference resources

10. Components for Documents

    • add components for policies, processes, plans and other documents

11. Evolving control responses (depends on "Normalize Inventory" and "Components for Documents")

    • within implemented-requirements add by-components entries for each relevant component
    • add/move component-specific control responses to their associated by-components response.

12. Customer Responsibility and Inheritence:

    • Move customer responibility statements to //by-components/export/responsibilities

---