Risk Register: Manage Risks Honestly and Openly

A third-party API dependency gets mentioned in sprint one planning. Someone says "that integration might be a problem — the vendor's roadmap is unclear." Heads nod. Nobody writes it down. Twelve weeks later, the vendor accelerates a deprecation, the integration the team built six sprints of work around is on borrowed time, the timeline slips by a month and a half, and at the next steering meeting somebody asks the question everybody knows the answer to: did anyone flag this earlier?

Someone did. The flag never made it into a register. The conversation in sprint one stayed a conversation, and by sprint twelve it was an incident.

This is the failure pattern a risk register is supposed to prevent. It is also the pattern risk registers most often fail to prevent. Most projects have one. Most of those are filled in for a steering committee, updated when the auditor asks, and ignored in between. The register exists. The risks are documented. The team still gets caught out.

The Built to Last™ 2.0 framework treats the risk register differently. It sits inside P04 — The Right Delivery — alongside the Scrum delivery framework, the sprint demo protocol, the decision and accountability log, and the change control register. The risk register answers one specific question honestly throughout the engagement, not just before the next audit: what could go wrong, how likely is it, what would it cost, and who owns getting ahead of it?

This article walks through why most risk registers fail, what makes one actually useful, and how to run one so risks surface in week two as conversations rather than emerge in week twelve as incidents.

What It Costs When the Register Is Missing or Performative

The cost of an absent or token risk register shows up across three lines, and none of them is the line most teams expect.

The first is timeline. Risks that are not surfaced early do not stay small. A third-party dependency that could have been replaced in sprint two with two days of work becomes a vendor migration project costing six weeks if it hides until sprint twelve. A regulatory change that could have been planned around in design becomes a refactor when the deadline is two months away. The cost of a project risk is roughly the cost of mitigation plus the cost of the delay, and both compound the longer the risk hides.

The second is trust. Stakeholders who learn about a problem the same week it becomes critical stop trusting the team's status updates. The most damaging conversation in a delivery engagement is not the one where the team explains a slip. It is the one where the team explains a slip that the stakeholders could have known about three months earlier. The register is the artefact that prevents that conversation. Its absence guarantees it.

The third is decision-making. Risks that are visible can be traded against. A stakeholder who knows the payments integration has a meaningful chance of slipping by a fortnight can decide whether to launch with a fallback flow, defer launch, or accept the slip and brief marketing. A stakeholder who finds out about the same risk in the week of launch can only react. The register is what turns risk management into a leadership tool instead of a project ritual.

Risk management as a discipline is well-established. ISO 31000 codifies what good practice looks like across industries: identify, analyse, evaluate, treat, monitor, communicate. The register is the operating artefact of that discipline at the project level. What goes wrong on most projects is not that the discipline is unknown. It is that the register stops being used.

What a Risk Register Actually Is

A risk register is a living document — a spreadsheet, a board, an entry in a project management tool — that records every identified project risk with a defined set of attributes that let the team and stakeholders treat the risk seriously. At minimum, each entry has six fields: description, likelihood, impact, mitigation, owner, and status.

That sounds bureaucratic. It is not, when the discipline is applied honestly. Each field forces a conversation that would not otherwise happen.

The description has to be specific enough to be actionable. "Integration risk" is not a risk. "The payment provider's sandbox behaves differently from production in three documented ways, so our automated tests may pass while production fails" is a risk. The specificity is what lets the next field be assessed honestly.

Likelihood is the probability the risk materialises within the project's timeframe. Most teams use a three-band or five-band scale. The bands matter less than the discipline of forcing a number. Anyone can call a risk "possible". Forcing the team to put it in a band — and to defend the band when challenged — is what surfaces hidden assumptions.

Impact is what happens if the risk materialises, quantified in the units that matter: timeline slip in weeks, budget cost in dollars, scope reduction in features. A risk that would slip the timeline by a sprint is a different conversation from a risk that would slip it by a quarter. The register is where that distinction lives.

The mitigation plan answers two questions: what reduces the likelihood, and what reduces the impact if the risk materialises anyway. Both matter. A risk whose only mitigation is "we'll deal with it if it happens" is a risk the team has not thought through. Strong mitigations have an action, an owner, and a date.

Every risk has a single accountable owner. Not a team, not a function — a named person whose job it is to track the risk, run the mitigation, and escalate when something changes. Without a named owner, risks drift. Project managers chase them, engineering leads acknowledge them, and nothing moves.

Status is the current state of the risk: open, mitigating, escalated, materialised, or closed. Status changes are the signal that the register is alive. A register where every risk has been "open" since sprint one is a register nobody is using.

The cadence that keeps it honest

The register is reviewed at a defined cadence. In our delivery, that is weekly inside the team and at every fortnightly steering meeting with the client. Weekly reviews ask two questions per open risk: has the likelihood or impact changed, and has the mitigation moved? Fortnightly steering reviews surface the risks that have escalated, the risks that have closed, and the new risks the team has added.

The conversation in the room is the point. The artefact is a record of the conversation, not a substitute for it. A register that updates itself between meetings without the team having to look it in the eye is not a register; it is a status document.

The room

The register is not a project manager artefact. It is built and maintained by the engineering lead, the product owner, the project manager, and at least one named person on the client side. Each writes into it. Each is accountable for the risks they own. The PM is responsible for the register existing and being current; the individual owners are responsible for their risks moving.

Failure modes even when a register exists

Registers fail even when they exist, and the failure modes are predictable. The audit register — kept for compliance, populated by the PM alone, never reviewed in a team setting. The optimistic register — every risk rated low likelihood and low impact because nobody wants to alarm the client. The orphaned register — populated honestly at the start, abandoned by sprint four when the team gets busy. The closed-loop register — risks identified and logged but never escalated, because escalation feels like admitting failure.

Each failure mode has the same root cause: the register stops being a tool for the team and becomes a tool for the optics. The structural fix is a defined cadence, a named owner per risk, a status field that has to change to reflect reality, and a culture where surfacing a risk early is treated as competence rather than alarm.

How to Set One Up and Keep It Useful

For a team running their first honest risk register, the work to set it up is small. The discipline to keep it alive is the real cost.

Start in the first week of the engagement. Before any sprint plans, run a one-hour session that asks the project leads from each function — engineering, product, design, the client side — to name everything they are worried about. Specificity matters. "Performance" is not a risk; "we don't know yet whether the recommendation engine will respond within the latency budget when the data set hits half a million records" is.

Capture every risk in the register with the six fields above. Resist the urge to triage in the room. Forty risks in week one is not unusual and not a problem; the register is a working document, not a deliverable.

Triage in a second session a few days later. Most of the forty will close out as either "not actually a risk" or "addressed by a decision already made". A typical engagement lands on ten to fifteen real risks at the start, with new ones added across the project as the team learns more.

Set the cadence next. Weekly internal review, fortnightly stakeholder review. Put both on calendars before sprint one. Give each risk a named owner with a defined escalation trigger — for example, "escalate to steering within seven days if likelihood moves from medium to high".

What to do this week if you find yourself mid-project with no register or a token register: convene the team for an hour, list the risks honestly, score them honestly, assign an owner to each, and put the next review on the calendar. The first honest review is the one that matters; whatever exists today is replaced by whatever exists after that meeting.

What to avoid: treating the register as a PM artefact. The register works only when engineering leads, product, and the client side all write into it. If the register is only ever updated by the PM, the team will route around it in conversation and the register will reflect the optics, not the reality.

Avoid also the trap of forecasting only known unknowns. The risks the team can name in sprint one are a fraction of the risks the project will encounter. The cadence is what catches new risks as the team learns more — the integration that turns out to be harder than expected, the requirement that quietly shifts, the team member who gives notice. A register that captures only the day-one risks ages out by sprint six.

The register depends on the rest of P04 to be more than a document. The decision and accountability log captures the decisions the register prompts. The change control register captures the scope changes that materialised risks force. The sprint demo protocol is where mitigated risks are demonstrated as closed. Together, they form the delivery discipline that this article assumes is in place; on its own, the register is half a tool. Our project delivery framework shows how the components sit together across an engagement.

A Tale of Two Dependencies

A mid-sized SaaS client at the Scale stage was building a customer-facing analytics module that depended on a third-party data provider's API. In sprint one, the integration engineer flagged in the team chat that the provider's API was on a public deprecation timeline — the current version would sunset in around twelve months and the replacement was in beta with significant breaking changes. The flag was acknowledged. The conversation moved on. Nothing made it into a register.

Six sprints later, the provider announced the deprecation timeline was being accelerated by four months because of a security issue in the older version. The replacement was still in beta. The integration the team had been building was now structurally compromised. Engineering pivoted mid-build to the beta API, absorbed the breaking changes, and rerun the testing already completed on the original integration. The slip was approximately six weeks. The stakeholder conversation that followed was the one nobody wanted.

A second engagement we ran for a comparable client treated the same class of risk differently. A dependency on a third-party payments provider was flagged in week one, scored at medium likelihood and high impact, and assigned to the engineering lead as owner. The mitigation was a small spike in sprint three to verify alternative providers and a written fallback architecture if a switch became necessary. Sprint three's spike confirmed the fallback was viable. The original provider held up through the rest of the build. The fallback was never needed.

The work the second team did on a risk that did not materialise was not wasted. The register entry, the spike, and the fallback document made the risk a non-event when it could have been a project-defining one. The cost was a few engineering days and a few hours of stakeholder discussion. The cost of the first team's identical risk going unregistered was six weeks of timeline and a stakeholder relationship that needed rebuilding.

Same risk. Two completely different outcomes. The difference was whether the team had a register, and whether the register was treated as a tool that earned its keep weekly.

When the Register Is Non-Negotiable, and When It Can Be Light

The risk register earns its place on any engagement long enough or exposed enough to face risks the team cannot foresee in week one. In practice that is most engagements. The threshold is not project size; it is exposure.

The register is non-negotiable when the delivery date matters to a third party — a regulator, a customer launch commitment, a board reporting cycle — because the cost of an unsurfaced risk in those contexts is reputational, not just operational. It is non-negotiable on any engagement with third-party dependencies the team does not control, because dependency risk is the class most often dismissed in week one and most often materialised in the months after. It is non-negotiable on engagements with regulatory exposure, because the audit will ask for the register and "we didn't keep one" is a finding by itself.

You can move with a lighter register on small, time-boxed, single-team builds where the scope is narrow and the dependencies are minimal. A two-week internal tool with no external dependencies probably does not need a formal register. Even there, ten minutes spent listing what could go wrong is rarely wasted; it is the formal cadence that is optional.

The category that catches teams out is the project that started small and grew. A four-week prototype that became the basis for the production build does not get a retrofitted risk register, because no one drew a line where one was needed. By the time the project clearly needs one, the risks that should have been captured in week one have already started materialising.

What to Do Next

If you do not have a current risk register, convene the project team this week, list the risks honestly, score them, and assign owners. The first honest register is the one that matters; the next twelve weeks of cadence is what makes it pay back.

For teams thinking about how the register fits into a broader delivery practice, see our custom software delivery approach, which builds the register in from sprint one alongside the rest of the Right Delivery components.

Frequently Asked Questions