Get a penetration test approved by making a business case, not a security one. Lead with the four arguments leadership responds to: revenue (enterprise customers require a recent test to sign, so it unblocks deals), risk (a test costs a fraction of a breach), compliance (regulators and frameworks require it), and due diligence (investors and acquirers check for it). Attach the request to a concrete trigger — a deadline, a customer requirement, a launch — quantify the downside of inaction, and bring a scoped, priced proposal so the decision is a simple yes. For most organisations, one unblocked deal or one avoided incident pays for years of testing.
// 01 Stop making a security argument
The most common reason a testing request stalls is that it's pitched to the wrong audience in the wrong language. "We have vulnerabilities we should fix" is true, but to a CFO it sounds like an open-ended cost with no deadline. The people who approve budget — finance, leadership, the board — don't think in CVEs; they think in revenue, risk, cost and obligation. Win by translating the test out of security-speak and into those terms. The vulnerability is the same either way; the frame is what gets it funded.
// 02 The four arguments that work
Revenue enablement
Enterprise customers and partners require a recent test before they sign. No test, no deal — so testing directly protects and unlocks revenue.
Risk reduction
A test costs a fraction of a breach once you count fines, incident response, downtime, legal and lost trust. Straightforward risk economics.
Compliance
Frameworks and regulators require it (PCI, SOC 2, CBB, SAMA, NCA). Non-compliance has its own penalties and lost business.
Due diligence
Investors and acquirers check for recent testing during funding and M&A. Its absence lowers valuation and slows deals.
You rarely need all four — pick the one or two that map to your situation and lead with them.
// 03 Attach it to a trigger
An abstract "we should test annually" is easy to defer; a specific trigger is not. The strongest business cases hang on a concrete event that creates urgency and a clear owner:
- An approaching compliance deadline (CBB, SAMA, PCI renewal).
- A named customer's security requirement blocking a deal.
- A product launch or major release.
- A board or investor question about security posture.
- A recent incident — yours or a competitor's — that raised the topic.
The trigger turns "someday" into "before the 30th," which is what moves budget.
// 04 The ROI, honestly framed
Resist the urge to invent a precise ROI percentage — leadership sees through fake numbers. Frame it as avoided cost and enabled revenue, which is both honest and compelling. On avoided cost: a breach routinely costs many multiples of a test once fines, response, downtime, legal and churn are counted, so finding the flaws first is simple economics. On enabled revenue: a clean, recent test and its attestation letter unblock specific enterprise deals and partnerships. The punchline for most organisations is stark: a single unblocked deal or one avoided incident pays for years of testing. See the cost guide for the actual numbers to put against it.
// 05 How to present it
Keep it to a page or two, written for finance and leadership, not engineers. Structure: the trigger, the risk (quantified where you can), the two or three value arguments that fit, the cost of the engagement against the cost of inaction, and a clear recommendation with scope and timing. Crucially, bring a scoped, priced proposal — not an open-ended "we need testing" — so the decision is a simple yes/no on a defined line item rather than an invitation to more analysis. A tight, business-framed, trigger-anchored one-pager with a real number attached is what turns a nice-to-have into an approved budget line. When you're ready, a good provider will help you scope and price it fast.
// 06 Frequently asked questions
How do you justify a pentest to management?
Frame it in business terms: revenue (customers require a test to sign, so it unblocks deals), risk (a fraction of a breach's cost), compliance (regulators and frameworks require it), and due diligence (investors and acquirers check). Present it as an investment protecting revenue and reputation, tied to a specific trigger — far more persuasive than "we should be more secure."
What should a business case include?
The specific trigger/driver, the risk (quantified where possible), the value arguments that fit your organisation, the engagement cost against the cost of inaction, and a clear recommendation with scope and timing. Keep it to a page or two, lead with the business outcome, and avoid jargon — the audience is finance and leadership.
What's the ROI of a penetration test?
Best expressed as avoided cost and enabled revenue. Avoided cost: a breach costs many times more than a test once fines, response, downtime, legal and churn are counted. Enabled revenue: a clean test and attestation unblock enterprise deals. For most organisations, one unblocked deal or avoided incident pays for years of testing.
How do you get budget approved?
Attach the request to a concrete trigger (deadline, customer requirement, launch, board question), quantify the downside of inaction, present the value arguments in the audience's language, and bring a scoped, priced proposal so the decision is a simple yes. Framing testing as protecting revenue and reputation, tied to a real event, turns it into an approved line item.
// 07 Related reading
- The board is asking about security posture — answering with evidence.
- How much does penetration testing cost? — the numbers for your case.
- Customer asking for a pentest report — the revenue trigger.