Risk Management

The risk map: seven groups

Here is the whole map first, because it is the part you can use today. Identification decides whether the rest of the process has anything to work with, and it is the step teams do worst — not because it is difficult, but because it is done once, at kick-off, by people who already agree with each other. A list of places to look is worth having precisely because it is not the place you already looked. Six of the groups below are places a risk comes from, which is what the diagram shows; the seventh is what you can do about one once you have found it, and each of its four lines gets a section of its own further down.

1. 1.Business risks

   1. 1.1Market uncertainty: changes in demand, competition, trends.
   2. 1.2Financial risks: budget overrun, a shortfall in funding.
   3. 1.3Strategic risks: goals that are not aligned between the business and the technical teams.
   4. 1.4Changes in leadership: loss of key people, changes to the company strategy.
   5. 1.5Unrealistic expectations: overestimating development speed, or the project’s payback.

2. 2.Technical risks

   1. 2.1Architecture problems: the wrong choice of technology, monolith vs. microservices.
   2. 2.2A weak codebase: technical debt, outdated technologies.
   3. 2.3Scalability and performance: the system does not hold up under load.
   4. 2.4Integration risks: external APIsAPIApplication Programming Interface — contract between programsThe rules one program follows to call another: which requests it may send, in what shape, and what comes back. To the caller it is a contract — everything behind it stays a black box, which is exactly what lets the other side be rewritten without breaking you.Full article →All terms, difficulty integrating with other services.
   5. 2.5Security: data leaks, vulnerabilities, no audits.

3. 3.Process risks

   1. 3.1Delays in development: wrong time estimates, delays in dependencies.
   2. 3.2Changing requirements: frequent pivots, no stable backlog.
   3. 3.3Quality problems: no testing, bugs in production.
   4. 3.4Missing documentation: technical decisions not described in enough detail.

4. 4.Team risks

   1. 4.1A gap in competencies: critical skills missing, engineers not at the level required.
   2. 4.2Loss of key employees: burnout, resignation.
   3. 4.3Communication problems: teams out of step with each other, conflicts.
   4. 4.4Low productivity: no motivation, problems with management.

5. 5.Operational risks

   1. 5.1Failures in production: servers going down.
   2. 5.2Dependence on third-party services: an API switched off, problems with suppliers.
   3. 5.3Gaps in security: no backups, weak authentication.

6. 6.Legal and compliance risks

   1. 6.1Licensing problems: the use of third-party libraries, patents.
   2. 6.2Regulatory constraints: GDPRGDPRGeneral Data Protection Regulation — EU personal-data lawThe European regulation governing personal data: what you may collect, on what legal basis, how long you may keep it, and what a person can demand you do with theirs. It applies by where the people are, not by where the company is, which is why it reaches software built anywhere.All terms, HIPAA, financial regulations.
   3. 6.3Data confidentiality: protecting users’ personal data.

7. 7.Risk management strategies

   1. 7.1Avoiding the risk: not taking on high-risk technologies.
   2. 7.2Mitigating the risk: introducing testing and security audits.
   3. 7.3Transferring the risk: insurance, using SaaS solutions.
   4. 7.4Accepting the risk: accepting risks deliberately, with contingency plans.

A risk is not a problem yet

A risk is something that has not happened. That sounds too obvious to state, and it is the distinction the whole practice rests on: the moment it happens it becomes an issue, it costs whatever it costs, and your options have collapsed to the ones still available at that moment. Everything risk management can do for you happens in the window before that — which is also the window in which the work is cheap, unglamorous, and very easy to postpone.

The second thing to get right is what a risk statement is. "The payment provider might be a problem" is a worry, not a risk: nobody can act on it, nobody can tell whether it got better, and it will sit in the register for eight months looking responsible. A usable statement has three parts. The cause is a fact you can check today. The event is the uncertain thing. The effect is what it costs you.

Three neighbouring things get filed as risks and are not, and separating them is most of what makes a register readable.

The assumption row is the cheapest move available to a project manager. Every plan rests on a pile of things nobody checked — that the client will review within a week, that the legacy export is documented, that the one engineer who knows the billing code will still be here in March. Writing down what each one costs if it is false converts a comfortable silence into something with an owner, and it takes an afternoon.

Why the list stops growing

The seven groups are not equally visible, and the order in which a team notices them is close to the reverse of the order in which they do damage. Technical risk gets the most attention because engineers enjoy discussing it and it is the one they are qualified to argue about. Team risk and legal risk almost never surface until one of them is already an issue — the engineer resigns, or a customer’s lawyer asks which jurisdiction the backups are in.

Sizing a risk without faking precision

Two questions decide what happens to a risk: how likely is it, and how much would it cost. Everything else in this part of the practice is an elaboration of those two, and most of the elaborations make the answer worse rather than better.

The template most organisations use scores probability from one to five, impact from one to five, multiplies them, and sorts by the product. It feels like analysis and it is close to arithmetic theatre. The scores are guesses dressed as measurements; multiplying two ordinal scales produces a number with no meaning; and the ordering it generates is unstable — a risk at 12 and a risk at 15 get the same response, while the difference between them is decided by whoever was most confident in the room.

The version that survives contact with a real project is coarser and more honest. Put impact in units somebody outside the team understands — money, days of delay, users affected, an order of magnitude is enough. Put probability in three bands: likely, possible, unlikely. Then place the risk on the grid above and read off the response. Two risks landing in the same quadrant get the same treatment, which is exactly right, because they were always going to.

Set the threshold before you score anything

Risk appetite is how much uncertainty the organisation is willing to carry to get what it wants; tolerance is the line past which a specific risk stops being the team’s to decide. Both have to be agreed before the scoring, in numbers: a delay of more than two weeks goes to the sponsor, anything that touches personal data goes to legal, any single risk over a set sum goes to the steering group. Agreed afterwards, the threshold is not a control — it is a justification for the answer somebody already wanted.

When numbers are worth the effort

Expected monetary value — probability times cost — is a legitimate tool in one situation: when you have many similar risks and the question is how much contingency to hold in total. Across forty small risks the averages behave. It is close to meaningless for a single catastrophic risk, because you will not run the project forty times; a 2% chance of losing the client is not "4% of the contract value", it is a coin you flip once.

For schedule risk there are two techniques worth knowing. A three-point estimate — optimistic, likely, pessimistic — asked per task and combined, gives a range instead of a date, and the range is the honest answer. A Monte CarloMonte Carlosimulation by many random runsA method that answers a question by running it thousands of times with randomly sampled inputs and reading the distribution of the results. On a schedule it replaces a single date with a range and a probability, which is the honest form of an estimate built out of twenty uncertain tasks.All terms simulation does the same thing properly by sampling those ranges thousands of times, and its real value is not the output but the conversation: it makes visible that a plan of twenty tasks each "usually fine" has a very low chance of all being fine at once.

Four responses, and the fifth one

Once a risk is stated and sized, there are only four things you can do with it. Choosing between them is the decision the whole register exists to produce, and a register where every row says "monitor" has not produced one.

Accept is the one that gets skipped, and it is the most common correct answer. A project with forty identified risks cannot afford to mitigate forty of them, and pretending otherwise spends the budget on the cheap ones and leaves nothing for the expensive one. Accepting properly is an act with three parts: it is written down, somebody senior enough agreed to it, and there is a contingency — a reserve of money or days that exists precisely because some accepted risks will land.

The fifth response, which PMBOKPMBOKA Guide to the Project Management Body of Knowledge — PMI’s project management referenceThe Project Management Institute’s reference for managing projects, and the basis of the PMP certification. The edition matters: the 6th (2017) prescribed 49 processes, the 7th (2021) replaced them with twelve principles, and the 8th (2025) has six principles, seven domains and forty processes.Full article →All terms’s 6th and 7th editions name explicitly, is escalate: the risk is real and the decision is not yours. PRINCE2 has no response by that name and gets to the same place through its exception procedure, which sends anything beyond the project manager’s tolerances up to the board. A risk that would change the business case, breach a regulation, or need money outside your budget belongs to whoever owns those things, and holding onto it out of a sense of ownership is the single most common way a project manager turns a manageable risk into an unrecoverable one. Escalation is not failure; escalating without a recommendation is.

One more thing worth naming, because half the standards include it and almost no team uses it: the same four responses exist for the upside. A risk with a positive effect is an opportunity, and you can exploit it (make it certain), enhance it (make it more likely), share it (partner with someone who can capture it) or accept it. The reason to bother is not symmetry — it is that a register full of threats teaches a team that planning ahead is a defensive activity, which is a bad thing for it to learn.

The practices that actually move the number

Everything above is analysis, and analysis on its own has never prevented an outage. The practices below are the ones that change what happens, roughly in order of how much they return for the effort.

A register that is a control, not a document

A risk register earns its place when it changes decisions, and it does that only if it is short enough to read. Six fields do the work: the statement in cause–event–effect form, the owner, the response, the trigger, the review date, and one line on what has changed since last time. Anything else is reporting. Fifteen live risks is a lot for one project; a register with sixty rows has become an archive, and an archive is read once a quarter by the person who has to present it.

Attach the review to a meeting that already exists rather than creating a risk meeting, which will be the first thing cancelled in a busy month. Fifteen minutes in an existing weekly is enough if the question asked is specific: which rows changed, which triggers fired, and what have we learned since that belongs here. Scrum teams have no register in the Guide and do not need to invent one — risks that need work become backlog items with owners, and the sprint review is the checkpoint where a stakeholder can see them.

The pre-mortem

A pre-mortem, from Gary Klein’s work on decision-making, is the highest-return hour in this whole article. You gather the team before the work starts and say: it is a year from now, this project failed completely, write down why. Then everyone writes silently for five minutes before anyone speaks.

Two things make it work where a risk workshop does not. Assuming the failure has already happened licenses people to say things that would sound disloyal as a prediction — "the client never gave us the data" is easy to write about the past and hard to say about the future in front of the client’s account manager. And writing before speaking stops the first confident voice from anchoring the room, which is the mechanism by which a workshop run by the person with the most authority produces the risks that person already believed in.

Buy information instead of writing a mitigation

Most technical risks are not really risks, they are ignorance — and the response to ignorance is an experiment, not a plan. If nobody knows whether the legacy export can handle a million rows, no amount of mitigation writing will find out; two days and a script will. This is the oldest idea in the field: Barry Boehm’s spiral model, from 1986, sequences a project by which unknown is most dangerous rather than by which component comes first architecturally.

The practical form of this is sequencing. Put the frightening work first: the unfamiliar integration, the migration, the piece with a hard external dependency, the part nobody on the team has built before. It feels wrong, because the easy work demonstrates progress and the frightening work produces two weeks with nothing to show. It is right for one reason — a discovery in month two has a plan, a budget and a calendar around it, and the same discovery in month eight has none of those.

Rehearse the recovery, not the failure

Any control you have never exercised is a belief. Restore the backup into a scratch environment and time it. Run the rollback on a Tuesday afternoon with the team watching. Hold a game day where somebody turns off a dependency on purpose and the rest of the team works out what breaks — which is the entire idea behind chaos engineeringchaos engineeringbreaking things on purposeDeliberately causing failures in a running system to find out what it does before the failure happens by itself. The point is timing rather than bravado: the same instance dying at 3 a.m. unrehearsed is an incident, and at 2 p.m. with the team watching it is a finding.All terms, and it applies long before you are running at Netflix’s scale. In every one of the incidents in the next section, the control existed on paper and had never been run.

Two more that pay for themselves on any project of size. Threat modelling — walking through a feature asking what an attacker would do with it, with STRIDE as the checklist if you want one — is the only reliable way security risks get identified before a penetration test finds them at ten times the cost. And a blameless post-mortempost-mortema written review after a failureA written review held after something went wrong, covering what happened, why, and what changes so it does not happen the same way. The word "blameless" in front of it is not politeness: an engineer who expects to be blamed reports less, and a review that produces a lesson rather than a change to a system has produced nothing.All terms after every incident, with one rule: the output is a change to the register or to a control, not a lesson. "Be more careful" is not a control.

Six failures and the control that was missing

These are the cases worth knowing because each one is documented in public by the organisation it happened to or by a regulator, and because in every one the missing control was cheap, known and boring. None of them failed for lack of talent.

The Equifax and Log4Shell cases are the same failure at two scales. Equifax received the advisory for a vulnerability in a widely used Java component, a patch existed, and the portal that was eventually breached did not get it — the process said "patch it", and no single person was accountable for confirming that any particular system had been patched. Log4Shell, four years later, showed the version of that problem nobody can solve by being diligent: the vulnerable library was pulled in indirectly, by dependencies of dependencies, into software whose owners had no idea it was there. The control in both cases is an inventory — an SBOMSBOMSoftware Bill of Materials — a list of what is insideA machine-readable inventory of every component a piece of software is built from, including the dependencies pulled in by other dependencies. It matters on the day a vulnerability is announced: without one, the question "are we affected?" is answered by guessing.All terms, a list of what is actually running — because every other control assumes you can answer the question "where is this?"

Where it turns into theatre

Risk management is unusually easy to perform without doing. The artefacts are cheap to produce, they look responsible, and nothing about a well-formatted register tells you whether it has ever changed a decision. These are the shapes the theatre takes.

• The register is updated the evening before the steering committee and not opened between meetings.
• "Mitigation: monitor closely" — which names no action, no owner and no date, and is how a row stays green for a year.
• Scores negotiated rather than estimated, because a high score triggers a conversation somebody wants to avoid.
• Risk used as a way of saying no to work, which teaches everyone to stop reporting risks to you.
• Escalation into a group that has no authority or no appetite to decide, which is a delay with a paper trail.
• Everything identified at kick-off and nothing added since, on a project that has been running for eight months.
• A control that exists in a document and has never been executed: the untested restore, the unrehearsed rollback, the failover nobody has triggered.

There is also an honest limit, and it is the most important paragraph on this page. A register cannot contain what nobody imagined. The failures that actually end projects are disproportionately the ones outside anyone’s list — a supplier bought by a competitor, a regulation announced in March, a library maintainer walking away, a pandemic. No amount of identification reaches them, and a team that believes its register is complete is more exposed than one that knows it is not.

The response to that class is not better prediction, it is shorter feedback. Detect faster, recover faster, and make changes reversible — which is why continuous delivery, feature flagsfeature flaga switch around new codeA switch that decides at run time whether a piece of code is active, so it can ship to production turned off and be turned on for a chosen audience later. It separates deploying from releasing, and it costs something: every live flag is a branch in the code that has to work in both states.Full article →All terms, staged rolloutstaged rolloutan update released to a growing share of usersReleasing an update to a small share of users first — 1%, then 5%, 20%, everyone — and checking crash and error rates before each step, so a bad release reaches a few people instead of all of them. It limits how many a bad release reaches, not whether it reaches them: on the app stores a halted rollout does not take the update back from those who already have it.All terms and a rehearsed rollback belong in a risk conversation even though they are usually filed under engineering practice. They are the only controls that work against a risk nobody wrote down. A team that can undo a change in four minutes has bought itself protection from the entire category of things it failed to imagine, which no register can offer.

When to use it

Related pages

• ManagementPM Checklist for a New ProjectA project manager’s first ninety days on a project they did not start is a diagnosis followed by a small number of deliberate changes, not a reorganisation. Month one is for finding out how the work actually flows, month two for agreeing what you will change and with whom, month three for making the first changes land and being able to show what they moved. This page is that checklist, with the situational judgement that decides which parts of it apply to you.
• ManagementPRINCE2PRINCE2 is a structured method for governing projects, built around one question a project must keep answering: is it still worth funding? It says almost nothing about how the work gets done and a great deal about who may decide that it continues. The page opens with one project set up the PRINCE2 way, finished, then covers what the method is, its seven principles, seven practices and seven processes, tolerances and exceptions, two projects it exists to stop, and where it degrades.
• ManagementEstimation MethodsEstimation methods in IT are the units a team uses to predict how much work something will take: story points, man-days, hours or T-shirt sizes. They are not interchangeable. Each one moves the step that turns effort into a date to a different place and a different person, and each fails in its own recognisable way. The page opens with all four side by side and a table of which one fits which decision, then covers why an honest estimate is a range rather than a number, each unit in depth, six documented estimates that went wrong, and where estimating turns into theatre.