User Guide System Security Plans
A System Security Plan documents how your system implements each control in
its baseline. In SPARC an SSP is the OSCAL system-security-plan document: you
create it from a baseline, enrich it with system metadata, record an
implementation status and narrative for every control, and export it as OSCAL.
This guide walks the full lifecycle.
Who this is for: ISSOs, control authors, and system owners. Working with SSPs requires authentication and a role with SSP permissions — see RBAC.
- Access: signed in, with a role that permits creating/editing SSPs.
- Prerequisites: a baseline (profile) to build from — see Control Catalogs & Baselines. Optionally a Component Definition (CDEF) to seed component narratives.
-
Where to find it: Implementation → System Security Plans
(
/ssp_documents).
A System Security Plan (SSP) detail view.
stateDiagram-v2
[*] --> Draft: Wizard / Upload / Import
Draft --> Enriched: Add system characteristics, components, users
Enriched --> InProgress: Set status + narrative per control
InProgress --> Complete: All controls addressed
Complete --> Exported: Export OSCAL / JSON
Exported --> [*]
- Author a new SSP from a baseline and document control implementations.
- Import an existing OSCAL SSP and continue editing it in SPARC.
- Enrich an SSP with the OSCAL-required system metadata (characteristics, components, users) needed for a valid export.
- Produce a submission-ready OSCAL SSP for the authorization package.
The SSP is the system-security-plan in the OSCAL implementation layer; it feeds
the assessment layer (SAP/SAR) and the ATO package.
- Go to Implementation → System Security Plans (
/ssp_documents). - Click Create New SSP to open the wizard (
/ssp_documents/wizard). - Select a baseline/profile — this determines the control set.
- Select a CDEF (optional) — to seed component-provided implementations.
- Enter system details: name, version, description.
- Submit. SPARC generates the SSP with one control entry per baseline control.
- From the SSP list, use Upload File to submit an existing document. Uploaded files are parsed asynchronously — the detail page shows a processing spinner and refreshes every few seconds until it reaches completed (or shows a failure banner if parsing fails).
- The Source badge on the list marks how each SSP was created: Wizard, OSCAL Import, or File Upload.
Enrichment adds the OSCAL metadata an SSP needs beyond control narratives.
- On the SSP list or detail page, click Enrich (
/ssp_documents/:id/enrich). The detail page shows an "Enrich SSP" prompt when a document is still Basic rather than Enriched. - Complete the form:
- System characteristics — description, sensitivity level, system status, authorization boundary.
- Components — title, type, description for each system component.
- System users — title and role IDs.
- Information types.
- Save. The detail page now shows the System Characteristics, Components, and Users cards, and the OSCAL badge flips to Enriched.
The SSP detail page (/ssp_documents/:id) is where the real work happens.
- Use the compliance heatmap or status chips to jump to the controls you need — chips filter the control cards by status.
- Expand a control card to see its stated requirement, catalog guidance, and any inherited/provider statements.
- Click Edit on the card to open the inline form and set:
- Status (implementation status)
- Control application and coverage level
- Control type
- Expected completion date (for planned items)
- Narrative text areas (implementation statement, etc.)
- Save the card. The compliance percentage and progress bar at the top update as you go.
For heads-down editing, open the dedicated Editor
(/ssp_documents/:id/editor), which updates control fields inline via Turbo
Frames without full page reloads.
On the detail page use Export OSCAL (for the OSCAL system-security-plan)
or Download JSON. Export when the compliance score and control statuses
reflect the current state you want to submit.
- Enrich early. Several export validations depend on system characteristics, components, and users — filling them up front avoids a late scramble.
- Drive completion with the status chips: filter to pending controls and work the list down until the compliance score is where you need it.
- Reuse CDEFs for common components (a managed database, a logging stack) so the same implementation narrative isn't retyped across systems.
- Watch the colour of the compliance score: green ≥ 80%, yellow ≥ 50%, red < 50% — a quick signal of how close the SSP is.
| Symptom | Likely cause | What to do |
|---|---|---|
| SSP stuck on the processing spinner | Async parse still running, or it failed | Wait for auto-refresh; if a failure banner appears, check the file and re-upload |
| "Enrich SSP" banner won't go away | System metadata not saved | Complete and save the enrichment form |
| OSCAL export fails validation | Missing enrichment or required control fields | Enrich the SSP and fill the flagged control fields, then re-export |
| Compliance score seems stuck | Control edits not saved | Re-open the control card, set the status, and save |
| Can't edit control cards | View-only role | Request SSP write permission (RBAC) |
- User Guides index
- Control Catalogs & Baselines — source of the SSP's control set.
- Component Definitions (CDEF)
- Security Assessment Plan (SAP) — the next step.
- Screens & UI — exhaustive element-level reference.