OSCAL SSP generation
Generating a valid OSCAL SSP is a serialisation problem and most tools can do it. The question worth asking is whether the OSCAL and the human-readable SSP are two renderings of one record, or two artifacts that can drift apart.
OSCAL — NIST’s Open Security Controls Assessment Language — gives authorization data a machine-
readable form. The system-security-plan model covers system characteristics, the authorization
boundary, control implementation, the parties involved and the back-matter that holds evidence
references.
Emitting a schema-valid SSP is not hard. Plenty of tools do it, and a schema validator will pass output that is complete nonsense. What separates a real OSCAL capability from a checkbox is narrower and more interesting.
The test: can the two formats disagree?
Every SSP has two audiences. A reviewer reads DOCX or PDF. A system consumes OSCAL.
The question is whether those are two renderings of one set of facts, or two artifacts each maintained on its own.
If they can disagree, OSCAL is an export format. Somebody generated it once, the DOCX has been edited eleven times since, and the JSON on disk describes a system from four months ago. This is the common case and it is worse than not offering OSCAL at all, because a consumer has no way to know the file is stale.
If they cannot disagree, OSCAL is the record’s native shape. Both outputs are generated from the same facts, so changing a fact changes both, and there is no version of the workflow in which one is current and the other is not.
Ask a vendor to change a control implementation status, regenerate both, and show the change in each. Two minutes, and it settles the question completely.
What the model needs from your record
Working backwards from the OSCAL SSP model tells you what your record has to hold. This is a useful exercise even if you never emit OSCAL, because the model is a reasonable specification of what a system security plan actually is.
System characteristics. The system name and identifier, its description, the security
categorization with the FIPS 199 information types behind it, the security impact levels for
confidentiality, integrity and availability, and the overall sensitivity level. Note that OSCAL
wants the information types, not just the resulting level — if your record stores only the level,
you cannot produce a complete system-characteristics block and you also cannot explain how the
level was derived.
Authorization boundary. OSCAL models it with a description and diagram references. If your boundary exists only as a Visio file, this is where that becomes a problem: you can reference the diagram but you cannot express what is inside it. A structured architecture — zones, components, connections, data flows — fills this properly and pays off far beyond OSCAL.
System implementation. Users, components, inventory items. Components carry a type, a status and responsible roles. This maps well onto an architecture model and badly onto a spreadsheet.
Control implementation. Per control, an implementation statement, and where a control has multiple statement parts, per-part responses. This is where CCI-level structure helps: a record that models assertions individually has something to say per part, and a record with one narrative blob per control has to repeat itself.
Parties and responsible roles. Who is the system owner, the ISSO, the AO. Structured, not typed into a signature block.
Back matter. Resources — evidence, policies, agreements — referenced from the statements that rely on them. This is the OSCAL expression of evidence binding, and a record without explicit bindings has nothing to put here.
Profiles, baselines and the import chain
An OSCAL SSP imports a profile, and the profile resolves against a catalog. This chain matters more than it first appears.
Seeding the 800-53 Rev 5 catalog from NIST’s own OSCAL release means the control text, structure and identifiers in your record are the authoritative ones rather than a transcription. Transcriptions drift — a parameter renamed, an enhancement mis-numbered, a control text updated in a NIST errata release and not in your copy.
The baseline your program uses is a profile over that catalog: which controls are selected, which are tailored out, and what the parameter values are. Expressing tailoring as profile modifications rather than as edits to control text keeps the relationship between your baseline and the NIST catalog inspectable.
Round-tripping
Import matters as much as export, and it is the part most tools skip.
A program that already has an OSCAL SSP — from another tool, from a cloud service provider, from an inherited authorization — should be able to bring it in. That means parsing the model, mapping it onto your record’s structures, and handling the mismatches honestly.
The rule that makes import safe is the same one that makes any import safe: write nothing until a person accepts it. An imported implementation statement is a proposal. It carries where it came from. An authorized practitioner accepts it, and the acceptance is recorded. Silent writes from an external file into an authorization record are how records become untrustworthy.
Common ways OSCAL output goes wrong
- Schema-valid, semantically empty. Every required field present, populated with placeholders. A validator passes it. A consumer gets nothing.
- UUID churn. Component and statement UUIDs regenerated on every export, so no consumer can diff two versions of your SSP. UUIDs should be stable properties of the underlying facts.
- Back matter with no bindings. Resources listed but not referenced from the statements that depend on them, which discards exactly the traceability OSCAL exists to carry.
- Categorization without information types. The impact level asserted as a bare value, so nobody can check the high-water-mark derivation.
- Stale export. The file was generated in March and the record has moved. This is the drift problem, and it is only solved by generating both formats from one source.
Why bother, on a DoD program
A fair question when your submission target is eMASS and your reviewer wants a Word document.
Three reasons that hold up. Inheritance and interconnection data moves between systems far more cleanly as structured data than as prose. Tooling that consumes authorization data — assessment tools, dashboards, downstream systems — increasingly expects OSCAL and the direction of travel is one way. And most usefully, if your record can emit a complete OSCAL SSP, that is strong evidence the record is genuinely structured rather than a document store with a database in front of it.
The OSCAL export is a test your own architecture has to pass.