Most GRC demos look the same: tidy dashboards, green tiles, an AI assistant. The differences that matter don't show up in a tile; they show up the day an auditor asks a hard question. These are the ten questions to ask before you sign, written for the person who'll have to answer for the choice.
1. How is my data kept separate from other customers'?
“Multi-tenant” means different things. Ask how your data is logically separated, whether one tenant's data can ever be reached from another, and whether that separation is enforced underneath the application or left to a query someone has to remember. The first is an architecture; the second is a hope. (It's the same segregation a SOC 2 report and a CAIQ/SIG questionnaire test for.)
2. Is evidence enforced, or just attached?
Can a requirement be marked “implemented” without valid, current evidence? If yes, your posture is a collection of assertions. The systems worth buying gate status on evidence and revert a control when its evidence goes stale.
3. Is the audit trail immutable, and can an auditor query it?
Ask how the audit log is protected from modification. “We log everything” is not the same as “the application has no permission to alter history.” Then ask whether an external auditor could query that trail directly, without the vendor in the loop.
4. How is segregation of duties enforced?
Maker/checker should be a constraint on the specific item, the approver cannot be the author, enforced by the system, not a role you label and trust. Ask them to show you a blocked self-approval.
5. Who keeps the regulatory content current?
A catalog of frameworks is only valuable if someone maintains it. When a new circular lands, does the vendor map it once and push it to you, or do you reconfigure it yourself? The answer is the difference between a managed feed and a very expensive spreadsheet.
6. What happens when the auditor arrives?
Audits are where GRC platforms earn their keep. Can you give an external auditor or examiner a scoped, time-boxed workspace where they self-serve evidence, without handing them access to your live data? Or does it still come down to emailed ZIP files?
7. Does it connect to the systems I already run?
Auto-collected evidence beats screenshots, but integrations should be read-only and fail-closed: a broken connection should raise an integration-health issue, never silently flip a control to red. Ask what happens when a token expires.
8. Can the vendor evidence its AI claims?
Everyone ships “agents” now. The question is whether each autonomous action is logged, routed through the same approvals as a human, and grounded in real data rather than a guess. Overstated AI is itself an audit risk, be wary of any claim the vendor can't demonstrate.
9. How fast can I actually be ready?
“Days to onboarded posture” is plausible only if the catalog pre-populates your programme. Ask to see a tenant go from empty to a mapped framework with owners and evidence slots, live, in the session.
10. Would this platform pass my own security review?
You are about to put your control evidence inside someone else's system. Hold them to the standard you hold yourself: data segregated by tenant, an append-only audit trail, break-glass-only vendor access, sealed secrets, SSO. A GRC tool that can't pass its own review has no business running yours.
The feature list tells you what a platform does on a good day. These questions tell you what it does on the day you're audited.
Bring this list to your next demo. The vendors building a system rather than a dashboard will answer each one plainly, and show you, not tell you.