The Right Amount
“How much security is enough?” is the question every business asks and no framework answers. It’s answerable — but only if you can see what you’re actually getting for what you’re spending.
It might go something like this. A CTO at a 35-person Series A B2B SaaS gets asked by a prospective enterprise customer whether they have ISO 27001 certification. They don’t. The deal is worth €400K annually. So the CTO does what any sensible person would do: panics quietly and calls a consultant.
The consultant scopes the project. Full ISO 27001 implementation: gap analysis, risk assessment, policy suite, control implementation, internal audit, certification audit. Three months. €30,000 in consulting fees, plus the certification body’s costs, plus the time of internal staff diverted from product work. Call it €60,000 all-in for the first year.
The CTO asks: “Is all of this necessary?”
The consultant says: “It depends on what you mean by necessary.”
That’s a fair answer, but it’s not a useful one. What the CTO actually wants to know is: given our size, our risk profile, our customer base, and our budget, what’s the right amount of security for us right now? Not the maximum. Not the minimum-to-pass. The right amount.
Nobody can tell them. The framework doesn’t answer that question — it tells you what to address, not how deeply. The consultant’s incentive is to scope comprehensively, because under-scoping creates liability. The certification body wants a thorough implementation because their reputation depends on it. Everyone in the ecosystem benefits from more, and nobody is structurally incentivised to help you figure out what’s enough.
So the CTO does what people in that position do: follows the consultant’s recommendation, implements everything at the depth suggested, spends the money, gets the certificate, wins the deal. And nine months later, half the controls are being maintained at a level that makes no sense for a 35-person company. They’re running quarterly business continuity exercises for a team that sits in one room. They have a formal change management board for a company where three people deploy code. They’re maintaining a physical security policy for an open office they rent in a co-working space.
None of this is wrong, exactly. It all satisfies the framework. It all passes the audit. But a meaningful chunk of the effort is disproportionate to the actual risk. The programme is shaped by the standard’s requirements, not by the company’s reality.
Why frameworks can’t answer “how much”
Frameworks are good at telling you what to address. ISO 27001 Annex A gives you 93 controls across four categories. NIS2 Article 21 specifies ten areas of cybersecurity risk management. SOC 2 defines five trust service criteria. These are useful structures. They ensure you don’t miss entire categories of risk.
What they deliberately don’t do is tell you how much effort each area deserves for your specific situation. And there’s a good reason for that: frameworks are designed to apply across wildly different organisations. The same standard covers a 20-person startup and a 10,000-person bank. The same requirement — “manage vulnerabilities” — means something completely different at those two scales.
This is a feature, not a bug. A prescriptive framework that specified exactly how to manage vulnerabilities for every type of organisation would be a thousand pages long and obsolete before publication. The flexibility is the point.
But the flexibility creates a gap. The framework says “manage access control.” It doesn’t say whether your quarterly access review should cover every system or just critical ones. It doesn’t say whether you need a formal IAM platform or whether a spreadsheet is fine for now. It doesn’t say whether your access review should take two hours or two days.
What fills the gap depends on two opposing forces: fear and efficiency.
Fear says do everything. Review every system quarterly. Buy the enterprise IAM tool. Document every access decision in triplicate. Fear is driven by the worry that the auditor will find a gap, that a breach will expose something you should have thought about, that the compliance certification is at risk.
Efficiency says do the minimum. Review critical systems only. Use a spreadsheet. Keep the documentation light. Efficiency is driven by the reality that you have limited time, limited budget, and a business to run.
Many organisations oscillate between these two without ever finding a stable middle ground. They over-invest in some areas (because someone got scared) and under-invest in others (because nobody was watching). The result is a programme that’s simultaneously too much and not enough — expensive in the wrong places, thin in the places that matter.
The proportionality principle
Here’s what I think is true, and what the rest of this chapter builds on:
The right amount of security is the amount where the value you get — reduced risk, compliance, business enablement, confidence — exceeds the cost of producing it. When the cost exceeds the value, you’ve done too much. When the risk exceeds what you’ve treated, you haven’t done enough.
Concretely: if your CTO spends four hours a month on access reviews for a low-risk internal wiki, and that time could go toward fixing misconfigured DNS records, the programme is investing in the wrong place. The total effort might be “right” — the allocation is wrong. Proportionality isn’t just about how much. It’s also about where.
That sounds obvious stated this way. It isn’t, because many organisations can’t see either side of the equation clearly enough to evaluate it.
On the cost side: what are you actually spending? Not just tool licences — the time people spend on security tasks, the opportunity cost of a CTO doing access reviews instead of product work, the overhead of maintaining policies and evidence and processes. Many organisations dramatically undercount the cost because they don’t know how much time security consumes across the business.
On the value side: what are you actually getting? Not “we have a certificate” — that’s an output, not a value. The value is: which specific risks are treated? What’s your actual compliance posture across the frameworks that matter to your customers? What business can you win that you couldn’t win without this programme? What’s the reduction in expected loss from the risks you’ve treated?
When you can see both sides, proportionality becomes a real conversation instead of an abstract principle. And that conversation changes how you invest.
Proportionality doesn’t work in isolation. You can’t invest proportionately without clarity — seeing what you have, what state it’s in, what’s connected to what. And you can’t sustain proportionate investment without feedback — knowing whether the controls you funded are actually working, whether the risks you accepted stayed acceptable, whether the gaps you planned to close actually closed. Clarity tells you where to look. Feedback tells you whether your last decision was right. Proportionality tells you how much to invest next. The three reinforce each other.
Making security investments visible
What does proportionate decision-making look like in practice?
Your security team recommends purchasing a web application firewall. It costs €15,000 per year. Should you buy it?
In a disconnected programme, the conversation goes something like this: “We should have a WAF. It’s industry best practice. Other companies our size have one. The penetration test recommended it.” These are all reasonable statements, and none of them answer the question. They describe general good practice, not your specific situation.
In a connected programme, you can trace the decision: the WAF would treat three specific risks — SQL injection, XSS, and application-layer DDoS — across two internet-facing assets that process customer data. Those assets are covered by six ISO 27001 requirements and two SOC 2 criteria. Currently, those risks are partially treated by input validation in the application code and rate limiting at the CDN, but there’s residual risk that shows up in your last penetration test as two medium and one high finding. The WAF would close those findings and reduce the residual risk on those assets to low.
Now you have a real conversation. €15,000 per year to close three risks on two critical assets, resolve three pen test findings, and strengthen compliance across eight requirements. Is that worth it? Maybe. Maybe you decide the existing application-level controls are sufficient and you’d rather spend that €15,000 on something with higher impact. Maybe you decide the pen test findings make it non-negotiable. Either way, you’re deciding based on your reality, not on what other companies your size do.
This is what proportionality looks like: specific enough to evaluate, connected enough to see the consequences, and honest enough to admit when something isn’t worth the cost.
The minimum viable security programme
There’s a question founders and CTOs keep asking: “We need to get ISO 27001 / SOC 2 / NIS2-compliant. What’s the minimum we need to do?”
The question makes security people uncomfortable. Minimum sounds like cutting corners. It sounds like they’re asking permission to do less than they should. It sounds irresponsible.
I think it’s the most responsible question they can ask.
A 25-person startup with limited budget and a product to build shouldn’t implement the same depth of security programme as a 500-person financial services company. Not because security matters less — it matters just as much — but because the risk profile, the threat landscape, the resources, and the acceptable cost are all different. The startup that tries to implement a bank’s security programme will either go bankrupt or, more likely, implement it on paper and not in practice. Neither outcome makes anyone more secure.
The minimum viable security programme isn’t about doing less. It’s about doing the right things first.
What does that look like? It starts with the questions from Chapter 5: what do you actually do, what data do you handle, what are you protecting, what would hurt if it failed? From there, identify the risks that matter most — not all risks, the ones that would genuinely damage the business. Implement controls for those risks first. Build the operational cadence from Chapter 7 around those controls. Add depth and breadth as the business grows and the risk profile evolves.
A startup that implements five controls properly — access management, vulnerability management, incident response, backup and recovery, and vendor assessment — and runs them with genuine operational discipline is more secure than a company with 93 controls documented in policies that nobody follows. The gap between what’s written and what’s real is where risk is buried.
Minimum viable doesn’t mean minimum forever. It means starting where the risk is highest, proving the approach works, and expanding deliberately. The annual wheel from Chapter 7 grows as you grow. The connected model from Chapter 6 scales because adding a new control or asset is incremental.
When the maximum is right
The mistake isn’t doing the maximum. The mistake is doing the maximum by default, without understanding whether the stakes warrant it.
Sometimes the stakes do warrant it. If you’re handling health records, financial data, or critical infrastructure, a gap isn’t a bad audit finding — it’s people’s lives, livelihoods, or safety. If you’re in a sector where the regulator has enforcement power and appetite, under-investing isn’t a risk you can accept — it’s a risk that gets accepted for you, by someone with the power to shut you down.
The proportionality principle still applies. It just produces a different answer. When the potential impact is catastrophic, proportionate effort is high. When regulatory consequences are severe, acceptable residual risk is low. The same chain — risk to asset to control to consequence — still works. It just tells you to do more, because more is genuinely justified.
Most organisations aren’t handling critical infrastructure. Most aren’t one audit finding away from shutdown. But they implement security as if they might be, because the framework doesn’t help them distinguish, and fear fills the gap. Proportionality works in both directions. For most readers of this book, it might mean doing less in some areas, but doing it properly in others. For some, it means doing everything and doing it properly. The common thread is “properly.”
The budget conversation
Your CFO asks: “Is the security budget too high?” You might have heard this before, and usually it produces a defensive conversation. This time, you pull up the answer. €80,000 a year. Sixteen critical risks treated. Three consciously accepted, with documented rationale — you made those decisions together last quarter. Ninety-four per cent on ISO 27001, eighty-nine on SOC 2. Customer security questionnaires answered in under an hour instead of five days. Three enterprise deals closed this year that required certification as a precondition. You show them. They think about it for thirty seconds. “That’s clear. What would it cost to close the SOC 2 gap?” Now you’re having a business conversation — not about whether security is worth it, but about where to invest next.
That’s what proportionality gives you in a budget conversation. Not “are we doing enough?” — a question that produces anxiety. But “here’s what we’re doing, here’s what it costs, here’s what it produces, and here’s what we’ve decided to accept.” A conversation that results in decisions.
What to do Monday morning
List your top five security costs and your top five security outputs. The cost column is relatively easy: tools, staff time, consulting, audit fees. The output column is harder — that’s the point. Start here: which specific risks can you name that your programme treats? Which deals required your certification as a precondition? When was the last time you answered a customer security questionnaire with confidence rather than dread? Has your programme ever caught something before it became an incident? Those are outputs. If you struggle to fill five, that’s not a sign you’re spending too much — it’s a sign you can’t see what the spending produces. That’s the problem to fix.
Find one disproportionate control and right-size it. You almost certainly have a control that’s running at a depth that made sense for someone else’s risk profile, not yours. The quarterly business continuity test for a co-located team. The enterprise-grade change management process for a three-person deployment pipeline. The monthly vendor assessment for a SaaS tool used by two people. Pick one. Reduce it to a level that matches the actual risk. Document why — you’ve just practised proportionality.
Answer “what would we lose if we stopped doing this?” for three security activities. Pick three things your programme does regularly. For each one, honestly assess: if we stopped, what specific risk increases? What compliance gap opens? What business capability is threatened? If the answer is “not much,” you’ve found waste. If the answer is “a lot,” you’ve confirmed value. Either way, you know something you didn’t before.