The First Security Hire Isn't a Smaller CISO. It's a Different Job Entirely.

Most companies hiring their first security leader write the job description like a smaller version of a job they've seen at a bigger company. Own the roadmap. Manage the vendors. Report on posture. Build the team. It reads sensible, and it's the wrong shape for what the role actually is in month one.

A CISO at an established company inherits infrastructure: a SOC someone else built, a policy library someone else wrote, a budget line someone else fought for two years ago. A first security hire inherits none of that. They inherit a company that has been shipping product and closing revenue without them, and their first job isn't strategy. It's finding out where the actual exposure lives, because nobody in the building has been looking full time.

The wrong question is "when do we need a CISO"

There's a decent rule of thumb from Rami McCarthy, who's written the clearest version of this I've seen: hire your first security person when security becomes an unavoidable distraction from scaling the business. Not at a headcount number. Not at a funding round. Not when a customer's security questionnaire finally embarrasses somebody in a sales call. When the founders and engineering leaders are already spending real time on it, badly, because nobody owns it.

Michael Graham's benchmark puts a rough number on it anyway: somewhere between 30 and 100 employees for most companies. But the number is less important than what should already be true before that person walks in the door. Security work should already exist. Engineering should already be doing some of it, imperfectly, because nobody else was. The first hire's job isn't to invent the function from a blank page. It's to find what's already happening in the dark and give it a name, an owner, and a budget.

The pattern repeats almost everywhere I've seen it: the technical work was never the hard part. The hard part was figuring out who already had informal ownership of pieces of the problem and bringing them in rather than replacing them. An engineer who's been quietly running the only secrets rotation the company has isn't a gap to route around. They're the start of your access and identity program, and they'll resent you if you show up acting like they weren't already doing the job.

The instinct to bring in outside help too early comes from the same misreading of the role. A founder feeling exposed will sometimes reach for a consultant, an audit, or a vendor tool before they reach for a person, because those feel like faster progress. They're not wrong that something needs to happen. They're wrong about what. A tool doesn't know which of your three critical vendors actually has access to something that matters. A person spending their first month talking to every team that touches customer data does. The fastest path to real security maturity is almost never the fastest path to a dashboard with green checkmarks on it, and a first hire who understands that difference is worth more than a stack of tools that don't.

Player-coach isn't a compromise. It's the point.

Let me argue against the framing everyone defaults to, because "player-coach" gets used as a euphemism for "we can't afford a real team yet," and that undersells what the role actually requires.

Being hands-on early isn't a budget constraint you tolerate until headcount arrives. It's how you earn the standing to make the calls that matter once the team exists. A security leader who spent their first year exclusively in strategy decks has no idea whether the controls they're proposing will survive contact with the actual codebase, the actual on-call rotation, the actual incident at 3 a.m. The best first hires I've watched do this well stayed close enough to the work that when they eventually did build a team, they knew exactly which three roles to hire first, because they'd done all three jobs badly themselves for a year and knew precisely where they were the bottleneck.

This is also where a lot of good candidates get it backwards in the interview. They pitch the roadmap. What a company actually needs to hear is how you'd spend your first ninety days finding out what's true, and what you'd refuse to build until you knew.

Where it actually goes wrong

The failure mode isn't usually technical incompetence. It's a first hire who treats the role as a smaller version of a CISO job they've seen before, and starts writing policy before they've earned the standing to enforce it. Policy without relationship reads as compliance theater to an engineering team that's been shipping fine without you. It gets nodded at in the meeting and ignored the moment the deadline pressure returns.

The other failure mode is the opposite: staying so deep in hands-on work that the company never gets the thing it actually hired you for, which is judgment about when to say "not yet" on the roadmap, and the credibility to make that call stick with the people who sign your budget.

What I would do about it, on either side of the hire

If you're the company: don't hire for a title. Hire for someone who asks what's already happening before they propose what should happen next, and who can point to a time they built something from genuinely nothing rather than inherited a running program.

If you're the candidate: ask what security work is already happening informally, and who's doing it. If the answer is "nothing, that's why we're hiring you," ask harder. There's almost always something. Finding it first is how you avoid spending your first quarter rebuilding what someone already half-built and quietly resents you for ignoring.

Ask where the org intends to place the role. Reporting into engineering versus reporting into legal or finance isn't a symbolic choice. It tells you whether the company sees security as embedded in how things get built, or as a function that checks what's already been built after the fact.

Ask what happens when the work outgrows one person. A company that's thought about when and how it will staff up has thought seriously about the role. A company that hasn't is asking you to be the whole plan.

Sources

Rami McCarthy, "The First Security Hire Rule of Thumb" (ramimac.me), including the Michael Graham 30–100 employee benchmark · Lightspeed Venture Partners, Cyber60 2025-2026 report, on enterprise security team composition and hiring trends.

A first security hire isn't a CISO with less budget. It's the person who decides what the security function is even going to look like, built from what the company was already doing without a name for it. Get that part right, and the roadmap writes itself. Skip it, and the best roadmap in the world won't survive contact with a team that never trusted where it came from.