The Trust Ledger

One Page to Yes: How to Win Software Buying Committee Approval From Your Board, CISO and CFO

By The Trust Ledger team · 6 min read

Empty modern boardroom with a long dark table, warm lighting and bronze curtains
In short

To win software buying committee approval, write one page that opens with the decision, names security evidence with scope and dates, shows three-year cost including exit against a measured benefit and ROI, and states what needs approving, by whom and by when.

Three approvers, three different questions and one meeting. Most software approvals are lost before that meeting begins, in paperwork nobody had time to read.

Buying a family car is a committee decision. One person asks about safety, another about the monthly instalment and a third about the school run. Arrive with a fifty-page brochure and nobody reads it; arrive with one page that answers all three, and you leave with the keys. This guide shows how to write that page for a software buying committee, with cost and value figures that will survive scrutiny.

Why do software approvals stall at committee?

Approvals rarely stall through disagreement. They stall because each approver reads for a different risk, and the proposal answers none of them directly. Gartner finds that a typical buying group for a complex solution involves six to 10 decision makers. It also finds that 77% of B2B buyers describe their latest purchase as very complex or difficult.

A proposal written for the evaluation team prompts questions from every approver. Approval then waits for the slowest round of answers. The table shows what each approver is really asking.

ApproverCore questionEvidence that answers it
Board or sponsorWhy this, why now, and who owns it?A one-sentence decision, a stated priority, a named owner
CISOWhat happens to our data?In-scope SOC 2 Type II report or ISO/IEC 27001 certificate
CFOWhat is the full cost, return and exit?Three-year cost, ROI with assumptions, renewal cap, exit cost
Legal or procurementAre the terms acceptable?Deviations from standard terms, data processing agreement status
Each approver reads for a different risk. The page must answer all four.

A SOC 2 Type II report is an independent auditor's opinion on how controls operated over a period. ISO/IEC 27001 is the international standard for an information security management system. Either, with its scope and dates, answers the CISO far better than adjectives.

The one-page structure: decision, risk, cost, value, ask

We recommend a fixed structure, so that approvers learn where to look. Keep it to one side of A4. Everything else belongs in an appendix that nobody needs to read in order to say yes.

  • Decision: one sentence naming the recommendation, the provider and the term, then one on the problem it solves.
  • Risk: the independent evidence reviewed, with scope and dates, and the main residual risk with its owner.
  • Cost: the three-year total by category, with the renewal cap and exit cost stated.
  • Value: a measurable outcome, its baseline, the ROI and the date you will report actual results.
  • Ask: exactly what needs approving, by whom and by when, and the cost of delay.

In the risk block, name evidence rather than adjectives. If the provider holds an independent, audit-based score such as a Trust-IQ Score™, include it with its validity date. Then state the gap you are accepting, for example an AI feature that stays disabled until audit scope covers it. A CISO trusts a page that names its own gap.

For value, express the benefit as a metric with a baseline, such as review hours per month. Return on investment is benefit minus cost, divided by cost, over the same period.

A worked example: three-year cost and ROI

Here is a hypothetical case for a contract management tool. Figures are in thousands of any currency.

LineYear 1Years 2 and 3Three-year total
Licences (5% annual uplift, capped)60129189
Implementation and integration65065
Training and internal staff time402060
Exit and data migration reserve01515
Total cost165164329
Benefit: legal review hours saved120400520
Hypothetical example for illustration only. Figures in thousands, any currency.

Over three years, ROI is (520 − 329) ÷ 329, or about 58%. Cumulative benefit overtakes cost during year two, reaching 320 against 238. The first-year licence, the figure most proposals lead with, is only 60 of 329. A CFO shown only that number will rightly suspect the rest is missing.

Add one line of sensitivity. If benefits fall 30% short, three-year benefit drops to 364 and ROI to about 11%. The case still holds, only just. Stating where a case would break is what makes the 58% credible.

Questions that sink software buying committee approvals

The questions that send a proposal back are predictable. Answer them on the page, before anyone asks.

  • Exit: in what format is our data returned if we leave, and is deletion confirmed in writing?
  • Renewal: is the price increase capped, and does the contract renew automatically?
  • Ownership: who owns the supplier relationship, the residual risk and benefit tracking?
  • Evidence currency: when do the security report and certificate expire?
  • Alternatives: what else was compared, including doing nothing?

The common mistakes follow the same pattern. Proposals lead with features, quote only first-year cost, describe security with adjectives and leave the exit blank. The most avoidable error is sending the page cold. Ten minutes each with the CISO and the CFO beforehand surfaces objections while there is still time to answer them.

The bottom line

Conclusion

The family that leaves the showroom with the keys did not find a better car. It brought one page that answered each question before it was asked. Approvers rarely refuse a well-evidenced decision; they defer a proposal that makes them do the work.

Lead with the decision, name dated evidence, show three years of cost against a measured benefit and state the ask. This week, rewrite the first page of the proposal awaiting approval in that order, and brief the CFO and CISO before the meeting.

Frequently asked questions

What should a three-year software cost include?

Licences with renewal uplift, implementation, integration, training, internal staff time, and the cost of exiting and migrating data.

How is software ROI calculated?

Return on investment is benefit minus cost, divided by cost, over the same period. For a software contract, that period is usually three years.

How many people sit on a software buying committee?

Gartner finds that a typical buying group for a complex B2B solution involves six to 10 decision makers, each reading for different risks.

What does a CISO need to approve a software purchase?

Most CISOs look for named, dated independent evidence, such as an in-scope SOC 2 Type II report or ISO/IEC 27001 certificate, plus a data flow summary and incident terms.

How long should a software approval memo be?

One page covers the decision, risk, cost, value and ask. Supporting detail belongs in an appendix that approvers may read if they choose.

References

  1. Gartner, The B2B buying journey (sales insights)
  2. Secureframe, SOC 2 Trust Services Criteria explained
  3. ISO, ISO/IEC 27001 Information security management
  4. Smartreview AI, Trust-IQ Score™ methodology

Disclaimer: General information only, not legal, security, compliance or financial advice. Check the cited sources and seek professional advice. Names belong to their owners; no endorsement implied.