How to Build a Business Case for PTaaS Investment (With Numbers Your CFO Will Approve)

A CISO at a growth-stage fintech company in Sydney spent three years asking for a formal penetration testing programme. Every year the request came back the same way: approved in principle, deferred in practice. The CFO's position was consistent. Security is important. Show me the numbers.

The CISO could not show the numbers. She could describe risk categories. She could reference industry reports. She could name recent incidents at comparable companies. But she could not connect the investment to a financial outcome the CFO was willing to sign off on.

The fourth year she came to the conversation differently. She presented a breach cost estimate, a regulatory exposure figure, a revenue-at-risk calculation based on one enterprise client contract, and the annual cost of the PTaaS programme she was proposing. The CFO approved it before the end of the meeting.

The difference was not the risk. The risk had been the same for three years. The difference was the language.

This post is a practical guide to building the business case that gets PTaaS investment approved, with the financial framing that actually moves the conversation forward.

Start With What a Breach Actually Costs

The first number a CFO needs to see is not the cost of the security programme. It is the cost of the incident the programme is designed to prevent.

The IBM Cost of a Data Breach Report consistently places the average total cost of a data breach above four million USD globally, with figures for financial services and healthcare running considerably higher. For companies in Australia and New Zealand, the figures are directionally consistent with local incident data and regulatory penalty structures.

But global averages are not the most persuasive number in a CFO conversation. What moves the discussion is a figure built from the specific business, not a report average.

The components to build from are direct costs and indirect costs. Direct costs include incident response and forensic investigation, legal and regulatory counsel, notification costs to affected individuals, regulatory fines under the Notifiable Data Breaches scheme in Australia or the Privacy Act in New Zealand, and technical remediation. Indirect costs include customer churn from loss of confidence, contract cancellations from enterprise clients with security clauses, reputational damage quantified through pipeline impact, and the productivity loss across the internal team during an active incident.

For a SaaS company with annual recurring revenue of ten million dollars, a breach affecting fifteen percent of customers and triggering one enterprise contract exit can produce a financial impact that exceeds the cost of three to five years of PTaaS investment in a single event. That arithmetic belongs in the business case.

Build the Regulatory Exposure Figure Separately

Regulatory penalties are a different category from breach costs, and they deserve their own line in the business case because CFOs respond differently to a figure that is known in advance versus one that depends on the severity of an incident.

In Australia, the Privacy Act allows the Office of the Australian Information Commissioner to pursue civil penalty proceedings with maximum penalties that have increased significantly in recent legislative amendments. Serious or repeated interference with privacy can attract penalties into the tens of millions of dollars for corporate entities. In New Zealand, the Privacy Act 2020 allows the Privacy Commissioner to issue compliance notices and refer matters to the Human Rights Review Tribunal, with financial outcomes that depend on the severity and circumstances of the breach.

For regulated sectors such as financial services, healthcare, and any business touching the Consumer Data Right framework in Australia, the exposure is compounded. APRA-regulated entities have specific prudential requirements around operational risk management that include information security. A gap in formal security testing is a gap in the documented risk management programme, which is itself an exposure.

Presenting the regulatory exposure as a bounded figure, even as a range, gives the CFO a number they can place against the investment. A PTaaS programme at fifteen thousand dollars per year is a straightforward decision when the regulatory floor for a serious breach is four orders of magnitude higher.

Translate the Security Programme Into Revenue Protection

The third number in the business case is the revenue figure the security programme protects.

For most growth-stage and enterprise SaaS companies, the majority of annual contract value sits with a relatively small number of enterprise clients. Those clients have security requirements. Some require a current penetration test report as a condition of contract renewal. Some require CREST-certified testing specifically. Some are moving toward requiring evidence of a continuous security testing programme rather than an annual assessment.

When an enterprise client worth five hundred thousand dollars in annual recurring revenue has a security audit clause, the cost of meeting that requirement is part of the cost of retaining that client. The cost of not meeting it is the client.

Framing the PTaaS investment as revenue protection rather than cost avoidance changes the conversation entirely. A CFO who is reluctant to approve a security spend will approach a revenue retention argument differently. The question shifts from "why are we spending this?" to "what is the risk-adjusted cost of not spending it?"

Capture The Bug works with companies across Australia, New Zealand, and the United States where this exact framing has been the difference between a security programme that sits in a proposal document and one that gets funded. The details of how a CREST-certified engagement is structured and what it covers are available at capturethebug.xyz/Services/penetration-testing, but the business case conversation starts before the scope conversation does.

Present the Investment Against the Risk, Not the Market

One of the most common mistakes in building a security budget request is framing the investment relative to what comparable companies spend. Benchmark spending data is not irrelevant, but it is the weakest argument in a CFO conversation because it invites the response "we are not that company."

A stronger frame is the investment relative to the specific risks identified above. If the breach cost estimate is four million dollars, the regulatory exposure is two million dollars, and the revenue at risk from one enterprise client is five hundred thousand dollars, the total exposure profile is six and a half million dollars. A PTaaS programme at twenty thousand dollars per year represents less than a third of one percent of that exposure. That is not a security budget. That is a risk transfer investment with a calculable return.

The calculation does not guarantee that a breach will happen without the programme or that it will not happen with it. What it does is put the investment in a context that a CFO can evaluate rationally rather than emotionally. "Security is important" is not a financial argument. The cost of the programme is 0.3 percent of the quantified exposure profile is.

Structure the Proposal Around Outcomes, Not Activities

The final element of a business case that gets approved is the outcome structure. A proposal that describes what the testing team will do is a service description. A proposal that describes what the business will have at the end is a business case.

The outcomes that matter to a CFO are specific and measurable. A documented baseline of the current security posture. Identified attack paths closed before an external party finds them. A CREST-certified report that satisfies enterprise client procurement requirements. Verified remediation evidence that holds up in a regulatory inquiry. A clear record of the security programme that demonstrates proactive risk management.

Each of those outcomes has a financial correlate. Closing an attack path before it is exploited is worth the cost of the incident it prevents. Satisfying a procurement requirement is worth the contract value it secures. Building a regulatory record is worth the penalty exposure it mitigates.

Capture The Bug builds the engagement model at capturethebug.xyz/Services/penetration-testing around verified outcomes rather than activity completion. The report is not the end of the engagement. The verified retest that confirms remediation held is the end of the engagement. That distinction matters when presenting outcomes to a CFO because it changes what the business is buying from a document to a verified reduction in exposure.

What the CISO in Sydney Got Right

The CISO who finally got her programme approved did not come to the fourth meeting with better risk language. She came with a financial model built from the specific revenue, regulatory exposure, and enterprise contract structure of her business.

The programme she got funded was not materially different from what she had been asking for in years two and three. The difference was that in year four, the CFO could see exactly what the company was paying and exactly what it was buying. Security investment approved in that context is not a cost line. It is a business decision.

Building that case takes less than a day when the components are clear. The breach cost model, the regulatory exposure figure, the revenue protection argument, and the outcome structure are all standard elements. The numbers that go into them are specific to each business. The result is a budget request that a CFO can approve without needing to understand the technical details of what a penetration test actually does.

The language is financial. The outcome is security. Both are required to get the programme funded.

Plan Security Better

Plan Your Annual Pentesting Strategy the Right Way

Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.

Get the Annual Pentesting Plan

Frequently Asked Questions