Monday morning, twenty minutes before the weekly status meeting, the project manager opens the risk register, changes two ratings and marks the rest “no change”. What the register does not show is that a supplier said on Wednesday that the test environment would be “a few days late”, and the date by which the team could still switch to a fallback environment passed on Friday. The risk was on the register. It was reviewed on schedule. It was reviewed too late.
That is the real problem behind the question of how often project risks should be reviewed. A calendar interval matters, but it is only a backstop.
How often should project risks be reviewed? The short answer
Review the most consequential risks at least weekly during active delivery, give the few fast-moving risks brief daily attention near a launch, cutover or other critical decision, and reassess any risk as soon as an event changes it. Above all, the next review of a risk must happen before the last useful decision point for that risk. If a response has to be triggered by Thursday, a review scheduled for next Monday is not a review at all.
These intervals are a starting point, not a standard. The Association for Project Management describes project risk management as reflecting “the dynamic nature of project work, capturing and managing emerging risks and reflecting new knowledge in existing risk analyses”, but it does not prescribe one review frequency for every project (APM, What is risk management?).
Monitoring a risk is not the same as reviewing it
- Monitoring means watching an agreed indicator: has supplier access arrived, did last night’s data load pass, has the client confirmed the approver? It is cheap, can happen daily and usually sits with the risk owner.
- Reviewing means formally reassessing the risk: is the cause still present, has the likelihood or impact changed, is the response working, what exposure remains, and does anyone need to decide something? It takes time and the right people.
You do not need a daily risk meeting. You need indicators that are watched often enough, and a clear rule that a changed indicator triggers a review. This is why every risk worth keeping should carry an observable trigger, which is part of how you identify project risks before they become delivery problems.
A starting cadence for client delivery work
This is our editorial recommendation for professional services engagements: a baseline to adapt, not a rule.
| Stage or situation | Suggested rhythm | What to inspect |
|---|---|---|
| Before committing to scope, price or dates | One structured review before the commitment | Scope, business outcome, client obligations, capacity, suppliers |
| Ordinary active delivery | Weekly review of the top risks; lower-exposure risks on a rotating basis | New evidence, overdue responses, next decision dates |
| Within about two weeks of a launch, cutover or hard deadline | Brief daily check of the few risks whose exposure changes quickly | Test results, access, rollback readiness, critical dependencies |
| Phase gate, release or commercial decision | Review before the decision is approved | Residual exposure, acceptance evidence, contingency |
| Quiet periods, such as waiting for client funding | Fortnightly or monthly, with triggers still active | Whether assumptions still hold, dates of known upcoming decisions |
Weekly suits most delivery teams because they already plan weekly and most client decisions take days, not hours. It stops working when a risk’s decision window is shorter than a week.
Set each review date from the latest useful decision date
The most useful field you can add to a risk register is the latest useful decision date: the last day on which a response can still be chosen and carried out in time to matter. Work it out backwards:
- Identify the milestone or outcome the risk affects.
- Estimate how long the realistic response takes to execute, such as booking a fallback environment, bringing in a contractor or getting a change approved.
- Subtract that lead time from the milestone date. That is the latest useful decision date.
- Schedule the next review early enough before it to gather evidence and reach the decision-maker.
If the next scheduled review falls after that date, bring that one risk’s review forward.
This works outside software, too. An engineering consultancy waiting on a geotechnical survey before finalising a foundation design might know the design pack is due to the client on the 30th, and that re-running the analysis with conservative assumptions and checking the pack takes eight working days. The decision to stop waiting therefore falls around the 18th, about a week and a half before the deadline, whatever day the fortnightly design review happens to be.
Event triggers: review now, not at the next meeting
Agree with the team that any of these events prompts a review of the affected risks within one working day, whatever the calendar says.
- A test fails or produces an unexplained result on something a milestone depends on.
- Scope changes, including informal requests the team has started to accommodate.
- A key person becomes unavailable, through leave, illness, resignation or reassignment to another client.
- A supplier or third party slips, misses a date or changes its commitment.
- The client provides new evidence: a changed process, a new stakeholder, a delayed decision or feedback that challenges an assumption.
- A risk response is completed. Responses can fail to reduce the original risk, and, as a guest post on the APM blog notes, measures taken to reduce one risk can raise others or create new ones, so re-evaluate after applying them (APM blog, risk-based thinking).
- An assumption’s validation date passes without confirmation.
- A commercial decision is approaching: a change request, a phase sign-off or a renewal.
Whoever notices the event tells the risk owner the same day; they do not need to run the review.
How to run a 20-minute risk review
Focus on change rather than reading every row aloud.
- What changed since last time? (5 minutes) Owners report only new evidence and triggered indicators. “No change” risks are not discussed.
- Which responses are overdue or not working? (5 minutes) Check actions against due dates. A completed action does not prove the risk has reduced, so ask what exposure remains.
- Which decision dates fall before the next review? (5 minutes) For each, agree who decides, what evidence they need and when.
- Escalations and new risks (5 minutes) Confirm what goes to the sponsor or client, and give any newly spotted risk an owner who will describe it properly after the meeting.
Record decisions, not discussion: what was decided, by whom, and the new review date.
Escalate on tolerance and authority, not colour
A red rating says a risk scored highly, not that anyone needs to act. Escalate when any of these is true:
- the team cannot authorise the response, for example because it costs money, changes scope or needs client action;
- exposure exceeds the tolerance agreed with the sponsor or client;
- the latest useful decision date is close and nobody with authority has decided.
Record the risk owner, action owner and decision-maker separately. Confusing them is how a risk sits “owned” while nobody can approve the response. If nobody has named the decision-maker, that belongs in the project charter, not in the risk meeting.
Hypothetical example: a Friday cutover
An IT consultancy is migrating a client’s finance system, with cutover scheduled for Friday evening. The risk review is normally held on Monday. One risk reads: “Because the legacy data contains inconsistent supplier codes, the final data load may fail validation, delaying cutover and leaving the finance team unable to process month-end payments.”
On Monday the risk is rated moderate. The response is a cleansing script, and the rehearsal load on Wednesday is the indicator. The team has recorded a latest useful decision date of Thursday at noon, because preparing and communicating a rollback plan to the client’s finance team takes a day and a half.
On Wednesday afternoon the rehearsal fails: several hundred supplier records are rejected. This is a trigger, so the risk owner calls a 30-minute review that day rather than waiting for Monday. The team sets out three options: fix and re-run on Thursday morning, proceed with manual workarounds for the rejected records, or move cutover by a week.
The difficult exception: the client’s finance director, who must approve any cutover change, is travelling until Thursday afternoon, after the decision deadline. Waiting would mean the decision is made by default. The project manager escalates on Wednesday evening to the client’s project sponsor with what failed, what it affects, the three options, a recommendation to prepare rollback alongside the fix, and the time a decision is needed. The sponsor approves preparing both paths. Thursday’s re-run passes; the rollback plan is not needed, but it existed in time.
The Monday meeting did not fail. It was never going to be where this decision was made.
Risk review cadence and trigger worksheet
Copy these columns into your register or use them as a one-page review sheet. The sample rows are hypothetical.
| Risk (cause, event, effect) | Owner / decision-maker | Latest useful decision | Next review | Trigger to review early |
|---|---|---|---|---|
| Supplier environment late, so integration testing slips and go-live moves | Tech lead / client IT manager | 12 Nov: last day to book fallback environment | 10 Nov | Supplier misses any interim date |
| Key analyst leaving, so requirements sign-off slows and UAT starts late | PM / delivery director | 20 Nov: last day to start handover | 17 Nov, then weekly | Resignation, leave request or reassignment |
| Client approver unavailable, so design pack acceptance is delayed | Account lead / client sponsor | 5 Dec: last day to agree a delegate | 28 Nov | Approver travel or change of role |
| Data quality poor, so cutover load fails and month-end is disrupted | Data lead / client finance director | Thursday 12:00 before cutover | Daily in cutover week | Any failed rehearsal load |
Pre-review checklist
- Every active risk has a latest useful decision date, or a note explaining why none applies.
- No next review date falls after its latest useful decision date.
- Each risk has one observable trigger that someone is watching.
- Completed responses have a residual exposure recorded.
- The escalation route and decision-maker are named for every high-exposure risk.
Limits and the common failure mode
A cadence cannot find risks nobody has thought of, and a latest useful decision date is an estimate that depends on honest lead times. Rating scales help comparison but do not turn judgement into precise probability. On very small engagements, a short list of top risks with dates and triggers, reviewed in the weekly planning conversation, may be all you need.
The most common failure mode is reviewing for the report rather than for the decision: ratings refreshed the night before the status meeting while the indicators that should prompt action go unwatched between meetings. If your risk updates cluster on the day before reporting, add triggers and decision dates, not more meetings.
Put the rhythm where the work already lives
The method works in a spreadsheet. It is easier to keep up when risk records sit in the same system as the project’s tasks and milestones, rather than in a file opened once a week. Chronodesk’s project management includes a dedicated risk register for every project and lets you escalate issues to portfolio level, which suits firms reviewing risk across several client engagements at once.
Your next step this week: add a “latest useful decision” column to your register, fill it in for your top five risks, and move any review that falls after its decision date. For the thinking behind this approach, see why good project management is really about reducing uncertainty and, if your register needs better entries before a better rhythm, how to identify project risks before they become delivery problems.
Frequently asked questions
How often should project risks be reviewed?
A practical starting point is a weekly review of the most consequential risks during active delivery, brief daily attention to the few fast-moving risks near a launch or cutover, and an immediate review whenever a triggering event occurs. No single interval suits every project. The test is whether the next review happens before the last date on which you can still act on the risk.
Is a monthly risk review enough?
It can be for slow-moving, low-exposure risks on a long engagement, such as a contract renewal months away. It is rarely enough for risks tied to a milestone in the next few weeks. Set the review date from each risk’s decision date rather than applying one interval to the whole register.
Who should attend a project risk review?
The project manager, the owners of the risks being discussed and anyone who can authorise the likely responses. For client engagements that often includes the client-side project lead when a risk depends on the client’s decisions or information. Keep it small: people who cannot contribute evidence or decisions can read the notes afterwards.
What is the difference between monitoring a risk and reviewing it?
Monitoring is watching an agreed indicator, such as whether supplier access has arrived or a test has passed, and it can happen daily as part of normal work. Reviewing is formally reassessing the risk: its likelihood, impact, response and residual exposure, and deciding whether to act or escalate. Monitoring should tell you when a review is needed.
When should a project risk be escalated?
Escalate when the team cannot authorise the response, when exposure exceeds the tolerance agreed with the sponsor or client, or when the decision deadline is close and nobody with authority has decided. A red rating on its own is not a reason to escalate, and an amber risk with a deadline tomorrow may need escalating today.