Compliance and Risk Management Automation

[brian-ruf]

This issue is related to the morning session "Rules" conversation at the December 15, 2025 plugfest. While the exact terminology to use for this work varied, most seemed to agree that the focus topic was enabling automation of compliance and risk management activities via OSCAL.
Most present were in favor of the Foundation continuing work on this topic under the TWG.

At the end of the session, we agreed to the following steps forward:

1. Identify use cases: We need consensus as to the use cases we are trying to satisfy
2. Develop OSCAL modeling patterns for each use case
3. Take a holistic view and optimize modeling across use cases. (Also ensure no conflicts)
4. Develop materials that enable new-comers to quickly adopt the appropriate patterns for each use case.

While the group did not discuss the following, I want to suggest:

• Use cases are designed so that that can either stand alone or work together depending on the OSCAL content author's goals.
• Data population is a separate topic. While this effort may develop representative examples, any concerns for how the data gets populated at scale is out of scope and to be addressed separately. We produce the models and allow other innovation to populate the data.
• To address steps 1 and 2, we will create child issues for each use case from this parent issue, and work each use case independently.
• We will attempt to use core OSCAL to the greatest degree practical. We will consider extensions and proposed model modifications if necessary; however, those should be used sparingly.

Related Use Case Issues:

• Identification of Framework Satisfaction with cDefs #2
• Inclusion of framework content/documentation #3
• Inclusion of automated deployment scripts #4
• Inclusion of validation scripts #5
• Inclusion of testing directives #6
• Representation of telemetry #7

[brian-ruf]

Here are some of the use cases I heard:

• Identification of framework satisfaction within cDefs
• Inclusion of framework content/documentation: Suitable for importing into an SSP or similar industry construct
• Inclusion of automated deployment scripts: Within component definitions (Ansible, TWerraform, chef, etc.) that achieve configuration relative to a framework target
• Inclusion of validation scripts
• Inclusion of testing directives: relative to specific components and frameworks in component defs and/or assessment plans
• Representation of telemetry: in assessment results

What did you hear differently? What other use cases do you have?