The First Security Hire Is a Unicorn Hire

Fri, 22 May 2026 11:28:29 -0700

The first security hire at a company is asked to be seven specialists at once.

Read the job description for a head of security role, especially at a company making its first dedicated security hire, and you’ll find a wish list that spans the entire field. Governance. Risk and compliance. Third-party risk management. Cloud security. Identity and access management. Product security. Security architecture. Each of those is a career. Each one has people who have spent fifteen years going deep on that single discipline and still feel like they’re learning. The req asks for one person who can do all of them well.

The industry has a word for the person who can: a unicorn. It gets said half as a compliment and half as a quiet admission that the role, as written, might not be fillable. And once you’ve reached for that word, the honest question is the one the hiring side would rather not sit with. How many unicorns actually exist?

Seven Jobs, One Headcount

When a company makes its first dedicated security hire, it isn’t hiring a specialist. It’s hiring a function. There is no team to absorb the parts of the job the new person isn’t strong at, because the new person is the team. Whatever they can’t do well enough either doesn’t get done, or gets done badly by someone whose actual job is something else.

That’s what makes the breadth real instead of aspirational. In a mature security org, the head of security sits above seven or eight specialist functions, and the depth lives in the people below them. As the first hire, there is no below. The governance program, the vendor reviews, the cloud posture, the identity model, the product security questions coming out of engineering, the architecture decisions getting made with or without them. All of it lands on one desk.

And these aren’t variations on a single theme. Governance is mostly a writing-and-influence job. Cloud security is a hands-in-the-console job. Third-party risk management lives in process and negotiation. Product security is, genuinely, an engineering job. The skills don’t transfer cleanly between them. Being excellent at one tells you remarkably little about whether someone is even competent at the next.

The Job Doesn’t Stay Inside Security

The seven domains, as broad as they are, are all still security. The job doesn’t stay inside that boundary. At most companies, and especially at any company selling software to other businesses, the first security hire ends up spending real time in two places that appear on no security domain list: revenue and legal.

Start with revenue. Modern enterprise deals have a security gate. Before a prospect signs, someone on their side wants to know how your company protects their data, and they want to hear it from a person who owns security, not from an account executive reading a script. So the first security hire becomes a part-time sales engineer. They join customer calls, walk prospects through the security posture, and answer the hard follow-up questions in a way that keeps the deal moving. When the deal reaches paper, they’re in the contract negotiation: the security exhibit, the data processing addendum, the breach-notification windows, the audit rights, the liability language tied to a security incident. The deal often cannot close until those terms are settled, which makes the head of security part of the sales team in a real and recurring way.

Then there’s the questionnaire tax. Enterprise customers send security questionnaires, sometimes a standard one, often a bespoke spreadsheet three hundred rows long, and a wrong answer is both a lost deal and a misrepresentation risk. Someone has to own answering them accurately and consistently. That someone is usually the first security hire.

And the job spills into legal. Privacy regimes like GDPR sit right next to security, share a lot of vocabulary, and almost always land on the security person’s desk at an early-stage company, because there is no dedicated privacy counsel yet. Privacy is a genuine discipline of its own, with its own lawyers at larger companies, and the first security hire inherits it anyway. They end up negotiating legal terms, interpreting regulatory obligations, and deciding which commitments the company can actually keep.

None of this is what people picture when they picture a security leader. It’s also, at a B2B software company, frequently where the most calendar time goes. Anyone arriving from a large company, where a security sales-enablement team handled customer calls and a privacy office handled GDPR, is in for a surprise. As the first hire, all of it is theirs.

Real Unicorns Are Rarer Than the Req Assumes

Run the math the hiring market tends to skip. Start with one domain, say identity and access management. The number of people with genuine operator depth in IAM, the kind earned by running a real program through a real migration, is already smaller than the LinkedIn population of “IAM experts” would suggest. Call it a meaningful but modest pool.

Now require that same operator depth in a second domain. You haven’t halved the pool. You’ve taken the intersection of two already-small pools, and intersections are unforgiving. Require a third and the number gets small enough to feel personal. By the time the req asks for real depth across all seven, plus the revenue and legal work, you’re no longer describing a labor market. You’re describing a list of named people, short enough that a well-connected CISO could probably recite most of it.

That’s the arithmetic underneath the word “unicorn.” It isn’t a flattering exaggeration. For the literal version of the role, operator depth everywhere, it’s roughly accurate, and the pool is close to empty.

Which would make first-security-hire roles nearly impossible to fill, if the literal version were the real one. It isn’t. The real role is fillable. You just have to be honest about what it actually asks for.

Nobody Has Operator Depth in Everything

Here’s what the unicorn framing gets wrong. It implies the rare person is rare because they personally mastered all seven domains. They didn’t. Nobody did. The day isn’t long enough, and neither is a career.

What the strong ones actually carry is a blend of two different kinds of depth, and the difference is worth naming.

Operator depth is what you get from owning the thing. You ran the program. You carried the pager. You were accountable for the metric, you made the calls that went wrong, and you lived with what followed. Operator depth is expensive. It costs years, and you can only sit in one or two of those seats at a time.

Partner depth is what you get from working closely alongside the thing. You didn’t run the IAM program, but you sat next to the person who did for three years. You depended on their work, negotiated with them, and watched what broke and what their week actually looked like. You came away knowing the operating rhythm of that domain, its processes, its failure modes, and the jobs it’s really trying to do, without ever having owned it.

The genuine “unicorn” is not someone with operator depth in seven domains. It’s someone with operator depth in two or three, and real partner depth across the rest. That person exists in far greater numbers than the mythical seven-domain operator. They’re still not common, but they’re findable. And, more usefully, they’re buildable, which matters once we get to the path.

The trap is mistaking partner depth for résumé tourism. Real partner depth shows up as specific knowledge of how a domain fails and what the failure costs. Résumé tourism shows up as vocabulary. The interview question that separates the two is never “have you done X.” It’s “tell me about a time X went wrong at the desk next to yours, and what it cost to fix.”

The Domain You Can’t Fake Depends on the Company

I don’t want to oversell partner depth. There’s a real failure mode where someone with partner depth in everything and operator depth in nothing starts making confident calls in a domain they only ever watched from one desk over. Partner depth is enough to understand a domain. It is not always enough to run one when the company’s risk is concentrated there.

Which domain you genuinely cannot fake depends entirely on the company.

At a software company, it’s product security and architecture. If the first security hire can’t read the code, can’t reason about how the product is actually built, and can’t sit in a design review and see the flaw forming, they’ll lose the engineering org inside a month. The credibility never recovers.

At a company in a heavily regulated space (finance, healthcare, anything with an auditor on a recurring schedule), it’s governance and compliance. Partner depth there gets you someone who can talk fluently about frameworks. It does not get you someone who can survive an examination, scope an audit defensibly, or tell the CEO which regulatory commitment is about to turn into a problem. That seat needs operator depth, and partner depth quietly fails the day it’s tested.

So the honest version of the unicorn question isn’t “can this person do all seven.” It’s “does this person have operator depth in the two or three domains where this company’s risk actually lives, and credible partner depth across the rest.” The wish list reads the same on paper. The hire is a completely different person.

This is also where first-hire searches quietly go wrong. The company writes the generic seven-domain req, interviews against all seven as if they were equal, and ends up optimizing for breadth of vocabulary instead of depth where it counts. The result is a hire who can speak to everything and is dangerous in the one place that actually mattered.

You Don’t Have to Hire the Whole Unicorn

There’s a move that the seven-domain req obscures. You don’t have to buy the entire unicorn as one full-time person, and at an early company you probably shouldn’t. Parts of this job can be rented, both before the first hire and after it.

Before the hire, the vehicle is usually a virtual or fractional CISO, or a security consultancy on retainer. A vCISO can carry the function while the company is still too small, or too early, to justify a full-time security leader. They can stand up the first real controls, run the company through its first SOC 2, build the initial governance, and answer the opening wave of customer questionnaires. For a company before product-market fit, that is often exactly the right amount of security leadership: enough to not be reckless, not so much that you’ve spent a senior headcount before you have the surface area to use it.

The outsourcing doesn’t stop once a head of security is hired. It changes shape. A good security leader keeps renting the work that is spiky, specialized, and infrequent. Penetration testing is the obvious one; you want independent testers, not your own staff grading their own homework. Audit and compliance readiness, specialized cloud reviews, and sometimes privacy counsel fall in the same bucket. The head of security becomes the orchestrator of a mix of in-house and outsourced capability, rather than the person personally doing all of it.

The pros are real. Outsourcing buys depth you cannot hire: a vCISO firm has actual operators across several domains, and you rent their breadth for a fraction of the cost of assembling it yourself. It’s faster and cheaper than a full hire for a company that isn’t ready for one. And it de-risks the eventual hire, because a year of a fractional CISO teaches the company where its risk actually lives, which is the single hardest input to that “domain you can’t fake” calibration.

The cons are just as real. A fractional person is not in the room. They miss the hallway context, the operating rhythm, the quiet signals that something is going wrong before it shows up in a metric. Partner depth across your specific company is precisely the thing they cannot accumulate at fractional time. Accountability is thinner, too: an outsourced CISO juggling eight clients is harder to hold than an employee, and the knowledge tends to walk out the door when the engagement ends. There’s also a slow failure mode where the vCISO becomes a permanent crutch, and the company defers the real hire well past the point it was needed, because someone is nominally “handling it.” And increasingly, enterprise customers and boards want a named, full-time, accountable security leader; a shared contractor starts to read as a gap during diligence.

The timing question usually answers itself if you watch for two signals. The first is when security becomes a deal gate. Once revenue is waiting on security answers, you need real ownership, even if a vCISO is the bridge to a permanent hire. The second is the question test: when the board or a major customer asks who owns security here, and the honest answer is “a contractor we share with eight other companies,” it’s time to hire. After the hire, the rule inverts. Outsource the spikes, the pen tests and audits and one-off reviews, and keep in-house the work that has to be in the room, which is the architecture decisions, the partnership across teams, and incident command.

In the Seat, Hands-On Follows the Risk

Here’s the part that’s easy to get wrong in both directions. A head of security is hands-on. As the first hire especially, there is nobody else to be hands-on for them. They are writing the policy, configuring the identity provider, reviewing the risky pull request, and filling in the security questionnaire themselves. This is not a delegate-from-a-corner-office job. But no one can be hands-on everywhere at once, not across seven domains plus the revenue and legal work. So the defining act of the role isn’t doing the work or not doing it. It’s deciding, continuously, where to put their own hands.

That decision runs on risk. Where the company’s risk is concentrated, the domain you can’t fake, that is where the head of security goes deep personally: in the design reviews, in the cloud console, in the incident channel. Where the risk is lower, or the work is steady-state, they set direction and let whoever owns the day-to-day run it. This is where the two kinds of depth earn their keep. The domains where you have operator depth are the ones you can drop into and be useful with your own hands. The domains where you have partner depth are the ones you can direct credibly without being the person typing. Both are real work.

Partner depth is what makes that second category possible. Understanding the operating rhythm of identity, or third-party risk, or cloud, is what lets you run those domains when your hands are busy elsewhere. It’s so you can tell when something is going sideways before the metrics say so. It’s so you can ask the engineering team for something they can actually act on instead of something that merely sounds right. It’s so that when you sit across from a vendor, a regulator, or your own CFO, you don’t get walked.

There’s an expectation here that shows up on no domain list. The first security hire is the single accountable name for security in front of the founders and the board. Every domain’s failure becomes their failure to explain. An identity misconfiguration, a vendor breach, a product vulnerability in the news: the room doesn’t care that no reasonable person is a true expert in all three. It wants one person who can speak to all of it credibly, own the response, and say what happens next. Partner depth is what makes that survivable. It’s the difference between explaining an incident you understand and reading a statement about one you don’t.

Much of the job also lives at the seams between domains, where the identity model meets the product roadmap, where third-party risk meets procurement’s timeline, where compliance meets what engineering can realistically ship. Partner depth is what lets you stand in those seams and still know what you’re looking at.

The role is also expected to outgrow itself. The first security hire is the person who eventually scopes the second hire, and the third, deciding which domain gets a dedicated owner first based on where the partner depth is thinnest and the risk is highest. Knowing the operating rhythm of a domain is what lets you hire well into it. You can’t write a good req, or evaluate a candidate, for a discipline you’ve only ever heard described.

Becoming One Is a Lateral Move, Not a Climb

The standard security career ladder runs vertically inside a single domain: analyst, senior analyst, lead, manager, all of it in, say, GRC. That path produces deep operator depth in one domain and partner depth in almost nothing. It’s the wrong shape for this role, no matter how high you climb it.

The path to a first-security-hire role is lateral. It’s a deliberate sequence of moves that trades some vertical depth for adjacency. You spend a few years owning a domain, earning your operator depth, and that part is non-negotiable. You cannot skip having genuinely owned something. Then you move sideways into a role that sits next to a domain you don’t have yet, and then you do it again.

A couple of patterns manufacture that adjacency faster than the org chart will. Consulting and advisory work is unusually good at it: you’re exposed to a dozen companies’ identity programs, vendor processes, and architecture decisions in the time it would take to see one of each from the inside. Security architecture roles do something similar by design. They sit structurally at the seams, and they force you to build a working model of every domain you touch.

The other lever is company size, used deliberately. At a 5,000-person company you’ll be a specialist whether you like it or not; the org is large enough to keep you in a lane. At a 200-person company you’ll be pulled into partner depth across half the field because there’s nobody else to do it. The breadth is a property of the environment, and the environment is something you get to choose.

What doesn’t work is shortcutting the years with certifications or vocabulary. You cannot read your way to partner depth. It comes from time spent next to the work while something was going wrong, and there’s no version of the path that skips that.

There’s one more honest thing to say about the path: it’s long. The shape I’ve described, operator depth in two or three domains and real partner depth across the rest, is usually fifteen to twenty years of deliberate moves. That’s not a discouragement so much as a calibration. If you’re five years into the field and a first-security-hire role is on the table, the most likely explanation is that the company has under-scoped the role and is about to learn something expensive. The timeline is part of the definition.

What the Word Actually Means

I used to think the word “unicorn” did some quiet damage, and I would have retired it if I could. I’ve come around. The word is fine. Plenty of people, and I’ll include myself, wear it with some pride. The problem was never the word. It was the assumption underneath it: that a unicorn is a single uniform creature, and that any one of them would do.

They wouldn’t. Every unicorn has a different set of powers. One has operator depth in product security and architecture and can see the flaw forming in any design review. Another came up through compliance and governance and can carry a company through a regulatory exam without flinching. A third has lived in identity and cloud. They are all unicorns. They are not the same unicorn, and they are not interchangeable.

That is the part worth getting right. The person who can fill a first-security-hire role isn’t someone who did all seven jobs. It’s someone who did two or three of them for real, got close enough to the rest to know how they work and how they fail, and learned to operate in the seams between them. Which two or three is the whole question. A software company needs the unicorn whose powers run to product and architecture. A regulated company needs the one who can survive the exam. Hiring a unicorn is easy to feel good about. Hiring the unicorn whose powers match your risk is the part that actually matters.

If you’re hiring one, calibrate the wish list to where your risk actually lives, interview hardest there, and rent the rest until you’re ready. If you’re trying to become one, stop climbing and start moving sideways. Notice which powers you’re collecting along the way, because those are what a company will eventually hire you for. The role rewards the shape of a career far more than the height of it.

Hiring on Matt Goodrich