How to make your first security hire and not regret it

If you’ve followed this series, you’ve seen the framework for security decisions, the commercial cost of unreadiness, what good security culture and good security leadership look like, why first hires fail, and when certification makes sense.

Now you need someone to do it.

This is one of the most consequential hires of this growth phase, not because security people are uniquely difficult to find, but because the consequences of getting it wrong compound quickly. A bad sales hire costs you perhaps a quarter in a specific market. A bad security hire can set you back a year or more, because the organisational damage, the lost engineering trust, the stalled compliance work, and the wasted budget don’t reset when the person leaves.

If you’ve done the groundwork from the earlier articles, you’re already ahead of most founders making this decision. That groundwork is necessary but not sufficient. The hiring process itself has its own failure modes, and the hire you need depends entirely on where you are in your growth.

Before you write the job spec

The most common mistake founders make when hiring for security is writing the job description before answering a more fundamental question: is the organisation actually ready for this hire?

This isn’t about whether you need security (you probably do) but about whether you can support a dedicated security person right now, and five things need to be true before you can, most of them within your control:

You know what you’re protecting, what risks you carry, and what’s proportionate at your stage. If you can’t articulate these clearly, your new hire may spend their first three months discovering the answers, which is expensive and demoralising for both sides. This is work you can do before you hire, and it shapes everything that follows.

You have achievable first-year goals. Not “build a security programme” but something specific: document current practices, establish a process for customer security reviews, create a basic incident response plan. Three or four things that one person can actually accomplish while handling the operational load.

The backlog has been triaged. Your hire shouldn’t inherit 18 months of undifferentiated security debt. Someone needs to have looked at the backlog and sorted it into what matters now, what matters this year, and what can wait. Handing them a prioritised list is very different from handing them everything.

You’re prepared to provide visible support. Budget, executive backing, and a reporting line that gives them access to the decisions that matter. If your plan is to hire someone and leave them to figure it out, you’re setting up the failure pattern we’ve already discussed.

You can describe what they’ll do in their first 90 days, not in general terms but specifically: which three or four things will they deliver? If you can’t answer that, you may not be ready to hire, though you may be ready to get help defining the role.

If several of these aren’t in place, consider whether fractional support to build the foundation is a better use of the next six months. A full-time hire into an unprepared organisation is almost always more expensive than getting the groundwork right first.

The hire depends on your stage

The person you need at 40 people is often fundamentally different from the one you need at 200. The Scaling Security model provides the frame: each stage has different priorities, different resource constraints, and different external pressures, and the hire should reflect where you are, not where you’d like to be in three years.

Most founders reading this are at one of two stages, and the hire is different for each.

At Early Traction: your first security person

If you’re between 15 and 150 people, probably Series A funded, and security is becoming a real concern but nobody has been dedicated to it, you’re hiring your first security person. Not a leader in the executive sense, but a builder and an operator.

The role is overwhelmingly operational. Your hire needs to document what exists, build basic processes, answer customer security reviews, and start creating the security culture that will scale with you. This is the player-coach from the earlier discussion of hiring failure modes: someone who configures SSO in the morning, reviews a customer questionnaire after lunch, and discusses authentication architecture with engineering before end of day.

What to look for.

The ability to work across the full range of the role: technical enough for credible conversations with engineers about architecture and controls, business-literate enough to explain risk without jargon, customer-facing enough to represent your company in security reviews. This is the translation skill in embryonic form.

Evidence they’ve built, not just advised. Ask about specific things they’ve created from scratch: a vendor risk process, an incident response plan, a compliance programme, a security review workflow. If every answer involves directing other people to do the work, they’re the wrong profile for this stage.

Comfort with imperfection. A startup security programme is never complete, never comprehensive, and always a set of deliberate trade-offs. The right hire understands this and can operate in that ambiguity without being paralysed by the gap between what exists and what they think should exist.

The ideal Tuesday test remains the best interview question for this hire. The answer reveals more about fit than any competency framework.

I’ve asked this question in dozens of interviews for roles like this. The candidates who light up when describing hands-on work are almost always the right ones. The candidates who pivot immediately to “building a team” are telling you what their first year actually looks like, and it isn’t what you need.

The title matters. Security Lead or Head of Security, not CISO. The CISO title at a 60-person company attracts candidates who want the title for their CV rather than the work. It sets expectations that don’t match what one person can deliver. And it makes it nearly impossible to hire above them later if the role needs to evolve.

They need visible founder involvement early on. The organisation has no security muscle memory yet. Your hire needs introductions to the people who matter, your presence in their early cross-functional conversations, and clear signals to the rest of the company that security has executive backing. This isn’t hand-holding but establishing credibility that the hire can then build on.

How they talk about failure matters, because every experienced security person has been part of something that went wrong. Ask about it. The ones who own their part, explain what they learned, and describe what they’d do differently have the self-awareness you need. The ones who only blame the organisation are telling you how they’ll operate when things go wrong at your company.

At Growth: your first security leader

If you’re between 100 and 500 people, Series B or C funded, and you either have a security person who’s reached their ceiling or you’re making your first hire at a stage where the role is fully executive, you’re hiring a security leader. This is someone who translates between board, engineering, and customers, who manages the tension between speed and safety, and who builds organisational capability rather than personal dependency.

The hiring process is different in several important ways, because at this level you’re selecting someone who will represent your company to the board, to customers, and to regulators.

The profile shifts. You still need someone who understands operational reality, but the balance tips towards strategic. They’re managing certification programmes, advising the board, building relationships with enterprise customers’ security teams, and potentially leading a small team. The ideal Tuesday answer shifts accordingly: more prioritisation decisions, more time on the trade-offs between business objectives and security requirements. But they should still be willing and able to roll up their sleeves when it matters.

The assessment changes because at this level you’re evaluating executive judgment as much as security expertise. How do they think about risk versus opportunity, and can they articulate what they’d stop doing if resources were cut? Do they understand that security at a scaling company is about enabling the business, not building a fortress?

The reporting line matters more. A security leader who reports to the CTO faces a structural conflict: they need to challenge engineering decisions while engineering controls their performance review. The pragmatic answer is reporting to the CEO, CFO, or General Counsel with a strong working relationship with the CTO. What matters most is access: they need to be in the room when decisions about architecture, product, and customer commitments are being made.

They may inherit a programme. If you had fractional support or a player-coach who built the foundations, the leader inherits a functioning programme rather than a blank sheet. This is the advantage of getting the sequence right: their first 90 days are about understanding and evolving what exists rather than building from nothing while simultaneously handling the operational load.

The recruiter brief

Whether you’re hiring a first security person or a first security leader, the brief you give your recruiter determines the candidate pool you see. Most security recruiting briefs produce the wrong candidates because they list certifications and years of experience rather than describing the work.

Tell your recruiter:

The stage, not the title. “We’re 90 people, Series A, first dedicated security hire. The role is hands-on with a path to strategic leadership.” This filters better than “CISO” or “Head of Security.”

The work, not the credentials. “This person will answer customer security reviews, build our compliance foundations, and do technical work alongside engineering daily. We need someone who enjoys that mix.” This attracts builders and operators.

The growth trajectory. “In 18 months, this role could grow into managing a small team and owning our certification programmes. Year one is mostly operational.” Honest expectations save everyone time.

What you’re not looking for. “We don’t need someone who’s managed a 20-person team or someone from a Big Four consultancy. We need someone who’s built something from nothing at a similar-stage company.” Being explicit about what you don’t want is as useful as describing what you do.

For a Growth stage leadership hire, adjust accordingly: emphasise the strategic balance, the board interaction, the need to manage existing programmes and people alongside continued hands-on involvement, and be explicit about whether the role manages a team or builds one.

Setting them up to succeed

Once the hire is made, the first few months determine whether the investment pays off.

Day one: hand them the context. If you’ve done the preparatory work, share it: what you’re protecting, what risks you’re carrying, the prioritised backlog, the customer pipeline and which deals have security dependencies. The more context they start with, the less time they spend discovering what you already know.

Week one: introductions that matter. Introduce them personally to engineering leadership, to sales, to the CTO, to anyone affected by security decisions. Personal introductions from you signal to the organisation that this person has your backing.

First month: listen more than fix. The best security hires spend their first month understanding reality before proposing changes. They talk to engineers about their workflows, sit in on customer calls, review existing documentation, and build a map of how things actually work versus how they’re supposed to work. The ones who arrive with a transformation plan on day three lose the engineering team’s trust before they’ve earned it.

First quarter: visible progress. They should deliver one or two things the organisation can see and feel: a cleaner customer security review process, a documented incident response plan, a vendor assessment that catches a real issue. Early visible progress builds credibility and buys time for the longer-term work.

This hire is worth getting right

The difference between a security hire who succeeds and one who fails comes down to preparation, not talent. The founder who has clear answers to the three questions, realistic first-year goals, a role shaped around the company’s actual stage, and a support structure that signals genuine commitment is the founder whose security hire is still there and thriving two years later.

If you’re reading this and thinking you’re not quite ready, that’s good judgment, not failure. Get the foundations right first, whether that means doing the three-questions work yourself, bringing in fractional help to build the base, or getting clearer about what you need. The preparation is what makes the hire work.

When you are ready: hire for the work that needs doing today, not the role you hope to have in three years. Find someone who wants the job you’re actually offering, give them the support to succeed, and then get out of their way.