- A completed System Boundary Definition Worksheet (ATL-001) — this worksheet does not work without one
- The asset inventory and the applicability questionnaire's findings summary
- Access to the people and provider contacts who can state, for each requirement family, what is actually in place
ATL-003WORKSHEETEDITORIAL REVIEW COMPLETE
System Security Plan Development Worksheet
A preparation worksheet that gathers, in one place, the raw material a system security plan is written from — system identification, the boundary reference, environment description prompts, per-family implementation notes, and interconnections — so the SSP drafting session starts from facts instead of a blank page.
Using this artifact
Purpose, inputs, and completion
Purpose. A system security plan fails most often not in the writing but in the gathering: the author sits down to draft and discovers nobody collected the boundary, the environment facts, or the per-family current state. This worksheet is the gathering step — it assembles the inputs an SSP is written from, in the order an SSP needs them, with evidence pointers attached. It deliberately stops where the SSP begins.
When to use it. Work through it after the boundary worksheet is complete and approved, with the administrators and providers who actually run each part of the environment contributing their own rows. Record current state only — what is true today, who does it, where the proof lives — and mark everything uncertain UNKNOWN so the SSP author inherits honest gaps instead of confident fiction. Refresh it before every SSP update rather than letting the plan drift away from the facts underneath it.
- Complete the boundary worksheet first; every section here assumes its output and cites it rather than restating it.
- Fill the identification and environment sections from records — inventory, contracts, provider agreements — not from memory.
- For each requirement family of the revision you are working against, record current state, who implements, and where the evidence lives; write UNKNOWN rather than optimistic prose.
- List every interconnection the boundary worksheet's crossings section surfaced, and note which have agreements behind them.
- Hand the finished worksheet to whoever drafts the SSP — it is their input stack, not their output.
Keeping it honest
Evidence, validation, and failure modes
- A single gathered input package an SSP author can draft from without re-interviewing the organization
- A per-family current-state record with named implementers and evidence pointers
- An interconnection list with the agreement status of each connection
- Hand the completed worksheet to someone who did not fill it in and ask them to describe the environment back to you; where they cannot, the worksheet has a gap the SSP would inherit.
- Pick two evidence pointers from the family table at random and open them; each must resolve to a real, dated artifact — a pointer to a document that does not exist is a finding in waiting.
What looks done but is not
- The worksheet is mistaken for the SSP itself and handed to a reviewer as one — it gathers inputs and makes no implementation claims.
- Family rows filled with aspirations ('we will deploy…') instead of current state, so the SSP drafted from them describes a fictional environment.
- The boundary reference points at a boundary worksheet that has since changed, and nobody re-syncs the two before drafting.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain the completed worksheet with the SSP's working papers; the trail from gathered fact to written plan is what makes the plan defensible.
Full document
Preview — exactly what prints
WORKSHEET · GOVERNANCE & PROGRAM MANAGEMENTv1.0 · REVIEWED 2026-08-06
System Security Plan Development Worksheet
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
A system security plan fails most often not in the writing but in the gathering: the author sits down to draft and discovers nobody collected the boundary, the environment facts, or the per-family current state. This worksheet is the gathering step — it assembles the inputs an SSP is written from, in the order an SSP needs them, with evidence pointers attached. It deliberately stops where the SSP begins.
How to use it
Work through it after the boundary worksheet is complete and approved, with the administrators and providers who actually run each part of the environment contributing their own rows. Record current state only — what is true today, who does it, where the proof lives — and mark everything uncertain UNKNOWN so the SSP author inherits honest gaps instead of confident fiction. Refresh it before every SSP update rather than letting the plan drift away from the facts underneath it.
What this worksheet is — and is not
This worksheet produces inputs to a system security plan. It is not one.
Nothing here is an SSP, a plan section, or an implementation claim. This worksheet knows nothing about your system boundary — it consumes the boundary your own System Boundary Definition Worksheet (ATL-001) defined, and every answer in it is only as good as that boundary. An SSP must still be authored, within your defined boundary, describing how each requirement is addressed in your environment; completing this worksheet does not do that work and does not, by itself, address any requirement. Treat every requirement reference below as a mapped relationship, not an equivalence claim.
Use it the way a builder uses a bill of materials: everything the SSP author needs, staged and labeled, none of it pretending to be the finished structure.
System identification
The front matter every plan needs, gathered once. Pull from records, not recollection.
Identification
| System / environment name | System type (on-prem, cloud tenant, hybrid) | Operational status | Responsible organization and named official | Information types handled (from the applicability questionnaire) | Key provider relationships (MSP, cloud services) |
|---|---|---|---|---|---|
Boundary reference
Cite the boundary — do not restate it. If the referenced version is stale, stop and fix that first.
Boundary document
| Boundary worksheet title | Version and date | Owner | Approved by | Known changes since that version |
|---|---|---|---|---|
No boundary, no worksheet
If there is no completed, approved boundary worksheet, stop here and complete ATL-001 first. Every section below assumes the boundary exists; gathering SSP inputs against an undefined boundary produces a plan about nothing in particular.
Environment description prompts
Short factual answers — two or three sentences each — that become the SSP's environment-of-operation narrative.
Environment facts
| Physical locations where in-scope work happens | Network shape in one paragraph (segments, cloud, remote access) | User population (counts by role, including provider staff) | How data enters and leaves (from the boundary crossings) | Where backups go and who can reach them | What changed in the environment in the last twelve months |
|---|---|---|---|---|---|
Implementation notes by requirement family
One row per requirement family of the revision you are drafting against — 14 families in Rev. 2, 17 in Rev. 3. Current state means today, in production, verifiable.
Rows beginning EXAMPLE: show the expected shape — replace them with your own, and add a row for every family of your target revision.
| Requirement family | Current state (in place / partial / planned / UNKNOWN) | Who implements (internal / provider / shared) | Evidence pointer |
|---|---|---|---|
| EXAMPLE: Access control | Partial — MFA enforced for cloud sign-in, not yet for VPN | Shared: internal identity admin + MSP | Conditional-access policy export, compliance library / Identity, 2026-07 |
| EXAMPLE: Media protection | UNKNOWN — removable-media handling never examined | Internal | None yet — logged as a gap |
A 'planned' row must name the plan it appears in (POA&M entry or project); a 'partial' row must say which part is missing. Rows that read well but point at no evidence are the ones an assessor unravels first.
Interconnections
Every system outside your boundary that yours deliberately exchanges data with. Start from the boundary worksheet's crossings and add anything discovered since.
Rows beginning EXAMPLE: show the expected shape — replace them with your own.
| Connected system or party | Direction | Data exchanged | Agreement in place (yes / no / informal) | Protection mechanism |
|---|---|---|---|---|
| EXAMPLE: Prime's transfer portal | Inbound / outbound | Marked drawings, delivery data | Yes — contract data-handling clause | TLS portal; named accounts with MFA |
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader or compliance lead |
| Approval authority | Executive sponsor |
| Review frequency | Quarterly while the SSP is being drafted; thereafter refreshed before every SSP update |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain the completed worksheet with the SSP's working papers; the trail from gathered fact to written plan is what makes the plan defensible. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.