03.15.02: System Security Plan

To meet the 03.15.02: system security plan requirement, you must produce and maintain a System Security Plan (SSP) that clearly defines the system boundary, how Controlled Unclassified Information (CUI) is handled, and how each NIST SP 800-171 Rev. 3 requirement is implemented (or why it is not). Treat the SSP as an operational document tied to evidence, ownership, and change control. ¹

Key takeaways:

• Your SSP must be system-specific, scoped to the CUI environment, and kept current through a defined update process. ¹
• Auditors look for traceability: each requirement mapped to concrete implementations, responsible owners, and supporting artifacts. ¹
• The fastest path to “audit-ready” is an SSP that doubles as your control catalog and evidence index, not a narrative Word document.

Most compliance failures around SSPs are not about “missing paperwork.” They happen because the SSP does not match reality: the described boundary is wrong, the control implementations are vague, or the plan is not updated when systems, third parties, or configurations change. Requirement 03.15.02: System Security Plan exists to prevent that drift and to give assessors a single, authoritative view of how you protect CUI in a nonfederal environment. ¹

For a CCO, GRC lead, or compliance officer supporting federal contracts, the SSP is the document that turns “we follow NIST” into a verifiable statement. It should answer basic questions quickly: What is the system? Where is CUI stored/processed/transmitted? What components and third parties are in scope? Which controls are implemented, and how do we prove it? ¹

This page focuses on operationalizing the requirement: scoping decisions, minimum SSP content that holds up in assessments, governance workflows to keep it current, and the evidence package you should retain so you can respond to customer requests, prime contractor flow-downs, and formal audits without a fire drill.

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.15.02 (System Security Plan).” ¹

Operator interpretation (what you must do): Maintain a written SSP for each system that handles CUI, describing the system environment and documenting how the NIST SP 800-171 Rev. 3 requirements are met for that system. The SSP must be accurate, complete enough for an assessor to understand implementation, and governed as a living document that changes when the system changes. ¹

Plain-English interpretation of the requirement

An SSP is your “single source of truth” for the CUI system. It is not a policy binder and not a marketing overview. It is a system-specific document that:

• Defines what is in scope (and what is explicitly out of scope).
• Explains where CUI exists in the environment and how it moves.
• Lists each NIST SP 800-171 Rev. 3 requirement and states your implementation approach in this system (or documents why it is not applicable).
• Points to the evidence that proves the implementation is real.

If you cannot hand an assessor your SSP and have them consistently reach the same system boundary and control conclusions as your security team, the SSP is not doing its job.

Who it applies to

Entity types (typical):

• Federal contractors and subcontractors.
• Any nonfederal organization operating systems that handle CUI. ¹

Operational context:

• Applies per system, not per company. If you have multiple distinct environments that handle CUI (separate enclaves, programs, networks, or cloud tenants), you should expect separate SSPs or a clearly partitioned SSP with unambiguous boundaries.
• Applies whether the system is on-prem, cloud, hybrid, or supported by third parties (managed service providers, SaaS platforms, hosting, incident response retainers). Your SSP must still document what is in scope and how shared responsibility works.

What you actually need to do (step-by-step)

1) Decide and document the system boundary (scope)

Create a boundary statement that a technical reviewer can test. Include:

• In-scope networks, identity providers, endpoints, servers, cloud accounts/subscriptions/tenants, CI/CD pipelines, and admin workstations used to manage the environment.
• Out-of-scope corporate systems (HR, finance, general email) with justification, plus the separation mechanism (network segmentation, separate tenant, separate identity, VDI, etc.).
• All ingress/egress points where CUI can cross the boundary (file transfer, email gateways, collaboration tools, APIs).

Practical test: If you removed one component from the diagram, would it change your ability to protect CUI? If yes, it belongs in scope.

2) Describe the CUI lifecycle in the system

In the SSP, explicitly document:

• Where CUI is received (from primes, agencies, third parties).
• Where CUI is stored (databases, file shares, object storage).
• Where CUI is processed (applications, analytics, engineering tools).
• Where CUI is transmitted (user access paths, integrations, VPN, remote access).
• How CUI is disposed of or archived.

This is where SSPs often fail: teams describe “the system” but never describe “the CUI.”

3) Build the control implementation summary (requirement-by-requirement)

For each NIST SP 800-171 Rev. 3 requirement, record in the SSP:

• Implementation status: implemented / partially implemented / planned / not applicable (only if you can defend it).
• How it’s implemented in this system: the actual mechanism (tooling, configuration, process).
• Responsible owner: role or team accountable for operation.
• Evidence pointer: where proof lives (ticketing system, screenshots, config exports, logs, policy docs, monitoring reports).

Keep the writing concrete. “Access is restricted” is not acceptable by itself. Name the control mechanism (for example: MFA enforced via your identity provider for privileged roles; conditional access policies; PAM workflow; logging to SIEM).

4) Tie the SSP to change control so it stays current

Define an SSP update trigger list and a workflow:

• System architecture changes (new subnets, new tenants, new identity provider).
• Major configuration changes (logging pipeline changes, encryption changes).
• New third party services inside the boundary (managed services, SaaS, hosting).
• New CUI types or new data flows.
• Findings from internal assessments or customer assessments.

Operationalize it with a lightweight gate: the change ticket must include “SSP impact: yes/no” and, if yes, link the SSP update PR/ticket.

5) Establish review, approval, and versioning

Minimum governance expectations:

• Named SSP owner (often system owner + security/GRC co-owner).
• Version history (what changed, when, by whom).
• Approval workflow (security + system owner; legal/procurement input if boundary includes third party contractual obligations).
• Controlled distribution (SSPs can contain sensitive security details; store in a restricted repository).

6) Make the SSP assessment-ready (your “evidence index”)

Assessors do not want a narrative. They want traceability. Add:

• A system diagram (data flows, trust boundaries).
• Asset inventory excerpt for in-scope components.
• A control-to-evidence table that points to durable artifacts (configs, reports, logs).
• Known gaps and Plans of Action and Milestones (POA&Ms), if used in your program, tied back to the relevant requirement and system component.

7) Operationalize recurring evidence collection

The SSP requirement fails in practice when evidence is stale. Set up recurring pulls for:

• Identity and access configuration exports.
• Vulnerability scan outputs for in-scope assets.
• Logging/alerting coverage proof.
• Backup job status and restore testing records.
• Training and admin access reviews for in-scope roles.

Daydream (or a similar GRC workflow tool) becomes valuable here when it acts as the SSP’s “control map” plus evidence tracker: each requirement mapped to the system’s implementation, with assigned owners and recurring evidence requests, so the SSP stays aligned with what you can prove.

Required evidence and artifacts to retain

Keep these artifacts tied to the SSP version:

• SSP document with version history and approvals.
• System boundary diagram(s) and data flow diagram(s).
• In-scope asset inventory (or a filtered view from CMDB/cloud inventory).
• Control implementation mapping (requirement-by-requirement) with owners.
• Evidence index with stable references (where logs/configs/reports live).
• Change records that caused SSP updates (tickets, CAB notes, architecture decision records).
• Third party documentation for in-scope services: shared responsibility notes, contracts/SLAs/security addenda, and due diligence summaries.
• Internal assessment results relevant to the system and remediation tracking.

Common exam/audit questions and hangups

Expect questions like:

• “Show me the system boundary. Which cloud accounts/tenants are in scope?”
• “Where exactly is CUI stored and who has access?”
• “For requirement X, describe the implementation and show evidence from the system.”
• “How do you ensure the SSP stays current after engineering changes?”
• “Which third parties are inside the boundary, and what controls are theirs vs yours?”
• “Why is requirement Y marked ‘not applicable’?”

Hangups that slow assessments:

• SSP content that is copied from a policy without system detail.
• Diagrams that don’t match actual network/cloud topology.
• Evidence links that point to ad-hoc screenshots with no change history.
• Unowned controls (“IT handles it”) instead of a named role/team.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix
Writing one SSP for the whole company	Blurs boundaries; assessors can’t tell what protects CUI	Define per-system SSPs or clearly separated enclaves with explicit boundaries
Treating SSP as a one-time deliverable	Drift between document and environment	Add change triggers + SSP update workflow tied to change management
Vague control statements	No testable implementation	Use “mechanism + scope + owner + evidence pointer” for every requirement
Marking items “not applicable” casually	Easy assessor challenge	Require written justification tied to system architecture and data flows
Forgetting third parties inside the boundary	Shared responsibility gaps	List each third party service, what it hosts/does, and how you verify controls

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this specific requirement, so this page does not cite enforcement outcomes.

Operationally, the risk is straightforward: a weak SSP creates an “unable to demonstrate” problem even when technical controls exist. That leads to failed customer assessments, delayed contract awards, remediation projects under deadline, and inconsistent security operations because teams do not share the same definition of what is in scope. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and ownership)

• Assign SSP owner and system owner; define approval workflow.
• Confirm the CUI system boundary and produce a boundary + data flow diagram draft.
• Inventory in-scope assets and in-scope third parties.
• Draft SSP skeleton: system purpose, architecture overview, CUI lifecycle, boundary definition.

By 60 days (make it assessable)

• Complete requirement-by-requirement implementation statements for the system.
• Build the evidence index and collect “first-pass” artifacts for high-friction areas (access control, logging, vulnerability management).
• Document shared responsibility for each in-scope third party service.
• Run an internal tabletop assessment: pick several requirements and verify the SSP claims match live configs and logs.

By 90 days (operate it as a living system document)

• Connect SSP updates to change control tickets and architecture review.
• Establish recurring evidence collection tasks with owners and due dates.
• Track gaps in a remediation register and reflect the current state in the SSP (avoid “future tense” claims).
• Perform a formal SSP review/refresh cycle and lock a version for customer/audit use.

Frequently Asked Questions

Do I need a separate SSP for each application?

Not automatically. You need an SSP per “system” that handles CUI, defined by a defensible boundary; multiple apps can share one SSP if they share the same enclave, controls, and evidence set. ¹

What level of technical detail is expected in the SSP?

Enough detail that an assessor can test your statements. Name the actual mechanisms (tools, configurations, workflows), scope them to the boundary, and point to evidence that can be produced on request. ¹

Can the SSP be a collection of links instead of a single document?

Yes if governance is strong: versioning, controlled access, and stable references are non-negotiable. Many teams use a primary SSP document plus linked diagrams, inventories, and evidence repositories.

How do we handle third party SaaS or MSP services in the SSP?

List each in-scope third party service, describe what data/functions it touches, and document the shared responsibility model. Tie that to due diligence artifacts and the evidence you can actually obtain (reports, attestations, configuration proof).

What’s the fastest way to fail an SSP review?

Claiming controls are implemented without system-specific proof. If your SSP says “logs are collected,” you should be able to show which sources, where they go, retention expectations, and sample events for in-scope assets.

How should we keep the SSP current without creating a bureaucracy?

Put SSP impact into existing engineering workflows. Add an “SSP update required: yes/no” field to change tickets and require a link to the SSP update when the answer is yes.

Footnotes

1. NIST SP 800-171 Rev. 3