Risk Breakdown Structure (RBS): Definition, Examples and How to Create One

A Risk Breakdown Structure, usually shortened to RBS, is a hierarchical framework that organises potential sources of project risk into categories and subcategories.

A project risk register can quickly become a long, undifferentiated list of technical problems, supplier failures, resource shortages, contractual disputes and external events. A Risk Breakdown Structure brings order to that list by showing where risks come from and how they relate to one another.

Used properly, an RBS helps a project team identify overlooked risks, spot concentrations of exposure, investigate common causes and plan coordinated responses.

What is a Risk Breakdown Structure?

A Risk Breakdown Structure is a hierarchical classification of project risk sources, categories and causes.

It normally begins with a broad heading such as Project Risk. That heading is divided into major categories such as:

• technical;
• commercial;
• project management;
• organisational; and
• external.

Each major category is then divided into more specific subcategories. Technical risk, for example, might be broken down into requirements, design, integration, testing, security and performance.

The result resembles a family tree for uncertainty. It starts broadly and becomes more specific at each level.

What does an RBS organise?

An RBS can organise risks by source, cause, area of uncertainty or another classification useful to the project.

For example, a risk register might contain these individual risks:

• The supplier may deliver the equipment late.
• The selected software may not integrate with the existing system.
• Users may reject the new business process.
• A change in regulation may require additional development.

The RBS would place those risks into categories such as:

• Commercial > Supplier performance
• Technical > Integration
• Organisational > Change adoption
• External > Regulation

This classification makes it possible to analyse the risk register as a collection rather than treating every risk as an isolated line in a spreadsheet.

Why use a Risk Breakdown Structure?

Risk identification workshops have a predictable weakness: people tend to identify risks in the areas they understand best.

Technical specialists find technical risks. Procurement specialists find supplier risks. Finance finds budget risks. Everyone congratulates themselves, and the risks sitting between departments remain untouched.

An RBS provides a structured prompt that forces the team to examine the project from several perspectives.

Benefits of an RBS

• Encourages more comprehensive risk identification.
• Reduces the chance of overlooking an entire source of risk.
• Creates a common language for classifying risks.
• Reveals concentrations of high-priority risks.
• Helps identify common causes and connected risks.
• Supports analysis across projects and programmes.
• Makes risk reporting clearer.
• Helps target management attention and resources.
• Supports coordinated risk responses.

It can also improve consistency. If every project uses broadly compatible risk categories, an organisation can compare risk patterns across its portfolio.

How an RBS is used during project risk management

An RBS is not merely a diagram produced during a workshop and then abandoned in a shared drive. It can support several parts of the risk management process.

1. Planning how risk will be managed

The RBS may be included in the project risk management plan.

The risk management plan sets out how risk-related activities will be performed, including:

• the risk management methodology;
• roles, responsibilities and authority;
• risk categories;
• definitions and thresholds;
• tools and templates;
• reporting and communication arrangements; and
• the timing of risk activities.

Including an RBS gives the project team an agreed classification system from the outset.

2. Identifying risks

During risk identification, the RBS acts as a prompt list. Participants review each branch and ask what uncertainty could arise from that area.

A useful risk identification exercise combines several approaches:

• Historical review: what happened on this project or comparable projects?
• Current assessment: what uncertainties arise from the characteristics of this project?
• Creative techniques: what unusual or emerging risks might not appear in previous records?

The RBS supports all three, but it cannot replace judgement, imagination or informed discussion.

3. Categorising and analysing risks

Once risks have been identified, the RBS can be used to group them according to their source or cause.

This can reveal:

• clusters of high-priority risks;
• categories producing repeated problems;
• several risks sharing one root cause;
• cause-and-effect chains between risks;
• risks likely to occur at the same time; and
• risks that would compete for the same recovery resources.

4. Planning risk responses

Categorisation can also improve response planning.

If several risks arise from one common cause, the project may be able to address them through one coordinated response rather than a jumble of unrelated actions.

For example, several supplier risks might be reduced through:

• stronger supplier assurance;
• additional contract controls;
• earlier technical reviews;
• alternative sourcing arrangements; or
• contingency stock.

Example Risk Breakdown Structure

The following example shows a generic project RBS.

This is only a starting point. A generic RBS copied blindly from another project can create the comforting illusion of control while missing the risks that matter.

Risk Breakdown Structure vs risk register

The RBS and risk register are related, but they perform different jobs.

Risks identified using the RBS should be entered in the risk register and assigned the relevant RBS category.

A useful risk register might therefore include an additional field called:

• Risk category;
• RBS category;
• Risk source; or
• RBS code.

Risk Breakdown Structure vs Work Breakdown Structure

An RBS is often compared with a Work Breakdown Structure because both use a hierarchy.

Their purposes are different:

Put bluntly: the WBS organises the work; the RBS organises what might derail it.

Using an RBS with a Work Breakdown Structure

The two structures become more useful when used together.

The RBS can show where risks originate, while the WBS can show which part of the project may be affected.

For example:

• The RBS may show that several high-priority risks arise from supplier performance.
• The WBS may show that those risks mainly affect equipment installation and system testing.
• The combined analysis may reveal that one part of the project carries a disproportionate share of the exposure.

This is more informative than merely announcing that the project has 37 risks, as though the number itself explains anything.

How to create a Risk Breakdown Structure

Step 1: Understand the project

Review the project objectives, scope, deliverables, assumptions, dependencies, constraints and delivery approach.

The structure should reflect the project that actually exists, not the project described in last year’s template.

Step 2: Review organisational risk categories

Check whether your organisation already has:

• a standard RBS;
• enterprise risk categories;
• lessons learned from previous projects;
• industry risk checklists;
• audit findings; or
• historical risk registers.

Existing categories provide a useful starting point and support comparison between projects.

Step 3: Select the top-level categories

Choose a manageable set of broad categories. Five to eight top-level categories will usually be easier to use than a sprawling taxonomy designed to classify every misfortune known to humanity.

Possible top-level categories include:

• technical;
• delivery;
• commercial;
• financial;
• people and organisation;
• stakeholders;
• governance; and
• external.

Step 4: Break categories into subcategories

Add detail only where it will help identification or analysis.

For example:

• Technical > Requirements
• Technical > Integration
• Commercial > Supplier performance
• Commercial > Contract terms
• Organisational > Skills
• Organisational > User adoption

Step 5: Test the structure against known risks

Take several risks from the project or a comparable project and try to classify them.

Ask:

• Can each risk be placed somewhere sensible?
• Are important categories missing?
• Are two categories saying the same thing?
• Are participants likely to interpret the categories consistently?

Step 6: Use the RBS to identify risks

Work through the structure with the project team and relevant stakeholders.

For each category, ask:

• What could happen?
• Why might it happen?
• What assumptions could prove false?
• What dependencies could fail?
• What happened on similar projects?
• What unusual event has not yet been considered?

Step 7: Link the RBS to the risk register

Assign each identified risk an RBS category or code.

This allows the team to filter, summarise and report risks by category.

Step 8: Review and update it

The RBS should be reviewed when:

• the project scope changes;
• a major supplier is appointed;
• the delivery method changes;
• new regulations appear;
• the project moves into a new phase;
• significant risks materialise; or
• lessons emerge from incidents and issues.

Tailoring an RBS to different project types

One of the defining features of an RBS is that it can be tailored.

Construction project RBS

• Site and ground conditions
• Design and engineering
• Planning and permissions
• Health and safety
• Contractors and subcontractors
• Materials and logistics
• Weather
• Community and environmental impacts

Software project RBS

• Requirements
• Architecture
• Interfaces and integration
• Data migration
• Cybersecurity
• Testing and quality
• Infrastructure
• Deployment and support

Business change project RBS

• Leadership and sponsorship
• Stakeholder support
• Communications
• Training
• Process design
• User adoption
• Operational readiness
• Benefits realisation

Procurement project RBS

• Requirements and specification
• Market capacity
• Supplier selection
• Commercial terms
• Contract management
• Supplier financial stability
• Supply chain dependency
• Transition and mobilisation

Tailoring does not mean reinventing the structure for every meeting. Begin with a reusable organisational framework, then modify it where the project demands.

Using an RBS to analyse risks

Once risks have been categorised, the project team can look for patterns that would remain hidden in a flat risk register.

Count risks by category

Counting risks is crude, but it can show where uncertainty is concentrated.

Ten low-priority technical risks may not matter as much as two catastrophic regulatory risks, so counts should never be considered in isolation.

Summarise exposure by category

Risk scores or quantitative exposure can be aggregated by RBS category to show which sources contribute most to overall project risk.

Identify common root causes

Several apparently separate risks may arise from one underlying cause.

For example, weak requirements management might lead to:

• design rework;
• supplier disputes;
• testing failures;
• schedule delay; and
• cost growth.

Treating each symptom independently would miss the obvious opportunity to address the requirements process.

Identify connected risks

One risk can change the probability or impact of another.

A supplier delay might compress the testing period. Reduced testing might increase the chance of quality failure. Quality failure might then delay operational approval.

The RBS can help reveal these relationships, although more detailed cause-and-effect analysis may still be needed.

Using an RBS for risk response planning

Risk responses are often planned one line at a time. That is necessary, but it can produce duplicated actions and conflicting decisions.

Reviewing risks by RBS category can identify opportunities for:

• one response addressing several related risks;
• shared contingency arrangements;
• category-level ownership;
• common monitoring indicators;
• coordinated use of contingency reserves; and
• senior management intervention in systemic risk areas.

The team should also consider interactions between responses.

Mitigating schedule risk by adding resources may increase cost risk. Reducing supplier dependency through dual sourcing may create integration and quality risks. Risk responses do not exist in splendid isolation.

Limitations of a Risk Breakdown Structure

An RBS is useful, but it does not guarantee that every risk will be identified.

• Generic categories may not reflect the specific project.
• A risk may fit into more than one category.
• Different participants may classify the same risk differently.
• The structure can become excessively detailed.
• Categories may overlap.
• Teams may focus on completing the structure instead of thinking creatively.
• New or unusual risks may sit outside the existing categories.
• A polished diagram can create false confidence that risk identification is complete.

An RBS should therefore be combined with other techniques such as:

• historical review;
• lessons learned;
• assumptions analysis;
• interviews;
• workshops;
• checklists;
• brainstorming;
• scenario analysis; and
• root cause analysis.

Risk Breakdown Structure best practice

• Keep the top level simple and memorable.
• Tailor the structure to the project and industry.
• Use organisational categories where they add consistency.
• Define categories clearly to reduce overlap.
• Record an RBS category against every risk in the risk register.
• Analyse both the number and significance of risks in each category.
• Look for common causes rather than treating every risk separately.
• Review the structure at major project stages.
• Use it as a prompt, not as a substitute for thought.

Risk Breakdown Structure FAQs

What does RBS stand for?

RBS stands for Risk Breakdown Structure.

What is the purpose of a Risk Breakdown Structure?

Its purpose is to organise potential sources of project risk into a logical hierarchy. This supports risk identification, analysis, reporting and response planning.

Does an RBS contain individual risks?

It can sometimes display risks at its lowest level, but its primary role is to classify risk sources, categories and causes. Individual risks are normally documented in the risk register.

Is an RBS the same as a risk register?

No. The RBS provides the classification structure. The risk register records and manages individual risks.

Is an RBS the same as a WBS?

No. A Work Breakdown Structure organises project scope and work. A Risk Breakdown Structure organises sources and categories of uncertainty.

When should an RBS be created?

It is normally established during risk management planning and used during risk identification. It should be reviewed when the project changes or enters a new phase.

Can an RBS be used on Agile projects?

Yes. An Agile project might use categories such as product, technology, delivery, people, dependencies, stakeholders and operations. The structure can be reviewed during release planning, retrospectives or risk workshops.

Should every project use the same RBS?

A common organisational framework helps comparison, but it should be tailored where the project has distinctive risks.

How many levels should an RBS have?

There is no compulsory number. Use enough detail to support identification and analysis without creating a classification system so complicated that nobody uses it.

Summary

A Risk Breakdown Structure is a hierarchical classification of project risk sources, categories and causes.

It can form part of the risk management plan, provide prompts during risk identification, reveal clusters and common causes during analysis, improve reporting and support coordinated risk responses.

The RBS does not replace the risk register. The RBS organises risk categories; the risk register records and manages the individual risks.

Nor is it an exhaustive checklist. Its categories should be combined with historical evidence, current project assessment and creative risk identification.

A good RBS gives a project team a structured way to search for uncertainty. A bad one merely arranges the risks it already knows about into attractive boxes.

Sources and further reading

This article draws on the following sources:

1. Project Management Institute, Practice Standard for Project Risk Management. Sections covering the risk management plan, historical review, current assessment, creativity techniques, categorisation of risk causes, qualitative risk analysis and interactions between risks and responses.
2. Stakeholdermap.com, Project Management Dictionary. Definition of Risk Breakdown Structure. Read the dictionary definition .

The Risk Breakdown Structure is a supporting framework rather than a complete method of risk identification. Categories, prompt lists and checklists should be supplemented by project-specific analysis and original thinking.