rcmp threat risk assessment methodology

• Skip to main content
• Skip to "About this site"

Language selection

• Search and menus

Harmonized threat and risk assessment (TRA) methodology . : D96-7/2007E-PDF

"The Harmonized Threat and Risk Assessment Methodology is designed to address all employees, assets and services at risk. Furthermore, it is easily integrated with project management methodologies and system development life cycles. Analysis may be performed at any level of granularity, from broadly based departmental risk profiles to more tightly focused examinations of specific issues, to meet management needs for responsive solutions at both strategic and operational levels. Use of common tools can promote interoperability when managing risks across shared facilities and interconnected information technology systems, an increasingly important consideration when service delivery responsibilities transcend organizational boundaries. Finally, in the spirit of Modern Comptrollership, objective metrics and analytical reports support the Management Accountability Framework to assess results and performance, especially with respect to risk management, stewardship and accountability"--Executive overview, EO-3.

Permanent link to this Catalogue record: publications.gc.ca/pub?id=9.845156&sl=0

• MARC XML format
• MARC HTML format

Request alternate formats

• Skip to main content
• Skip to site information

Language selection

Harmonized tra methodology (tra-1).

" TRA-1 - Tool TRA-1 - A-5: Sample Statement of Work for TRA Consulting Services TRA-1 - A-6: Sample TRA Work Plan TRA-1 - B-2: Asset Listing TRA-1 - B-5: Asset Valuation Table / Statement of Sensitivity TRA-1 - C-2: Threat Listing TRA-1 - C-4: Threat Assessment Table TRA-1 - D-2: Vulnerability Listing TRA-1 - D-4: Vulnerability Assessment Table TRA-1 - E-2: List of Assessed Residual Risks TRA-1 - F-2: Safeguard Listing TRA-1 - F-5: Recommendations Table TRA-1 - F-6: Outline TRA Report) TRA-1 - G-1: TRA Worksheet "

• Publisher - Current Organization Name: Communications Security Establishment Canada
• Publisher - Organization Section Name: Canadian Centre for Cyber Security (CCCS)
• Licence: Open Government Licence - Canada

Data and Resources

• More information
• Go to resource

Threat Risk Assessment (TRA) for Physical Security

• First Online: 01 June 2021

Cite this chapter

• Darek Baingo 11  

Part of the book series: Advanced Sciences and Technologies for Security Applications ((ASTSA))

444 Accesses

3 Altmetric

Maintaining the physical security of an organization entails navigating an intricate landscape of threats, adversaries, systems, and policies. As organizations evolve, become more complex and spatially distributed, security risks increase exponentially and become difficult to fully understand. Organizations entrusted with critical missions and ownership of high risk/high value assets realize that physical protection systems and policies are crucial to prevent unacceptable consequences arising from harmful influences, whether deliberate, accidental or natural. The more serious the consequences, the more important it is to have a high degree of confidence that physical protection will be as effective as planned. The highest level of confidence in physical protection is best achieved through the design and implementation of protective measures that are linked to a thorough understanding of the threats and vulnerabilities. This is achieved through comprehensive and up-to-date analysis of the motivations, intentions, and capabilities of potential adversaries against which protection systems are designed and evaluated. This chapter presents the conceptual development of a Threat Risk Assessment (TRA) Methodology for physical security planning and design. The methodology addresses critical knowledge and capability gaps in TRA approaches, and aims to strengthen the transparency, robustness and defensibility of an organisational Security Risk Management program. The chapter concludes with a discussion of lessons learned and recommendations for future work.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info
• Durable hardcover edition

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Harmonized Threat Risk Assessment Methodology (2007) Ottawa, Royal Canadian Mounted Police, Communications Security Establishment (TRA-1), Available at: https://cyber.gc.ca/en/guidance/harmonized-tra-methodology-tra-1 . Date accessed on 22 Jan 2021

Morris R, Bureaux J, McDonald S (2017) A comparative review of the threat risk assessment methodologies, defence research and development Canada, DRDC-RDDC-2017-C130

Google Scholar  

Facility security plan: an interagency security committee guide, 1st edn, US, 2015-02, Interagency Security Committee (ISC)

Reference manual to mitigate potential terrorist attacks against buildings, 2nd edn, 2011-10, Department of Homeland Security.

Hazard identification and risk assessment workbook, Toronto, Ontario, 2012, Emergency Management Ontario

The design-basis threat, an interagency security committee report, 9th edn, US, 2014-08, Interagency Security Committee (ISC)

Risk management process of federal buildings, 2nd edn, 2016-11, Interagency Security Committee (ISC)

Guide for conducting risk assessments, Gaithersburg, Maryland, 2012 Sept, US Department of Commerce, National Institute of Standards and Technology

Assessing and managing the terrorism threat, Washington, DC, 2005, US Department of Justice

Canadian Armed Forces (2007) B-GJ-005-314/FP-050 CF force protection assessment guide (FPAG). National Defence, Ottawa

ISO 31010:2019 Risk management–risk assessment techniques, International Organisation for Standardisation, 2019

Threat and hazard identification and risk assessment guide—comprehensive preparedness guide, 2nd edn, Aug 2013, Department of Homeland Security

National institute of building sciences, whole building design guide (WBDG) methodology: https://www.wbdg.org/ . Date accessed on 20 Jan 2021

Baingo D, Friesen SP (2020) Threat risk assessment implementation project, defence research and development Canada, DRDC-RDDC-2020-L226

Morris R, Bureaux J, McDonald S (2018) Draft methodology for the development of a DND/CAF national design basis threat assessment, Defence Research and Development Canada, DRDC-RDDC-2018-C238, Dec 2018

Morris R, Bureaux J, McDonald S (2018) Procedures for the selection and prioritization of DND/CAF installations for baseline TRA conduct, Defence Research and Development Canada, DRDC-RDDC-2018-C273, Dec 2018

Field Manual 3-37.2 Antiterrorism, headquarters department of the Army, Feb 2011. www.us.army.mil . Accessed on 12 Oct 2020

Download references

Author information

Authors and affiliations.

Centre for Security Science, Defence R&D Canada, Ottawa, Canada

Darek Baingo

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Darek Baingo .

Editor information

Editors and affiliations.

College of Public Health, University of South Florida, Tampa, FL, USA

Anthony J. Masys

Annex A: Comparative Analysis of TRA Methodologies

This Annex contains the comparative descriptions of TRA methodologies as related to each phase of the baseline HTRA using the metrics identified in Sect.  2 .

Requirement and Scope Definition Phases

2.1 requirements.

There was a wide variance in how assets were identified and classified/categorized between the various methodologies. However, the requirement to conduct a TRA falls out of policy direction, which should be based on specific criteria, such as:

large capital project definition, development and delivery;

system development; and

establishment of an organisation’s baseline.

The establishment of a baseline TRA for critical infrastructure, equipment, personnel, information etc., is widely recognized as a best practice. Once a baseline TRA has been completed, the requirement to revisit or revalidate a TRA may be caused by any number of “triggers”. Roles and responsibilities to identify and act upon these triggers also need to be instituted. Triggers include but are not limited to:

change in any aspect of threat;

changes in asset inventory or purpose;

identification of safeguard failures; and

a cyclical review process.

Whether the TRA model under development will be used for IT system implementation and maintenance is unclear and requires resolution. What is clear is that all TRA models in use need to use the same terminology and key definitions, and reporting should be funnelled through a central national level OPI via the appropriate chain of command.

2.2 Scope and Definition

Scalability of a TRA methodology was deemed to be of critical importance. It is clear that a TRA may be required for various reasons, and at various levels within the organisation. This means that a TRA may be required for a single asset (e.g., high value stand-alone building), at a regional/international level or strategically. Similar to the aforementioned need to clarify the organisational policy regarding the requirement to conduct a security risk assessment, clear policy direction regarding the responsibility for determining the scope and definition is also required. It is important that local staff be engaged for their input during this phase, as incorporation of local knowledge during this phase will be valuable in ensuring that the correct assets are being assessed for the right reasons.

Asset Identification and Valuation Phase

3.1 asset identification.

During the brainstorming sessions, the question as to whether to include both tangibles and intangibles as assets in the new methodology was debated at length. Among the models reviewed, only the HTRA identified intangibles (e.g., morale, public confidence etc.) as assets. It was decided that intangibles would be assessed as a consequence or impact, rather than an asset, as part of the new methodology.

There are numerous processes for the identification of assets, and at an even more basic level, how to define an asset. For those models that did identify (tangible) assets, they were usually defined in terms of the following categories:

Information;

Facilities;

Infrastructure (e.g., equipment/systems); and

During the brainstorming sessions, it was determined that for the Departmental methodology, services or capabilities would not be considered as a category of tangible asset; the first four categories are required to provide services, and hence the compromise of these would result in an impact on the ability to deliver of a service.

Several of the methodologies provided lists of assets which served as an aide memoire, providing examples of the various types of assets within each of the categories. Within the department there are already databases of some categories of assets (e.g., personnel, facilities, equipment etc.), that may be exploitable for the purposes of identifying them within a specific geographical location (i.e., base/wing). There was some discussion during the brainstorming sessions that perhaps valuation of an asset in terms of operational criticality should take place first, allowing for identification and selection of critical assets during the scope and definition phase. Using the ISC model’s Facility Security Level (FSL) [ 6 ] as a baseline, the development of a tool for determining and assigning a facility’s (or asset’s) value, is worthy of consideration.

3.2 Asset Valuation

There were two main focuses of the various methodologies reviewed in terms of asset valuation. One approach was to define the criticality of the asset using various language ladders or parameters, while the other approach focussed on assigning a value to an asset by determining the impact of its compromise using parameters such as confidentiality, availability and integrity. Both these methods involved some degree of subjectivity. The latter process was much more complex, albeit more granular.

It was stressed during the brainstorming sessions that the removal of as much subjectivity as possible from the asset valuation process was very important. This would indicate that the development of a strategic baseline asset valuation table (which would also require the development of a strategic asset identification table) would be a useful tool, similar to the FSL developed as part of the ISC documentation. However, assigning values to all assets at a strategic level is likely not prudent. Local input into the importance of specific assets needs to be included in the methodology, as local experience and intuition are important aspects of the valuation process. Therefore, a combination of both approaches would likely be of the greatest benefit. Another important consideration in terms of asset valuation is asset redundancy.

Similar to asset identification, the use of current databases for extracting asset values, at least in monetary terms and, likely in other terms as well, may be feasible and should be investigated. Asset valuation may be tied to the BCP process, and more specifically the BIA which identifies critical services albeit from a corporate perspective.

Threat Assessment Phase

Threat assessments were for the most part considered in three broad categories. These are natural hazards, accidents and deliberate threats such as terrorism. When assessing a threat, it is accepted practice that the impact of a threat is considered in relation to the likelihood of the threat actually occurring. Use of word ladders seemed to be an effective method of reducing subjectivity.

Within the Department, the threat picture is continuously monitored, and the products developed (or at least the process used to develop them) should be leveraged for use in TRAs. For this current capability to be leveraged, TRA threat data requirements will need to be defined. The development and use of a DBT product are worthy of investigation, and in fact may be a best practice. This could include the development of a baseline TRA threat assessment template for completion by intelligence circles; collection and inclusion of information from other federal departments on natural hazards such as earthquakes etc., needs to be explored further. For the production of this type of threat product to be generated, roles and responsibilities will need to be assigned both within intelligence circles and for those that would need to be in receipt of these products. Additionally, a “trigger” mechanism to alert that a change in threat (i.e., probability, modus operandi etc.) may require a TRA to be revisited, should be considered for inclusion in the methodology of the future. This would necessitate that the process allows for the variation of threat over time.

Once the baseline threat is developed, it would need to be reviewed and adapted for use at the local level. Other local threat metrics are already produced and should be exploited. Examples include safety reports, security violation reports and PSS reports; the information provided in these types of products should be considered when developing the local threat picture. The local threat picture should also include crime statistics and trends.

The review process indicated that an increased complexity in the threat assessment process resulted in greater scalability and adaptability; careful consideration needs to be given to the scalability and adaptability requirements of the methodology under consideration. Given the confined context of the intended application (DND/CAF versus all of government), a reduction in scalability and adaptability may be entirely warranted, which may then result in a corresponding reduction in the complexity required for the development of threat assessments.

Vulnerability Assessment Phase

All of the methodologies that used a vulnerability assessment phase, used on-site assessments and interviews as a major data gathering process. Assessment of the data ranged from very complex to being of insufficient complexity. Once again complexity could be correlated to what the methodologies were trying to address in terms of assets, and the impact on scalability and adaptability was similar to that of the threat assessment process; a reduction in complexity may be warranted by the reduced requirement for adaptability and scalability in the global sense.

All methodologies used some type of language ladder to define, and in some cases quantify, impacts/vulnerabilities. It is suggested that an adaptation of this process would also work best for the methodology in question.

During the brainstorming sessions, it was clear that there was no requirement to reassess minimum security safeguards; this was captured quite adequately by the PSS. There is a requirement however, to assess whether the minimum safeguards are effective in countering the current threat, thus reducing vulnerability to an acceptable level.

Reviewing PSS results, safety and security reports etc., prior to the conduct of the TRA, may assist in exposing possible vulnerabilities, and provides some measure of the ability of baseline security/safety measures address the threat.

Risk Assessment Phase (and Calculation of Residual Risk)

While these two phases were presented as distinct processes, they both essentially generate the same information; a descriptor of what the risk is after safeguard effectiveness has been factored in. The formulas used are entirely dependent on the processes that have preceded this phase within each methodology. The following three formulas are provided for comparison purposes:

FEMA—the risk assessment integrates the likelihood/probability of the attack (threat) occurring with the probability that a successful attack will produce consequences of a certain magnitude, given the vulnerabilities of the target:

HTRA—this tool uses values for frequency, impact/consequences and a “change in risk” factor (a correction based on predicted changes to frequency and vulnerability).

The DOJ risk is calculated by the following equation:

For Residual risk the HTRA assigns numerical scores from 1 to 5 to asset value, threat and vulnerability, based on their assessed descriptor score of very low to very high. Residual Risk is the product of Asset × Threat × Vulnerability. In both cases it was assessed that these calculations provide a sufficient scale on which to base mitigation decisions. The complexity of the calculation was assessed as very complex.

Risk Mitigation Strategy (Recommendations Phase)

The identification of unacceptable risks and the provision of recommendations to mitigate those risks to acceptable levels, are the critical outputs of the TRA. The method used to determine what constitutes an unacceptable risk varied from a consultative process to the use of a Target Risk Level (e.g., medium) as the acceptable level of risk, hence anything above medium is unacceptable.

The identification of additional safeguards to reduce risk, requires that the personnel used for this process have an in depth and up-to-date understanding of what the possible remedies may include. Additionally, the inclusion of a cost benefit analysis, especially when more than one solution exists, is of significant importance for decision makers.

The ISC use of Facility Security Levels (which could be looked at as facility criticality levels), uses weighted values for various parameters such as facility size, importance, population, replacement value etc., to establish a priority rating for buildings; recommendations from the TRA are assessed against the FSL and additional documentation that lists physical standards for each FSL/residual risk situation.

The use of TRLs, and the incorporation of a process similar to the use of FSLs, as well as the development of a list of corresponding additional safeguards to reduce risk levels to acceptable standards, based on the criticality of the asset, is worthy of further investigation.

Annex B: Localized Design Basis Threat

Overview of the ldbt and use in the tra methodology, 2.1 undesirable events (ue).

The DBT identifies and rates “Undesirable Events” (UEs) based on their likelihood and impact. A UE will fall into one of three categories of threat types; Deliberate , Accidental or Natural , with each UE identifying and defining a specific threat event. Some examples of UE are provided in Table 4 (Deliberate UE), Table 5 (Accidental UE) and Table 6 (Natural UE).

The LDBT represents the UE that are considered relevant to the Assets being assessed for a TRA. The LDBT is based on the Regional DBT which is assessed locally to ensure that the local threat environment is accurately represented. UEs identified in the Regional DBT are evaluated by the TRA Team Leader and appropriate Asset representatives; the resulting UE ratings are applied to the TRA process.

2.2 UE Ratings

Each UE is assessed regionally to determine its relevance to the Unit being assessed and subsequently “localised” to ensure that the UE ratings being used for the TRA represent local influences. As an example, the UE for “Earthquake” may have a higher probability of occurring (and severity/impact) in Esquimalt than Halifax. As a result, this UE may be rated “High” in Esquimalt and “Low” in Halifax. Table 7 provides the values and associated ratings for individual UEs, while Table 8 provides normalised Unit threat values and their associated ratings.

An accurate DBT assessment is critical to the success and credibility of the TRA process. In this methodology, the DBT provides the threat values necessary inform the vulnerability assessment and calculate risk. The TRA team leader should be well versed with the DBT methodology

Annex C: Targeting Analysis

The targeting analysis process uses six Target Selection factors (TSFs) that were developed specifically for the TRA methodology. Care was taken to ensure that TSFs assessed did not duplicate criteria otherwise accounted for in the NDBT and Strategic Asset Type valuation processes

Specific rating criteria have been developed for each TSF. Each rating criteria represents a specific variable associated with susceptibility factors relevant to a specific TSF. Each rating criteria within a TSF contains language ladders which have been designed to remove as much subjectivity as possible; the most accurate descriptor for each rating criteria is selected which will result in a value being assigned. The TSFs developed for use in the prioritization methodology are presented below

TSF 1— Symbolism : Assesses the degree to which an installation symbolises—or may be perceived by an aggressor to symbolise—the Government of Canada (GoC), the Canadian military, Canadian interactions with foreign militaries, or other activities associated with the installation which may represent symbolic targets to an attacker.

TSF 2— Recognisability : Assesses the degree to which an installation’s local and/or regional profile will impact its susceptibility to a UE. An installation’s profile includes its physical footprint, the degree to which it is a visible presence in the community where it is located, and its identifiable attributes.

TSF 3— Accessibility : Unfettered access to an installation and the ability to conduct undetected pre-attack surveillance on it increase its susceptibility to a UE. TSF 3 assesses the ease with which an installation can be accessed by examining the daily access control posture of the installation and identifying factors related to the ease with which surveillance could be conducted. It also examines the installation’s compliance with Departmental Security Policy related to physical security.

TSF 4— Proximity : Examines the susceptibility to a UE related to an installation’s surroundings, including identifying factors associated with the neighbourhood in which the installation is located. Population density can be associated with the amount of pedestrian and vehicle traffic in the vicinity of an installation, increasing potential victims of a UE and/or potential concealment of an attacker. The identification of other potential nearby targets in the vicinity of the installation increases the attractiveness of an attack in the vicinity and accordingly on the installation.

TSF 5— Recuperability : An installation’s susceptibility to a UE is considered to increase as its ability to recover or recuperate from it decreases. TSF 5 assesses the installation’s ability to maintain its core mission by identifying its ability to mount response operations which can mitigate damages and/or injury and by identifying the scale of redundancies available to it, which are necessary to resume regular operations associated with mission accomplishment.

TSF 6— Demographic : Examines the susceptibility of an installation to a UE based on its demographic, including an assessment of military personnel composition, civilian employee composition, visitation/access to members of the general public, and the visit history of foreign military members, dignitaries, or Internationally Protected Persons (IPP).

All 6 TSF ratings for each installation are added together to calculate the Asset’s Targeting Analysis value ( ATv ), which is used in the calculation of the Prioritization Score. A higher ATv represents a higher assessed susceptibility to a UE.

Rights and permissions

Reprints and permissions

Copyright information

© 2021 The Author(s), under exclusive license to Springer Nature Switzerland AG

About this chapter

Baingo, D. (2021). Threat Risk Assessment (TRA) for Physical Security. In: Masys, A.J. (eds) Sensemaking for Security. Advanced Sciences and Technologies for Security Applications. Springer, Cham. https://doi.org/10.1007/978-3-030-71998-2_14

Download citation

DOI : https://doi.org/10.1007/978-3-030-71998-2_14

Published : 01 June 2021

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-71997-5

Online ISBN : 978-3-030-71998-2

eBook Packages : Political Science and International Studies Political Science and International Studies (R0)

Share this chapter

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

• Find a journal
• Track your research

• Skip to main content
• Skip to "About this site"
• Search and menus

Guideline on Developing a Departmental Security Plan

More information.

Terminology:

List of Figures

The purpose of this guideline is to assist departments in meeting the requirements of the Policy on Government Security (PGS) and the Directive on Departmental Security Management (DDSM) to develop a departmental security plan (DSP) that details decisions for managing security risks and outlines strategies, goals, objectives, priorities and timelines for improving departmental security. It describes an approach to developing the DSP that is based upon a process of security risk management (SRM) to ensure that decisions for managing security risks are substantiated through thorough analyses and supported by processes which are rigorous, repeatable, and documented. This approach is intended to support the development of a DSP that provides Deputy Heads (DH) and senior managers with an integrated view of departmental security requirements that is aligned with the strategic priorities, programs, plans, processes, and other practices within each department.

The guidance is based upon well-recognized principles and best practices related to planning, risk management, and performance measurement. They have been assembled from TB policy instruments and guidelines, reports from jurisdictions, private industry, and other countries, along with standards bodies such as ISO and NIST. The guideline also comprises input from departmental representatives who participated in its development.

2. Audience

The guideline is aimed at departmental security officers (DSO), security practitioners, and managers at all levels. Their specific roles and responsibilities related to departmental security planning and SRM are identified in the PGS and DDSM.

The guideline may also be useful to departmental corporate risk managers, strategic planners, Management Accountability Framework (MAF) coordinators and other subject matter specialists who play an important role in helping to integrate security into corporate risk management, planning and performance measurement practices and whose corporate perspectives should be considered in the development of the DSP.

3. Application

Deputy heads and DSOs of all departments 1 have policy responsibilities related to security planning and SRM. Each department has unique characteristics with respect to mandate, size, programs, internal management processes and practices, along with resources dedicated to security operations. Given these differences each department, including small departments and agencies (SDAs), should determine an approach to developing its DSP that considers their distinct operations, capacity, and risk environment by adopting or adapting this guideline to best suit their business needs.

4. Implementation

The DDSM provides a three year transition period for full implementation of requirements related to the DSP 2 that began July 1, 2009, and will end June 30, 2012. The following sequencing of activities is suggested to help ensure that each step in the SRM process can be completed and the results used as the basis for developing the DSP.

• Analyze and define the context; initiate consultations
• Consolidate results from existing security risk assessment and identify gaps in coverage (i.e. program activities that are not covered by current security risk assessments to address all information, assets, or other resources)
• Identify requirements for additional controls or performance indicators
• Define security priorities based on results of security risk assessments and analysis of treatment options; develop implementation strategy
• Develop DSP and seek DH approval
• Begin implementation and monitor performance
• Conduct and/or complete risk assessments as required to address identified gaps
• Report progress to DH and senior managers
• Update DSP as required
• Continue security risk management activities and implementation and monitoring of controls
• Maintain DSP and report to DH and senior managers

5. An Integrated Approach to Planning

The management of security is most effective when it is systematically woven into the business, programs and culture of a department and the public service as a whole. 3

The concepts of integrated planning and integrated risk management are not new. The Clerk of the Privy Council, in his Seventeenth Annual Report to the Prime Minister on the Public Service of Canada , reaffirmed the importance of integrated planning stating that "planning should be seen as a core business practice for all public servants, one that is necessary to align goals, resources and results. 4 Previous Public Sector Renewal Plans characterized integrated plans as "a foundation for assessing and understanding the current and future needs of departments and the Public Service as a whole. Risk management, since it is directed at the uncertainty related to future events and outcomes, is an integral component of good planning and decision-making at all levels 5 . The Framework for the Management of Risk recognizes that risk needs to be managed at every level of the Program Activity Architecture (PAA) (e.g. all programs down to the sub-sub activity level) and the results aggregated at the corporate level to facilitate priority setting and improve decision-making.

Integration is the act of bringing together plans, activities and processes so that they work in harmony with each other to achieve common business objectives. Alignment is the act of linking short and long-term objectives to the strategic outcomes and program activities of the department as defined in their PAA. Developing an integrated approach to planning can help reveal interdependencies and horizontal linkages of individual activities, opportunities to streamline work processes and operations, and potential for economies of scale. Aligning plans to the business objectives of the department can help ensure that resources can be effectively allocated to achieve strategic outcomes.

In examining best practices of departments with mature security programs, it has been observed that security is firmly integrated into the internal management functions and aligned with corporate planning and risk management activities. Security policies and SRM processes and plans are well documented, tailored to the unique business activities of the department, and include performance measurement as an integral component of planning. Integration and alignment is further supported through strong governance that uses Management Accountability Framework (MAF) elements 6 to establish expectations for good internal management practices and the departmental PAA as the framework for aligning internal management practices with program delivery outcomes.

An integrated approach to planning and risk management requires the active participation of senior managers and internal stakeholders from corporate and program areas. It is achieved through regular and recurring dialogue, a clear understanding of roles and responsibilities, and a commitment to improved planning and risk management practices at all levels within the department.

6. Documentation

Documenting security processes, policies, and plans is a means to establish a common understanding and frame of reference for security terminology, support internal and external communications, define roles and responsibilities, and build the maturity of security and SRM practices. Documenting the analysis and findings of SRM helps ensure that the results are reproducible and provides evidence of due diligence so that anyone, including managers and auditors, can understand the thinking that led to action being taken, and trace those actions to management decisions, plans, and policies.

Documentation should be prepared throughout the process of security risk assessment and security risk treatment to capture the analysis, findings and resulting actions, and provide a basis for review, priority setting, decision-making, and performance measurement. This will help demonstrate the relationship from the selected controls back to the results of the security risk assessment and security risk treatment processes.

While the extent and format of documentation will differ from one department to another given each one's size, complexity, operations, and internal management practices, each department should take steps to establish and maintain evidence of the SRM process and findings that are legible, readily identifiable and retrievable 7 . Such documentation should also remain available to those who need it while respecting any policy, legal or regulatory requirements and contractual obligations to protect and control it. (See Section 8.3 - Departmental Security Plan for further detail on documentation).

7. Process of Developing a Departmental Security Plan

The guidance on developing a DSP is laid out according to the process depicted in Figure 2 Process of Developing a Departmental Security Plan . The process is a hybrid of various planning and risk management models that are described in reference documents used to develop this guideline (Appendix B - References). Each step in the SRM process has been mapped to the mandatory requirements related to the DSP as described in the PGS and DDSM to help ensure that these can be met.

Figure 1 - Process of Developing a Departmental Security Plan

7.1 Communicate and Consult

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.
• 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.

7.2 Security Risk Management

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 8

7.2.1 Setting the context

The DSO ... is responsible for developing, implementing, monitoring and maintaining a departmental security plan (DSP) that ... provides an integrated view of departmental security requirements.

Directive on Departmental Security Management 6.1.1.1

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 9 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 10 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

.. a departmental security plan (DSP) that...identifies security threats, risks and vulnerabilities to determine an appropriate set of control objectives

Directive on Departmental Security Management 6.1.1.2

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. 11

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 12 , 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

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

Directive on Departmental Security Management 6.1.1.3

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." 13

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 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

... outlines security strategies, objectives, priorities and timelines for improving the department's security posture

Directive on Departmental Security Management 6.1.1.4

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 14 ; and
• risks and controls that will remain during the transition period.

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 15 .

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.

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 16 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.

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

7.3 Departmental Security Plan Template

Deputy heads ... approve the departmental security plan that details decisions for managing security risks and outlines strategies, goals, objectives, priorities and timelines for improving departmental security and supporting its implementation

Policy on Government Security, 6.1.3

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.

8. Enquiries

For enquiries regarding this policy instrument, please contact the Security and Identity Management Division .

Appendix A — Definitions

Appendix b — references, federal government.

• Annual Reports to the Prime Minister on the Public Service of Canada
• Auditor General Reports and Publications
• Directive on Departmental Security Management (DDSM)
• Departmental Performance Reports (DPRs)
• Harmonized Threat and Risk Assessment Methodology
• Integrated Planning Guide
• Framework for the Management of Risk
• Management Accountability Framework
• Policy on Government Security (PGS)
• Policy on Management Resources and Results Structures (MRRS)
• Public Service Modernization Act (PSMA)
• Reports on Plans and Priorities (RPP)
• Treasury Board Policy Frameworks
• Treasury Board Policy Suite
• Whole-of-Government Framework

Provincial Government

• Results Oriented Government A Guide to Strategic Planning and Performance Measurement in the Alberta Government
• Government of British Columbia - Enterprise Risk Management (ERM) Guideline (PDF 850 KB)

Other Government

• Australian National Audit Office - Security Risk Management (report number 44, conducted 2008-09)
• Department of Homeland Security - National Infrastructure Protection Plan - Partnering to Enhance Protection and Resiliency (PDF 4.54 MB)
• UK National Risk Register
• NIST Special Publication 800-18 - Guide for Developing Security Plans for Federal Information Systems
• NIST Special Publication 800-30 - Risk Management Guide for Information Technology Systems
• NIST Special Publication 800-37 - Guide for Applying the Risk Management Framework to Federal Information Systems - A Security Lifecycle Approach (Final Draft 2009)
• NIST Special Publication 800-39 - Managing Risk from Information Systems

International References

• ISO 31000:2009 (Final Draft) - Risk management - Principles and guidelines
• ISO/IEC 27001:2005 - Information technology - Security techniques - Information security management systems - Requirements
• ISO/IEC 27002:2005 - Information technology - Security techniques - Code of practice for information security management

Appendix C — Sample Security Risk Register

Scope: (department-level or identification of programs or resources covered by the risk assessment / risk register)

© Her Majesty the Queen in Right of Canada, represented by the President of the Treasury Board, 2017, ISBN: 978-0-660-09751-0

Language selection

• Français fr

Course 508: Harmonized Threat and Risk Assessment (HTRA) Methodology within the ITSG-33

From: Canadian Centre for Cyber Security

Description

In this 3-day course, you will learn about the Threat Risk Assessment methodology using the ITSG-33 ISSIP and CSE’s new ASTRA tool to help you conduct your assessments. The course will further your knowledge of ITSG-33 in a practical application for any Government IT project.

The objectives of this course are to ensure that upon successful completion, the participant will be able to:

• Describe HTRA activities
• Situate the HTRA within the ITSG-33 risk management lifecycle process
• Describe the HTRA activities within the ITSG-33 ISSIP
• Apply the HTRA activities as part of an IT project that follows the ITSG-33 ISSIP

Target audience

Project/Program Managers, IT Security Designers, Architects, Engineers and Managers

Prerequisites

• Course 601 - Introduction to IT security management ; knowledge of GC security risk management is beneficial
• Course 104 - IT security risk management: A lifecycle approach (ITSG-33)

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Thank you for your help!

You will not receive a reply. For enquiries, please contact us .

• Skip to main content
• Skip to "About"

Language selection

My lh learning account, summary of 508 – harmonized threat and risk assessment (htra) methodology within the itsg-33, 508 – harmonized threat and risk assessment (htra) methodology within the itsg-33, course description.

In this 3-day course, you will learn about the Threat Risk Assessment methodology using the ITSG-33 ISSIP and CSE’s new ASTRA tool to help you conduct your assessments.  The course will further your knowledge of ITSG-33 in a practical application for any Government IT project. 

Course Outline

Module 1: htra overview.

• Relate the HTRA to the requirements for the assessment of threats and risks
• Recognise the structure of the HTRA publication
• Describe the phases of the HTRA process

Module 2: HTRA Activities

• Describe the HTRA activities
• Apply the HTRA activities for a variety of mandates

Module 3: Using the HTRA within ITSG-33 ISSIP

• Situate the HTRA within the ITSG-33 risk management lifecycle process
• Situate the HTRA activities within the ITSG-33 ISSIP
• Describe the adaptations that are recommended to use the HRTA in the ITSG-33 ISSIP  

Module 4: Practical Examples and TRA Tool

• Describe the practical examples for the exercises
• Use the TRA tool to complete the exercises

Module 5: Support Project Initiation Phases

• Describe the TRA activities of the ISSIP conducted during the following phases of the generic SDLC process:
• Requirements analysis
• Complete these activities in an IT project

Module 6: Support Risk-based Design

• High-level design
• Detailed design

Module 7: Assess Residual Risks and Reporting

• Describe the TRA activities of the ISSIP conducted during the installation phase of the generic SDLC process

Target Audience

Project/Program Managers, IT Security Designers, Architects, Engineers and Managers

Recommended Prior Learning

• Course 601- Introduction to IT Security Management, Knowledge of GC Security Risk Management is Beneficial
• Course 104 - IT Security Risk Management:  A Lifecycle Approach (ITSG-33)

• Richter app – log in
• Insolvency cases

Threat and Risk Assessments

The challenge.

The cyber threat landscape is constantly changing and evolving. Risks to your organization can come from cyber criminals, hacktivists, state-sponsored actors, and malicious insiders.

Your systems, applications, and networks are constantly being probed by such groups looking for potential weaknesses or gaps in your security posture. What plan do you have to identify and manage these risks before an attacker exploits them? Consider conducting a Threat and Risk Assessment (TRA).

WHAT IS A THREAT AND RISK ASSESSMENT?

A Threat and Risk Assessment (TRA) is designed to be a foundational aspect of an organization’s risk management program. A TRA consists of the following steps:

• Identifying and assigning values to critical assets
• Identifying threats relevant to the identified assets
• Assessing the likelihood and impact of any identified vulnerabilities
• Evaluating the overall risk to the identified assets
• Recommending safeguards to reduce the overall risk

A TRA aims to help you better identify, assess, and manage your information security risks at an enterprise level.

• Evaluates current policies, procedures, and processes for potential gaps
• Identifies opportunities for improvement
• Educates organizational leaders on emerging threats and trends
• Supports strategic planning activities
• Enhances risk response capabilities and operational resilience
• Promotes and communicates risk ownership

HOW WE CAN HELP

Richter’s TRA approach leverages a customized version of the Harmonized Threat and Risk Assessment (HTRA) methodology developed by the Royal Canadian Mounted Police (RCMP) and Communications Security Establishment (CSE).

We work with both business and technical stakeholders to understand your environment, the business impact of any incidents that may impact your environment’s confidentiality, integrity or availability, and the presence (or lack thereof) of any controls/safeguards you have in place.

From there, we provide tailored recommendations to your organization’s size, scope, and maturity to manage any identified risks effectively.

Our key experts

Raymond Vankrimpen

David Greenham

Royal Canadian Mounted Police

www.rcmp.gc.ca

Common menu bar links

• Français

Home > LSA for Physical Security > Publications > G13-01 Secure Storage Rooms (SSR) 

Institutional links

Lsa for physical security.

• Publications

National RCMP

• About the RCMP
• Family Corner

Navigate by

• A-Z site index
• Proactive Disclosure
• Acts and Regulations

G13-01 Secure Storage Rooms (SSR)

Physical security guide lead agency publication g13-01.

This Guide replaces all previous versions of G1-029

Issued: July 2013

Table of Contents

Definitions, abbreviations, referenced commercial standards, how to use this guide, design-basis threat and secure storage room design premise, table 1 – security recommendations, frequently asked questions.

• PART 2 (SSR Construction Specifications)
• Figure 1: Wall Framing Detail
• Figure 2: Welding Steel Mesh
• Figure 3: Welding Sheet Steel
• Figure 4: Riveting Sheet or Mesh
• Figure 5: Example of Mesh Interlay Seam, Riveted
• Figure 6: Critical Attack Area Wall Reinforcement
• Figure 7: Frame Reinforcement at Door
• Figure 8: Ceiling Mount Duct Pass-Through
• Figure 9: Surface Mount Duct Pass-Through

Authority Having Jurisdiction - Normally the local city, municipality or county building inspector. For Canadian Forces Bases the Authority Having Jurisdiction will be the Canadian Forces Fire Marshall.

Attack Side - The side of the door or wall that is exposed to the adversary.

Base-line Threat - Threat(s) that are common to government departments in Canada under normal security conditions, as specified in the Operational Security Standard on Physical Security.

Day Door - A door to a secure room or vault with a primary lock which when unlocked in the morning by the person responsible is still secured by a secondary lock (usually electronic access control) which can be opened (until the primary lock is re-locked) by authorized assistants.

Design-Basis Threat (DBT) - The threat(s) which the specific protection measure (equipment, procedure or policy) is designed to mitigate. Unless specified otherwise, RCMP protective designs and guides are meant to mitigate a DBT based upon the Base-line Threat.

Compromise - The unauthorized access to, disclosure, destruction, removal, modification, use or interruption of assets or information.

Hinge Pair - Industry practice is to specify hinges by pairs. For example, doors with 3 hinges are specified as “1½ pair”.

Maximum Security Pin - A hinge pin that has been fixed after insertion by welding, pinning, or other permanent means to prevent hinge pin removal without the use of special tools. Set screws are not permitted. Affords greater security than a Non-Removable Pin. (ref.: ANSI 156.1 (2006)).

Non-Removable Pin - A hinge pin secured by a set screw or other equivalent means (ref.: ANSI 156.1 (2006)).

Open Shelf Storage - Storage other than in approved security containers and safes. Open shelf storage includes storage where records are kept in containers or commercial fire and/or water resistant containers.

Safety Stud - A projecting member on one surface of a full mortise leaf that engages a hole in the opposite leaf when the door is closed. (ref.: ANSI 156.1 (2006))

Security Container - A totally enclosed container or specially designed room functioning as a storage container (e.g.: Secure Storage Room).

Secure Room (SR) - Term used to denote a room constructed to specifications of the RCMP Guide G1-029. Although not an RCMP-endorsed practice, these rooms were commonly constructed to create security zones, secure working rooms (or suites), as well as for secure storage (the original intended application).

Secure Storage Room (SSR) - The formal term and abbreviation used to identify a room which is designed to the specifications of the RCMP Guide G13-01. Note: The term “Secure Storage Room” does not automatically replace the term “Secure Room” (level 1 or 2). Existing Secure Rooms should only be referred to as Secure Storage Rooms (SSRs) if they are actually being used in a manner consistent with this guide.

Threat and Risk Assessment (TRA) - A consideration of the assets and the threats to those assets in consideration of the sum of the security measures in place or anticipated. The RCMP and CSEC have jointly developed and promote the use of a formal procedure, checklists, valuation tables and associated training for conducting a TRA in the Federal Government called the Harmonized Threat and Risk Assessment (HTRA).

Vibration Detector - A system of one or more sensors to detect vibrations created by impact and powered cutting tools. Approved systems have a sensitivity / detection algorithm to ensure that ambient and incidental noises or vibrations due to normal activity will not initiate false alarms.

Zones - Defined in Reference B.

• AHJ - Authority Having Jurisdiction
• CCVE - Closed Circuit Video Equipment
• Ga - Sheet metal gauge indicating the standard thickness of the sheet metal
• IDS - Intrusion Detection System
• SEG - Security Equipment Guide
• SCIF - Secure Compartmented Information Facility
• SR - Secure Room (+ suffix indicating Secure Room “Type” as per earlier versions of G1-029)
• SOR - Statement of Requirements
• SSR - Secure Storage Room
• TRA - Threat and Risk Assessment
• OD - Outside diameter
• oc - On centre
• Ø - Bar diameter
• Policy on Government Security
• Operational Security Standard on Physical Security
• G1-001 RCMP Security Equipment Guide (SEG)
• HRSDC Fire Commissioner: Standard for Records Storage
• HRSDC Fire Commissioner Technical Interpretation: Door and Door Release Hardware with One Release Operation
• Lock-Up Requirements for Protected A and Protected B Information (published under the “Storage” section of the RCMP Security Equipment Guide

These standards are available for purchase from their respective standards associations, or from standards vendors such as IHS Standards , the ANSI Store or Techstreet

ANSI/ BHMA A156.4: Door Controls-Closers American National Standards Institute

ANSI/BHMA A156.1: Butts and Hinges American National Standards Institute / Builders Hardware Manufacturers Association

ASTM A627-03: Standard Test Methods for Tool-Resisting Steel Bars, Flats, and Shapes for Detention and Correctional facilities American Society for Testing and Materials

ASTM F1267-07: Standard Specification for Metal Expanded Steel American Society for Testing and Materials

CAN/CGSB-1.60: Interior Alkyd Gloss Enamel Paint Canadian General Standards Board

CSDMA 08 11 13: Recommended Specification for Commercial Steel Door and Frame Products Canadian Steel Door Manufacturer's Association

EMMA 557-99: Standard for Expanded Metal, Introduction, Product Selection Considerations, Terminology, Manufacturing Process, Manufacturing Tolerances and Applications. Expanded Metal Manufacturers Association

HMMA 840-07: Guide Specification for Installation and Storage of Hollow Metal Door and Frame Hollow Metal Manufacturers Association

HHMA 810-09 (NAAMM Standard): Hollow Metal Doors Hollow Metal Manufacturers Association

SSMA: Product Specifications Steel Stud Manufacturers Association

PART I (For use by the Department or Agency)

Advances in portable tool technology have changed the nature of overt force and skilled force attacks. In addition, large-capacity memory devices can now store significant amounts of information and the threat to personal information has greatly increased due to identity theft.

In light of these technological and threat evolutions, it is recommended that a TRA be conducted on all existing Secure Rooms (or similar spaces constructed using previous G1-029 version specifications) to determine if modifications are warranted.

Significant Changes introduced with the G13-01:

• There is an emphasis on the Secure Storage Room (SSR) as a special type of approved security container (essentially an alternative to using numerous approved security containers) and on its application consistent with that design premise. The name has been changed from Secure Room (SR) to Secure Storage Room (SSR) to further emphasize the design intent.
• In the past, Secure Room levels (1 or 2) were determined essentially by the choice of metal used in the walls. This guide now permits the selection of one or the other based on cost, availability and construction preference.
• Windows and false ceilings are not part of the Secure Storage Room design and are highly discouraged. When they must be used, compensatory measures will be required. The RCMP can provide guidance on a case-by-case basis.
• There is a new emphasis on the early detection of forced entry.
• This guide attempts to optimize the use of commercial-off-the-shelf (COTS) material and components. Widely accepted commercial standards are referenced whenever practical.

This Guide (particularly Part 1) is intended for use by qualified security practitioners and departmental security staff to select appropriate Secure Storage Room features and Intrusion Detection System (IDS) components and develop a Statement of Requirements (SOR) to guide the designer responsible for its design and construction.

Once the SOR is established, appropriately cleared architects, engineers or qualified builders/ designers should be engaged to develop detailed drawings and specifications. These should incorporate the features and components specified in the SOR and ensure the design conforms to overall project requirements (where part of a larger project) and all applicable codes and facility “fit-up” standards. IDS design and installation should ideally be done by departmental security personnel. Departments without alarm and intrusion system sections should engage an independent (without ties to vendors or installers) consultant to assist with developing the IDS architecture and help manage the contract and procurement process. They can also be helpful with developing commissioning criteria.

The rationale for any component or feature selection (as well as the nature of the asset and the design-basis threat) should only be divulged to the architect, designer and contractor on a need-to-know basis and only if they have the appropriate security clearance. Consideration should be given to classifying the rationale and key security features.

Note : The fact that a SSR may store classified information does not in itself imply the SSR construction details should have the same classification. It does imply the construction details (as well as purpose and name of the SSR) should be adequately protected.

Segregation of details and distribution on a need-to-know basis will often be sufficient. The architect or designer should be provided with formal guidance / direction on the preparation of drawings for tender or sub-trades to ensure that sensitive information is not inappropriately divulged. For example, the purpose or name of the room should not appear on widely disseminated drawings, specifications or other contract documents. A generic or numeric name should be used. Sub-trades should receive only enough information to perform their work (eg: partial building drawings and system schematics which do not identify adjacent activities or security-related system details). Security requirements should be incorporated into contract documents where feasible to ensure enforceability.

Purpose of the Secure Storage Room

A Secure Storage Room is intended to function as an approved storage container for open-shelf storage of a large amount of classified or highly sensitive non-national (Protected) information or assets. A Secure Storage Room is essentially a “security container” and subject to the same zoning requirements.

Unless all mandatory technical and application specifications in this Guide are met, the room does not qualify as an approved Secure Storage Room (SSR) and should not be referred to as an SSR.

Fire Protection

Fire requirements (legislation) ALWAYS supersede security requirements (policy) so good planning and early consultation with the local AHJ is very important to avoid issues which may result in the removal or modification to security features.

Sprinklers are not an integral component of a Secure Storage Room and should not be added inside an SSR unless required by the AHJ. If additional fire protection is required, records can be stored in commercial fire rated containers placed inside the Secure Storage Room. Inert gas fire suppression systems can also be used.

Additional or Type X drywall sheets can be installed to meet code requirements (or as required by the AHJ). If necessary, an appropriately labelled fire door can be used instead of the specified door. Please note that there are specific requirements for mounting locks and hardware on fire rated doors. Contact the local AHJ for assistance and guidance on fire and safety issues.

Slab-to-Slab

Secure Storage Room walls must be slab-to-slab (from the finished floor to the underside of structural concrete roof or floor) or continue across the ceiling to form a continuous secure enclosure (Secure Ceiling). Where the space above the Secure Ceiling (measured to the underside of the limiting structural component) exceeds 6 inches, the space should be closed and secured or electronically monitored. In rare cases, the floor may also need special treatment. Consult the RCMP for advice.

Secure Storage Rooms primarily protect against surreptitious attacks but also detect and delay forced entry. The SSR is designed for location in a Security Zone or High Security Zone in a federal government building (or CISD-approved equivalent in contractor facilities) in urban centres. SSR constructed in remote locations may require additional safeguards.

A Vulnerability Assessment should be conducted to determine if a potential adversary can access the perimeter (or any space above or below) of the SRR undetected and unobserved for long periods of time. If so, additional measures are required to limit access or actively monitor activity in the perimeter areas.

Floors and ceilings are assumed to be constructed of highly intrusion-resistant materials such as structural concrete, reinforced concrete block or concrete on steel (roofs and floors). Wood or steel assemblies should be steel-strengthened and vibration-monitored the same as the walls.

A vestibule was included with the original Secure Room design for two purposes: to limit the swinging motion of hand tools and to provide better sound isolation at the door. With respect to the first objective, the most viable forced entry threat to the SSR door and hardware is now from powered portable tools and a vestibule does little to reduce it. In fact, a vestibule now becomes a possible space for an adversary to hide while attacking the door (or the wall around it). The vestibule is also not needed to enhance sound isolation at the door when the SSR is used as intended – as a records storage room.

Therefore, exterior vestibules are not required (though still permitted) for construction of a SSR. Any vestibule that is built should be constructed so as to permit observation of activities within it (eg: glazed walls or door).

A “day door” function is facilitated by use of SEG-listed locks which provide this function where departmental policy accepts the practice. To be approved for this function, the electronic access controls must work only when the mechanical lock is “open” (locking the mechanical lock must mechanically disengage the electronics so that attacks by compromising the access controls are not possible).

Well-defined and enforced operating procedures are necessary when using “day doors”. Users must not be permitted to use the electronic locking mechanism in place of the mechanical lock for extended periods (especially overnight and weekends).

Intrusion Detection Systems (IDS)

While the sheet steel on the walls provides some force resistance, its main use is to transmit vibrations from force attacks to vibration sensors. The RCMP has tested and approved a vibration detector for SSR walls which is listed in the SEG. Detection systems (e.g. motion sensors) located inside the Secure Storage Room may also be employed, although they do not detect the adversary until he/she has already gained entry, thereby reducing the available response time.

The selection table suggests what type of detection system should be used for various situations. In all cases, the alarm systems must generate reliable, timely and appropriate response.

Plumbing and Electrical Pass-through Construction

Minimize plumbing and electrical pass-throughs in SSR walls where possible. Do not locate pass-throughs in the Critical Attack Area. Where pass-throughs are required, frame openings within 1 inch (25mm) of the pipe/conduit and secure to the stud framing at minimum two places. Extend the wall protection material to within ¾” (20 mm) of the edge of the opening. Extend gypsum wall board to the edge of the pipe or conduit. Seal all gaps with fire rated or acoustic sealant. Recommended product standard: ASTM E 814 (UL 1479) or CAN/ULC S115, or as required by the AHJ.

Where necessary to accommodate pipe or conduit movement or expansion, pipes and conduit may be enclosed in a close-fitting sheet metal sleeve and the sleeve mechanically fastened to the stud framing at two places (minimum). Clearance between the sleeve and pipe or conduit should be kept to a minimum and not exceed ¼”.

Steel bars should be installed to delay access of a person through a duct with a cross-sectional area greater than 96 square inches and a smallest dimension greater than 6”. They may be omitted if a TRA determines that unauthorized entry through these ducts is not a threat.

Note that Man Bars do not prevent the introduction of deleterious material (e.g. water, toxic fumes). If a TRA identifies such threats as viable, all ducts and openings may require additional mitigation measures (e.g.: filters or dampers). Contact the RCMP for advice.

A code-compliant (single motion, single action) door lock that accepts approved combination locks has been approved and is listed in the SEG.

Two-Person Integrity

Some SEG-listed electronic combination locks permit the application of a two-person integrity (both persons must dial the lock open) policy. This is one of the most effective security measures that can be applied to sensitive information storage.

Screws (including “security screws”) are not approved for attaching wall protection material (steel sheet or mesh) to steel studs. Wall protection must be attached by welding or rivets.

Standard drywall screws are permitted for attaching gypsum wall board over steel protection sheeting to metal or wood studs.

Self-tapping sheet metal screws are permitted for attaching anti-spread and cross-bracing to metal studs.

Use minimum 38mm (1-1/2”) long #7 (or larger) wood (not drywall) screws spaced at 300mm o.c. (with appropriate washers) to attach steel protection material to wood joists or wood studs.

Statement of Requirements

Where the department (client) is not also the designer, a Statement of Requirements (SOR) should be developed to tell the designer exactly what is required and to identify selected construction options from those presented in the General Specifications in Part II.

The SOR and all documentation leading to the selection of SSR specifics should be considered sensitive and treated accordingly.

Do not tell the designer why a selection has been made unless the designer has a need to know.

Advice and Guidance

Royal Canadian Mounted Police Departmental Security Branch Physical Security Section 1426 St. Joseph Boulevard Ottawa, Ontario  K1A 0R2 Email: [email protected]

Table Notes

1   UL 687 labelled Burglar Resistant safes provide significant additional force resistance (as well as compartmentalization for need-to-know segregation). Although the Secure Storage Room provides early detection and some delay, the safe’s resistance time should closely correspond to the assured response time for an appropriate response.

2   Additional compartmentalization is recommended where the need-to-access principle is still a concern (see Reference B paragraph 7.6.7). Information can be compartmentalized by using commercial locking containers/cabinets. UL 437 high security keyed locks are recommended.

3   Procedural and/or technological mitigation measures should also be considered.

4   Consider the use of High Security cylinders with “chip technology” (e.g. CLIQ ™) for audit purposes (only).

General Notes:

A)  Where a TRA determines that a particular threat is well-mitigated by other aspects of security the DSO may decide that one or more of the recommended measures are not required.

B)  The Communications Security Establishment of Canada (CSEC) requires certain equipment to be placed in a Secure Room (previously the SR-2). Additional security features such as emanations protection may be required, but the RCMP can only advise on the construction of a Secure Storage Room as designed for records storage. Contact CSEC Client Services: [email protected]

Q1: Why does Protected “C” in a Secure Storage Room still require a safe?

A1: The nature of the threat to Classified information differs significantly from the threat to Protected “C” (especially Life Threatening) information. Secure Storage Rooms are an alternative to approved security containers and must provide at least the same protection. Protected “C” (especially Life Threatening) is considered susceptible to sustained force attacks by a motivated adversary and thus needs significant force resistance. This can best be assured by using UL 687 Burglar Resistant safes with at least a 1 hour rating for the additional compartmentalization. Safes also provide additional compartmentalization for need-to-know.

Q2:  How do the Secure Storage Room requirements relate to those for a Secure Server Room as specified in G1-031?

A2:  The functions of the rooms are different. Secure Storage Rooms are designed for the storage of records. They are not intended for the processing of information (or for occupancy). Servers are vulnerable to different threats than stored records, and server rooms generally have extensive electrical, air conditioning, vents and ducts, and other systems in the room (and through the walls).

Q3: The Operational Security Standard on Physical Security says Confidential information can be stored in an Operations Zone. Why does Table 1 recommend that the Secure Storage Room for Confidential information be in a Security Zone?

A3: The Secure Storage Room should be in a Security Zone because of the elevated risks associated with storing large amounts of information on open shelves. The “periodic monitoring” requirement for an Operations Zone does not provide assurance that an adversary will not benefit from long periods of unmonitored activity. The concern is that without effective 24/7 monitoring, an adversary could gain access and operate without detection for an extended period of time. Access might be by insecure ceiling spaces or by un-alarmed/ un-monitored exit doors or elevators. If a TRA reveals that the Operations Zone is sufficiently secure that unauthorized access is highly improbable, then the DSO may permit a Secure Storage Room to be located there.

Q4:  The space assigned to us for a Secure Storage Room is adjacent to a public space or non-departmental occupant. What should we do?

A4:  A Secure Storage Room should never be placed against exterior walls other than those made of reinforced concrete or reinforced concrete blocks (all voids filled). Secure Storage Rooms can normally be placed adjacent to subterranean (basement) walls and walls at least 3 storeys above an accessible surface (ground or roof) without additional safeguards.

Q5:  We have an existing double steel door and would like to keep it for our Secure Storage Room as it makes it easier to use a forklift. Can we use it?

A5:  If the door and frame meet the basic construction requirements of this Guide you may be able to secure one of the doors to provide satisfactory security when closed and secured. One way to do this would be to install heavy duty locking bars at the top and bottom that can be secured with padlocks (to ensure users do not open them and leave them open). The bars should have a diameter of at least 30mm and be connected to the door with two guides that are welded or riveted to the door and spaced at least 300mm apart. The bars must project at least 30mm into a pocket or guide welded or riveted to the frame or secure wall. The bars should have a design that prevents unlocking when the padlock is attached.

This approach requires strict adherence to policy and procedure and should be used with discretion. A custodian should be appointed to hold the keys to the padlocks and be responsible for ensuring the secondary door is secured.

Q6:  Are there any restrictions on wall switches or outlets on Secure Storage Room walls?

A6:  The Secure Storage Room walls were tested without holes or penetrations. Surface mounted fixtures should be used where possible. Where a fixture must be set into the wall, it should be located as far as possible from the door. The fixture box must be steel and welded or riveted to the steel wall sheathing. All cables and wires should be encased in steel/EMT conduit.

Through penetrations are to be avoided. Where penetrations must be made on both sides of the wall, they should be offset at least 300mm from each other.

Q7:  The G13-01 uses mandatory language with words like “required” but isn’t it a ‘guide’?

A7:  As Lead Agency, the RCMP is delegated the authority to design, test, evaluate and approve security equipment. Each department or agency has the authority to decide if it will use RCMP approved equipment or designs – either as approved or modified in some way. To be approved, a Secure Storage Room must be constructed to the RCMP design specifications. If all RCMP specifications are not met, it is not an RCMP approved Secure Storage Room and should not be referred to as a Secure Storage Room (SSR).

Q8: What if the AHJ requires the SSR to have two means of egress?

A8:  This should not occur when the room is kept to its original design purpose as a (relatively) small records storage room since the secondary exit is determined by occupancy and floor area. If this situation arises, the second exit door should not have any locking hardware on the outside.

Q9: Can I build an SSR in a wooden building?

A9: The SSR was designed for location in a Security or High Security Zone within a typical government building in an urban environment. For other situations, conduct a TRA taking into consideration the threat, the asset and the sum of all protection measures (e.g.: location on a military base, regular patrols and fast response, etc.). While not explicit in this guide, operational security measures that are sufficient and assured can offset minor gaps in the level of physical protection afforded by wooden floor and ceiling construction. Metal protection material and vibration sensors should be installed on both the floor and ceiling of an SSR constructed in a wooden building – contact the RCMP for additional guidance.

Q10: We are putting in an enforcement unit in a warehouse bay with a main floor and a mezzanine floor that will be open to the main floor. However, there will be enclosed offices on this floor. There are plans for two evidence/secure storage rooms on the main floor underneath the mezzanine floor. The floor will not be slab concrete. What should we do?

A10: Where the roof (mezzanine floor) is made of wood (wood or composite joists with plywood sub-flooring), we recommend that the roof have expanded metal mesh (3/4" - #9F as called for in the wall construction) secured to the underside (secure side) of the roof joists and a vibration detector (sensor) installed in contact with the mesh on the secure side. The sensor mounting plate can be installed adjacent to the roof joist (preferred solution). Cabling for the roof sensor should be run on the secure side of the SR ceiling (i.e. in surface mounted conduit) to where it joins the other sensor cabling in the common conduit to the alarm control panel.

Q11: Can I install the door lock at a different height to accommodate accessibility requirements?

A11: Ordinarily installing the door lock 44 inches above floor level will accommodate accessibility requirements for all users. If the lock is being installed less than 42 inches above floor level, the anti-spread bracing (between the door frame and adjacent stud – located 48 inches above the floor) should be lowered to within 6 inches of the lock center-line, or additional anti-spread bracing installed 6 inches or less below the lock center-line.

Q12: Can I change the lock height (e.g., to accommodate a handicapped person)?

A12: Yes. If the lock height is shifted more than about 150mm (6”) we recommend also shifting the anti-spread bracing to match.

PART 2 - SSR Construction Specifications

SSR General Construction and Assembly Specifications

Note : The specifications in this Part should be modified as required and incorporated into the Project Contract Documents by the Designer in accordance with client requirements (ideally outlined in a detailed SSR Statement of Requirements) and overall project and code requirements.

Extend wall partition framing slab to slab.

Wall Framing (Figure 1)

Top and Bottom Tracks: SSMA standard: 1- 5/8” x 6”, 18ga (600T162-43); OR Preferred: 2” x 6”, 18ga (600T200-43)

Secure top and bottom steel stud track to both slabs at 300mm oc using any expanding (preferably double expanding) mechanical fastener. Non-expanding (e.g. “Tapcon”) screws are not acceptable.

Studs: SSMA standard: 1- 5/8” x 6”, 18ga (600S162-43: 33ksi); OR Preferred: 2” x 6”, 18ga (600S200-43: 33ksi)

Space studs at 300 mm oc and secure to the top and bottom tracks with welds or rivets (not screws).

Install double (jamb) studs at the door frame opening. Install the door frame as per HMMA 840-07, part 3 A, B, C, D and E (except that screws shall be replaced with steel rivets).

Install anti-spread bracing approximately 48” from the bottom of the wall between the door frame double stud and the adjacent stud on both sides of the frame.

Construct wall corners with double studs.

• Leaving a small gap and using drywall sheets to brace frame sections during wall erections is permitted provided steel sheets on the attack side are continuous over all gaps.
• Drawings of doubled studs are representative. Connect and orient doubled studs as per standard industry practice.

Wall Protection Material (Figures 2 to 5)

Wall protection material may be one of two options:

Flattened Metal Mesh: To EMMA 557-99. Style ¾-9F: nominal strand thickness of 0.120” (0.108” to 0.132”). Diamond opening of 0.563” x 1.688”. OR Sheet Steel: 16 Ga, A1008 / A1008M (cold rolled) or A1011/ A1011M (hot rolled) or equivalent.

Mount on the outside (attack side) of the room. Support all edges by anti-spread bracing, studs or corners. Align the sheet edges at every vertical and horizontal seam on the centre line of the steel stud or anti-spread bracing and secure all sheets with welds or rivets.

Note: Screws (including “security screws”) are NOT acceptable for permanently attaching the protection material (steel or steel mesh). Screws may be used to “tack’ the sheets in place pending riveting or welding. Temporary screws do not need to be removed.

Welding (Permitted Method)

Steel mesh (Figure 2): 3mm fillet weld along the strand at 200mm oc

Steel Sheet (Figure 3): 1.5mm fillet weld 15mm long at 200mm oc OR 8mm plug weld at 200mm oc

Rivets (Preferred Method) (Figure 4):

Steel sheet: 3/16" steel rivets at 200mm o.c. Steel mesh: 3/16" steel rivets and “fender” washer (1 ½ " OD, 3/16’’ ID) at 200mm o.c.

Suggested material: Rivets: 3/16” steel pop rivet: Speaneur part #301-440 Washers: 1 ½ " OD, 3/16’’ ID “fender” washer: Fastenal part #1133204

Steelmesh Interlay Seam (Figure 5):

Critical Attack Area (Figure 6)

16 ga. (1.6 mm) steel sheet, HR Commercial quality, ASTM A366, matte finish, shall extend 1200mm around the door frame on the inside of the secure storage room and be attached as per selected rivet or welding requirements for protection material.

Note : Perforations for services, conduits or ducts are not permitted in the Critical Attack Area.

Wall Finishing Details

Install 16mm gypsum wall boards on both sides of the wall (interior is optional). Standard drywall screws are acceptable for attaching the drywall.

Apply continuous bead of fire-rated acoustic sealing on both sides of the top and bottom tracks. ASTM E814 (UL1479), ASTM E1966 (UL 2079) or CAN/ ULC S115 test standards with a fire/ smoke rating acceptable to the Authority Having Jurisdiction (AHJ).

Paint exterior surface of wall with one coat primer/sealer and one coat of gloss enamel. Primer/sealer must extend above drop ceilings to the bottom of structural ceiling. Paint must be uniform and without blemishes. Joints must not be visible. Custom colors should be considered.

Door, Frame and Hardware

Door and Frame:

Commercial Steel Door and frame compliant with section 08-11-13 of CDMA Publication: Recommended Specification for Commercial Steel Door and Frame Products.

Door may be specified as fire rated where required.

Doors wider than 900mm (36”) should be avoided. Double doors will require special measures.

Face Gauge: 16 gauge (1.6 mm) steel

Construction: Laminated core with vertical steel stiffeners at 150mm oc (stiffeners welded or laminated to each face sheet with voids between stiffeners filled with fiberglass or mineral batt type material).

Caps: ‘Flush Closing Channel’ or ‘Flush Channel’ top and bottom.

Ref: NAAMM 810-09 Part 2. A. Figures E and F for edge details.

Edges: all edges and top and bottom caps to be continuously welded and ground smooth.

Door handing: (must be specified as per client requirements).

Gauge: 16 gauge (1.6mm) steel

Frame construction: Welded or fully field welded 3-piece “knock-down” (for retrofit applications).

Anchors: “Z” shape steel wall anchors welded to frame.

Reinforcing at latch: as per lock manufacturer recommendations. Lock specifications must be provided to the supplier/manufacturer to provide necessary reinforcing requirements.

Locks: Select according to Table 1.

Hinges : to ANSI/BHMA A156.1 Grade 2 and ANSI A8112 (Steel Material Standard) Full mortise, five knuckles, ball bearings, standard weight. Three (3) hinges per door (minimum). Minimum Dimensions: 114mm (4 ½”) x 114mm (4 ½”) x 3.4mm (0.124”) thick.

Hinges mounted with barrels on the attack side (“reverse-hung” or outwards opening) must have non-removable pins (NRP), maximum security pins (MSP) or safety studs/reverse safety studs. Note that these require special ordering instructions.

Suggested products:

• Hager (Catalogue item BB1279)
• Stanley Architectural Hardware (Catalogue item FBB179)
• Mont-Hard (Canada). Mont-Hard products are carried by Montreal Hinge (Catalogue item BB-1079)

Door closer : Overhead style ANSI A156.4 Grade 1 Suggested product: Ingersol-Rand LCN 4040 series

Threshold : Aluminum (or other metal) interlocking style with hook strip installed on door. The SSR should qualify for exception from building code “Barrier-free path” requirements when used only to store records. However, where wheelchair accessibility is required, two recommended products are:

• PEMKO (model 114): PEMKO (Toronto) 866-243-9816 (sales)
• Zero International (model 73A)

Door contacts: UL 634 High Security Switch - level 1 or level 2.

Door installation: The door is generally installed as regular hung (opening into the Secure Storage Room), but it can be reverse hung (opening out) in exceptional cases.

Frame reinforcement at the lock area (Figure 7): Secure a 6.4mm x 25mm x 610mm steel plate inside the frame using tack welds on every edge. Align the centre of the plate with the lock bolt.

For reverse hung doors, install a steel astragal covering the entire lock edge of the door AND the unmodified strike plate. The astragal should be at least 14 ga (2 mm) thick, should overlap the door frame by at least 25mm. Attach with minimum 6mm (1/4") diameter steel carriage bolts spaced at 250mm oc and at least 25mm from mortise lock pocket. Carriage bolt heads must be on the attack side.

Suggested product: Zero International #43STST

Ventilation Duct Pass-throughs

Note: Where superior resistance to cutting is required, man bars can be specified as tool‑resistant steel (grade 1 or 2) per ASTM A627.

Ceiling mount: (Figure 8)

• Duct sleeve to be at least the same thickness as duct passing through.
• The overall dimension of the sleeve must be slightly greater than the duct.
• Construct frames of 1- 3/8” x 1- 3/8” x 1/8” angle steel welded around duct sleeve (ceiling mount brackets are recommended).
• Space 3/8” Ø steel bars at 6” oc and weld to the frame.
• Secure the duct sleeve to the structural ceiling with mechanical fasteners.
• Cut protection material ¾” max from the edge of the duct opening (3 sides)
• Apply fire-rated caulking between duct sleeve and finished wall.

Surface Mount: (Figure 9)

• Duct sleeve to be at least the same thickness as the duct passing through.
• Construct frame on each side of the wall of 1- 3/8” x 1- 3/8” x 1/8” angle steel welded around duct sleeve.
• Space 3/8” dia man bars at 6” oc and weld to the frame.
• Secure duct sleeve with ¼” dia bolts and hex nuts (inside the room) at 8” oc around the outside duct sleeve. The bolt head shall be on the attack side and be welded in at least three places to the angle frame.
• Framing around duct sleeve is required.

To read Adobe Acrobat (PDF) files, you may need to download and install the free Adobe Reader available from Adobe Systems Incorporated.

Breach Assistance

Get in touch

Threat and Risk Assessment: What is it, Guides and Benefits

As more and more sophisticated crime operations spread across the globe, and as new software vulnerabilities are discovered and exploited by cyber criminals, companies have an increasing obligation to assign experts and analysts to systematically identify and remediate threats. One invaluable tool for creating and implementing an effective security program is a detailed and comprehensive Threat and Risk Assessment (TRA).

What is a Threat and Risk Assessment?

A TRA is a process used to identify, assess, and remediate risk areas. The result of this process will be to, hopefully, harden the network and help prevent (or at least reduce) attacks. Threat and Risk Assessment provides a more thorough assessment of security risk than the standard assessments, such as studying threat statistics or conducting a facility walk-through. The analyst takes information and data from many methods and then combines these pieces, forming an extensive plan for sound security management, while also assessing a company’s compliance with industry practices and applicable laws.

The goals of Threat and Risk Assessment

The main objective of Threat and Risk Assessment is to protect organizations against liabilities by identifying and understanding the various risks facing the client property and community. Threat and Risk Assessment identifies exposures by determining potential security weaknesses and taking the appropriate actions to reduce the impact of threatening events and manage the risks.

When do you need to assess the risk of insider threats?

Not only does the TRA assess external threats, but it can also be effective in assessing and protecting from internal threats. If you are an organization that works with sensitive data, you should also assess the risk of insider threats. No one wants to imagine that their employees can be a security risk, but an estimate of 63% of cyber attacks are internal . There are three steps to assess the risk of insider threats:  

• Audit your organization’s cybersecurity;
• Apply for cybersecurity insurance;
• Comply with laws, regulations, and security standards.

  Audit your organization’s cybersecurity

Risk assessment is an essential part of risk management strategy. aside from being part of a regular routine, here are just a few of the times when your organization should perform an assessment:  

• To plan for reorganisation or expansion of a business;
• An abnormally high increase in cybersecurity incidents within your industry;
• A known attack on your organization.

  Apply for cybersecurity insurance

Just as we insure our buildings and businesses for risks such as fire, theft, and natural disasters, it’s advisable to also insure your company for cyber attacks. As with most insurance, the insurance company may require an assessment before issuing the policy, and in order to help define the terms of your coverage. The risk assessment method used by insurers for analyzing an organization’s risk level includes:  

• Client meetings;
• Underwriting questionnaires;
• Risk audits;
• Open-source intelligence;
• Threat intelligence;
• Third-party assurance reports.

  Comply with laws, regulations, and security standards

There are many laws and regulations that directly involve the security of data. Whether it is dealing with PCI , HIPAA , or organisations such as ISO and NIST, assessing the risk of insider threats is mandatory. Below, we will run through a few of these regulatory requirements:

NIST Risk Assessment Guide

The National Institute of Standards and Technology (NIST), suggests the following steps:

• Prepare for the assessment  
• Here you define the scope and purpose of the assessment, as well as constraints (you may, for example, limit the assessment to only the customer-facing network). Further, it explains the risk model you are comfortable with, sources of information, and which analytical approaches you will use.
• Conduct the assessment  
• At this stage, you identify the relevant sources of threats and events, together with any vulnerabilities that could be exploited. Further, you determine the potential and likely impact of the specific threat events.
• Share and communicate risk assessment information  
• To support risk responses, communicate risk assessment results to decision-makers and other relevant personnel.
• Maintain the risk assessment  
• This includes remediating vulnerabilities (such as updating and patching software, or monitoring known, but low-level risks (using an IDS).

PCI DSS Risk Assessment Guide

The PCI Guide offers pages of guidelines and assessment values to consider. Here are just a few of the most important tips:

• All data should be encrypted, both in-transit and at-rest;
• Monitor and assess networks on a regular basis;
• Only store customer data when necessary (for example, keeping a card on file at popular retail websites).

Guidance on Risk Analysis Requirements under HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) requires that health organisations conduct a regular risk assessment. During this assessment, auditors should check for:

• Malicious software installation;
• Computer- and network-based attacks;
• Inaccurate data entry;
• Unauthorised access to electronically protected health information.

Engaging Stakeholders in Risk Assessments

In the context of cybersecurity risk mitigation, involving a diverse range of stakeholders is essential for a comprehensive threat and risk assessment. These stakeholders, including board members, executives, managers, employees, IT teams, customers, and external entities like suppliers and regulators, bring unique perspectives crucial for effective risk management. The process begins with identifying and categorizing stakeholders, followed by transparent communication of the risk strategy. Actively involving stakeholders in risk assessment, consulting them on treatment plans, and collaborating on implementation ensures a collective and informed approach. Regular updates on risk monitoring maintain transparency and foster a culture of cybersecurity awareness. To enhance stakeholder engagement, consider tailoring communication methods, addressing concerns promptly, and promoting a pervasive cybersecurity mindset across the organization.

INTEGRATING NEW TECH IN RISK ASSESSMENT

When introducing new technology for safety risk assessments, it is important to remember that it is meant to complement and enhance existing practices, not replace them. The first step is to clearly define the goals you want to achieve with the technology. Next, choose the technology that best fits your needs. It is crucial to seamlessly integrate this technology into your current workflow. Ensure that everyone understands their role in using the technology and handle the data it produces responsibly. Once the technology is operational, regularly evaluate its performance and make any necessary adjustments and improvements. However, it is essential to remember the core principles: always act ethically and legally, and prioritize stakeholder privacy and rights.

CONTINUOUS MONITORING IN RISK ASSESSMENT

The evolving nature of cyber threats necessitates a transition from periodic assessments to continuous monitoring. Continuous monitoring involves real-time tracking of security metrics, network activities, and potential vulnerabilities. It enables you to oversee high-risk assets and systems and promptly respond when needed. The good news is that continuous monitoring can be automated, ensuring the quality of assessments without overwhelming your team.

Five Key Steps for Assessing Insider Threats

As we mentioned at the beginning of this article, while external threats are certainly a risk, a large number of attacks come from internal sources. Insider threats pose a significant risk to organizations, as they involve malicious or negligent actions from employees, contractors, or other insiders who have authorized access to sensitive information, systems, or assets.

An insider threat can cause significant damage to an organization, ranging from physical damage to intellectual property, financial loss, and reputation, ultimately resulting in reduced profitability and competitive advantage.

For this reason, it is vital to assess your organization’s security from the inside, as well. A threat and risk assessment program can help you to identify and address insider threats, thus reducing the overall risk to your organization and improving the effectiveness of your information security program.

A typical insider threat and risk assessment would look like this:

Source: CISA

We've broken down the threat assessment process into five key steps. Keep reading to learn more. 

IDENTIFYING ESSENTIAL ASSETS OF AN ORGANIZATION

Risk assessment starts by distinguishing the valuable assets that insiders can compromise in an organization. It would help if you, therefore, focused on:  

• Access to admin accounts and servers (both physical and cloud);
• Confidential information, such as trade secrets;
• Employee’s sensitive data;
• Subcontractors’ and partners’ data;
• Crucial services and systems.

In this step, you need to identify the assets and data that need to be protected, and determine the potential insider threats that could compromise them and the current level of exposure of your critical assets to insider threats. You also need to define the goals and objectives of the assessment, such as identifying vulnerabilities and weaknesses, assessing the effectiveness of existing controls, and developing mitigation strategies.

A penetration test can help you determine if your current security controls are effective to protect these assets. Additionally, it can help to uncover any vulnerabilities that may be exploited by an insider. 

Defining the possible insider threats

Activities done by legitimate users but with negative connotations are referred to as insider threats. These include:  

• Sensitive data disclosure;
• Misusing, changing, or deleting data;
• Malware uploads (both intentional and unintentional);
• Failure to follow the principles of least privilege.

Insider threats can take many forms. According to CISA, these are the main types of insider threats:

• Unintentional Threats: Unintentional threats include negligent employees that could expose your organization to threats, and accidents or mistakes that cause unintended risks to your organization's data;
• Intentional Threats: Intentional threats are malicious actions taken by an insider with the intention of harming your organization's data or systems. This can include employees who are disgruntled or who are working against the organization due to monetary or other personal reasons;
• Other Threats: Threats such as third-party and vendor access to your organization's systems and data, and insiders who collaborate with outside parties can also pose a risk to your organization's data and systems. 

All these threats can manifest in your organization in different ways. According to CISA, these 'expressions' of insider threats can include workplace violence, terrorism, sabotage, and espionage. Here's a chart by that illustrates the various expressions of these insider threats.

To identify potential insider threats, you need to review access logs, conduct employee interviews, and analyze past incidents. It's also important to keep an eye out for suspicious activity, or concerning behaviors in your employees that may include any of the abovementioned expressions of insider threats. This will help you identify individuals who have authorized access to your organization's systems and data, and who may pose a risk to the confidentiality, integrity, and availability of that data.

PRIORITIZE RISKS

Once you've identified potential insider threats, it's time to classify and prioritize them, based on the level of risk they pose to your organization.

Here, you determine which risks most threaten your business, both in terms of profitability and customer confidence. A risk matrix can help you determine the level of each risk. Here are the four factors that you should analyze:  

• How critical the threat is;
• Importance of the at-risk assets;
• Likelihood of an occurrence;
• System vulnerability.

While evaluating the risk of possible insider threats, it is important to consider the following:

• Does the insider have an interest or motive in harming the organization?
• If yes, do they have the capability to carry out their plan?
• What could be the extent of the damage if the insider were to act?
• Is there evidence of the insider's intentions?

CREATE A RISK ASSESSMENT REPORT

Wrap your risk assessment results into a comprehensive report. This will help to simplify the decision-making processes at the further stages of the management strategy. The report can help you to:  

• Communicate results of risk assessment to decision-makers;
• Share the risk-related information with your employees;
• Adjust your risk management approach (updating software more regularly, making password requirements more stringent, etc.).

As per CISA's Insider Threat Mitigation Guide , the ultimate question to answer in a threat assessment is if the insider is on a path to cause harm. And if they are, how far along are they? And when can you intervene?

MAKE INSIDER RISK ASSESSMENT A COMMON PRACTICE

You should note that with time, organisations tend to change either software and tools, or expand their departments and their practices. Such changes create new vulnerabilities, and your organization should therefore conduct a risk assessment regularly.

Also remember that the threat assessment is not a one-time event and is a process that requires continuous monitoring and updating. If your initial assessments and strategies fail, revisit your threat assessment to find out why and refine your approach accordingly. 

Risk assessments collect essential information and expose weak cybersecurity spots. They also provide an organization with the tools they need to evaluate the consequences of potential security incidents. Lastly, they also help an organisation improve its security practices, helping to prevent incidents in the future. While it is impossible to prevent all incidents, risk assessments are a vital tool for protecting any organization from the ever-growing threat of cyber criminals.

< Older Post

Newer Post >

Essential Tools and Strategies for Enterprise Threat Detection

Integrity-Based Cyber Attacks Against AI Systems: An In-Depth Exploration

SIEM vs SOAR

ISO 27001: How to Prep Like a Pro

Threat Intelligence | All Rights Reserved

• EHR Privacy and Security Reference Architecture
• Privacy Governance
• Privacy Policies and Procedures
• Project Management
• Monitoring and Reporting
• Audit and Review
• Consent Management
• Breach Management
• Client Privacy Rights Support
• Privacy Impact Assessment Methodology

Threat and Risk Assessment

BlueImpact Threat and Risk Assessment Methodology adopted the principles of the HTRA  [1] and ISO/IES 27005 [2] and is customize specifically to the healthcare industry.  The TRA methodology proposes a simple and straightforward approach to conduct TRA that can be easily communicated with the stakeholders and the staff involved in the TRA process; however, it contains all required tools and templates to facilitate the information gathering and risk assessment.

BlueImpact TRA methodology, and has 5 phases:

• Preparation
• Asset identification and valuation
• Threat assessment
• Risk Assessment
• Recommendations

The key activities in each of the 5 phases are described in the following:

 1 Preparation

In preparation to start the TRA project, the consultant and client project team/stakeholder will have a kickoff meeting. The agenda of the kickoff meeting includes:

• review, determine and agree on the scope of the TRA;
• identify all project documentation for review and reference;
• discuss and confirm the TRA approach and timeline;
• discuss the logistics of the project in terms of the meeting schedule, contact person for various project perspectives, project coordination, etc.

By the end of Preparation Phase, the consultant will document the TRA scope and agreed-upon Approach.

 2 Asset Identification

The next step is to identify and evaluate all information assets that are within scope of the assessment. People, processes and technology should all be evaluated and documented. This includes the following:

•  Data/information such as username, password, monitored vital signs, answer to the patient questionnaires;
• Applications that support the project;
• Servers for each network segment – for example, web, applications and data;
• Networking assets such as firewalls, intrusion protection systems, routers, switches, VPNs;
• Services offering data such as FTP or VPN, EDI, etc;
• If physical facilities are in scope, those assets will need to be identified.

As part of the asset identification, the consultant needs to understand all the key data assets with regards to how the data flows through the application and where the data is stored. Data flow mapping is perfect technique to identify the data and determine where the data goes. Data flow mapping identifies all data flow paths from the originating point to receiving point, which will not only identify all data/information but also the data storage location. Data flow map will also be used in the next phase – Threat and vulnerability Assessment.

During the asset identification process, the assets will be rated on a list of security weights – Replacement cost if any, Confidentiality, Integrity, Availability, Impact if compromised, and Criticality to the business.

Upon completion of this phase, the consultant will develop the Statement of Sensitivity which includes all information assets identified and the rating of the assets.

 3 Threat Assessment

In this phase, threats will be identified and evaluated, which have security impact to the information assets identified in previous phases.

The success of TRA relies on the identification and determination of threat; the TRA result won’t be reliable if not all threats are identified. The methodology leverages the threat list provided in Harmonized Threat and Risk Assessment (HTRA) document and other recognized sources, as well as the broad and deep knowledge and experience of the TRA consultant.

There are many effective techniques that can be used to identify and evaluate the threats.

-The data flow map developed in previous phase is extremely effective in identifying the threat to the data/information that moves between actors and system components. Following the data/information flow, it is straightforward to determine the threat to the data at a particular transmission point or location.

-Matching to known threat list is normally used to determine the threats to certain common assets that are exposed to the common threats.

-Brainstorming is a technique to discover threats to some specific assets that are unique and specific to the project, for example, personnel.

The methodology will apply different technique to different types of asset to ensure all threats are appropriately identified and evaluated.

4 Risk Assessment

In the risk assessment phase, vulnerabilities will be carefully identified and examined, existing safeguards and controls will be evaluated for effectiveness in the risk reduction, and residual risk will be determined. Risk assessment phase has three steps:

-Identify and evaluate the vulnerabilities

-Identify and evaluate the existing safeguards and controls

-Evaluate the residual risk

In determining risks associated with systems implementation, the consultant would classify the risks depending on the threat likelihood and the magnitude of impact on the business. In consultation with the client, threat likelihood definitions would be derived with associated consequences.  (High means the threat-source is highly motivated and sufficiently capable, and controls to prevent the vulnerability from being exercised are ineffective)

The controls selected to mitigate the risk would then be analyzed to ensure the residual risk is at an acceptable level for management.  Additional security controls and practices may be identified in the recommendations and carried forward to the Security Design document.

 5 Recommendation

Recommendations of additional safeguards and/or controls will be made to reduce the risk to an acceptable level. Whenever, a residual risk is not at the level that can’t be accepted based on risk appetite of the project stakeholders, additional mitigating safeguards and/or controls will be proposed to the client that if implemented properly, will further reduce the risk to an acceptable level.

An overall TRA report will then be published in a format prescribed by the client, which would also contain mitigation strategies and also review these strategies with program and I & IT Managers for function and acceptability, and obtaining agreements on recommended solutions and provide knowledge transfer to the client’s staff.

———————————————————-

[1] The federal government’s Harmonized Threat Assessment Methodology (HTRA) is a proven and well-recognized methodology for effectively determining the risks. A complete copy of the HTRA is available from the RCMP on their web site.

[2] ISO/IEC 27005:2008 Information technology — Security techniques — Information security risk management provides guidelines for information security risk management

• Mon. Jun 24th, 2024

51 Security

Learning, Sharing, Creating

• Recent Posts

Harmonized Threat and Risk Assessment (TRA) Methodology ( CSE-RCMP)

Harmonized tra methodology (tra-1).

• TRA -1 -   Tool
• TRA -1 -   A-5: Sample Statement of Work for TRA Consulting Services
• TRA -1 -   A-6: Sample TRA Work Plan
• TRA -1 -   B-2: Asset Listing
• TRA -1 -   B-5: Asset Valuation Table / Statement of Sensitivity
• TRA -1 -   C-2: Threat Listing
• TRA -1 -   C-4: Threat Assessment Table
• TRA -1 -   D-2: Vulnerability Listing
• TRA -1 -   D-4: Vulnerability Assessment Table
• TRA -1 -   E-2: List of Assessed Residual Risks
• TRA -1 -   F-2: Safeguard Listing
• TRA -1 -   F-5: Recommendations Table
• TRA -1 -   F-6: Outline TRA Report)
• TRA -1 -   G-1: TRA Worksheet

https://cyber.gc.ca/en/guidance/harmonized-tra-methodology-tra-1

Harmonized Threat and Risk Assessment

RiskView H-TRA solution automates the Government of  Canada Harmonized Threat and Risk Assessment model  and helps organizations identify, evaluate, prioritize, and report risks. The model is summarized in the above depiction and explained below. While the solution is dynamic and allows the user to start anywhere, it follows a five step process as outlined below.

1. Identify Assets

Identify Assets (e.g. data, equipment, buildings) and assign a value based on their confidentiality and their impact in terms of financial, legal, privacy, or possible injury to people. Assets are assigned a value from Very Low (1) to Very High (5) based on a threshold that can be changed for an industry or an organization depending on their risk appetite.

2. Identify Threats

Threats to an organization can be external, internal, competitors, foreign governments, natural, or other. The more you identify and list such threat the better the result of your TRA. Each threat is assigned a value based on the likelihood and impact of the threat.

3. Identify Vulnerabilities

The third step and the most labor intensive step is the vulnerability assessment for each asset, where each vulnerability is assigned a value based on its likelihood and impact. There are many methodologies for identifying vulnerabilities and ranking them. For example, you may use RiskView’s methodology for identifying IT network and application security vulnerabilities as depicted below.

4. Calculate Residual Risks

The last step is to calculate the residual risk. The risk calculation and conversion is based on the following formula. The tool helps with the automated calculation of the residual risks:  Residual Risk Value = Asset Value [1..5] * Threat Risk [1..5] * Vulnerability Residual Risk [1..5]

5. Monitor and Report

Report and Monitor findings. The tool allows for either pre-made PDF reports, or fully customized company Word documents.

https://www.h-tra.ca/

Currently viewing this topic 1 guest.

Share this:

RC Consulting and Managed Security

We care about protecting your information, assessing risk – helping the smb market understand.

I remember the first risk assessment I was to complete. It was messy essay on defining the use of a specific port to allow an application through our firewall. Truthfully, it was downright ugly to get to the point that the port wasn’t vulnerable, and neither was the application. It was LOW risk.

Early Stages

When I did my first risk assessment, I didn’t realize there was methodologies (although nowhere near as mature as today) that were established by NIST, the RCMP, CSE, and other organizations out there. For some reason, my earlier years were sparse for resources when it came to risk assessments and how to develop them.

After my first risk assessment and getting approval for allowing specific traffic through the firewall, I positioned myself for training. Research this time worked for me.

In 2007 I attended the RCMP Threat and Risk Assessment 2 day course in Ottawa, Ontario. The course was eye-opening. It was an entire methodology laid out with worksheets and examples. It was here where I found out how way off I was in regards to my first assessment.

This is where I learned about Single Loss Expectancy, Annual Rate of Occurrence, and Annual Loss Expectancy. Mathematical functions that help put costs for risk in front of decision makers.

SLE (Single-loss expectancy) = AV (Asset Value) x EF (Exposure factor)

ALE (Annualized Loss Expectancy) = ARO (Annual Rate of Occurrence) x SLE (Single-loss Expectancy)

The instructor for this course was completely honest about these equations as well. He mentioned that Exposure Factor is completely subjective, which makes the entire process subjective. That being said, he mentioned that this is just a framework and like any other framework, you have to decide what works best. As long as you are assessing risk and doing something about it, you are better off than closing your eyes and hoping nothing happens.

After a few examples, it was getting clearer on modeling threats and mitigation strategies. My early practices were still much to be desired but having a basic template was working to establish the baseline to create better templates moving forward. For example, my basic template following the early RCMP templates was not much more than a Risk Register but it was a start. It allowed me to relay risk information better than essay type documents making someone read jargon for two and a half pages without immediate clear context.

My biggest problem with this was that this was created in Excel and stayed there. At this point in my career, it didn’t mature much. I had multiple Excel files and stored them for people to view. A very static approach.

A mentor steps in

It was during my transition to work in Toronto where things became clearer on how you can adapt Risk Management frameworks to your organization. I worked with some amazing people and one specific mentor showed me how to present information to different audiences. My main learning outcome was that people like easy explanations, no jargon and especially COLOUR!

From a risk management perspective, I learned from this point on that at any time in a document where risk is High or Critical (I’ll come back to this) the test or highlight must be RED. I think everyone knows why this is a great indicator.

Along with the colouring of the risk levels, this where I said I would come back to it, the establishment of risk levels. Weirdly, I was happy to learn, you can add and remove risk levels as it applies to your business. For example;

You can range from Low to High, Very Low to Very High, anything basically.

And now, this is where heat maps started to make sense as well. I am sure most people by now saw a heat map in their lifetimes. Here is a rough example as well;

You can tailor your heat maps to your business and what is important. An SMB might only be doing $1 million in revenues a year, so a heat map that references a $1 billion dollar loss does not address risk appropriately. You also may put numbers to likelihood, or occurrence so you have a clearer definition making it more quantitative versus qualitative.

As you mature as an organization and can afford to spend time developing your heat maps, they may also include various other factors as well, such time of impact or time to restore. This is where it is important to understand your risk levels and how much of each square in that grid is relevant to your risk tolerance.

I have worked with many organizations where that grid is static and doesn’t reflect a good tolerance of risk. One example that comes to mind is the Low risk category. A lot of times, organizations see Low risk and assume that no further action is required. That depends on your current controls, your levels and that even though it is a Low risk, there is possibly still risk. Further attention may be required. As mentioned below in the comments; be aware of low risk chaining. This may take multiple Low risk vulnerabilities and combine to make them a High. An example might be a Race Condition, combined with Privilege Escalation that can cross a  trust  boundary.

It’s all about mitigating  risks

Once you have established your heat maps, defining your templates and start getting your processes in place to assess risks, it’s time to mature even further.

Maturing around frameworks

RCMP/CSE harmonized –  https://www.cse-cst.gc.ca/en/publication/tra-1

https://www.cse-cst.gc.ca/en/system/files/pdf_documents/tra-emr-1-e.pdf

NIST –  http://csrc.nist.gov/groups/SMA/fisma/framework.html

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-39.pdf

FAIR –  http://www.fairinstitute.org/fair-risk-management

OCTAVE –  http://www.cert.org/resilience/products-services/octave/

COBIT 5 –  https://www.isaca.org/Knowledge-Center/Research/Documents/COBIT-5-Risk_res_Eng_1213.ppt

ISO –  https://www.iso.org/standard/43170.html

As you can see, the maturity of risk around various frameworks can be intimidating. The frameworks can be free to access and use, like OCTAVE and the RCMP/CSEC harmonized or behind a paywall like ISO and COBIT.

It’s up to you as an organization to determine how you want to mature. The cookie cutter risk assessment templates are truly just a start, and from there you should customize to ensure your are finding appropriate risk because next is how you determine how money is spent.

Once you figure out your assets, the likelihood, the occurrence, the value, and other risk defining information, you have to figure out what you are going to do with that.

Are there existing controls?

Do you need to spend money on new controls?

Is it worth it to accept, defer or transfer the risk?

As you can see, this where you start expanding the ‘columns’ you need to add to your risk assessment model.

Due diligence

So as you can tell at this point the model starts to develop your template that it’s time to make it more logical and tactical.

Now it’s your specific preference and how you do your job as a risk assessor, the organizations tolerance for information, how it’s presented and what outcomes are expecting.

My personal preference is to target one system, application or service at a time. This gives me the chance to fully understand the system before getting to the bigger picture. There are a lot questions to be asked at this stage. Some people hand out a questionnaire template and ask for information back. I like to get Visio diagrams and ask people in person making notes on how specific systems work to get a visual understanding and logical flow of a system and its assets.

Questions can be so varied, so again, I dislike the cookie cutter approach. It is much easier to tailor questions once you get used to your methodology of choice.

This is a great example of one of those intimidating questionnaires , but a lot of research has gone into this and gives a great indication of risk profile when doing an assessment.

https://downloads.cloudsecurityalliance.org/assets/research/consensus-assessments/CAIQ_-_v3.0.1-12-05-2016.xlsx

The  C loud Security Alliance is an absolutely amazing resource for providing guidance on assessing cloud based initiatives.

Once you have received the information needed, fill out your template and work with your teams to understand where to spend your time and effort.

To clarify, this approach is more tailored to tactical risk versus organizational risk. It is all up to your maturity model on how you address this. Thought processes work well for certain assessors versus others. For me it was understanding the systems and how they fit into an organization. This allowed me to figure out their true ‘Keys to the Kingdom’. We all know HR, Financial, Intellectual Property, and Consumer information is important but sometimes the value of reputation, brand, or other data can be more important in context.

Other resources:

https://www.sans.org/reading-room/whitepapers/auditing/overview-threat-risk-assessment-76

http://www.isaca.org/chapters3/Atlanta/AboutOurChapter/Documents/Security%20Risk%20Management.pdf

Risk Assessment Software:

FixNix GRC Suite –  https://www.fixnix.co/

Archer –  https://www.rsa.com/en-us/products/governance-risk-and-compliance.html

SAP GRC –  https://www.sap.com/canada/solution/platform-technology/analytics/grc.html

Open IT GRC –  http://www.eramba.org/

SimpleRisk –  https://www.simplerisk.com/

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Facebook (Opens in new window)

• Skip to main content
• Skip to site information
• Departments

Language selection

Implementation challenges, risks and mitigation efforts.

Delivering on our ambitious yet crucial strategy will not be easy. It will take the dedication of all of our employees to ensure our outcomes are achieved. In order to prepare for delivery, this section outlines six key implementation challenges to be considered going forward.

• 1. Commissioner's message and purpose of the Strategic Plan
• 2. Organizational overview
• 3. RCMP of 2023 and beyond
• 4. Strategic focus
• 5. Implementation challenges, risks and mitigation efforts
• 6. Implementation timeline

Corporate risks and strategic plan activities

A Corporate Risk Profile has been completed for the RCMP to identify key risks that have both a high chance of occurring and high potential to affect the RCMP and its modernization efforts. The strategic plan and the associated activities and initiatives have been designed to mitigate these risks. For more information refer to the RCMP Corporate Risk Profile .

Risk rating

Recruitment, retention and modernized skillsets.

Risk that the RCMP will be unable to adequately attract and retain diverse groups of employees with the appropriate skills, attributes, characteristics and mindset to police the crimes of the future.

Expanding commitments

Risk that the RCMP 's commitments continue to expand without sufficient resources, impeding its ability to deliver on priorities and core services.

Infrastructure and systems

Risk that the RCMP 's IT infrastructure, systems and applications will become increasingly inadequate to support the administrative and operational requirements of the organization.

Risk that the RCMP may not have the technology to sufficiently combat the changing nature of crime.

Employee wellness

Maximize opportunities to promote and optimize employee wellness as well as support employees who experience stress, trauma or serious injury as a result of the nature of policing work and the environments in which they operate.

Strategic decision-making

Risk that the RCMP 's priority setting and business planning are insufficient to support strategic decisionmaking.

Transformation resistance

Risk that the RCMP will encounter resistance and obstacles in the realization of transformative efforts to support policing of the future.

Intelligence and information sharing

Risk that a lack of clear, timely and reliable intelligence and information sharing across jurisdictions will impede the RCMP 's ability to effectively investigate crime and take appropriate actions.

Vision150 and Beyond outlines many important activities to focus on over the coming years. Delivering on these activities will lead to highly consequential, positive outcomes for the organization and our stakeholders. That said, doing so will involve challenges that should be considered in advance and mitigated where possible.

Adaptability of the RCMP 's Strategic Plan

Using the Environmental Scan to shape its priority statements and refining these priorities based on the evolving operational environment will ensure that the Strategic Plan remains adaptable and relevant year over year.

Embedding strategic planning in the RCMP 's standard practices

Understanding that any given strategic plan is a point-in-time exercise when it is first released, it should be adequately embedded throughout the organization to ensure adherence and adaptability.

Governance, ownership and accountability

Executing the stated priorities expressed in this plan will require sufficient governance oversight, as well as appropriate implementation, ownership and accountability.

Open and transparent collaboration and engagement

Business lines owning and executing priority statements must communicate needs or obstacles early and often to internal collaborators, contract partners and other stakeholders.

Using benefits management to continuously improve

Leveraging the RCMP 's robust performance measurement frameworks in the Departmental Results Framework (DRF) and the Vision150 Outcome Model, along with associated Benefits Management will enhance execution and adaptability.

Monitoring and mitigating corporate risks

Utilizing the RCMP 's 2020 Corporate Risk Profile in execution planning will ensure key corporate risks are addressed and mitigated throughout the modernization mandate.

Spy watchdog raps RCMP over application of protocol to avoid complicity in torture

Law aims to prevent the torture of someone in overseas custody due to the information canada exchanges.

Social Sharing

A federal spy watchdog says a senior RCMP official wrongly considered the importance of a strategic relationship with a foreign organization when deciding whether sharing information posed a risk of torture.

The aim of the Avoiding Complicity in Mistreatment by Foreign Entities Act is to prevent the brutalization of someone in overseas custody due to the information Canada exchanges with agencies abroad.

The RCMP and other federal agencies subject to these provisions must assess the risk of mistreatment and decide whether a risk can be managed.

In a report released Thursday, the National Security and Intelligence Review Agency (NSIRA) strongly cautions against including other considerations, such as fostering strategic relationships, in the assessment of substantial risk.

The intelligence review agency recommended that in cases where an RCMP assistant commissioner disagrees with a committee's recommendation not to share information, the case be automatically referred to the force's commissioner.

• Justice minister says RCMP has tools it needs to handle threats against politicians
• Intelligence watchdog calls out panel for failing to sound alarm on election interference

The heavily redacted report, the review agency's latest to examine the anti-torture protocol, covers the calendar year 2021.

The watchdog found the RCMP had "a robust framework" in place for the triage and processing of cases pertaining to the law aimed at avoiding complicity.

However, it raised pointed concerns about one case handled by the RCMP's foreign information risk advisory committee, an advisory body to senior management.

Details of the case, including the foreign entity involved, were stripped from the version of the report made public Thursday.

The committee concluded that there was a substantial risk of mistreatment should certain personal information be shared, and said the risk could not be managed by caveats and assurances.

As a result, the committee recommended that the information not be exchanged. It suggested exploration of additional options to reduce the potential risk of torture, so that members could reconsider the case.

RCMP official rejects recommendation

However, an assistant RCMP commissioner rejected the committee's recommendation and "allowed the sharing of information," the review agency report says.

The assistant commissioner reasoned, in part, that the RCMP should consider the consequences of not sharing, as this would be detrimental for the relationship, adding that "engagement ... will give insight and influence."

Ultimately, the senior official decided the risk could be mitigated, despite the committee's view to the contrary.

However, federal instructions for implementing the law clearly state that when officials are unable to determine whether the risk can be managed adequately, the matter must go to the RCMP commissioner for a final say.

• CSIS and Trudeau's adviser clashed on foreign interference threat in 2021: report
• Watchdog calls out 'gaps' in how Canada conducted online intelligence operations

The intelligence review agency concluded that "this case should have been elevated to the Commissioner for determination."

In a response included with the report, the RCMP disagreed with the call to automatically refer such cases to the commissioner, saying the intelligence review agency had "misinterpreted the roles and responsibilities" of the assistant commissioner with respect to the process.

The RCMP agreed that the decision to share information "should not include external objectives."

But the force added that for the assessment of substantial risk, these external objectives, such as relationship-building, "have been, and will continue to be, important in the totality of the information being considered."

The review agency also found that the RCMP did not have a centralized system of documenting assurances and did not regularly monitor and update the assessment of the reliability of assurances.

In addition, the watchdog notes the Mounties had not developed mechanisms to update country and entity profiles in a timely manner. "In many cases these assessments are more than four years old and are heavily dependent on an aggregation of open source reporting."

In its response, the RCMP said the force "has an established centralized system in place to track caveats and assurances provided by foreign entities."

The RCMP's record management system is where information from any follow-ups conducted with foreign entities — including any concerns about non-compliance with caveats and assurances — is included in respective operational files, the force added.