"When should we make our first security hire?" It's the most common question I get from founders. The honest answer is somewhere between 20 and 200 employees, depending on what you're building and who you're selling to.
That's a wide range. This guide will help you narrow it down.
The tension
Bessemer Venture Partners notes that startups are incredibly vulnerable to cyberattacks in their first 18 months. That's true. But it's also the period when security makes the least sense relative to finding product-market fit. If there's no business, there's nothing to secure.
This creates a real tension. You're accumulating risk every day you operate without thinking about security, but spending on security before you have a viable business is money you don't have solving a problem that might not matter yet.
The good news: you don't need to hire someone to start doing security. You need to hire someone when security becomes an unavoidable distraction from scaling your business. Before that point, there's a lot you can do yourself.
Before the hire
A lot of meaningful security progress can be made without a security team. Ryan McGeehan, who led security at Facebook and Coinbase, argues that startups should task existing engineering talent with security projects and get short-term guidance from external expertise rather than rushing to hire.
I broadly agree with this. Your existing engineers are already making security decisions every day—how they handle authentication, how they manage secrets, how they configure cloud infrastructure. The question isn't whether engineers should do security work. They already are. The question is whether they're doing it well.
Here's what you can do before your first hire, most of it in a focused weekend:
- MFA on everything. Every account that touches infrastructure, code, or production. No exceptions for founders or contractors.
- Password manager for the team. Bitwarden or 1Password. Shared credentials go here, nowhere else.
- Secrets out of code. Run TruffleHog or GitGuardian against your repos. You'll probably find something.
- Cloud hygiene. No public S3 buckets. No overly permissive IAM roles. Separate prod from non-prod accounts. Never use root credentials for daily operations.
- Enable audit logging. Turn on CloudTrail (or equivalent). Even if nobody reads the logs yet, you'll want them later—the average time to discover a breach is 181 days.
- HTTPS everywhere. Every endpoint your product exposes.
Total cost: under $1,000. This baseline covers the attacks that actually hit startups—opportunistic, automated scripts scanning for exposed keys, misconfigured buckets, and unpatched services. Not nation-state adversaries.
The uncomfortable truth
If your engineers need someone else to care about security for them, the problem isn't the lack of a security hire—it's the quality of your engineering culture. A dedicated security person can raise the bar, but they can't be the only one who cares.
McGeehan puts this more bluntly: hiring a dedicated security person too early can create a culture where everyone assumes "the security team" will handle those pesky security problems for them. First Round Capital makes a related point: most startups are exposing customers to more risk than they realise. That's hard to avoid early on, which is exactly why the basics that scale—MFA, secrets management, access control—matter so much.
Signals it's time
The commonly cited rule of thumb is to hire your first security person between 30 and 100 employees. In my experience, the real range is wider—roughly 20 to 200—depending on what you're building and who you're selling to.
Closer to 20 if you're building something high-trust: storing financial data, health records, or handling sensitive communications. If you're in a regulated industry or your product is a critical part of your customers' infrastructure, security isn't optional at any size.
Closer to 200 if security isn't core to your product and your engineering team has been handling the basics well. Plenty of startups operate at this size without a dedicated security person, though they're usually starting to feel the strain.
Headcount is a rough proxy. The real signals are situational:
Enterprise customers are asking hard questions
When you start landing enterprise deals, security questionnaires appear. At first, the CTO can handle them. But when you're getting multiple 200-question assessments per quarter, each taking 20+ hours, someone needs to own this. If security questionnaires are blocking revenue, that's a clear signal.
Compliance is becoming unavoidable
Customers requiring SOC 2, ISO 27001, or HIPAA compliance need someone to build and maintain the systems behind those certifications. This isn't checkbox work—it's a sustained effort.
You're handling sensitive data at scale
Once you're storing meaningful amounts of customer PII, financial data, or health information, the stakes change. A breach at this point isn't just embarrassing—it can end the company. Nearly 60% of attacked small businesses fail within six months without recovery funding.
Security is slowing engineering down
When your engineers are constantly context-switching—reviewing dependencies, responding to vulnerability alerts, answering customer security questions—it's a sign. Add up all the time your team spends on security-adjacent work each week. If it adds up to a full-time person, you should hire one.
You've accumulated security debt
Every month without dedicated security attention adds debt. Waiting six months too late means your first hire inherits a year or two of cleanup work on top of everything else. The longer you wait, the harder the ramp.
What role to hire first
This is where most startups get it wrong.
Your first security hire should be a hands-on security generalist—someone who can do and learn everything and anything. Not a CISO. Not a specialist. A generalist who is comfortable across product security, infrastructure security, compliance, and incident response.
The ideal candidate has been the first or second security hire at another startup before. They know what it's like to build a program from scratch, to wear every hat, and to operate without a team behind them.
A different view
Andreessen Horowitz advises portfolio companies to hire a CISO early. Joel de la Garza, who was CSO at Box from Series B through IPO, argues that security leadership is foundational. I disagree for most organisations. Early-stage CISOs typically aren't hands-on enough. They expect a team, a budget, and corporate infrastructure that doesn't exist yet. At a startup, you need someone who will roll up their sleeves and ship.
Think about which sub-function is causing you the most pain right now. Vanta suggests identifying whether the pressure is coming from customer assurance (sales stalling on questionnaires), product security (you need someone reviewing code), or compliance (SOC 2 is required). Hire for the pain you're actually feeling, not an abstract security org chart.
That said, even if the immediate pain is compliance, don't hire a pure compliance person. Your first hire needs to be technical enough to review code, pragmatic enough to handle a questionnaire, and articulate enough to talk to a customer about your security posture. They need to be able to learn on the job, because the job will change every quarter.
The advisor bridge
There's a gap between "we're handling the basics ourselves" and "we need a full-time hire." That gap is where an advisor comes in.
An experienced security advisor can help you make the right foundational decisions, unblock enterprise deals, prepare for compliance, and define the role for your eventual first hire. This is different from a fractional CISO, which I don't recommend for most startups. A fractional CISO implies an ongoing operational role that often doesn't map well to how early-stage companies actually work. What you usually need is someone you can call when you hit a security question you can't answer yourself.
Georgian Partners recommends designating an existing team member (usually the CTO or a senior engineer) to own security, with an advisor providing guidance. I think this is the right model for most startups pre-hire. It keeps security embedded in engineering rather than siloed, and it costs a fraction of a full-time salary.
When the advisor starts telling you they can't keep up with the volume of work, it's time to hire.
Common mistakes
I see these patterns repeatedly:
Creating a "security babysitter" culture
The moment you hire a security person, there's a risk that everyone else stops thinking about security. "That's the security team's job now." This is the single most damaging outcome of a security hire. Security is an organisational commitment, not a one-person department. McGeehan warns against creating a culture where a security team babysits security for everyone else. Your first hire should make the whole team better at security, not replace everyone else's responsibility.
Hiring too senior
A CISO from a Fortune 500 company sounds impressive, but they're used to having a team of 50, a seven-figure budget, and established processes. At your startup, they are the team. Make sure they can and want to do hands-on work. If they expect to spend their days in board meetings and strategy sessions, it's the wrong fit.
Assuming junior won't work
Conventional wisdom says your first security hire needs years of experience. I've seen the opposite work well. A junior person who is hungry to learn, has no biases about how things "should" be done, and is willing to do whatever it takes can be a great first hire. They need to be a genuine self-starter—autonomous enough to figure things out without hand-holding—and they'll need some mentorship, whether from an advisor or from peers. But the combination of energy, adaptability, and no baggage can outperform a mid-career hire who wants to run a playbook from their last company.
Hiring too specialised
A very senior person who spent their career in penetration testing and that's all they want to do is the wrong first hire. Same goes for someone who only wants to do compliance, or only wants to do detection engineering. Your first security hire has to be able to do everything—and be willing to learn the parts they don't know yet. Specialists come later, when you have a team.
Treating security as purely technical
Security is cross-functional. Your first hire will need to work with engineering, legal, sales, and executive leadership. They'll field customer calls, help close deals, interpret regulations, and explain risk to the board. If you hire someone who only speaks in CVEs and CVSS scores, they'll struggle to have impact. Look for someone who can translate security into business language.
Expecting one person to fix everything
A common misconception is that a security hire is a turnkey solution. Working toward security is an organisation-wide decision that affects almost every part of the business. Your first hire can lead the effort, but every department head needs to be prepared to contribute.
Summary
- The range is 20 to 200 employees. Closer to 20 for high-trust, regulated products. Closer to 200 if your engineering team handles the basics well.
- Product-market fit comes first. If there's no business, there's nothing to secure. But the basics (MFA, secrets management, cloud hygiene) cost almost nothing and should happen from day one.
- Use an advisor before you hire. An experienced advisor bridges the gap and helps you define the right role when you're ready.
- Hire a generalist, not a CISO. Your first hire needs to do everything—compliance, code review, customer calls, incident response. Specialists and executives come later.
- Watch for the signals: enterprise sales pressure, compliance requirements, security debt accumulating, engineers drowning in security work.
- Avoid the babysitter trap. Your first hire should make the whole team better at security, not replace everyone else's responsibility.
If you're not sure whether you're ready, reach out. I'm happy to chat through your specific situation.
Further reading: Starting Up Security by Ryan McGeehan, First Round Review on startup security, Rami McCarthy on the first security hire, Tad Whitaker on security staffing ratios.
This post is part of a series on startup security. Next up: "The Startup Security Tech Stack"—a guide to every tool you need (and don't need) at each stage.