If your company handles Controlled Unclassified Information for a defense customer, you will likely need a system security plan, usually shortened to SSP. It is the central document of a NIST SP 800-171 program: it describes the environment that holds CUI and explains how each security requirement is met. Many small contractors find the idea intimidating, but a good SSP is mostly an organized, honest description of what you already do and what you still need to do.
What the SSP is for
The SSP serves three purposes. It forces you to define the boundary of your environment, it records how each requirement is implemented, and it gives an assessor, customer, or auditor a clear map of your practices. Under the CMMC program, which applies NIST SP 800-171 practices at Level 2, an organization's documentation and evidence are part of what gets assessed.
Step 1: Define the scope
Scope is the most important decision. Identify where CUI is stored, processed, or transmitted, and which people, systems, and facilities touch it. Everything within the boundary must meet the requirements, so a smaller boundary is cheaper and easier to defend.
Options include a dedicated cloud enclave for CUI work, a limited group of managed computers, or a separate network segment. Draw a simple diagram showing the systems, the data flows, and the connections to the outside world. Also list external service providers that handle CUI, such as cloud platforms and managed service providers.
Step 2: Inventory the assets
List the hardware, software, and services in scope, along with their owners and locations. Include user accounts and roles. If you cannot list it, you cannot show you protect it.
Step 3: Walk through the requirements
NIST SP 800-171 organizes its requirements into families, including access control, awareness and training, audit and accountability, configuration management, identification and authentication, incident response, maintenance, media protection, personnel security, physical protection, risk assessment, security assessment, system and communications protection, and system and information integrity.
For each requirement, record:
- Whether it is implemented, partially implemented, planned, or not applicable.
- A plain description of how it is met: the tool, setting, or procedure.
- Who is responsible.
- Where evidence can be found.
Write what is true
The most common failure is describing an ideal rather than reality. An assessor will compare your document with what they observe. A statement that says "all laptops are encrypted" must be provable. Where something is not yet done, say so and put it into the plan of action.
Step 4: Create the plan of action
For each gap, list what needs to be done, who owns it, the target date, and the resources required. The plan of action turns the SSP from a snapshot into a working roadmap. Keep it updated as items close.
Step 5: Gather evidence
For each implemented requirement, collect proof: screenshots of settings, policy documents, training records, access review logs, and configuration exports. Organize them so they can be found quickly.
Step 6: Keep it alive
An SSP that was written once and filed away quickly becomes inaccurate. Update it when you add systems, change providers, or alter procedures. Review it on a schedule, at least annually, and after any significant incident.
Tips for a smaller contractor
- Use a template or tool as a starting point, but rewrite it in your own terms.
- Involve the people who do the work, such as your IT provider and office manager, rather than writing in isolation.
- Align policies with practice. A beautiful policy that nobody follows is a liability.
- Be careful with shared responsibility. If a cloud provider handles part of a control, document what they do and what you remain responsible for.
- Keep the document readable. Clear writing helps the assessor and helps your own staff.
Common pitfalls
- Setting scope too wide and overwhelming your resources.
- Copying generic text that does not match your environment.
- Neglecting physical security and personnel items because they seem non-technical.
- Forgetting about managed service providers that have access to the in-scope environment.
Help from Ironfield Cyber
Ironfield Cyber helps defense-adjacent contractors define scope, draft system security plans, and prepare the technical evidence behind them. If you are starting from scratch, we can begin with a scoping conversation and a gap assessment.