ERM software-buying series · Capability differences
Enterprise Risk Management (ERM) Software Capabilities: How Suppliers Actually Differ Capabilities
You can't evaluate every ERM supplier in the market. Knowing where they differ narrows the list quickly.
A capability on the feature list may be built in, licensed separately, or through complex configuration that lengthens the implementation phase.
Key takeaway
Start by learning the range of ERM functions available, which are common to most suppliers and which only some can deliver. Use that to refine your requirements and reach an ideal shortlist, then assess those few suppliers in depth.
Where ERM suppliers stop looking alike
Everyday functions carry
most of the daily work.
These appear on nearly every enterprise risk management (ERM) feature list. A supplier can be strong on rare capabilities and still be a poor fit if the everyday functions do not suit your team.
Throughout this page, suppliers are the software companies you will be comparing.
Enterprise Risk Management (ERM) Software Requirements covers how to turn your needs into a brief before you compare suppliers.
A capability on the list
is not yet in your proposal.
Beyond the everyday functions, a smaller set of capabilities is delivered by only some suppliers. The considerations below cover the mains ones.
When a supplier confirms a capability, establish which of these four routes it arrives by. The route determines what you pay, who does the work, and whether your team can maintain it.
Built in
Included in the product and licence being proposed. Confirm the configuration effort still required.
Separate module
Delivered through another licensed application or analytical module. Clarify shared records, workflow continuity and the additional cost.
Via partner
Delivered through a third party the supplier has partnered with, such as threat intelligence or regulatory change feeds. Confirm whether the partner is contracted through the supplier or separately, and what happens if that relationship ends.
Configured or built
Requires configuration, custom development or services. Separate what your administrator can maintain from what needs the supplier.
Settle the functions first.
Then bring in the rest.
Functional capability decides which suppliers can do the work. It does not decide the shortlist on its own. Technical fit, security and access, implementation and support, and total cost can each remove a supplier that scores well on functionality, and they are usually answered by colleagues outside the risk team.
You are ready to shortlist when you can
- Say whether the everyday functions suit how your team works
- Name which of the differences in the considerations (in the below sections) matter to you
- Know which route each one arrives by in the proposal
- Bring technical fit, security, implementation and cost questions in next
How to Evaluate ERM Software in Supplier Demos: What to Ask and What to Watch shows how to test what each shortlisted supplier shows you.
Planning reference: This guidance is for planning a software purchase. Which capabilities matter will depend on your organisation's own circumstances.
Capabilities worth checking before you shortlist
01 Quantitative risk simulationModelling
Simulation runs thousands of probability-weighted scenarios to show the range of losses a risk could produce, rather than a single estimate. It also covers monetary scoring, so a supplier that can simulate can already express exposure in dollar terms. The common gap is not whether a supplier can simulate, but where the simulation runs. Many export the register to a separate modelling tool and bring the results back by hand, which means the numbers are only as current as the last export. It matters most where a board expects exposure quantified rather than rated.
Ask in the demoDoes it model several risks together, and does it run against our live risk records or an export?
02 Bowtie analysisModelling
A bowtie maps a risk visually, with the threats that could cause it on one side, the consequences on the other, and the preventive and mitigating controls in between. It is standard practice in energy, aviation and process safety, and largely absent from general-purpose GRC tools. It also works well in an annual risk workshop, where a room can see the controls on a risk and where the gaps are without reading a register.
Ask in the demoIs the bowtie included in the base licence, and how many people can use it?
03 Automated indicator feedsIndicators
Most tools record key risk and key control indicators. Fewer collect the values automatically, pulling them from incident counts, control failures or a system such as a service desk, rather than someone entering them each month. A populated dashboard looks identical either way in a demo. Where automation is available it usually carries a licence cost and an implementation cost, so the practical question is what you get without paying for either: whether a first line user can upload from a spreadsheet unaided, and what it would take to automate the handful of indicators that matter most.
Ask in the demoWhat would it cost, in licence and in build, to automate our most important indicators rather than uploading them?
04 External risk and threat intelligenceIntelligence
Some suppliers ingest outside feeds, such as threat intelligence, regulatory change or supply chain data, and connect that information to the risks and controls already in your register. The value is in the connection. A feed that arrives as a separate report someone has to read is a subscription, not a capability. Most suppliers deliver this through a partner rather than building it, so you are buying into their commercial arrangement as well as their product.
Ask in the demoHow is the feed licensed, including the annual, integration and support fees, and how deep is the partnership with the data provider? Has the provider changed before?
05 Project riskProjects
Project risk needs different handling from enterprise risk. Risks are tied to a schedule and a budget, they are compared in cost terms to decide which response is worth taking, and they close when the project does. Expected monetary value, probability multiplied by cost impact, is the usual method. Some suppliers cover this in the core product, some through a separate module, and some not at all.
Ask in the demoIs project risk part of the base licence or a separate module, and can they show how project risk is reported, including the total expected monetary value across the register and how it informs the contingency reserve?
06 Integration claimsIntegration
Every supplier will tell you they support integration, and they are not wrong, because almost anything can be connected given enough work. What varies is what they actually offer: a ready-made connector for your system, an open API someone has to build against, a scheduled file exchange, or a middleware platform you are expected to license separately. A supplier will usually build and support their own side of a connector. The other side, on your existing system, is often left to you, which means your own developers or the other vendor's professional services, at your cost and on their timeline.
Ask in the demoDoes this connector already exist for our systems, and who builds and tests the other side, us or you?
07 Group ConsolidationStructure
Most suppliers can hold risks for more than one entity. What differs is what happens when the group wants one view. Some keep a separate register per entity and combine them into a report, so the group number is only as consistent as the local wording behind it. Others hold one taxonomy and one scoring scale across every entity, so a subsidiary risk rolls into the group view without being rewritten, while local risk owners still see only their own. The difference shows up when two subsidiaries rate the same exposure differently and someone has to decide which number reaches the board. It also decides how much work a restructure or an acquisition creates, because entities move more easily in some data models than others.
Ask in the demoShow us a risk raised in a subsidiary appearing in the group board view, and tell us what happens to that view when we add an entity or move one between divisions.
Fit-based software matching
Find software that fits how your organisation operates
Tell us what the software must support, how your teams work and which delivery constraints matter. Centvra uses those inputs to build a focused supplier shortlist.
Your operating brief
Fit-based shortlist
Tell us your requirements and we match you to suppliers that fit
Share the capabilities that matter, how your risk team works and what your delivery constraints are. Centvra matches that against supplier data and returns a shortlist, with the capabilities each one covers in the product being proposed.
Common questions
- What are the standard functions I should expect in any ERM tool?
Most ERM tools cover the same ground: a risk register with owners and categories, inherent and residual assessments with review workflow, treatments and actions tracked to completion, indicators recorded against appetite, and dashboards and reporting for different audiences.
These carry most of the daily work, so the question is not whether a supplier has them but whether each one suits the way your team operates.
- What is the difference between a capability being native and being configured?
Native means the capability is built into the product and licence you are being offered. Configured means it can be made to work, but someone has to build it first and maintain it afterwards.
There are two routes in between: a separate module, which is another product on the same platform at additional cost, and a partner, where a third party supplies the capability through the supplier. The route affects what you pay, who owns the work and how long implementation takes.
- Can I tell from a demo whether a capability is native?
Not reliably. A demo environment is prepared in advance, so a capability built through configuration looks the same as one that ships with the product.
The difference only appears when you ask what it took to set up, whether it is included in the licence being proposed, and who maintains it once the project ends. Ask those questions during the demo rather than after it.
- Will a supplier's feature list tell me what is included in the price?
No. A feature list tells you a capability exists somewhere in the supplier's portfolio. Suppliers usually quote a base package, and the feature list is broader than what that package contains.
It does not tell you whether a capability is in the edition being quoted, whether it needs a separate module, or whether a partner subscription sits behind it. Ask which of those applies to each capability that matters to your team, and ask for the annual, implementation and support costs separately.
- A supplier offered us their requirements template. Should we use it as a specification base?
- No. An ERM template is not a neutral list, because the rows carry that supplier's risk methodology inside them. A row reading "supports risk appetite" hides whether appetite is one threshold per risk or tolerance bands set per entity, and whether a breach raises an alert or waits for someone to open a dashboard. "Supports key risk indicators" covers both a field somebody types into each month and an automated feed from a source system. "Multi-entity" can mean separate registers side by side or a genuine group roll-up with a consistent taxonomy underneath. The same vagueness runs through the rows your IT colleagues will care about. "Supports single sign-on" does not say whether that means SAML or OpenID Connect, which identity providers are already proven, whether user accounts are provisioned automatically, or whether any of it sits in the edition being quoted rather than an enterprise tier above it. Build your specification on those rows and you inherit the methodology they assume, usually the one that supplier's product implements best. Keep your own taxonomy, assessment scale and appetite model as written, and use the template only to check for an area you had missed. For each row that matters, add how the capability is delivered in the edition being quoted, because a template records a capability as present or absent and never says whether it is built in, a separate module, a partner subscription or a configuration project.