The register was in good shape once. At kick off there was a proper risk workshop: risks identified, scored for probability and impact, owners assigned, mitigations agreed. Everyone left the room feeling the project was under control.
Six weeks later, a supplier problem surfaces in a status meeting and someone asks whether it is on the register. It is not. Neither are the four other things that have gone sideways since the workshop. Keeping a risk register updated on a manufacturing programme turns out to be one of those jobs that everyone agrees matters and nobody has the time to do.
If that describes your project, the problem is not discipline. It is structural, and it has a fix.
The Register Starts Strong and Then Decays
Every risk register I have inherited follows the same curve. High quality at project initiation, when there is a workshop and dedicated time. Steady decay from week three onwards, as the project gets busy and the register drops down the priority list.
By the middle of the project the register describes the risks the team could imagine at the start, not the risks the project actually has. The two lists overlap less than you would hope. The risks that materialise are usually the ones that emerged in week five, in a supplier call or a design review, and never made it into the file.
This is worth naming precisely: a risk register nobody updates is not risk management. It is paperwork that photographs how the project looked at kick off.
Risks Do Not Appear Where the Register Lives
The core structural problem is a location mismatch. Risks surface in conversations: status meetings, supplier calls, design reviews, corridor chats after the daily walk around. The register lives somewhere else entirely, usually a spreadsheet on a shared drive that must be opened, edited, versioned, and saved.
That gap between where a risk is spoken and where it is recorded has to be bridged by a person doing manual work after the meeting. I wrote about this pattern in more detail in the meeting to project record gap: decisions and risks generated in meetings reach the formal record late, partially, or not at all, because the transfer step is manual and always loses to more urgent work.
For risks specifically, the transfer step is worse than for actions or decisions. A risk entry needs a description, a probability and impact score, an owner, and a mitigation. That is five fields of structured thinking, reconstructed from memory, hours or days after the conversation that identified it. Deferring it is rational. Deferring it forever is common.
A risk logged two weeks late is not just a documentation gap. It is a mitigation that started two weeks late. The register lag and the response lag are the same lag.
The Spreadsheet Makes It Worse
Most manufacturing project teams run the register in Excel. I understand why: it is available, familiar, and free. But the format actively contributes to the decay.
A spreadsheet has no owner prompts, so nothing nudges the person responsible for a mitigation to report movement. It has no connection to the schedule, so a risk that threatens a milestone sits in a different file to the milestone it threatens. It usually has a single de facto editor, the project manager, because shared editing of a scored register invites version chaos. I have covered the broader trade offs in the comparison between Excel and a structured project system, but the short version for risk management is that the spreadsheet turns a team process into one person's admin task.
And when updating the register is one person's admin task, it competes with everything else on that person's list. It loses most weeks.
What a Stale Register Costs in a Regulated Environment
In regulated manufacturing and med-tech, the register being out of date is not only a delivery problem. It shows up in three places that matter.
First, gate reviews. A phase gate decision made against six week old risk data is a decision made on incomplete information. Sponsors approve gates believing the risk picture in front of them is current. When it is not, the governance process is performing confidence rather than providing it. Both ISO 21502 and the PMBOK treatment of risk describe risk management as a continuous activity through the life of the project, not an initiation deliverable. If you want the plain language version of what that standard expects, I have written a guide to ISO 21502 separately.
Second, audits and customer assessments. Auditors can tell the difference between a register that is lived in and one that was reconstructed the night before. Edit history, mitigation progress notes, and closed risks with dates tell the real story. In med-tech especially, a project register that visibly lags reality invites questions about what else does.
Third, escalation. A risk that is not on the register cannot be escalated through any formal path. It travels by hallway conversation instead, which means the people with authority to act on it hear about it late, secondhand, or not at all.
One distinction worth keeping sharp in med-tech: the project risk register is not the ISO 14971 design risk file. Product safety risk and delivery risk are separate records with separate owners. A project register stuffed with design risks, or a design file doing double duty for schedule risks, serves neither purpose well.
Keeping the Risk Register Updated: What Actually Works
The fix is not more discipline applied to the same process. It is changing the process so the register gets updated inside work that already happens, rather than as extra work afterwards. Five changes make most of the difference.
-
1
Make the top risks a standing agenda item
The first ten minutes of every status meeting: walk the top five risks by exposure, ask each owner what moved. The register gets reviewed inside a meeting that already exists, at zero additional calendar cost. If a risk owner has nothing to say about their risk two meetings running, the risk is either stale or unowned.
-
2
Capture at the moment of identification
When a risk surfaces in a meeting, log it in the meeting: a one line description and an owner, nothing more. Scoring and mitigation planning can happen later. The expensive failure is the risk that was spoken and never written. A thin entry captured live beats a complete entry that never gets created.
-
3
Owners update their own risks
The project manager should audit the register, not write it. Each risk owner updates their own entries before the status meeting. This is the single change that moves the register from a reporting artefact to a management tool, and it is also the hardest to enforce. Tie it to the agenda item in change one: owners who know they will be asked in the meeting update beforehand.
-
4
Keep the live register short
A forty entry register is unreviewable, so it does not get reviewed. Hold the live register to the ten or fifteen risks that genuinely carry exposure, ranked, and archive the rest where they can be revisited at phase boundaries. Reviewing fifteen entries fortnightly beats admiring forty entries never.
-
5
Tie register currency to the gate
Add one line to your gate entry criteria: the register has been fully reviewed within the last ten working days, with evidence. This converts keeping the register updated from good behaviour into a condition of passing the gate, which is the only kind of rule that survives a busy programme.
Where Tooling Earns Its Place
Process changes carry most of the weight, but the location mismatch from earlier is fundamentally a tooling problem. If the register lives in the same system as the schedule, the actions, and the gate checklists, then updating a risk stops being a separate trip to a separate file. Risk review becomes part of the same working session as everything else, and exposure against specific milestones becomes visible instead of implied.
The emerging step beyond that is capture assistance: tools that can take what was said in a meeting and propose a structured register entry from it, with a description, a suggested owner, and draft scoring for the project manager to review. The important word is propose. Nothing should enter a governed project record without a person confirming it. But reducing the capture task from write it from scratch to review and approve removes most of the friction that lets registers decay in the first place.
Teams running NPI programmes in regulated manufacturing feel this more than most, because their documentation requirement is not optional and their risk picture moves weekly. For a practical walkthrough of building the register itself, including scoring and field structure, see the earlier post on building a risk register your team will actually use.
Start With an Honest Look at Your Own Register
Open your register today and check three things. The date of the most recent new entry. The date of the most recent update to an existing entry. And whether the biggest problem currently occupying your project appears on it at all.
If the answers are uncomfortable, you are in the majority, and the cause is the structure of the process rather than the diligence of the people. Fix the structure: review inside existing meetings, capture at the moment of identification, owners updating their own risks, a short live register, and currency tied to the gate.
I have been talking with programme managers and engineering leaders across regulated manufacturing about how their teams keep project records current, risk registers included. If you would like to compare notes on what is working and what is not, the calendar link below is the easiest way to start that conversation.
Frequently Asked Questions
How often should a risk register be updated on a manufacturing project?
The register should be touched at the same cadence as your project status rhythm. On an active NPI or capital programme running weekly status meetings, the top risks by exposure should be reviewed weekly and the full register at least fortnightly. The register should also be brought fully current before every phase gate review, because a gate decision made against stale risk data is a decision made on incomplete information. A register that is only updated before gate reviews is not a risk management process. It is gate preparation.
Why do risk registers go out of date so quickly?
Three structural reasons. First, risks surface in meetings, supplier calls, and corridor conversations, but the register lives somewhere else, usually a spreadsheet on a shared drive, so capture requires a separate manual step that gets deferred. Second, ownership is concentrated: the project manager maintains the register on behalf of everyone, which makes updating it one more administrative task competing for their time. Third, the initial register is often too long. A register with forty entries is expensive to review, so reviews get skipped, and the register decays.
Is the project risk register the same as the design risk management file in med-tech?
No, and conflating them causes problems in both directions. The design risk management file required under ISO 14971 addresses product safety risk: harm to patients and users. The project risk register addresses delivery risk: schedule, cost, resource, supplier, and regulatory pathway risks. They interact, because a product risk finding can create a project delay, but they are separate records with separate owners, separate review cadences, and separate audiences. The project register should reference the design risk process where relevant, not duplicate it.
Who should own the risk register?
The project manager owns the register as a record, but each risk should have a named owner who is responsible for the mitigation and for reporting movement on that risk. The most reliable pattern is that risk owners update their own entries before the status meeting, and the project manager audits the register rather than writing it. When the project manager is the only person who ever touches the register, it becomes a reporting artefact rather than a management tool, and it will always lag reality.
How do you keep a risk register updated without adding admin time?
Capture risks at the moment they are identified rather than reconstructing them later: name the risk, assign the owner, and log a one line description in the meeting itself, then score and refine it afterwards. Keep the live register short, ten to fifteen entries ranked by exposure, with everything else archived. Make the top five risks a standing agenda item so review happens inside meetings that already exist. And tie register currency to gate criteria so that keeping it updated is part of passing the gate, not extra work on top of it.
When did your register last tell you something you did not already know?
I am talking to programme managers and engineering leaders in regulated manufacturing about keeping project records current without adding admin. If you would like to compare notes, let us talk.
Book a 20-Minute Call