System Security Plan (SSP) and Plan of Action and Milestones (PoA&M)

A System Security Plan (SSP) is a critical document that outlines the security controls implemented within an organization to protect the confidentiality, integrity, and availability of a system. The SSP is integral to meeting research contract compliance requirements, including those stipulated by FAR 52.204-21 (Basic Safeguarding) and DFARS 252.204-7012 Safeguarding Covered Defense Information and Cyber Incident Reporting (CUI).

FAR 52.204-21 (Basic Safeguarding) establishes basic security controls for contractor information systems that involve Federal Contract Information. It is complemented by DFARS 252.204-7012, which calls for advanced protection of covered defense information and requires defense contractors to implement the cybersecurity standards described in NIST SP 800-171 for Controlled Unclassified Infomation CUI).

For compliance with Basic Safeguarding, the SSP must demonstrate how an organization is addressing 15 essential security controls to protect systems processing, storing, or transmitting Federal contract information (FCI). The required controls aim to limit system access to authorized users and functions, establish secure communication protocols, and prevent unauthorized information disclosure as well as other security measures.

For compliance with DFARS 252.204-7012, the SSP must demonstrate how an organization is addressing all 110 controls from NIST SP 800-171, which enhances the protections for controlled unclassified information (CUI). The SSP is specifically connected to NIST SP 800-171, necessitating that an SSP be developed, documented, and periodically updated.

The purpose of the SSP is to provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements. A System Security Plan is required to meet research contract compliance requirements. More specifically, it will show how all required controls are being addressed. The SSP also delineates the responsibilities and expected behavior of all individuals who access the system.

A Plan of Actions & Milestones (PoA&M) is a key document component in the security authorization package and for continuous monitoring activities. The POA&M facilitates a disciplined and structured approach to tracking risk mitigation activities. The POA&M includes security findings for the system from continuous monitoring activities and periodic security assessments. A POA&M describes the current disposition of any discovered vulnerabilities and system findings and includes intended corrective actions for those findings.

Why is a System Security Plan (SSP) important for researchers?

Federal agencies have to make sure that the sensitive data that is sent to a non-federal agency has similar levels of security to protect that data. The SSP is part of the security compliance requirements because it documents how that non-federal agency is protecting the data.

A DFARS 252.204-7012 clause does not exempt contractors from any additional safeguarding requirements mandated by federal agencies for protected contractor information systems or for controlled unclassified information (CUI) outlined by Executive Order 13556. Equally important contractors (researchers) must also flow down these requirements to all applicable subcontracts to ensure the security of FCI throughout the supply chain.

At the University of Michigan, there are multiple levels used to create a complete project-specific SSP.

Currently, there are three (3) categories of SSPs for CUI at the University of Michigan:

  1. Stand-alone System Security Plan (SSP)- This is the plan where the researcher implements 110 controls as required by the appropriate DFARS clause.
  2. Project-specific System Security Plan (SSP) – This is a plan that documents those controls that are not completely addressed by other services the PI is using such as the Secure Enclave Service (SES). This is where information specific to the project security will be captured, and how shared security responsibilities for controls are implemented.
  3. Organizational System Security Plan (SSP) – This plan is inherited from the service owner and is not meant to be filled out by the researchers. It is completed by a service owner and is intended to be referenced in the Project-specific System Security Plan (SSP) of the researchers using that service.
  4. SECURE Enclave Service (SES) OSSP example