Build a cybersecurity funding case in six steps: risk register, breach cost, benchmarked budget, five-year ROI and NPV, then export a PDF summary.
This is a six-step wizard that turns a security funding request into a document a finance committee can act on. You describe your organisation, score your top risks, estimate the cost of a breach, derive a budget from industry benchmarks, validate the return on that budget over five years, and export the whole thing as a formatted PDF executive summary. Your progress is saved in your browser as you go, so you can start on Monday, gather a number you did not have, and resume where you left off.
It exists because the hardest part of a security budget is rarely knowing what to buy. It is translating “we need endpoint detection and a second analyst” into the language a CFO already uses — expected loss, payback period, net present value, percentage of revenue against peers. That translation is what this tool automates.
Each risk gets a score of likelihood multiplied by impact, on a 1–5 scale each, giving a range of 1 to 25 that maps onto five bands from very low to very high. This is the standard qualitative risk matrix, and its virtue is that people will actually fill it in.
Two habits make it much more useful. First, define what your numbers mean before you score anything — likelihood 4 should mean “expected roughly annually”, not “feels likely”, and impact 5 should be anchored to a monetary or operational threshold everyone recognises. Undefined scales are how two teams produce incompatible registers. Second, score the scenario you can describe end to end. “Ransomware” is a category; “ransomware encrypts the file server and the last known-good backup is 11 days old” is a scenario you can estimate and, more importantly, argue about productively.
The count of high and very-high risks feeds forward into the breach cost model as an uplift, so the register is not decorative — it changes the numbers downstream.
It is worth understanding the mechanics, both so you can defend the output and so you know where to substitute better data.
Breach cost starts from an industry benchmark drawn from published cost-of-breach research — healthcare is the most expensive sector by a wide margin, followed by financial services and technology, with retail and government at the lower end. That baseline is increased for each high or very-high risk in your register and decreased by a maturity factor, on the reasoning that a mature programme detects and contains faster, which is where most of the cost difference between organisations comes from. The total is then split into six components: detection and escalation, notification, legal, regulatory fines, business disruption, and post-breach response. Business disruption and detection dominate, which surprises people who expect fines to be the largest line.
Budget is derived rather than guessed. The model estimates your IT budget as a proportion of revenue, applies an industry-specific security share of that IT budget — financial services benchmarks highest, education and manufacturing lowest — then adjusts by maturity, on the basis that an organisation starting from minimal maturity has catch-up investment to make while an optimised one spends more efficiently. The result is checked against the breach exposure, floored at a per-employee minimum, and capped at a percentage of revenue so it cannot recommend something structurally unaffordable. You get a recommended figure with a range around it and a standard allocation across software, personnel, services, hardware, and training.
ROI multiplies your modelled breach cost by an assumed annual probability of occurrence to get an expected annual loss, then credits the programme with reducing that loss on a staged curve — a large reduction in year one, tapering as the easy wins are used up, with an additional increment for organisations starting from low maturity. Operational efficiency gains are added on top, the five-year stream is discounted to present value, and the payback period is the point at which cumulative benefit overtakes cumulative investment.
Every number this tool produces is the output of a model with assumptions in it. That is true of every business case, including the ones consultancies charge for; the difference is whether the assumptions are visible. Three of them deserve your attention before you present anything:
Used well, the output is a structured argument with explicit assumptions that a finance function can interrogate. Used badly, it is a large number with a decimal point. The first version gets funded.
One reframing that consistently helps: lead with the risk-transfer comparison rather than the ROI percentage. Executives are used to buying insurance against low-probability, high-impact events without demanding a positive expected return on the premium. Security spending is closer to that than to a capital project, and framing it that way avoids an argument about the probability assumption that you are unlikely to win.
Score your current state before you build the case with the cybersecurity maturity assessment, and map controls to a recognised framework with the NIST CSF 2.0 control mapper. For deeper work on individual inputs, the data breach cost calculator models the loss figure in more detail, the cybersecurity budget calculator covers the spend side, and the risk matrix calculator handles likelihood-and-impact scoring on its own.
No. Your progress is stored in your own browser’s local storage so you can return to a partially completed business case. Nothing is uploaded, and clearing your browser storage deletes it.
Twenty to thirty minutes if you have your revenue figure, headcount, and a sense of records at risk to hand. The risk assessment step is where the thinking happens; the preset scenarios cover the most common six and are a reasonable starting register for most organisations.
They are modelled from published industry cost-of-breach benchmarks, adjusted for your risk register and maturity level. They are estimates for planning, not actuarial figures. Sanity-check the total against your insurance limit or a comparable public incident before presenting it.
A lot. It reduces the modelled breach cost, because mature programmes detect and contain faster; it raises the recommended budget for low-maturity organisations, who have catch-up investment to make; and it feeds the ROI model, where there is more headroom for improvement at the bottom of the scale.
By treating avoided expected loss as the benefit: modelled breach cost multiplied by an assumed annual probability, multiplied by the proportion of that exposure the programme removes, plus operational efficiency gains. It is the standard approach, and the probability and reduction assumptions are the parts to state explicitly when you present it.
Because it is the metric finance teams already use to compare unlike investments, and it is less sensitive to arguments about the probability assumption. “This pays back in under two years” is a sentence a CFO can act on without agreeing with your threat model in detail.
A titled cover section, the executive summary, the risk landscape from your register, the financial impact analysis with the six-way cost breakdown, the budget recommendation with allocation amounts and percentages, and the return on investment section — formatted for circulation as-is.
Yes. Select the frameworks that apply in step 1 and frame the required controls as obligations rather than discretionary spend. Compliance-driven items belong in the case, but they are a different argument from expected-loss reduction, and mixing the two weakens both.
No. The allocation is by category — software, personnel, services, hardware, training — not by product. Vendor selection is a separate exercise that should follow from the risks you documented, not precede it.
Yes. You can move back through completed steps and revise anything; the downstream calculations recompute from your changes. You can also delete the saved business case entirely and start again.
Security leaders face a persistent challenge: translating technical risks into language that resonates with business stakeholders. A well-constructed business case bridges this gap.
1. Risk Quantification Abstract threats become tangible when translated to financial terms. By identifying your top security risks and assigning likelihood and impact scores, you create a foundation for analysis.
2. Financial Impact Analysis Understanding potential breach costs helps stakeholders appreciate what is at stake. Industry-specific benchmarks provide credible reference points.
3. Investment Sizing Budget recommendations grounded in industry benchmarks are more defensible than arbitrary requests. Demonstrate how investment levels relate to risk reduction.
4. Return Validation ROI projections transform security from a cost center into a value generator. Positive returns and strong NPV figures make the investment case compelling.
A cybersecurity business case is a documented justification for security investments that demonstrates the value, necessity, and expected return of proposed security initiatives. It includes risk assessment, cost analysis, budget recommendations, and ROI projections.
The Business Case Builder guides you through a 6-step process: Organization Profile, Risk Assessment, Breach Cost Analysis, Budget Planning, ROI Validation, and Executive Summary generation.
Calculations are based on industry benchmarks from sources like the IBM Cost of Data Breach Report, Gartner security spending research, and NIST frameworks. We factor in your industry, size, and compliance requirements.
Your business case data is stored locally in your browser using localStorage. No data is sent to our servers unless you explicitly choose to generate a shareable link.
Yes! The final step generates an Executive Summary that you can export as a PDF document. It includes all your analysis in a professional format suitable for board presentations.
Breach cost estimates are based on industry averages. Actual costs can vary significantly based on breach scope, response time, regulatory environment, and reputational impact. Use these as starting points for discussions.
Each step provides links to our standalone calculators for more detailed analysis. You can use the full Breach Cost Calculator, Security Budget Calculator, or ROI Calculator independently.
We recommend updating annually or whenever significant changes occur: major security incidents, regulatory changes, business growth, or shifts in threat landscape.