Where project risk ends and enterprise risk begins, how to connect the two, and what UK organisations should look for in project risk management software that does it.
In UK organisations, the search for project risk management software usually starts after something has already gone wrong. A key supplier fails. Three projects slip in the same quarter. And the board asks, quite reasonably, why the enterprise risk register said amber the whole time.
The answer is almost always the same. The risk was there. Each of the three project risk registers held it, rated red, with an owner and a mitigation plan. What nobody had was a view across them. The project managers did their job, the risk team did theirs, and the risk fell into the space between the two.
That space is what this guide is about: where project risk ends and enterprise risk begins, how to connect the two, and what UK organisations should look for in project risk management software that does it. It is written for risk leaders in construction, government, healthcare, infrastructure, mining and transport, where a project going wrong is rarely only a project problem.
What UK buyers should check first
Check for one risk language across every register, risks linked rather than copied between project and enterprise level, and the same risk visible across every live project. Check what happens to open risks at project close. Then check UK hosting, Cyber Essentials and G-Cloud availability. The full checklist, with the question to ask each vendor, closes this guide.
What is project risk management software?
Use the table to narrow the field. Then read the detail on the platforms that match your starting point.
Project risk management software is a system for identifying, assessing, treating and reporting the risks to a project’s scope, cost, schedule and quality in one place. The best tools also connect those risks to the enterprise risk register, so the ones that matter beyond the project reach the people who need to act on them.
It sits between two familiar categories. Project management tools track tasks and timelines, with a risk field at best. Enterprise risk platforms cover the whole organisation but rarely see inside individual projects. A dedicated tool has to do both jobs: run each project register properly, and keep it connected to the enterprise view.
What is project risk management?
Project risk management is the process of identifying, assessing, treating and monitoring the risks that could stop a project delivering its scope on time, on budget and to the required quality. It is led by the project manager, recorded in a project risk register, and ends when the project closes.
Enterprise risk management works at a different altitude. It covers the risks to the organisation’s strategic objectives, across every function and every project, over a horizon measured in years. It is led by named executive risk owners, overseen by the board, and recorded in the enterprise risk register.
The two share a process: identify, assess, treat, monitor. What differs is the question each one answers, and that difference is where the trouble starts. A project risk register is not a smaller enterprise register. It is a different instrument pointed at a different target. For the mechanics of the documents themselves, our guide to the difference between a risk management plan and a risk register explains how the governing document and the live record fit together.
Project risk vs enterprise risk: the key differences
The clearest way to see the difference is side by side.
| Project risk | Enterprise risk | |
|---|---|---|
| What it protects | The project's scope, cost, schedule and quality. | The organisation's strategic objectives. |
| Time horizon | The life of the project, often months. | The strategic planning horizon, often years. |
| Typical owner | The project manager, accountable to a sponsor. | A named executive, overseen by the board. |
| Appetite and tolerance | Set by the project's contingency and delegated authority. | Set by the board's risk appetite. |
| Review cadence | Weekly or fortnightly, alongside project controls. | Monthly or quarterly, alongside governance cycles. |
| Typical risks | Design change, ground conditions, subcontractor performance and approvals. | Safety, regulatory standing, reputation, workforce, supply chain and strategy delivery. |
| When the work ends | The register closes with the project. | The register persists and evolves. |
Key distinction
Project risk asks whether this project will deliver what it promised. Enterprise risk asks whether the organisation will achieve what it set out to. The risks that answer both questions are the ones most likely to fall between the registers.
Why project and enterprise risk registers drift apart
Nobody designs the gap. It accumulates, for four reasons.
The first is tooling. Project risk lives wherever the project lives: a spreadsheet, a project management tool, a tab in the project controls workbook. Enterprise risk lives somewhere else entirely. Nothing connects the two except a person with time to re-key the data, and that person rarely exists.
The second is language. A project measures consequence in days of delay and cost against its own budget. The enterprise measures it against strategic objectives, safety, reputation and regulatory standing. A project red and an enterprise red are not the same thing. Without a translation between them, the scores cannot be compared, let alone added up.
The third is cadence. Projects review risk weekly because they have to. The enterprise register may be reviewed quarterly. By the time a project risk reaches the enterprise view, it has often already happened.
The fourth is behaviour, and it is the one nobody writes down. Project managers are measured on delivery, and escalating a risk can feel like admitting the project is in trouble. So risks get managed quietly at project level until they cannot be. Meanwhile the enterprise register treats the whole programme as a single line, usually called something like major project delivery, and never sees inside it.
"An enterprise risk register that cannot see into its projects is not a summary of risk. It is an educated guess."
This is why so much board reporting on projects stays reassuring right up until it isn’t. Directors rarely need more project detail. They need the few project risks that genuinely change the enterprise picture, which is exactly what directors actually need to see in a risk report.
Where project risk ends and enterprise risk begins
Here is where the line sits. A project risk stays on the project register when it can be understood, owned and resolved inside the project. It belongs on the enterprise risk register as well when it passes any one of three tests.
1. The objective test
Does the risk threaten an enterprise objective, not just a project objective? A two-week delay to a fit-out is a project risk. A two-week delay that breaches a regulatory commitment, pushes a new hospital ward past winter demand, or puts a mine’s approval conditions in doubt is an enterprise risk that happens to start in a project. Ask what the consequence means for the organisation, not only for the schedule.
2. The capacity test
Is the risk bigger than the project can absorb? Every project has limits: its contingency, its sponsor’s delegated authority, and the tolerance the organisation has set for it. When a risk’s credible consequence would exceed any of those, the decision about it is no longer the project’s to make alone. This is where the distinction between risk appetite and risk tolerance earns its keep: tolerance gives the project a threshold rather than a feeling.
3. The pattern test
Does the same risk appear in more than one project? This is the easiest test to miss, and it is the one from the opening example. One project relying on a fragile supplier is a project risk. Three projects relying on the same fragile supplier is a concentration risk, and only the enterprise can see it. The same applies to a shared pool of specialist labour, a common contractor, a single approvals body or the same untried technology. Moderate risks that repeat across projects can add up to a major one.
The rule of thumb
If a risk passes none of the three tests, leave it with the project. If it passes one, it belongs on the enterprise register too. If it passes all three, it should already be on the board's agenda.
How to escalate project risks to the enterprise risk register
Knowing where the line sits is half the job. The other half is a route across it that works every time, not only when someone remembers.
Agree one risk language
Use one risk taxonomy and one set of consequence definitions across every register, with a clear translation from project terms to enterprise terms. A project can still measure delay in days, but the scale should say what thirty days means for the organisation. Without that, escalation becomes an argument about scoring rather than a decision about risk.
Write the escalation criteria into the plan
Put the three tests, and the thresholds behind them, into every project risk management plan before work starts. Escalation then becomes a rule the project follows, not a judgement call a project manager has to defend. Our guide to writing a risk management plan step by step covers where criteria like these belong.
Link the risk, don’t copy it
When a project risk is escalated, the enterprise register should reference it, not duplicate it. Copy a risk and you have two risks, drifting apart from the moment they are created. Link it and you have one risk seen from two altitudes, with the project’s latest rating and actions visible to the enterprise owner.
Name two owners
Escalation does not move the risk. The project owner stays responsible for the response inside the project. A named enterprise owner takes responsibility for what the risk means across the organisation, including any decision beyond the project’s authority. Both names belong on the record. A risk escalated to “the executive” has been escalated to nobody.
Plan for the end of the project
Decide in advance what happens to open risks when the project closes. Some close with it. Others transfer to the team that inherits the asset, the facility or the service. A latent defect, a warranty exposure or a commitment made to a community during construction does not disappear at practical completion. It changes owner, and the handover should say who.
"The project risk register closes with the project. Some of its risks do not."
Key distinction
Escalating a project risk does not hand it over. The project still manages its part. The enterprise register adds the view the project cannot have from the inside.
Project risk management in the UK: the frameworks that shape it
UK organisations do not design their approach to project risk in a vacuum. Several frameworks set the expectations, and the three tests above line up with them closely.
Central government. The Government Functional Standard for Project Delivery, GovS 002, is mandatory for central government. Its principles expect delivery objectives to align with organisational objectives, risks to be managed within the organisation’s risk appetite, accountabilities to be traceable across every level of management, and the transition to operations to be planned with ongoing responsibilities agreed. That is the objective test, the capacity test, the two named owners and the handover step, written as policy. The Teal Book, government’s definitive guide to project delivery, explains how to meet the standard in practice.
Risk across the public sector. HM Treasury’s Orange Book sets the principles for risk management in government. It is written for central government, but its principles apply just as well across the wider UK public sector.
Major projects and infrastructure. Since April 2025, the National Infrastructure and Service Transformation Authority (NISTA) has brought the Infrastructure and Projects Authority and the National Infrastructure Commission together as a joint unit of HM Treasury and the Cabinet Office. It leads on the government’s largest projects, including the assurance reviews behind them.
Listed companies. For companies applying the UK Corporate Governance Code, Provision 29 asks boards to declare the effectiveness of their material controls, including operational and compliance controls, for accounting periods beginning on or after 1 January 2026. Where a major project carries material exposure, the controls around it can fall within that declaration. Our white paper on Provision 29 sets out what boards need.
The profession. The Association for Project Management (APM), the chartered body for the project profession in the UK, treats risk management as a core part of project practice in its Body of Knowledge.
What this means for software
None of these frameworks prescribes a tool. All of them assume you can show, on demand, how a project risk connects to the objectives it threatens and who owns it. That is a data problem before it is a reporting one.
How project and enterprise risk meet in your sector
The three tests hold everywhere. What changes is where the line tends to fall.
In construction, the pattern test does the heavy lifting. Subcontractor capacity, materials and skilled labour are shared across a pipeline of jobs, so a constraint on one project is often a constraint on several. That shared exposure sits at the centre of risk management for construction organisations.
In mining and resources, the objective test dominates. Project risks that touch environmental approvals, heritage or community consent can become risks to the licence to operate faster than any cost overrun. In mining and resources risk management, approvals risk usually belongs on the enterprise register from the outset.
In infrastructure and transport, long asset lives make the handover question critical. Risks created during delivery can sit inside an asset for decades, so the transfer from project to operations deserves as much care as the escalation route. It is a recurring theme in risk management for infrastructure and utilities.
In healthcare, NHS capital works interact with clinical services. A delay to a new facility is a service capacity risk as much as a construction one, so the objective test usually applies early.
In government, public accountability and statutory commitments mean project risks with reputational or ministerial consequence cross the line early, often well before they reach any cost threshold. GovS 002 builds the objective test in, by expecting every delivery objective to trace back to organisational and policy objectives. That traceability sits at the heart of risk management for government organisations.
Common mistakes when managing project and enterprise risk
These show up wherever organisations run significant projects. Each one feels sensible at the time.
Copying risks between registers. Duplicated risks drift. Within a month the project version and the enterprise version disagree, and nobody can say which is current.
Escalating everything red, or nothing at all. If every project red lands on the enterprise register, the board learns to skim it. If nothing does, the board learns about project risk only when it materialises. Clear escalation criteria fix both.
Scoring on different scales. A project’s 5×5 matrix and the enterprise’s 5×5 matrix look identical and mean different things. Unless the consequence definitions line up, the scores cannot be compared, and they certainly cannot be added together.
Closing the register at project close. Risks that outlive the project quietly disappear at handover, then resurface years later with nobody’s name against them.
Spreadsheets vs project risk management software
Everything above can be done in spreadsheets, and many organisations try. The difficulty is that the line between project and enterprise risk has to be maintained every week, by dozens of people, and spreadsheets are built for one person at a time.
A project risk register in a spreadsheet is a snapshot that gets emailed. An enterprise view assembled from those snapshots is a snapshot of snapshots, already out of date by the time it reaches committee. The links that matter most, from a project risk to the enterprise risk it feeds and from there to the objective it threatens, cannot be held in a spreadsheet at all. They live in someone’s head until that person changes roles.
Purpose-built risk management software changes that. When project registers and the enterprise register sit in one system, with one taxonomy and one set of scales, escalation can become a link rather than a re-keying exercise. A risk rated up in a project is visible to the enterprise owner without waiting for the monthly pack. A pattern across three projects shows up as a pattern, not as three unrelated rows. And when the board asks why delivery is amber, the answer traces down to the specific risks underneath it.
What organisations should look for in project risk management software
The checks below test whether a tool can hold the line between project and enterprise risk, not only record risks. For buyers, six matter most.
| Check | Why it matters | Ask the vendor |
|---|---|---|
| One risk language | Project and enterprise scores only add up when the scales mean the same thing. | Can we set one taxonomy and one set of consequence scales for every register? |
| Linking, not copying | A copied risk drifts. A linked risk stays one version of the truth. | Show us a project risk linked to an enterprise risk, then change the project rating. |
| Patterns across projects | The pattern test depends on seeing one supplier or contractor risk across every project. | How would we see the same risk across all our live projects? |
| Handover at project close | Risks that outlive the project need a new owner, not an archive. | What happens to open risks when a project closes? |
| UK data hosting | UK public sector and infrastructure buyers often need to know where data is held and who can reach it. | Where are production data, backups and support access located? |
| UK assurance and buying routes | Public sector buyers commonly look for Cyber Essentials and buy through frameworks such as G-Cloud. | Which certifications do you hold, and are you on the current G-Cloud framework? |
Ask every vendor to answer with a demonstration on your own data, not a slide. For reference, Clew customers choose their AWS hosting region, including a UK region, and Clew holds ISO 27001, Cyber Essentials and Cyber Essentials Plus. Public sector buyers can also buy Clew through G-Cloud 15. For a structured way to run the whole evaluation, use our Risk Management Software Buyer’s Guide.
Frequently asked questions
What is the difference between project risk and enterprise risk?
Project risk is any uncertainty that could stop a single project delivering its scope, cost, schedule or quality objectives. Enterprise risk is any uncertainty that could stop the organisation achieving its strategic objectives. Project risk is owned within the project and usually closes with it. Enterprise risk is owned by named executives, overseen by the board, and persists.
What is project risk management software?
Project risk management software holds each project’s risk register, assessments, treatments and owners in one place, instead of in separate spreadsheets. The better tools also link material project risks to the enterprise risk register, so they reach the people who need to act on them without being re-keyed.
When should a project risk be escalated to the enterprise risk register?
Escalate a project risk when it passes any one of three tests. It threatens an enterprise objective rather than only a project objective. Its credible consequence exceeds what the project can absorb within its contingency, authority or tolerance. Or the same risk appears in more than one project at once. Risks that pass none of the tests stay with the project. Those that pass any one belong on the enterprise register as well, linked to the project record rather than copied.
Who owns a project risk once it is escalated?
Two people, for different things. The project owner stays responsible for managing the risk within the project. A named enterprise owner is responsible for what the risk means for the organisation, including any decision beyond the project’s authority.
What happens to project risks when a project closes?
Some close with the project. Others transfer to whoever inherits the asset, facility or service, such as an operations team. Agree the transfer process in the project risk management plan so latent risks are handed over with a named owner rather than lost at completion.
What should UK organisations look for in project risk management software?
Look for one risk language across every register, risks linked rather than copied between project and enterprise level, visibility of the same risk across projects, and a clear handover process at project close. UK buyers should also check where data is hosted, which certifications the vendor holds, such as Cyber Essentials, and whether it is available through G-Cloud.
Bring project risk into the enterprise view
Clew is a risk and assurance platform built around the Golden Thread: the traceable link from strategic objectives, through the risks that threaten them, to the controls that manage them and the exposure that remains. Clew now supports project-level risk registers linked to the enterprise risk register, so project teams and the enterprise risk function work in one platform, in one risk language, from one version of each risk. UK organisations are supported from our office in Reading, with UK hosting available and a G-Cloud 15 listing for public sector buyers. Risk and assurance teams in construction, government, healthcare, infrastructure, mining and transport use Clew to keep the line from objective to action visible, from the boardroom to the site.
Clew is a risk and assurance platform built around the Golden Thread, the traceable link from strategic objectives to the controls that manage them and the exposure that remains.
Explore Clew's risk management software →