How to Choose Enterprise Risk Management (ERM) Software

Common questions

How should risk appetite shape our ERM software requirements?

It decides what the software must monitor, escalate and report, so agree how you express appetite before you write requirements.

Appetite set as qualitative statements needs different support from appetite set as metrics with thresholds for each risk category or business unit. Clarify who sets and approves appetite, at which levels it applies, which indicators track it and what should happen when a threshold is breached. Those answers shape your requirements for key risk indicators, escalation, exceptions and board reporting.

Do we need advanced ERM features such as Monte Carlo simulation, bowtie analysis or automated KRI feeds?

Only if your risk maturity, data and team can use them. Most ERM platforms already cover the core functions as standard.

Risk registers, inherent and residual ratings, risk and control self-assessment, appetite tracking, action tracking and standard reporting rarely separate suppliers. Advanced features such as Monte Carlo simulation, financial impact scoring, automated KRI data feeds, external risk intelligence and bowtie analysis do. Before paying for them, check that you have reliable loss or exposure data, source systems that can feed your indicators, and people who will maintain the models and act on the results.

Who from our organisation should attend ERM supplier demos?

Include the people who will use, run and rely on the system, not only the central risk team.

Business unit risk owners can judge whether assessments and updates fit their day-to-day work. System administrators can gauge the effort needed to configure and maintain it. Senior report users can check whether the group view answers their questions. IT and security representatives can raise integration and access questions early. Agree in advance what each attendee will assess, so feedback stays comparable across suppliers.

Which ERM buying activities do teams most often underestimate in effort and time?

Negotiating the master services agreement, the main contract, is often the longest back-and-forth. Liability limits, data protection terms, service levels and termination rights are common sticking points, and each round waits on both legal teams.

Other activities that often take longer than planned:
· Your own supplier due diligence: your third-party risk, security and data protection reviews apply to the ERM supplier too, often with long questionnaires and follow-up rounds.
· Data location and hosting checks: where risk data is stored and who can access it may need its own review, especially in regulated industries.
· Scope for a group rollout: agreeing which entities, business units and features go first can take several rounds.
· Document alignment: a change to the contract, statement of work or price can reopen the others.
· Funding and approvals: budget cycles and approval committees run on their own calendar.

Starting these early, and in parallel where possible, protects your project kick-off date.

Why do ERM projects struggle when business units define risk differently?

Group reporting only works when risks are categorised and rated on a shared basis.

When business units use different risk categories, rating scales or terms, the software may show their risks side by side but cannot compare or combine them reliably. Fixing this after configuration usually means rework. Agree the group taxonomy, rating approach and any allowed local variation before the system is set up. How a platform handles this is usually settled during implementation scoping rather than shown in a standard demo, so ask each supplier directly.

How should our ERM maturity affect the way we buy?

Buy for the ERM function you have now and the next stage you can realistically reach, not an ideal end state.

A developing function usually gains most from a clear operating model, a consistent risk taxonomy and a phased rollout, with advanced features left for later. A mature function can push harder on group aggregation, appetite monitoring, quantitative analysis and links to operational, third-party and IT risk. Either way, check that the supplier can support your next stage without a disruptive change of platform.