Something feels wrong with your security function, but you can’t quite name it. The security team (often just one or two people at this stage) is clearly working hard, there are meetings and updates and things being looked at, and yet nothing seems to get resolved. Engineering is frustrated. Sales is frustrated. There’s a low-level anxiety every time security comes up, which is increasingly often, and no clear picture of whether anything is actually improving.
This is a recognisable pattern, and it’s worth naming it clearly before it names itself in a worse way.
Part one: is it drowning?
The signals are visible from the outside, if you know what you’re looking at. Most founders and CTOs I’ve worked with describe some version of the following before they formally acknowledge a problem exists.
Commitments are being missed. Not dramatically, and not all of them, but consistently enough to notice. Audit evidence that was supposed to be ready isn’t, the security review that was promised for a customer renewal hasn’t landed, and the policy documentation that engineering needed last week is still being worked on. Each individual miss has an explanation, but the pattern is harder to explain away.
Response times are slipping on everything. Routine requests are taking longer than they should: a vendor to assess, a question from engineering about an authentication decision, a compliance question from the sales team. The answers when they arrive are sometimes incomplete or hedged in ways that don’t help the person who asked. Security has likely become a bottleneck rather than a resource, and the rest of the organisation is starting to route around it.
Security is doing work that belongs elsewhere. Audit evidence collection has often quietly become security’s job because it was easier for every other team to hand it over than to learn what was needed. Technical compliance questions that may well sit with a compliance function are being handled by security because nobody else has built the knowledge. Security people find themselves in the critical path on commercial deals and renewals, not because anyone decided that was appropriate, but because nobody else wanted to spend the time. Every team made a reasonable individual choice and the cumulative result is that security is typically carrying work that would occupy two or three roles in a more mature organisation.
Engineering and security are in a friction pattern. Not outright conflict, usually, but a grinding low-level tension where security is seen as slowing things down and security feels like nobody takes them seriously. Both sides are probably partially correct about the other. This friction tends to produce one of two outcomes, and in particularly toxic cases, two of two outcomes: security gets quietly bypassed on decisions where it should have a voice, or security becomes increasingly rigid in compensation, neither of which is useful.
Management is getting no usable signal. Updates to the board or leadership are infrequent, and when they do arrive they’re either very detailed in ways that don’t land or reassuring in ways that don’t quite convince. Feedback from leadership generally doesn’t seem to produce any visible change in what the security function is working on. There’s a low-level unease about security that you can’t quite resolve because you can’t get a clear picture of what’s actually happening.
The security team appears to be working constantly. This looks like dedication, or misuse of illegal stimulants, and perhaps it is, but constant high-tempo work without clear progress is usually a sign of something structural rather than a workload problem. If the answer to “what are you working on” is “everything, all at once,” that’s a prioritisation failure, and prioritisation failures at this level are rarely the security function’s fault.
None of these signals alone is definitive. Three or more of them together, persisting over more than a month or two, is a pattern worth taking seriously.
The timing problem
By the time these signals are visible and named, the security team is often so deep in the weeds that they can’t see a way out. The window for intervention is earlier than most founders realise, and it closes faster than they expect.What you’re probably not seeing
The signals above are visible from the outside. What’s harder to see is what’s producing them.
Security roles at scaling companies tend to accumulate scope in a particular way: everything that touches security, or might touch security, or that nobody else wants to own, ends up with the security function by default. The mechanism is simple and consistent across companies. Every team makes the same calculation: this security-adjacent thing is important, security seems to think it matters, and I’d rather not do it, so I’ll let it flow to them. With little management support and few prioritisation tokens to spend pushing back, security tends to absorb it all. The result is a function carrying work that was never designed into the role and that no single person, or even a small team, can sustain.
Alongside scope, there’s usually an authority gap: the security team has responsibility for outcomes they don’t control, and they can identify a risk in an engineering decision but can’t compel a change, flag a vendor concern but can’t stop a procurement, push back on a product deadline but have no standing in the conversation where that deadline was set. Over time this often produces a particular kind of exhaustion, the work of identifying problems repeatedly without the power to resolve them.
In one company I worked with, the authority gap traced back to a single decision made eighteen months earlier: they’d hired a junior IT person pivoting into security because junior was light on the budget, and the organisational weight that a more experienced person would have carried simply wasn’t there. In other words, they bought cheap and got organisationally inexperienced.
The missing piece that compounds both of these is executive clarity. In most companies where this pattern is playing out, nobody has had repeated, regular and clear conversations with the security function about what it’s actually supposed to be achieving at this stage, what trade-offs are acceptable, and what it is not expected to do. The security team is likely operating on assumptions, some of which are probably wrong, and there’s no mechanism for correcting them because the feedback loop between security and leadership has broken down.
Part two: what can you do about it?
There are four realistic paths out of here, three of which require a decision. The fourth is what happens if you don’t make any.
Path one: organisational reset
This is likely the right path when the security team is capable and motivated but the conditions around them have become unworkable. It requires the founder or CTO to own the intervention directly, because the problems are structural and structural problems rarely fix themselves.
In practice this typically means several things happening in sequence. First, an honest audit of what the security function is currently doing versus what it should be doing at your stage, which will almost certainly reveal a significant gap between the two. Second, a deliberate descoping: things that have accumulated onto the security function by default get redistributed, handed back to the teams that should own them, or deprioritised explicitly rather than left as a permanent undone item. Third, a clarification of boundaries with IT and engineering, ideally in a meeting where the security team is present and the exec team’s backing is visible. Fourth, a realistic plan that the security team helped shape, with three or four specific deliverables rather than an infinite list of everything that needs fixing.
Visible executive support in this context means something specific: the CTO or CEO showing up in the early cross-functional conversations, reinforcing decisions publicly when engineering or commercial teams push back, and being explicit with the rest of the organisation that security has a specific mandate.
It’s quite different to saying “we support security” in an all-hands.
This path is available when the security team still has energy and belief that the situation can change. It closes when they’re far enough into burnout that recovery seems unlikely, or they’ve submitted their resignation.
Path two: external decompression
Sometimes the backlog is so large, or the operational load so continuous, that the security team has no capacity to step back and think, even if the organisational conditions improve. In these cases, bringing in external support for a defined period can decompress the situation enough to let path one work.
External support in this context isn’t a replacement for the security team; it’s triage: clearing the backlog that’s been accumulating, getting the prioritisation framework established, handling the customer security reviews that are piling up, and generally creating the breathing room that allows the security team to start building rather than firefighting. The outcomes I’ve seen from this approach tend to be considerably better when the security team is actively involved in shaping what the external support does, so they inherit a programme rather than someone else’s decisions.
Path three: managed transition
If the security team isn’t right for the role as it actually exists at your stage, the kindest and most practical thing is generally to handle the transition carefully rather than letting it drag. Badly managed departures frequently take the institutional knowledge with them, leaves the function leaderless at a moment when it needs direction, and damages the credibility of the security function with the rest of the organisation.
A managed transition means several uncomfortable things done well. It means telling the person directly that the role as currently scoped isn’t working and what it actually needs to look like, not hinting at it in performance reviews or hoping they’ll draw their own conclusions. It means giving them enough runway to hand over properly rather than escorting them out before the institutional knowledge goes with them. And it means sitting down and extracting that knowledge deliberately: what’s in progress, what’s been deferred and why, where the compliance programme actually stands versus where the documentation says it does, which customer commitments have security dependencies nobody else knows about. Most of this will not be written down anywhere. Most of it lives in one person’s head. If you don’t get it out before they leave, you’ll spend the first three months of the next hire’s tenure rediscovering it.
Path four: doing nothing
Path four isn’t really a path; it’s the trajectory you’re already on if you recognise the pattern and don’t intervene.
The sequence is fairly consistent: members of the security team, having been stretched past the point of recovery, leave, sometimes with a resignation that feels sudden but has been coming for months. Whatever institutional knowledge they were carrying leaves with them, the context on customer commitments, the state of the compliance programme, what’s actually been done versus what’s been deferred. The security function m even go dark or reverts to being nobody’s job, well the CTO has a few hours a week, right? The problems that were accumulating before accelerate as a result. Engineering makes decisions without security input and customer questionnaires go unanswered or get answered badly. The compliance programme stalls. A new hire, when you eventually make one, inherits the same conditions that broke the last person, and it’ll happen a bit faster this time.
Act before you are forced to
I’ve been brought into the situation where nothing was done for too long, more than once. It’s generally recoverable, but it typically takes longer and costs more than any of the first three paths, time and money that I’m confident you’ve got much better uses for.
If you’re recognising three or more of the signals in the first section, the question probably isn’t whether something is wrong; it’s which path is still available to you.
The honest answer to that question usually requires someone who’s seen the pattern before to look at the specifics. The signals are fairly consistent; the underlying causes vary more than they appear to from the outside, and the most supportive approach to take which will have positive business outcomes isn’t that obvious.
That said, almost any positive intervention is better than nothing for these situations.