Present the pilot on one page with seven blocks: goal, method, results, trade-offs, recommendation, cost drivers and next steps. Show measured data from your own repositories, state what you could not test, and say plainly what you are asking leadership to approve. Avoid vendor slides and feature tables.
Why one page
People who approve budgets read the top of a document and skim the rest. A single page forces you to decide what matters. Keep a longer appendix for engineers who want detail, but do not make the decision depend on it.
The seven blocks
1. Goal. One or two sentences. For example: reduce injection style flaws reaching production without slowing merges. State the problem in terms leadership already cares about, such as audit findings, customer questionnaires or past incidents.
2. Method. Two weeks, three to five of our own repositories, named triagers, pass criteria set in advance. Say how many tools were tested and that every tool ran on the same code.
3. Results. A small table, one row per tool: setup effort, share of findings labelled real, triage minutes per finding, known bugs caught, developer verdict. Use counts and say that samples are small.
4. Trade-offs. This is the block that earns trust. Write what each option costs in noise, effort or coverage. Include what the pilot could not show, such as behaviour on languages you did not test or at full production scale.
5. Recommendation. One sentence naming the option and the condition. For example: adopt the tool in report only mode for 30 days, then block on a short list of rules.
6. Cost drivers. Do not hide pricing structure. Explain what the cost scales with, such as developers, applications, or lines of code, and what could make it grow. OWASP's selection criteria note licence cost may vary by user, organisation, application or lines of code, so say which applies here. Add the internal cost too: triage time and ownership.
7. Next steps. Dates and owners. Contract review, rollout plan, success measure at 90 days.
Be honest about the free option
If an open source engine met most of your criteria, say so. Leadership will respect a recommendation that considers it, and it may be the right choice. Explain what the paid option adds, in terms of support, coverage or workflow, and whether that justifies the spend.
Name the risks of the recommendation
Every choice carries risk. Common ones: noise leading to disabled checks, lock in to a proprietary format, dependence on one vendor for rule updates. State your mitigation for each, such as requiring SARIF export, or a baseline plus staged blocking.
Define success up front
Write two or three measures you will check at 90 days: share of pull requests scanned, time to fix findings classed as real, and developer survey result. Leadership can then hold you to them, which makes approval easier.
Quick check
How much data should be on the page?
One small table and a few sentences. Put detailed logs in an appendix.
Should I show rejected options?
Yes, briefly, with the reason. It shows the decision was made on evidence.
Safeguard's compliance and evidence automation is generally available if you want pilot records kept for audits, and the free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
