Your first security hire will fail, and it's a management problem

You’ve thought about what you’re protecting, you’ve felt the commercial drag of security unreadiness, and you have a sense of what good security actually looks like. The natural next step is to hire someone.

That hire is probably going to fail, not because you picked the wrong person (they’re quite likely excellent) but because the job you’re handing them is impossible in its current shape.

I’ve watched this happen many times. The exec team are smart, the company is scaling well enough to keep the VCs happy, and there’s increasing pressure from customers or investors to “get serious about security,” so they hire someone. The candidate has a good CV, relevant experience, and genuine enthusiasm, but three months in the hire is often overwhelmed. Six months in, they’re either burned out or quietly looking for their next role, and the founder is frustrated. The hire is frustrated. Security is no further forward than it was the day they started.

It’s not a mis-hire. It’s a structural failure, and it starts well before the job ad goes live.

The impossible backlog

Your new security hire didn’t create your security debt; they just inherited all of it.

There’s no asset inventory; nobody can say with confidence what systems you run, what data they hold, or who has access. There are no documented security practices, because security has lived in your CTO’s head and a few Slack messages. There’s no vendor risk assessment even though you’re using forty SaaS tools and counting, and customer security questionnaires have been piling up, answered late or not at all. And there’s no prioritisation framework because everything feels urgent and nothing has been triaged.

That’s the backlog they inherit on day one. On day two, the operational load starts: an engineer has a question about authentication, a customer sends a 200-question security review, someone needs to evaluate a new vendor, and the board wants a security update for next month’s meeting.

There is no universe in which one person clears 18 months of accumulated debt while simultaneously handling the operational demands of a scaling company, all while trying to build credibility with engineers they need favours from and have no authority over. But that’s exactly what most founders ask them to do.

The title without the authority

You gave them a title. Head of Security, maybe even CISO. But you didn’t give them what actually makes that title work: budget, some planning priority, or visible executive support.

When your security hire pushes back on an engineering decision, deploying without a security review, granting broad production access to a whole new team, shipping a feature with a known vulnerability on a deadline, what happens? If the CTO overrules them and the rest of the execs stay quiet, you’ve told the entire company that security is optional when it’s inconvenient.

Air cover in this context means making clear, visibly and repeatedly, that security decisions have executive backing, not fighting the security hire’s battles for them. Without it, your security hire has responsibility without power, and that’s the fastest path to burnout in any role.

The same pattern plays out with budget. If every security tool purchase requires a fight, if there’s no budget line for security, if every request gets deferred to “next quarter,” your hire learns quickly that the organisation isn’t serious, regardless of what you said in the interview.

There’s a second dimension here. Even when formal authority is limited, and in a startup it always is, effective security people can learn to lead without it. They build influence through relationships, through being useful, through making engineers’ lives easier rather than harder. That skill matters.

The problem is that most early and mid-career security people have never been taught how. Leading without authority in the fluid mess of a startup’s decision-making isn’t intuitive, and nobody trains for it. So you have a hire with no formal authority and no experience operating without it, trying to change behaviour across an organisation that didn’t ask for their input.

I’ve pulled too many traumatised early security hires out of this situation to accept it as inevitable. It’s a management failure: the exec team didn’t set up the conditions for success, and nobody equipped the hire for the conditions they actually found.

The missing context

Here’s a subtler failure mode: your security hire is competent, you’ve given them some authority, and the backlog is large but manageable, yet they still build the wrong programme.

Why? Because nobody told them what the business actually needs from security.

Without clear answers to the questions that should be driving your security decisions (what are you protecting, what are you willing to risk, what’s the minimum you need right now) your security hire defaults to what they know. They build a security programme from a textbook: policies, frameworks, controls mapped to ISO 27001 or SOC2, a comprehensive risk register.

It’s all correct and all professional, and most of it is irrelevant to your specific 70-person Series A startup that needs to pass customer security reviews and not get breached.

Your hire isn’t wrong for building this way; they’re doing what security professionals are trained to do. The exec team is wrong for not giving them the business context that would have shaped a completely different set of priorities.

The wrong profile

Even if you fix the backlog, the authority, and the context, there’s still a common failure mode: you hired the wrong profile for the stage you’re at.

The three most common misfires:

The manager: someone senior, credentialed, and strategic who comes from a big consultancy or a large corporate security function and is used to managing or advising rather than doing. They produce beautiful slide decks, risk frameworks, and maturity models, and little of it gets implemented because there’s nobody to implement it. They become expensive and disconnected from the daily reality of your engineering team. At this stage you need a doer, not a strategist without hands.

The junior engineer: someone technically sharp who can find vulnerabilities and harden systems, but the role demands far more than technical skill. They need to explain risk to the board in business terms, push back on a CTO’s architecture decision diplomatically, influence engineers who don’t report to them. These are skills that take years to develop, and you’ve dropped someone into a role that requires all of them from day one.

The title collector. This may be the worst fit. Someone who wanted the CISO title for their LinkedIn profile more than they wanted the work. They’ve collected a string of 12-18 month stints at startups, each time arriving with grand plans and leaving before the hard operational work is done. They’ll talk strategy and attend conferences, but configuring tools, answering a tedious customer questionnaire, or sitting with an engineer to debug an access control problem is beneath them, even as they stretch themselves thin trying to do everything.

I’ve interviewed a fair number of these candidates over the years. The tell is usually that they can describe their strategy for your company in detail before they’ve asked a single question about it.

What you actually need at this stage is a player-coach: someone who can configure your SSO in the morning, review a customer security questionnaire after lunch, and sit with your CTO to discuss the security implications of a new product architecture before end of day, and who enjoys all three.

That last part matters more than the CV. The right person at this stage isn’t someone tolerating hands-on work while they wait to build a team. They find satisfaction in fixing a misconfiguration, getting a clean SOC2 evidence set together, and helping an engineer think through a secure design, all in the same week.

The title compounds the profile problem. Calling someone “CISO” at a 60-person company attracts candidates who want the title for their CV more than they want the work. It also sets expectations, internally and with customers, that don’t match what one person can deliver. “Security Lead” or “Head of Security” are more honest titles and attract a different pool. And you will find it very difficult to hire someone more experienced above a “CISO” later, which is a brutal position for a scaling startup.

This is a management failure

If you’ve recognised your own company in any of the above, the uncomfortable truth is that this is a management failure, not a hiring failure, and it’s one that nearly every scaling startup makes because nobody tells founders how to set up a security function before they hire into it.

Any one of these four problems, the backlog, the authority gap, the missing context, the wrong profile, is enough to sink the hire. Most companies have at least three of them running simultaneously.

The result is predictable. The hire “fails.” The founder concludes “security people don’t understand startups.” The departing hire concludes “that company wasn’t serious about security.” Both walk away with the wrong lesson, and the pattern repeats with the next hire.

The groundwork that changes this

Fixing these failure modes is specific, bounded work, and it starts before you write the job ad.

The preparatory phase that most companies skip has concrete deliverables: working through the three questions so your hire inherits clear priorities rather than a blank sheet, triaging the backlog so they face something manageable rather than 18 months of accumulated debt, building the reusable artefacts that external scrutiny demands so they’re not starting from scratch, and defining what the role actually needs to look like at your stage so you attract the right profile.

This is typically a few months of work, a few days a month, and it benefits from someone who’s seen the pattern across multiple companies rather than someone learning your specific context from zero. A fractional security leader or experienced advisor can build this foundation, and the full-time hire who comes after walks into a job that’s actually possible.

Skip this phase and you’re back at the top of this article in six months with a different name on the resignation letter.