---
title: SSP Builder
description: 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.
navigation:
  icon: i-lucide-file-check
---

# SSP Builder

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.

::note
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](#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 |
| --- | --- |
| :badge[Implemented]{color="success"} | Every in-scope objective for the control is satisfied |
| :badge[Planned]{color="warning"} | One or more objectives are not yet satisfied |
| :badge[Not Applicable]{color="neutral"} | Every objective is marked not applicable |

::tip
A control counts as satisfied when its objectives are **implemented** *or* 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

::steps{level="4"}

#### 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.

::

::note
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

::steps{level="4"}

#### 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.

::

::tip
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.

::note
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

::steps{level="4"}

#### 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 | :badge[MANAGE_SYSTEMS]{color="info"} |

`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.

::warning
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.

:::field-group
::field{name="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.
::
::field{name="Scope"}
CAGE code, target CMMC level, scope name, unique system identifier, system categorization, and executive summary.
::
::field{name="System definition"}
Information system name and abbreviation, a function narrative, hosting model, and environments.
::
::field{name="Boundary"}
Boundary and data-flow narratives, in-scope and out-of-scope components, and physical locations.
::
::field{name="Asset inventory"}
The in-scope hardware and software, read live from your detailed inventory.
::
::field{name="External providers"}
Each provider's service type, CUI handling, FedRAMP status, and inherited controls.
::
::field{name="Interconnections"}
Each external connection's counterparty, whether CUI is involved, and whether it's encrypted.
::
::field{name="Diagrams"}
Network, boundary, and data-flow diagrams — in-app or uploaded.
::
::field{name="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.

---

## Related features

:::card-group

::card{title="Evidence Locker" icon="i-lucide-archive" to="https://app.dibfi.com/dashboard/systems"}
The files and links that prove each control — surfaced against the objectives in your plan.
::

::card{title="Document Library" icon="i-lucide-file-text" to="https://app.dibfi.com/dashboard/policy-templates"}
Generate and publish the policies your controls reference, as control-linked evidence.
::

::card{title="Asset Inventory" icon="i-lucide-server" to="https://app.dibfi.com/dashboard/inventory"}
Maintain the hardware and software that feed the plan's inventory section.
::

::card{title="Organization Settings" icon="i-lucide-building" to="https://app.dibfi.com/dashboard/org-settings"}
Record the personnel and organization details that appear on the plan's cover and identification pages.
::

:::