Building a Defensible SSP and POA&M

NIST 800-171 requirement 3.12.4 calls for a plan that describes system boundaries, operating environments, how each security requirement is implemented, and connections to other systems. In practice the SSP is the operational reference manual for your CUI environment — not a policy document, not a copy-paste of the NIST text, and not a corporate handbook.

When an assessor asks how you enforce MFA, the SSP should tell them exactly which product, which configuration, which group of users, and which person owns it.

• System identification & purpose — name of the system, what data it processes (CUI, ITAR), system owner, last-updated date.
• System boundary & scope — explicit in-scope/out-of-scope statements with a real network diagram showing segments, firewalls, VPNs, and the line between the CUI environment and the rest of the corporate network.
• Hardware & software inventory — every server, workstation, network device, and authorized application in scope. Assessors cross-reference this against what they observe.
• Roles & responsibilities — System Owner, ISSM, MSPs, and CSPs named, with their specific security responsibilities.
• Data flow diagrams — how CUI enters, moves, is stored, and exits.
• Implementation detail for all 110 controls — the bulk of the document and where most SSPs fall apart.

The most common SSP failure is restating the NIST requirement or copying a corporate policy. Assessors don't want to know what your policy says you should do — they want to know what you actually do. For each control, answer three questions:

1. How is the control implemented technically? Name products, configurations, and policy IDs. Not "we use MFA" but "Microsoft Entra ID with Duo Security; all CUI-environment users authenticate with password + Duo push; enforced via Conditional Access policy 'Require MFA for All Users' documented in Appendix B."
2. Who is responsible? Name the role or person who configures, monitors, and maintains it.
3. What evidence proves it works? Reference the GPO, configuration export, log review, or report that would be produced on request.

For controls that don't apply (no wireless, no mobile code, no portable media), mark them Not Applicable with a technical justification. Vague "N/A" with no reason is treated as a finding.

Cloud platforms like Microsoft 365 GCC High and AWS GovCloud inherit some controls, but never all of them. The SSP must split each shared control into what the provider handles (data center physical security, infrastructure patching) and what you handle (identity, access policies, conditional access, logging configuration). "Handled by Microsoft" without that split is an assessor finding waiting to happen.

Same rule for MSPs: a formal managed-services agreement must define their security responsibilities, grant you audit rights, and require incident notification.

NIST 800-171 requirement 3.12.2 requires a plan for closing deficiencies. Every organization has gaps; the POA&M is how you show maturity, not weakness. For each open item track:

• The specific NIST 800-171 requirement that is unmet
• A description of the deficiency
• Planned remediation steps and required resources
• Owner
• Milestones with interim dates
• Target completion date and current status

• Minimum score: 88 of 110 for a conditional Level 2 certification. Below that, no conditional, no contract.
• Certain controls cannot be POA&M'd at all. Failing one of these critical controls fails the assessment outright.
• 180-day deadline. Open POA&M items must close within 180 days of the assessment or the conditional certification is revoked.

The POA&M is no longer a parking lot. It is a ticking clock that needs executive ownership and a real budget.

Under DFARS 252.204-7020, contractors self-assess against NIST 800-171 and post a score in the Supplier Performance Risk System (SPRS). Start at 110 and subtract for each unmet requirement — some worth 1 point, some 3, the most critical worth 5. Scores can go negative; the floor is -203.

Prime contractors pressure subs for scores of 88+ before awarding work. That pressure is exactly how contractors end up reporting inflated scores — and how they end up in the DoJ's Civil Cyber-Fraud Initiative. The 2022 Aerojet Rocketdyne settlement was $9 million for cybersecurity misrepresentation. Treble damages under the False Claims Act are not theoretical.

Report what is true. A 45 with a funded POA&M and a credible timeline beats a fabricated 110 every time.

• The ISSM reviews the SSP at least annually, and whenever the environment changes — new cloud provider, new MSP, new firewall vendor, new acquisition.
• Treat the SSP as the audit artifact it is. Assessors read it first; if it describes systems that don't exist or omits ones that do, the assessment goes badly.
• Keep evidence organized. Map screenshots, configuration exports, log samples, and policy documents directly to the corresponding NIST 800-171 control. When an assessor asks, you should be able to produce the artifact in minutes.