Software · TPRM · Demo evaluation
How to Evaluate Third-Party Risk Management (TPRM) Software Demos: What to Ask and Watch
In most third-party risk management (TPRM) software demos, sometimes described as vendor risk management demos, much of what matters is explained rather than shown.
Let the supplier run its standard demo first, then book focused sessions for the questions that still matter.
Key takeaway
You'll know what to look for in the standard demo, what to take into a focused follow-up, and how to record each point as shown live, explained only or unresolved, so you compare suppliers on evidence rather than impressions.
Run Fewer, Better TPRM Demos and Record What Each One Proves
One third party.
Many moving parts.
A single third party can have several services, contracts, internal owners, locations and assessments running at the same time.
Products organise this in different ways. A good demo helps you understand how the product links these pieces together, and whether they stay linked when something changes. For example, a new service is added, evidence arrives late, an alert comes in, or the relationship ends.
Throughout this page, third parties are the vendors and partners you already work with, and suppliers are the software companies you're comparing. This guide covers the demo stage of the TPRM software buying series.
Five demos in a week
blur into one.
Many shortlists are built from the first page of search results for "TPRM software". That can mean booking five suppliers in a single week. By the fourth demo, the products start to look alike. By the end of the week, the team struggles to remember what each supplier's software could actually do. The comparison ends up resting on impressions rather than evidence.
It's like test-driving five cars in one afternoon. By the last one, you're comparing cup holders.
See the standard product first.
Go deeper where it matters.
Once the demos are booked, leave time between them and write up each one on the same day, using the same headings for every supplier.
See the standard product
Let the supplier use its usual demo setup, data and running order. You don't need to prepare data, set anything up or ask for a tailored show.
Go deeper where it matters
Book a focused session when an open question could affect whether the product fits. Agree the questions, who should attend and what you want to settle before the session.
Bring a short example
to talk through.
If some of your third-party relationships are complex or unusual, prepare a short example and ask the supplier to talk through how the product would manage it over its lifetime. This keeps the first demo on the standard product while still testing what matters to you. Points to think about:
You're ready to book demos when you can
- Name the few suppliers worth a full demo, and why
- Space the demos out, with time to write up each one
- Use the same write-up headings for every supplier
- Bring one short example from your own third parties
Planning reference: This guidance is for planning a software purchase. Which obligations apply will depend on your organisation's own circumstances.
Six Things to Check in a TPRM Software Demo
01 · How Does the Product Structure the Third-Party Relationship?Relationship model
Use the first demo to see how the product organises the relationship, before asking for your own scenarios.
Focus
Find out whether third-party assessments are tied to the third party, the service, the contract, or some mix of these. Follow how services, internal owners, locations, access, contracts, assessments, evidence, issues and reassessment schedules stay linked to each other. If the demo covers several services or contracts for one third party, ask how the separate results are kept and how you'd see the whole relationship at a glance.Watch for
- The supplier can't clearly explain how the pieces fit together
- Third party, service and contract are used as if they're the same thing
- Related information sits on separate screens with no clear link between them
- Separate assessments are combined into one result without explanation
- Important behaviour depends on settings that weren't shown
Carry forwardNote how the product organises this, whether it matches how you actually manage third parties, and which questions still need a closer look.
02 · Does the Portal Support the Third Party Through Its Lifecycle?Third-party portal
Examine whether the portal supports the required exchanges with third parties from onboarding through periodic updates, reassessment, remediation and eventual exit.
Focus
View the questionnaire from the third party's side. Examine onboarding information, delegated sections, saved responses, evidence uploads, clarification, periodic updates, reassessment, remediation and change notification. If an audit report is not ready, follow how the expected date, communication, owner, due date, reminders, later upload and evidence review are retained.Watch for
- Clarification moves into email
- Missing evidence is buried in a comment
- No owner or follow-up date is assigned
- An assessment appears complete while required evidence remains outstanding
- Later evidence is disconnected from the request
- Uploading a document automatically closes the follow-up
- Internal comments are exposed externally
Carry forwardRecord which lifecycle stages and interactions the portal supports, how communication and evidence history are retained, and which activities still rely on email or manual tracking.
03 · How Are Assessment Templates, Scoring and Weighting Applied?Assessment logic
Establish what determines the assessment content and how questionnaire responses contribute to a risk result.
Focus
Ask what is being assessed and how service criticality, sensitivity, access, location, risk tier and other factors select the questionnaire and evidence. Examine conditional questions, answer and section weighting, treatment of unanswered, incomplete and not-applicable responses, internal review, overrides and rationale. Where one third party provides several services, ask how separate results remain traceable.Watch for
- Template-selection rules cannot be explained
- A standard questionnaire contains large irrelevant sections
- Scoring or weighting cannot be readily configured or explained to authorised internal users
- Exceptions cannot be understood
- Missing evidence is treated as accepted evidence
- Evidence submission is confused with approval
- Overrides leave no rationale or audit history
Carry forwardRecord what selects the assessment content, what is scored, where judgement applies and how separate service, contract and third-party-level results are handled.
04 · Is External Risk Intelligence Part of the Required Scope?Risk intelligence
Not every buyer requires external intelligence within the TPRM platform. Where it is required, test both the coverage and the route from information to action.
Focus
Establish the required intelligence types, countries and regions, information depth and update frequency. Ask for an example from an important market using the supplier's demo data. Follow one alert from receipt through relevance review, ownership and action. Where a partner provides the intelligence, ask who supplies it, how established the current connection is, how closely it supports the TPRM workflow and who supports it.Watch for
- Broad coverage claims without regional explanation
- Weak entity or location matching
- High alert volume without a clear review process
- Alerts disconnected from the relevant owner or action
- The partner relationship or integration depth is unclear
- The intelligence shown is outside the intended product scope
Carry forwardRecord the required intelligence categories, regional coverage, update approach, route from alert to action and any reliance on a partner service.
05 · How Should Buyers Examine Fourth-Party Visibility?Fourth parties
Where fourth-party visibility is required, examine the relationship context, information source, shared exposure and route to action.
Focus
Examine how fourth parties connect to direct third parties, services and locations. Ask where the dependency information comes from and whether relationships are declared, inferred or verified. Establish whether common providers can be identified across the third-party population and whether an event can be traced to the relevant services and internal owners.Watch for
- Relationship context is too limited for the buyer's intended use
- Shared providers cannot be identified across third-party records
- The source or basis of a relationship is unclear
- Events affecting a fourth party cannot be traced to the relevant services or owners
Carry forwardRecord the level of visibility shown, where the relationship information comes from and whether the product can identify and support action on shared dependencies.
06 · What Was Proven and What Still Needs Testing?Evaluation evidence
A polished demo should not give an explained capability the same confidence as a completed live workflow.
Focus
Classify each important point as shown live, explained but not shown, supported by other evidence or unresolved. Record whether the outcome depends on configuration, integration, another service or manual work. Where unresolved points could affect fit, use a focused workshop. A configuration walkthrough can also show whether changes to questionnaires, scoring or review frequency suit the team's skills and capacity.Watch for
- Verbal explanations recorded as if they were shown live
- Roadmap items treated as current functionality
- Configuration, integration and custom work treated as interchangeable
- Material gaps hidden by an overall score
- A follow-up workshop arranged without defined questions
Carry forwardPreserve the evidence status, unresolved questions, delivery dependencies and areas requiring further examination. Record what each focused workshop established.
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
Common questions
- Should we send our questions to the supplier before the demo?
Yes. Share a short list of questions and areas of interest in advance so the supplier can allocate time to the topics that matter. For TPRM software, that usually means how the product links a third party to its services and contracts, what the third party sees in the portal, how questionnaires are selected and scored, and, only if you need them, external risk alerts and visibility of the companies your third parties rely on.
The supplier may still follow its standard demo sequence and use its usual demo data. Questions should show where the team wants more explanation, not ask for a tailored show or set the whole running order. Keep anything that needs your own scenario or data for a focused follow-up session, and ask further questions based on what is shown.
- Should we provide our own non-sensitive third-party data for a supplier demo?
No. You should not need to prepare third-party data for the initial demo. Let the supplier use its standard demo environment so the buying team can understand the product's normal structure, terminology and workflow.
However, if your organisation has complex or less common third-party relationships, prepare a brief scenario for discussion. For example, one third party may have multiple contracts covering different services. Use the scenario to ask how the product would represent the relationship, not as data for migration or a tailored demo.
- What should we ask to see when one third party provides several services that have different assessment criteria?
First, ask the supplier to explain whether an assessment is linked to the third party, a service, a contract or a combination, and how separate results contribute to any contract-level or third-party-level view.
Then ask the supplier to show how different service profiles determine the questionnaire, evidence requirements, scoring method and review frequency. Findings and actions should remain connected to the relevant service while remaining visible within the wider third-party relationship.
- How should we test external risk-intelligence coverage during the software evaluation?
If external risk intelligence is required, ask which countries and regions are covered, what types of intelligence are available in each market and whether the depth or update frequency differs.
Where regional coverage is important, ask the supplier to show an example from that market using its existing demo data.
Test coverage separately from workflow. Finding information about a third party does not show how an alert is reviewed and acted upon. A well-designed alert workflow also does not prove that the intelligence source covers the regions and third parties that matter to the buyer.
- Would a demo recording with an artificial intelligence-generated summary be reliable as internal evidence?
A recording and generated summary can support the internal evaluation, but neither should be accepted without review. Consider what the material actually establishes: Was the capability shown live or only explained? Was it part of the standard product, a configured environment or a partner service? Did the summary retain important limitations and qualifications?
Use the recording to verify material points and mark each as shown live, explained or unresolved. Do not mark a capability as shown live simply because the generated summary mentions a relevant term. For example, "fourth parties" may appear in the summary even though the demo did not show how those relationships or shared dependencies are represented.
- When is a focused supplier workshop more useful than another general demo?
Use a focused workshop when one or more unresolved points could affect product fit but cannot be examined properly within the initial demo. The purpose is to explore a defined set of related areas in sufficient depth, rather than repeat the standard product tour.
The workshop can also show how configuration is performed. For example, ask the supplier to change a questionnaire rule, scoring weight or review frequency, and explain who would normally make that change. This helps the buyer judge whether the level of difficulty and ongoing administration suit the team's skills and capacity.
- How can we compare TPRM suppliers when their products use different relationship and assessment models?
Compare how each product represents the same third-party relationship, not just whether it uses the same feature labels. Follow one example across the third party, its services, contracts, assessments, evidence, issues and review schedules. Check where each risk result is stored, how separate service-level outcomes roll up, and whether the full relationship remains understandable when something changes.
Then test the model against your own operating environment. Does it reflect how you currently manage the third-party lifecycle, or would your team have to change its process to fit the software?
Examine the supplier portal from the third party's perspective as well. Are the questions, evidence requests and follow-up steps straightforward enough for the types of service providers you work with, or would the process be unnecessarily complex for them?
The goal is to compare both the underlying data model and how practical it would be for your organisation and third parties to use it in day-to-day operations. The right level of portal complexity will depend on the types of third parties you work with, their capabilities and the information you need them to provide.