The Real Cost of 'Good Enough' Security: A Framework for Budgeting Digital Risk

Ask most organisations how they arrived at their security budget, and the honest answer is some version of “we listed the tools that seemed necessary and added up the invoices.” That’s not a budgeting process — it’s an inventory. A budgeting process starts from what you’re protecting against and what failure would actually cost, then works backward to what’s worth spending to prevent it. Almost nobody in a small-to-mid-size organisation does this, because it requires admitting upfront that perfect security isn’t the target — an insurer’s actuarial mindset is, and that mindset feels uncomfortably mercenary applied to your own business.

It shouldn’t. It’s the only framework that produces a defensible answer to “are we spending the right amount,” rather than a guess dressed up as a decision.

The Question Every Security Budget Should Start With

Not “what tools do we need” — “what’s the actual cost if this specific thing fails, and what’s the probability it does?” Multiply the two, and you have a number worth comparing against the cost of prevention. This is exactly how cyber insurers price a policy, and it’s a more honest starting point than a vendor’s feature list, because it forces the conversation onto what the organisation is actually trying to avoid.

Applied practically, this means pricing risk in at least three tiers, not one blended “security budget” line:

Tier 1 — total compromise. What does it cost if the identity provider admin account, the primary domain, or the core financial platform is fully compromised? For most organisations this isn’t a bounded number — it’s “the business stops operating until this is resolved,” which makes the corresponding protection spend easy to justify regardless of its price, because the alternative is unbounded.

Tier 2 — contained compromise. A single application or account breached, but not one that cascades. Real cost, real disruption, genuinely bounded — a specific system down, specific data exposed, a specific incident response cost.

Tier 3 — nuisance-level risk. Spam, low-severity phishing attempts caught by existing filters, the background noise every organisation absorbs without a formal incident. Spending heavily here has rapidly diminishing returns.

Where “Good Enough” Actually Fails

The phrase “good enough security” almost always means uniform protection applied evenly across all three tiers — the same MFA policy, the same review cadence, the same budget priority for the account that can take down the whole business and the account that manages the office snack subscription. This isn’t caution; it’s the appearance of thoroughness substituting for actual risk-adjusted decision-making.

The correction isn’t spending more everywhere. It’s spending disproportionately more on Tier 1 — the small number of failure points with unbounded cost — and consciously, deliberately less on Tier 3, freeing budget rather than spending it uniformly thin.

A Concrete Worked Example

Take hardware-bound authentication (FIDO2 security keys) versus SMS-based two-factor as the fallback option on a critical admin account. The keys cost perhaps $150 total, all-in, for genuine redundancy — two keys, held separately. SMS-based recovery costs nothing extra, which is exactly why it’s still the default nearly everywhere.

Priced against Tier 1 consequences — a compromised identity provider admin account, which typically means every downstream account is now attacker-controlled — the $150 is not a rounding error next to the cost of that failure; it’s closer to negligible. Priced against a Tier 3 nuisance-level risk, spending the same amount on the same protection for every low-stakes account in the organisation would be genuinely disproportionate. Same control, wildly different justified spend, depending entirely on which tier the account sits in.

This is the exact reasoning I’ve applied to the three specific credentials that deserve materially higher protection than everything else — not because every account needs hardware-level security, but because a small number of accounts justify it disproportionately, and budgeting has to reflect that disproportion explicitly rather than averaging it away.

The Organisational Bias This Framework Corrects

Left unexamined, security budgets drift toward whatever’s easiest to justify in a board meeting — usually a recognisable vendor name and a compliance checkbox — rather than toward the specific failure modes that would actually hurt most. A tiered risk-pricing model forces the harder, more useful conversation: not “what are we buying,” but “what specifically are we trying to prevent, and have we priced it honestly.” Boards and finance teams generally respond better to this framing than to a security team’s unquantified sense of unease, because it translates directly into the same cost-benefit language used everywhere else in the business.

What This Looks Like as an Ongoing Process, Not a One-Off Exercise

Risk isn’t static — a Tier 3 account today can become Tier 1 the day it’s granted broader permissions, or the day the business starts routing payments through it. The tiering exercise needs a review cadence, not a one-time classification exercise that quietly goes stale. Quarterly is reasonable for a growing organisation; at minimum, any time a new system is granted meaningful access to other systems, it needs to be re-tiered before, not after, an incident forces the question.

Related reading: a digital succession plan; how fast the patch window has actually compressed.

Frequently Asked Questions

Isn’t this just a more complicated way of saying “spend more on security”? No — the explicit goal is spending less in aggregate by redirecting Tier 3 spend toward Tier 1, not increasing the total budget. Most organisations applying this framework honestly find they’re overspending on low-consequence risk and underspending on the handful of failure points that would actually be catastrophic.

How do you price the cost side of the equation when a total compromise is genuinely unbounded? For truly unbounded consequences — “the business stops operating” — the framework’s value isn’t in producing a precise number, it’s in establishing that the protection spend is justified regardless of its cost, which resolves the budgeting question without needing false precision.

Does this replace formal risk management frameworks like ISO 27001 or NIST? No — it’s a practical lens for prioritising spend within whatever formal framework an organisation already operates under, not a replacement for one. It answers “what do we fund first,” which those frameworks generally leave to organisational judgement.

Who should own this tiering exercise inside an organisation? It works best as a joint exercise between whoever holds technical risk (a CTO or IT lead) and whoever holds financial risk (a CFO or finance lead) — priced in isolation by either side alone, it tends to either overweight technical severity or underweight operational consequence.

What’s the first step for an organisation that’s never done this formally? List every account and system with meaningful administrative or financial access, and sort them into the three tiers honestly — most organisations find the list of genuine Tier 1 items is much shorter than their existing security spend implies it should be.