Keep all four options open until the first workflow and its failure points are understood. Use the following decision test before issuing a GRC RFP.
| Route | Consider it when | What your team must still do | Recommended stop condition |
|---|---|---|---|
| Repair the incumbent | You can demonstrate that ownership, configuration or data quality—not an essential capability gap—is the principal problem | Redesign the process, cleanse data, simplify configuration and retest reporting | A mandatory workflow or permission boundary cannot be supported acceptably |
| Configure an existing enterprise platform | Your organisation already has relevant platform skills and an approved architecture | Verify additional entitlements, module fit, administration and integration capacity | Existing platform ownership is being mistaken for entitlement or domain capability |
| Buy a specialist or enterprise GRC product | The first workflow needs capabilities you cannot reasonably deliver with existing tools | Select, configure, migrate, test, train and operate it | No one will own the system after launch |
| Build a bounded internal application | Requirements are narrow, stable and supported by a funded engineering owner | Own the data model, access rules, workflow, evidence handling, testing, support and exit format | The project is expanding into a general-purpose enterprise GRC product without corresponding engineering capacity |
If you choose the internal-build route, do not bypass the remaining stages. Replace the supplier evaluation with a build-design review, and require the same permission, audit-history, recovery, integration and portability tests.
For a build experiment, start with one controlled register and one approval workflow, not an attempted replacement for enterprise risk, SOX, internal audit and third-party risk simultaneously. Treat expansion as a separate funding decision.