GRC platform RFPs tend to ask whether a product "supports ISO 27001" or "automates evidence", every bidder answers yes, and the real differences in mapping quality, connector permissions, audit trail and exit terms only appear a year into the contract. This template gives you a ready-to-issue request for proposal for a governance, risk and compliance (GRC) platform, also sold as integrated risk management (IRM) or compliance automation, with numbered requirements that a bidder must evidence and an evaluation panel can score. It covers control libraries and framework mapping, automated evidence, the risk register, policy and exception management, third-party risk, audit workflow, continuous control monitoring, AI governance, the platform's own security, data and exit, commercials, weighted scoring and a pre-award test plan. It is vendor-neutral and written for CISOs, GRC leads, internal audit, procurement and legal teams. For how the market works and what good looks like, read the GRC Platform Buyer's Guide first; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [framework] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example GRC-EVD-03) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (weighted 0 to 5) or I informational (not scored). Keep M items to the few you would genuinely walk away over.
- Numbers, periods and weights in brackets are illustrative, not benchmarks. Set them from your obligations and risk appetite before issue, and do not change them after responses arrive.
- Agree section 4.9 (data and exit) and section 7 (commercials) with legal, privacy and procurement before issue. Agree section 4.6 with internal audit and, where relevant, your external auditor.
- Issue sections 1 to 8 to bidders. The implementation guidance is for the evaluation panel only. Ask for responses in a spreadsheet with one row per requirement ID and a column for the evidence reference (document, screenshot or demo timestamp).
1. Purpose and scope
[Organisation] invites proposals for a [three]-year subscription to a GRC platform, with implementation services, to replace [spreadsheets / current tool] and support [number] frameworks across [number] legal entities.
- In scope: control library and framework mapping; automated evidence collection; risk register and treatment; policy, attestation and exception management; [third-party risk]; internal and external audit workflow; continuous control monitoring; [AI system inventory and assessment]; reporting and API; implementation, data migration and training.
- Out of scope: [audit or certification services]; [legal advice on regulatory interpretation]; [security monitoring, provided by our SOC].
- Drivers: [first SOC 2 Type 2 report by date]; [ISO/IEC 27001:2022 certification or transition]; [regulatory obligation, such as sector regulation or DORA]; [board request for enterprise risk reporting]; [audit findings on evidence quality].
2. Organisation background
| Item | [Organisation] value |
|---|
| Frameworks and versions in scope | [for example ISO/IEC 27001:2022, SOC 2, NIST CSF 2.0, NIST SP 800-53 Rev. 5, PCI DSS v4.0.1, ISO/IEC 42001:2023, contractual schedules] |
| Legal entities, business units and regions | [number and list] |
| Users by role | [number] administrators, [number] control owners, [number] risk owners, [number] auditors (internal and external), [number] suppliers |
| Current controls, risks and policies | [number] controls, [number] risks, [number] policies, held in [tool or format] |
| Identity provider and SSO | [name]; SCIM provisioning [required / preferred] |
| Systems to connect for evidence | [cloud providers and account counts], [HR system], [ticketing], [endpoint management], [vulnerability scanner], [code repositories], [SIEM] |
| Suppliers in third-party risk scope | [number], of which [number] critical |
| Data residency and retention | [permitted hosting regions]; audit evidence retained for [period] |
3. Instructions to bidders
- Timeline: RFP issued [date]; questions by [date]; answers shared with all bidders [date]; responses due [date, time, time zone]; scripted demonstrations [dates]; proof of concept [dates]; award [date].
- Contact: [name, email]. Other contact with [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state available now (generally available, in the version offered), configuration (no code), custom development (state effort and who maintains it), third-party product (name it), roadmap (give a date; roadmap items score 0) or not offered.
- Evidence: state where each answer is evidenced. Attach a sample OSCAL export, the platform's current independent assurance report, the sub-processor list, a sample connector permission sheet and your standard data processing agreement.
4. Requirements
4.1 Control library and framework mapping
| ID | Requirement | Type |
|---|
| GRC-LIB-01 | Provide content for each framework in section 2 at the stated version (for example the ISO/IEC 27001:2022 Annex A control set, not the 2013 set). State how quickly revised framework versions are delivered. | M |
| GRC-LIB-02 | Support a common control set mapped once to many frameworks, with mappings visible, editable and attributable to an author and date. | M |
| GRC-LIB-03 | Import and export catalogues, profiles and control mappings in NIST OSCAL (JSON or XML). Demonstrate import of the official NIST SP 800-53 Rev. 5 catalogue. | S |
| GRC-LIB-04 | Keep framework versions side by side during a transition, so an audit in progress can stay on the old version while new work uses the new one. | S |
| GRC-LIB-05 | Produce an ISO/IEC 27001 Statement of Applicability with inclusion and exclusion justifications, and a system security plan in OSCAL where [Organisation] uses NIST frameworks. | S |
| GRC-LIB-06 | State who authors framework content and mappings, how they are quality checked, and whether customers may export and keep them at contract end. | I |
4.2 Evidence collection and integrations
| ID | Requirement | Type |
|---|
| GRC-EVD-01 | Native connectors for each system in section 2. For each, state the data collected, the collection schedule and whether it is generally available. | M |
| GRC-EVD-02 | Every evidence item records source system, collection time, collecting identity and the control and test it supports, and cannot be altered without a logged new version. | M |
| GRC-EVD-03 | Alert owners when a connector fails, when evidence is older than [period], or when a sample falls outside the audit period. | S |
| GRC-EVD-04 | Manual evidence upload with request, reminder and approval workflow for controls that cannot be automated. | S |
| GRC-EVD-05 | A documented API and webhooks to push evidence from systems without a native connector. | S |
4.3 Integration identities
Each connector is a non-human identity with read access, and sometimes write access, to [Organisation]'s most sensitive systems. These requirements carry the same weight as features.
| ID | Requirement | Type |
|---|
| GRC-NHI-01 | Provide a permission sheet for every connector: scopes, roles or API permissions requested, and whether each is read-only. Connectors needing global administrator, owner or write rights must justify each permission. | M |
| GRC-NHI-02 | Support federated or short-lived credentials (for example cloud role assumption with an external ID, workload identity federation or OAuth with refresh token rotation) instead of static keys, wherever the target system allows it. | S |
| GRC-NHI-03 | Exportable inventory of all connectors with owner, credential type, creation date, last use and expiry; alerts before expiry. | S |
| GRC-NHI-04 | Credentials stored encrypted, never shown again after entry, and revocable by [Organisation] in one action per connector. | M |
See the Service Account Security Guide and the SaaS and OAuth App Governance Guide for the controls GRC-NHI-01 to 04 should reflect.
4.4 Risk register and treatment
| ID | Requirement | Type |
|---|
| GRC-RSK-01 | Configurable risk scoring (scales, matrices, appetite thresholds) with inherent, current and target risk, treatment plans, owners and review dates. | M |
| GRC-RSK-02 | Risks linked to controls, assets, suppliers, issues and findings, so a failed control shows its effect on risk. | S |
| GRC-RSK-03 | Roll-up of risks from system to business unit to enterprise level, in a way consistent with the cybersecurity risk register approach in NIST IR 8286 Rev. 1. | S |
| GRC-RSK-04 | Optional quantitative analysis with monetary loss ranges alongside qualitative scores. State the method and its assumptions. | [S or I] |
| GRC-RSK-05 | Risk acceptance workflow with approver authority levels, expiry and automatic re-review. | S |
See the Cyber Risk Quantification Guide before deciding whether GRC-RSK-04 is scored.
4.5 Policy, attestation and exceptions
| ID | Requirement | Type |
|---|
| GRC-POL-01 | Policy versioning, approval workflow and publication, with policy statements mapped to controls. | S |
| GRC-POL-02 | Attestation campaigns targeted from identity provider groups, with completion reporting. | S |
| GRC-POL-03 | Exception requests linked to the policy and control, with compensating controls, approver, risk link and mandatory expiry. | M |
4.6 Audit workflow
| ID | Requirement | Type |
|---|
| GRC-AUD-01 | Audit plans, request lists and read-only auditor workspaces scoped to an audit period, without exporting evidence by email. | M |
| GRC-AUD-02 | Sampling support for operating effectiveness testing over a period (for example a SOC 2 Type 2 review period). | S |
| GRC-AUD-03 | Findings and plans of action and milestones (POA&M) tracked to closure, with owners and due dates, exportable in OSCAL POA&M where required. | S |
| GRC-AUD-04 | Segregation of duties: the same user cannot prepare and approve evidence or tests for the same control. State how this is enforced. | S |
| GRC-AUD-05 | If you bundle, refer or are affiliated with audit firms, describe the relationship and how [Organisation]'s free choice of auditor and the auditor's independence are preserved. | M |
4.7 Continuous control monitoring and reporting
| ID | Requirement | Type |
|---|
| GRC-CCM-01 | Automated tests with visible test logic, pass, fail and exception states, and history retained for at least [period] to cover audit periods. | M |
| GRC-CCM-02 | Test frequency configurable per control in line with [Organisation]'s monitoring strategy (the approach in NIST SP 800-137 and SP 800-53 CA-7). | S |
| GRC-CCM-03 | A failed test can open a ticket in [ticketing system] and close it when the test passes again. | S |
| GRC-RPT-01 | Board, executive and regulator views with trends over time and drill-down to the underlying evidence. | S |
| GRC-RPT-02 | All data reachable through a documented API, with scheduled exports to [data platform]. | S |
See the Audit Evidence and Continuous Controls Monitoring Guide.
4.8 Third-party risk and AI governance (optional modules)
| ID | Requirement | Type |
|---|
| GRC-TPR-01 | Supplier inventory with tiering, questionnaires, document requests (SOC 2 reports, ISO/IEC 27001 certificates), issue tracking and review scheduling by tier. | [S or delete] |
| GRC-TPR-02 | Supplier portal with SSO or enforced MFA for supplier users, and no supplier access to other suppliers' data. | [M or delete] |
| GRC-AI-01 | AI system inventory with owners, risk tiering and impact assessments mapped to ISO/IEC 42001:2023 and the NIST AI RMF functions (Govern, Map, Measure, Manage). | [S or delete] |
| GRC-AI-02 | If the platform uses AI features (for example drafting control narratives or answering questionnaires), state which models process [Organisation] data, where, whether data is used for training, and how outputs are marked for human review. | M |
If supplier risk is a major driver, use the TPRM Platform RFP Template for a fuller section; for AI governance tooling, use the AI Governance Platform RFP Template.
4.9 Platform security, data and exit
| ID | Requirement | Type |
|---|
| GRC-SEC-01 | SSO through [identity provider] with enforced MFA for all users, SCIM provisioning and role-based access down to entity and framework level. | M |
| GRC-SEC-02 | Customer-visible, exportable audit log of changes to controls, mappings, risks, evidence, users and connector settings, retained for [period]. | M |
| GRC-SEC-03 | Current independent assurance for the platform itself (for example a SOC 2 Type 2 report or ISO/IEC 27001 certificate with a scope covering the service offered), a published vulnerability disclosure process and incident notification to customers within [hours]. | M |
| GRC-SEC-04 | Hosting in [regions], named sub-processors with locations, encryption at rest and in transit, and customer-set retention. State any transfers outside [jurisdiction] and the transfer mechanism. | M |
| GRC-SEC-05 | At exit, export of controls, mappings, evidence files with metadata, risks, policies, audit history and logs in open formats (OSCAL, CSV, JSON or API), followed by deletion within [days] and written confirmation. | M |
5. Implementation, team and references
- Plan: a phased implementation plan for [frameworks] with milestones, [Organisation] effort by role and the data migration approach for existing controls and risks.
- Team: named implementation lead and the experience of the team with [frameworks] and organisations of similar size.
- Partners: any implementation partner or subcontractor who may access [Organisation] data, and what they do.
- References: [two or three] customers of similar size or sector, at least one of whom has completed an external audit using the platform.
6. Contract terms
- Term and exit: [term]; exit assistance and the export in GRC-SEC-05 at no extra cost.
- Service levels: availability target, support hours and response times, and service credits.
- Content updates: framework updates included in the subscription, with delivery commitments from GRC-LIB-01.
- Data protection: a data processing agreement covering sub-processors, transfers, breach notification and deletion.
7. Commercials
| Cost element | What to state |
|---|
| Subscription | The unit charged (users, modules, frameworks, entities, connectors or suppliers) and the price per unit |
| Growth | Cost of adding one framework, one legal entity, [100] suppliers and [50] users |
| Implementation | Fixed price or rate card, with assumptions |
| Content and connectors | Any charges for framework content, premium connectors or API volume |
| Training and support | Included hours and tiers |
| Renewal | Cap on price increases |
8. Evaluation method and pre-award tests
[Organisation] will check mandatory requirements, then score the rest using these weights (illustrative; set your own before issue):
| Criterion | Weight | Evidence |
|---|
| Evidence and integrations, including integration identities (4.2, 4.3) | [25%] | Permission sheets, proof of concept results |
| Control library and mapping (4.1) | [20%] | OSCAL import and export test, mapping review |
| Risk, policy and audit (4.4 to 4.6) | [20%] | Scripted demonstration, mock audit |
| Monitoring and reporting (4.7) and optional modules (4.8) | [10%] | Demonstration with test history |
| Platform security, data and exit (4.9) | [10%] | Assurance report, DPA, exit test |
| Cost over the term (7) | [15%] | Pricing modelled on the growth scenario in section 7 |
Scores use 0 to 5: 0 not offered or roadmap only; 1 needs custom development; 3 meets the requirement through configuration; 5 exceeds it and is evidenced. Shortlisted bidders will complete these tests in a tenant loaded with [Organisation] data, not a demo tenant:
- Import our existing control set and [two] frameworks; export them again in OSCAL and confirm nothing is lost.
- Connect [one cloud account, the identity provider and the ticketing system] using dedicated read-only integration identities we create, recording every permission requested.
- Break three controls on purpose (for example a user without MFA, a public storage bucket, an overdue access review) and time how long the platform takes to flag each and open a ticket.
- Give an internal auditor a read-only workspace and a [20]-item request list; count requests answered without manual exports.
- Revoke every integration credential at the end and confirm the connectors stop collecting, then request written confirmation of test data deletion.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Start with obligations: fill in section 2 with every framework, version and contractual schedule before drafting requirements; GRC-LIB-01 removes bidders whose content is out of date.
- Script the demonstrations: send the same script and data to every shortlisted bidder and score live, against requirement IDs, so polished presentations do not outscore evidence.
- Treat connectors as access requests: have identity or cloud security review each GRC-NHI-01 permission sheet as they would any privileged access request. A GRC tenant with broad read access is a high-value target.
- Size matters: a scale-up seeking its first certification can drop GRC-RSK-03 and GRC-RSK-04 and weight evidence more heavily; a regulated group with several entities should keep them and add multi-entity reporting to GRC-RPT-01.
- Model total cost: price the growth scenario in section 7 for each bid. Per-framework or per-supplier pricing can discourage good coverage later.
- Carry IDs into the contract: make scored answers contractual commitments, and plan the rollout with the GRC platform rollout playbook.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|
| Control assessment, evidence and monitoring (4.2, 4.7) | CA-2, CA-7, PM-31 | GV.OV-03, ID.IM-01 |
| Risk register and treatment (4.4) | RA-3, PM-9 | GV.RM-01, GV.RM-03 |
| Policy and exceptions (4.5) | PL-2 | GV.PO-01 |
| Findings and POA&M (4.6) | CA-5 | ID.IM-01 |
| Integration identities and platform access (4.3, 4.9) | AC-6, AU-2, AU-11 | PR.AA-05 |
| Supplier requirements and assessment (4.8, 4.9, 6) | SA-4, SA-9, SR-6 | GV.SC-05, GV.SC-07 |
NIST SP 800-37 Rev. 2 describes the categorise, select, implement, assess, authorise and monitor activities that a GRC platform records for each system; if you run that process, ask bidders to show where each step lives in the tool. For definitions of the terms used here, see the GRC and Cyber Compliance Glossary.
Standards and references
Related NHI Mgmt Group resources: GRC Platform Buyer's Guide · GRC platform rollout playbook · Top 10 GRC Mistakes · Security Vendor Evaluation and RFP Guide · How to Read a SOC 2 Report Guide