A Risk Breakdown Structure (RBS) organizes risks according to their main sources and provides a clear view of the different levels of risk. It offers a hierarchical view of risk and helps project teams identify, analyse and monitor risks more effectively.
How do you build an effective RBS? How is it different from a risk register or a Work Breakdown Structure (WBS)? And how can it be used in practice on an industrial project?
In this article, we explain the principles of the RBS, how to build one, and how to use it to structure project risk identification and analysis.
What is a Risk Breakdown Structure (RBS) in project management?
A Risk Breakdown Structure (RBS) is a hierarchical structure used to classify project risks according to their source or origin. It organizes risks into several levels, from broad risk categories down to more specific sources of risk.
An RBS helps project teams check that no major risk category has been overlooked during the risk identification process.
For example, for a plant construction project, an RBS could start with four main categories, which can then be broken down into more specific risk sources:
- Technical risks: design, equipment, technical interfaces.
- Project-related risks: schedule, resources, costs, coordination.
- External risks: regulations, suppliers, economic environment.
- Execution risks: construction work, safety, commissioning.
An RBS is therefore not a risk register in itself. Its purpose is to structure and organize risk sources. The risk register comes afterwards and provides details on the individual risks identified, including their probability, impact, owner and planned response actions.
What is the difference between an RBS, a risk register and a WBS?
The RBS is often confused with other project management tools. However, the RBS, risk register and WBS serve different purposes.
The RBS organizes risks according to their sources. It answers the question: Where could risks come from?
The WBS (Work Breakdown Structure) breaks the project down into its work components. It answers a different question: What needs to be delivered?
The risk register records the individual risks identified and provides a means of monitoring them throughout the project. It typically includes their probability, impact, owner and planned response actions.
Going back to our plant construction project, the WBS may include a work package called “Equipment Installation.” The RBS may identify a “Supplier Risks” category, with “Delivery Delays” as a subcategory. The risk register can then contain the specific risk “Delay in delivery of the main compressor,” together with its potential impact on the schedule and the planned mitigation actions.
These three elements are therefore complementary:
- WBS → Break down the work
- RBS → Structure the sources of risk
- Risk register → Identify and monitor individual risks
How do you structure a project RBS?
An RBS is built progressively, starting with broad sources of risk and moving towards more specific categories.
Define the main risk categories (Level 1)
Level 1 provides the overall structure of the RBS. It should cover the main sources of risk relevant to the project without attempting to define every detail at this stage.
Categories should be defined according to the project context, industry, organization and specific constraints. An RBS designed for an industrial project will therefore not necessarily be the same as one used for an IT or real estate project.
The objective is to create a structure broad enough to avoid overlooking a major source of risk, while keeping it simple enough to remain practical and usable.
Break down each category into subcategories (Levels 2 and 3)
Once the main categories have been defined, they can be broken down into more specific subcategories. The structure can be developed to a level of detail that allows individual risks to be clearly identified and named.
A third level can be added when it provides useful information. For example, “Delivery Delays” could be broken down into manufacturing delays, transportation delays or customs issues.
However, unnecessary levels of detail should be avoided. The structure should be detailed enough to guide risk identification while remaining simple enough for project teams to use effectively.
Validate the structure with all stakeholders
An RBS should not be developed solely from the perspective of the risk manager or project manager. The teams involved in the project may identify different sources of risk depending on their area of expertise.
A review with the main stakeholders therefore helps test the structure before it is used. The objective is to ensure that the categories are clear, relevant to the project and that no significant source of risk has been overlooked.
Validation also helps identify duplicate categories and categories that are either too broad or too specific. The same source of risk should not appear in several parts of the RBS without a clear reason. Conversely, a category that is too broad may make risk identification more difficult.
Once validated, the RBS can provide a common reference framework for risk workshops, the risk register and risk analyses throughout the project. It can also be adjusted when the project scope, organization or context changes.
How can you identify project risks using an RBS?
Rather than starting with a predefined list of known risks, the project team can work through each branch of the RBS and ask what could prevent the project from achieving its objectives.
This approach helps structure discussions during risk workshops and can bring to light risks that might otherwise be overlooked.
Organize risk identification workshops
Risk identification workshops can bring together all stakeholders with knowledge of the different stages of the project. The RBS provides a framework for the workshop.
The teams work through each branch and identify events that could affect the project objectives. Discussions can draw on lessons learned, similar projects and project-specific constraints. The objective is to identify risks precisely enough for them to be analysed and monitored afterwards.
Identify risks from each category
Each RBS category helps guide the questions asked during the identification process. Teams review one branch at a time and consider the events that could occur within that area.
For example, under “Supplier Risks,” a stakeholder may identify a manufacturing delay, a non-conformity or a subcontractor failure.
Under “Technical Risks,” the analysis may identify a design error, incompatibility between two pieces of equipment or a late technical change.
This approach gradually moves from the source of risk to a specific risk event. It also prevents the analysis from being limited to risks that the team already knows.
Link the RBS to the risk register
The risks identified are then recorded in the risk register. The RBS maintains their classification and shows the source to which each risk is linked.
- RBS: Supplier Risks → Procurement
- Risk: Delay in delivery of critical equipment
- Risk register: Probability, impact, owner, risk response and action due date.
The risk register therefore contains the information required to monitor each individual risk, while the RBS provides a structured view of their sources.
Combining the two also makes it possible to analyse the concentration of risks. If a large number of risks are associated with the same branch, that area may require particular attention during project management.
Limitations of the RBS
An RBS provides a framework for structuring risk identification, but it does not by itself guarantee the quality of the risk analysis. Certain practices can make the structure difficult to use or reduce its value as the project progresses.
Confusing risk categories with individual risks
An RBS describes sources of risk. It should not become a list of individual risks.
For example, “Supplier Risks” can be an RBS category. In contrast, “Delay in delivery of the main transformer” is a specific risk that should be recorded in the risk register.
This distinction is important. If every identified risk becomes a new branch of the RBS, the structure quickly becomes difficult to understand and maintain.
Creating an overly complex structure
An RBS that is too detailed can become difficult to understand and maintain. Adding more levels and subcategories does not necessarily improve risk analysis.
On an industrial project, a branch such as “Technical Risks → Equipment → Electrical Equipment → High Voltage → Transformer → Supplier X” may go too far if this level of detail does not provide any additional value for risk identification or monitoring.
The structure must remain clear and usable for the teams working with it. The appropriate level of detail depends on the project, its size and the level of analysis required.
Failing to update the RBS
The RBS is usually established at the beginning of the project, but the project context can change. New interfaces may emerge, work packages may be modified or new suppliers may become involved.
A category that was initially absent from the RBS may then become relevant to subsequent risk analyses. Supply chain risks, for example, may become significant enough to require a new subcategory.
The RBS should therefore be reviewed whenever the project scope, organization or conditions change. It should not be treated as a fixed structure once the first risk workshop has been completed.
A Risk Breakdown Structure (RBS) provides a structured way to organize sources of risk and establish a common framework for project risk identification and analysis. When properly designed, it facilitates discussions between stakeholders and complements the risk register.
Its effectiveness largely depends on keeping the structure simple and adapting it to the project. The RBS must remain practical, evolve with the project context and integrate with the tools used to manage risks, schedules and costs.
