Raise the Floor Before You Raise the Ceiling

Most security teams don’t struggle with knowing what to improve. They struggle with knowing when to stop improving one thing and move on to the next.

TL;DR

• Not about vulnerability remediation. That already has a risk-based process telling you what’s next. This is about proactive work, where nothing does.
• Proactive security has no finish line, so it’s easy to over-invest in one area long after it stopped being the weakest.
• Attackers take the path of least resistance. Your risk is set by your weakest capability, so effort pays off most at the floor.
• Prefer coverage over depth. A capability that broadly covers the environment beats one that’s exquisite in a corner and absent everywhere else.
• Raise the floor across the organisation before raising the ceiling of any single system.

First, what this is not

If a scanner, pen test, or incident is telling you to fix something, ignore this post. That work already comes with a prioritisation engine: severity, exploitability, impact. The next thing is handed to you.

This is about the proactive half of the job: the projects you take on before anyone forces your hand, like network segmentation, IAM, detection, or hardening a pipeline. Nothing tells you when one of these is “done enough.” That’s where the mistake creeps in.

The problem: no finish line

Should you improve your NetworkPolicies? Refine IAM? Tune detections? All legitimate, none with a natural endpoint. There’s always a more granular policy, a wildcard to remove, a rarer attack to detect.

So the failure mode isn’t picking the wrong thing. It’s continuing to optimise one area long after it stopped being the organisation’s weakest capability. It happens because the momentum and expertise are already there, the wins are easy to measure, and the next-weakest area is often unfamiliar or owned by someone else. Sunk cost in a lab coat.

The attacker doesn’t care about your best work

Attackers take the path of least resistance. They don’t admire your strongest control; they find the weakest and walk through it. So your risk isn’t set by your average capability, and definitely not your best one. It’s set by your weakest one.

Beautifully granular NetworkPolicies do nothing if an attacker lands in a namespace that emits no logs and moves laterally on an over-permissioned account. Every hour spent lifting your lowest capability closes the path an attacker is most likely to take. Every hour perfecting your highest one defends a path they’d never bother with.

What this looks like in the wild

Three examples. Each starts from a genuinely healthy place, because that’s when the temptation to over-optimise is strongest.

1. Kubernetes NetworkPolicies: polishing one wall while another has no coverage

Picture a Kubernetes platform in solid shape. No critical vulnerabilities. The major hardening is done. The obvious risks are handled. The team rolls out NetworkPolicies, and the early wins are big:

• Sensitive workloads get isolated.
• Unnecessary east-west traffic is blocked.
• The attack surface shrinks.

So far, so good. Then the next several months go into making every policy more granular and chasing every edge case. Meanwhile workload identity and centralised logging haven’t reached the same maturity. The wall the team keeps building is already tall. The gap two capabilities over is the one an attacker would actually use, and it’s getting no attention because the interesting work is elsewhere.

2. IAM least privilege: perfectionism with no attacker on the other side

The IAM environment is already good:

• MFA is enforced.
• Privileged access is controlled.
• The obviously excessive permissions are gone.

So the next goal becomes perfect least privilege. Weeks turn into months hand-crafting policies to remove the last wildcards and shave permissions to the exact action. This is honest, careful work. But the risk delta from “no glaringly over-permissioned roles” to “mathematically perfect least privilege” is small and shrinking, and no realistic attacker is being stopped by that last increment. That same time could have stood up a capability that currently doesn’t exist at all.

3. Detection engineering: sharpening the signal while parts of the map are dark

The SOC has good visibility:

• Critical logs are collected.
• High-risk detections are live.
• Responders have what they need.

The team keeps improving: false positives drop, rare attack scenarios get bespoke detections, the dashboards get genuinely sophisticated. And meanwhile, parts of the environment produce no logs at all. You cannot detect what you cannot see. A dark corner with zero telemetry is a far bigger risk than a slightly noisy rule in a corner you already watch closely. The team is sharpening the signal where the signal already exists, while blind spots stay blind.

The shape is the same every time. None of the work is bad. The question is never whether it should be done. It’s whether it should be done now, ahead of the weakest thing you’ve got.

A way to decide

You don’t need a heavy framework.

1. List your capabilities as capabilities, not projects: identity and access, network segmentation, secrets, logging, detection, endpoint hardening, vuln management, backup, data protection, supply chain.
2. Score each on coverage. Precision doesn’t matter; honesty does.

Level	Coverage	Meaning
0: Absent	None	Doesn’t really exist. Parts of the environment are wide open.
1: Partial	Some	Exists in places, with real gaps an attacker could walk through today.
2: Baseline	Broad	Covers what matters. Remaining work is refinement, not gap-closing.
3: Advanced	Broad + deep	Well beyond baseline. Each further increment is small.

3. Work your lowest scores, not your backlog. A single 0 almost always beats any further work on something at 2 or 3. Moving 0 to 1 closes paths that are open right now; moving 2 to 3 refines a path that’s already closed.

The question that settles most cases:

Would this month of effort reduce more organisational risk somewhere else?

If yes, that’s your next priority. If you genuinely can’t find anywhere it would do more good, raise the ceiling. Just make that a real bar, not a formality you wave through because the current work is comfortable.

When to raise the ceiling anyway

The rule is a default, not a law. Depth in an already-strong area is right when:

• A regulation or contract mandates it. The floor is defined for you.
• Genuine crown jewels justify defence in depth. For the few systems whose compromise would end the company, stacking depth on top of a baseline is legitimate.
• The improvement is a force multiplier. Strong identity, a solid logging pipeline, good asset inventory: deepening these raises the floor of everything else, so it’s floor-raising in disguise.

All three either define the floor externally or raise it for other capabilities. Ceiling-for-its-own-sake on one strong system while a 0 sits elsewhere is the thing to avoid.

If you do nothing else

The objective of a security program isn’t one exceptional capability. It’s having no capability dramatically weaker than the rest, because that’s the one an attacker finds. Do the coverage scan, fix the lowest score first, and before extending any already-good area, ask whether that month would reduce more risk somewhere else.

Raise the floor first. Raise the ceiling later.