How to automate an ATO package
Automate the record first and the assembly last. An authorization package is SSP plus SAR plus POA&M, and if those three are generated from one record they cannot contradict each other — which is the actual deliverable, not the ZIP file.
An authorization package under SP 800-37 Rev 2 is three things: the System Security Plan, the Security Assessment Report, and the Plan of Action and Milestones. Everything else a program attaches is supporting material.
Most attempts to automate it start at the end — build something that assembles those three documents and produces a bundle. That works once. The second time, the three documents disagree with each other, because each was maintained separately in the interval.
The order that works runs the other way.
The order
1. Make the facts structured. Categorization and the information types behind it, the baseline and every tailoring decision, per-control implementation status, the architecture, the evidence bindings, the assessment results, the determinations, the findings. If any of these live only inside a document, that document is the record and nothing downstream can be automated safely.
2. Bind evidence to what it supports. Not a folder. An explicit relationship: this artifact supports this control and this determination, ingested from this source on this date. Without this, the SAR cannot be generated and the SSP cannot cite anything.
3. Assess against the record. Per-CCI results, each naming the assessor, the method, the date and the architecture version it was performed against. That last field is the one everyone omits and the one that makes staleness computable later.
4. Generate each artifact from the record. SSP from system facts, implementation and architecture. SAR from assessment results and determinations. POA&M from findings. All three from the same facts, which is what makes contradiction structurally impossible rather than merely unlikely.
5. Check readiness before assembling. Inventory, controls, CCI results, POA&M, evidence, documentation — is each one in a state that can be submitted? Name what is outstanding rather than producing a bundle with quiet gaps.
6. Assemble. Now the bundle is trivial, because everything in it was already true.
Steps 1 to 3 are the work. Step 6 is the part that demos well, and the reason so many programs buy step 6 and are surprised a year later.
Why the three artifacts must share a source
This is the argument for the whole approach, so it is worth making concretely.
The SSP says a control is implemented and describes how. The SAR says that control was assessed on a date with a result. The POA&M says a finding against that control is open with a scheduled completion date.
Those three statements are about the same control and they constrain each other. An SSP claiming full implementation, alongside a SAR recording a not-satisfied determination, alongside a POA&M with no corresponding item, is a package that contradicts itself — and a reviewer will find it, because finding exactly this is what review is for.
Maintained separately, that contradiction is a matter of luck and diligence. Generated from one record, it cannot happen: there is one implementation status, one determination, one finding, and three renderings of them.
What readiness checking should actually check
“Ready” is not a percentage. It is a set of specific answerable questions, per input:
- Inventory — is the asset picture current, and does it match the architecture model?
- Controls — does every control in the baseline have an implementation status and a statement? Does every tailoring decision have a recorded rationale?
- CCI results — is every applicable CCI assessed, and is any result older than your currency threshold?
- POA&M — does every not-satisfied determination have a corresponding item? Does every item have a scheduled completion date and milestones?
- Evidence — does every determination that requires supporting evidence have it, and is it current?
- Documentation — are the narrative sections present, and does each carry the tag that says whether a person authored it, it was generated, or it was accepted from a proposal?
A readiness view that names the outstanding items is useful. A percentage complete is not, because it averages a missing contingency plan against a missing comment field.
Where the package goes
Two destinations, and they need different things.
A human reviewer wants DOCX or PDF in the shape they expect. This is not a lesser output — a reviewer who cannot navigate your SSP will find fewer of its virtues and more of its gaps.
A system wants OSCAL, or in the DoD case an eMASS submission. For eMASS that means control information, CCI test results, POA&M items and inventory, ideally over a direct integration and ideally with POA&M items upserting on their eMASS external identifier so a second submission updates rather than duplicates.
Both come from the same record. That is the point. Two formats generated from one source cannot drift; two formats maintained separately will.
A checksum manifest over the bundle is worth the small effort — SHA-256 per file, so the receiving end can verify it got what you sent rather than assuming it.
The failure modes, and what causes each
One good package, then nothing. Assembly was automated without a record behind it. The second generation loses the edits made since the first.
Three artifacts that disagree. They have separate sources. This is the most common finding a reviewer raises and it is entirely structural.
A bundle with quiet gaps. No readiness check, or a readiness check that reports a percentage instead of naming what is missing.
Duplicated POA&M items in eMASS. Export without upsert on the external identifier. Small bug, enormously annoying for the reviewer who now has your findings twice.
Nobody can defend a sentence. Generation was not evidence-grounded. The document reads well and falls apart under a follow-up question.
What this does not automate
The determinations. The genuinely narrative sections — the system description, the boundary narrative, the rationale for a tailoring decision. The conversation with your AO about what they expect. The judgment about whether a compensating control is adequate.
Those are the parts of the job that require a practitioner, and a tool that claims to automate them is claiming to make authorization decisions. Automate the assembly, the traceability and the reconciliation, and give the practitioner their attention back for the parts that need it.