OSCAL package pattern
How TRGR structures a machine-readable authorization package in OSCAL, so the control implementations, the components, and the open items live as linked data an assessor's tooling can read directly.
- Profile and baseline
- The profile that tailors a control catalog to the system's impact level. The package starts from the exact set of controls in scope, not a generic list.
- System Security Plan model
- The SSP expressed as OSCAL: the system description, the boundary, and the responsible parties as structured fields rather than prose in a Word file.
- Control-implementation statements
- One statement per control, describing how the control is met and pointing at the component responsible, so each control traces to the part of the system that satisfies it.
- Component definitions
- Reusable descriptions of each part of the system, a service or a managed AWS service, and the controls it satisfies. A control implemented once is referenced everywhere it applies.
- Open findings as linked data
- Open items tracked as records linked to the control and component they concern, so remediation status is queryable rather than buried in a spreadsheet.
- Validation against the model
- The package checked against the OSCAL schema and the selected baseline before it reaches an assessor, so structural errors are caught by tooling, not by a reviewer.
The SSP, the implementation statements, the component definitions, and the open findings live as connected OSCAL an assessor's tooling reads directly.