Q: What should the first security hire at a startup actually do?

Absorb the customer trust queue. That means security questionnaires, audit evidence, policy sign-off, prospect security calls, remediation chasing, vendor lists, and telling sales what can be committed to contractually. Technical security work exists at that stage but is not yet a full role, closer to a rotation plus tooling in the pipeline.

Q: Why is hiring an application security engineer first a mistake?

Because the person chose their career to avoid the work the role actually contains. Given a quarter of questionnaires and evidence collection, a strong application security engineer will either leave, quietly return to engineering and push the queue back to the founder, or build a bespoke internal tool that becomes unmaintained when they go.

Q: When does a startup hire its first security engineer?

Second, after the program hire. By then the first person has spent a year inside the queue and can say precisely where the technical gaps are, which makes the engineering role concrete rather than speculative. The exception is a company whose product is itself a security product.

Deepak Gupta

I have watched this hire go wrong the same way four or five times, at four or five different companies, and the mechanism is always identical.

A founder decides it is time for security. Security means hacking, so they hire the most technically impressive security person they can find, usually an application security engineer with a good reputation. Six months later that person is unhappy and the founder does not understand why, because they are paying well and the person is clearly talented.

The reason is that the job was never the job that was advertised.

What the first security person actually does

Track the work for a quarter at a fifty-person business-to-business software company and it looks roughly like this.

Answering customer security questionnaires. Assembling audit evidence. Writing and getting sign-off on policies. Joining prospect security calls. Chasing engineers for remediation of findings somebody else produced. Maintaining a vendor list. Updating a trust page. Explaining to sales what can and cannot be committed to in a contract.

Somewhere near the bottom: actual technical security work.

That distribution is not a failure of the role. It is the role. The queue described above is what a software company's security function exists to absorb at that stage, because it is what stands between the company and enterprise revenue.

Why the engineer is the wrong fit for it

Not because engineers cannot do program work. Because the specific person you hired chose their career to avoid it.

An application security engineer optimized their skills for finding and fixing vulnerabilities. Give them a quarter of questionnaire responses and evidence collection and one of three things happens. They leave. They quietly stop doing the queue and do engineering instead, which means the queue lands back on the founder. Or they automate the queue, which sounds ideal and usually produces a bespoke internal tool that becomes unmaintained the moment they leave.

Meanwhile the actual technical security work at a fifty-person company is genuinely not a full role yet. It is a rotation, a code review habit, a scanner in the pipeline, and an annual penetration test.

What generalizes

The first security hire should be a security program manager, a technical compliance lead, or an experienced generalist who is comfortable being the interface between engineering and everyone who wants something from it. Titles vary; the shape does not.

What matters more than the title is the failure mode you screen for. This person will spend most of their time saying things like "we do not do that, and here is what we do instead" to a customer's security reviewer, under deal pressure, without overcommitting. That is a judgment and communication skill, and it is not correlated with technical depth in either direction.

The engineer is the second hire, and by the time you make it the first person will be able to tell you exactly what the engineer should work on, because they will have spent a year finding out where the actual gaps are.

The limit of this

There is a real exception, and it is the security product company. If what you sell is itself a security product, product security is a product function and the first hire probably is an engineer, because the work is in the product rather than in the queue. The corporate queue still forms, but it can often be handled fractionally for longer.

There is also a version where the founder is technical, has run compliance before, and can hold the queue personally for another year while the company is small. That is a legitimate choice. It is worth being honest that it is a choice to spend founder time on questionnaires, because that is what it is.

What the second hire looks like

Worth sketching, because the argument here is about sequence rather than about engineers being unnecessary.

By the time the first hire has been in seat a year, the technical gaps have names. Usually two or three of: the product handles authentication in a way nobody has reviewed, dependency and supply chain risk in what ships is unmanaged, there is no threat modelling at design time, or the detection and response story for the production environment is aspirational.

Those are engineering problems and they need an engineer. The difference is that you now know which one to hire for, and the person joining has a defined scope rather than a mandate to find something to do.

There is also a real chance the second hire should be a detection or infrastructure security engineer rather than an application security engineer, and you would not have known that a year earlier. Companies default to application security because it is the most legible specialism, and for a company whose risk is concentrated in its cloud posture that is the wrong first engineer.

How to screen for it

Two interview questions have done more work for me than any technical assessment when hiring into this role.

The first: describe a time a customer asked for a security commitment you could not make, and what you said. Weak answers describe escalating it. Strong answers describe the exact language they used to decline while keeping the deal alive, because that language is the job. Someone who has done this role has a rehearsed answer, and someone who has not will improvise something either too rigid or too accommodating.

The second: walk me through what happens between a researcher emailing security@ and the fix shipping. This tests whether they think in processes with named owners and clocks, which is the actual skill. It also surfaces whether they have ever been on the receiving end of a disclosure, which changes how someone thinks about the whole function.

Neither question asks about a vulnerability class, and that is deliberate. The technical screen for this role should be a floor rather than a ranking: can they hold a credible conversation with an engineer, and can they read a penetration test report without needing it explained.

The narrow claim

At a normal software company with an enterprise sales motion, the first security hire is a program hire. The instinct to hire technical depth first is understandable, expensive, and consistently wrong. The engineer is the second hire, and by then the first person will know exactly what that engineer should work on.

Your First Security Hire Is Not an Engineer