PL-2—System Security Plan

PBMM (P1)

Secret (P1)

Management

>Control Description

(A) The organization develops a security plan for the information system that: (a) Is consistent with the organization’s enterprise architecture; (b) Explicitly defines the authorization boundary for the system; (c) Describes the operational context of the information system in terms of missions and business processes; (d) Provides the security categorization of the information system including supporting rationale; (e) Describes the operational environment for the information system and relationships with or connections to other information systems; (f) Provides an overview of the security requirements for the system; (g) Identifies any relevant overlays, if applicable; (h) Describes the security controls in place or planned for meeting those requirements including a rationale for tailoring decisions; and (i) Is reviewed and approved by the authorizing official or designated representative prior to plan implementation. (B) The organization distributes copies of the security plan and communicates subsequent changes to the plan to ⚙organization-defined personnel or roles. (C) The organization reviews the security plan for the information system ⚙organization-defined frequency. (D) The organization updates the plan to address changes to the information system/environment of operation or problems identified during plan implementation or security control assessments. (E) The organization protects the security plan from unauthorized disclosure and modification.

>Supplemental Guidance

Security plans relate security requirements to a set of security controls and control enhancements. Security plans also describe, at a high level, how the security controls and control enhancements meet those security requirements, but do not provide detailed, technical descriptions of the specific design or implementation of the controls/enhancements. Security plans contain sufficient information (including the specification of parameter values for assignment and selection statements either explicitly or by reference) to enable a design and implementation that is unambiguously compliant with the intent of the plans and subsequent determinations of risk to organizational operations and assets, individuals, other organizations, and Canada if the plan is implemented as intended.

Organizations can also apply tailoring guidance to the security control baselines in Appendix 4 to develop overlays for community-wide use or to address specialized requirements, technologies, or missions/environments of operation (e.g., DND-tactical, GC Public Key Infrastructure, or ICAM).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.

For example, security plans do not contain detailed contingency plan or incident response plan information but instead provide explicitly or by reference, sufficient information to define what needs to be accomplished by those plans. Related controls: AC-2, AC-6, AC-14, AC-17, AC-20, CA-2, CA-3, CA-7, CM-9, CP-2, IR-8, MA-4, MA-5, MP-2, MP-4, MP-5, PL-7, SA-5, SA-17.

>Tailoring Guidance

By completing the ISSIP activities, IT projects will produce the information elements that are normally found in a system security plan. Although ISSIP promotes the minimization of standalone security documentation through the integration of ISSIP outputs into standard project deliverables, it does not proscribe the use of system security plans. Where departments have established the requirement for system security plans in their departmental security control profile or domain security control profiles, IT projects can easily prepare one for their information system by assembling the prescribed information elements from the various ISSIP activities.

>Profile-Specific Parameters

(B) frequency [at a period no longer than every 3 years or whenever a significant system change occurs]

Ask AI

Configure your API key to use AI features.