Risk Register
Also known as: risk log, risk tracker, risk and issue register, project risk register
A risk register (also called a risk log) is a structured document used to identify, assess, track, and manage risks across a project, system, or organization.
Each entry records what the risk is, what might cause it, the likelihood of it occurring, the potential impact if it does, who owns it, what action has been taken to mitigate or accept it, and the current residual risk level. A risk register is a living document: it is reviewed regularly and updated as risks change, new risks emerge, and mitigation actions are completed.
Risk Register, explained at three levels
At home
A risk register is a list of things that could go wrong, organized so that the most serious risks get the most attention. Each entry says what might happen, how likely it is, how bad it would be, who is responsible for dealing with it, and what is being done about it. Project managers use them to track project risks; security teams use them for security risks; organizations use them for business risks. Reviewing the register regularly stops risks from falling through the cracks.
At work
A risk register gives your team a single place to track all identified risks so that nothing is forgotten and ownership is clear. It is the output of your risk assessment process and the input to your risk treatment decisions: whether to mitigate (reduce the risk), accept (live with it), transfer (insure or outsource), or avoid (stop the activity). The register should be reviewed at regular intervals (weekly for active projects, monthly or quarterly for operational programs) and updated whenever the risk environment changes.
At home
A risk register entry typically captures: a unique risk ID, a description of the risk event ('the payment system vendor goes out of business'), the risk category (operational, strategic, financial, security, etc.), the likelihood (probability of occurrence, often rated 1-5 or Low/Medium/High), the impact (consequences if it occurs, often rated 1-5), the risk score (likelihood x impact), the risk owner (person accountable for managing the risk), the treatment type (mitigate, accept, transfer, avoid), the actions taken or planned, the target date for actions, and the residual risk score after treatment.
At work
Risk registers in information security (required by ISO 27001) follow the same structure but are scoped to threats and vulnerabilities affecting information assets. Each risk identifies a specific asset (customer database), a specific threat (unauthorized access), a specific vulnerability (weak password policy), and the potential impact (data breach, regulatory fine, reputational damage). The risk is then treated with a specific Annex A control or combination of controls, the chosen controls are listed in the Statement of Applicability, and the residual risk is recorded in the register and approved by the risk owner.
At home
Risk registers in project management track risks that could affect project objectives: schedule, budget, quality, and scope. Project risk registers include a 'risk trigger' (the early warning sign that the risk is about to materialize) and a 'contingency plan' (what to do if the risk occurs despite mitigation). Project risks that materialize become issues and move to the issue log: the risk register and issue log are separate documents tracking future uncertainties and present problems respectively.
At work
From a practitioner standpoint, the most common risk register failure is treating it as a compliance artefact rather than a management tool: creating it for an audit, then filing it away. A valuable risk register is reviewed in risk committee meetings with senior leadership, updated when risks materialize or change, and linked to the organizational risk appetite. Heat maps (plotting risks by likelihood and impact) make the register accessible to non-technical stakeholders. Risk registers with 200+ entries are usually not reviewed meaningfully: effective registers focus on the top 15-20 risks that require active management attention.
Real-world examples
At home
Carlos was renovating his house and created a simple risk register in a spreadsheet. He listed risks like 'contractor goes over budget', 'materials delayed', and 'building permit refused', rated each by likelihood and impact, and noted what he would do if each one happened. When materials were delayed by two weeks, the entry already had a contingency plan: order from a local supplier at slightly higher cost.
At work
The project manager at Brightfield Bank maintained a risk register for a core banking system migration. At the weekly risk review meeting, the team updated the likelihood score for 'data migration validation fails' from Medium to High after a test migration showed a 3% error rate. The risk owner was tasked with commissioning an additional data quality audit before the next migration phase.
How it compares
| Feature | Risk Register | Issue Log |
|---|---|---|
| What it tracks | Potential future problems that may or may not occur | Problems that have already occurred and need resolution |
| Timing | Forward-looking and proactive | Reactive: present-tense problems |
| Status options | Open, monitored, accepted, mitigated, transferred, closed | Open, in progress, resolved, closed |
| Owner | Risk owner (accountable for monitoring and response) | Issue owner (accountable for resolution) |
| When created | Risk assessment during planning or ongoing review | As issues arise during execution or operations |
A risk register tracks what might go wrong; an issue log tracks what has gone wrong. A risk that materializes is typically closed in the risk register and opened as an issue in the issue log. Both are living documents reviewed regularly.
For analysts
The risk register is a core BA artefact in any project with significant uncertainty or compliance obligations. BAs contribute to it by identifying risks during requirements elicitation: stakeholders often know what might go wrong and articulate risks naturally in conversations about requirements. When facilitating risk workshops, use categories (technical, operational, regulatory, people, schedule, third-party) to prompt comprehensive identification. Useful practice: link each risk to the requirement or user story it affects, so that if the risk materializes the impact on scope is immediately clear. For ISO 27001 programs, the BA can map each identified risk to the relevant Annex A control being proposed to treat it.
History & origin
Formal risk registers emerged from project management and financial risk practices in the 1980s and 1990s. The UK government's PRINCE project management method (1989), relaunched as PRINCE2 in 1996, made a formal risk log a standard project artefact. ISO 31000 (Risk Management: Guidelines, first published 2009) standardized risk management principles internationally and implicitly required a mechanism like a risk register for tracking identified risks. ISO 27001 requires documented risk assessment results and a risk treatment plan as part of its Information Security Management System, which most organizations keep as a risk register. Today, risk registers are standard artefacts in project management, enterprise risk management, IT security, business continuity, and regulatory compliance.