SSP Automation

    SSP Automation for CMMC and NIST SP 800-171

    SSP automation generates and maintains your CMMC System Security Plan against all 110 NIST SP 800-171 Rev. 2 controls — drafted from real evidence, regenerated whenever control state changes, and defensible to a C3PAO. Athena replaces the 200-page Word document that ages out in 90 days with a live SSP that always matches the system it describes.

    What is SSP automation?

    An SSP (System Security Plan) is the foundational CMMC document. It describes how your organization implements each of the 110 NIST SP 800-171 controls — system boundary, CUI scope, control statements, implementation descriptions, responsible parties, and evidence citations. SSP automation is software that drafts the document from real evidence (policies, telemetry, configuration baselines, SOC reports), keeps it synchronized with current control state, and exports it in the formats a C3PAO or DIBCAC reviewer accepts. The point is not just to write the document faster — the point is that the document does not lie about the system on the day the assessor reads it.

    Why manual SSPs fail

    A hand-built SSP is a Word document that captures what the system looked like the week it was written. CMMC environments change continuously — a new identity provider, a revised baseline, a remediated finding, a scoped-in subsidiary. Every change makes the SSP slightly less true. By the third quarter, the SSP and the live environment have drifted far enough that the C3PAO interview will surface the gap immediately. The remediation is not a fix — it is a rewrite.

    The other failure mode is provenance. A hand-written control statement cannot be traced to the evidence that justifies it. The assessor asks "show me the policy excerpt and the configuration export that back this paragraph," and the trail goes cold.

    What Athena's SSP automation does

    • 110-control coverage. Drafts the SSP across every Level 2 control with citations to the evidence backing each implementation statement.
    • Real-evidence drafting. Pulls from policies, telemetry, configuration baselines, SOC reports — not templates.
    • Live regeneration. When control state changes, the affected SSP sections regenerate. No quarterly rewrite cycle.
    • Reviewer workflow. Human reviewers accept, edit, or reject each section. Nothing exports without sign-off.
    • Provenance on every paragraph. Each control statement carries a "Why?" trace to the source evidence, the AI draft, and the reviewer who approved it.
    • OSCAL and eMASS-shaped export. Machine-readable for ingestion by DoD acquisition systems.

    How SSP automation connects to the rest of the assessment

    The SSP, POA&M, and SAR all draw from the same evidence ledger. When evidence lands, it links to the objective it satisfies; the SSP updates the corresponding implementation statement; the POA&M closes the matching open item; the SPRS score recalculates. By assessment day, the three documents tell the same story because they are generated from the same source. The workflow automation pillar walks through the end-to-end flow.

    Buyer checklist for SSP automation

    • Drafts across all 110 controls, not just a subset.
    • Cites source evidence per implementation statement, not generic templates.
    • Regenerates from current state — no drift between document and system.
    • Human-in-the-loop sign-off before export.
    • OSCAL output for machine-readable ingestion.
    • Provenance trace per paragraph the C3PAO can verify.

    Frequently asked questions

    Can the SSP really be generated from evidence, not templates?

    Yes. Athena reads policies, telemetry, configuration baselines, and SOC reports linked to each NIST SP 800-171A objective, then drafts the implementation statement from that material. Templates supply structure; evidence supplies content. Reviewers approve every statement before it lands in the exported SSP.

    How does an automated SSP stay current after the assessment?

    Live telemetry from your SIEM, EDR, identity provider, and configuration tools validates technical controls continuously. When a control state changes, the corresponding SSP section regenerates and flags for reviewer approval. The SSP and the live system never drift more than one review cycle apart.

    Is the output a Word document or machine-readable?

    Both. Athena exports the SSP in human-readable form for assessor review and in OSCAL JSON for machine-readable ingestion by eMASS, prime contractor portals, and future DIBCAC tooling. Every artifact carries a SHA-256 chain-of-custody hash and a provenance trace.

    Further reading

    Related Athena pages and authoritative external references.

    Ready to act on this?

    Run the free Quick Score, then walk through the Assessment Pack.