# Domain 1: Have you agreed what the platform must accomplish?

NIST’s organisational-profile guidance distinguishes current and target outcomes and uses their differences to prioritise action. The IIA’s July 2026 Three Lines statement emphasises clear responsibilities, collaboration and safeguards for independence. These are useful foundations for defining a buying brief without confusing shared technology with shared accountability. ([csrc.nist.gov](https://csrc.nist.gov/pubs/sp/1301/final?trk=article-ssr-frontend-pulse_little-text-block))

### 1. Who can approve scope, resolve disputes and commit resources?

- **A — 0:** We have interest in a platform, but no accountable executive sponsor or programme owner.
- **B — 1:** A sponsor is named, but decision rights and escalation routes are informal.
- **C — 2:** The sponsor and programme lead have accepted their responsibilities; scope, funding and escalation decision rights are documented.
- **D — 3:** The governance group has used those arrangements to resolve a real scope or resource trade-off, with the decision recorded.

**Evidence to retain:** sponsor mandate, decision-rights table and decision log.

**Mandatory gate:** score at least 2.

### 2. Is the first-release scope specific enough to price and evaluate?

- **A — 0:** The brief is essentially “one enterprise GRC platform”.
- **B — 1:** Preferred modules are listed, but workflows, entities and exclusions remain unsettled.
- **C — 2:** The first workflow, participating entities, relevant obligations, retained systems and exclusions are approved; an appropriate specialist owns obligation applicability.
- **D — 3:** Business owners have also agreed measurable outcomes, a current baseline and the conditions under which scope may expand.

**Evidence to retain:** a one-page scope charter and requirements register linking each requirement to an owner and acceptance method.

**Mandatory gate:** score at least 2. Do not substitute a supplier’s framework library for your own applicability decisions.

### 3. Have you separated control ownership, challenge and independent assurance?

- **A — 0:** We expect the software or implementation partner to determine accountability.
- **B — 1:** Owners exist, but risk acceptance, exception approval, testing or escalation responsibilities conflict.
- **C — 2:** Responsibilities for operating controls, reviewing evidence, accepting risk, approving exceptions and providing assurance are documented, including applicable independence safeguards.
- **D — 3:** The team has rehearsed a failed control, disputed risk score and overdue action; each scenario reaches a named decision-maker without unresolved role conflicts.

**Evidence to retain:** responsibility matrix and scenario decision records. Where internal audit is outside the first release, document how the design preserves its access and assurance role rather than marking the question irrelevant.

**Mandatory gate:** score at least 2.

---