The System Security Plan is the document an assessor reads first and judges you by. It describes what systems you have, where the boundary around CUI sits, who is responsible for what, and — requirement by requirement, all 110 of them — how each one is met in your shop specifically.
It is not a policy. Policies say what the company requires; the SSP says what is actually true. An assessor holds the two against each other, and then against the evidence.
What has to be in it
- System boundary and a data flow: where CUI enters, where it lives, where it leaves, and what touches it on the way.
- An inventory of the components inside that boundary, including the CAD workstation nobody thinks of as a server.
- For each of the 110 requirements: an implementation statement naming the actual mechanism — the product, the setting, the frequency, the person.
- Roles and responsibilities, by name or position rather than "IT".
- Anything not yet implemented, cross-referenced to a POA&M entry with a real date.
Why the free templates disappoint
A downloadable template gives you the skeleton and leaves the hard 90% blank, because the hard 90% is your environment. "Multifactor authentication is enforced for all privileged accounts" is a sentence anybody can paste. Naming which accounts are privileged, which system enforces the second factor, and what happens on the machine tool that cannot support it — that is the SSP, and no template can guess it.
The most common failure is not a missing control. It is a plan that describes an aspirational company rather than the one an assessor is standing in.
So should you write it yourself?
If you have someone in-house who knows the network genuinely well and can protect a few uninterrupted weeks for writing, yes — self-written plans pass all the time. Be honest about the second half of that sentence, because it is where it usually breaks down. The owner-operator who is also the estimator and the quality manager does not have three weeks.
The middle path most small shops end up on: an interview-driven draft produced by someone who has written these before, then reviewed line by line by the person who actually runs the systems. That review is not optional and never should be — you are the one affirming it.
That is exactly how our readiness package works. We interview, we draft every implementation statement, we flag every place a statement is thin, and nothing ships until a human at your shop has cleared each flag.