Automating SAR generation from the assessment record
A SAR should be generated from the assessment record, including which version of the system architecture each assessment was performed against — otherwise it describes the system as it is today rather than as it was when assessed.
The Security Assessment Report answers a narrow question: what did the assessors conclude, and on what basis?
Automating it is straightforward if the assessment record is complete. It is impossible if the record is a spreadsheet of determinations with nothing attached to what was being determined.
The missing field
Most assessment tracking records the determination, the assessor and the date. That is three of the four things you need. The fourth is what the system looked like at the time.
Without it, a SAR generated today describes conclusions about a system that has since changed, and there is no way to tell which conclusions are still load-bearing. The workaround everyone uses is to treat the assessment date as a proxy for system state and reason about it by hand at review time. That works until two changes land in the same week.
The fix is to bind each assessment to a specific, immutable version of the architecture, and to hold that binding as a fact rather than infer it from timestamps.
What that binding must and must not do
It must not move when the architecture is republished. Publishing a new version is not an assessment act. If publishing silently re-pointed every existing assessment at the newest version, the binding would claim every assessment was performed against the current state — which is both false and exactly backwards from what the field is for.
It must advance on genuine reassessment. When a control is actually reassessed, the binding moves, because that is what happened.
It must be changeable deliberately, and audibly. Occasionally a binding is wrong and needs correcting. That should require a rationale, be audited, and be refused outright on a completed campaign.
It must report absence honestly. Assessments made before the binding existed should be reported as unknown, not back-filled with a guess. “We do not know what this was assessed against” is a finding. “We assumed it was the version closest in time” is a fabrication.
Findings need their source too
A finding in a SAR should name where it came from. One that came from a scan names the scan; one that came from a checklist item names the item; one an assessor raised names the assessor.
This matters at the moment somebody disputes a finding. Being able to go straight to the source turns a meeting into a lookup.
Generating it
Once the assessment record carries determinations, per-CCI results, findings and the version each was performed against, the SAR is a rendering. It regenerates. It cannot contradict the SSP generated from the same record. And it exports as OSCAL as readily as it prints to PDF.
The work is in the record, not in the document. It always was — the document is just where the absence became visible.