The Overwhelm
People do the minimum because they’re overwhelmed, not because they’re lazy — and the problem is structural, not personal.
Here’s a job description. You’ll recognise it:
Security & Compliance Lead. Responsible for maintaining the organisation’s security programme, including risk management, policy development, access control, vulnerability management, incident response, vendor assessment, business continuity planning, security awareness training, audit preparation, regulatory compliance, and liaising with authorities. Reports to the CTO. Must be familiar with ISO 27001, SOC 2, GDPR, NIS2, and relevant industry frameworks. Experience with cloud security, application security, and network security preferred.
That’s one hire. One person. Expected to understand and manage multiple security functions, every relevant compliance framework, operations, and stakeholder relationships. Reporting to a CTO who has twenty other priorities and a limited security budget.
Nobody can do this job.
I don’t mean it’s difficult. I mean it is, by definition, too much for one person. The breadth of knowledge required spans legal, technical, operational, and strategic domains. The depth required in each domain is constantly increasing as frameworks expand, threats evolve, and regulations multiply. The workload — reviews, assessments, evidence collection, meetings, firefighting — fills whatever time is available and then overflows.
Yet this job exists, in a similar form, at many organisations with fewer than 200 people. One person, or at most a small team, expected to deliver something that a large enterprise spreads across twenty specialists.
The result is overwhelmed people and under-resourced security. And overwhelmed people default to the minimum — not because they don’t care, but because the minimum is all that’s achievable given the impossible scope of what’s expected.
The impossible job
Let’s get specific about what the security lead at a mid-size organisation is actually responsible for, because the job description doesn’t capture it.
Understanding the frameworks. ISO 27001 has 93 controls across four categories. SOC 2 has five trust service criteria. NIS2 has ten categories of measures. GDPR has its own security requirements. Each framework has its own language, its own logic, and its own interpretation in practice. Keeping current with one framework is a meaningful professional investment. Keeping current with three or four, while understanding how they overlap and where they diverge, is a specialisation in itself.
Managing risks. Identifying what could go wrong, assessing likelihood and impact, mapping risks to assets, determining whether existing controls adequately treat each risk, and updating all of this when the environment changes — which it does constantly. A new vendor, a new product feature, a new regulation, a staffing change, a vulnerability disclosure, an AI tool a team adopted without telling anyone. Each one can change your risk landscape.
Tracking assets. Every important system, service, data store, vendor, tool, and piece of infrastructure the organisation depends on. What it does, who owns it, what data it processes, who has access, when it was last reviewed. In a growing organisation, this inventory used to change monthly. Nowadays it can change weekly, if not daily. Keeping it current is a task that never ends and never feels done.
Proving controls work. Every control needs proof that it’s operating, and that it’s sufficient. Access reviews need evidence of the review. Policies need evidence they were approved and acknowledged. Incident response needs evidence of the triage and lessons learned. Vulnerability management needs evidence of the remediation. This evidence needs to be collected, stored, organised, and retrievable — for multiple frameworks, on different schedules.
Responding to everything else. Security questionnaires from customers. Staff questions about what’s allowed. Board-level requests for security status. Audit preparation. Vendor security assessments. Training sessions. Policy exceptions. Change approvals.
Each of these is a necessary part of security work. Together, they are more than any person or small team can manage with consistent quality. So, something will slip. Something always does.
The question isn’t whether the security lead is good enough. It’s whether the structure they’re working within is too much for a human being.
Competing priorities are the default
It’s not that often that security is someone’s only job.
At companies with fewer than 100 people, the security lead is usually also something else. The CTO who handles security alongside product and engineering leadership. The IT manager who handles security alongside helpdesk, procurement, and office infrastructure. The compliance manager who handles legal, personal data protection, and security. The founder who handles security on the side of everything else. And so it gets the time that’s left after the primary role is served. Because the primary role always has more immediate deadlines, more visible stakeholders, and more direct consequences.
Normally, nobody gets fired for a late risk review. But people do get fired for a missed product launch, a failed customer implementation, a blown quarter. The incentive structure is unambiguous: the primary job comes first, and security gets whatever time remains.
This isn’t a motivation problem. It’s a calendar problem. When the CTO has six hours of meetings, two hours of monthly one-to-ones, and a board presentation, the quarterly risk register update doesn’t happen. They know it’s important. There are literally not enough hours.
The industry’s answer to this is “get executive buy-in” and “make security a board-level priority.” This is well-meaning and useless advice. Watch it play out anywhere: the board has a security agenda item. The CISO presents the risk posture. The board agrees security is critical. Everyone nods seriously. The budget discussion is scheduled. The meeting ends. The CTO goes back to their desk, opens their calendar, and finds the same wall of product meetings, customer escalations, and hiring pipeline that was there before the board meeting. Security is now a board-level priority. The calendar is unchanged. The quarterly risk review doesn’t happen that month either.
Agreeing that something matters doesn’t create time. It doesn’t reduce the competing demands on the only person qualified to do the work. It just adds guilt to the overwhelm.
One more consequence of the overwhelm deserves its own section, because it’s the one that causes the most damage.
The knowledge concentration problem
In most mid-size organisations, the security programme lives in one person’s head.
Not entirely — there are documents, spreadsheets, policy files, evidence folders. But the understanding of how it all fits together. What’s current, what’s stale, where the gaps are, what the auditor will ask about, which vendor is overdue for review, and what the risk register actually means in operational terms. That knowledge exists in one person’s mental model and memory. One person’s grasp of the connections between hundreds of entities.
Documentation was never going to hold it. The programme is too interconnected and too context-dependent to externalise with disconnected tools. You can write a risk register in a spreadsheet, but the spreadsheet doesn’t know that Risk 7 is connected to Asset 12, which depends on Vendor 3, which is protected by Control 22, which satisfies Requirement A.5.15. The person knows this.
When that person goes on holiday, things slow down. Decisions wait; questions pile up until they return.
When that person leaves, things break. The next person inherits a collection of documents — policies, spreadsheets, evidence folders, ticketing systems — without the mental model that connects them. They can see the pieces. They can’t see how the pieces fit together, which ones are current, which ones are fiction, and which ones matter.
When the transition happens, the new security lead spends their first three months not improving the programme but understanding it — trying to reconstruct the mental model that their predecessor built over years. During those three months, the programme runs on autopilot, which in practice means it degrades. Reviews are missed. Evidence gaps widen. The next audit becomes harder than it should be. And every issue discovered during those months gets explained the same way: the last person’s fault. More on that in the next chapter.
You can’t succession-plan a mental model. The failure is structural — the programme depends on a resource (one person’s memory and understanding). By definition, that is fragile. People leave, get sick, sometimes burn out. When the programme can’t survive any of these events, it won’t survive the ones that come from outside.
Here’s something few of us admit openly, because admitting it feels like professional failure: many security professionals are quietly terrified they’re missing something critical. Not the obvious things — those are covered. The things that keep you up at night are the things you don’t know you don’t know. The vendor that was onboarded without a security assessment because someone in marketing signed the contract. The legacy system that nobody monitors because it was supposed to be decommissioned two years ago. The access rights that were granted temporarily and never revoked.
These aren’t exotic scenarios. They’re the normal accumulation of decisions, shortcuts, and oversights that every growing organisation produces. In a connected system, they’d surface during routine reviews. In a disconnected one — the programme that lives in your head — they’re invisible until they cause an incident. The annual audit provides temporary relief: someone external looked and didn’t find a catastrophe. But the relief fades, because you know the audit sampled, not scanned. The blind spots survived. They always do.
This is the human cost of the knowledge concentration problem: the person holding it together is carrying the weight of gaps they can see and ones they can’t, with no way to tell what’s covered from what’s missing. Not just busy — busy and afraid.
The paralysis pattern
When you’re overwhelmed, everything feels equally important. That’s not hyperbole — it’s the actual cognitive experience of trying to manage a programme that spans more domains than you can hold simultaneously.
Say the risk register has forty risks — yours might have twenty-five or ninety; the arithmetic is the same. Which ones need attention this quarter? All of them, technically. But you have time for maybe five. How do you choose?
In most programmes, the prioritisation is a guess. You can see the risks. You can see the assets. But you can’t see the connections between them clearly enough to make confident decisions. Which risks are adequately treated? Which controls are working? Where are the real gaps, as opposed to the theoretical ones?
When you can’t answer these questions, you default to external authority. The auditor says focus here, so you do. The consultant recommends; you implement. The framework ranks its controls, and its ranking becomes your priority list. You’re not making decisions — you’re following instructions, because the complexity has exceeded your ability to reason independently about your own programme.
This is the paralysis pattern: compliance-shaped action driven by external direction rather than internal understanding. You’re busy. You’re doing things. But the decisions that would make the programme genuinely yours aren’t being made, because you don’t have the visibility to make them with confidence.
The clarity that would break the paralysis — seeing what connects to what, what’s treated and what isn’t, where the real gaps are — requires exactly the connected, externalised understanding that the overwhelm prevents you from building. That’s the trap. You need the map to navigate, but you’re too busy navigating to build the map.
The structural constraint
Working harder doesn’t fix the overwhelm — working harder is what got you here. The constraint is structural: the understanding of how your programme fits together lives in one person’s head, because the tools don’t preserve relationships. Spreadsheets store data. Documents store descriptions. Neither stores understanding. So the person becomes the system, and the system inherits all the fragility of being human.
To fix this, the understanding has to live outside the person: connections maintained by the system itself, blind spots that surface because the relationships reveal them, a map that exists independently of whoever drew it.
It starts with recognising the overwhelm for what it is: structural. The person isn’t the problem. The programme is.
Your compliance manager just resigned. How much of your security programme walked out the door with them? If the answer is “most of it,” you don’t have a programme — you have a person. And now you have neither.
What to do Monday morning
Take the bus test. If the person who manages your security programme was unavailable for a month — starting today — what would the next person be able to pick up from the documentation alone? List what they could find, what they could understand, and what they’d be stuck on. The “stuck” column is your knowledge concentration risk. It’s also the strongest argument you’ll ever make for investing in a connected, externalised programme.
Find security on the calendar — not in the management review deck. Open the next four weeks, yours or your security lead’s, and look for time where security work actually happens: someone running a review, updating the register, collecting evidence. Meetings don’t count — meetings are where the work gets discussed, assigned, and postponed. In many organisations the real footprint is zero: security gets talked about on the calendar and done in the gaps of somebody’s primary job. The fix is a standing block: two hours, recurring, defended like a customer meeting. If it keeps getting stolen, you’ve learned what outranks security.
Identify your top three blind spots. Not your top three risks — your top three areas where you suspect you don’t have visibility. The vendor category you’ve never assessed. The system nobody owns. The data flow nobody’s mapped. You won’t be able to verify whether these are actual gaps or false alarms — that’s exactly the point. The inability to verify is the problem.