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)
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.
Sources cited on this page
- csrc.nist.gov ↗csrc.nist.gov