# Stage 4: What belongs in an enterprise GRC software requirements checklist and RFP?

**Write requirements as observable behaviour, with an owner and acceptance method.** Avoid requests such as “supports enterprise risk” unless followed by a specific workflow.

### What is a usable requirement format?

| Field | Example |
|---|---|
| Requirement ID | REM-014 |
| Business outcome | An overdue high-priority action receives accountable escalation |
| Scenario | The owner misses the due date and then requests an extension |
| Required behaviour | Preserve the original date, record the reason, route approval and update reporting without hiding lateness |
| Priority | Mandatory for release one |
| Owner | Head of Compliance |
| Acceptance | Demonstrate with supplied synthetic records and retain the resulting history |
| Supplier response | Supported configuration, custom development, third party, roadmap, not demonstrated or unavailable |
| Commercial dependency | Identify module, licence, integration and services implications |

Include requirements for data, security, reporting, administration, integration, migration and exit—not just end-user functions.

### What should the RFP pack contain?

Prepare these eight documents:

1. Scope charter and explicit exclusions.
2. Process diagrams and decision rules.
3. Requirements workbook.
4. Data inventory and redacted sample.
5. Architecture and interface register.
6. Demonstration script and acceptance criteria.
7. Commercial response workbook.
8. Draft delivery, support and exit requirements.

Request separate prices for the first release, optional later phases and ongoing support. Require assumptions and buyer responsibilities beside every services estimate.

A recent public example shows why scope discipline matters: EPB’s August 2026 GRC solicitation sought internal audit, enterprise risk, compliance and third-party management in one procurement. That demonstrates the breadth of that buyer’s requirement, not that every buyer should launch all those workflows together. ([business.epb.com](https://business.epb.com/competitive-sealed-bids-request-for-proposals/))

### How should you weight the evaluation?

Apply mandatory gates first. A high feature score should not offset an unacceptable security, legal or portability issue.

**Suggested starting weights—not a validated universal scoring model:**

| Scored category | Weight |
|---|---:|
| Release-one workflow and specialist depth | 25% |
| Migration and evidence integrity | 20% |
| Administration and contributor usability | 15% |
| Integration and architecture | 15% |
| Three-year ownership cost and commercial flexibility | 15% |
| Delivery capability and reference evidence | 10% |
| **Total** | **100%** |

Score demonstrated evidence separately from confidence. Record a capability as **not demonstrated** when it was not shown; do not silently treat it as either proven or unavailable.

### How should you approach named-platform comparisons?

For searches such as **ServiceNow IRM vs Archer vs IBM OpenPages**, compare the same data model, restricted-evidence case, integration failure and export test. Do not compare one supplier’s configured environment with another’s unconfigured baseline without recording that difference.

For **AuditBoard vs Workiva**, note the naming change: AuditBoard announced its rebrand to **Optro on 9 March 2026**. Use “Optro, formerly AuditBoard” in the evaluation register so historical references and current proposals are not mistaken for separate suppliers. ([optro.ai](https://optro.ai/blog/meet-optro-auditboard-unveils-new-identity-as-ai-transforms-grc?utm_source=openai))

**Exit gate:** shortlisted suppliers have answered the same scoped requirement and commercial questions; unresolved items have owners and dates.