What ISO 73 Actually Gives You (And What It Doesn't)
ISO 73 is a vocabulary guide. That's it. It doesn't tell you how to manage risk. It tells you what the words mean so that when someone says "risk assessment," you and the other person are talking about the same thing instead of two completely different processes. I've sat through enough meetings where a compliance team and an engineering team spent forty-five minutes arguing about whether something was a "risk treatment" or a "risk mitigation measure" before realizing they were using different dictionaries. ISO 73 exists to prevent that. It aligns terminology with ISO 31000, which is the actual risk management standard most people reference. The problem is nobody reads it cover to cover. It's dry by design. It's a reference document, not a textbook. People download it, open it to one page, and treat it like a dictionary when they need it. That's actually the right way to use it in most cases.
Risk Management Vocabulary Iso Guide 73
If you're looking for the current version, it's publicly available through ISO's member bodies. You can grab it from iso.org or from your national standards institute depending on your country. It's not free in most places, though some organizations provide institutional access. The 2009 version is the one most people are still using. There was a 2021 update that aligned more closely with revisions to ISO 31000, and that's the one you should be referencing if your organization is doing this seriously.
The Definitions That Actually Matter in Practice
Here's what I've found useful from the guide, the definitions that come up repeatedly in real work. Risk. The effect of uncertainty on objectives. That's the core definition and it's deliberately broad. Effect means any deviation from the expected, positive or negative. Uncertainty means there's partial or complete absence of information or knowledge. This definition alone resolves half the debates I see in risk meetings because people keep treating risk as only negative outcomes. Risk source. Something that has the potential to give rise to risk. This could be an event, a situation, a process, or even a decision. The distinction between a risk source and a risk event matters more than people think. A risk source is the thing. A risk event is the thing happening. Pressure vessel fatigue is the source. A crack forming in the vessel wall is the event.
Get the Full Details
Risk assessment. The overall process of risk identification, risk analysis, and risk evaluation. Note that this is a process, not a single activity. I've seen organizations produce a document called a "risk assessment" that was actually just a risk register with no analysis or evaluation behind it. That's not wrong because the vocabulary is sloppy, not because the people are incompetent. Risk treatment. The process of selecting and implementing measures for modifying risk. The guide lists four options: risk retention, risk elimination, risk acceptance, and risk modification. Risk modification breaks down further into risk sharing, risk reduction, and risk transfer. Most people stop at "mitigate" and call it a day, but the guide is more granular than that. Inherent risk versus residual risk. Inherent risk is the risk before any treatment. Residual risk is what remains after treatment. This distinction sounds simple but it's where documentation falls apart constantly. I once audited a safety file where a company had listed residual risks but never documented the inherent risk baseline. You can't meaningfully evaluate whether your treatment worked if you don't know what you started with.
Severity. The consequence of a risk event measured against the criteria established by the organization. Severity isn't an objective number. It's whatever your organization's criteria say it is. This trips people up because they expect severity to be universal. It's not. Probability or likelihood. The chance of something happening. Again, this is defined in the context of your organization's risk criteria. Frequency-based, scenario-based, and subjective probability are all valid approaches depending on the data available. Most organizations default to subjective probability because they don't have historical data. That's fine as long as everyone knows what they're doing.
Where ISO 73 Gets Thin and You Have to Fill It In
The guide gives you definitions. It does not give you methodologies for applying those definitions. You will need to pair it with ISO 31000 for the actual process framework, and likely with ISO 31010 for risk assessment techniques if you need specific tools. One specific issue I ran into: ISO 73 defines "risk acceptance" as a treatment option, but it doesn't define the criteria for when acceptance is appropriate. That gap caused a real problem for a client of mine in the healthcare sector. They had a risk register entry for a rare but serious adverse event that the board kept pushing to "accept" because the financial impact was manageable. The risk manager had no vocabulary or framework to push back because the guide doesn't address acceptability criteria at all. The workaround was straightforward but uncomfortable. I went back to ISO 31000's section on risk criteria and built a formal acceptability framework with explicit thresholds for likelihood and severity, then got sign-off from legal and senior management. Once the criteria were documented, the discussion stopped being personal opinion and started being a structured decision. The vocabulary from ISO 73 gave us the term "risk acceptance." The process from ISO 31000 gave us the structure to use it responsibly.
Another gap that bites people: ISO 73 doesn't really address risk appetite and risk tolerance in enough depth for operational use. The definitions are there, but the practical distinction between how much risk an organization is willing to pursue and how much variation it can tolerate around objectives is where most governance frameworks actually break down. I've seen risk appetite statements that were copy-pasted from another industry with no adjustment. The vocabulary was correct. The application was nonsense. If you're building a risk management system from scratch, I'd recommend reading ISO 73 alongside ISO 31000 and ISO 31010 as a set. Use ISO 73 as your reference for terms, ISO 31000 as your process guide, and ISO 31010 as your toolbox. That combination covers more ground than any single document. The vocabulary is useful. It's just not sufficient on its own. Anyone who tells you otherwise is selling something.
