Writing a system security plan an assessor can follow

The document everything else hangs on

A system security plan describes what you are protecting, where the boundary sits, and how each security requirement is met in your environment. An assessor reads it first and then spends the rest of the assessment checking whether it is true. A good plan makes that check easy. A poor plan makes every requirement a negotiation.

The stakes are built into the scoring rule. Under 32 CFR 170.24, a company must have a system security plan in place at the time of assessment for each system in scope. The absence of an up-to-date plan produces a finding that "an assessment could not be completed due to incomplete information and noncompliance with 48 CFR 252.204-7012." The plan also cannot be deferred: requirement CA.L2-3.12.4 is on the list of items that may not go on a plan of action for a Conditional status.

What requirement 3.12.4 asks for

NIST SP 800-171 Revision 2, requirement 3.12.4, is one sentence: "Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems."

NIST also says there is no prescribed format or specified level of detail. Plenty of companies read that as permission to be brief. It is better read as a burden: nobody hands you a form that proves you covered it, so the plan has to show on its face that it conveys what the requirement asks for.

The eight objectives an assessor checks

NIST SP 800-171A breaks 3.12.4 into eight assessment objectives. Each one needs to be satisfied for the requirement to be scored met, so it is worth building your plan's outline directly from this list.

Objective	What it requires	Where it belongs in your plan
3.12.4[a]	A plan is developed	The document itself, with an owner and approval date
3.12.4[b]	The system boundary is described and documented	Boundary section and network diagram
3.12.4[c]	The environment of operation is described and documented	Environment section: locations, people, systems, cloud services
3.12.4[d]	Requirements approved as non-applicable are identified	A list with the approval or rationale for each
3.12.4[e]	The method of implementation is described and documented	A narrative for each requirement
3.12.4[f]	Connections to other systems are described and documented	External connections and service providers
3.12.4[g]	The update frequency is defined	Maintenance section, with a stated interval
3.12.4[h]	The plan is updated at that frequency	Revision history showing it happened

Objective [d] rewards precision. Under 32 CFR 170.24, an objective assessed as not applicable counts the same as met, and the rule's own example is public-access system separation where no publicly accessible systems sit within scope. State the reason beside each one, because "not applicable" with no explanation invites the question you would rather have answered in advance.

Start with the boundary and the asset inventory

Write the boundary before you write a single control narrative, because every sentence afterward depends on it. Name the facilities, networks, cloud tenants, endpoints and people that handle controlled unclassified information. State plainly what is outside the boundary and why.

Then build the inventory. 32 CFR 170.19 sorts Level 2 assets into five categories: CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets and Out-of-Scope Assets. For the first four, the rule requires an entry in the asset inventory, a description of how the asset is treated in the plan, and a place on the network diagram. Out-of-Scope Assets need a justification ready for why they cannot handle CUI.

Draw the diagram and the data flows

The network diagram is a required artifact under that same table, and it is where an assessor first tests whether the words match the building. Show the boundary line, the firewalls, the servers and cloud services, the workstations by group, and every path by which CUI enters and leaves.

Add one more picture that a network diagram does not give you: how CUI actually moves. Take a concrete flow such as a customer drawing that arrives through a supplier portal, gets saved to a shared drive, opens in CAD, and goes to inspection. Then show that flow on the diagram. A flow diagram catches the paths a device list misses, such as the email attachment that bypasses the file server.

Write each control narrative so it can be tested

Requirement 3.12.4 says the plan describes how requirements are implemented. NIST adds that plans describe this at a high level and do not need detailed technical design, but a sentence still has to be specific enough to check. The test is simple. Could a stranger read the sentence and know exactly what to look at?

A narrative that can be tested names four things: the tool, the setting or rule, the person who owns it, and the record it produces. Compare these two versions of the same requirement.

• The company uses multifactor authentication as appropriate to protect user accounts and follows industry best practices

• All users sign in to the CUI environment through the identity provider, where a conditional access policy requires a second factor for every network and privileged sign-in. The IT manager reviews the policy quarterly and files the export in the evidence folder

The second version gives an assessor a console to open, a setting to read, a person to interview and a record to pull. It also tells you when you have stopped meeting your own plan, which the first version never can.

Spend your best writing on the requirements that cost the most when they fail. The scoring method subtracts five points for requirements such as 3.1.1 (limit system access), 3.5.1 and 3.5.2 (identify and authenticate users and devices), 3.6.1 and 3.6.2 (incident handling), 3.12.1 and 3.12.3 (assess and monitor your controls) and 3.13.1 (protect the boundary). A vague narrative on one of these is where an assessor's attention goes first, and where a misjudged score costs the most.

Have the people who run the systems supply the facts. An outside writer can give the plan structure and clear language, but the sentence about how backups are tested should come from the person who tests them. A plan written with no contact with the systems reads that way, and an interview exposes it quickly.

The test is simple. Could a stranger read the sentence and know exactly what to look at?

Handle exceptions in the open

Some systems cannot meet a requirement fully, and the rule has a place for that. An enduring exception, such as test equipment or operational technology where full compliance is not feasible, is scored met when it is described in the plan along with any mitigations. A temporary deficiency is scored met when it is addressed in an operational plan of action that shows progress toward correction.

The operative words are "described" and "shows progress." A controller that cannot run endpoint protection belongs in the plan with its name, its reason and the compensating measures around it. A controller that goes unmentioned is simply a gap.

Document your service providers

If a managed service provider administers the environment or a cloud service holds CUI, the plan should say so, and it should say who is responsible for what. Under 32 CFR 170.19, a cloud provider that handles CUI has to meet the FedRAMP requirements in DFARS 252.204-7012, and an external provider that is not a cloud provider has its services assessed as part of your scope. Name each provider, the service, the data it touches and the division of duties, and keep the contract or responsibility matrix that backs it up.

Failures that show up in the first hour

• Vendor text pasted in. Marketing language from a security product describes what the product can do, and a plan must describe what your company does
• Future tense. "Will implement" or "plans to deploy" describes a requirement that is not met, and belongs in a plan of action
• No diagram, or one from another era. A diagram that does not match the current network undercuts everything written around it
• A boundary that stops at the server room. Laptops, phones, cloud mail and the CMM workstation hold CUI too
• Named people who have left. A departed owner tells the assessor nobody has opened the document since

Keep it current

Objectives [g] and [h] make maintenance part of the requirement itself: you define a frequency and then show you kept to it. Pick an interval you will honor, such as annually and on any significant change. Put a revision table at the front with the date, the change and the approver for each update.

Tie the plan to the events that make it stale. A new cloud service, a firewall replacement, a change of provider or a new facility each trigger an update. The review before your annual affirmation is the natural moment to read the entire plan against the running systems.

• Name one owner for the plan and one approver above them
• Store it under access control, and treat it as sensitive
• Link each narrative to the evidence that proves it, in final form, since 32 CFR 170.24 does not accept drafts or working papers
• Keep prior versions, so you can show the history

Frequently asked questions