Any risk comes with it entrepreneurial activity.

During the implementation of the project, operational activities, investment activities and financial activities. All types of activities are associated with typical risks of any investment project.

The IP may provide for certain stabilization mechanisms that ensure the protection of IP participants in the event of an unfavorable change in the conditions of its implementation, measures to reduce the level of risks and their compensation. If we are talking about internal risks, then it is possible to reduce the degree of risk itself (due to additional costs for creating reserves and stocks, improving technology and reducing production accidents, due to material incentives to improve product quality, creating reserve capacities, etc.) When implementing IP implementation of IS, it is possible to reduce the degree of risk through financial incentives for IT service workers and other employees involved in working with the new IS, as well as through additional costs for creating reserves and inventories, conducting trial operation of the IS, etc.

The use of any stabilization mechanisms requires additional costs, the amount of which depends on the conditions of the project, the interests of its participants and assessments of the degree of risk. It is necessary to take into account different values ​​of the risk premium depending on the goals of the project and the factors influencing its implementation. The larger the implementation project (for example, a corporate IP implementation project), the higher the level of risk.

All risks associated with the implementation of IP, depending on the sources of occurrence and the possibility of elimination, can be divided into external (objective, systematic, or non-diversifiable) and internal (subjective, non-systematic, or diversifiable).

External and internal risks are interconnected.

External risks do not depend on a specific enterprise or individual entrepreneur. These risks are present at all stages of IP implementation. They arise as a result of external events affecting the market as a whole, affect the income of all enterprises for all individual entrepreneurs and cannot be completely eliminated by diversification.

External risks include: political, legislative, macroeconomic, natural disaster risks (force majeure risks). Country risk is often included in the discount rate to take into account external risks.

Internal risks caused by factors specific to a given enterprise or individual entrepreneur. These risks affect the income of individual enterprises for individual IP and differ at different stages of IP. These can be largely eliminated through diversification.

For IP, specific factors causing internal risks include the following:

exceeding the deadlines for putting the IS into operation and the implementation budget;

a significant increase in the timing of IS implementation;

changes in the need for software and hardware, lack of human resources, etc.;

interruptions in the supply of purchased hardware, lack of attracted consultants or the level of their competence;

loss of contracts as a result of incorrect debugging or interruptions in the operation of the IS;

accidents and failures in hardware or software, etc.

Based on their structural characteristics, internal risks include:

1 property risks associated with the likelihood of loss of property of an enterprise or individual entrepreneur for various reasons (due to theft, fire, negligence);

2 production risks associated with losses due to production stoppages due to the influence of various factors, and above all damage to fixed and working capital, as well as risks associated with the introduction of new equipment and new technologies into production (for example, the introduction of new IP);

3
commercial risks associated with losses due to delays in payments, refusal to pay during the transportation of goods, non-delivery of raw materials and components or their delivery deviation from the planned terms, etc.;

4 financial risks associated with the likelihood of loss of financial resources due to irrational investment of capital.

At different phases of IP implementation, various internal risks occur.

Let's look at typical errors that occur at the decision-making stage on the implementation of IP.

1 Weak development of the automation strategy (the enterprise lacks a holistic long-term IT strategy that corresponds to the scale and growth rate of its business).

2 Passion for fashion trends in relation to certain products when choosing IP.

3 Search for an ideal that perfectly meets the specifics of the enterprise.

4 Lobbying for the implementation of IS by one of the divisions of the enterprise - the consequence may be a discrepancy between the system and the needs of other key divisions.

5 Incorrect preparation of the tender task - the task is drawn up not according to the key requirements for IP, but by simply collecting and summarizing applications from all departments. This approach, as a rule, takes into account only the current requirements of departments, and not the strategic goals of the company as a whole.

The most common mistake when choosing IP is a passion for the technical side of the matter to the detriment of functional expediency, dictated by the final goals of implementation. To ensure that the assessment is not one-sided, it is necessary from the very beginning to involve employees of “subject” departments, as well as senior management of the company, in the selection of the system.

At the implementation stage The most serious risks of the project are the following.

1 Unpreparedness of the enterprise's top management for changes in the enterprise's business processes and organizational structure.

2 Unsuccessful selection of external consultants for the project (based on the principle of minimum cost or based on partnerships with a specific software supplier). When choosing a project executor - consultant, the following criteria must be observed: professionalism, reliability and predictability of results.

3 The influence of the human factor in the process of project implementation (changes in technology, work regulations and formats, the need to take into account the reaction of employees to implementation).

4 Delegation of key management and executive powers to the IT department. The project team must include key employees from all “subject” departments, who will then work with the implemented system.

It should be noted that recommendations for overcoming difficulties in the implementation and operation of information systems should be developed based on the specifics of the activities of a particular enterprise. First of all, the management of the enterprise and the IT service must realize that in the future the enterprise will have to make constant efforts to improve the information system. The transition from the “design mode” of operation to the improvement and modification phase represents a significant problem for some enterprises, the solution of which requires careful study and planning. An important task in risk research is to determine the stage at which a particular risk is more likely to occur.

At the implementation stage the risks inherent in the previous stages of the project, the so-called production risks, begin to fully manifest themselves. To these are also added “end-to-end” risks that occur at almost every stage of the project. Cross-cutting risks include, first of all, internal political risks - often an IP implementation project serves as a lever for political struggle in an enterprise. If the project affects the sphere of vital interests of large teams and senior managers who control property, commodity and cash flows, then even with ideal planning and organization of implementation, significant problems may arise.

There is also end-to-end risk associated with the distribution of workload between the client and the consultant. The share of work performed by consultants should decrease during the course of the project, otherwise the customer enterprise will have difficulties in further operating the IS without consultants. The project may also develop poorly due to the influence of the human factor (staff resistance, psychological fatigue from the project), as well as due to ineffective communications established within the enterprise.

Rejection of the project by staff, as a rule, arises due to a lack of information: the management of the enterprise is not aware of what the project team is doing, and employees do not see the point in implementation at all. Timely and regular explanatory work, which should be the responsibility of the project team members, can overcome the negative attitude of staff.

After completion of the project, long-term risks begin to appear that impede the effective use and further development of IP in the enterprise. The main long-term risks arise from inadequate support for external and internal changes. An important long-term risk is associated with the human factor - the end of consultants' participation in the project. In addition, there is a risk of information security violation - a possible leak of commercial information from the company.

Leadership among long-term risks (both in terms of the severity of damage and the complexity of minimization) belongs to factors associated with the reorganization of the enterprise, as well as the loss of flexibility of business processes.

However, long-term risks have a minor impact on the IS life cycle. First of all, competent planning and successful implementation of IS is necessary.

The point of describing the risks of IT projects is to identify these risks in advance and carry out a set of preventive measures before the start of the project. It is advisable to divide the main measures aimed at preventing the occurrence risky situations in IT projects:

1 mandatory documentation of the project’s goals, as well as all changes in the project documentation that arise during its implementation;

2 increasing employee motivation through financial incentives;

3 attraction of third-party qualified specialists;

4 training team members and senior management of the enterprise in project management methodology, etc.

Among the risks characteristic of all IP implementation, the following can be identified:

1 design risks when creating a system (incorporated during the design of the IS);

2 organizational risks (including the impact of the human factor on the process of implementation and operation of the IS, as a result - incorrect interpretation of data processed using the IS);

3 technical risks consisting of downtime, failures, loss or corruption of data, etc.;

4 risks of business losses (business risks) associated with the operation of the system (arising as a result of technical risks).

Project risks appear at the design or delivery stage of the IP. These may include, for example, the risk of obsolescence of certain software or technical solutions, as well as the risks of delays in the delivery of IS components. However, taking into account the relatively short period of time required for the delivery and implementation of an IS, as well as the conditions for the implementation of such projects, where, as a rule, all issues related to delivery and implementation are resolved by one supplier company, the likelihood of such risks is low.

The cost of organizational risks can be assessed through expert analysis. Many of the organizational risks, with a sufficient probability of occurrence, can reduce the entire effect of automation to zero or even reveal harm from automation, so their analysis must be approached with particular care.

The most obvious organizational risks include the following.

1 Sabotage of personnel. This risk negates all efforts to implement IP. It can arise for many reasons: for example, fear of losing a job due to a planned staff reduction, the desire to hide the real results of the work of a particular employee, to avoid identifying incompetence, etc.

2 Erroneous conclusions drawn based on the analysis of data obtained as a result of the operation of the IS, i.e. incorrect interpretation of data processed in the IS.

3 Transfer of information accumulated in the system to competitors as a result of theft or betrayal by personnel, etc.

The planned work of the enterprise IT service, as well as the strategic development and planning department, should include the development of recommendations for reducing the risks of the IS implementation project. It is also necessary to conduct trial operation of the IS, work with qualified consultants and reliable equipment suppliers, and include additional payments to employees involved in working with the IS in the preliminary cost estimate for the IS implementation project. Important factors for minimizing risks are also: the attentive attitude of top management to IP implementation of IP and the preliminary development of the overall enterprise automation strategy

At the moment, there is no unified classification of enterprise project risks. However, we can highlight the following main risks inherent in the project of opening and developing a corporate training center.

Since it is inappropriate to consider all the risks of creating software at this stage of opening an “It - progress” enterprise, it is necessary to analyze the risks of opening an enterprise engaged in the development and sale of software.

Table 2.1 - Risks of opening a development enterprise software

Continuation of Table 2.1

Delphi method similar to method brainstorming, but its participants do not know each other. The facilitator collects expert responses using a list of questions to elicit ideas about project risks. The experts' responses are then analyzed, categorized and returned to the experts for further comments. Consensus and a list of risks are obtained through several cycles of this process. The Delphi method eliminates peer pressure and the fear of embarrassment when expressing an idea.

The project risk register contains information in tabular, easy-to-read form about known, identified project risks. The project risk register should always contain up-to-date information, the quality of the project team’s work with risks fully depends on this. Typically, the project risk register contains the following information:

• ID— unique identification number of the project risk. When used, this number must match the risk ID specified in the PMIS.
• Description of the risk— detailed description of the project risk.
• Category— risk category in accordance with the KSUP. For example, investment risk, technological risk, risk associated with the project team, etc.
• Type— type of risk: positive or negative. Positive risks play into the hands of the project team and carry additional benefits that allow the project to be implemented faster. Negative risks, on the contrary, reduce the likelihood of successful completion of the project.
• Influence— the degree of influence of risk on one of the four key parameters of the project: cost, timing, content or quality. Typically evaluated with values ​​of 0.05, 0.1, 0.2, 0.4, 0.8.

• Overall Impact— the overall impact of risk depends on the chosen model ( max— the maximum value is used, avg- the average value is used) and is determined based on the impact of risk on four parameters.
• Probability— probability of risk occurrence. Typically evaluated with values ​​of 0.1, 0.3, 0.5, 0.7, 0.9.
• Meaning- actually the amount of risk, calculated as the product Overall influence on Probability.
• Strategy— risk response strategy. One of seven strategies is selected. For negative risks: evasion, reduction, sharing. For positive risks: transmission, use, amplification. For all risks: Adoption.
• Events— description of risk management measures in accordance with the selected response strategy.
• Responsible— Full name of the project team member responsible for working with the risk.

R 50.1.084-2012 Risk management. Risk register. Guide to Creating an Organizational Risk Register

set bookmark

set bookmark

Risk management

RISK REGISTER

Guide to Creating an Organizational Risk Register

Risk management. Risk register. Guidelines on construction of organization risk register

Date of introduction 2013-12-01

Preface

1 DESIGNED Autonomous non-profit organization"Research Center for Control and Diagnostics technical systems" (ANO "NIC KD")

2 INTRODUCED by the Technical Committee for Standardization TC 10 "Risk Management"

3 APPROVED AND ENTERED INTO EFFECT by Order of the Federal Agency for Technical Regulation and Metrology dated November 29, 2012 N 1283

4 INTRODUCED FOR THE FIRST TIME

Information about changes to these recommendations is published in the annual index "Guiding documents, recommendations and rules", and the text of changes and amendments is published in the monthly information index "National Standards". In case of revision (replacement) or cancellation of these recommendations, the corresponding notice will be published in the monthly information index "National Standards". Relevant information, notices and texts are also posted in information system for general use - on the official website of the Federal Agency for Technical Regulation and Metrology on the Internet

Introduction

A risk register is one of the ways to present and store information about hazardous events and risks. The presence of a risk register allows an organization to obtain information related to a specific source of danger, consequences, object of influence of hazardous events, etc. However, developing a risk register, especially when there is large quantity sources of danger, requires a lot of effort, time, financial resources, as well as a large amount of information.

The organization determines the need to develop and maintain a risk register independently.

3.2 risk register(risk register): A form for recording information about an identified risk.

NOTE The term "risk log" is sometimes used instead of the term "risk register".

3.3 danger(hazard): A source of potential harm.

NOTE Hazards can be a source of risk.

3.4 risk manager(risk manager): Specialist in identification, assessment, analysis, processing, monitoring of risk, as well as other activities in the field of risk management of an organization.

4 The procedure for developing an organization’s risk register

4.1 General provisions

The organization must determine the need for development, stages, form and methods of maintaining a risk register. The main goals of developing an organization's risk register, its place in the risk management system, the advantages and disadvantages of the risk register are established in GOST R 51901.21.

An organization's risk register is a form of maintaining records of identified hazardous events, assessment of the corresponding risk, methods and timing of its processing. When maintaining a risk register, it is necessary to take into account the relevant mandatory requirements, as well as other available information about the types of hazards and the risk of its occurrence. Depending on the characteristics of the organization, the form and content of the risk register can be changed or supplemented in relation to the standard form of the risk register given in Table 1 GOST R 51901.22.

When developing an organization's risk register, it is necessary to consider:

• the organization's risk management policy, goals and strategy;
• features of the products manufactured and services provided by the organization;
• basic production processes and organizational management processes;
• established and used methods of risk analysis and assessment;
• legal requirements;
• operating conditions of manufactured products.

Responsibility for risk management should be assigned to the responsible risk manager or risk management team, including responsibility for controlling and monitoring risk. Requirements for risk managers are established in GOST R 51901.21.

The development, approval, maintenance and updating of the organization’s risk register must be carried out in accordance with clause 5 GOST R 51901.22.

The exchange of information on the risk register and ensuring the confidentiality of information related to the risk register must be carried out taking into account the requirements of clause 6 of GOST R 51901.22 and the recommendations established in R 50.1.070.

An example of a simplified method for assessing risk and developing an abbreviated version of a risk register for a small organization is given in Appendix A.

4.2 Stages of the organization's risk management process

The main steps in developing an organization's risk register should correspond to the steps in the risk management process. At the same time, the content of the stages depends on the characteristics of the organization’s risk management. Risk management principles are established in GOST R ISO 31000. The main elements of the risk management process for small organizations are shown in Figure 1.

Figure 1 - General diagram of the risk management process

A description of the main elements of the risk management process for small organizations is given in R 50.1.069.

4.3 Organizational risk management process map

Based on the risk management process in accordance with GOST R 51901.21, the organization can draw up a risk management process map. When developing a process map for small organizations, it is recommended to retain the basic elements of risk management (identification of hazardous events, quantification risk, analysis and comparative risk assessment, risk treatment, monitoring and review), while their content can be clarified depending on the characteristics of the organization’s activities.

4.4 Development of an organization's risk register

4.4.1 General

The results of the actions performed at each stage of the risk management process should be presented in the risk register. Rules for constructing a risk register are given in GOST R 51901.22. The standard form of the risk register is given in Table 1 GOST R 51901.22.

The distribution of responsibilities for developing and maintaining the organization's risk register should correspond to the stages of the risk management process, since entering information into the risk register and its adjustment should be carried out after completion of each stage of the risk management process.

The main stages of developing an organization's risk register are described in paragraphs 4.4.2-4.4.6.

4.4.2 Establishing the purpose and scope of the risk register

The organization shall establish external and internal organizational and risk management objectives to achieve the remaining elements of the risk management process. Recommendations for defining the scope of risk management are given in R 50.1.068.

When determining the goals and scope of the risk register, the objects of the risk register are first determined. Objects of the risk register can be:

• the organization as a whole structural subdivision or part thereof;
• product, service, process or activity;
• staff or individual workers.

General requirements to determine the scope of application of the risk register are established in GOST R 51901.21.

4.4.3 Development of risk criteria

The organization must establish risk criteria. The criteria should reflect the objectives and scope. They often depend on the interests of the parties involved, as well as relevant legal and/or regulatory requirements. Risk criteria can be operational, technical, financial, legal, legislative, social, environmental, humanitarian and/or others.

general description Decision criteria should be developed when establishing the scope of risk management. Risk criteria should be clarified and/or revised after identifying a specific type of risk and selecting a risk analysis method. Risk criteria must be appropriate to the type of risk and the way it is presented.

Risk criteria are usually included in the organization's risk register, but for small organizations risk criteria may be established in the organization's documented procedures or other risk management documents.

4.4.4 Identification of hazardous events

Identification of hazardous events should include the identification of phenomena and events that may affect the risk register objects established in the scope of the risk register. General requirements for identifying hazardous events for inclusion in the risk register are established in clause 4.2 GOST R 51901.21.

For small, small organizations, identification of hazardous events may consist of three stages:

• determination of risk identification methods;
• identification of dangerous events;
• identifying the causes of a dangerous event.

The organization must first determine methods for identifying risk. When identifying risk, the following methods can be used: analysis of checklists, expert assessments, analysis of experimental and chronological data, analysis block diagram reliability, brainstorming method, system analysis, scenario analysis, system design methods. These methods are discussed in more detail in GOST R ISO/IEC 31010. The choice of method depends on the type of risk, the scope and objectives of the organization's risk management, as well as the controls applied and required and the organization's risk management methods.

Methods for identifying risk are usually included in the organization's risk register, but for smaller organizations, methods for identifying risk may be defined in the organization's documented procedures or other risk management documents.

The next step is hazardous event identification, in which the organization must develop a general list of hazardous events that could adversely affect its operations and achievement of objectives. Based on the list, each identified hazardous event that could occur should be described in detail. When compiling a list of hazardous events, the hazard classification given in Appendix A can be used GOST R 51901.21.

The name of the dangerous event must be formulated in a clear phrase. For a hazardous event whose name is sufficiently long, a short name can be used.

Once possible hazardous events have been identified, it is necessary to consider the sources and causes of their occurrence, as well as possible consequences for the activities of the organization.

Hazardous events, their sources and possible consequences are included in the organization’s risk register (regardless of its size).

When carrying out the hazard identification stage, it is recommended to take into account the requirements of GOST R 51901.23.

4.4.5 Risk analysis

General requirements for risk analysis of hazardous events for inclusion in the risk register are established in clause 4.3 of GOST R 51901.22.

Risk analysis involves examining the sources of hazardous events, their consequences, and the likelihood of these events occurring. At the same time, factors influencing the consequences and likelihood of the event must also be identified. Risk must be analyzed taking into account the combination of the consequences of the event and its likelihood. In addition, the organization must review and evaluate its controls and management practices. The magnitude of the consequences of an event and its likelihood must be assessed taking into account the effectiveness of existing strategies, controls and management practices.

An organization's risk analysis can be conducted to varying degrees of detail depending on the characteristics of the risk, the purpose of the analysis, and the available data and resources. Risk analysis can be qualitative, quantitative or a combination. For small organizations, qualitative analysis is typically used to obtain an overall risk assessment and identify risk issues. If the organization decides that further detailed analysis is necessary, then quantitative or combined risk analysis methods can be applied. A description of these types of risk analysis is given in R 50.1.069 and GOST R ISO/IEC 31010.

The means of representing the consequences and likelihood of events in the risk register should be chosen to ensure that the objectives of the risk analysis are met.

Risk analysis must take into account uncertainty and variability in estimates of the consequences and likelihood of an event, as well as the effectiveness of risk communication. When entering quantitative data into the risk register, the corresponding uncertainty should (if possible) be indicated.

4.4.6 Comparative risk assessment

General requirements for comparative risk assessment for inclusion in the risk register are established in subsection 4.4 GOST R 51901.22.

The purpose of a comparative risk assessment of a small organization is to make, based on the results of the risk analysis and risk acceptance criteria, decisions about the need for risk treatment and the prioritization of risk treatment.

When performing a comparative risk assessment, you should be guided by the requirements of GOST R 51901.23.

The results of the comparative risk assessment are usually recorded in the organization's risk register, unless otherwise specified in the organization's documented procedures or other risk management documents.

4.4.7 Risk treatment

General requirements for risk treatment for inclusion in the risk register are established in subsection 4.5 of GOST R 51901.22.

At the risk treatment stage, a risk treatment strategy is selected, the consequences, the probability of a dangerous event and risk are assessed (taking into account the application of the selected risk treatment strategy), risk treatment measures, deadlines and those responsible for their implementation are determined, and the results of risk treatment are assessed.

For small organizations, mandatory elements of the risk register associated with the risk treatment stage are the definition of risk treatment measures, the timing of their planned and actual implementation.

Typically, a small organization's risk treatment budget is limited, so treatment methods must also establish the order in which each risk is treated. The organization must compare the total cost of a hazardous event occurring when no measures are taken with the savings achieved after treating the risk and applying preventive actions.

4.4.8 Risk monitoring and risk register revision

General requirements for risk monitoring and revision of the risk register are established in subsection 4.6 GOST R 51901.22.

The organization must ensure the continuity of the risk management process, therefore it is necessary to regularly monitor all types of risks and review entries in the risk register.

The results of risk monitoring are usually recorded in the organization's risk register, but for small organizations these results may be defined in the organization's documented procedures or other risk management documents.

Appendix A
(informative)

An example of a simplified method for assessing risk and developing an abbreviated version of a risk register for a small organization

A.1 General provisions

The structure and composition of the risk register depend on the characteristics of the organization. The standard form of the risk register is given in GOST R 51901.22. Small organizations can use an abbreviated (simplified) form of the risk register, an example of which is given in Table A.1.

Table A.1 - Simplified form of the risk register

When filling out the risk register, the following scales can be used:

scale of consequences: 5 - catastrophic consequences, 4 - significant consequences, 3 - moderate consequences, 2 - small consequences, 1 - minor consequences;

probability scale of a dangerous event: 5 - very high probability, 4 - high probability, 3 - medium probability, 2 - low probability, 1 - very low probability;

risk assessment: acceptable risk (0-4), controlled risk (5-8), significant risk (9-25);

risk treatment measures: (0) there is no risk, no action is taken; (0-4) low risk, only low-cost actions are taken; (5-8) medium risk, actions are taken taking into account the time of their implementation and economic feasibility; (9-25) high risk, urgent implementation of measures to reduce the risk is necessary; (16-25) high risk, use of immediate (emergency) actions to reduce risk.

A.2 Risk matrix

A.2.1 General

The method for assessing the risk of hazardous events is given in GOST R 51901-23*, however, small organizations can use simplified risk assessment methods, and the uncertainty of such risk assessments must be taken into account.

________________

*Probably an error in the original. Should read: GOST R 51901.23. - Database manufacturer's note.

Small organizations can use a risk matrix to assess the significance of a risk. For a systematic and consistent risk assessment, it is necessary to develop a risk matrix according to the following steps:

• assessment of the probability of a dangerous event (A.2.2);
• assessment of the consequences of a hazardous event (A.2.3);
• drawing up a risk matrix (A.2.4);
• determination of risk treatment measures (A.2.5).

This example shows the simplest version of the risk matrix. An organization, depending on the risk assessment conditions, can develop its own risk matrix.

A.2.2 Assessing the probability of a hazardous event

In a small organization, depending on the object of the risk register, the risk manager must answer the question of what is the likelihood of a dangerous event occurring when using the specified controls and methods for managing risk reduction measures. In this case, you can use table A.2.

Table A.2 - Assessment of the probability of a dangerous event

If there are doubts about the assessment of the likelihood of a hazardous event occurring, the hazard rating of the event is increased.

A.2.3 Assessing the consequences of a hazardous event

Depending on the area of ​​impact of the hazardous event, the risk manager must evaluate the consequences of the hazardous event under existing controls, management practices, and risk mitigation activities. To do this, you can use Table A.3.

Table A.3 - Assessment of the consequences of a hazardous event

If there are doubts about the assessment of the consequences of a dangerous event, then the rank of this event is increased.

A.2.4 Drawing up a risk matrix

In this example, the simplest method of risk assessment is used - qualitative assessment consequences and likelihood of a hazardous event. In this case, the risk is calculated as the product of consequences and probability:

The rankings of consequences and probabilities are determined according to tables 2 and 3.

The results obtained allow us to construct a risk matrix (Table A.4), which can be used as a basis for identifying acceptable and unacceptable risks.

Table A.4 - Risk matrix

For greater clarity in the risk register, the risk assessment can be highlighted in color:

green color - acceptable risk (0-4);

yellow color - controlled risk (5-8);

red (dark red) color - serious and significant risk (9-25).

Identified types of risk can be ranked both within departments and across the entire organization. The ranking is based on a risk matrix (the product of consequences and probability) and allows the identification of most significant risks.

A.2.5 Definition of risk treatment strategy and measures

Depending on the risk assessment (see Table A.4), the actions to be taken for each risk recorded in the risk register should be determined. Table A.5 provides an example of actions taken based on the risk assessment.

Table A.5 - Example of actions taken taking into account risk assessment

Risk mitigation or risk treatment activities may be included in the risk register and/or may be developed as a separate document. In this case, a link to this document must be provided in the risk register. In the example given, risk treatment activities are included in the risk register.

A.3 Additional provisions

Since the risk register is constantly updated, it is necessary to record the dates of risk entries and all changes made. If the action plan is included in the risk register, the purpose and time frame for completing the actions included in the plan must be recorded.

The comments or notes column in the risk register allows you to make references to necessary information, for example, holding a meeting at which the problems of this risk were discussed.