Security requirement
- a.Develop a system security plan that:
- 1.Defines the constituent system components;
- 2.Identifies the information types processed, stored, and transmitted by the system;
- 3.Describes specific threats to the system that are of concern to the organization;
- 4.Describes the operational environment for the system and any dependencies on or connections to other systems or system components;
- 5.Provides an overview of the security requirements for the system;
- 6.Describes the safeguards in place or planned for meeting the security requirements;
- 7.Identifies individuals that fulfill system roles and responsibilities; and
- 8.Includes other relevant information necessary for the protection of CUI.
- b.Review and update the system security plan [Organization-defined: frequency].
- c.Protect the system security plan from unauthorized disclosure.
Discussion
System security plans provide key characteristics of the system that is processing, storing, and transmitting CUI and how the system and information are protected. System security plans contain sufficient information to enable a design and implementation that are unambiguously compliant with the intent of the plans and the subsequent determinations of risk if the plan is implemented as intended. System security plans can be a collection of documents, including documents that already exist. Effective system security plans reference policies, procedures, and documents (e.g., design specifications) that provide additional detailed information. This reduces the documentation requirements associated with security programs and maintains security information in other established management or operational areas related to enterprise architecture, the system development life cycle, systems engineering, and acquisition.
Tailoring decisions required
Resolve these values through the governing organization’s approved tailoring and risk-management process before declaring the requirement implemented.
Implementation perspective
Treat System Security Plan as a CUI protection outcome that must be reflected in the system boundary, documented implementation, operational behavior, and assessment evidence. Pay particular attention to accurate plans, architecture, rules of behavior, system boundaries, and lifecycle alignment for CUI protection.
- Confirm the requirement is in scope for the CUI system components, services, users, and external connections being assessed.
- Resolve every organization-defined parameter through an approved governance and tailoring process.
- Map each clause of the requirement to an accountable owner, implementation mechanism, and evidence source.
- Verify that inherited and shared implementations are supported by current provider evidence and responsibility boundaries.
- Collect evidence during normal operation and review changes, exceptions, and deficiencies on a risk-based cadence.
Questions to ask
- Which CUI assets, data flows, users, and services are protected by this requirement?
- Which portions are implemented locally, inherited, shared, or not applicable, and what evidence supports that determination?
- Do the system security plan, deployed configuration, operating process, and assessment evidence tell the same story?
- What change, incident, or threshold should trigger reassessment?
Evidence and validation
- system security plans
- architecture and data-flow diagrams
- rules-of-behavior acknowledgments
- plan review and approval records
Common failure patterns
- plans copied from templates without system specificity
- diagrams that do not match deployed services
- inherited protection claimed without provider evidence
- plans updated only before assessment
Assessment objectives and methods
Assessment objectives (11)
- a.1.
a system security plan that defines the constituent system components is developed.
- a.2.
a system security plan that identifies the information types processed, stored, and transmitted by the system is developed.
- a.3.
a system security plan that describes specific threats to the system that are of concern to the organization is developed.
- a.4.
a system security plan that describes the operational environment for the system and any dependencies on or connections to other systems or system components is developed.
- a.5.
a system security plan that provides an overview of the security requirements for the system is developed.
- a.6.
a system security plan that describes the safeguards in place or planned for meeting the security requirements is developed.
- a.7.
a system security plan that identifies individuals that fulfill system roles and responsibilities is developed.
- a.8.
a system security plan that includes other relevant information necessary for the protection of CUI is developed.
- b.
the system security plan is reviewed [Organization-defined: frequency].
- b.
the system security plan is updated [Organization-defined: frequency].
- c.
the system security plan is protected from unauthorized disclosure.
Examine
- security planning policy and procedures
- procedures for system security plan development and implementation
- procedures for system security plan reviews and updates
- enterprise architecture
- system security plan
- records of system security plan reviews and updates
- risk assessments
- risk assessment results
- security architecture and design documentation
- other relevant documents or records
Interview
- personnel with system security planning and plan implementation responsibilities
- system developers
- personnel with information security responsibilities
Test
- processes for system security plan development, review, update, and approval
Source NIST SP 800-53 controls
These controls are referenced by the official SP 800-171 Rev. 3 OSCAL record. Open the corresponding control pages for complete control text, enhancements, D3FEND mappings, and related learning.
Authoritative sources
- NIST SP 800-171 Revision 3 official publication ↗
- NIST SP 800-171A Revision 3 official publication ↗
- NIST OSCAL Content release used for this import ↗
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. The official publications, the responsible federal agency, and the governing contract or agreement determine applicability, tailoring, assessment depth, and required implementation.