Security Engineer or vCISO? Your First Hire, by Stage

TL;DR: “We need to hire security” is two different sentences wearing one set of clothes. A security engineer builds and fixes — appsec, infra hardening, tooling, the code-level work. A vCISO decides and represents — the program, the priorities, the customer security reviews, the audit strategy. They are not interchangeable, and the wrong first hire is expensive in both directions: a $220K engineer with no program to execute, or a strategist with nobody to implement. The stage answer, compressed: pre-seed, neither — it’s engineering hygiene and founder-owned basics. Seed to pre-Series A selling into the enterprise, vCISO first — the work at that stage is decisions and paperwork, and the hours don’t justify a full-time anything. Series A with a real attack surface, first security engineer — and the vCISO graduates to advisory. Series B+, a full-time security lead. And yes — I sell vCISO work, so read the bias disclosure below before you take my word for any of it.

Two different jobs wearing one word

When a founder tells me “we need to hire security,” my first question is always the same: do you need someone to build things, or someone to decide things? The blank pause that usually follows is the whole problem.

A security engineer is a builder. They write and review code, harden your infrastructure, wire up your secrets management, tune your dependency scanning, fix the auth bug, build the audit-logging pipeline. Their output is commits, configurations, and closed findings. They are judged the way any engineer is judged: by what ships.

A vCISO — or any security leader — is a decider and a representative. Their output is a program: what you’ll fix and in what order, what you’ll accept and document, what you’ll tell the enterprise customer’s security team on Thursday’s call, how you’ll scope the audit so it unblocks revenue instead of consuming a quarter. They are judged by whether security decisions stop being bottlenecks — whether deals close, audits pass, and the engineering team knows what “secure enough for now” means this quarter.

The market blurs these constantly, because both get filed under “security” in the hiring plan and both cost real money. But they fail differently, they interview differently, and — this is the part that matters — they’re needed at different stages.

The mis-hire, in both directions

Get the order wrong and you pay twice: once in salary, once in the work not getting done.

The engineer with no program. Hire a senior security engineer — call it $220K fully loaded, and that’s not the top of the market — into a 12-person startup with no security program, and you’ve bought a very expensive person who now has to invent their own job. Some can. Most, reasonably, do what engineers do: they pick the technically interesting work. You get a beautifully tuned SIEM and a hand-rolled scanner while the thing actually threatening the company — the enterprise security questionnaire sitting in your sales pipeline, the SOC 2 scoping decision, the access-review policy nobody wrote — sits untouched, because none of that is engineering work. Six months later the founder is confused about why “hiring security” didn’t make the security problems go away. It did — just not their security problems.

The strategist with no hands. The inverse fails just as hard. Bring in security leadership — fractional or otherwise — at a company where the actual gap is implementation, and you get beautifully prioritized findings that nobody fixes. The roadmap says rotate the credentials, isolate the tenants, add the rate limiting. The engineering team, heads down on product, treats it as a wishlist. A vCISO without engineering capacity to direct is a report generator. I say this as someone who writes those reports: the engagement only works if someone on the other side can execute, even if that someone is a product engineer with 20% of their time carved out.

The fix for both failure modes is the same: match the hire to the kind of work your stage actually generates. So let’s do it by stage.

Pre-seed: neither

At pre-seed you do not have a security hiring problem. You have an engineering hygiene problem, and hygiene is not a role — it’s a set of defaults your existing engineers either practice or don’t.

What actually matters here fits on an index card: SSO or a password manager everywhere, MFA enforced, secrets out of the repo and into a manager, dependency updates on, cloud account with billing alerts and no root-key usage, laptops encrypted, and one founder who owns the answer to “what do we do if something leaks.” That founder-owned basics list is boring precisely because it’s effective — the pre-seed incidents I’ve seen were all in the gap between “we knew better” and “nobody owned it.”

Spending real money on security headcount — or even a meaningful fractional engagement — at this stage is solving next year’s problem with this year’s runway. The one exception: if you’re building something regulated from day one (health data, payments infrastructure, kids’ products), the compliance floor arrives before product-market fit does, and you should read the next section as applying to you now.

Seed to pre-Series A: the vCISO, first — and here’s my bias

Full disclosure before this section, because it’s the one that pays my invoices: fractional security leadership is literally what I sell. My consulting practice is built around vCISO engagements for exactly this stage of company. Discount accordingly — and then check the reasoning, because I’ll also tell you below when the answer isn’t a vCISO.

Here’s why the strategist comes first at this stage. Look at what security work a seed-stage company selling into the enterprise actually generates in a given month: a customer security questionnaire (or three), a decision about whether and when to do SOC 2, a vendor review from a prospect’s procurement team, an access-control policy that needs to exist in writing, a prioritization call about which of the 40 scanner findings matter, maybe an architecture review for the feature that touches customer data. Almost none of that is engineering. All of it is decisions and representation — and every piece of it is blocking revenue, not blocking uptime.

That’s a leadership workload, and it’s a part-time leadership workload. There are maybe 15–25 real hours of it a month. A full-time CISO runs $200–400K and is over-leveled for that work in both cost and scope — I’ve done the full cost math on this elsewhere, so I won’t repeat the tables here. The fractional version runs $2–4K/month and covers the actual demand. If you want to know what those hours look like in practice — what actually happens in the first 90 days — I’ve written a week-by-week teardown of a typical engagement.

The other reason the strategist comes first: at this stage, your engineers are your security engineers. A competent product engineer, pointed at a clearly prioritized finding with a clearly articulated “why,” can close most of what a seed-stage company needs closed. What they can’t do is generate the prioritization, or sit on the customer call, or scope the audit. Buy the scarce thing; direct the abundant thing.

And if enterprise deals are why you’re here: start with SOC 2 as a revenue tool, because scoping that correctly is the single most valuable decision a vCISO makes at this stage.

When the answer is not a vCISO

Three cases where I’d tell you to skip the engagement I sell:

You have a real-time attack surface from day one. If you’re building deep tech where the product itself is a target the moment it ships — a wallet, an exchange, network infrastructure, anything holding other companies’ credentials — you don’t have a “decisions and paperwork” workload, you have an adversary. That’s an engineering problem first. Hire the security engineer (or make your first ten engineering hires security-strong), and get leadership fractionally on top of that, not instead of it.

You’re regulated from day one. HIPAA, PCI-DSS at level, banking partnerships — when the compliance floor is structural, the work volume justifies dedicated ownership much earlier, and a fractional leader spread across clients may not be able to carry your audit calendar. Some can; be honest about the hours.

You already have a security-strong staff engineer. Some teams get lucky: a staff-level engineer who’s carried security at a previous company and wants the ownership. If that person exists and has the appetite, give them the mandate and 20–30% of their time, and buy them a few advisory hours a month to pressure-test the program instead of a full engagement. That’s cheaper than me, and for the right person it works. The failure mode to watch: the mandate quietly evaporates the first time a product deadline hits. If it happens twice, the experiment failed — go back to the stage table.

Series A: the first security engineer

Somewhere past Series A the workload flips. You now have real attack surface: more engineers shipping faster than any part-timer can review, customer data at a volume that makes isolation failures existential, infrastructure complex enough that hardening is a project rather than a checklist. The security work stops being mostly decisions and starts being mostly engineering — continuous, hands-on-keyboard engineering.

That’s when the first security engineer earns their seat. And the hire works precisely because the program already exists: they walk into prioritized work with organizational context, not a blank page. The sequencing matters more than the individual — I’ve written about where security fits in the broader pre-Series-A hiring sequence, and the short version is that this hire lands after your core product team is stable, not before.

What happens to the vCISO? The engagement should shrink — advisory hours, audit-cycle support, the customer calls that still need a title. A fractional engagement that’s still running at full intensity eighteen months after a security engineer joined is a smell: either the engineer isn’t being given the program, or the vCISO won’t hand it over. Graduation is the success condition, not churn.

Series B and beyond: the full-time lead

Eventually the decisions themselves become full-time: a security team to manage, quarterly board reporting, a compliance portfolio (SOC 2 plus the customer-specific attestations that enterprise growth accretes), incident process with real stakes, and enough spend to need its own budget owner. That’s a full-time security lead or CISO, and at this point the $200–400K stops being over-leveled and starts being table stakes — the title now carries work that fills the hours.

The practical note founders miss: your first security engineer is not automatically this person. Sometimes they grow into it; often the builder wants to keep building. Promote for appetite, not tenure — and if you promote, backfill the engineering, because the building didn’t stop.

The decision, compressed

The one-line version: buy decisions before you buy hands, until the hands are what’s scarce.

If you’re at the stage where the decision is live, run your numbers through the vCISO cost calculator — four questions about your stage, a monthly number out. And if the math points at the fractional route, this is exactly the engagement I run. If it points at the security engineer instead — good, hire them, and spend the money you saved on making sure they walk into a program instead of a blank page.