Automating SSP generation without losing the thread
An SSP is worth automating only if it is generated from the authorization record rather than assembled beside it — otherwise generation is a one-time act and every subsequent change is a manual edit to a Word file.
Generating a System Security Plan is the demo everyone gives. It is a good demo, because the manual version of the job is genuinely miserable and the automated version looks like magic.
The trouble starts at the second generation.
Generated from a record, or assembled beside one
There are two architectures behind an automated SSP, and they look identical for about ten minutes.
Assembled beside a record. The tool holds some structured data, runs a template over it once, and hands you a document. From that point the document is the artifact. Changes are edits to the document. The structured data and the document drift apart immediately, and nobody can tell you which one is right.
Generated from a record. The document is a rendering of the authorization record at a point in time. The record is the artifact. Regenerating is a normal operation, not a rewrite, because there was never anything in the document that did not come from somewhere.
You can tell which one you are looking at by asking to regenerate after making a change, and watching whether anything is lost.
The parts of an SSP that should be facts
A surprising amount of an SSP is not prose at all. It is structured data that happens to be rendered as sentences:
- The FIPS 199 categorization and its rationale
- The overall impact level, which is a high-water mark and should be derived, not typed
- The control set, which comes from the baseline
- Per-control implementation status
- The authorization boundary, its zones, components, connections and data flows
- Interconnections and the agreements behind them
- Evidence references
If those live as facts, the corresponding SSP sections are deterministic. They regenerate correctly every time and cannot disagree with the SAR generated the same afternoon.
What is genuinely prose — the system description, the boundary narrative, the implementation statements — should live once, as narrative facts attached to the system, rather than being retyped into each document that needs them.
Importing the SSP you already have
Most programs are not starting from nothing. They have a two-hundred-page SSP, and the job is to get its content into a form that can be maintained.
The naive version of this is to parse the document and write what you find into the record. Do not do that. Document extraction is unreliable in exactly the ways that matter — a heading that means something slightly different, a control discussed in two places, an implementation statement that was already out of date when it was written.
The defensible version:
- Classify sections deterministically where you can, with named rules a person can inspect, and fall back to AI assistance only for headings the rules could not resolve.
- Extract with the quote attached. A proposed implementation statement for AC-2 should carry the passage it was drawn from, so a reviewer can check it in seconds rather than searching the source.
- Write nothing until a person accepts it. Extraction produces proposals. Acceptance is the authoritative act, and it should be audited like one.
- Refuse stale acceptances. If the target changed between extraction and acceptance, refuse rather than overwrite. Somebody made a more recent decision and it should win.
Tagging where each statement came from
Once a document has been through import, generation and human editing, “who wrote this?” becomes a real question — and on most programs the honest answer is that nobody knows.
Keep the tag on the statement: authored by a person, generated from the record, or accepted from a proposal on a date by a named user. If somebody later edits a generated statement, the tag should change to reflect that a human has taken ownership of the wording.
An assessor asking which parts of the SSP a person actually stands behind is asking a reasonable question. It should have an answer.
Machine-readable as well
The same record should export as OSCAL, so the systems that consume structured authorization data get it without a conversion step and without the risk of a human-readable and a machine-readable version disagreeing.
Two formats, one source. That is the only arrangement in which they cannot drift.