Loading page…
Vendor-neutral questions that reveal what a scripted demonstration will not — including the ones we expect prospective buyers to ask us.
Anyone running a GRC platform selection: CISOs, heads of risk, compliance managers, internal audit leads and the procurement teams supporting them.
Send the questions in advance and ask for them to be answered in the demonstration against your own frameworks rather than a sample tenant. Where an answer is 'on the roadmap', treat it as 'not available' for evaluation purposes and record the date given.
Dabster Group develops SecureGRC, so we are not a neutral party in a platform selection. This checklist is written to be vendor-neutral and includes questions on which SecureGRC's own answer is a limitation — see the platform boundaries stated on our capabilities page.
The control model determines whether adopting a new framework is a mapping exercise or a fresh implementation. This is the highest-consequence area and the least often examined properly.
Ask to see a single control mapped to requirements from two different frameworks, tested once, with the evidence satisfying both. If controls are held per framework, effort multiplies with every standard adopted.
Whether requirements are authored centrally by the vendor, imported by the customer, or both — and what happens when a standard is revised. Ask specifically what the upgrade path was for ISO/IEC 27001:2022.
When a control is mapped to a requirement, is the reasoning and approver recorded? Without it, the mapping cannot be defended when a standard changes or an auditor challenges it.
Ask for the view that shows requirements with no control behind them. A platform that can only show what is mapped cannot tell you what is missing.
When a control changes, is the prior version retained with the evidence collected under it? Audit periods span control changes.
Evidence handling determines whether audit preparation is retrieval or a project. Test it with a real question rather than a feature list.
Ask to start from a framework clause and reach the evidence in as few steps as possible. Evidence stored in a document library, unlinked, produces the same preparation burden as a shared drive.
Who changed what, when, and what the prior value was — for risks, controls, findings and evidence. Ask to see the trail on a record, not a description of it.
Whether files are accessed through permission-checked endpoints or via storage URLs. A URL that works without a session is a URL that works for anyone who obtains it.
For access reviews particularly: does the record show access as it stood when it was reviewed, or as it stands now? Only the former is defensible.
The difference between a platform and a database is whether it pursues outstanding work without someone remembering to chase.
Ask to see the view an ordinary control owner logs into. If it does not show what is theirs and what is due, a person will remain the routing mechanism.
For control tests, reviews, attestations and training. Ask what happens when an owner is on leave and whether delegation is supported.
Whether an action closes on assertion or on evidence. Closure on assertion is how findings recur.
Whether intake is open to the wider organisation with a triage step, or restricted to the risk function. Restricted intake produces a register that reflects one team's view.
A GRC platform holds your findings, gaps and unremediated risks. Its own access model deserves the scrutiny you would apply to a system of record.
Whether rights are per module or per action within a module, and whether a user can hold several roles. Coarse permissions force over-provisioning.
Whether a department head sees their department and a control owner sees their controls, or everyone with a role sees everything.
Ask where isolation is enforced — in query construction, in a middleware layer, at the database — and what prevents a missing filter from exposing another tenant's data.
Whether permission and configuration changes are recorded and reviewable. Administrative change is the least visible and highest-consequence activity in the system.
Ask what the platform does not integrate with. Vendors answer the first question expansively and the second precisely.
SSO, directory synchronisation, provisioning — and specifically which protocols and which identity providers have been implemented in production rather than are theoretically supported.
Be specific about your own estate. Ask directly whether entitlement data can be pulled from your identity provider or service management tool, because 'access reviews' means very different things depending on the answer.
Whether integration credentials are managed, scoped and revocable, and whether outbound events are available for your own automation.
Export format, completeness, and whether it includes evidence files and audit history. Ask at evaluation, not at renewal.
The questions that determine whether the platform survives its second year in your organisation.
Which phases, whose time from your side, and what has to be decided before configuration begins. A platform rollout without an agreed operating model behind it is the most common way these projects stall.
Channels, hours, response expectations, and who answers a methodology question as opposed to a software question.
Ask for a security overview covering authentication, authorisation, isolation, encryption in transit, logging, secure development and vulnerability handling. Ask what independent assurance exists, and treat a straight answer about what is not held as a positive signal.
A vendor that names its boundaries is easier to plan around than one that answers every question affirmatively. Record roadmap commitments with dates.
Which dimensions scale the price — users, modules, entities, frameworks — so you can model the cost of the programme you intend to build rather than the one you are starting with.
Next step
Send us what the assessment surfaced and we will give you a view on which items are genuine blockers, which matter less than they look, and what closing them realistically takes.