Technology procurement business case guide. Last reviewed:
A technology procurement business case gets board approval when it answers five questions in plain language: what problem are we solving, what happens if we do nothing, which options were tested, what will it really cost over the full term, and how will we know it worked. Boards rarely reject a good investment. They reject a case that cannot show its working. This guide sets out the structure, the numbers and the evidence that directors look for in an IT, AI or cybersecurity purchase.
What a board is actually deciding
A board is not approving a product. It is approving a use of capital, a level of risk and an accountable owner. Directors want to know that the problem is real, that management has looked at more than one answer, and that the organisation will not be locked into a cost or a vendor it cannot leave. Write the case around those three concerns and the technical detail becomes supporting evidence rather than the main story.
The structure of a board-ready business case
- Executive summary. One page. The problem, the recommendation, the total cost over the term, the expected benefit and the decision you need.
- Problem statement. The business issue in measurable terms, such as downtime hours, audit findings, manual effort or exposure to a known threat.
- Cost of doing nothing. What continues or worsens if the board says no. This is often the strongest argument in the paper.
- Options considered. At least three: do nothing, a minimum option and the recommended option. Show why each was accepted or rejected.
- Whole-of-life cost. Licences, implementation, integration, internal effort, training, support, renewals and exit, across the full contract term.
- Benefits and measures. Benefits you can measure, with a baseline and a target date.
- Risk and compliance. How the option affects your obligations, for example the Essential Eight, APRA CPS 230 and CPS 234, or the Privacy Act.
- Evaluation method. How vendors were compared, the criteria and weightings used, and who scored them.
- Implementation and ownership. Timeline, milestones, the accountable executive and how progress will be reported back.
- Decision requested. The exact approval sought, the amount and any conditions.
Getting the numbers right
Most challenges in the boardroom are about cost. A licence price on its own understates the real figure, often by a wide margin once integration, internal time and renewal uplifts are counted. Present cost over the full term and show the assumptions behind it.
| Cost line | What to include | Common mistake |
|---|---|---|
| Licences or subscriptions | Year-by-year pricing, including uplifts at renewal | Showing year one only |
| Implementation | Partner fees, integration and data migration | Assuming the vendor estimate is fixed |
| Internal effort | Staff time for the project and ongoing operation | Treating internal time as free |
| Change and training | Adoption, process change and training | Leaving it out entirely |
| Exit | Data extraction, transition and overlap costs | Not considering exit at all |
The CYBORIUM TCO calculator and the guide to total cost of ownership in technology procurement set out a full cost model you can adapt.
Show that the market was tested
Directors are increasingly alert to cases built around a vendor that was chosen first and justified later. The strongest evidence you can give is a structured evaluation: requirements agreed before the market was approached, separated into must-haves and nice-to-haves using MoSCoW prioritisation, providers scored against weighted criteria, and pricing benchmarked against comparable offers. Include the scoring summary as an appendix so the board can see how the recommendation emerged.
Write for the board, not the project team
- Use plain language and explain any acronym the first time it appears.
- Lead with the decision and the money, then the detail.
- Quantify benefits with a baseline, a target and a date.
- State the risks honestly, including what could go wrong with the recommended option.
- Name one accountable executive.
How CYBORIUM supports a business case
CYBORIUM runs the market evaluation that sits behind the business case: requirements definition, vendor shortlisting, scoring and commercial benchmarking across cybersecurity, AI and enterprise IT. The evidence is structured so it can go straight into a board paper. The service carries no fee to your organisation, and you contract directly with the provider you choose. Learn more about procurement as a service.
Frequently asked questions
What should a technology procurement business case include?
A clear problem statement, the options considered including doing nothing, whole-of-life cost, quantified benefits, risk and compliance impact, the evaluation method, an implementation plan and a specific decision request with an owner.
How long should a business case for a board be?
Keep the board paper to two to four pages with a one-page executive summary. Put the detailed cost model, scoring and vendor evidence in appendices so directors can test the numbers without reading them first.
Why do boards reject technology business cases?
Most rejections come from unclear problems, a single option presented as the only answer, cost that ignores the full contract term, benefits that cannot be measured, and no evidence that the market was tested independently.
Should the business case name a preferred vendor?
Only after a structured evaluation. A case that names a vendor before the market has been tested looks like a decision already made, which weakens the board’s confidence in the recommendation.
Does independent procurement advice strengthen a business case?
Yes. Evidence from a vendor-neutral market evaluation shows the board that options were compared fairly and that pricing was benchmarked, which is the question directors most often ask.
Related guidance: procurement governance, managing procurement risk, writing a technology RFP.
