Many people picture thick reports when they hear "risk management". For us it is mostly a fixed way of writing down what can go wrong, deciding what to do about it and making someone responsible for doing it. Here is how that works in practice.
First, know the risk exists. Seeing the risk is the most important part. Once you know something can go wrong, you naturally pay more attention to it.
Key idea: a risk nobody has noticed is a risk in itself.
We look for them actively. Sources include:
- internal audits and incident reviews
- customer feedback and support tickets
- deviations we find in our own work
- changes such as a new feature, a new dependency, an external service or a change in the team
- a "what if this breaks?" during sprint planning or a retrospective
Anyone can report a risk, not just management.
We look at three areas: information security (confidentiality, integrity and availability), the quality of what we deliver, and business continuity. One risk can play out differently in each. Let's look at a few examples. We score likelihood and each of the five impact areas from 1 (low) to 5 (high). The level is likelihood multiplied by the highest impact.
A risk in one sentence. Vague worries can't be assessed. So we write every risk in the same shape: there is a risk of a cause, leading to a consequence, resulting in an effect on our objectives. For example, a vulnerability in a software library may not be noticed in time, allowing it to be exploited and potentially giving access to client data.
Cause, consequence and effect get their own columns in the risk register. That shows straight away where you can act: prevent the cause or limit the damage from the consequence.
Splitting what is separate. If one sentence contains more than one cause or consequence, we split the risk. "An outdated library may cause security, performance and compatibility problems" becomes three risks. We split when the answer to any of these is yes:
- Are cause and consequence clearly distinguishable?
- Can you rate the likelihood of each scenario on its own?
- Would the approach or the owner differ per scenario?
It is more work than one line, but it gives you something to act on. An automated check for vulnerabilities solves something different from a performance test, and often a different person is behind it.
Likelihood, impact and risk level
A risk is a judgement about an uncertain future: something that hasn't happened, and may never happen. So we can't measure it like a temperature. We can assess separate elements:
- Likelihood: how probable is it that the scenario occurs?
- Impact: how bad is it if it does?
- Risk level: likelihood combined with impact. A very unlikely event with a huge impact can weigh as heavily as a likely, small nuisance.
Two risks with the same level can be very different: a small chance of a huge impact (a laptop with client data goes missing) or a large chance of a small impact (an external service is unavailable for fifteen minutes). That is why we record the elements separately rather than only the final score.
Examples of risks we assess this way include a vulnerability in a software library going unnoticed, a key person becoming unavailable, an external service we depend on failing or changing its terms, and a secret accidentally ending up in a log file. We assess likelihood and impact separately for confidentiality, integrity, availability, quality and continuity, then use the highest impact. Top management decides which levels of risk we may accept. We also record why we assessed a risk as we did, so we can check whether the reasoning still holds at the next review.
| Risk | Likelihood | Confidentiality | Integrity | Availability | Quality | Continuity | Level |
|---|---|---|---|---|---|---|---|
| A secret ends up in a log file by accident | 3 | 5 | 2 | 1 | 1 | 1 | 15 |
| Only one person understands a certain system, and they are gone | 3 | 1 | 1 | 3 | 3 | 5 | 15 |
- The secret in the log and the person who is gone both score 15, but one affects only confidentiality and the other only continuity. The first is addressed by cleaning up logs and rotating the secret; the second by sharing knowledge. If we scored only "security", the continuity risk could remain nearly invisible.
Four choices per risk. After the assessment we pick one of four options:
| Option | What it means |
|---|---|
| Avoid | Stop the activity |
| Mitigate | Put measures in place |
| Transfer | Place the risk with someone else, for instance through insurance or outsourcing |
| Accept | Knowingly accept it because it stays within our limits |
If we choose anything other than acceptance, we determine which measures are needed, who becomes the risk owner and what the deadline is. We also estimate how much risk remains once the measure is in place: the residual risk. We weigh the cost of a measure too, because removing every risk completely is not always sensible.
Coming back to it. The register is not a one-off document. We go through it regularly, and also when something big changes, such as a new project, new regulation or a major system change. Then we check whether existing measures still work, how the actions are progressing and whether new risks have appeared. The policy itself is reviewed yearly and after a major incident.
A fixed format and an owner per risk make the subject concrete: a decision with a name and a deadline attached, rather than a general feeling. Each reassessment is part of our continual improvement: a risk that happens more often than expected gets a stronger measure and an owner to see it through.