3.12.4Keep a system security plan
One document describing your boundary, your environment, and how each requirement is met.
The requirement, verbatim
NIST SP 800-171 Rev. 2 · 3.12.4Develop, 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's discussion
186 There is no requirement to embed every asset in the SSP. .
System security plans relate security requirements to a set of security controls. System security plans also describe, at a high level, how the security controls meet those security requirements, but do not provide detailed, technical descriptions of the design or implementation of the controls. System security plans contain sufficient information to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk if the plan is implemented as intended. Security plans need not be single documents; the plans can be a collection of various documents including documents that already exist. Effective security plans make extensive use of references to policies, procedures, and additional documents (e.g., design and implementation specifications) where more detailed information can be obtained. This reduces the documentation requirements associated with security programs and maintains security-related information in other established management/operational areas related to enterprise architecture, system development life cycle, systems engineering, and acquisition.
Federal agencies may consider the submitted system security plans and plans of action as critical inputs to an overall risk management decision to process, store, or transmit CUI on a system hosted by a nonfederal organization and whether it is advisable to pursue an agreement or contract with the nonfederal organization.
NIST SP 800-18 provides guidance on developing security plans.
NIST SP 800-171 Rev. 2, discussion under 3.12.4. Whitespace normalised; wording unchanged.
Assessment objectives
An assessor decides each of these separately. The requirement is met only when every objective is.
- [a] a system security plan is developed
- [b] the system boundary is described and documented in the system security plan
- [c] the system environment of operation is described and documented in the system security plan
- [d] the security requirements identified and approved by the designated authority as non-applicable are identified
- [e] the method of security requirement implementation is described and documented in the system security plan
- [f] the relationship with or connection to other systems is described and documented in the system security plan
- [g] the frequency to update the system security plan is defined
- [h] system security plan is updated with the defined frequency
NIST SP 800-171A, determination statements for 3.12.4.
For assessors: examine, interview, test
NIST SP 800-171A names what an assessor may examine, whom they may interview, and what they may test for this requirement. Assessors select from these lists; they are not a checklist of everything you must produce.
Examine
- Security planning policy
- procedures addressing system security plan development and implementation
- procedures addressing system security plan reviews and updates
- enterprise architecture documentation
- system security plan
- records of system security plan reviews and updates
- other relevant documents or records
Interview
- Personnel with security planning and system security plan implementation responsibilities
- personnel with information security responsibilities
Test
- Organizational processes for system security plan development, review, update, and approval
- mechanisms supporting the system security plan
NIST SP 800-171A, potential assessment methods and objects for 3.12.4.
Evidence
No evidence examples are published for this requirement yet. The objectives above are what an assessor checks; evidence is whatever shows each one is true in your environment, dated and kept with your system security plan.
Scoring weight
Not scored. The scoring table assigns this requirement no point value; see the note below.
Why it is not scored. This requirement must be Met to receive CMMC Conditional or Final Level 2; if Not Met, no score is assigned.
DoD NIST SP 800-171 Assessment Methodology v1.2.1 weighting, as carried in the Bedrock scoring table. The score starts at 110 and subtracts the weight of every requirement not met.
In Rev. 3
Rev. 2 is what your contract requires today. A standing DoD class deviation keeps Rev. 2 in force; NIST has published Rev. 3, but it is not adopted for contracts. In Rev. 3 this requirement is reworded: 03.15.02 System Security Plan. It gains organization-defined parameters.
See the Rev. 2 and Rev. 3 wording word by word, or start with the status page.
Related requirements
Where this page's facts come from
- Requirement text
- bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.basicRequirement@rev2
- Discussion
- bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.discussion@rev2
- Practice name
- bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.title@rev2 (CMMC Assessment Guide practice name)
- Objectives
- bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2
- Examine, interview, test
- bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2 ({examineGuidance, interviewGuidance, testGuidance})
- Level
- bedrock-cmmc-api@89b8e8e:migrations/021_fix_level1_requirements.sql#Requirement.cmmcLevel@rev2
- Weight
- bedrock-cmmc-api@89b8e8e:internal/cmmc/requirement_values.go#requirementValues (DoD AM v1.2.1 / eMASS L2 template v3.8)
- Rev. 3 mapping
- bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/r2_r3_transition_map.json#r2_to_r3
- Plain-language title and summary
- editorial/CMMC Navigator.dc.html#RAW (Foxx Cyber editorial)