A one page decision memo for a security tool purchase states the problem, the options considered, the evidence from your own test, the risks, the cost drivers and the specific decision you want. Executives approve faster when the page is short, honest about trade-offs and tied to outcomes they care about.
Why one page
Approvers rarely read appendices. They read the top third. If your recommendation, the reason, and the risk are not visible there, they will ask for a meeting, and the meeting becomes the review you wanted to avoid.
Put the detail in an appendix and keep the page itself plain.
The template
| Section | What to write |
|---|---|
| Decision requested | One sentence: approve X for Y, by date Z |
| Problem | The business or risk problem, in two or three lines, with an example from your own environment |
| Options | The shortlist, plus the option of doing nothing |
| Recommendation | Which one and the three reasons that matter most |
| Evidence | What you tested, on which repos, with which results |
| Risks | The top three and how you will manage them |
| Cost drivers | The units and add-ons, plus your estimated operating effort |
| Exit and fallback | How you can leave, and what the runner-up is |
| Next steps | Owner, date, success measure at ninety days |
Writing each section well
Decision requested. Start with it. Do not make readers hunt.
Problem. Use a concrete example, such as a recent advisory that took too long to triage across repos. A real story lands better than a statistic.
Options. Always include "do nothing" or "improve what we have." It shows you considered the cheaper path, and it answers the first question a skeptic asks.
Evidence. State what the hands-on test measured: setup effort, coverage of your ecosystems, triage time for a sample, and how well it reported in pull requests. Say what you did not test.
Risks. Be direct. A memo with no risks looks naive. Typical risks include adoption by developers, noise at rollout, a vendor being acquired, and data handling. Pair each with a mitigation.
Cost drivers. Show the units, the add-ons and the estimated operating hours. Avoid quoting figures you cannot source. If finance wants numbers, attach the quote.
Success measure. Pick two or three that you can report on at ninety days, such as coverage of repos, time to triage a new advisory, or share of findings with an owner.
Mistakes to avoid
- Burying the recommendation in the third paragraph.
- Listing every feature instead of the three reasons that decided it.
- Claiming certainty about results you measured on a small sample.
- Hiding the runner-up. Naming it shows the decision was real.
- Using vendor language. Describe outcomes in your own words.
Add an appendix, not a second page
Link a scorecard, the response template answers and the test notes. People who care will read them. Everyone else gets the page.
A worked example: the memo, filled in
Here is a condensed sample for a fictional company. Names and numbers are placeholders.
Decision requested. Approve Vendor A for dependency risk management across all product repositories, with a start date next month, and keep Vendor B as the fallback.
Problem. Our last two dependency advisories took several days to trace across repositories because we had no current inventory, and findings were not routed to owners. We want a current inventory, findings in pull requests and a way to show auditors our process.
Options. (1) Do nothing and keep manual searches. (2) Improve the current scanner by finishing rollout. (3) Vendor A. (4) Vendor B.
Recommendation. Vendor A, for three reasons. It covered all five of our ecosystems in the trial. Developers rated its pull request feedback as clear in a five question survey. It exports inventory and history in open formats.
Evidence. We ran a two week test on three repositories with four engineers. Setup took under a day. We reviewed twenty findings per vendor with their owners.
Risks. Developer adoption (mitigation: start with one team and an observe-only policy). Noise at rollout (mitigation: tune policies in week two). Vendor change of control (mitigation: contract notice and export terms).
Cost drivers. Units are repositories. Two add-ons are needed. We estimate a few engineer hours per week for tuning in the first quarter, falling after that.
Exit. Full export of findings, history and inventory; fallback is Vendor B.
Next steps. Security lead owns rollout. Ninety day review checks coverage of repositories, time to trace a new advisory and share of findings with owners.
This is under 300 words, and a busy executive can read it in two minutes.
Tone and credibility
- Use plain verbs and specific numbers from your own test.
- Say what you did not test. It builds trust.
- State assumptions, such as "assumes we onboard teams in three waves."
- Avoid superlatives. Describe the difference that matters to you.
Formatting tips
Use a table for options and risks, because executives scan. Keep paragraphs to three lines. Put the decision in bold at the top. Add a link to the appendix and a date. Save a PDF copy with the final scorecard so that the record is stable.
Before you send it
- Ask someone outside the project to read it and say what you are asking for. If they cannot tell in thirty seconds, rewrite the top.
- Check every claim against the scorecard.
- Confirm with legal and procurement that the terms are reflected.
- Check that no vendor marketing language slipped in.
After approval
Send the vendor a short note, tell the runner-up politely, and schedule the ninety day review. Keep the memo, because it is the baseline you will measure against.
Where Safeguard fits
If Safeguard is on your shortlist, the same memo applies. Its GA capabilities include dependency scanning, SBOMs, reachability analysis, and policies and gates, and the free scan at https://gold.safeguard.sh/scan gives you real output to cite as evidence.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how monitoring results are summarized over time, then decide which two or three measures you will promise in your own ninety day review.
Quick check
Who should sign the memo?
The budget owner decides, and the security lead recommends. Name both so accountability is clear.
Should the memo name the runner-up?
Yes. It shows a real comparison and gives you a fallback.
How long should the appendix be?
Long enough for a reviewer to verify your claims: the scorecard, the response template answers and the test notes. Keep the memo itself to one page.
Last reviewed: 19 October 2026.
