Project risk management: the 5 steps, and how to do each one

Project risk management is the work of finding what could go wrong on a project, and what could go unexpectedly right, before it happens, then deciding in advance what you will do about it. It runs in five steps: plan, identify, analyse, respond and monitor.

Those five steps are also the five domains of PMI's risk credential, the PMI-RMP, so this guide follows them in order. They are a practical overview, not the full process: PMP and PMI-RMP study goes into each step in more detail. Each step below says what the work is, what it produces and where teams usually cut corners.

What is project risk management?

A risk is something that has not happened yet. In PMI's terms it is an uncertain event or condition that, if it occurred, would affect at least one project objective, such as scope, schedule, cost or quality.

Two things follow from that. First, a risk can be good news. A supplier finishing early or a cheaper material becoming available is a risk too, and PMI calls it an opportunity. Second, when a risk happens, the event becomes an issue. You plan for risks; you deal with issues. Any uncertainty that remains, such as how long a delay will last, stays on the risk register.

Risk management in project management is the habit of keeping that list of uncertain events visible, sized and owned for the whole life of the project, not only at kickoff.

Step 1: Plan how you will manage risk

Before anyone logs a single risk, decide how the project will handle them. This is the step most teams skip, and it is 22% of the PMI-RMP exam.

The plan answers a few plain questions. How much risk will the sponsor accept (the risk appetite), and at what point does a risk need escalating (the thresholds)? How will you score probability and impact, so that "high" means the same thing to everyone? Who owns the process, and how often will the team review it? Write the answers down in a risk management plan. It does not need to be long.

Step 2: Identify the risks

Identification works best as a short workshop with the people who will do the work, not as a form the project manager fills in alone. Go through the scope, the schedule, the assumptions and the constraints, and ask what could change each one.

Write every risk in three parts: the cause, the uncertain event and the effect. "Because the vendor has not confirmed a delivery date, the servers may arrive late, which would delay testing by two weeks." A risk written that way can be sized and owned. "Vendor issues" cannot.

Each risk goes into the risk register, the single list of risks for the project, together with its trigger: the early sign that it is about to happen.

Step 3: Analyse probability and impact

You will find more risks than you can act on, so the next step is sorting them. Qualitative analysis scores each risk for how likely it is and how much it would hurt or help, usually on a simple probability and impact grid. The risks in the top corner get a response; the rest get watched.

Quantitative analysis puts numbers on the risks that matter most, for example a schedule simulation that shows the chance of finishing by a given date. It takes time and good data, so it pays off on large or high-stakes projects, not on every risk on every project.

Analysis is 23% of the PMI-RMP exam, level with identification.

Step 4: Plan and implement the response

Every risk that matters needs a response and a named owner. For threats, PMI uses five strategies:

• Avoid: change the plan so the risk cannot happen, for example by dropping a risky feature.

• Transfer: move the impact to someone else, usually through a contract or insurance.

• Mitigate: make the risk less likely or less damaging, for example by testing earlier.

• Accept: acknowledge the risk without acting on it now. Passive acceptance stops there; active acceptance sets aside time or money (a contingency reserve) in case it happens.

• Escalate: hand it up when it is outside the project's authority to deal with.

Opportunities get the mirror image: exploit, share, enhance, accept or escalate.

Accepting a risk is a real decision, not a shrug. Sometimes a response would cost more than the risk itself, and the right answer is to do nothing, write that down and keep a contingency reserve. For the biggest risks, also agree a fallback plan in case the first response fails.

A response on paper changes nothing. The owner carries out the agreed actions when the plan says, or when the trigger fires, and the team checks that they happened and that they worked. PMI's process lists implementing risk responses as a step of its own, because it is the one most often skipped.

Step 5: Monitor and close risks

The register is only useful if it changes as the project does. Review it on a fixed rhythm (the weekly status meeting is the usual place) and ask four questions. Has any trigger fired? Are the responses working? Has a response created a new, secondary risk? Which risks have passed and can be closed?

Watch residual risk too: what is left after a response has done its job. A risk you mitigated is smaller, not gone. At the end of the project, the register becomes lessons learned for the next one.

A worked example: one risk from start to finish

Here is the vendor risk from step 2, followed from identification to closure, on a team that scores probability and impact from 1 to 3 and responds to any risk scoring above 4.

1. Identify: because the vendor has not confirmed a delivery date, the servers may arrive late, which would delay testing by two weeks.

2. Analyse: probability 2 (possible) and impact 3 (testing is on the critical path). The score is 6 out of 9, above the threshold, so it needs a response.

3. Respond: mitigate. The project manager asks the vendor to confirm a date by Friday, and the team lines up cloud test environments as a fallback. The infrastructure lead owns the risk.

4. Implement: the request goes out the same day, and the cloud environments are ready to switch on but not yet paid for.

5. Monitor: the trigger is no confirmed date by Friday. The vendor confirms on Thursday, so probability drops to 1 and the score falls to 3, below the threshold.

6. Close: the servers arrive on time. The risk is closed in the register, with a note on what worked for the next project.

In the risk register, that risk is one row:

• Risk: servers arrive late, delaying testing by two weeks

• Cause: the vendor has not confirmed a delivery date

• Probability and impact: 2 and 3 (score 6)

• Trigger: no confirmed date by Friday

• Response: mitigate, with cloud test environments as the fallback

• Owner: infrastructure lead

• Status: open, reviewed weekly

Where project risk management goes wrong

Most failures are not about technique. They are habits:

• The register is filled in once at kickoff and never opened again.

• Risks are written as categories, such as "resources" or "budget", that nobody can act on.

• Only threats are listed, so the opportunities are never used.

• Every risk belongs to the project manager, so in practice none of them has a real owner.

• Accepted risks have no contingency behind them.

Treat risk as something you run every week, not a document you produce once.

How project risk management appears on the PMP exam

Risk is part of the PMP exam rather than a section of its own. In PMI's 2026 exam outline, "Plan and manage risk" is a task in the Business Environment domain, which is 26% of the exam. It covers identifying and analysing risks, developing a risk management plan, maintaining a risk register, carrying out the responses and communicating the status of risks.

Two related points sit elsewhere in the outline: recognising when a risk becomes an issue, and quantifying risk and contingency money when you plan the budget. And because about 60% of PMP questions use agile or hybrid approaches, expect risk questions set in agile teams too, where risk is handled through the backlog and short iterations, not only at fixed checkpoints.

If the PMP is your next step, our PMP course covers risk alongside the rest of the outline.

Do you need the PMI-RMP to manage project risk?

No. Every project manager manages risk, and the PMP exam has a whole task on planning and managing it. The PMI-RMP is for people who already own risk on a project: the person who runs the risk register, leads the workshops or quantifies risk for decisions other people make. PMI counts only months spent on project risk management toward it, so it shows a specialism that a general credential cannot.

Its exam follows the five steps above: Risk Strategy and Planning (22%), Risk Identification (23%), Risk Analysis (23%), Risk Response (13%) and Monitor and Close Risks (19%). If you are weighing it up, read is the PMI-RMP worth it?

To apply, PMI asks for project risk management experience within the last five years plus risk management education: 36 months and 40 hours with a secondary diploma, 24 months and 30 hours with a bachelor's degree, or 12 months and 30 hours with a degree from a GAC accredited program.

Our live PMI-RMP course is 35 hours, built on PMI's current Exam Content Outline, with weekly reviews and quizzes, mock exams, and help with your application and any audit. We teach risk as something you run on Monday, not only something you sit an exam on.