Risk management frameworks turn uncertainty into repeatable business decisions. ISO 31000:2018 provides principles, a framework and a process for identifying, analysing, evaluating, treating and monitoring risks. To implement it, organisations should define objectives and risk criteria, assign accountable owners, maintain a usable risk register and review results when conditions change—not simply collect risks in a spreadsheet.
What Is a Risk Management Framework?
A risk management framework is the set of responsibilities, rules, information flows and review routines that allow an organisation to handle uncertainty consistently. It connects the questions executives ask—what could prevent us from reaching our objectives, how much disruption can we tolerate and who will act?—with everyday activities such as procurement, product launches and cash-flow planning.
A framework is different from a one-off risk assessment. An assessment examines a particular situation. The framework determines who starts the assessment, what criteria apply, how decisions are documented and when those decisions must be revisited. For example, a manufacturer may assess a new supplier this month, but its standing framework also governs the next supplier, the next contract renewal and the response when that supplier becomes distressed.
ISO 31000:2018 is a widely applicable reference for this work. The International Organization for Standardization describes three related elements: principles, a management framework and a risk management process. ISO states that its guidelines apply across sectors and organisation sizes. It also explicitly says ISO 31000 is not a certifiable risk management standard. A consultant’s certificate of training is therefore not evidence that an entire business has received ISO 31000 certification.
ISO 31000 Principles, Framework and Process: Three Different Jobs
These terms often appear together, yet they answer different questions. Confusing them leads to elaborate procedures with no clear ownership or, conversely, executive policies that never influence operating decisions.
| Element | Question answered | Practical output |
|---|---|---|
| Principles | What makes risk management useful? | Decision-making that creates and protects value, uses relevant information and improves with experience |
| Framework | Who leads, integrates and reviews the activity? | Accountabilities, policy, resources, escalation rules and management review |
| Process | How is each uncertainty assessed and handled? | Defined context, assessment, response, monitoring, communication and records |
The British government’s Orange Book provides a useful operational comparison. Its risk-management illustration combines governance, integration and collaboration with identification, treatment, monitoring, reporting and continual improvement. Those are public-sector governance requirements in that document, not automatically legal obligations for private companies. Nevertheless, they show why an isolated risk-scoring exercise is incomplete: decisions need information, people and feedback.
For broader strategic choices such as the board’s risk appetite, readers can explore our guide to enterprise risk management. This article instead concentrates on building and operating the ISO-oriented process.
Step 1: Establish Objectives and Decision Boundaries
Before listing threats, identify what the organisation is trying to achieve. A risk only becomes meaningful in relation to an objective. “Technology” is a department; “a payment-platform outage preventing customers from completing orders during peak trading” is an assessable event linked to an operational goal.
Start with three to five measurable objectives for the area being assessed. They might include order availability, on-time delivery, regulatory compliance, product quality and cash conversion. Then specify the assessment horizon, geographic boundaries, business units, key dependencies and decision authority.
Next, define risk criteria. These may cover financial loss, service interruption, safety consequences, legal exposure, customer harm and reputational damage. A serious safety incident should not be treated as acceptable merely because its expected monetary cost is small. Where risks affect several objectives, retain those dimensions rather than forcing everything into one dollar figure.
The result of this stage should be a brief scoping note: objective, time horizon, included activities, exclusions, assessment criteria, approval owner and review trigger. A shared vocabulary also matters. Different teams should not use “high risk” to mean incompatible things.
Step 2: Identify Events, Causes and Consequences
Useful risk identification begins with scenarios, not category labels. Describe the cause, uncertain event and consequence in a sentence. For example: “Because the online store relies on one payment processor, a prolonged provider outage could block checkout transactions and delay revenue collection.”
Collect scenarios through interviews, process mapping, incident records, contract reviews, customer complaints, audits and workshops. Bring together people who operate the process and those who challenge it. Procurement may know which suppliers are difficult to replace; treasury may see the cash impact; legal advisers may identify notice periods and contractual obligations.
Include threats to opportunity as well as direct losses. An unnecessarily cautious approval process may cause a company to miss a profitable product launch. Similarly, a rapid expansion may offer upside while exposing the business to liquidity constraints. Risk management should improve decisions, not prevent all risk-taking.
Use a small set of categories as navigation aids—strategic, operational, financial, compliance, technology and external—but avoid assuming they are mutually exclusive. A cyber incident may cause operational downtime, trigger contractual penalties and threaten cash flow at the same time. Our separate article on financial risk management covers market, credit and liquidity exposures in more detail.
Step 3: Analyse Likelihood, Impact and Existing Controls
Risk analysis estimates what could happen and how well current arrangements would respond. The simplest method uses a descriptive likelihood scale and an impact scale. It works for early prioritisation, provided definitions are consistent. A “likely” event could mean once a quarter to one department and once every five years to another; such scores are not comparable.
For material exposures, build an explicit scenario with a time horizon and a range of outcomes. Ask what evidence supports the likelihood estimate, how losses might vary, which controls already operate and whether several events can occur together. Record assumptions instead of presenting judgement as precision.
An illustrative annual expected-loss calculation is:
Expected annual loss = estimated annual probability × estimated financial impact.
Suppose a company estimates a 5% annual probability of a payment outage that would cost $1.6 million. The simple expected annual loss is 0.05 × $1,600,000 = $80,000. This is an illustrative planning estimate, not a forecast that the business will lose exactly $80,000. In a real assessment, outage durations, recovery costs, lost customer value and uncertainty around probability would require further analysis.
A control must be assessed for performance, not merely existence. A documented backup procedure offers little protection when no employee has tested it. Distinguish the exposure before controls (inherent risk) from the exposure remaining after credible controls (residual risk), and say how the second was estimated.
Step 4: Evaluate Results Against Risk Criteria
Risk evaluation asks whether residual exposure is acceptable in relation to the organisation’s objectives and agreed criteria. A single 5-by-5 heat map may help with discussion, but it should not be mistaken for a statistical model. Multiplying ordinal scores such as “3 × 4 = 12” creates a prioritisation label, not a measured dollar loss or a reliable comparison of unlike hazards.
Consider severity, speed of onset, reversibility, legal constraints and concentration. A rare shutdown may deserve urgent attention despite a low average annual loss. Meanwhile, two moderate risks that depend on the same cloud provider could amplify one another during one incident.
Establish escalation triggers before an event occurs. A team might manage operational delays within agreed limits, while any breach affecting regulated customer data goes straight to senior leadership. The correct thresholds depend on the business; ISO 31000 does not prescribe universal numbers for every company.
Step 5: Select, Fund and Assign Risk Treatments
Common treatment choices include avoiding an activity, reducing likelihood, limiting consequences, transferring some financial consequences through insurance or contracts, sharing exposure, retaining the risk consciously or taking more risk to pursue a worthwhile opportunity. Each treatment has a cost and may introduce new dependencies.
For the payment-outage scenario, management considers a second processor costing $38,000 annually. It estimates that tested failover would reduce the annual probability of the defined $1.6 million loss from 5% to 2%. On those assumptions, expected annual loss would fall from $80,000 to $32,000. The estimated reduction is $48,000, producing an illustrative net expected benefit of $10,000 per year after the $38,000 operating expense.
This calculation does not prove the investment is optimal. The assumed probability reduction needs evidence, other failure scenarios may remain, and a severe outage could exceed the modelled amount. A decision might still favour resilience even if the net expected benefit were negative, particularly where service obligations or customer harm impose tighter limits.
| Payment-system scenario | Before treatment | After proposed treatment |
|---|---|---|
| Estimated annual probability | 5% | 2% |
| Modelled loss if event occurs | $1,600,000 | $1,600,000 |
| Simple expected annual loss | $80,000 | $32,000 |
| Additional annual control cost | — | $38,000 |
| Change in expected loss less control cost | — | +$10,000 estimated benefit |
Every treatment plan needs one accountable owner, a due date, funding, a measurable completion test and a fallback. “Improve supplier resilience” is not a sufficient action. “Complete a failover test with the alternate provider by 30 June and demonstrate recovery within 30 minutes” is much easier to verify.
Step 6: Build a Risk Register People Can Actually Use
A risk register should support decisions rather than become a warehouse of labels. A workable minimum includes an identifier, objective, scenario, cause, consequence, existing controls, owner, inherent assessment, residual assessment, selected response, next action, review date and escalation threshold. Where financial estimates are reliable enough, store them beside their assumptions.
The National Institute of Standards and Technology offers a relevant primary-source example. Its December 2025 revisions to the NIST IR 8286 series explain how detailed cybersecurity risk records can inform broader enterprise risk registers. NIST also provides machine-readable register and risk-detail schemas. Although these resources focus on technology risks, the underlying documentation lesson applies widely: decision-makers need consistent scenario descriptions and traceable assumptions, not just coloured boxes.
| ID and scenario | Owner | Evidence / indicator | Response and next review |
|---|---|---|---|
| R-01: Payment provider outage blocks checkout | Head of Digital Operations | Provider uptime, failover test results | Test second processor; review monthly |
| R-02: Critical component supplier misses deliveries | Procurement Director | On-time delivery, supplier lead times | Qualify alternate material; review quarterly |
| R-03: Unauthorised system access disrupts order data | Technology Director | Unresolved high-severity findings | Restrict access and rehearse recovery; review monthly |
All three register entries are hypothetical illustrations, not reported incidents or the official NIST template. Companies should expand fields where needed without adding columns that no one updates. A single risk can require several treatment actions, while a shared underlying dependency should be clearly identified across records.
Supplier due diligence and monitoring deserve their own lifecycle. Our upcoming guide to vendor risk assessments explains how to connect provider selection, ongoing checks and exit planning without duplicating the enterprise register.
Step 7: Set Monitoring Triggers, Reporting and Review Cycles
Risk controls deteriorate, markets change and projects create fresh exposure. Monitoring should therefore look at leading indicators as well as past incidents. Examples include overdue control tests, single-supplier reliance, unusually long recovery times, rising customer complaints or exceptions that remain unresolved after a deadline.
Give each indicator a measurement method, data owner and action threshold. If the monitoring system produces noisy or late data, management may overlook a genuine deterioration. Where numerical indicators are unsuitable, use structured evidence from walkthroughs, incident reviews and independent assurance.
The UK’s Orange Book emphasises monitoring, reporting and continual improvement. Its practical guidance calls for decision-useful information about how risk is changing, how controls operate and whether exposure remains within appetite. Private businesses can adopt this logic while designing their own reporting cadence.
For example, process owners could review operational risks monthly, the executive risk group could examine cross-functional trends quarterly, and the board could consider major exposures alongside strategic decisions. These frequencies are suggested practices, not mandatory ISO rules. Significant incidents, regulatory developments and acquisitions should trigger out-of-cycle reassessment.
How Risk Management Tools Should Fit the Process
The appropriate risk management tools depend on the decision. A workshop helps teams discover scenarios; a risk matrix supports quick screening; a failure-mode analysis examines process weaknesses; scenario planning tests severe disruption; and a cash-flow sensitivity model explores financial resilience. None replaces competent judgement or reliable underlying data.
| Tool | Best use | Main limitation |
|---|---|---|
| Risk register | Ownership, actions and tracking | Can become stale without review |
| Likelihood-impact matrix | Initial prioritisation | Ordinal scores are not monetary measures |
| Scenario / stress testing | Severe but plausible disruptions | Highly sensitive to assumptions |
| Process mapping and interviews | Uncovering operational dependencies | May miss external or hidden links |
| Key risk indicators | Identifying a changing exposure | Thresholds may trigger false alerts |
Start with documented decisions and a small, maintained register before buying software. A platform cannot decide which risk a company is prepared to take. Sophisticated systems become useful when several business units need consistent data, audit trails, workflow approvals or aggregation across a large portfolio.
Practical 90-Day Risk Management Plan
A phased rollout can produce useful evidence without turning implementation into a year-long policy project. Select one real operational process as a pilot and use the first cycle to uncover weaknesses in definitions and ownership.
| Period | Priority | Deliverable |
|---|---|---|
| Days 1–15 | Set objectives, scope, criteria and roles | Approved assessment brief and common scoring definitions |
| Days 16–30 | Map processes and identify scenarios | First risk register with named owners |
| Days 31–60 | Analyse priority risks and choose responses | Costed treatments, test plans and escalation triggers |
| Days 61–90 | Test controls and report decisions | Evidence-based review with actions for the next cycle |
At the 90-day review, ask whether decisions changed because of the process. Were funds redirected to a stronger control? Did a supplier selection include evidence that it would otherwise have missed? Was a risky expansion postponed, adapted or consciously accepted? These questions reveal more than the percentage of staff who completed a template.
Information Gain: What Recent Public-Sector Guidance Adds
Two primary-source developments illustrate how expectations for risk documentation are becoming more explicit. First, NIST released IR 8286A Revision 1 in December 2025, updating its discussion of risk scenarios, likelihood, impact and their documentation in support of enterprise oversight. Its accompanying structured schemas show how information can move from a detailed risk record to an aggregated register. This is cybersecurity-focused guidance, not a universal requirement for every company’s risk function.
Second, the U.S. Government Accountability Office updated the federal Green Book in May 2025. Among its changes are documented risk assessment results—including identification, analysis and response—and a documented process for assessing significant change. The revision applies to U.S. federal internal-control requirements from fiscal year 2026, with early adoption permitted. It does not impose those federal rules on ordinary private businesses. Still, it reinforces a practical lesson: a framework should retain the reasons for decisions and a method for reopening them after major changes.
Combined with ISO’s process-based approach and the Orange Book’s focus on decision-useful reporting, these documents point to a useful test: can an organisation explain a material risk from objective to scenario, evidence, owner, decision, control and subsequent review without reconstructing the story from old emails?
Common Implementation Mistakes
Counting risks instead of improving decisions. A register with 200 rows is not necessarily stronger than one with 20 material and well-managed scenarios. Prioritise relevance and action.
Using the same rating scale for everything. A financial loss, a safety consequence and a regulatory breach have different decision constraints. Provide appropriate criteria rather than pretending all impacts are commensurate.
Assigning responsibility to a committee. Committees can challenge and oversee, but an operational risk needs a specific person who can fund and implement the response.
Ignoring dependencies. Separate entries for two cloud systems may hide that both rely on the same data centre or access provider. Map concentration explicitly.
Treating controls as effective because they exist. Test recovery, inspect evidence and track failures. A written policy without proof of operation offers weak assurance.
Publishing a policy without revisiting it. Acquisitions, new products, unusual market conditions and serious incidents should reopen the assessment. A functioning risk management cycle is continuous.
Frequently Asked Questions
What are the main steps in the ISO 31000 risk management process?
Establish context and criteria; identify, analyse and evaluate risks; select and implement treatment; then monitor, review, communicate and record decisions. Communication and consultation support the process throughout, rather than appearing only at the end.
Can a company be ISO 31000 certified?
No. ISO describes ISO 31000:2018 as guidance, not a certifiable management-system standard. Organisations may evaluate their practices against it and individuals may receive training, but those are different claims.
What is the difference between a risk management framework and a risk management plan?
The framework establishes continuing responsibilities and decision rules across the organisation. A plan applies them to a particular activity, project or business unit, specifying methods, owners, timing, resources and deliverables.
How often should a risk register be updated?
Review frequency should reflect exposure and how quickly conditions change. Monthly checks may suit payment or cybersecurity risks, whereas some longer-term strategic risks require less frequent scheduled reviews. Material changes and incidents warrant earlier updates.
Is a 5-by-5 risk matrix sufficient?
Usually not for material decisions. It is a screening and communication aid, but high-impact scenarios also need credible assumptions, control testing, dependency analysis and escalation criteria. Numeric matrix scores should not be mistaken for financial forecasts.
Does ISO 31000 replace COSO ERM or internal controls?
No. ISO 31000 supplies adaptable guidelines, COSO ERM provides another approach to enterprise risk governance, and internal controls are specific measures supporting objectives. Organisations can use complementary elements without duplicating meetings and registers.
Final Takeaway
Effective risk management frameworks make uncertainty visible at the point of decision. Begin with a business objective, document scenarios clearly, evaluate them against practical criteria, fund treatments with accountable owners and revisit the evidence as conditions change. ISO 31000 offers the structure; a maintained register, tested controls and candid reporting turn that structure into useful management practice.
