Most projects have a risk register. Most risk registers are created at project initiation, approved by the steering group, filed in the project folder, and never meaningfully used again. The risks that were identified were not the ones that ultimately affected the project, and the ones that did affect it were never in the register. This is not a coincidence. It is the result of building a risk register as a compliance artefact rather than as a living management tool.
A risk register that actually gets used is built differently from the start. It is maintained by the people closest to the risks, reviewed regularly in project meetings rather than filed between them, updated as the risk landscape changes, and connected to decisions being made about the project right now. This guide explains how to build one that works.
Key Takeaways
|
70% Of project failures are attributable to risks that were either not identified or not actively managed, according to PMI’s Pulse of the Profession research |
Risk ≠Issue A risk is something that might happen. An issue is something that has happened. Every project needs both a risk register and a separate issues log, managed differently |
Owner Every risk needs a named individual who is accountable for monitoring it and implementing the response. A risk without an owner is a risk that will not be managed |
Living A risk register that is not updated at least weekly on an active project is not a management tool. It is a historical document |
- A risk register is a structured record of the risks that have been identified for a project, including their likelihood, potential impact, owner, and planned response.
- The purpose of a risk register is to support decision-making, not to demonstrate compliance. Every entry should answer “what are we doing about this?” not merely “what could go wrong?”
- Risk identification is a team activity, not a solo desk exercise. The best risk registers are built through structured workshops that bring diverse perspectives to the risk landscape.
- Risk scoring (probability and impact) provides a basis for prioritising management effort. The top risks by score should receive the most active management attention and the most detailed response planning.
- The four standard risk response strategies (avoid, reduce, transfer, accept) each have specific applications. Choosing the right strategy for each risk is as important as identifying the risk in the first place.
Risk vs Issue: The Most Important Distinction
Before building a risk register, it is essential to be clear about what a risk is and what it is not. The most common confusion in project risk management is the conflation of risks and issues, which are managed differently and require different responses.
|
Risk: Something that might happen A risk is an uncertain event or condition that, if it occurs, would have a positive or negative effect on the project’s objectives. It has not happened yet. The management task is to reduce the probability or impact before it does. “A key supplier might experience a supply chain disruption during our peak build phase” is a risk. Managed in: Risk Register |
Issue: Something that has happened An issue is a current problem or constraint that requires immediate attention and decision. It is already affecting the project. The management task is to resolve it or find a workaround. “Our key supplier has just notified us of a three-week delivery delay” is an issue. When a risk event occurs, it transitions from the risk register to the issues log. Managed in: Issues Log |
Step 1: Risk Identification
A risk register is only as good as the risks it contains. The most significant failure mode in risk identification is not being systematic enough: relying on the project manager’s experience and intuition rather than drawing on the diverse perspectives of everyone involved in the project.
Five Risk Identification Techniques
| Technique | How It Works | Best For |
|---|---|---|
| Risk workshop | Structured group session with project team and stakeholders, using facilitated techniques to identify risks from multiple perspectives. Most effective risk identification technique for projects of significant size or complexity. | Any project where the risk landscape is complex or spans multiple disciplines |
| Assumption analysis | Systematically examine every assumption in the project plan. Each assumption that proves wrong is a risk. “We have assumed that the IT team can be available for three days of user acceptance testing in week eight” becomes a risk if that availability is not confirmed. | All projects; particularly useful for exposing plan-embedded assumptions that are treated as facts |
| Lessons learned review | Review the lessons learned from similar previous projects within the organisation or industry. Historical risk events are among the most reliable indicators of future risks in comparable projects. | Repeat project types; organisations with good historical project documentation |
| Risk checklist | A pre-defined list of risk categories and common risks for the project type, used as a prompt to ensure common risk categories are not overlooked. Categories typically include: technical, resource, schedule, commercial, regulatory, stakeholder, and environmental. | Quick identification on smaller projects; useful supplement to workshop-based identification on larger ones |
| Pre-mortem analysis | Ask the team: “Imagine the project has failed. It is six months from now and we are describing what went wrong. What happened?” This hypothetical framing surfaces risks that people are reluctant to name directly but will readily generate in this context. | Any project; particularly effective at surfacing risks that team members are aware of but reluctant to raise |
Step 2: Risk Assessment and Scoring
Once risks are identified, each is assessed on two dimensions: probability (how likely is this risk to occur?) and impact (if it does occur, how severely will it affect the project’s objectives?). The combination of probability and impact determines the risk’s priority for management attention.
The standard scoring approach uses a scale for each dimension (typically 1-5 or 1-3, with 3 or 5 representing the highest level) and calculates a risk score by multiplying the two. A risk with high probability and high impact scores highest and demands the most active management response.
| Low Impact (1) | Medium Impact (2) | High Impact (3) | Very High Impact (4) | Critical Impact (5) | |
|---|---|---|---|---|---|
| Almost Certain (5) | 5 | 10 | 15 | 20 | 25 |
| Likely (4) | 4 | 8 | 12 | 16 | 20 |
| Possible (3) | 3 | 6 | 9 | 12 | 15 |
| Unlikely (2) | 2 | 4 | 6 | 8 | 10 |
| Rare (1) | 1 | 2 | 3 | 4 | 5 |
🟢 Low (1-5) | 🟡 Medium (6-10) | 🟠High (11-15) | 🔴 Critical (16-25)
Step 3: The Risk Register Structure
A well-designed risk register contains the following fields for each risk. Resist the temptation to add more fields than are actively used: a register with twenty columns that are mostly empty is not a management tool.
| Field | Description | Example |
|---|---|---|
| Risk ID | Unique identifier for tracking and reference | R-017 |
| Date raised | When the risk was identified and entered into the register | 15 March 2026 |
| Risk description | A clear statement in the form: “The risk that [event] occurs, resulting in [consequence].” Should be specific enough to be actionable. | “The risk that the third-party data migration tool does not support our legacy data format, resulting in a four-week rework and delay to go-live.” |
| Category | Risk type: Technical / Resource / Schedule / Commercial / Regulatory / Stakeholder / External | Technical |
| Probability (P) | Likelihood score 1-5 | 3 (Possible) |
| Impact (I) | Consequence score 1-5 if the risk occurs | 4 (Very High) |
| Risk Score (P×I) | Priority rating; determines level of management response | 12 (High) |
| Risk Owner | Named individual accountable for monitoring this risk and implementing the response. Must be a person, not a team or role. | James Okafor (Technical Lead) |
| Response strategy | Avoid / Reduce / Transfer / Accept (see response strategies below) | Reduce |
| Response actions | Specific, dated actions being taken to implement the response strategy | “Conduct technical compatibility test with vendor by 30 March. If incompatible, evaluate alternative tool by 10 April.” |
| Residual score | Expected P×I score after the response actions are implemented. Confirms the response is proportionate to the risk level. | 6 (Medium) |
| Status / Last review | Current status: Active / Reduced / Closed / Occurred (became an issue). Date of last review. | Active / 22 March 2026 |
📋 Build complete project management capability including risk management
Alpha Learning Centre’s project management courses cover the full spectrum of project delivery skills, from risk identification and management to scheduling, stakeholder engagement, and governance frameworks. Browse the project management course catalogue.
The Four Risk Response Strategies
|
Avoid Eliminate the risk entirely by changing the project plan. If a particular technology platform creates significant technical risk, switching to a lower-risk alternative avoids the risk altogether. Best for: High-score risks where avoidance is practical |
Reduce (Mitigate) Take specific actions to reduce either the probability of the risk occurring or the severity of its impact if it does. The most commonly applicable strategy: early testing reduces technical risk; building schedule contingency reduces impact of delays. Best for: Most medium and high-score risks |
Transfer Shift the financial consequence of the risk to a third party: through insurance, fixed-price contracts with suppliers, or performance bonds. Transfer does not eliminate the risk; it reassigns who bears the cost if it occurs. Best for: Financial or commercial risks where insurance or contract protection is available |
Accept Acknowledge the risk and take no proactive action beyond monitoring. Appropriate for low-score risks where the cost of mitigation exceeds the expected value of the risk. Acceptance is a decision, not an omission; it should be actively confirmed, not defaulted into. Best for: Low-score risks; risks where all other responses are disproportionate |
Keeping the Register Alive: Review and Governance
The most technically excellent risk register becomes worthless if it is not maintained. Risk registers must be reviewed regularly, updated as the project progresses, and used as an active management tool rather than a filing exercise.
Best-practice risk review cadence for active projects: weekly status update by each risk owner (has anything changed? are response actions on track?); formal register review in each project team meeting; complete reassessment at each stage gate or key milestone (new stage, new risks); and escalation of any risk that moves to a Critical score (16+) to the project sponsor or steering group immediately.
The Association for Project Management (APM), the UK’s leading professional body for project management, publishes extensive guidance on risk management practice in its Body of Knowledge and in its dedicated risk management guide, available at apm.org.uk. The APM’s risk management guidance provides both the conceptual framework and practical tools that underpin the approach described in this article.
Conclusion: A Tool That Earns Its Place in Every Project Meeting
A risk register earns its place in every project meeting when it contains current, specific risks with named owners, active response plans, and scores that reflect recent assessment. When those conditions are met, the risk register stops being a document and becomes a conversation: a structured, evidence-based discussion about what the team is most worried about and what they are doing about it.
That conversation is the real value of risk management. The register is just the discipline that makes the conversation happen consistently.
Related reading: Risk management is most effective when it is embedded in a broader project governance culture. Our article on accountability exercises that actually work for leadership teams covers the behavioural disciplines that make risk ownership genuine rather than nominal.
🔧 Develop specialist project and construction management skills
The Construction Project Management Masterclass covers risk management, procurement, scheduling, and contract administration for professionals managing complex project delivery in construction and infrastructure environments.