Software · ERM · Requirements
The request that starts an ERM purchase rarely says enough about what the software must do.
Turn it into a short brief first, then compare enterprise risk management (ERM) products against it.
Key takeaway
You'll know what your ERM software must help your organisation decide, what belongs in the first phase, and which open questions still need answers, before you compare products.
Whether you are buying enterprise risk management (ERM) software for the first time, replacing a system or expanding its use, begin with the organisational need. A board request, reporting workload, appetite breach or group expansion may prompt the purchase. Clarify what must improve and which decisions the new system should help people make.
The examples below turn starting requests into requirements that colleagues and suppliers can work with.
Throughout this page, suppliers are the software companies you will be comparing.
We need better board reporting.
The quarterly board pack shows the approved enterprise position, material changes, appetite breaches and management actions, with the reasons behind them.
We need one risk register.
The group sees the enterprise picture while each subsidiary keeps its own assessments, and detailed IT risk records stay in the specialist system.
We need automated key risk indicators (KRIs).
Priority indicators have agreed sources, update frequencies and escalation thresholds. Feeds that are not yet available are recorded as implementation dependencies.
ERM Software Capabilities: How Suppliers Actually Differ covers how products differ in meeting requirements like these.
You do not need to finish a full redesign of how you run enterprise risk management before exploring software. You do need to know which methods and scope decisions affect the purchase, including those still awaiting agreement.
Then decide what the first phase covers: which entities, business units and types of risk, whether local assessments will be managed in ERM or supplied by existing systems, and which information the group needs for oversight.
The entities, business units and risk types the initial rollout must cover, and the information the group needs to oversee them.
Needs you want to keep open but not deliver yet, such as bringing another risk area into ERM. Check how the software would connect to it or take it on, so the first purchase keeps that option open.
Early supplier conversations can reveal alternative workflows, extra data needs or capabilities you had not considered. Revisit the requirement before widening the scope. Ask which agreed problem the idea addresses, when it is needed and what it would ask of your organisation.
Record the new idea and what prompted it.
What decision does it support, and which people, data or systems would it need?
Does it belong in the first phase, a later phase or further exploration? Update the brief and note why.
Use the seven considerations below to prepare an initial brief. It should give colleagues and suppliers enough context to understand the purchase, without becoming a catalogue of every possible function.
How to Evaluate ERM Software in Supplier Demos: What to Ask and What to Watch shows how to test your brief once it is ready.
Planning reference: This guidance is for planning a software purchase. Which requirements apply will depend on your organisation's own circumstances.
A request for a board dashboard often starts the purchase. The real difficulty may be spotting material changes, tracking appetite breaches or following management action, and a dashboard alone will not solve that. Buying the software does not, on its own, deliver the improvement.
Write down what should get better and how you would notice, such as less time assembling the board pack or more timely local reviews. Measure where you are today before setting targets.
Risk information often travels from local teams to enterprise review by being re-entered, reconciled and waited for. Without tracing that route, a purchase can speed up a step that was never the real delay. Some gaps come from rules that are not yet agreed, such as scoring definitions or approval authority, and software cannot settle those.
Follow one recent reporting cycle or escalation from local update to enterprise review. Mark where information was re-entered, delayed or missing, and whether the fix is software, a process decision or both.
A group may hope ERM will cover every entity, risk type and existing system from the start. That makes it hard to tell suppliers what the first delivery must include, and hard to compare their answers.
Say which entities, business units and risk types the first phase covers, which systems stay as they are and what information the group needs from each. Keep later-phase needs in a separate list.
ERM depends on business contributors as well as the central team: people who update assessments, review local information and challenge conclusions. If business units use different risk categories or rating scales, the software may show their risks side by side but cannot compare them reliably.
List the tasks the software must support: updating assessments, reviewing local information, approving decisions and administering the system, and how often each happens. Note which methods are agreed and which are still open.
A request for a board dashboard does not say what the board needs to decide. Boards, executives and local risk owners need different information at different times, with an explanation beside each rating or trend. Appetite monitoring may need statements and commentary, measurable thresholds or both.
For each audience, write down the decision, the information needed, how often and the explanation that goes with it. If leadership wants a comparison with an earlier approved position, say so.
Hosting, access, assurance and integration conditions can rule out a delivery option, but they are often assumed rather than confirmed. Some dates are fixed and others only preferred. An integration nobody has confirmed is a dependency, not a given.
Check each limit with IT, security, procurement and privacy or legal colleagues early. Record whether each date is fixed, preferred or waiting on an approval, and what each integration must carry.
Labels such as essential or high do not help when colleagues disagree about the same item. Supplier conversations can also add ideas that quietly widen the scope, so the brief drifts without anyone deciding it should.
Write down what would go wrong without each essential requirement. When the brief changes after a supplier conversation, record what changed and why.
Fit-based software matching
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
Describe your institution in plain language. Only three minutes, no signup to see your matches.
Start with the buying purpose, initial scope, important users, current gaps and constraints that could exclude an option. Describe important requirements with a reason and priority.
You can leave some details open for market exploration. Identify the uncertainty, how it will be clarified and whether it affects initial scope or later delivery. A complete configuration specification is not necessary for an initial conversation.
Four things. How your risk register works today, including how many entities it covers and how local risk owners update it. What the board or audit committee paper has to show, and which parts of it are reconciled by hand. Whether risk appetite thresholds exist, and how a breach gets noticed. And which risk types already sit in other systems that will keep their own records.
Then the request that started this. An audit finding, a board paper and an acquisition each point to a different first phase, and the reason behind the request is what tells you which requirements matter most.
You do not need to complete every methodological detail before exploring the market. Identify the taxonomy, assessment, approval and review decisions that are settled, those open to change and those needing internal agreement.
Material uncertainty about scoring or approval authority needs a plan for resolving it. Supplier input may inform the approach, while the organisation remains responsible for its risk management decisions.
Sort each requirement into one of four groups: needed at launch, useful but optional, needed in a later phase, or still an open question. For anything needed at launch, write down what would go wrong without it. That reason is what settles disagreements when two stakeholders rank the same item differently.
Check hard limits, such as hosting or data restrictions, with the relevant team before treating them as fixed. Revisit priorities when scope, budget or supplier conversations change the picture, and note why each change was made.
A supplier's template can be a helpful starting point, especially for checking you have not missed an area. Because it is written from one product's perspective, it will naturally use that supplier's terms and reflect what its product emphasises.
Before adopting an item, rewrite it in terms of your own need: the decision it supports and how important it is. Check that the wording describes an outcome rather than one product's way of delivering it, so every supplier can respond on equal terms. Add any needs the template does not cover, and remove anything nobody in your organisation can explain.
Not necessarily. Some organisations manage all of these in one platform. Others keep specialist systems for third-party, continuity or IT risk and send only the information enterprise oversight needs into ERM. Neither approach suits everyone.
Weigh how well your existing systems work, whether the teams involved are ready to change how they work, and how much your central team can realistically administer. If you may bring these areas in later, check how the ERM software would connect to them or take them on, so the first purchase keeps that option open.