Most governance, risk and compliance (GRC) platforms are bought to escape spreadsheets, then fail because evidence is still collected by hand and the risk register still lives in a slide deck. The category now spans control libraries, automated evidence collection, risk registers, policy management, third-party risk, audit workflow and, increasingly, AI governance. Products sold as "GRC", "integrated risk management (IRM)" or "compliance automation" overlap heavily, so the label tells you little: the modules, the integrations and the data model decide whether the platform fits. This vendor-neutral buyer's guide is for CISOs, GRC leads, internal audit and risk teams who are writing requirements, running an RFP or replacing a platform. It covers what to define first, the criteria to score, the questions that expose weak answers, and a proof of concept you can run in four to six weeks.
Key takeaways
- Start from your obligations, not the module list. Write down the frameworks, regulators, customers and internal policies you must evidence, then buy the platform that maps them with the least manual effort.
- Machine-readable controls matter. Ask whether control catalogues, mappings and system security plans import and export in NIST OSCAL (JSON, XML or YAML), so your control data is not locked into one product.
- Evidence automation is only as good as the connectors. Test them against your real cloud, identity, ticketing and endpoint stack, and check how failed or stale evidence is flagged.
- The platform holds privileged machine credentials. Every integration is a non-human identity with read access, sometimes write access, to your most sensitive systems. Score the platform's own security as hard as its features.
- Plan the exit before you sign. Confirm you can export controls, evidence, risks and audit history in open formats, and agree what happens to your data at contract end.
Define requirements
A GRC platform encodes your operating model. Before talking to vendors, agree the following internally and write them into the RFP.
- Obligations in scope: list every framework and its version, for example ISO/IEC 27001:2022, SOC 2 trust services criteria, NIST CSF 2.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1, sector regulation and contractual security schedules. Version matters: a library still built on the 2013 Annex A creates rework.
- Risk method: decide whether you score risk qualitatively (likelihood and impact matrices), quantitatively (loss ranges in money, for example FAIR-style analysis), or both. NIST IR 8286 Rev. 1 describes how cybersecurity risk registers roll up into enterprise risk management; the platform should support that roll-up rather than a flat list. See the Cyber Risk Quantification Guide.
- Users and owners: how many control owners, risk owners, auditors and suppliers will log in, and whether they authenticate through your identity provider.
- Systems to integrate: cloud providers, identity provider, HR system, ticketing, endpoint management, vulnerability scanners, code repositories and the SIEM.
- Data constraints: where evidence may be stored and processed, retention periods for audit evidence, and any rules on transfers outside your jurisdiction (for example GDPR Chapter V).
- AI scope: whether you need an AI system inventory and assessments against ISO/IEC 42001:2023 or the NIST AI RMF now, or only on the roadmap. See the AI Governance Guide.
Size changes the answer. A scale-up chasing its first SOC 2 report usually needs evidence automation and an auditor-friendly workflow more than a configurable risk engine. A regulated enterprise with several legal entities needs multi-entity hierarchies, configurable workflows, quantification and strong segregation of duties inside the tool. Many large organisations run both: an enterprise platform for risk and audit, and lighter automation for product certifications.
| Framework or source | What the platform must support | Check during evaluation |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 2022 control set (93 controls in four themes), Statement of Applicability, internal audit and management review records | SoA export with justifications; mapping from the 2013 control set if you are migrating |
| SOC 2 | Trust services criteria (security, availability, processing integrity, confidentiality, privacy), Type 1 and Type 2 evidence periods | Auditor read-only access; sampling support over the review period |
| NIST CSF 2.0 | Six functions including Govern; categories such as GV.RM, GV.SC and ID.RA; current and target profiles | Profile gap analysis and reporting by function |
| NIST SP 800-53 Rev. 5 | Control and enhancement IDs (for example CA-7, RA-3, SR-6), baselines, POA&M (CA-5) | Import of the official OSCAL catalogue, including release 5.2.0 changes |
| ISO/IEC 42001 and NIST AI RMF | AI management system controls; Govern, Map, Measure, Manage functions; generative AI profile (NIST AI 600-1) | AI use case register linked to risks and controls |
Evaluation criteria
Weight these criteria to your requirements. An illustrative split for a first platform is 30% evidence and integrations, 20% control library and mapping, 20% risk, 15% platform security and data, 15% everything else; adjust it rather than copying it.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Control library and mapping | Common control set mapped once to many frameworks; versioned libraries; OSCAL catalogue, profile and control mapping import and export | Mappings you cannot inspect or edit; no version history when a framework changes |
| Evidence collection and integrations | Native connectors for your cloud, IdP, HR, ticketing and endpoint tools; scheduled pulls with timestamps; evidence linked to the control and test it supports | "Integration" means a CSV upload; no alert when a connector fails or evidence goes stale |
| Risk register and quantification | Configurable scoring, inherent and residual risk, treatment plans, risk appetite thresholds, roll-up from system to enterprise level, optional loss-range quantification | Fixed 5x5 matrix only; risks not linked to controls or assets |
| Policy management | Version control, approval workflow, attestation campaigns, exception requests with expiry, mapping of policy statements to controls | Policies stored as attachments with no link to controls or exceptions |
| Third-party risk | Supplier inventory, tiering, questionnaires, document requests, review of SOC 2 reports and ISO certificates, issue tracking to closure | Questionnaires with no tiering or follow-up; supplier portal without SSO or MFA |
| Audit workflow | Audit plans, request lists, auditor workspaces, sampling, findings and POA&M tracking, segregation between preparers and reviewers | Auditors must be sent exports by email; no evidence of who changed what |
| Continuous control monitoring | Automated tests run on a schedule with pass, fail and exception states; history kept for audit periods, in line with the ISCM approach in NIST SP 800-137 and CA-7 | Dashboards that show "green" without the underlying test logic |
| AI governance modules | AI system inventory, risk tiering, impact assessments, mapping to ISO/IEC 42001 and NIST AI RMF, links to model and data owners | An AI questionnaire bolted on with no inventory or ownership |
| Reporting | Board and regulator views, trend over time, drill-down to evidence, scheduled exports, API access to all data | Static PDF reports; data not reachable through an API |
| Data residency and platform security | Named hosting regions, customer-controlled retention, encryption at rest and in transit, SSO and enforced MFA, customer-visible audit logs, current independent assurance for the platform itself | Unclear sub-processors; no tenant audit log; shared admin accounts |
Integration credentials are privileged non-human identities
To collect evidence, the platform holds API keys, OAuth tokens, service principals and cloud roles for your IdP, cloud accounts, code repositories and HR system. A compromised GRC tenant can therefore read configuration from almost everything you own. This maps directly to the OWASP Non-Human Identities Top 10: NHI5:2025 Overprivileged NHI, NHI7:2025 Long-Lived Secrets, NHI2:2025 Secret Leakage and NHI3:2025 Vulnerable Third-Party NHI. Require read-only scopes by default, short-lived or federated credentials (for example cloud role assumption with an external ID or workload identity federation rather than static access keys), a named owner for each connector, rotation, and a connector inventory you can export. The Salesloft Drift breach showed how OAuth tokens held by one integrated SaaS product opened hundreds of customer tenants. See the SaaS and OAuth App Governance Guide and the Service Account Security Guide.
Questions to ask vendors
- Can you import the official NIST SP 800-53 Rev. 5 OSCAL catalogue and export our controls, mappings and system security plan in OSCAL? Show it, do not describe it.
- When a framework is revised, how are library updates delivered, how do you show what changed, and can we stay on the old version during an audit cycle?
- For each connector we need, which permissions does it request, is it read-only, and does it use federated or short-lived credentials instead of static keys?
- Where are our evidence files and metadata stored, which sub-processors handle them, and can we choose the region and retention period?
- How do you show an auditor that a piece of automated evidence is complete, unaltered and collected within the review period?
- How does the risk register roll risks up from systems to business units to the enterprise, and can risks carry monetary loss ranges as well as scores?
- If your product bundles or recommends audit firms, how is the auditor's independence preserved? AICPA has publicly warned that SOC services "should be thoroughly evaluated by service organizations and CPA firms".
- What independent assurance covers your own platform, when was it issued, and what security incidents have you disclosed?
- What does the pricing model count (users, modules, frameworks, entities, connectors or suppliers), and what happens to cost when we add a framework or a subsidiary?
- At contract end, what do we receive, in which formats, and when is our data deleted?
Red flags
- Framework mappings presented as proprietary content that you cannot export or audit.
- Connectors that need global administrator or owner rights, or that only work with long-lived API keys.
- "Continuous monitoring" that is a daily screenshot or a dashboard with no test history.
- Promises of certification in a fixed number of days, or an auditor relationship you cannot choose freely.
- No customer-visible audit log of who changed controls, risks, evidence or connector settings.
- Vague answers on data location, sub-processors or retention, or no published vulnerability disclosure process.
- Pricing that rises sharply per framework or per supplier, which discourages good coverage.
Proof of concept
- Scope it: pick two frameworks you actually report against (for example ISO/IEC 27001:2022 and SOC 2), one cloud account, your IdP, your ticketing system and ten suppliers. Agree pass criteria and weights before the first demo.
- Load your own data: import your existing control set and risk register, not the vendor's demo tenant. Time how long mapping and clean-up take.
- Connect with least privilege: create dedicated, read-only integration identities with named owners and expiry. Record every permission requested. Never reuse an administrator's personal token.
- Test evidence end to end: deliberately break three controls (for example an IdP user without MFA, a public storage bucket, an overdue access review) and measure how long the platform takes to flag each one and whether the evidence trail is clear.
- Run a mock audit: give an internal auditor a read-only workspace and a sample request list. Score how many requests are satisfied without manual exports.
- Exercise risk and suppliers: create a risk, link it to controls and an asset, set a treatment plan and roll it up; send one supplier questionnaire through to closure.
- Test the exit and roll back: export everything in the formats promised (OSCAL, CSV or API), revoke every integration credential, confirm the connectors stop working, and request written confirmation of tenant data deletion.
Measure the trial with a few numbers you can keep tracking after go-live: percentage of controls with automatically collected evidence, time to assemble an audit request list, mean time to detect a failed control, number of stale or failed connectors, and age of open POA&M items and policy exceptions.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Cyber Risk Quantification Guide · AI Governance Guide · Identity Security Metrics Guide · NHI Security Platform Buyer's Guide