Planning

Table of Contents

On this page

 

The controls and activities in the Planning (PL) family deal with the development, documentation, update and implementation of security and privacy plans for organizational systems. These plans describe the security and privacy controls in place or planned for the systems, and the rules of behaviour for individuals accessing the systems.

PL-01 Planning policy and procedures

Activity

  1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles]
    1. [Selection (1 or more): Organization-level; Mission/business process-level; System-level] planning policy that
      1. addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance
      2. is consistent with applicable laws, jurisprudence, Orders in Council, directives, regulations, policies, standards, and guidelines
    2. procedures to facilitate the implementation of the planning policy and the associated planning controls
  2. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the planning policy and procedures
  3. Review and update the current planning
    1. policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]
    2. procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]

Discussion

Planning policy and procedures for the controls in the PL family are implemented within systems and organizations. The risk management strategy is an important factor in establishing such policies and procedures. Planning policies and procedures contribute to security and privacy assurance. Therefore, it is important that security and privacy programs collaborate on their development.

Security and privacy program policies and procedures at the organization level are preferable and may remove the need for mission-level or system-specific policies and procedures. The policy can be included as part of the general security and privacy policy or be represented by multiple policies that reflect the complex nature of organizations.

Procedures can be established for security and privacy programs, for mission/business processes, and for systems, if needed. Procedures describe how the policies or controls are implemented and can be directed at the individual or role that is the object of the procedure. Procedures can be documented in system security and privacy plans or in one or more separate documents.

Events that may precipitate an update to planning policy and procedures include, but are not limited to, assessment or audit findings, security incidents or breaches, or changes in laws, jurisprudence, Orders in Council, directives, regulations, policies, standards, and guidelines. Simply restating controls does not constitute an organizational policy or procedure.

Related controls and activities

PM-09, PS-08, SI-02, SI-12.

Enhancements

None.

References

Top of page 
 

PL-02 System security and privacy plans

Activity

  1. Develop security and privacy plans for the system that
    1. are consistent with the organization’s enterprise architecture
    2. explicitly define the constituent system components
    3. describe the operational context of the system in terms of mission and business processes
    4. identify the individuals that fulfill system roles and responsibilities
    5. identify the information types processed, stored, and transmitted by the system
    6. provide the security categorization of the system, including supporting rationale
    7. describe any specific threats to the system that are of concern to the organization
    8. provide the results of a privacy risk assessment for systems handling personal information
    9. describe the operational environment for the system and any dependencies on or connections to other systems or system components
    10. provide an overview of the security and privacy requirements for the system
    11. identify any relevant control baselines or overlays, if applicable
    12. describe the controls in place or planned for meeting the security and privacy requirements, including a rationale for any tailoring decisions
    13. include risk determinations for security and privacy architecture and design decisions
    14. include security- and privacy-related activities affecting the system that require planning and coordination with [Assignment: organization-defined individuals or groups]
    15. are reviewed and approved by the authorizing official or designated representative prior to plan implementation
    1. document the business purposes for the processing of personal information
    2. define retention and disposition standards for personal information stored within the system
  2. Distribute copies of the plans and communicate subsequent changes to the plans to [Assignment: organization-defined personnel or roles]
  3. Review the plans [Assignment: organization-defined frequency]
  4. Update the plans to address changes to the system and environment of operation or problems identified during plan implementation or control assessments
  5. Protect the plans from unauthorized disclosure and modification

Discussion

System security and privacy plans are scoped to the system and system components within the defined authorization boundary and contain an overview of the security and privacy requirements for the system and the controls selected to satisfy the requirements. The plans describe the intended application of each selected control in the context of the system with a sufficient level of detail to correctly implement the control and to subsequently assess the effectiveness of the control.

The control documentation describes how system-specific and hybrid controls are implemented and the plans and expectations regarding the functionality of the system. System security and privacy plans can also be used in the design and development of systems in support of lifecycle-based security and privacy engineering processes.

System security and privacy plans are living documents that are updated and adapted throughout the system development lifecycle (e.g., during capability determination, analysis of alternatives, requests for proposal, and design reviews). Section 2.1 describes the different types of requirements that are relevant to organizations during the system development lifecycle and the relationship between requirements and controls.

Organizations may develop a single, integrated security and privacy plan or maintain separate plans. Security and privacy plans relate security and privacy requirements to a set of controls and control enhancements. The plans describe how the controls and control enhancements meet the security and privacy requirements but do not provide detailed, technical descriptions of the design or implementation of the controls and control enhancements. Security and privacy plans contain sufficient information (including specifications of control parameter values for selection and assignment operations 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.

Security and privacy plans do not need to be single documents. The plans can be a collection of various documents, including documents that already exist. Effective security and privacy plans make extensive use of references to policies, procedures, and additional documents, including design and implementation specifications, where more detailed information can be obtained. The use of references helps reduce the documentation associated with security and privacy programs and maintains the security- and privacy-related information in other established management and operational areas, including enterprise architecture, system development lifecycle, systems engineering, and acquisition. Security and privacy plans do not need to contain detailed contingency plans, incident response plans, or privacy breach processes but can instead provide (explicitly or by reference) sufficient information to define what needs to be accomplished by those plans.

Security- and privacy-related activities that may require coordination and planning with other individuals or groups within the organization include assessments, audits, inspections, hardware and software maintenance, acquisition and supply chain risk management, patch management, and contingency plan testing. Planning and coordination include emergency and non-emergency (i.e., planned or non-urgent unplanned) situations. The process defined by organizations to plan and coordinate security- and privacy-related activities can also be included in other documents, as appropriate.

Related controls and activities

AC-02, AC-06, AC-14, AC-17, AC-20, CA-02, CA-03, CA-07, CM-09, CM-13, CP-02, CP-04, IR-04, IR-08, MA-04, MA-05, MP-04, MP-05, PL-07, PL-08, PL-10, PL-11, PM-01, PM-07, PM-08, PM-09, PM-10, PM-11, RA-03, RA-08, RA-09, SA-05, SA-17, SA-22, SI-12, SR-02, SR-04.

Enhancements

  • (01) System security and privacy plans: Concept of operations
    • Withdrawn: Incorporated into PL-07.
  • (02) System security and privacy plans: Functional architecture
    • Withdrawn: Incorporated into PL-08.
  • (03) System security and privacy plans: Plan and coordinate with other organizational entities
    • Withdrawn: Incorporated into PL-02.

References

 

PL-03 System security plan update

Withdrawn: Incorporated into PL-02.

Top of page 
 

PL-04 Rules of behaviour

Activity

  1. Establish and provide to individuals requiring access to the system the rules that describe their responsibilities and expected behaviour for information and system usage, security, and privacy
  2. Receive a documented acknowledgment from such individuals, indicating that they have read, understand, and agree to abide by the rules of behaviour, before authorizing access to information and the system
  3. Review and update the rules of behaviour [Assignment: organization-defined frequency]
  4. Require individuals who have acknowledged a previous version of the rules of behaviour to read and re-acknowledge [Selection (1 or more): [Assignment: organization-defined frequency]; when the rules are revised or updated]

Discussion

Rules of behaviour represent a type of access agreement for organizational users. Other types of access agreements include non-disclosure agreements, conflict of interest agreements, and acceptable use agreements (see PS-06). Organizations should consider rules of behaviour based on individual user roles and responsibilities and differentiate between rules that apply to privileged users and rules that apply to general users.

Establishing rules of behaviour for some types of non-organizational users, including individuals who receive information from federal systems, is often not feasible given the large number of such users and the limited nature of their interactions with the systems. Rules of behaviour for organizational and non-organizational users can also be established in AC-08. The related controls and activities section provides a list of controls that are relevant to organizational rules of behaviour. PL-04B, the documented acknowledgment portion of the control, may be satisfied by the literacy training and awareness and role-based training programs conducted by organizations if such training includes rules of behaviour. Documented acknowledgments for rules of behaviour include electronic or physical signatures and electronic agreement check boxes or radio buttons.

GC discussion

The expectations for rules of behaviour for external system users or recipients of information contained within governmental systems can be captured in an information sharing agreement or arrangement.

Related controls and activities

AC-02, AC-06, AC-08, AC-09, AC-17, AC-18, AC-19, AC-20, AT-02, AT-03, CM-11, IA-02, IA-04, IA-05, MP-07, PS-06, PS-08, SA-05, SI-12.

Enhancements

  • (01) Rules of behaviour: Social media and external site/application usage restrictions
    • Include in the rules of behaviour restrictions on:
      1. use of social media, social networking sites, and external sites/applications
      2. posting organizational information on public websites
      3. use of organization-provided identifiers (e.g., email addresses) and authentication secrets (e.g., passwords) for creating accounts on external sites/applications
    • Discussion: Social media, social networking, and external site/application usage restrictions address rules of behaviour related to the use of social media, social networking, and external sites when organizational personnel are using such sites for official duties or in the conduct of official business, when organizational information is involved in social media and social networking transactions, and when personnel access social media and networking sites from organizational systems. Organizations should also address specific rules that prevent unauthorized entities from obtaining non-public organizational information from social media and networking sites either directly or through inference. Non-public information includes personal information and system account information.
    • Related controls and activities: AC-22, AU-13.

References

 

PL-05 Privacy impact assessment

Withdrawn: Incorporated into RA-08.

 

PL-06 Security-related activity planning

Withdrawn: Incorporated into PL-02.

Top of page 
 

PL-07 Concept of operations

Activity

  1. Develop a Concept of Operations (CONOPS) for the system describing how the organization intends to operate the system from the perspective of information security and privacy
  2. Review and update the CONOPS [Assignment: organization-defined frequency]

Discussion

The CONOPS may be included in the security or privacy plans for the system or in other system development lifecycle documents. The CONOPS is a living document that requires updating throughout the system development lifecycle. For example, during system design reviews, the CONOPS is checked to ensure that it remains consistent with the design for controls, the system architecture, and the operational procedures. Changes to the CONOPS are reflected in ongoing updates to the security and privacy plans, security and privacy architectures, and other organizational documents, such as procurement specifications, system development lifecycle documents, and systems engineering documents.

Related controls and activities

PL-02, SA-02, SI-12.

Enhancements

None.

References

Top of page 
 

PL-08 Security and privacy architecture

Activity

  1. Develop security and privacy architectures for the system that describe
    1. the requirements and approach to be taken for protecting the confidentiality, integrity, and availability of organizational information
    2. the requirements and approach to be taken for handling personal information to minimize any privacy risk to individuals
    3. how the architectures are integrated into and support the enterprise architecture
    4. any assumptions about, and dependencies on, external systems and services
  2. Review and update the architectures [Assignment: organization-defined frequency] to reflect changes in the enterprise architecture
  3. Reflect planned architecture changes in security and privacy plans, CONOPS, criticality analysis, organizational procedures, and procurements and acquisitions

Discussion

The security and privacy architectures at the system level are consistent with the organization-wide security and privacy architectures described in PM-07, which are integral to and developed as part of the enterprise architecture. The architectures include an architectural description, the allocation of security and privacy functionality (including controls), security- and privacy-related information for external interfaces, information being exchanged across the interfaces, personal information data flow, and the protection mechanisms associated with each interface. The architectures can also include other information, such as user roles and the access privileges assigned to each role; security and privacy requirements; types of information processed, stored, and transmitted by the system; supply chain risk management requirements; restoration priorities of information and system services; and other protection needs.

It is important to follow relevant guidance on the use of security architectures as part of the system development lifecycle process. The Cyber Centre recommends the use of the systems security engineering concepts described in System lifecycle cyber security and privacy risk management activities (ITSP.10.037). Security and privacy architectures are reviewed and updated throughout the system development lifecycle, from analysis of alternatives through review of the proposed architecture in contract proposals to the design reviews before and during implementation (e.g., during preliminary design reviews and critical design reviews).

In today’s modern computing architectures, it is becoming less common for organizations to control all information resources. There may be key dependencies on external information services and service providers. Describing such dependencies in the security and privacy architectures is necessary for developing a comprehensive mission and business protection strategy.

Establishing, developing, documenting, and maintaining under configuration control a baseline configuration for organizational systems is critical to implementing and maintaining effective architectures. The development of the architectures is coordinated with the office of the departmental CIO, the senior official in the department’s security governance, and the appropriate privacy senior official or executive to ensure that the controls needed to support security and privacy requirements are identified and effectively implemented.

In many circumstances, there may be no distinction between the security and privacy architecture for a system. In other circumstances, security objectives may be adequately satisfied, but privacy objectives may only be partially satisfied by the security requirements. In these cases, consideration of the privacy requirements needed to achieve satisfaction will result in a distinct privacy architecture. The documentation, however, may simply reflect the combined architectures.

PL-08 is primarily directed at organizations to ensure that architectures are developed for the system and, moreover, that the architectures are integrated with or tightly coupled to the enterprise architecture. In contrast, SA-17 is primarily directed at the external IT product and system developers and integrators. SA-17, which is complementary to PL-08, is selected when organizations outsource the development of systems or components to external entities and when there is a need to demonstrate consistency with the organization’s enterprise architecture and security and privacy architectures.

Related controls and activities

CM-02, CM-06, PL-02, PL-07, PL-09, PM-05, PM-07, RA-09, SA-03, SA-05, SA-08, SA-17, SC-07.

Enhancements

  • (01) Security and privacy architectures: Defence in depth
    • Design the security and privacy architectures for the system using a defence-in-depth approach that:
      1. allocates [Assignment: organization-defined controls] to [Assignment: organization-defined locations and architectural layers]
      2. ensures that the allocated controls operate in a coordinated and mutually reinforcing manner
    • Discussion: Organizations strategically allocate security and privacy controls in the security and privacy architectures so that adversaries must overcome multiple controls to achieve their objective. Requiring adversaries to defeat multiple controls makes it more difficult to attack information resources by increasing the work factor of the adversary; it also increases the likelihood of detection. The coordination of allocated controls is essential to ensure that an attack that involves one control does not create adverse, unintended consequences by interfering with other controls. Unintended consequences can include system lock-out and cascading alarms.
      The placement of controls in systems and organizations is an important activity that requires thoughtful analysis. The value of organizational assets is an important consideration in providing additional layering. Defence-in-depth architectural approaches include modularity and layering (see SA-08(03)), separation of system and user functionality (see SC-02), and security function isolation (see SC-03).
    • Related controls and activities: SC-02, SC-03, SC-29, SC-36.
  • (02) Security and privacy architectures: Supplier diversity
    • Require that [Assignment: organization-defined controls] allocated to [Assignment: organization-defined locations and architectural layers] are obtained from different suppliers.
    • Discussion: IT products have different strengths and weaknesses. Providing a broad spectrum of products complements the individual offerings. For example, vendors offering malicious code protection typically update their products at different times, often developing solutions for known viruses, Trojans, or worms based on their priorities and development schedules. By deploying different products at different locations, there is an increased likelihood that at least one of the products will detect the malicious code. With respect to privacy, vendors may offer products that track personal information in systems. Products may use different tracking methods. Using multiple products may result in more assurance that personal information is inventoried.
    • Related controls and activities: SC-29, SR-3.

References

Top of page 
 

PL-09 Central management

Control

Centrally manage [Assignment: organization-defined controls and related processes].

Discussion

Central management refers to organization-wide management and implementation of selected controls and processes. This includes planning, implementing, assessing, authorizing, and monitoring the organization-defined, centrally managed controls and processes. As the central management of controls is generally associated with the concept of common (inherited) controls, such management promotes and facilitates standardization of control implementations and management and the judicious use of organizational resources. Centrally managed controls and processes may also meet independence requirements for assessments in support of initial and ongoing authorizations to operate and as part of organizational continuous monitoring.

Automated tools (e.g., security information and event management tools or enterprise security monitoring and management tools) can improve the accuracy, consistency, and availability of information associated with centrally managed controls and processes. Automation can also provide data aggregation and data correlation capabilities, alerting mechanisms, and dashboards to support risk-based decision-making within the organization. Some central management or enterprise security monitoring tools can collect or create personal behavioural information about system users. This information should be protected as personal information. For insight, organizations should seek advice and guidance from the organization’s appropriate privacy senior officials or executives.

As part of the control selection processes, organizations should determine the controls that may be suitable for central management based on resources and capabilities. It is not always possible to centrally manage every aspect of a control. In such cases, the control can be treated as a hybrid control with the control managed and implemented centrally or at the system level. The controls and control enhancements that are candidates for full or partial central management include but are not limited to: AC-02(01), AC-02(02), AC-02(03), AC-02(04), AC-04(all), AC-17(01), AC-17(02), AC-17(03), AC-17(09), AC-18(01), AC-18(03), AC-18(04), AC-18(05), AC-19(04), AC-22, AC-23, AT-02(01), AT-02(02), AT-03(01), AT-03(02), AT-03(03), AT-04, AU-03, AU-06(01), AU-06(03), AU-06(05), AU-06(06), AU-06(09), AU-07(01), AU-07(02), AU-11, AU-13, AU-16, CA-02(01), CA-02(02), CA-02(03), CA-03(01), CA-03(02), CA-03(03), CA-07(01), CA-09, CM-02(02), CM-03(01), CM-03(04), CM-04, CM-06, CM-06(01), CM-07(02), CM-07(04), CM-07(05), CM-08(all), CM-09(01), CM-10, CM-11, CP-07(all), CP-08(all), SC-43, SI-02, SI-03, SI-04(all), SI-07, SI-08.

Related controls and activities

PL-08, PM-09.

Enhancements

None.

References

None.

Top of page 
 

PL-10 Baseline selection

Activity

Select a control baseline for the system.

Discussion

Control baselines are predefined sets of controls specifically assembled to address the protection needs of a group, organization, or community of interest. Controls are chosen for baselines to either satisfy mandates imposed by laws, Orders in Council, directives, regulations, policies, standards, and guidelines or address threats common to all users of the baseline under the assumptions specific to the baseline.

Baselines represent a starting point for the protection of individuals’ privacy, information, and information systems with subsequent tailoring actions to manage risk in accordance with mission, business, or other constraints (see PL-11). Recommended control baselines are provided in Security and privacy controls and assurance activities catalogue – Baseline profiles (ITSP.10.033-01) for Protected B, Medium Integrity, Medium Availability (PBMM) and Cloud profiles.

The selection of a control baseline is determined by the needs of stakeholders. Stakeholders need to consider mission and business requirements as well as mandates imposed by applicable laws, Orders in Council, directives, policies, regulations, standards, and guidelines. The requirements recommend organizations to select one of the control baselines after the reviewing the information types and the information that is processed, stored, and transmitted on the system; analyzing the potential adverse impact of the loss or compromise of the information or system on the organization’s operations and assets, individuals, other organizations, or Canada; and considering the results from system and organizational risk assessments.

GC discussion

The control baselines in Security and privacy controls and assurance activities catalogue – Baseline profiles (ITSP.10.033-01) are compliant with TBS policies, directives, standards, and guidelines. For guidance on control baselines for national security systems, contact contact@cyber.gc.ca.

Related controls and activities

PL-02, PL-11, RA-02, RA-03, SA-08.

Enhancements

None.

References

Top of page 
 

PL-11 Baseline tailoring

Activity

Tailor the selected control baseline by applying specified tailoring actions.

Discussion

The concept of tailoring allows organizations to specialize or customize a set of baseline controls by applying a defined set of tailoring actions. Tailoring actions facilitate such specialization and customization by allowing organizations to develop security and privacy plans that reflect their specific mission and business functions, the environments where their systems operate, the threats and vulnerabilities that can affect their systems, and any other conditions or situations that can impact their mission or business success. Tailoring guidance is provided in the Cyber security and privacy risk management: A lifecycle approach series.

Tailoring a control baseline is accomplished by identifying and designating common controls, applying scoping considerations, selecting compensating controls, assigning values to control parameters, supplementing the control baseline with additional controls as needed, and providing information for control implementation. The general tailoring actions in the Cyber security and privacy risk management: A lifecycle approach series can be supplemented with additional actions based on the needs of organizations.

Tailoring actions can be applied to the baselines provided in Security and privacy controls and assurance activities catalogue – Baseline profiles (ITSP.10.033-01) in accordance with the security and privacy requirements from the Privacy Act, PIPEDA, and TBS policies and directives. Alternatively, other communities of interest adopting different control baselines can apply the tailoring actions in Cyber security and privacy risk management: A lifecycle approach series to specialize or customize the controls that represent the specific needs and concerns of those entities.

Related controls and activities

PL-10, RA-02, RA-03, RA-09, SA-08.

Enhancements

None.

References

 
Table of Contents
Date modified: