Centvra
Menu

Software · ERM · Demonstration and evaluation

How to Evaluate Enterprise Risk Management (ERM) Software Demos: What to Ask and Watch

A polished enterprise risk management (ERM) demo can look right without showing how your risk process actually works.

Start with the supplier's standard demo to understand the product, then use focused follow-up sessions to trace the risk flows that could change your decision.

Key takeaway

You'll know what a first demo should show, which questions deserve a focused follow-up session, and how to record what each supplier showed, explained and left unproven, so you can compare them side by side.

What to Ask and Look for at Each Stage of an ERM Software Evaluation

01 Plan the first demo

Let the supplier lead the first demo.
Follow one risk through.

Use each evaluation activity for a different decision: the first demo to understand the standard product, focused workshops to examine material uncertainties, evidence to establish what each finding supports, and a decision to resolve gaps and commitments.

Start with the supplier's prepared environment. Ask the supplier to choose one risk and stay with it from owner to reporting. A connected story shows how the product really works, while a tour of separate screens does not. Use the first session to understand the interface, navigation and enterprise risk management (ERM) record relationships before asking for buyer-specific configuration. Share your context, priorities and any requirement that could rule out the product, but let the supplier guide the sequence.

Most suppliers will run a standard script in a standard demo environment. Ask whether the supplier has demo environments set up for different industries, because a manufacturing setup can look very different from a banking one. Tell the supplier your region and industry beforehand so it can choose the closest environment.

Throughout this page, suppliers (often called vendors) are the software companies you are comparing. This guide covers the demonstration stage of the ERM software buying series.

01

Owner and entity

Who holds the risk, and which part of the organisation it belongs to.

02

Assessment

The inherent and residual ratings, and the rationale behind them.

03

Controls and actions

The mapped controls and the treatment actions.

04

Reporting

How the risk appears in local and enterprise reporting.

Do not require a buyer-specific dataset, custom workflows or pre-built reports in the first demo. Partial buyer data may lack the related controls, assessment history, thresholds, hierarchy and reporting relationships needed to complete the story. Check whether important information is visible at the point where each user makes a decision.

Enterprise Risk Management (ERM) Software Requirements covers how to set the priorities you will test.

02 Go deeper

Test a few scenarios
that match your priorities.

After the first demo, use focused workshops for the ERM questions that could change the selection decision. Before each session, ask the supplier which topics it can cover and mark your priorities. Share the roles who will attend, so the session can start with the topics that matter to them and people such as IT can join only for theirs. Agree the question and expected output for each. Use non-sensitive examples only where they help, and record what was shown, explained and left unresolved.

Choose a small number of scenarios tied to your priorities. These examples illustrate the method, not a complete ERM test plan.

Appetite breach

Scenario

A business unit exceeds an appetite threshold.

What to observe

Open the risk record and follow its owner, residual rating, linked controls and relevant indicator through review, escalation, treatment and management response. See what the local user, approver and central ERM team can each see.

WhyA highlighted breach or email alert does not establish the full response.
Clarify nextThe threshold source, routing rule, overdue escalation, temporary exception, action ownership and how the breach appears in group reporting.

Group roll-up

Scenario

Headquarters reviews risks reported by several business units.

What to observe

Switch between local and rolled-up views, then drill from the group position into the contributing records. Follow ownership, permissions, local ratings, group classification and any duplicated or shared exposure.

WhyA roll-up can mean several different things, and they are not interchangeable.
Clarify nextWhether the enterprise view lists records, reclassifies them against a group matrix or calculates an aggregate, what remains unchanged locally, and how the reporting position is preserved over time.

First and second line views

Scenario

A first line user and a second line user open the same risk.

What to observe

Open the same risk as each user. Compare what each can see, change and approve. Check whether the first line user gets a simplified view of only what they need to update, while the second line user keeps the full record and history.

WhyFirst line users need a quick task, while second line users need the full picture. One screen for both tends to suit one group and frustrate the other.
Clarify nextWhich fields each role can see, change or approve. Whether the simplified view is standard or configured. Whether second line review comments are visible to first line users. Who sets and maintains the permissions.
03 Weigh the evidence

Record what was shown,
and what you were looking at.

Match the evidence to the question, then note what you were looking at. Keep the two apart: something set up for the demo can be shown live, while shipped functionality may still need documentation or follow-up.

Evidence source

How you know

Shown live. Risk fields, workflow, permissions and drill-down observed in that environment.

Explained. Configuration or methodology claims that may need follow-up.

Documented. Evidence suited to security, API coverage, architecture or scale.

In the demo

What you are looking at

Shipped. Part of the product you would buy, and the supplier can show where it is switched on.

Set up for the demo. Built by the supplier's team for this session. Ask what your own administrator could build, and how long it would take.

Not shown. May need a module, partner or custom work, or may simply not have been demonstrated. Keep it as a follow-up, not as proof it is missing.

After each session, make two judgements for every requirement you tested. Capability fit is how well the proposed ERM flow and enterprise view support it. Evidence confidence is how strongly the available evidence supports that judgement. Use the same important requirements for every supplier, but allow them to show different approaches.

Keep one short record for each finding:

Requirement and priority
The requirement being tested and how important it is.
What was observed
What was shown live in the session.
Supporting evidence
What the finding rests on: shown live, explained or documented.
What you were looking at
Whether it was shipped, set up for the demo, or not shown.
Material limitation
Anything that limits how well it meets the requirement.
Decision
Whether the gap must be resolved, committed in scope or accepted.
Do not let an overall score hide an unresolved essential requirement. A different workflow is not automatically weaker if it supports the intended decision and your users can operate it.

ERM Software Capabilities: How Suppliers Actually Differ explains the four routes a capability can arrive by.

04 Decide the next step

A proof of concept should be avoided
unless procurement requires one.

A formal proof of concept (POC) is a separate exercise, not the default next step. It suits only a material question that demonstrations, workshops and evidence cannot resolve.

Default position

Avoid a formal POC

Do not start a formal POC when demonstrations, workshops, configuration walkthroughs or the evidence you already have can answer the question.

If procurement requires one

Test a defined uncertainty

Secure sponsorship, participants, representative data and success criteria before requesting supplier commitment.

You are ready to decide when you can

  • Say what each finding rests on: shown live, explained or documented
  • Say whether each capability was shipped, set up for the demo or not shown
  • Compare suppliers on the same requirements, not identical screens
  • Decide each material gap: resolve it, commit it in scope or accept it
Technical and procurement reviews are additional evaluation work. Workshops do not establish every requirement.

Why GRC Software Projects Can Take Months to Get Started covers what has to happen after you choose a supplier.

Planning reference: This guidance is for planning a software purchase. Which requirements apply will depend on your organisation's own circumstances.

Six Practices for a More Effective ERM Software Evaluation

  • 01 · What Should the First Demo Establish?First demo

    Use the first session to understand the standard ERM product and decide whether deeper evaluation is justified.

    Focus
    Follow one risk from creation and ownership through assessment, controls, actions and reporting. Examine navigation, field clarity and the information available to each role. Let the supplier use its prepared data and normal demonstration sequence.

    Watch for

    • A risk that cannot be followed from owner to reporting in one sequence
    • Fields or navigation that only the presenter can explain
    • Every role seeing the same information, whatever it needs to decide

    Carry forward: An initial view of product relevance and a short list of ERM questions for focused follow-up.

  • 02 · Which Gaps Need Focused Workshops?Follow-up

    Use workshops for material ERM uncertainties after the standard product is understood.

    Focus
    Choose from four areas: the risk flow (assessment, control mapping, appetite, treatment and approval), the group view (local registers, hierarchy, permissions, roll-up and drill-down), administration (matrices, roles, recurring cycles and routine configuration), and technical points (imports, integrations, reporting feeds and supporting evidence).

    Watch for

    • A workshop with no agreed question, participants or expected output
    • An area booked that could not change your decision
    • What was shown, explained and left unresolved not written down afterwards

    Carry forward: The question, participants and expected output for each workshop, and a record of what was shown, explained and left unresolved.

  • 03 · What Does the Evidence Support?Evidence

    Base each finding on evidence suited to the question being assessed.

    Focus
    Observe which risk fields, workflow steps, permissions and drill-downs worked live. Distinguish live behaviour from explanations, slides and documentation. Separate evidence strength from configuration, modules, integration or custom work.

    Watch for

    • Explanations, slides or documentation treated as live behaviour
    • Security, application programming interface (API) coverage or performance at scale judged from a general demo
    • A configured capability treated as if it were standard

    Carry forward: Any material ERM behaviour that remains unanswered or undemonstrated, kept as a follow-up item rather than treated as proof of absence.

  • 04 · Can Users and Administrators Work With It?Operating fit

    Evaluate the ERM work people must perform, not only what the dashboard displays.

    Focus
    A risk owner updating an assessment, controls, rationale and treatment action. A reviewer seeing changes, challenging the submission and approving or returning it. The central ERM team monitoring cycles, breaches, overdue work and enterprise reporting. An administrator changing roles, matrices, fields and routing without avoidable dependency on the supplier.

    Watch for

    • Extra steps or unclear fields that make routine updates slow
    • A reviewer who cannot see what has changed
    • Changes to roles, matrices or routing that need the supplier

    Carry forward: What each role must do in the product, and how much effort each task takes.

  • 05 · How Should Fit and Gaps Be Compared?Evaluation

    Compare ERM outcomes against the same important requirements without forcing identical product approaches.

    Focus
    Compare ownership, assessment, control, appetite, treatment and reporting outcomes. Challenge how local assessments become a defensible enterprise view. Separate capability fit from confidence in the supporting evidence.

    Watch for

    • An overall score that hides an unresolved essential requirement
    • A different workflow marked down although it supports the same decision
    • A material gap left without a follow-up or an explicit decision to accept it

    Carry forward: For each material gap, whether it must be resolved, committed in scope or accepted.

  • 06 · What If Your Procurement Requires a Proof of Concept?Proof of concept

    Do not make a formal proof of concept (POC) the default next step for an established ERM product.

    Focus
    Prefer demonstrations, focused workshops and evidence where they answer the question. Test only a defined material uncertainty about organisational fit, such as an unusual assessment method, complex hierarchy and roll-up logic, a material data-volume concern or critical integration behaviour.

    Watch for

    • A POC that tries to recreate your whole ERM environment
    • Starting without a sponsor, committed participants, representative data or success criteria
    • Supplier effort and commercial arrangements left unagreed until after it begins

    Carry forward: The specific uncertainty to test, and what must be ready first: a senior sponsor, committed risk and technical participants, representative data, observable success criteria and an agreed way to reach the decision.

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.

Start matchingFree to use · No paid ranking
Matching modelRequirements-led

Your operating brief

CapabilitiesWhat the software must support
Ways of workingWorkflow, ownership and scale
Delivery constraintsHosting, integration and support

Fit-based shortlist

Matched supplierFunctional fit
Matched supplierOperating fit
Matched supplierDelivery fit

Tell us your requirements and we match you to suppliers that fit

Share what the software must support, how your risk team works and your delivery constraints. Centvra matches that against supplier data and returns a shortlist you can take into your demos.

This example is ready to run or edit it to match your own situation.

Common questions

The supplier's demo data is not relevant to our ERM scope. Should we give them our dataset?

Not for the first demonstration. Use the supplier's prepared data to examine the interface, navigation and ERM flow.

Follow whether a risk captures its owner, organisational entity, category, inherent and residual assessments, mapped controls, indicators, actions and review history, then see how it reaches business-unit and group reporting. A partial buyer dataset can consume preparation time while lacking the related records and history needed to complete the story.

Record the material gaps and arrange a later session with the supplier's technical specialist to examine the relevant configuration and detailed flow.

How can we assess ERM usability without configuring the software for our organisation?

Use a focused session with representative roles.

Ask a risk owner to update an assessment, controls, rationale and treatment action. Ask a reviewer to challenge or return it. Ask the central ERM team to monitor completion, breaches and overdue work. Examine the number of steps, clarity of fields, navigation between related records and the information available at each decision.

For administration, ask how roles, matrices, fields and routing are changed. This reveals operating effort without requiring the supplier to build your complete environment.

How should we compare ERM suppliers that use different workflows and terminology?

Compare the required outcome rather than identical screens.

Suppliers may represent appetite, tolerances, assessment stages or approval roles differently. Use the same material scenarios and establish whether each approach preserves ownership, supports the assessment method, links controls and actions, identifies breaches and produces the required enterprise view.

Record limitations and delivery dependencies alongside fit. A different workflow is not automatically weaker if it supports the intended decision and can be operated by your users.

When does an unresolved question from a demo become a material selection risk?

When it affects an essential ERM requirement.

That includes enterprise reporting, ownership, assessment methodology, permissions, implementation scope, integration cost or ongoing administration. Examples include an unexplained roll-up method, an inability to preserve local and group classifications, unclear access to confidential records or a board view that cannot be reconstructed.

Keep the issue visible outside the overall score and decide whether it must be resolved, committed in scope or explicitly accepted.

When is a formal proof of concept (POC) justified for ERM software, and what must be ready first?

Only when a defined uncertainty cannot be resolved any other way.

Use demonstrations, focused workshops, configuration walkthroughs and supporting evidence first. A POC may be justified for an unusual assessment method, complex hierarchy and roll-up logic, a material data-volume concern or critical integration behaviour. Test that uncertainty rather than attempting to recreate your complete ERM environment.

If procurement requires one, confirm a senior sponsor, committed participants, representative data and success criteria before asking the supplier to commit, and agree the supplier's effort and any commercial arrangements up front. If these are not ready, use a focused workshop to clarify the requirement first.