SSP Library

Chapter 1

How Do I Document Each Safeguard in the SSP?

October 02, 2026

Your SSP (System Security Plan) names every requirement. The assessor still asks one question: how does each safeguard actually work here?

What the rule requires

NIST Special Publication 800-171 (NIST SP 800-171) is the federal checklist for protecting CUI (Controlled Unclassified Information). Requirement 03.15.02 covers the SSP itself. It calls for a plan that defines system components. It must describe the environment and connections to other systems. It must describe the safeguards in place or planned for each requirement. It also says to review and update the plan on a schedule you define. It says to protect the plan from unauthorized disclosure. (NIST SP 800-171 Rev. 3)

The plan can be a collection of documents, not one giant file. Effective plans reference existing policies, procedures, and design documents instead of repeating them. (NIST SP 800-171 Rev. 3, discussion of 03.15.02)

SP 800-18 is the older guide for writing security plans. It says the plan must describe the controls in place or planned. It says the plan must name who is responsible for each control. It also says the plan covers the expected behavior of everyone who touches the system. (NIST SP 800-18 Rev. 1)

The per-safeguard pattern

For each requirement, document these five items.

  1. What the safeguard is. Name the requirement and what it asks for.
  2. How it is implemented. Name the technology or process. Name the settings.
  3. Who is responsible. Name the role or team, not just a department.
  4. The evidence. Name the proof an assessor can examine.
  5. The boundary link. State which system or boundary segment it covers.

If an item is planned instead of done, say so. Planned safeguards also belong in the POA&M (Plan of Action and Milestones).

Worked example 1: multifactor authentication

Requirement 03.05.03 says to implement multifactor authentication for privileged and nonprivileged accounts. MFA (multifactor authentication) means two or more different factors. Examples include something you know plus something you have. (NIST SP 800-171 Rev. 3)

  • What: MFA is enforced for every account that can reach CUI.
  • How: Conditional access policies require a second factor at sign in. Privileged accounts require phishing resistant methods.
  • Who: The identity team owns the policies. The help desk handles authenticator resets.
  • Evidence: The conditional access policy export shows the settings. A sample of sign in logs shows MFA prompts.
  • Boundary: The policy covers the identity provider for the in scope tenant. Remote access sessions must pass the same policy.

Worked example 2: audit logging

Requirement 03.03.01 says to specify the event types selected for logging. Requirement 03.03.03 says to generate audit records for those event types. Records must be retained for the period set in the retention policy. (NIST SP 800-171 Rev. 3)

  • What: The system logs sign ins, privileged actions, and configuration changes.
  • How: Diagnostic settings forward logs to a central log store. Retention is set to one year.
  • Who: The security operations team monitors the logs. The platform team owns log collection.
  • Evidence: The diagnostic settings export shows the log sources. A sample audit record shows event type, time, and user.
  • Boundary: Logging covers all in scope Azure subscriptions. On premises servers forward logs to the same store.

What the assessor checks

NIST SP 800-171A is the assessment guide for these requirements. For the SSP requirement it lists three methods: examine, interview, and test. (NIST SP 800-171A Rev. 3)

Examine means reading the SSP and related records. The assessor also reads policies, review records, risk assessments, and architecture documents. Interview means talking to the people who wrote and run the plan. Test means checking the process for developing, reviewing, updating, and approving the plan.

The SSP appears as an examine object for almost every requirement. When the assessor checks MFA or logging, the SSP entry is read first. Keep each entry specific.

Common mistakes

Generic entries fail. Saying MFA is enabled proves nothing. Name the policy, the factors, and the accounts covered.

Stale entries fail. Update the SSP when the system changes. Your own defined review schedule is the minimum.

Missing owners fail. Every safeguard needs a named role. The word IT is not a role.

Sources

  • NIST SP 800-171 Rev. 3, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.pdf
  • NIST SP 800-171A Rev. 3, Assessing Security Requirements for Controlled Unclassified Information: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171Ar3.pdf
  • NIST SP 800-18 Rev. 1, Guide for Developing Security Plans for Federal Information Systems: https://doi.org/10.6028/NIST.SP.800-18r1

Next step

Write each safeguard from live configuration, not from memory. PolicyCortex reads live Azure configuration with 33 collectors. It builds SSP, SAR (Security Assessment Report), and POA&M output from the collected evidence. See how it works.