Gate 1: Have we defined a problem worth buying software to solve?

Approve a bounded first release before issuing an enterprise GRC RFP. The sponsor should be able to explain the intended operating result without naming a product.

An illustrative scope statement:

Establish accountable control testing and remediation for the named business units, with approved evidence access, traceable closure decisions and a reconciled management report. Enterprise risk aggregation and additional entities remain later phases.

For cyber-led programmes, NIST’s organisational profiles provide a useful way to distinguish current and target outcomes and prioritise gaps. They are a cybersecurity planning aid—not a complete enterprise GRC procurement specification. (csrc.nist.gov)

What should the scope checklist contain?

• [ ] A sponsor and a decision owner: identify who approves scope, funding and unresolved trade-offs.
• [ ] One first-release workflow: describe its trigger, participants, approvals, evidence and final output.
• [ ] Named process owners: distinguish responsibility for operating controls from responsibility for independently assessing them.
• [ ] Explicit boundaries: list included entities, functions and record types; identify exclusions and retained specialist tools.
• [ ] Baseline measures: record current chasing time, rejected evidence, overdue actions and reporting reconciliation effort where these can be measured.
• [ ] Real constraints: identify examination, reporting, procurement and contractual dates separately from aspirational launch dates.
• [ ] An alternatives assessment: explain why repairing the incumbent, extending an existing platform or maintaining a controlled interim process would or would not meet the need.

For an internal build, require the same named ownership for security, testing, maintenance, documentation and eventual exit as for a purchased product.

Output: a two-page scope charter and requirements register. Each requirement should have an owner, priority, acceptance method and phase.

Proceed when: the sponsor and affected process owners agree what must work first.

Hold when: the specification is essentially a list of departments, regulations and product features, without agreed workflows or decision rights.