When a SaaS Company Needs a Head of Security

The advice a founder usually gets is a number. Fifty employees. A hundred. Ten million in revenue. Series B.

Every one of those is a proxy, and the proxies fail in both directions. I have seen thirty-person companies that needed a security lead a year earlier, because they sold to banks from day one. I have seen two-hundred-person companies where the right answer was still a fractional arrangement, because they sold to small businesses who never asked a security question.

The variable the proxies are trying to capture is the shape of the work.

The moment it usually becomes obvious in hindsight

Talking to founders after the fact, the same specific week comes up more than any other.

A large prospect sends a security questionnaire on a Thursday, wants it back Monday, and separately asks for a call with someone who owns security. The engineering manager who has been handling this cancels two days of their own work. The deal closes. Everybody treats it as a win.

Then it happens again five weeks later, and the second time nobody flags it, because the first time established that this is how it works now.

That second occurrence is the signal. The first is an event; the second is a pattern, and a pattern with an external deadline is a queue. Founders who go looking for a threshold number are usually looking past this, because it arrives as a busy fortnight rather than as a metric crossing a line.

Project-shaped versus queue-shaped

Project-shaped security work has a start, an end, and a deliverable. Get the SOC 2. Fix the findings from the penetration test. Roll out single sign-on. An engineering manager can own this alongside a roadmap, because a project competes for planning capacity in a way the organization already knows how to arbitrate.

Queue-shaped security work arrives continuously and never completes. Customer questionnaires. Evidence requests from the auditor. Vulnerability reports from researchers. Access requests. A prospect's security team wanting a call this Thursday. None of these can be planned, all of them have external deadlines, and every one of them interrupts something.

An engineering manager can absorb the first kind indefinitely. The second kind destroys them, because a queue with external deadlines always wins against a roadmap with internal ones, and within two quarters that manager has stopped doing engineering leadership and started doing security operations badly.

The hire is not triggered by the amount of work. It is triggered by the arrival of the second kind.

Why the obvious answer is wrong

The obvious answer is to hire when a customer demands it. That is too late, and it is also the most expensive moment to hire, because you are now recruiting against a deal deadline.

The second obvious answer, which is to hire when you can afford it, is worse. It produces a hire with no defined queue to own, who then spends their first two quarters inventing a program nobody asked for and generating internal friction. A head of security hired before the queue exists has no source of authority, because their authority comes from being the person who unblocks things.

The discriminating variables

Is there an unowned queue with external deadlines?

The test: count the security questionnaires, audit evidence requests, and customer security calls in the last ninety days. If that number is above roughly one a week and rising, the queue exists.

Who is absorbing it now, and what are they not doing?

The test: ask the person currently handling security work what they stopped doing to handle it. If the answer is a named piece of engineering leadership, you are already paying for a head of security, just at a worse exchange rate and with worse outcomes.

Does the sales motion have a security gate?

The test: how many deals in the last two quarters had a security review as a named stage? If security review is a routine stage in the enterprise pipeline, the queue is structural rather than episodic and it will not go away.

Is the work program work or engineering work?

The test: of the last twenty security tasks, how many required writing code? Usually the answer is one or two. That has direct implications for who you should hire, which is a separate decision covered on this desk.

Counting the queue properly

The test above depends on a number most companies do not track, so here is how to get it in an afternoon.

Search the last ninety days for four things: security questionnaires received, audit or evidence requests, prospect calls where a security reviewer attended, and inbound vulnerability reports. Count each occurrence, not each thread.

Then, for each one, write down who handled it and roughly how long it took. Questionnaires are the big rock at three days each. Prospect security calls are an hour of preparation and an hour of call. Evidence requests are unpredictable and usually underestimated.

Two numbers fall out. The first is arrival rate. Above roughly one item a week and climbing, the queue is structural. The second is absorbed cost, and it is usually the one that ends the argument: a company doing twenty questionnaires and six security calls a quarter is already spending most of a person on this, distributed across people whose actual jobs are something else.

That is the pitch. Not "we need a security leader", but "we are currently spending sixty percent of a head on this, taken out of engineering leadership, and here is what that costs us in delivery."

What the fractional option really buys

Fractional and virtual CISO arrangements get recommended reflexively and evaluated rarely. They are genuinely good at some things and structurally bad at others.

Good at: framing a program, choosing a control set, preparing for a first audit, reviewing an architecture, giving a founder someone to think with, and being credible to a customer's security team on a call. All of these are episodic, expertise-shaped, and do not require being in the building.

Bad at: absorbing a queue. A fractional arrangement is a fixed number of hours against a workload that arrives unpredictably with external deadlines. The questionnaire that lands on a Tuesday and blocks a deal on Friday does not care that your fractional CISO has two days a month and they are next week.

That distinction gives you the actual decision rule. If the work is projects, fractional is often better than a hire, because you buy more seniority per dollar. If the work is a queue, fractional will disappoint regardless of who you hire, and the disappointment will be blamed on the person rather than the structure.

The hybrid that works: a fractional senior person for judgment and credibility, plus an internal owner, often not full-time and often not a security specialist, who holds the queue. That combination covers both shapes and is usually cheaper than a single senior hire.

Decision table

The cost of hiring late

Worth pricing, because the delay usually feels free and is not.

An engineering manager absorbing the queue is a partial loss of engineering leadership, and it is the least visible cost in the company. Nobody logs the roadmap conversation that did not happen. What shows up instead, two quarters later, is delivery slipping for reasons nobody can name and a manager who has become harder to retain.

The second cost is deal friction. A questionnaire answered slowly, or a security call where nobody credible attends, does not usually lose a deal outright. It adds weeks. Across a year of enterprise deals that is a real revenue timing effect, and it is invisible in every dashboard you have.

The third is the hire itself. Recruiting against a deal deadline costs more, converges on whoever is available rather than whoever is right, and starts the person in firefighting mode. Hiring three months early costs a salary. Hiring three months late costs a salary plus a worse candidate plus the two quarters they spend digging out.

What changes the answer

Selling to regulated buyers from the start. Financial services and healthcare buyers ask security questions at seed stage, so the queue arrives before the company has an engineering organization to absorb it. Hire or contract earlier than any headcount rule suggests.

A product that is itself a security product. Different problem entirely. Product security is a product function, and the head of security you hire for the corporate queue will not be the right person for it. Those two roles are distinct and this desk treats them separately.

A pending acquisition or funding round. Diligence generates a queue spike that looks like a permanent trend and is not. Handle it with a contractor, and make the permanent decision after the process closes.

Consumer product, no enterprise motion. The questionnaire queue may never form. In that case the trigger is a different one, usually the first significant vulnerability report or the first regulatory obligation, and the hire profile changes with it.

Hiring against the queue, not against a title

Two things worth getting right in the job description, because both are commonly wrong and both are expensive to fix later.

Describe the queue honestly. If the first two quarters are questionnaires, evidence, and prospect calls, say so. Candidates who want that job exist and are good at it. Candidates who read a job description about building a security program from scratch and arrive to find a questionnaire backlog leave inside a year, and you have burned a hire and two quarters.

Name the authority. Can this person block a release, decline a contractual commitment, or require a control? If the answer is no, say that too, and expect a different and cheaper candidate. The most common failure in an early security hire is a person with full accountability and no mechanism, which is a job that grinds people down quietly.

The best single question to ask in the interview: "the head of sales wants to commit contractually to something we do not do, and the deal is worth 8% of the year. What happens next?" You are not looking for a specific answer. You are looking for whether they have been in that room before.

What to do Monday

Count the security-driven interruptions in the last ninety days: questionnaires received, evidence requests, prospect security calls, researcher reports. Then ask whoever handled them what they gave up.

Two numbers and one sentence. That is a better basis for this decision than any headcount benchmark, and it is a case a board will accept because it is denominated in engineering leadership time rather than in fear.