SSP Builder

Assemble a complete, assessor-ready System Security Plan — organization and system details, boundary, asset inventory, external providers, interconnections, diagrams, and per-control implementation narratives — then preview, print, or export it to PDF.

The SSP Builder assembles your System Security Plan — the single document an assessor reads to understand what your CUI environment is, where its boundary sits, and how you meet every applicable security requirement. Instead of writing that document by hand, you fill in a series of guided sections and the builder stitches them together with the implementation narratives you've already authored, producing one continuous, print-ready plan.

A System Security Plan is a foundational CMMC and NIST SP 800-171 artifact (practice CA.L2-3.12.4): every organization seeking certification must have a current SSP that describes the system boundary, the environment, and the implementation status of each control. The SSP Builder keeps that plan tied to the live data already in your workspace — your systems, your asset inventory, your external providers, and your per-objective statements — so the plan you export reflects the environment you actually assessed.

The SSP Builder belongs to an assessment — open it from within an assessment, and switch between assessments using the selector next to the title. Each assessment has its own plan. See Permissions for who can build and export it.

Key concepts

The plan is built from sections

The builder is organized into sections, each capturing one part of the plan. You can fill them in any order and return to them at any time; the export weaves them into a single document.

Section	What it captures
Scope	The organization's CAGE code, target CMMC level, a scope name and unique system identifier, the system categorization, and an executive summary of the CUI environment
Vendors	External service providers you rely on — service type, whether they handle CUI, FedRAMP status, and the controls you inherit from them
System Definition	The information system's name and abbreviation, a narrative of what the system does, its hosting model, and its environments
Asset Inventory	The hardware and software components in scope, pulled live from your detailed asset inventory
Boundary	A narrative of the authorization boundary and data flow, the in-scope and out-of-scope components, and physical locations
Diagrams	Network, boundary, and data-flow diagrams — built in-app or uploaded
Interconnections	Connections to external organizations — the counterparty, whether CUI crosses the link, and whether it's encrypted
Controls	The per-control implementation narratives and their status, assembled read-only from your assessment work

Control implementation status

In the Controls section, each control shows a single status derived automatically from the status of its underlying objectives. You never set it here — it reflects the work you did while assessing.

Status	Meaning
Implemented	Every in-scope objective for the control is satisfied
Planned	One or more objectives are not yet satisfied
Not Applicable	Every objective is marked not applicable

A control counts as satisfied when its objectives are implementedor marked not applicable with a justification — the same rule used for your SPRS score and compliance percentage everywhere else in the app. The status conveys N/A directly, so an out-of-scope control still reads as a complete, defensible answer rather than a gap.

Data flows in, so you don't re-type it

Much of the plan is already in your workspace. When you open the builder, it fills empty fields only from data you've already entered — it never overwrites something you've edited by hand.

Pulled from	Fills
Your systems and their scope	In-scope / out-of-scope components on the boundary
Your onboarding environment answers	The system's hosting model
The assessment's level	The target CMMC level in Scope
Your external service providers	The Vendors list
Your detailed asset inventory	The hardware and software components
Your objective implementation statements	The per-control narratives in Controls

Using the SSP Builder

Work through the sections, review completeness, then export.

Complete the organization and system details

Fill in the scope

In Scope, record your CAGE code, target CMMC level, a scope name, and a unique system identifier, then write an executive summary describing your mission, the CUI you handle, and the purpose of the enclave.

Define the system

In System Definition, give the information system a name and abbreviation, describe what it does, and confirm its hosting model and environments.

Add external providers and interconnections

In Vendors, list the external service providers you rely on and note which handle CUI and what controls you inherit. In Interconnections, record any connections to outside organizations and whether CUI crosses them.

The target CMMC level and any external providers you've already recorded are imported for you — you'll see a note where a field was pre-filled. Adjust anything that isn't right.

Establish the boundary and diagrams

Describe the boundary

In Boundary, confirm which components are in scope and out of scope, list your physical locations, and write the boundary and data-flow narratives.

Add diagrams

In Diagrams, build interactive network, boundary, and data-flow diagrams in-app, or upload existing diagram files. If you provide both, the in-app diagram is used.

Your in-scope components, providers, locations, and interconnections seed the diagram canvas, so you're arranging real elements of your environment rather than starting from a blank page.

Confirm the asset inventory

The Asset Inventory section shows the hardware and software in scope, pulled live from your detailed asset inventory. Review it here, but make any edits in the inventory itself — the section always reflects the current inventory.

Review the control narratives

The Controls section assembles, read-only, the implementation narrative and status for every applicable control, grouped by family. Each control lists its objectives, the narrative that answers them, any per-system statements, and the evidence attached.

Control narratives are authored elsewhere — as you assess each objective and record how it's met. The SSP Builder pulls those statements in; it does not edit them. To change what a control says in the plan, update the objective's implementation statement in your assessment.

Review completeness and export

Open the preview

Choose Preview & Print to see the full plan rendered as it will appear in the finished document — cover page, organization and personnel details, system identification, boundary, inventories, diagrams, and every control.

Check for gaps

Read through the preview. Sections you haven't completed show as unspecified, and any control still short of satisfied reads as Planned — a quick way to spot what's left before an assessor sees it.

Export

Print the plan directly from your browser, or Download PDF to save a formatted copy for your assessor or your records.

Permissions

Building and exporting the SSP is a system-management capability.

Capability	Permission
Open the SSP Builder, edit its sections, preview, print, and export	MANAGE_SYSTEMS

MANAGE_SYSTEMS is held by Organization Admin, MSP Super Admin, MSP Admin, and Platform Admin — the same roles that manage systems and scope. Roles without it (Org User, Assessor) don't open the builder directly.

The control narratives shown in the plan come from your assessment work, and editing those objective statements requires the assessment permissions for that work — not the SSP Builder. The builder assembles and exports them; it doesn't author them.

How it works

Extra detail on how the plan is assembled and exported — product behavior, not internals.

What the plan pulls together

Each section contributes a defined set of details to the finished document.

Organization & personnel

Your legal name and address, plus the primary security contact, affirming official, and system security officer recorded in your organization settings — surfaced on the plan's cover and identification pages.

Scope

CAGE code, target CMMC level, scope name, unique system identifier, system categorization, and executive summary.

System definition

Information system name and abbreviation, a function narrative, hosting model, and environments.

Boundary

Boundary and data-flow narratives, in-scope and out-of-scope components, and physical locations.

Asset inventory

The in-scope hardware and software, read live from your detailed inventory.

External providers

Each provider's service type, CUI handling, FedRAMP status, and inherited controls.

Interconnections

Each external connection's counterparty, whether CUI is involved, and whether it's encrypted.

Diagrams

Network, boundary, and data-flow diagrams — in-app or uploaded.

Controls

Every applicable control, its objectives, the implementation narrative and status, per-system statements, and attached evidence.

Which controls appear

The Controls section is scoped to the assessment. It shows the objectives that apply at the assessment's CMMC level, limited to your in-scope systems, and it omits any control that every in-scope system has excluded. If you haven't defined a boundary yet, it falls back to showing all objectives so nothing is hidden while you're still scoping.

How status is decided

Each control's status is computed from its objectives, never entered on the plan: Implemented when all are satisfied, Not Applicable when all are marked N/A, and Planned otherwise. "Satisfied" means implemented or N/A-with-justification — so the plan's rollup always agrees with your compliance percentage and SPRS score.

Filling without overwriting

Every automatic pull is additive: it fills a field only when that field is empty. Anything you type by hand stays exactly as you left it, even after new systems, providers, or answers appear elsewhere — the builder adds what's missing and leaves your edits alone.

Exporting

The preview renders the whole plan in the browser. From there you can print it or download a PDF — a formatted document with a cover page, organization and personnel identification, the full environment description, your diagrams, and every control laid out with its status and narrative.

Evidence Locker

The files and links that prove each control — surfaced against the objectives in your plan.

Document Library

Generate and publish the policies your controls reference, as control-linked evidence.

Asset Inventory

Maintain the hardware and software that feed the plan's inventory section.

Organization Settings

Record the personnel and organization details that appear on the plan's cover and identification pages.

Evidence Locker & Requests

Collect, store, organize, and maintain the evidence that proves each CMMC objective is met — upload files or links, link them to objectives, track expiry, and request evidence from your team.

Overview

Manage risk, run recurring compliance tasks, and track remediation with POA&Ms.