LARION General Risk Management Process PDF
Document Details
Uploaded by LuckyChalcedony1151
2024
Truc Du-Thi-Thanh
Tags
Summary
This document details a risk management process framework for LARION, last updated in August 2024. It describes different activities and sections including, security classification, document code, version, and change descriptions.
Full Transcript
--------------------------------- QM General Risk Management Process --------------------------------- -- -------------------------- ------------------------------ Security classification: INTERNAL Document code: LARION.QM.PRO.012 Last updated by: Truc...
--------------------------------- QM General Risk Management Process --------------------------------- -- -------------------------- ------------------------------ Security classification: INTERNAL Document code: LARION.QM.PRO.012 Last updated by: Truc Du-Thi-Thanh Effective date: Aug 05, 2024 Version: 2.0 Template ID: Process\_Base\_Template-1\_7 -- -------------------------- ------------------------------ Document Control +-----------+-----------+-----------+-----------+-----------+-----------+ | Version | Change | Changed | Date | Approved | Date | | | descripti | by | | by | | | | on | | | | | +-----------+-----------+-----------+-----------+-----------+-----------+ | 1.3 | Add | LanLH | Mar 31, | VinhTD | Apr 03, | | | "Security | | 2017 | | 2017 | | | Classific | | | | | | | ation: | | | | | | | INTERNAL" | | | | | | | at the | | | | | | | first | | | | | | | page for | | | | | | | this | | | | | | | document | | | | | +-----------+-----------+-----------+-----------+-----------+-----------+ | 1.4 | Update | TrucDTT | Oct 19, | HuyNQ | Oct 20, | | | Positive | | 2017 | | 2017 | | | Impact | | | | | | | Risk | | | | | | | (Opportun | | | | | | | ity) | | | | | | | Response | | | | | | | Methods | | | | | +-----------+-----------+-----------+-----------+-----------+-----------+ | 1.5 | Add | ThuyTT | Nov 30, | TrucDTT | Dec 04, | | | metrics | | 2017 | | 2017 | | | in | | | | | | | section 3 | | | | | +-----------+-----------+-----------+-----------+-----------+-----------+ | 1.6 | Delete | LanLH | Jan 09, | TrucDTT | Jan 09, | | | metrics | | 2018 | | 2018 | +-----------+-----------+-----------+-----------+-----------+-----------+ | 1.7 | \- Rename | TrucDTT | Jun 22, | HuyNQ | Jul 06, | | | "Risk | | 2023 | | 2023 | | | Register" | | | | | | | into | | | | | | | "Risk | | | | | | | Managemen | | | | | | | t | | | | | | | Report" | | | | | | | | | | | | | | \- Update | | | | | | | process | | | | | | | flow | | | | | | | | | | | | | | \- | | | | | | | Section | | | | | | | 5.4 | | | | | | | "Identify | | | | | | | Risks": | | | | | | | Add refer | | | | | | | to | | | | | | | Appendix | | | | | | | | | | | | | | \- Add | | | | | | | section | | | | | | | "Appendix | | | | | | | " | | | | | | | | | | | | | | \- Remove | | | | | | | section | | | | | | | "Process | | | | | | | Managemen | | | | | | | t" | | | | | +-----------+-----------+-----------+-----------+-----------+-----------+ | 1.7.1 | Update | TrucDTT | Jul 22, | N/A | N/A | | | content | | 2024 | | | | | at: | | | | | | | | | | | | | | \- | | | | | | | Section | | | | | | | 1.2.1. | | | | | | | "Audience | | | | | | | of This | | | | | | | Process": | | | | | | | Update | | | | | | | scope | | | | | | | include | | | | | | | Informati | | | | | | | on | | | | | | | Security | | | | | | | Managemen | | | | | | | t | | | | | | | System | | | | | +-----------+-----------+-----------+-----------+-----------+-----------+ | 2.0 | Approve | N/A | N/A | HuyNQ | Aug 05, | | | | | | | 2024 | +-----------+-----------+-----------+-----------+-----------+-----------+ Table of Contents Index of Tables Index of Illustration []{#anchor}Introduction ======================= []{#anchor-1}Purpose -------------------- This document describes a process framework for risk management regarding potential negative or positive impacts to the planned objectives of a project, program or organizational unit. The process is aimed to be adapted with different risk management strategies, instead of sticking to a specific risk management strategy. []{#anchor-2}Scope ------------------ ### []{#anchor-3}Audience Of This Process All managers responsible for a project, program, or an organizational unit which are under scope of the Quality Management System and Information Security Management System. ### []{#anchor-4}When To Use This Process This process should be applied whenever there are uncertainties exist, that cause impacts to achievement of the objectives responsible by a project, program or organizational unit. []{#anchor-5}[]{#anchor-6}Risks ------------------------------- The following risks relevant to the effectiveness and efficiency of this process, have been addressed as in followings: -- ---------------------------------------------------------------------------------------------------- Activity "Identify Risks" Activity "Monitor and Control Risk Treatment" Activity "Define Risk Management Strategy" ensure consistent risk categories are used for projects -- ---------------------------------------------------------------------------------------------------- ::: {.caption} Table 1: Risks of This Process ::: []{#anchor-7}Abbreviations & Definitions ---------------------------------------- - BoD: Board of Directors - HR: Human Resource - IT: Information Technology - ISMS: Information Security Management System - Senior manager: A senior manager who manage a Risk Owner - OSP: Organizational Standard Process - QM: Quality Management - SDD: Software Development Department - Organizational unit: Common terms for a unit in the corporate organizational chart. The unit shall be responsible for a specific area of operational functions, such as HR, Admin, IT,\... - Risk: An uncertainty that causes negative (threat) or positive impact (opportunity) to objective(s) - Risk Owner: A person or unit with the accountability and authority to manage a risk - Threat Source: Internal or external agent that bring a risk - Impact: An consequence on objective(s) - Probability (or Likelihood): Likelihood for a risk to occur - Risk Acceptance Level: Degree by which risk is acceptable or not. This level will drive decision for risk response methods - Risk Assessment: Overall activity consisting of risk identification, analysis and evaluation - Risk Analysis: Action to comprehend nature of risk, and to determine risk level - Risk Evaluation: Evaluating risk level against risk acceptance level, to decide about risk response - Risk Level (or Risk Value): A magnitude of a risk, which is a value calculated as following: Risk Level = Score of Risk Impact \* Score of Risk Probability - Risk Urgency (optional parameter of risk analysis): Indicator for earliness of occurrence of a threat or opportunity source causing the risk. Treatment for risks with lower urgency can be in latter time than treatment of those with higher urgency - Example: In software development project risks of product testing are in lower urgency than risks of product analysis and design - Risk Treatment: Action to modify risk level, by changing risk impact and / or risk probability - Contingency Plan: Plan to be executed when a risk actually occurs, in order to mitigate the consequences - Risk Control: Outcome of risk treatment actions that ensure mitigation of risks in a long term, and built into organizational processes. *Examples: A procedure requiring using proximity, to prevent unauthorized access to physical facilities* - Risk Management Strategy: An overall strategic plan for management risks affecting a specific project / program or operational unit - Risk Management Strategy helps to ensure the general risk management framework is tailored to suit to specific areas of operational objectives. In other side, one risk management strategy can be used by several projects / programs / operational units that have similar nature of objectives. []{#anchor-8}References ----------------------- ### []{#anchor-9}Policies -- Regulations 1. General\_Risk\_Management\_Strategy ### []{#anchor-10}Forms -- Templates 1. []{#anchor-11}Risk\_Management\_Report\_Template 2. []{#anchor-12}Risk\_Management\_Strategy\_Template 3. Risk\_Management\_Report\_InfoSec\_Template (Apply for ISMS Program) ### []{#anchor-13}Work Instructions -- Guidelines -- Checklists -- Conventions 1. []{#anchor-14}N/A ### []{#anchor-15}External Sources - ISO 31000:2009 - CMMI for Development 3^rd^ Edition (Risk Management process area) []{#anchor-16}Roles & Responsibilities ====================================== ----------------- ---------------- Role Responsibility Risk Owner Managers Senior Managers BoD ----------------- ---------------- ::: {.caption} Table 2: Roles & Responsibilities ::: []{#anchor-17}Process Characteristics ===================================== --------------------- ------------- Characteristic Description Entry Criteria Inputs Outputs Exit Criteria Affecting Processes Impacted Processes Tools & Techniques --------------------- ------------- ::: {.caption} Table 3: Process Characteristics ::: []{#anchor-18}Process Flow ========================== ![Illustration 1: Process Flow](Pictures/100000000000087B00000B80E21B2F2D.jpg) []{#anchor-19}Main-Process Details ================================== []{#anchor-20}Activity Details: Define Risk Management Strategy --------------------------------------------------------------- - Senior manager who is accountable for the business / operational objectives, shall be accountable for the relevant risk management strategy appropriate to those objectives - In case the strategy for the context is already defined at corporate level (*i.e. OSP*), the senior manager can tailor it to adapt to the specific needs, then get approval from BoD - Risk Owner ensures stakeholders affected by the objectives are communicated and understand of the approved Risk Management Strategy []{#anchor-21}Activity Details: Identify Risks {#illustration-2-position-of-risk-management-strategyactivity-details-identify-risks} ---------------------------------------------- - When the business / operational objectives are to be approved, or when there is explicit demands from stakeholders to know the risks associated with the objectives, Risk Owner ensures risks are identified, based on following information in the Risk Management Strategy: - Threat Sources and Opportunity Sources - Other criteria that drive risk identification - Risk Owner ensures appropriate details of identified risks are reviewed by the stakeholders relevant to the affected objectives - Risk Owner ensures details of identified risks are documented in Risk Management Report, using template [\[1\]](#anchor-11). Refer to Appendix below for risk identification and risk statement guidelines. []{#anchor-22}Activity Details: Analyze Risks --------------------------------------------- - When a risk is identified, Risk Owner ensures it is analyzed by qualified persons and roles. Analysis is done based on following information in the Risk Management Strategy: - Ranks of Risk Impact and ranks of Risk Probability, each must be divided into at least 5 ranks - Risk Level, which is calculated as following: Risk Level = Score of Risk Impact \* Score of Risk Probability - - Ranks of Risk Urgency (Risk Urgency is optional risk analysis parameters) - Risk Owner ensures result of risks analysis is documented in Risk Management Report (using template [\[1\]](#anchor-11)), and reviewed by the stakeholders of affected objectives []{#anchor-23}[]{#anchor-24}Activity Details: Evaluate Risks ------------------------------------------------------------ - Based on Risk Levels, Risk Owner decides risk acceptance level, conforming to the Risk Management Strategy - For risks of \'Unacceptable\' level, Risk Owner shall have to decide risk response strategy and treatment plan (per the next activities in this process) - For risks of \'Acceptable\' level, Risk Owner may either ignore the risks, or keep them in \'Watched\' status to continue monitoring - Risk Owner decides the risk response method for the risks that are unacceptable: - Risk Management Strategy may state a response strategy which require a certain risk response method, depending on risk acceptance level and other conditions (*for example,* "*Risk response method must be transferred or avoid, if its level is "highly unacceptable" and the cost of treatment is higher than one million dollars*") - Threat Response Method for a risk of negative impacts must be selected from one of the followings: ------------------------ ------------------------------------------------------------------------------------------------ Threat Response Method Description Avoid Eliminate all conditions causing the threat. Mitigate Take action to implement additional control to mitigate the probability or reduce impact. Transfer Transfer the risk to other asset owners or external parties. Accept Take no action. This should only be used when the impact or probability of risk is very small. ------------------------ ------------------------------------------------------------------------------------------------ ::: {.caption} Table 4: Threat Response Method ::: - - Opportunity Response Method for a risk of positive impacts must be selected from one of the followings: ----------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------- Opportunity Response Method Description Exploit The exploit strategy may be selected for risks with positive impact where the organization wishes to ensure that the opportunity is realized. Enhance The enhance strategy is used to increase the probability and/or the positive impact of an opportunity. Share Sharing a positive risk to a third party who is able to capture the opportunity. Accept Accepting an opportunity is being willing to take advantage of the opportunity if it arises, but not actively pursuing it. ----------------------------- ----------------------------------------------------------------------------------------------------------------------------------------------- ::: {.caption} Table 5: Opportunity Respond Method ::: - Risk Owner ensures result of risks evaluation is documented in Risk Management Report (using template [\[1\]](#anchor-11)), and reviewed by the stakeholders of affected objectives []{#anchor-25}[]{#anchor-26}Activity Details: Plan Risk Treatment ----------------------------------------------------------------- - Risk Owner ensures collaboration with stakeholders affected by the risk, to define risk treatment plan, as per the decided Risk Response Method - Risk treatment plan provides solution to effectively reduce the Risk Level in future - Optionally, the plan will specify the **expected risk level** (*i.e., expected Risk Impacts and expected Risk Probability*), to be achieved when treatment plan is fulfilled - Risk Owner ensures the treatment plan is breakdown to appropriate actions, in a manner that each action is comprehensible and responsible by a specific project/ organizational unit - Risk Owner ensures Risk Treatment Plan is documented (using template [\[1\]](#anchor-11)), reviewed by affected managers (responsible for the actions) before his / her approval - ***Caution:*** In case risk treatment plan imposes additional cost (beyond the cost baseline) to execute, additional to current budget, Risk Owner shall explicitly propose the cost estimates to get BoD\'s approval before execution []{#anchor-27}Activity Details: Monitor And Control Risk Treatment ------------------------------------------------------------------ - Per intervals specified in Risk Management Strategy, Risk Owner shall ensue periodical monitoring status of the planned treatment actions - Per intervals specified in Risk Management Strategy, Risk Owner report status of risk treatment actions and residual risks to Senior Manager and stakeholders of affected objectives - Risk Status - Since a risk is identified, it will go through its life cycle via different status, depicted in following table: *(**Note:*** S*ucceeding status are the ones that can be transited to, from the given status).* +-----------------------+-----------------------+-----------------------+ | New | Pending, Analyzed, | Risk is just | | | Expired | identified, and not | | | | yet analyzed. | +-----------------------+-----------------------+-----------------------+ | Pending | Analyzed, Expired | Risk is pending to be | | | | analyzed, due to its | | | | low urgency or its | | | | treatment is not yet | | | | feasible or necessary | | | | to execute. | +-----------------------+-----------------------+-----------------------+ | Analyzed | Evaluated, Watched | Risk is analyzed the | | | | first time and can be | | | | evaluated. | +-----------------------+-----------------------+-----------------------+ | In-Progress | Expired | Risk treatment plan | | | | is approved and / or | | | | in progress. | | | | | | | | The risk can be | | | | re-assessed several | | | | times during | | | | responding status, | | | | and according to | | | | that, its treatment | | | | plan can be updated | | | | several times. | +-----------------------+-----------------------+-----------------------+ | Closed | None (ending status) | Risk is no longer | | | | cause impact / | | | | completed plan risk | | | | treatment | +-----------------------+-----------------------+-----------------------+ ::: {.caption} Table 6: Risk status ::: []{#anchor-28}Activity Details: Re-assess Risks ----------------------------------------------- - Per intervals to re-assess risk (specified in Risk Management Strategy), Risk Owner shall involve relevant stakeholders to re-assess the risks being treated - The re-assessment shall take into accounts the effectiveness of risk treatment actions that have been done recently - By result of re-assessment, Risk Owner shall take appropriate actions, which can be one of followings, but not limited to: - If risk acceptance level changes to becomes \'unacceptable\', Risk Owner may update risk response method and / or treatment plan, as needed - If risk acceptance level changes to \'acceptable\', Risk Owner may cease the existing treatment actions, and optionally put the risk to \'Watched\' state - Risk Owner determines a risk is expired, only when any of following conditions is met: - The affected objectives are closed or no longer in effect - The source of threat / opportunity is proved to no longer exist []{#anchor-29}Appendix ====================== []{#anchor-30}What Information Should We Collect During The Risk Identification Step? ------------------------------------------------------------------------------------- Identifying risks involves considering what, when, why, where and how things can happen. More specifically: - **What are the sources of risk or threat** -- the things which have the inherent potential to harm or facilitate harm. - **What could happen** -- events or incidents that could occur whereby the source of risk or threat has an impact on the achievement of objectives. - **Where** -- the physical locations / assets where the event could occur or where the direct or indirect consequences may be experienced. - **When** -- specific times or time periods when the event is likely to occur and/or the consequences realised. How -- the manner or method in which the risk event or incident could occur. - **Causes** -- what are the direct and indirect factors that create the source of risk or threat. - **Business consequence**s -- what would be the impact on objectives if the risk was realised. Business areas / stakeholders affected -- what parts of the organization and what stakeholders might be involved or impacted? - **Existing controls** -- a preliminary review of existing controls should be undertaken to identify - **What controls currently exist** to minimize the likelihood and consequences of each risk? - **What vulnerabilities exist** that could undermine the effectiveness of the controls? *Note*: a detailed review is completed during the risk analysis process. []{#anchor-31}Risk Statement ---------------------------- - Based on these definitions, a risk statement should look something like: - (Event that has an effect on objectives) ****caused by**** (cause/s) ****resulting in**** (consequence/s) - An alternative version reads: - (Event that has an effect on objectives) ****caused by**** (cause/s). This may ****result in**** (consequence/s)