What is a risk register?
A risk register — also called a risk log or risk list — is a tabular document in which all known risks of a project are systematically recorded, assessed, and tracked. It is the link between risk analysis and operational risk management.
The register answers four questions for each risk: What could happen? How likely and how severe is it? What do we do about it? And who is responsible?
Unlike a one-time analysis, the risk register is a living document. It is created in the planning phase and updated throughout the entire project lifecycle — through to project closure. New risks are added, existing ones change their assessment, resolved ones are closed. What is not in the register is quickly forgotten in day-to-day project work.
What is a risk register used for?
The risk register serves several functions at once:
Central repository. All identified risks are in one place — not scattered across emails, meeting minutes, or people’s heads. This prevents risks from getting lost when team members change or meeting outcomes are forgotten.
Prioritization. Not every risk deserves the same attention. The register orders risks by priority and directs limited resources toward the greatest threats.
Tracking. The status of every risk is visible at any time: open, in progress, closed. This makes progress in risk mitigation measurable and gives project management control over the risk situation.
Communication. The register forms the basis for status reports and decision documents for the steering committee. Stakeholders can see at a glance what risks exist and how they are being handled.
Learning foundation. At the end of the project, the register provides valuable data for lessons learned: Which risks materialized? Did the measures work? What was underestimated?
Risk register vs. risk matrix
Risk registers and risk matrices are often confused. Both are risk management tools, but they serve different purposes.
| Criterion | Risk Register | Risk Matrix |
|---|---|---|
| Format | Tabular, one row per risk | Visual grid (heat map) |
| Level of detail | High — description, measures, owners, status | Low — position in the grid shows priority |
| Purpose | Documentation and tracking | Visualization and prioritization |
| Updates | Ongoing throughout the project | With each re-assessment |
In practice, the two complement each other: the risk matrix provides the picture — showing at a glance where the greatest threats lie. The risk register provides the detail — what exactly is planned and who acts. The assessment in the register (probability × impact) determines the position in the matrix.
What belongs in a risk register?
The scope of a risk register depends on project size. A small project can make do with five columns; a complex undertaking needs more. The table below shows the most common columns:
| Column | Content |
|---|---|
| Risk ID | Unique identifier (e.g., R-001) — makes referencing in reports and meetings easier |
| Risk description | Concrete description: what could happen, and what would the consequences be? |
| Risk category | Classification by type — e.g., technical, organizational, financial, external, legal |
| Probability of occurrence | Qualitative (low / medium / high) or quantitative (as a percentage) |
| Impact | Extent of damage to cost, schedule, or quality — qualitative or quantitative |
| Risk score | Probability × impact — determines priority |
| Risk strategy | Avoid, reduce, transfer, or accept |
| Planned measures | Concrete countermeasures with a timeline |
| Owner | Person responsible for monitoring the risk and implementing measures |
| Status | Open, in progress, closed |
| Notes | Additional information, change history, references |
Not every project needs all columns. The key is: a lean register that is kept up to date beats a comprehensive one that ends up in a drawer. For more details on assessment methods and scale definitions, see our articles on risk analysis and risk assessment.
Creating a risk register — step by step
1. Identify risks
The first step is a systematic collection of all risks that could threaten the project. Proven methods:
- Team brainstorming — different roles see different threats
- Checklists from previous projects — lessons learned are one of the richest sources
- Stakeholder interviews — clients and specialist departments recognize risks the project team is unaware of
- Perspective shift — ask not “What is going well?” but “How could this project fail?”
Cover all risk categories: technical, organizational, economic, legal, and external risks. A detailed guide can be found in the article on identifying project risks.
2. Describe risks
Formulate each risk concretely and traceably. Vague entries such as “staffing problem” or “technology” are useless in day-to-day project work — no one can derive from them when the risk will occur or what needs to be done.
Use a cause-and-effect structure: “If [cause], then [impact].” Example: “If the external service provider does not deliver the interface documentation by week 20, the integration test will be delayed by at least two weeks.” This immediately makes clear to the risk owner what to watch for and what consequences are at stake.
3. Assess risks
Estimate two values for each risk — separately, to avoid mixing them up:
- Probability of occurrence: How likely is it that the risk materializes?
- Impact: How severe would the consequences be for cost, schedule, or quality?
The two values combine to produce the risk score (probability × impact). The higher the score, the more urgent the need for action. The assessed risks can then be entered into a risk matrix to visualize the prioritization.
Whether you assess qualitatively (scale 1–5) or quantitatively (percentages, euros, days) depends on project size and available data. What matters is that all stakeholders use the same scale. Detailed methods are described in our article on risk assessment.
4. Define measures and owners
Each prioritized risk needs a strategy and concrete measures. The four basic strategies:
- Avoid: Eliminate the root cause of the risk — e.g., by changing the project scope or the technology
- Reduce: Lower the probability of occurrence or the extent of damage — e.g., through testing, training, or buffers
- Transfer: Pass the risk on to a third party — e.g., through insurance or contractual arrangements
- Accept: Consciously carry the risk — e.g., because countermeasures would be disproportionately expensive
Assign an owner to each risk. Without a clear assignment, nothing happens — the risk is documented, but no one feels responsible. The owner monitors the risk, implements measures, and reports changes to project management.
5. Maintain and update the register
The risk register is not a document that is created once and then filed away. It is briefly reviewed in every status meeting or regular check-in:
- Add new risks
- Adjust assessments when conditions change
- Update the status of measures
- Close resolved risks
A fixed rhythm — every two weeks, for example — ensures the register stays current. Integrate the most important risks into the project status report so the steering committee is kept informed as well.
Practical example: risk register for an IT project
A mid-sized company is implementing a new CRM system. The project has a budget of 120,000 EUR and a timeline of six months. The project team identified four key risks in a workshop and documented them in the risk register:
| ID | Risk | P | I | Score | Strategy | Measure | Owner | Status |
|---|---|---|---|---|---|---|---|---|
| R-001 | Key developer leaves the project | Medium (3) | High (4) | 12 | Reduce | Knowledge transfer to a second person, pair programming in critical modules | Project management | Open |
| R-002 | Requirements changes by the specialist department after specification sign-off | High (4) | Medium (3) | 12 | Reduce | Establish a change request process, build buffers into the schedule | Product Owner | Open |
| R-003 | Interface to the legacy ERP system does not work as documented | Medium (3) | High (4) | 12 | Reduce | Interface prototype in Sprint 1, integration test in Sprint 2 | Tech Lead | In Progress |
| R-004 | Delivery delay by external service provider for data migration | Low (2) | Medium (3) | 6 | Transfer | Agree on contractual penalties, identify alternative providers | Procurement | Open |
Assessment on a 5×5 scale: 1 = Very low, 2 = Low, 3 = Medium, 4 = High, 5 = Very high
Result: Three risks with a score of 12 require active measures. R-003 was addressed first because the interface lies on the critical path — failure here would jeopardize the entire project plan. Measures were defined for R-001 and R-002 to be implemented in parallel with ongoing development. R-004 is being monitored and managed through contractual protection.
A more detailed example with seven risks and a full risk matrix can be found in our article Risk Management Example.
Tips for an effective risk register
-
Keep it simple. Only as many columns as your project actually needs. A lean register that is maintained beats a comprehensive one that nobody opens.
-
Assign responsibility clearly. Every risk needs exactly one responsible person. If no one is in charge, nothing happens — and the risk only surfaces once it has become a problem.
-
Be specific. “Technical risk” is not an entry. “Interface X delivers corrupted data under load” is. The cause-and-effect structure forces precision.
-
Review regularly. Make the risk register a standing agenda item — at least every two weeks. An outdated register is worse than none, because it creates a false sense of security.
-
Close risks too. A register that only grows loses clarity. When a risk is no longer relevant or a measure has worked, close it. This sends the team a signal: we have the situation under control.
-
Software instead of spreadsheets. With more than ten risks or distributed teams, Excel reaches its limits. Project management software with integrated risk management offers filtering, notifications, versioning, and linking with tasks.
Tools for the risk register
For small projects, a spreadsheet — Excel or Google Sheets — with a clean template is sufficient. The columns correspond to the fields described above, with one row per risk.
Beyond a certain level of complexity, project management software pays off. The advantages over a static table: real-time status, automatic notifications on changes, linking risks with work packages and tasks, role-based access, and dashboards for an overview. This turns a list into an active process — and no risk falls through the cracks.
Frequently asked questions
What is a risk register?
A risk register is a tabular document in which all identified project risks are systematically recorded — with a description, assessment (probability of occurrence and impact), planned measures, responsibilities, and status. It is the central tool of operational risk management in project management.
What is the difference between a risk register and a risk matrix?
The risk register is a detailed table containing all information about each risk: description, assessment, measures, owners, and status. The risk matrix is a visual representation that maps risks onto a color-coded grid based on probability of occurrence and impact. Both tools complement each other — the matrix prioritizes, the register documents.
Who creates the risk register?
Usually the project manager. In large or complex projects, a risk manager may take on this task. Responsibility for creation lies with one person — but the identification and assessment of risks should involve the entire project team, including subject-matter experts and stakeholders.
When should a risk register be created?
As early as possible — ideally in the planning phase, once the project goals and scope have been defined. The register is then updated continuously throughout the project and reviewed at every milestone and in every status meeting.
Which columns must a risk register contain?
At a minimum: risk ID, description, probability of occurrence, impact, risk score, measures, and owner. Additional useful columns are risk category, risk strategy, status, and notes. Adjust the scope to your project size — a lean register that is maintained is more valuable than a comprehensive one that becomes outdated.
CEO Alltena GmbH
Christoph Friedrich is a computer scientist and certified Project Management Professional. He has extensive experience in the introduction and integration of project management tools as well as the analysis and definition of processes in project and service management.
