Guideline on Developing a Departmental Security Plan

A consistent exchange of pertinent information should take place during all phases of developing the DSP. Communication and consultation demonstrates that stakeholders have been engaged and that their input and concerns have been addressed. It also demonstrates that authoritative sources have been referenced and considered.

It is important that individuals who are responsible for managing security risks are involved in the SRM process as this will help secure endorsement and support for the DSP when approval is sought. Individuals in all areas of the department can contribute significantly at various stages. They include:

• Program and business managers, corporate services, legal services, and regional offices can provide advice and insight into the business context, matters of strategic importance, legal obligations, internal management protocols and processes, and strategic planning and performance measurement. They can contribute to defining the criteria to be used for evaluating the significance of security risks and into the consequences that could result in the event of a compromise.
• Subject matter experts can help identify and characterize security vulnerabilities and threats to information, assets, services, and individuals and contribute to assessing, evaluating and treating security risks. These experts may include individuals well versed in access to information, privacy, corporate risk management, emergency and business continuity management, human resources, occupational health and safety, real property and materiel management, information management, information technology (IT) and finance.
• The DSO together with departmental security practitioners are best placed to provide advice and guidance regarding the threat environment, the overall security risk management process, and security risk treatment options. They can help determine the most appropriate tools to be used in assessing risks (e.g., Threat and Risk Assessments (TRAs), self assessments, other), interpret the results of these risk assessments and provide guidance on what priorities should be in the DSP. The DSO is also responsible for developing, implementing, monitoring and maintaining the DSP and for managing the departmental security program. As such, the DSO is likely to be the central point of coordination for departmental security planning and security risk management. Their responsibilities may include:
  • Defining the approach, resources and capabilities necessary to develop the DSP
  • Coordinating with stakeholders including program managers, departmental planners, subject matter experts, and other individuals involved in the development of the plan
  • Developing the plan including integrating the results of consultations, risk assessments, etc., and
  • Seeking guidance from the ADM champion and supporting executive committees.

Governance is a key element of the consultation as it provides structure and process to engage senior managers, formalize decision-making, and sustain momentum during the planning lifecycle. It may be useful to identify an executive level champion to initiate the development of the DSP and to be a conduit of information and decision-making with the departmental governance structure (i.e., within key departmental standing committees). Including the DSP as part of the management agenda is also a way to ensure that it is results-based and aligned with the business activities and priorities of the department.

All those involved in developing the DSP or conducting SRM should be familiar with key departmental documents that establish the mandate, program structure, priorities, and commitments of the department. Together these documents provide an integrated view of the business environment and will help orient and align the development and implementation of a DSP. They include:

• Instructions to Departments for Developing a Management, Resources and Results Structure
• Departmental Report on Plans and Priorities (RPP)
• Departmental Performance Report (DPR)
• Integrated Business and HR Plans
• Investment Plans
• Policy on Internal Audit, and
• Office of the Auditor General and internal audit reports.

Risk management is an integral component of good management, good planning, and decision-making at all levels. It is evident in virtually every public and private sector organization. SRM is a component of an overall risk management practice. It is an ongoing and iterative process of analyzing and coordinating of activities for controlling security risk. These include identifying and assessing security risks to essential resources (information, assets, individuals, and services) that a department depends on to deliver programs and achieve its business objectives, and implementing measures to reduce security risk to an acceptable level. SRM is important because it links departmental security to the broader management, business planning, and corporate risk management activities, can help build a stronger culture of security, and enable the department to identify and deal with security issues proactively.

Security risks that are not mitigated can impact a department at any level. At the corporate level, they may impede the department from achieving its strategic outcomes. At the program level they may impact the achievement of expected results or service delivery imperatives. At the operational level, they may compromise the confidentially, availability or integrity of departmental information and assets, or expose individuals to workplace violence. SRM should be logically and practically connected to all levels of program activity in order to develop a holistic view of departmental security both in terms of how it enables or impedes the achievement of business objectives. Figure 2 - Integrated Security Risk Management illustrates the relationship between departmental, program, and operational activities and security risks to help frame the SRM process.

The SRM process described in the remainder of the guideline deals with initial risk, that is, risk before it has been mitigated. This approach has been taken to help ensure that all risks, including residual risk (i.e. risk after treatment) are identified and documented. In this way, departments will be able to successfully develop an integrated view of all security risks to the department and determine treatment options in consideration of overarching business and legal obligations.

Figure 2 - Integrated Security Risk Management⁸

Text version: Figure 2 - Integrated Security Risk Management

7.2.1 Setting the context

Setting the context is the first activity of the planning cycle. It is an important aspect of planning as it will allow the department to gain insight into its strengths and weaknesses as well as opportunities and threats posed by the environment within which the department operates. Context analysis focuses mainly on the macro environment both internal and external to the organization. This analysis will help to determine how security interacts with internal operations of the department in order to articulate the role that security plays in enabling the department to achieve its goals as well as helping to identify the parameters and constraints within which security risks should be managed.

The departmental business objectives are the most important driver of the DSP and for the subsequent steps in the SRM process. They are the basis of arguments that may be used to develop any business case for change, will help prioritize initiatives based on business requirements, and establish a common basis for consultations and managing the expectations of partners and stakeholders.

Business Context

Defining the business context should begin with a review of the department's mandate, priorities, strategic outcomes, program activities, and program sub-activities. The departmental PAA, RPP and DPR are useful sources for gathering this information and will help orient and align the development and implementation of a DSP. The PAA in particular provides a structured inventory of all departmental programs⁹ and depicts them according to their logical relationships to each other and the strategic outcome(s) to which they contribute. The RPP will be useful for defining the legal and policy framework and obligations. Opportunities to use available information and create linkages with specialists in corporate risk management and departmental planning should be explored as this type of analysis is something typically undertaken by those areas.

The business context can also be used as the basis for identifying the information, assets, individuals and services associated with the program activities and sub-activities, and for describing how their protection enables the department to achieve its mission. This will help structure and scope risk assessments to ensure they are associated with the context of the department's overarching mandate and later in the process, can aid in determining priorities for treating security risks.

Organizational Context

An analysis of the organizational context involves examining the internal workings of the department to identify how individuals and groups operate in order to achieve business outcomes. It considers factors such as the number of employees, location of facilities, management practices and authorities, core competencies (knowledge and skills), technologies, and administrative processes. This analysis will help to define the department's policies, operations, and the strategies that are in place to achieve business objectives, and will provide insight to the capabilities, limitations, perceptions and values of internal stakeholders.

Organizational contexts will vary significantly between departments depending on the size and complexity of the business. Some departments have only a few business lines that are performed in a single office location and supported by streamlined processes. Other departments are characterized by numerous program activities and sub-activities that involve thousands of people located across the world, are supported by complex processes and decision making authorities, and involve a broad range of skills and competencies.

Security Context

The security context provides an overview of the departmental security function and its operations including the constraints and requirements derived from legal, regulatory, policy, contractual, and other obligations. It also explains the threat environment within which security activities are conducted.

An analysis of the security context should consider the relationship between the departmental security and other internal management practices as defined in the organizational context, in order to explain how these activities work in concert to protect departmental resources¹⁰ and support the business of the department. All departments are exposed to a certain level of security threat. For example, the threat of malicious attacks on IT systems is relevant to all departments. However, a limited number of departments are more susceptible to internal espionage or sabotage. These threat characteristics also define and influence the departmental security function.

Approach to developing the DSP

The approach to developing the DSP will vary depending on the business, organizational and security contexts of each department. Some departments will choose to develop a single DSP that details all of the key elements described in this guideline. Larger or more complex departments are more likely to develop a DSP that is supported by detailed plans and risk assessments covering identified regions, programs, services, activities or systems.

The approach defined by each department will help scope and establish a framework for organizing the DSP. It should consider the process for developing the plan, the timelines required to develop the DSP, and how the DSP links to or consolidates other plans and risk assessment to provide a complete and coherent view of departmental security requirements. Defining these linkages will also help ensure that the findings and priorities proposed in the DSP can be traced and linked to more detailed findings in a particular plan or assessment where the analysis of risk assessments and treatment options are documented.

Approach to security risk management

SRM occurs within the business, operational and security context of the department and government in general. Defining the departmental approach to SRM forms the basis for communicating the philosophy, values and practices with respect to security management, and defining the criteria for evaluating security risks and making decisions to treat them. Each department is likely to have a somewhat different approach based on corporate risk management practices, the maturity of the security program, security risk exposure and risk tolerance. The SRM process should also identify the authorities responsible for selecting risk treatment options and accepting the residual risks. Typically, the manager responsible for the program, service activity or system would be the responsible authority.

In defining the department's SRM approach, it may be helpful to consider:

• How are the linkages between SRM and the departments' business objectives and policies determined?
• How are decisions made regarding how risk assessments are conducted as it pertains to the methodologies used, processes followed, and timing for conducting or reviewing risk assessments?
• What is the risk criterion by which the significance of risk is defined and assessed to determine whether it is acceptable or unacceptable?
• Who are the responsible authorities for making decisions regarding the treatment of security risks (i.e. corporate security, risk/business owners, senior managers, etc.)?
• How are the results of risk assessments and risk treatments documented for evidentiary purposes?
• How will the results of risk assessments and risk treatment decisions be combined and summarized in the DSP?
• How are SRM activities monitored, evaluated, and reported?

Defining criteria for evaluating the significance of security risks is an essential element of the SRM process. The criteria should reflect the department's values, business context and objectives, and resources. Some criteria may be imposed by or derived from legal or policy requirements. Decision-making regarding the treatment of security risks often requires weighing multiple criteria to decide on a course of action based upon the degree to which the security risk may impede the achievement of business objectives. Since it can be complex, there is no one decision criterion that must be or is always used. Several criteria recur with some frequency. They include cost-benefit, cost effectiveness, level of risk tolerance, views of stakeholders, and consideration of multiple risks. The use of risk criteria will be important at the risk evaluation stage in order to decide if risks are acceptable or unacceptable and how they should be treated.

7.2.2 Security risk assessment

Security risk assessment is the process of identifying, analyzing, and evaluating security risks to determine the significance of the risk and determine whether the risk is acceptable or not and requires treatment. Security risk assessments should be conducted in a methodical and systematic way and may be conducted at any time independent of the overall SRM process. They should be repeated periodically to address any significant changes in the security environment or when a new service or business practice is introduced.

Security risk assessments are typically conducted on IT systems, critical assets and facilities. In order to provide a consolidated view of security risks, risk assessments should also be conducted at the program activity level and consider other factors such as business processes. Deciding how to organize and approach security risk assessment is something each department will need to decide based on their unique operations and program activities. What should remain paramount is that scope and purpose of the risk assessment is aligned with the business objectives of the department so that the results of each risk assessment can be combined to provide an integrated view of security risks to the department and support informed decision-making at a corporate level.

Consideration should be given to the scope of each risk assessment to ensure that it documents at a sufficient level of detail what is at risk (e.g. information, assets, services, individuals, programs) and how it fits into the PAA of the department. The analysis that leads to conclusions should also be documented so that it can be referenced and re-evaluated if necessary. Since it is likely that multiple risk assessments will be conducted and aggregated to provide a department-wide view, consideration should also be given to describing the linkages between risk assessments and how the results can be documented in a way that allows details to be elaborated on and compared.

Security risk assessments do not always need to be a major undertaking and there is no "one size fits all approach. Each risk assessment should be conducted with full consideration of the need to justify the resources used to carry them out. Various tools and methodologies are commonly used and they vary considerably in complexity, objectivity and subjectivity, the quality of results they yield, along with the relative level of expertise required to use or conduct them. Some commonly used methodologies include: TRAs, audits, Business Impact Analysis (BIA), Privacy Impact Assessments (PIA), self-assessments, monitoring, security investigations, and vulnerability assessments. As some of these will generate the same or similar risk information, departments should endeavour to avoid duplication by requiring that these activities be coordinated and that the information garnered from them be shared (in accordance with laws and policies dealing with the collection, use, disclosure and retention of information). Opportunities to collaborate or use risk assessments produced by other areas (e.g. IT services, corporate risk management) should also be explored.

Departmental level security risk assessments are generally very broad in scope and concentrate on strategic risks related to program activities and their related resources and services. Although they lack the detail of more focused risk assessment that may be devoted to a single facility, network or system, departmental assessments establish a broad contextual framework and a solid foundation for the security program, and will help identify the need for additional program and system level risk assessments and/or prioritize individual risk assessment projects.

Risk assessments for programs or resources that do not represent any specific risk to the organization can be combined, conducted without requiring significant or specialized resources, and documented in a concise manner. Risk assessments of programs or resources that have similar operating environments and security concerns can in many cases be conducted using "generic" risk assessments that can be reused. Programs or resources that are considered at higher risk or higher value will warrant more rigorous and in-depth analysis that are supported by sophisticated methodologies. Conversely, less effort need be expended on the examination of lower value assets, less significant threats and more obscure vulnerabilities.¹¹

Risk identification

Identifying security risk is a multifaceted exercise. It involves the identification of risk sources (as a function of threats and vulnerabilities) and their potential consequences. The aim of risk identification is to generate a comprehensive list of security risks that impact departmental resources¹², thereby affecting the achievement of business objectives. Developing a comprehensive inventory of risks (initial risk) is important because risks that are not identified will not be included in further analysis. Identification should include risks whether or not their source is under the control of the organization, even when the risk source or cause may not be evident or the risk may currently be adequately mitigated. An example of risks that are not under the control of the organization might be malicious attacks on information systems resulting in denial of services.

Security threats typically fall into three categories: deliberate, accidental or natural hazard. They may be generic or specific and require analysis on a case-by-case basis. Relevant and up-to-date information is important in identifying risk sources. Some methods to consider in defining risk sources include brainstorming, acquiring threat and vulnerability information from lead security agencies (LSAs) or other sources, and consulting with people who have appropriate knowledge such as corporate risk managers, program and system owners, and other stakeholders.

Some examples of security risks common to most departments include:

• Financial and non-financial losses resulting from theft, destruction or vandalism of physical assets
• Fraud, network damage,  disclosure, misuse resulting from insider threats
• Harm to employees or their families whose jobs expose them to increased risk of workplace violence (e.g. contact with the public, exposure to volatile or unstable people, guarding valuable assets, etc.)
• Interruption to service delivery due to loss or unavailability of human resources (e.g. affected by pandemic flu, extreme weather conditions, natural disasters)
• Compromise of sensitive information or assets shared with business partners or service providers due to inadequate application of security controls
• Financial and reputation costs related to data breaches or loss of information integrity
• Interruption to critical service delivery due to natural disaster or cyber attack affecting critical infrastructure or communications

Given that this is not an exhaustive list each department should take steps to identify risks that may be unique to their own business and operating environment.

Risk analysis

The purpose of risk analysis is to assess the likelihood and impact of security risks that could affect the achievement of strategic and business outcomes. It involves understanding the nature and severity of the risk and provides the information and analysis necessary to decide whether or not risks need to be treated, and on the most appropriate risk treatment approach. The analysis process is typically supported by the use of various models and tools and can be conducted at varying levels of detail depending on the risk and the information available. Tools may use qualitative or quantitative approaches, or a combination of both.

Following are examples of qualitative matrices that can be adapted by departments to aid in the analysis process. These examples demonstrate a simple way of assessing impact and likelihood to help assess the severity of the risk. They can be expanded by adding rows or columns and customizing descriptions to the department's decision making criteria. These examples do not advocate a particular dimension and departments are encouraged to adapt such matrices to be consistent with other internal risk analysis practices (i.e. those used by corporate risk management). This will help compare and assess risks using a common tool and point of reference.

Examples of Qualitative Risk Analysis Matrices

Figure 3 - Sample Risk Matrix

Text version: Figure 3 - Sample Risk Matrix

Risk Evaluation

Risk evaluation is the process of determining whether the risks are acceptable or unacceptable and need treatment. These decisions should be guided by established risk criteria and be made by the person(s) with the appropriate authority. Decisions should also take into account the context of the risk, the tolerance of the department, risk owners and other stakeholders that may be impacted by the risk.

If the level of risk is determined to be acceptable, it may be accepted with no further treatment. Risks that are determined to be acceptable should still be documented, monitored and periodically reviewed to ensure they remain acceptable.

If the level of risk is determined as unacceptable, options for treating the risk should be identified. These may include reducing the risk, avoiding the risk, or transferring the risk.

Risk reduction may be achieved by implementing controls to effectively reduce or eliminate the risk. Controls that most effectively reduce risk at a reasonable cost to the department are the controls that are most likely to be recommended for implementation.

Risk avoidance may be achieved by not undertaking any activity that is likely to trigger the risk. It may not always be a practical option but can form an important part of the overall consideration of how to manage the risk and may form part of the treatment option.

Transferring risk may be achieved by moving the responsibility to another party or sharing the risk through a contract, partnership, or joint venture. Note that new risks may arise from transferring the risk if it is not adequately managed by the party to whom the risk is transferred.

Some risk evaluations can lead to decisions to undertake further analysis. The evaluation, along with the reasons or rationale for arriving at the decision, should be documented to provide a record of the thinking that led to the decision as it will provide useful context for future risk assessments.

7.2.3 Security risk treatment

Decisions on how to treat security risks are management's prerogative. The criteria defined as part of the department's approach to SRM along with legal, policy, or regulations by which the department is bound, will serve to guide decision-making. The willingness of the department to accept or manage risk will also be a factor in decision making. The risk remaining after security controls have been applied or a decision has been made to accept the risk is known as residual risk.

Security Risk Treatment Decision

For each security risk, the DSP should record the decision regarding the selection of risk treatment option (e.g. reduce, avoid, transfer). Security risks for which the selected treatment option is to avoid or transfer should detail the mechanisms that will be used to adequately manage the risk and ensure on-going monitoring.  

Security Control objectives

Security control objectives are the desired result or purpose to be achieved by treating security risks. They serve to guide the selection of controls to treat the risk along with the determination of performance indicators to measure the achievement of the objective.

Security control objectives should be defined for each security risk that is evaluated as unacceptable and for which the selected treatment option is to reduce the risk. The control objectives form the basis for measuring the effectiveness of controls at managing security risks.

Security Controls

Security controls are those administrative, operational, technical, physical or legal measures applied to manage and reduce security risk to an acceptable level. They should be selected and implemented for each risk for which a control objective has been determined. Controls may be categorized as common government-wide controls or department-specific.

Common government-wide controls are defined in Appendix C of the DDSM and apply to all aspects of departmental security. These controls are related to activities that include:

• Information Assurance
• Security Screening of Individuals
• Physical Security
• IT Security
• Security in Contracting
• Sharing Information and assets with other organizations or departments
• Obtaining Security Services from other organizations
• Security awareness
• Security Training
• Security incident management
• Protection of employees from workplace violence
• Security inspections
• Administrative investigations related to security incidents
• Security in emergency and increased threat situations
• Business continuity planning

Department-specific controls are defined by the department based upon their business objectives. As such they are likely to be unique to each department. While they may be articulated at a very high level in the DSP, they provide a framework for identifying more specific controls unique to the department. This will typically be necessary for departments that need to achieve a greater level of security based upon their particular operations or other constraints. An example of a department-specific control might be "protective measures to safeguard employees outside of the work environment due to the increased security risks to which they are exposed. When defining controls unique to the department, it is important to keep in mind the impact that applied controls could have on other government departments.

The selection of controls should be aimed at achieving the control objectives identified in the previous step. It should involve balancing the costs and efforts of treating the risk against the benefits to be derived and compliance requirements. Any opportunity to minimize resource requirements while maximizing benefits to the department should be considered.

The PGS, DDSM and associated standards identify security controls that are intended to maintain a general operating environment that is suitable to most programs, services, activities or systems. Depending on the nature and level of risk to be treated, departments may choose to apply additional controls to address their unique or heightened requirements. Security controls may also be found in various guidelines produced by lead security agencies (LSA) based on their area of expertise. These include: Royal Canadian Mounted Police (RCMP) for physical security, Communications Security Establishment Canada (CSEC) for information technology security, Public Works and Government Services Canada (PWGSC) for contract security, Public Safety Canada for emergency management and business continuity planning, and Treasury Board Secretariat (TBS) and Canadian Security and Intelligence Service (CSIS) for security screening of individuals.

Performance Indicators

Performance indicators are the basis for assessing the effectiveness of controls at achieving control objectives. Through the systematic and ongoing process of collecting and analyzing performance indicators, departments can assess and report on how well controls are doing at achieving intended results.

A performance indicator can be quantitative or qualitative. Quantitative performance indicators are composed of a number and a unit. The number indicates the magnitude (how much) and the unit gives the number its meaning (what), e.g. the number of documented cases of theft. In contrast, qualitative indicators are more subjective or relative, e.g. assessment of the quality of an investigation. As much as possible, qualitative indicators should be summarized into a rating scale, e.g. research quality is rated as "excellent," "average," or "below average."¹³

A minimum of one and maximum of three performance indicators should be identified for each control to help ensure that the amount of information to be tracked, collected and maintained remains manageable. When selecting or developing performance indicators, it is important to consider:

• Will the performance indicator clearly demonstrate and appropriately reflect the achievement of control objectives?
• Are the performance indicators simple and easy to measure?
• Is it possible to use information that is already available in the department, other departments, statistical agencies, international organizations, etc.?
• Can the performance indicators be tracked and compared over time to allow for year-to-year comparisons?
• How difficult or expensive will it be to capture the information?

For each performance indicator, it is important to identify:

• Sources of data or information to be captured, created, or available on a regular basis
• Frequency at which the data will be collected and evaluated (e.g. annually, biannually, monthly), and
• Targets (or level of success) to be achieved within a specified time.

The TBS document entitled Instructions to Departments on Developing a Management Resources and Results Structure provides good guidance on developing performance indicators and can be referenced for further information. While security performance indicators are unlikely to be added to the departmental PMF as this level of detail is usually not captured as part of the PAA, it may be useful for achieving consistency.

Gap Analysis

The purpose of assessing gaps is to identify security control objectives that remain unmet, for which controls need to be implemented, improved, or otherwise adjusted, and/or for which performance indicators have not yet been established. It will help confirm which risks are already being managed to an acceptable level. For each identified risk that has been determined to be unacceptable and for which a control objective(s) has been identified, a gap analysis should seek to determine:

• Are controls currently in place to achieve the control objective and manage security risks?
• Are the controls effectively managing the risk and achieving the control objectives (as demonstrated by the performance indicators)?
• Are the performance indicators sufficient / appropriate for measuring the effectiveness of the control?

The results of a gap analysis form the basis for establishing a list of relative priorities for implementing additional controls and establishing performance indicators. They may also indicate where controls may be deemed excessive and should be reduced, eliminated or otherwise replaced.

Priorities

Priorities should focus on broad areas that are critical to the success of the department or to ensure compliance with legal and policy obligations. A determination of priorities should be confirmed against known and stated departmental priorities and it may be helpful to consult with other internal stakeholders to determine opportunities for alignment or collaboration. As there are always many more issues vying for attention than there are resources to address them, it may be helpful to consider:

• Is the security priority linked to departmental priorities and strategic outcomes?
• Does this priority address compliance requirements defined in policy, legislation, contractual or other obligations?
• How does this priority relate to government priorities?
• What are the availability or limitations of departmental or government resources?
• Does this priority address stakeholder expectations or possible negative consequences to reputation?
• Have opportunities to collaborate with, or consolidate priorities with other departmental plans and initiatives been considered?
• What is the residual risk that will remain if the risk remains untreated and how will it be addressed?

7.2.4 Implement, monitor and update

The final stage in the SRM process involves elaborating a strategy to implement security controls and performance indicators, monitor progress, and report on results achieved. An implementation strategy is a means to manage process and resources, focus on the achievement of desired outcomes, and strengthen partnerships with departmental stakeholders, and focus on assessing the achievement of outcomes. The details of implementation are what is typically captured in work plans and project plans.

Implementation Strategy

An implementation strategy details activities and assigns responsibility to specific individuals for accomplishing those activities. It also establishes timelines, estimates resource requirements, and describes how progress will be assessed and monitored. Consultation remains important in developing an implementation strategy as it affords a means to align goals, timelines, and resource requirement with other departmental plans.

A typical implementation strategy will identify:

• short term (one - two years) and long term (three - five years) goals for implementing security controls and performance indicators, in line with established priorities
• activities, roles and responsibilities for implementing additional controls and establishing performance indicators (where each activity may in turn be translated into a number of specific work plans)
• timelines and milestones to sequence activities
• resources necessary to implement controls and monitor their effectiveness¹⁴; and
• risks and controls that will remain during the transition period.

Monitoring

Monitoring entails gathering and analyzing information to gauge progress in implementing controls and establishing performance indicators, to ensure that planned activities and implementation of controls remain on schedule and within allocated resources. It also entails monitoring the effectiveness of the controls at achieving control objectives (using the performance indicators). Managers at all levels and security practitioners have a responsibility for monitoring the implementation and effectiveness of security controls and reporting accordingly to the DSO¹⁵.

Monitoring can also include maintaining an awareness of the threat and operating environment so that emerging risks can be identified, assessed and managed on an ongoing basis. Regular consultation with stakeholders and risk owners should help in maintaining awareness of changes to the business of the department and periodic environmental scanning will aid in monitoring the threat environment. Consulting with risk owners is also an opportunity to inform them of progress, and seek decisions should any changes be required. As with previous steps, the results of monitoring should be documented for evidentiary purposes and used to facilitate reporting progress to senior management.

Consideration may be given to whether or not an independent review (audit) would be useful for evaluating the effectiveness of the SRM process and activities along with progress at implementing the DSP. Any such plan should be consulted internally, undertaken with the awareness of associated costs, and balanced with other departmental audit and evaluation priorities.

Reporting

Periodic reporting is useful for seeking management input or decisions to address emerging issues and an opportunity to demonstrate progress towards expected results. Reporting improves decision-making by assessing both successes and failures, monitoring the use of resources, and disseminating information on best practices and lessons learned. Departments should evaluate the effectiveness of their SRM processes on a periodic basis¹⁶ to facilitate learning and continuous improvement.

Reporting should be based on reliable and accurate information to demonstrate that planned activities are achieving expected results effectively and efficiently. Providing that findings and decisions have been documented throughout the SRM process, and progress information gathered through monitoring activities is recorded, reporting need not be an arduous task.

Update

The DSP and supporting risk assessments should be updated and revised regularly or when circumstances change significantly.

A well-prepared plan demonstrates that managers have thought through the business of the organization, understand what they need to achieve to support that business, and how to accomplish it. The DSP formalizes the linkage between business objectives and the management of security risks to achieve those objectives. It supports the deputy head and senior managers in achieving management excellence by providing a means to identify and manage operational security risks proactively.

The DSP details decisions for managing security risks based on their relative priority, timelines for implementing additional controls to improve departmental security, and performance indicators to evaluate the achievement of results. While the management of all security risks are within scope of SRM, the DSP should concentrate on those risks that have the most potential to impact the department's ability to fulfill its mandate, significantly impact human or financial, resources, may prevent compliance with security requirements outlined in policy or legislation, or may result in disruption of critical services.

The DSP is a strategic document that provides the deputy head and senior managers with "an integrated view of security risks to the department. While it is understood that the format and structure of the document, along with any evidentiary documents may vary from one department to another, the following template is recommended to help ensure that elements of a DSP remain somewhat consistent from one department to another and reflect the results of SRM.

The DSP can also be used as the basis for developing annual work plans and project plans that support the implementation of department-wide security goals and objectives approved in the DSP.

The first three sections are intended to provide the reader with an introduction and orientation to the DSP itself. The remaining sections map to the SRM process and the requirements of the PGS and DDSM.

7.3.1 Evidentiary Documents

All security risks should be documented in evidentiary documents used to record the analysis and findings of each step in the SRM process. Together with appropriately documented polices and processes they establish a record of SRM activities for ongoing reference, review and decision-making and can be used to guide the day to day SRM activities. Evidentiary documents could include:

Security risk management process

• Establishes the department's approach to SRM and may include policy, procedural, and practical descriptions for assessing, evaluating, treating and monitoring security risks
• Establishes the department's criteria for deciding if security risks are acceptable or unacceptable (tools, methodologies, etc.)
• Explains relationship between DSP and evidentiary documents

Security environmental scan

• Analysis of the internal and external threat environment and assessment of the department's current risk exposure

Communication and consultation report

• Documents the approach to and/or results of consultations with internal and external stakeholders

Departmental Security Program documentation / policy

• Document(s) describing the departmental security program activities and management practices related to all aspects of departmental security.
• Describes governance, delegation, coordination and reporting mechanisms within the security program, and between the security program and other groups with security related responsibilities (e.g. emergency preparedness, occupational health and safety, IM, IT, regions, etc.), and security services provided by or to another party, such as a portfolio department or shared services provider

Security risk assessment reports

• Details the results of security risk assessments together with their analysis and decisions on how those risks are to be managed based on the establish SRM criteria
• This information may also be captured in a Security Risk Register (SRR) (see below)

Security risk treatment reports

• Detailed analysis and decisions related to the selection of risk treatment options, the identification of control objectives, the selection of controls and performance indicators, the conduct of gap analysis and the establishment of priorities
• This information may also be captured in a SRR (see below)

Security Performance Measurement Framework

• Describes roles and responsibilities, tools, methods, processes, and frequency for evaluating the performance of the security program, assessing the effectiveness of SRM practices, assessing effectiveness of controls at achieving control objectives, and reporting to senior management

Annual Work Plans and Project Plans

• Describes focussed activities and assignments that support the implementation of priorities approved in the DSP along with activities related to the administration of the departmental security program.

7.3.2 Security Risk Register

A risk register is a tool commonly used by many corporate risk managers and by some security organizations to document the results of risk management. A SRR is used to record the results of SRM. This type of tool may be referred to as a corporate risk register (CRR), secuard, or security risk log. A SRR can be used to record the same information as may otherwise be documented in some of the evidentiary documents described above (policy type documents excepted) A comprehensive SRR would capture the details of risks that have been identified, together with their analysis and plans for how those risks are to be treated. One of the advantages of a SRR is that it provides a means to consolidate and synthesize a great deal of information in a relevant, consistent, and concise manner, and allows for comparisons across multiple programs to support decision-making.

A SRR can be maintained as a simple document in a word-processing or spreadsheet format, or can be developed as database. An example of a SRR in the form of a table is shown in Appendix C - Sample Security Risk Register.

Evidentiary documents and the SRR should be updated on a routine basis, including instances where emerging information or issues would make it appropriate, there are changes or adjustments in the business or security exposure of the department, or updates to the departmental PAA.