Quality Control & Compliance Initiative. This document is publicly available to any staff member on the following network path:

Similar documents
RISK MANAGEMENT. Budgeting, d) Timing, e) Risk Categories,(RBS) f) 4. EEF. Definitions of risk probability and impact, g) 5. OPA

1. Define risk. Which are the various types of risk?

Practical aspects of determining and applying a risk appetite for SMEs

Risk Management Plan for the <Project Name> Prepared by: Title: Address: Phone: Last revised:

EFFECTIVE TECHNIQUES IN RISK MANAGEMENT. Joseph W. Mayo, PMP, RMP, CRISC September 27, 2011

Risk Management Policy and Framework

M_o_R (2011) Foundation EN exam prep questions

Slide 3: What are Policy Analysis and Policy Options Analysis?

Delivering Clarity to Credit Unions Through Expertise and Experience

BERGRIVIER MUNICIPALITY. Risk Management Risk Appetite Framework

For the PMP Exam using PMBOK Guide 5 th Edition. PMI, PMP, PMBOK Guide are registered trade marks of Project Management Institute, Inc.

Project Risk Management

Risk Management Policy

MEMORANDUM. To: From: Metrolinx Board of Directors Robert Siddall Chief Financial Officer Date: September 14, 2017 ERM Policy and Framework

APPENDIX 1. Transport for the North. Risk Management Strategy

Managing Project Risks. Dr. Eldon R. Larsen, Marshall University Mr. Ryland W. Musick, West Virginia Division of Highways

Fraud Risk Management

Project Theft Management,

Risk Evaluation, Treatment and Reporting

Understanding Enterprise Risk Management: An Overview

Master Class: Construction Health and Safety: ISO 31000, Risk and Hazard Management - Standards

Business Auditing - Enterprise Risk Management. October, 2018

Best Practices in ENTERPRISE RISK MANAGEMENT. [ Managing Risks Holistically ]

Construction projects: manage risk to achieve success

Sections of the ORSA Report

INTERNATIONAL ASSOCIATION OF INSURANCE SUPERVISORS

Project Risk Management

UNIVERSITY OF ABERDEEN RISK MANAGEMENT FRAMEWORK

GOV : Enterprise Risk Management Policy

Fundamentals of Project Risk Management

Version: th November 2010 RISK MANAGEMENT POLICY

Procedures for Management of Risk

Table of Contents Advantages Disadvantages/Limitations Sources of additional information. Standards, textbooks & web-sites.

Risk Management Framework

Association for Project Management 2008

Job Safety Analysis Preparation And Risk Assessment

Risk Management User Guide. Prepared By: Neville Turbit Version Feb /01/2009 Risk Management User Guide Page 1 of 36

client user GUIDE 2011

SIL and Functional Safety some lessons we still have to learn.

ENTERPRISE RISK MANAGEMENT (ERM) The Conceptual Framework

Kidsafe NSW Risk Management Plan. August 2014

Appendix B: Glossary of Project Management Terms

Risk Management Policy and Procedures.

ENTERPRISE RISK MANAGEMENT (ERM) GOVERNANCE POLICY PEDERNALES ELECTRIC COOPERATIVE, INC.

The Central Bank of Ireland Risk Appetite: A Discussion Paper

Liquidity Policy. Prudential Supervision Department Document BS13. Issued: January Ref #

AN INTRODUCTION TO RISK CONSIDERATION

Scouting Ireland Risk Management Framework

Managing Project Risk DHY

Risk Assessment Policy

Risk Management Strategy

Project Selection Risk

Risk Management: Assessing and Controlling Risk

Nagement. Revenue Scotland. Risk Management Framework. Revised [ ]February Table of Contents Nagement... 0

Project Risk Management. Prof. Dr. Daning Hu Department of Informatics University of Zurich

BERMUDA MONETARY AUTHORITY THE INSURANCE CODE OF CONDUCT FEBRUARY 2010

Risk Assessment Mitigation Phase Risk Mitigation Plan Lessons Learned (RAMP B) November 30, 2016

Meeting of Bristol Clinical Commissioning Group Governing Body

LCS International, Inc. PMP Review. Chapter 6 Risk Planning. Presented by David J. Lanners, MBA, PMP

RISK MANAGEMENT FRAMEWORK

WHITE PAPER FOUR PRACTICAL WAYS TO CAPTURE AND MONITOR RISK APPETITE

The Evolution of Risk Management and The Risk Management Process

Planning Construction Procurement. A guide to risk and value management

Risk Management Strategy January NHS Education for Scotland RISK MANAGEMENT STRATEGY

The PRINCE2 Practitioner Examination. Sample Paper TR. Answers and rationales

Risk Management For Projects

REGULATORY GUIDELINE Liquidity Risk Management Principles TABLE OF CONTENTS. I. Introduction II. Purpose and Scope III. Principles...

INTERNATIONAL ASSOCIATION OF INSURANCE SUPERVISORS

ก ก Tools and Techniques for Enterprise Risk Management (ERM)

Subject SP9 Enterprise Risk Management Specialist Principles Syllabus

Procedure: Risk management

Project Management for the Professional Professional Part 3 - Risk Analysis. Michael Bevis, JD CPPO, CPSM, PMP

RESERVE BANK OF MALAWI

ENTERPRISE RISK MANAGEMENT POLICY FRAMEWORK

Chapter 7: Risk. Incorporating risk management. What is risk and risk management?

Risk Video #1. Video 1 Recap

ENTERPRISE RISK MANAGEMENT Framework

Risk Management at Central Bank of Nepal

INTERNAL CAPITAL ADEQUACY ASSESSMENT PROCESS GUIDELINE. Nepal Rastra Bank Bank Supervision Department. August 2012 (updated July 2013)

Executive Board Annual Session Rome, May 2015 POLICY ISSUES ENTERPRISE RISK For approval MANAGEMENT POLICY WFP/EB.A/2015/5-B

The Capital Expenditure Decision

Zurich Hazard Analysis (ZHA) Introducing ZHA

Navigating the New Normal Enterprise Risk Management After e-risk Identification and Assessment

TD BANK INTERNATIONAL S.A.

Module 6 Study Guide. PRINCE2 is a registered trademark of AXELOS Ltd.

Nagement. Revenue Scotland. Risk Management Framework

INTEGRATED RISK MANAGEMENT GUIDELINE

The Proactive Quality Guide to. Embracing Risk

Risk Management Policy. Apollo Hospitals. Risk Management Policy

SECTION II.7 MANAGING PROJECT RISKS

CONSTRUCTION ENGINEERING & TECHNOLOGY: EMV APPROACH AS AN EFFECTIVE TOOL

INSE 6230 Total Quality Project Management

Five-Day Schedule and Course Content

Special Considerations in Auditing Complex Financial Instruments Draft International Auditing Practice Statement 1000

Bournemouth Primary MAT Risk Management Policy

How to review an ORSA

Applying COSO s Enterprise Risk Management Integrated Framework

Project Management Certificate Program

2014 Own Risk and Solvency Assessment (ORSA) Feedback Pilot Project Observations of the Group Solvency Issues (E) Working Group

12 GeV CEBAF Upgrade. Risk Management Plan

Transcription:

Quality Control & Compliance Initiative RISK ASSESSMENT Author: Phonovation Quality Control Group Gavin Carpenter Effective Date: 20 th Nov 2013 Revised: 20 th Jan 2015 Revised by: To: Pedro Quintas All Phonovation Staff This document is publicly available to any staff member on the following network path: File:\\srvadmdc00\dev & it\quality Control\QC - Phonovation Risk Assessment.docx 1

Risk Policy Context Value is a function of risk and return. Every decision either increases, preserves, or erodes value. Given that risk is integral to the pursuit of value, strategic-minded enterprises do not strive to eliminate risk or even to minimize it, a perspective that represents a critical change from the traditional view of risk as something to avoid. Rather, these enterprises seek to manage risk exposures across all parts of their organizations so that, at any given time, they incur just enough of the right kinds of risk no more, no less to effectively pursue strategic goals. This is the sweet spot, or optimal risk-taking zone, referred to on the following graph: That s why risk assessment is important. It s the way in which enterprises get a handle on how significant each risk is to the achievement of their overall goals. To accomplish this, Phonovation require a risk assessment process that is practical, sustainable, and easy to understand. The purpose of this document is to provide guidance on selected Phonovation staff to improve Quality Control & Compliance objectives with an overview of risk assessment approaches and techniques that have emerged as the most useful and sustainable for decision-making. 2

Risk Assessment Process Within Phonovation Risk Assessment follows event identification and precedes risk response. Its purpose is to assess how big the risks are, both individually and collectively, in order to focus management s attention on the most important threats and opportunities, and to lay the groundwork for risk response. Risk assessment is all about measuring and prioritizing risks so that risk levels are managed within defined tolerance thresholds without being over controlled or forgoing desirable opportunities. Events that may trigger risk assessment include the initial establishment of the Company Risk Management Program, a periodic refresh, the start of a new project, a merger, acquisition, or divestiture, or a major restructuring. Some risks are dynamic and require continual ongoing monitoring and assessment, such as certain market and solution deployment risks. Other risks are more static and require reassessment on a periodic basis with ongoing monitoring triggering an alert to reassess sooner should circumstances change. 3

Identify risks The risk (or event) identification process precedes risk assessment and produces a comprehensive list of risks (and often opportunities as well), organized by risk category (financial, operational, strategic, compliance) and sub-category (market, credit, liquidity, etc.) for business units, corporate functions, and capital projects. At this stage, a wide net is cast to understand the universe of risks making up the enterprise s risk profile. While each risk captured may be important to management at the function and business unit level, the list requires prioritization to focus senior management and board attention on key risks. This prioritization is accomplished by performing the risk assessment. Develop assessment criteria The first activity within the risk assessment process is to develop a common set of assessment criteria to be deployed across business units, corporate functions, and large capital projects. Risks and opportunities are typically assessed in terms of impact and likelihood. Many enterprises recognize the utility of evaluating risk along additional dimensions such as vulnerability and speed of onset. Assess risks Assessing risks consists of assigning values to each risk and opportunity using the defined criteria. This may be accomplished in two stages where an initial screening of the risks is performed using qualitative techniques followed by a more quantitative analysis of the most important risks. Assess risk interactions Risks do not exist in isolation. Enterprises have come to recognize the importance of managing risk interactions. Even seemingly insignificant risks on their own have the potential, as they interact with other events and conditions, to cause great damage or create significant opportunity. Therefore, enterprises are gravitating toward an integrated or holistic view of risks using techniques such as risk interaction matrices, bow-tie diagrams, and aggregated probability distributions. Prioritize risks Risk prioritization is the process of determining risk management priorities by comparing the level of risk against predetermined target risk levels and tolerance thresholds. Risk is viewed not just in terms of financial impact and probability, but also subjective criteria such as health and safety impact, reputational impact, vulnerability, and speed of onset. 4

Respond to risks The results of the risk assessment process then serve as the primary input to risk responses whereby response options are examined (accept, reduce, share, or avoid), cost-benefit analyses performed, a response strategy formulated, and risk response plans developed. Develop Assessment Criteria Traditional risk analysis defines risk as a function of likelihood and impact. Indeed, these are important measures. However, unlikely events occur all too often, and many likely events don t come to pass. Worse, unlikely events often occur with astonishing speed. Likelihood and impact alone do not paint the whole picture. To answer questions like how fast could the risk arise, how fast could you respond or recover, and how much downtime could the company tolerate, Phonovation need to gauge vulnerability and speed of onset. By gauging how vulnerable Phonovation is to an event, we develop a picture of our needs. By gauging how quickly it could happen, we understand the need for agility and rapid adaptation. Who should carry out Risk Assessment? It is the employer s duty to carry out the risk assessment. Quality Control & Compliance Group held a specialized team of staff to execute the Risk Assessment, while involving managers and employees as much as possible. Where the in-house expertise is not available, employ the services of an external competent person to help. Involve as many employees as possible in order to encourage them to share ownership of the finished assessments. High-level brainstorming Phonovation Quality Control & Compliance Group should start by doing some high-level brainstorming about the company s risks and who the stakeholders are: Who are our customers? Which business areas interact directly with those customers or their data? What laws and regulations apply to our industry and company? Who has oversight over those laws and regulations? Which business areas are interacting directly with regulators? Who are our competitors and what are they doing regarding innovation, regarding overall direction of the industry and regarding privacy? What issues have we previously experienced or seen? Where has the company had issues or risk? What keeps us up at night? What keeps our Corporate Services Suite up at night? What is likely to land the company on the front of a newspaper? 5

This brainstorming will help jumpstart the process of what areas you need to talk to later on in our risk-assessment process. Developing Assessment Scales Some form of measurement of risk is necessary. Without a standard of comparison, it s simply not possible to compare and aggregate risks across the organization. Most organizations define scales for rating risks in terms of impact, likelihood, and other dimensions. These scales comprise rating levels and definitions that foster consistent interpretation and application by different constituencies. The more descriptive the scales, the more consistent their interpretation will be by users. The trick is to find the right balance between simplicity and comprehensiveness. Scales should allow meaningful differentiation for ranking and prioritization purposes. Five point scales yield better dispersion than three point scales. Ten point scales imply precision typically unwarranted in qualitative analysis, and assessors may waste time trying to differentiate between a rating of six or seven when the difference is inconsequential and indefensible. Illustrative scales are provided for impact, likelihood, vulnerability, and speed of onset. 6

Impact Impact (or consequence) refers to the extent to which a risk event might affect the enterprise. Impact assessment criteria may include financial, reputational, regulatory, health, safety, security, environmental, employee, customer, and operational impacts. Enterprises typically define impact using a combination of these types of impact considerations (as illustrated below), given that certain risks may impact the enterprise financially while other risks may have a greater impact to reputation or health and safety. When assigning an impact rating to a risk, assign the rating for the highest consequence anticipated. For example, if any one of the criteria for a rating of 5 is met, then the impact rating assigned is 5 even though other criteria may fall lower in the scale. Some entities define impact scales for opportunities as well as risks. 7

Likelyhood Likelihood represents the possibility that a given event will occur. Likelihood can be expressed using qualitative terms (frequent, likely, possible, unlikely, rare), as a percent probability, or as a frequency. When using numerical values, whether a percentage or frequency, the relevant time period should be specified such as annual frequency or the more relative probability over the life of the project or asset. Sometimes enterprises describe likelihood in more personal and qualitative terms such as event expected to occur several times over the course of a career or event not expected to occur over the course of a career. 8

Vulnerability Vulnerability refers to the susceptibility of the entity to a risk event in terms of criteria related to the entity s preparedness, agility, and adaptability. Vulnerability is related to impact and likelihood. The more vulnerable the entity is to the risk, the higher the impact will be should the event occur. If risk responses including controls are not in place and operating as designed, then the likelihood of an event increases. Assessing vulnerability allows Phonovation to gauge how well we re managing risks. Vulnerability assessment criteria may include capabilities to anticipate events such as scenario planning, real options, capabilities to prevent events such as risk responses in place, capabilities to respond and adapt quickly as events unfold, and capabilities to withstand the event such as capital buffer and financial strength. Other factors can also be considered such as the rate of change in the industry or organization. There is no one-size-fits-all assessment scale. Every entity must define scales to meet its needs. 9

Speed of Onset / Velocity Speed of onset refers to the time it takes for a risk event to manifest itself, or in other words, the time that elapses between the occurrence of an event and the point at which the company first feels its effects. Knowing the speed of onset is useful when developing risk response plans. Inherent and Residual Risk When assessing risks, it s important to determine whether respondents will be asked to assess inherent risk, residual risk, or both. Inherent risk is the risk to an entity in the absence of any actions management might take to alter either the risk s likelihood or impact. Residual risk is the risk remaining after management s response to the risk. Applying this concept is trickier than it might seem at first glance. 10

Assess Risks Risk assessment is often performed as a two-stage process. An initial screening of the risks and opportunities is performed using qualitative techniques followed by a more quantitative treatment of the most important risks and opportunities lending themselves to quantification (not all risks are meaningfully quantifiable). Qualitative assessment consists of assessing each risk and opportunity according to descriptive scales as described in the previous section. Quantitative analysis requires numerical values for both impact and likelihood using data from a variety of sources. The quality of the analysis depends on the accuracy and completeness of the numerical values and the validity of the models used. Model assumptions and uncertainty should be clearly communicated and evaluated using techniques such as sensitivity analysis. Phonovation uses Quantitative analysis based on Risk Rating: Risk Rating = ( Likelihood of risk occurring ) X ( Impact of the risk occurring ) In Phonovation Quantitative Risk Model, risk is treated as a function of three variables: Likelihood of a type of a risk may occur, rated 1 to 5. Impact to the business of the risk occurring, rated 1 to 5. Risk Rating (Exposure) is calculated by multiplying the Likelihood by the Impact. Risk Rating Thresholds and Actions Low: 1 8 Any rating less than 8 does not get considered as it is possible to contemplate everything as a risk thus we just accept these risks (see Risk Acceptance below) Any rating calculated at 3 should be clearly noted and monitored to ensure the risk does not occur or if the risk rating should increase then the appropriate action is taken (see below). Medium: 9 16 Any rating calculated as medium should be clearly noted and have a clear action plan should the risk occur. High: 17-25 Any rating calculated as high should have a clear action plan to reduce the risk as this is exposure is unacceptable to the organization. 11

Assess Risk Interactions ERM 1 enables an integrated and holistic view of risks. The key here is that the whole does not equal the sum of the parts. To understand portfolio risk, one must understand the risks of the individual elements plus their interactions due to the presence of natural hedges and mutually amplifying risks. Understanding risk interactions and then managing them requires breaking down silos. A simple way to consider risk interactions is to group related risks into a broad risk area (such as grouping risks related to sourcing, distribution channels, vendor concentrations, etc., into supply chain risk) and then assigning ownership and oversight for the risk area. Three explicit ways to capture risk interactions increasing in level of complexity and richness of information are risk interaction maps, correlation matrices, and bow-tie diagrams. Risk Interaction Map A risk interaction map is the simplest form of graphical representation in which the same list of risks form the x and y axes. Risk interactions are then indicated by an X or other qualitative indicator. 1 ERM Enterprise Risk Management 12

Where historical data are available, risk interactions can be expressed quantitatively using a correlation matrix. This is an especially useful technique to apply within a risk category such as market risk. Difficulties in determining correlations for risks include the possibility that past causal relationships will not be indicative of future relationships, lack of historical data, differences in time frames (short-, medium-, and long-term), and the large numbers of risks required for an enterprise-wide assessment. Fault Trees, Event Trees, and Bow-Tie Diagrams Diagrams that break a complex risk occurrence into its component parts showing the chains of events that could lead to or result from the occurrence can be indispensable for identification and assessment of risk responses and key risk indicators. The diagrams can be qualitative or serve as the basis for quantitative models. Three commonly used diagrams are fault trees, event trees, and bow-ties. Fault trees are used for analysing events or combinations of events that might lead to a hazard or an event. Event trees are used for modelling sequences of events arising from a single risk occurrence. A bow-tie diagram combines a fault tree and an event tree and takes its name from its shape. Probabilistic models built on bow-tie diagrams are versatile for quantifying inherent and residual risk levels and performing what-if, scenario, and sensitivity analyses. Phonovation Quality Control & Compliance Group should use bow-tie diagrams to reduce risk complexity analysis like show below: 13

Prioritize Risks Once the risks have been assessed and their interactions documented, it s time to view the risks as a comprehensive portfolio to enable the next step prioritizing for risk response and reporting to different stakeholders. The term risk profile represents the entire portfolio of risks facing the enterprise. Some entities represent this portfolio as a hierarchy, some as a collection of risks plotted on a heat map. Entities with more mature ERM programs and quantitative capabilities may aggregate individual risk distributions into a cumulative loss probability distribution and refer to that as the risk profile. Similar to assessing risks, ranking and prioritizing is often done in a two-step process. First, the risks are ranked according to one, two, or more criteria such as impact rating multiplied by likelihood rating or impact multiplied by vulnerability. Second, the ranked risk order is reviewed in light of additional considerations such as impact alone, speed of onset, or the size of the gap between current and desired risk level (risk tolerance threshold). If the initial ranking is done by multiplying financial loss by likelihood, then the final prioritization should take qualitative factors into consideration. Risk Maps A simple way to view the portfolio is to create a risk map, often called a heat map. These are usually two-dimensional representations of impact plotted against likelihood. They can also depict other relationships such as impact versus vulnerability. For even richer information, the size of the data points can reflect a third variable such as speed of onset or the degree of uncertainty in the estimates. The most common way to prioritize risks is by designating a risk level for each area of the graph such as very high, high, medium, or low, where the higher the combined impact and likelihood ratings, the higher the overall risk level. The boundaries between levels vary from entity to entity depending on risk appetite. For example, an entity with a greater risk appetite will have boundaries between risk levels shifted toward the upper right, and an entity with greater risk aversion will have boundaries between risk levels shifted toward the bottom left. Also, some entities adopt asymmetric boundaries placing a somewhat greater emphasis on impact than on likelihood. For example, a risk having an impact rating of moderate and likelihood rating of frequent has an assigned risk level of high, whereas a risk having an impact rating of extreme and a likelihood rating of possible has an assigned risk level of very high. After plotting on the heat map, risks are then ranked from highest to lowest in terms of risk level. These rankings may then be adjusted based on other considerations such as vulnerability, speed of onset, or detailed knowledge of the nature of the impact. For example, within a group of risks having a designation of very high, those risks having extreme health and safety or reputational impacts may be prioritized over risks having extreme financial impacts but lesser health and safety or reputational impacts. When using numerical ratings in a qualitative 14

environment, it s important to remember that the numbers are labels and not suitable for mathematical manipulation although some entities do multiply the ratings, such as for impact and likelihood, to develop a preliminary ranking. Where entities have defined impact scales for both opportunities and risks, they may plot risks on a map such as that illustrated below. This allows a direct comparison of the highest rated opportunities and risks for consideration and prioritization. The following example should be considered as a guideline for Phonovation Quality Control & Compliance Group to plot risks on a map: Example context: a company identified 60 risks to include in its risk universe. It then determined appropriate assessors. It used a combination of interviews, workshops, and a survey to perform an initial qualitative assessment of impact, likelihood, vulnerability, and speed of onset criteria. Risk interactions were evaluated for the highest risks and the assessments were refined. Risks were plotted on a heat map to perform an initial prioritization. Twelve risks plotted in the Very High risk level designated as red in the below heat map. These risks were designated key risks meaning that they will be reported to and monitored by executive leadership and the board of directors. 15

Respond to Risks There are four types of risk actions Phonovation can take once a risk rating has been established. Avoidance Reduction Transfer Accept Risk Avoidance Assumes risk is within control of the organisation Assumes organisation has resources and authority and resources to deal with it Change the business process to avoid the risk This can be used for: low to medium risks. Risk Reduction Unlikely to be able to eliminate risk thus most common strategy o Reduce probability o Reduce impact This is to be used for medium and high risks. Risk Transfer Risk passed to third party e.g. insurance company This can be used for medium and high risks. Risk Acceptance For low probability, low impact Accept the risk Phonovation will accept the risk if the preventative costs are high than possible losses This can be used for: low to medium risks. 16

Privacy Risk Matrix The following table provides an overview of possible privacy risks to which Phonovation may be exposed. A breach occurring in any one of these 10 principles may have a detrimental effect on your bottom line. Ignoring these issues only increases the risks to Phonovation. 17

Privacy Risk Register Risk Information This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure. Project Management Team Decision This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure. Risk Closure This table describes detailed information about risks, project management team decisions, tracking and control, and risk closure. 18

Privacy Risk Register Definition This table describes the columns heading and descriptions in the project risk log Column Heading Risk # Date Opened Risk OPI Risk Description Risk Category Probability Impact Risk Treatment Strategy Priority Risk Management Plan Risk Status Date Closed Issue # Lessons Learned Description The unique number of the risk being documented and managed. # is assigned by the Project Manager or delegated Risk Manager. Date when the risk is identified and OPI is assigned. Name of the person assigned to develop, implement and manage the risk response plan. A brief description of the risk. Category or group to which the risk belongs. E.g. Business, Application, Project Management Process, etc. See Taxonomy worksheet for more examples. (H)igh = >75% chance of occurring. (M)edium = 25 to 75% chance of occurring. (L)ow = <25% chance of occurring. Impact of the risk: (H)igh, (M)edium, (L)ow. (A)ccept: take no action as risk probability and impact are low. (M)itigate: take steps to reduce the probability and/or impact of the risk. (T)ransfer: assign the risk to an external body outside of the project. (E)liminate: take steps to completely eliminate the risk. (H)igh, (M)edium, (L)ow. Brief description of the Risk Management Plan to be implemented to manage the risk. Open = Risk is being managed. Closed = Risk is no longer being managed. Date the risk is closed. If a risk is realized, most often, it becomes an issue. If it becomes an issue, the risk is closed and is recorded in the Issue Log. Record the associated issue # here. Risks that become issues remain in the Risk Log. Yes or No: were lessons learned from the management of the risk? Optional summary text may be added. 19

Privacy Risk Register Taxonomy The following includes some examples of risk categories and risks. These are intended to help during the risk identification stage. It s not a complete list but is offered for suggestion only. A. Product Development Think about risks to the project that may arise from the nature of the product being developed. 1 Requirements Are there risks that may arise from requirements being placed on the product? Stability Completeness Clarity Validity Feasibility Precedent Scale 2 Design Are there risks that may arise from the design chosen to meet the project's requirements? Functionality Difficulty Interfaces Performance Testability Hardware constraints Non-development software 3 Code and Unit Test Are there risks that may arise from the method chosen to subdivide the design and construct the pieces? Feasibility Testing Coding/implementation 4 Integration and Test Are there risks that may arise from the way the project team is choosing to bring the pieces together and prove that they work as a whole? Examples of risk areas: hardware and software support facilities; integration of parts of the product; integration with the larger system. Environment Product System 5 Non-Functional Attributes (formerly : Functional Attributes) Are there risks that may arise from special attributes of the product? Maintainability Reliability Safety Security Human Factors 6 Development Process Are there risks that may arise from the process being used to develop the product? Formality Suitability Process control Familiarity Product control 7 Development System Are there risks that may arise from the hardware and software tools being used to control and facilitate the development process? Capacity Suitability Usability Familiarity Reliability System support 20

Deliverability 8 (Other) Are there other risks that may arise from the nature of the product, but that are not covered by the above categories? B. Project Management Think about risks to the project that may arise from the way the product is being developed. 1 Project Management Process Are there risks that may arise from: the way the project budget or schedule is planned, monitored, or controlled; management experience; the project's organizational structure; or the way that internal and external organizational interfaces are handled? Planning Project organization Mgmt. experience Program interfaces 2 Management Methods Are there risks that may arise from the way the development or project personnel are managed? Risks may occur in areas such as status monitoring, personnel management, quality assurance, or configuration management. Monitoring Personnel Mgmt. QA Configuration Mgmt. 3 Work Environment Are there risks that may arise from the general environment in which the project is found? Risks may arise from areas such as attitude, cooperation, communication, and morale. Attitude Cooperation Communication Morale 4 (Other) Are there other risks that may arise from the way the project is being developed that are not covered by the above categories? C. Project Constraints Think about risks to the project that may arise from sources outside the project team's control. 1 Resources Are there risks that may arise because of resources needed for the project that cannot be obtained or maintained? Schedule Staff (HR) Budget Facilities 2 Contract Are there risks that may arise from the [already legally] binding contract? Type Restrictions Dependencies 3 Project Interfaces Are there risks that may arise from outside interfaces that the project team cannot reasonably expect to control? Customer Associate contractors Sub-contractors Prime contractors Corporate Mgmt. Vendors Politics 4 Legal or Regulatory Are there risks associated with legal or regulatory requirements? Privacy Are there risks associated with the privacy of employees, contractors or the Canadian public? 5 Security Are there risks associated with security, protection of assets, documents, data, etc? 6 Other Are there risks that may arise from factors outside the project team's control, but that are not covered by the categories above? 21