# 1. What must be fixed before suppliers are scored?

**Agree the first useful release, its users and its acceptance conditions before demonstrations begin.** Give every supplier the same scope and distinguish mandatory requirements from desirable capabilities.

NIST’s cybersecurity supply-chain quick-start guide explicitly addresses defining and communicating supplier requirements. Use that principle to make requirements an input to procurement, rather than something reconstructed from sales presentations. ([csrc.nist.gov](https://csrc.nist.gov/pubs/sp/1305/final))

### Complete this scope charter

| Decision | Required entry |
|---|---|
| Buying trigger | Finding, renewal, acquisition, spreadsheet replacement or another defined problem |
| First-release outcome | For example, accountable control testing and remediation across named business units |
| Essential workflows | Specific processes that must work at launch; identify their business owners |
| Explicit exclusions | Future modules, entities, integrations and AI uses that are not being purchased now |
| Users and permissions | Administrators, risk practitioners, control owners, executives, auditors and external contributors |
| Data footprint | Object counts, attachments, history, sensitive classifications and source repositories |
| Technical dependencies | Identity, ticketing, evidence sources, reporting tools and retained specialist systems |
| Operational constraints | Internal capacity, required support hours, hosting constraints and recovery objectives |
| Commercial envelope | Preferred three-year budget, maximum approved exposure and growth assumptions |
| Acceptance authority | Named people authorised to accept workflow, data, security and commercial evidence |

Write requirements as observable outcomes. Replace “supports risk aggregation” with “reproduces the approved business-unit and group-level risk report, including the treatment of disputed assessments and shared exposures”.

Record each supplier’s edition, release, enabled modules, hosting arrangement, partner and demonstration configuration. Label delivery mechanisms as **standard**, **supported configuration**, **custom development**, **third-party dependency** or **roadmap**. Do not treat those categories as equivalent.

Include a **retain-and-repair incumbent option** where credible. Evaluate it against the same future outcomes and include its future operating, remediation and retained-tool costs. Do not give it free credit merely because it is already installed.