Use the recordings to generate tests, not to award supplier scores. The following workshop is our proposed method; it is not a process claimed by any speaker.
Step 1: Agree the first operational problem
Before watching, write down one problem narrowly enough to demonstrate. Examples might include assigning overdue remediation, collecting recurring control evidence or consolidating a particular risk assessment across business units.
Record the process owner, the users affected and the decision the resulting report must support. Keep later ambitions in a separate list.
Step 2: Separate what a source says from what procurement must prove
Use four columns:
| Note type | What belongs here | How to use it |
|---|---|---|
| Source statement | What the transcript or publisher description actually says | Retain the link and attribution |
| Buyer inference | Why that statement might matter to your organisation | Validate with the affected process owner |
| Demonstration request | The task a supplier should perform | Apply the same scenario across the shortlist |
| Acceptance evidence | The result, limitation and configuration observed | Record demonstrated, partly demonstrated or untested |
Do not convert a customer story into a universal implementation assumption. Equally, do not record an undemonstrated capability as absent: it remains unproven until investigated.
Step 3: Build a common test pack
Our recommended pack should ask each shortlisted supplier to:
- [ ] Import a small synthetic dataset containing duplicate identifiers, missing owners and a broken relationship.
- [ ] Explain which defects are rejected, corrected or accepted, and retain the reconciliation record.
- [ ] Route an overdue action through escalation and reassignment.
- [ ] Restrict an evidence attachment while allowing an authorised user to see the associated control.
- [ ] Demonstrate a failed integration and the recovery process.
- [ ] Let a buyer administrator change a field, routing rule and report.
- [ ] Export linked records, attachments and relevant history for inspection.
- [ ] Identify which demonstrated elements require extra modules, services or custom work.
- [ ] Run any proposed AI feature against both sufficient and deliberately insufficient evidence.
- [ ] Show how a reviewer rejects an AI recommendation without losing the decision record.
These are proposed acceptance scenarios—not claims that the recordings demonstrate them or that any listed platform passes them.
Step 4: Make the cost questions operational
For a three-year GRC total cost of ownership comparison, request separate buyer-specific estimates for:
| Cost area | Question to put to the supplier or partner |
|---|---|
| Subscription scope | Which user categories, modules, entities and environments are included? |
| Implementation | Which decisions and data-cleansing tasks remain the buyer’s responsibility? |
| Integration | Who builds, monitors and repairs each connection? |
| Administration | Which changes can our administrators make, and what training is needed? |
| Dual running | What assumptions underpin the proposed cutover and legacy retirement dates? |
| Renewal and exit | What can be exported, in what form, with what assistance and charges? |
Leave unanswered items marked unknown, rather than entering zero. None of the reviewed media establishes a comparable enterprise GRC price benchmark for your shortlist.