Risk management is a systematic process of identifying, assessing and reducing the uncertainty that could prevent an organization from achieving its objectives. It consists of five steps – identification, analysis, evaluation, risk treatment and monitoring – and its results are recorded in a risk register, assessed on a risk matrix, and overseen by risk owners and key risk indicators (KRIs). The international reference point is the ISO 31000 standard, which defines risk as the effect of uncertainty on objectives.
In this guide we explain what risk management in a company is, how the risk management process works step by step, what risk registers and risk matrices are for, who a risk owner is, how KRIs work, and when an organization needs a GRC-class risk management system. If you are just starting to organize this area, read our article on GRC – what is Governance, Risk & Compliance as well.
What Is Risk Management?
Risk management is a set of coordinated activities that lets an organization make decisions consciously under uncertainty. Instead of reacting to events after the fact, it identifies possible threats in advance, assesses their significance and decides what to do about them.
ISO 31000 (the current edition dates from 2018) defines risk as the effect of uncertainty on objectives. That effect can be negative, positive or both – in practice, organizations focus mainly on threats. ISO 31000 has three elements: principles, an organizational framework and a risk management process. It is a guidance document rather than a certifiable standard – you don’t undergo a certification audit, but you can refer to it in policies and procedures. It is complemented by, among others, IEC 31010 (risk assessment techniques) and ISO 31073 (vocabulary).
It helps to distinguish three terms that are often mixed up. A risk is the possibility that something will happen. A threat or risk source is what could cause it. An incident is an event that has already occurred – a risk that has materialized.
Key Concepts in Risk Management
Why Do Organizations Manage Risk?
There are two reasons: business and regulatory.
From a business perspective, risk management lets an organization direct limited resources where they genuinely reduce exposure – instead of firefighting or protecting everything equally. It also gives the board a common language for discussing uncertainty: instead of “this feels dangerous,” a risk level, an owner and a plan.
From a regulatory perspective, risk analysis is a component of many requirements companies face today. ISO/IEC 27001 requires a defined information security risk assessment and treatment process. The NIS2 directive, in Article 21, lists risk analysis and information system security policy as the first of ten required areas – we describe the details in our articles on NIS2 requirements and the Polish KSC act. In the financial sector, the DORA regulation requires an ICT risk management framework. In each case, an organization has to be able to show not only that it assessed risk, but that it does so cyclically and can document it.
What Does the Risk Management Process Look Like?
The ISO 31000 risk management process covers establishing the scope, context and criteria, risk assessment (identification, analysis and evaluation), risk treatment, and monitoring and review. It is accompanied throughout by communication and consultation, and by recording and reporting. In practice it can be presented as five steps:
To show how these steps fit together, we use a single illustrative example throughout the article: a services company, an online order handling process, and a platform hosted with a single cloud provider. The figures and thresholds in the examples are chosen for this article – every organization sets its own.
1. Risk Identification
Identification means finding and describing risks before they materialize. The starting point is the business processes and assets that the organization’s objectives depend on, and the sources of information are: workshops with process owners, business impact analysis (BIA), audit findings, incident history, the list of critical vendors and regulatory changes.
A well-described risk has three parts: an event, a cause and a consequence. In our example: “The order platform being unavailable for more than 4 hours (event) because of an outage at the only cloud provider (cause) results in lost orders and contractual penalties (consequence).”
BCMLogic expert commentary: the most common mistake at this stage is entering gaps instead of risks in the register, e.g. “no backup environment.” That is a control gap, not an event that could happen. From such an entry, neither likelihood nor impact can be estimated.
2. Risk Analysis
Analysis establishes how likely the event is and how serious its consequences would be. The most common approach is a qualitative 1-5 scale for likelihood and for impact, with each level described – e.g. “3 – possible: once every few years,” “4 – major impact: a key process down for more than 4 hours.” Quantitative methods (e.g. estimated financial loss) are more precise but require data that many organizations don’t yet have.
Impact is worth assessing in several dimensions at once: financial, operational, regulatory and reputational. Where possible, likelihood should be based on data – for example, the number of past incidents affecting a given process or asset – rather than on intuition alone.
In practice, a distinction is made between inherent risk (before controls) and residual risk (after existing safeguards are taken into account). In our example: likelihood 3 (possible), impact 4 (major), so a score of 12.
3. Risk Evaluation
Evaluation compares the result of the analysis with the risk criteria – the level the organization is prepared to accept, i.e. its risk appetite. A decision is made at this stage: accept the risk, treat it, or carry out further analysis. This is where the priority list is born – you can’t deal with every risk at once.
In the example, a score of 12 falls in the “high” band. Under the company’s risk criteria, high risks cannot be accepted without a board decision, so we move on to treatment.
4. Risk Treatment
Risk treatment is choosing how to respond and implementing that response. In practice, four basic strategies are used (ISO 31000 lists a broader set of options, but these four cover most cases):
The chosen strategy goes into a risk treatment plan: specific actions, a responsible person, a deadline and resources. After implementation, the risk is reassessed – residual risk remains, which the risk owner or an authorized person accepts or sends for further action. Transfer doesn’t remove accountability: insurance will cover part of a financial loss, but it won’t restore customer trust.
In the example we choose to reduce the risk: launching a backup environment in a second region with a quarterly failover test. The plan owner is the IT director, with a deadline at the end of the quarter. Residual risk will be reassessed after implementation.
5. Risk Monitoring
Risk is not static: threats, vendors, systems and regulations change. Monitoring includes cyclical reviews of the register, tracking KRIs, verifying that controls actually work, and reassessing risk after every significant incident or change. The results go into reports for the board.
This step is often skipped, yet it is what separates risk management from a one-off assessment for an audit. Requirements such as NIS2 explicitly expect regular verification of the effectiveness of implemented measures.
What Is a Risk Register?
A risk register is a central record of all identified risks together with their assessment, existing controls, owner and treatment plans. It is the main working tool and the basis for reporting: priority lists, the risk matrix and board reports are produced from it.
A good register contains at least: an identifier, a risk description (event – cause – consequence), the related process or asset, a category, an owner, likelihood and impact, the risk level, existing controls, the chosen strategy with its plan and deadline, residual risk, related KRIs and the date of the last review. An extract from a sample register (illustrative data):
A register can be kept in a spreadsheet as long as there are a dozen or so risks and a few people responsible for them. As the number of risks, vendors and regulatory requirements grows, a spreadsheet stops being enough – more on that in the section on GRC systems.
How Is a Risk Matrix Used?
A risk matrix is a table that combines likelihood and impact into a single risk level. On a 5×5 scale, the level is the product of the two values (1-25), and the cells are colored according to thresholds set by the organization. The matrix is used for prioritization – it shows which risks to address first – and for communication: one picture the board can understand.
A sample matrix with risk R-014 highlighted (likelihood 3, impact 4):
Sample thresholds: 1-4 low (green), 5-9 medium (yellow), 10-16 high (orange), 17-25 critical (red). Thresholds are set by the organization in line with its risk appetite.
BCMLogic expert commentary: a matrix is a tool for discussion and prioritization, not a precise measurement. The scales are ordinal, so different combinations can give the same result (2 × 6 and 3 × 4 don’t necessarily mean the same thing), and the assessment depends on who fills it in. That is why every level of the scale should have a written definition, and every assessment a justification.
Who Is a Risk Owner?
A risk owner is the person who is accountable for a given risk and has the authority to decide how to treat it. It has to be someone who genuinely influences the process or asset the risk relates to – usually the manager or director of that area, not automatically the security or risk department. The risk function provides methodology and tools, but doesn’t “own” the risks.
A risk owner assesses the risk, chooses the strategy, is accountable for carrying out the treatment plan, and accepts residual risk within their authority. Assigning owners is easiest to sustain when you work from an organizational structure in which every process, risk and control has a named person – which is how, among others, the Organization module works.
In smaller organizations roles are combined, but the principle stays the same: every risk has one named person who is accountable for decisions.
What Are KRIs?
A KRI (Key Risk Indicator) is a measurable indicator that signals the level of risk is rising – before the risk materializes. It works like a warning light: it doesn’t say an incident has happened, only that conditions are starting to favor one. That makes it possible to respond earlier.
A KRI differs from a KPI. A KPI measures how well the organization is achieving a goal (e.g. sales, ticket handling time). A KRI measures how close an event is that could threaten that goal. A good KRI is tied to a specific risk, measurable from available data, and has defined thresholds (warning and alarm), an owner and a measurement frequency. Illustrative examples:
The threshold values are examples – each organization sets them in line with its own risk appetite. Crossing a threshold should trigger a specific response: a risk review, escalation to the owner or additional action.
How Does a GRC System Support Risk Management?
A GRC-class risk management system keeps risks, controls, processes, assets, vendors and regulatory requirements in one place and links them together, instead of scattering them across different departments’ spreadsheets. As a result, a change in one element – a new incident, a new vendor, a change in regulation – is visible where it affects the risk assessment. We describe the broader context in our article on GRC.
Typical signs that a spreadsheet is no longer enough:
- risks are kept in several files and nobody knows which one is current,
- it’s hard to tell who owns a risk and when it was last reviewed,
- risks and plans are approved by email, with no audit trail,
- assessments don’t take incident and vendor data into account because it lives elsewhere,
- preparing a report for the board or an auditor takes days.
Taking the BCMLogic platform as an example, according to the description of its risk management module, such support includes, among other things:
- a risk register linked to processes, assets (IT systems, infrastructure, vendors), existing safeguards, strategy and treatment plans,
- integration with incident data, BIA and business continuity plans – the likelihood level can result from the number of incidents affecting a process or asset (see also business continuity management),
- a risk level derived from a matrix that takes likelihood and multiple types of impact into account,
- workflow with dynamically assigned permissions – users see risks according to their role,
- a KRI library linking indicators to data collected by the platform (incidents, outages) and to other systems,
- role-based dashboards (board, supervisory board, directors of areas) and export to MS Excel,
- a distinction between existing and planned safeguards – a completed treatment plan becomes an active safeguard,
- a link to vendor risk.
A system doesn’t replace decisions – it is still the risk owner who chooses the strategy – but it organizes data and process so that decisions are made faster and on fuller information. It is also a natural backbone for requirements such as NIS2/KSC or DORA, which expect documented, cyclical risk management.
Common Mistakes in Risk Management
- Risks described as gaps – “no backup” instead of an event, cause and consequence.
- Scales without definitions – everyone understands “medium impact” differently, so assessments aren’t comparable.
- A register without owners – a risk nobody is accountable for isn’t being managed.
- A one-off assessment “for the audit” – the register is built once a year and doesn’t live between reviews.
- Assuming a control works – a residual assessment without checking whether the safeguard is actually effective.
- Plans without deadlines and owners – “implement a safeguard” with no date and no person.
- No link to incidents – an incident happens and the risk assessment doesn’t change.
FAQ
What is the difference between a risk and an incident?
A risk is a possible event that hasn’t happened yet. An incident is an event that has already occurred – a risk that has materialized. Incidents are a valuable source of data for assessing the likelihood of risks.
Is ISO 31000 mandatory, and can it be certified?
No. ISO 31000 is a set of guidelines, not a certifiable standard. You can refer to it in a risk management policy, but you can’t be certified against it. Legal obligations come from regulations such as NIS2 or DORA, not from the standard itself.
How often should the risk register be reviewed?
ISO 31000 doesn’t prescribe a frequency – it speaks of monitoring and review throughout the process. In practice, many organizations carry out a full review quarterly or once a year, and additionally reassess risks ad hoc after a significant incident, a process change, a new vendor or a regulatory change. What matters most is that the frequency is written into the policy and followed.
Can risk management be run in Excel?
At the beginning, yes – with a dozen or so risks and a few owners, a spreadsheet is enough. As the number of risks, vendors and requirements grows, it becomes hard to keep data current, maintain change history, approvals and links to incidents.
What is the difference between risk management and ERM?
ERM (Enterprise Risk Management) is risk management at the scale of the whole organization, integrated with strategy and reported at board level. It is the same approach, applied consistently across all areas rather than separately in each department.
What is the difference between a KRI and a KPI?
A KPI measures how well the organization is achieving its objectives. A KRI measures how close an event is that could threaten those objectives – it is an early-warning indicator.
Summary
Risk management is a repeatable process, not a document: identification, analysis, evaluation, treatment and monitoring, supported by a register, a matrix, risk owners and KRIs. The most value comes from three things organizations most often skip: well-described risks (event, cause, consequence), unambiguous owners, and regular reviews driven by data rather than by the audit calendar.
Read Also
- GRC – What Is Governance, Risk & Compliance and How Does It Work in Practice?
- NIS2 – Requirements and Obligations for Organizations. What Must Be Implemented?
- NIS2 2026 – Who Does the New Law Apply To and What Obligations Does It Impose?
See What This Could Look Like for Your Organization
If your organization keeps risks in spreadsheets and is looking for a single, consistent register with owners, KRIs and board reports, it’s worth seeing what this looks like on a GRC platform. BCMLogic Solutions helps financial and technology companies manage operational risk, business continuity and regulatory compliance – in line with ISO 22301, ISO 27001 and requirements such as DORA and NIS2/KSC.
