Most enterprise technology procurement doesn’t fail in negotiation. It fails earlier, when requirements are vague enough that every vendor can claim to meet them. MoSCoW prioritisation closes that gap. It forces a business to agree what a solution must do, should do, could do, and will not do, before a single vendor is approached, and it is one of the most effective tools available for keeping cybersecurity, AI and IT procurement decisions defensible.
What Is the MoSCoW Method?
MoSCoW is a requirements prioritisation technique developed by Dai Clegg in 1994 and popularised through the Dynamic Systems Development Method (DSDM). The name is an acronym: Must have, Should have, Could have, and Won’t have (the interstitial “o”s exist purely to make the word pronounceable). It was built for software delivery under fixed timeframes, but the same discipline applies directly to enterprise technology procurement, where budget, security obligations and delivery timelines are just as fixed.
Why MoSCoW Matters More in Cybersecurity, AI and IT Procurement Than Almost Anywhere Else
Technology vendors are skilled at reframing their product’s features as your requirements. Without a locked scope, a shortlist conversation quietly turns into a demonstration of what the vendor already built, rather than an evaluation against what the business actually needs. MoSCoW prevents this by fixing the requirement set, and the relative importance of each requirement, before the market is engaged. It is also one of the clearest ways to produce a decision record a board or auditor can review months later and understand exactly why a provider was selected.
The Four Categories, Applied to Technology Procurement
Must Have
Non-negotiable requirements. In cybersecurity and enterprise IT, this typically includes regulatory and security obligations: data residency, encryption standards, specific compliance certifications such as ISO 27001 or SOC 2, integration with existing identity and access management, and any control mandated by an applicable framework such as APRA CPS 234 or the ASD Essential Eight. A provider that fails a Must Have is out of the evaluation, regardless of price or relationship.
Should Have
Important requirements with a workable, if imperfect, alternative. A Should Have might be single sign-on support, a specific reporting cadence, or a preferred deployment model. These carry real weight in scoring but do not eliminate a vendor on their own.
Could Have
Desirable but genuinely optional. Could Haves are useful for differentiating between finalists once the Must and Should requirements have already been satisfied, but they should never be allowed to drive the overall decision.
Won’t Have (This Time)
Explicitly out of scope for the current procurement, and stated as such. This category does the most underrated work in the whole framework: it stops scope creep before it starts, and it gives stakeholders a documented answer when a feature request resurfaces mid-evaluation.
How MoSCoW Prevents the Most Common Procurement Failures
Most of the technology procurement outcomes that end up being questioned later, an over-scoped contract, a platform that does not fit the operating environment, a renewal that quietly compounds, trace back to requirements that were never properly prioritised. MoSCoW addresses four failure modes that show up repeatedly in enterprise technology buying. Scope creep is contained because every Won’t Have is a documented decision, not an oversight. Vendor-led framing is prevented because Must Haves are fixed before vendors are engaged, rather than shaped by whichever demonstration ran first. Evaluation stays fair because every provider is scored against the same weighted criteria. And budget overrun is harder to justify because Could Haves are visibly optional, so premium add-ons cannot be sold to the business as essential.
Running a MoSCoW Workshop Before You Approach the Market
A MoSCoW exercise works best as a structured session, not a form circulated by email. Start by bringing the right stakeholders into the room: the CIO or CISO, procurement, the business owner of the outcome, and anyone holding a security, risk or compliance mandate. Capture every requirement first, without prioritisation, so nothing is lost to groupthink. Then sort requirements into the four categories, testing each Must Have against a single question: does the project fail without this? Weight the Should Have and Could Have categories so scoring reflects genuine business priority rather than simple presence or absence. Finally, sign off the finished requirement set with stakeholders before any vendor conversation begins.
How CYBORIUM Applies MoSCoW in Vendor-Neutral Evaluations
MoSCoW sits at the front of CYBORIUM’s evaluation methodology for exactly this reason. Requirements are captured and prioritised with the client before the market is approached, so every provider is measured against the same locked criteria. That requirement set becomes part of the evidence pack behind the final recommendation: traceable from requirement to shortlist to selection, and available if a board, auditor or risk committee asks why a particular provider was chosen. Because CYBORIUM is compensated by the selected provider under a capped, success-based model rather than by the client, there is no commercial incentive to loosen a Must Have to accommodate a preferred vendor.
Common Mistakes When Using MoSCoW in Procurement
The most common mistake is overloading the Must Have category: if more than a third of requirements end up there, the prioritisation has not actually happened. The second is skipping stakeholder alignment, since a MoSCoW list built by one department rarely survives contact with the rest of the business. The third is treating the list as final when it should be revisited if the business case changes materially during a long procurement cycle. The fourth is leaving the Should Have and Could Have categories unweighted, which produces close, unhelpful scores that do not actually separate vendors.
Frequently Asked Questions
What is MoSCoW prioritisation in procurement?
MoSCoW is a method for sorting procurement requirements into four categories, Must have, Should have, Could have and Won’t have, so that vendor evaluation is measured against an agreed, weighted set of criteria rather than an unordered list of wants.
Why use MoSCoW instead of a standard requirements list?
A flat requirements list treats every item as equally important, which makes vendor comparison subjective and hard to defend later. MoSCoW forces relative prioritisation up front, producing a scoring basis that stands up to board and audit scrutiny.
How many requirements should be in the Must Have category?
As a rule of thumb, Must Haves should represent a minority of the total requirement set, often less than a third. If most requirements are marked Must Have, the prioritisation exercise has not been rigorous enough to be useful.
Does MoSCoW work for AI and cybersecurity vendor selection?
Yes, and arguably it matters more in these categories than most others. AI and cybersecurity vendor claims are difficult to verify and easy to overstate, so a fixed, prioritised requirement set gives decision owners a concrete basis for testing vendor claims rather than accepting them at face value.
MoSCoW is one part of a wider evaluation methodology. If your organisation is approaching a cybersecurity, AI or enterprise IT procurement and requirements have not yet been locked, that is the right time to bring in independent, vendor-neutral evaluation support.
