ATALAIAMost engineering organisations make their first security hire at the wrong moment and for the wrong reason. Usually a large customer sends a questionnaire, an auditor asks who owns security, and a job advert goes out the same week. The person who arrives inherits a deadline rather than a role.
Our position is simple: hire when security has become a delivery problem, hire a generalist who can work inside your engineering teams, and give them 90 days to build a baseline before anyone asks for a roadmap. If you cannot answer the questions below yet, start smaller.
When it is time
Headcount and funding rounds are poor signals. Better signals are the ones engineers feel every week:
- Pull requests wait on a security answer and nobody knows who should give it.
- Sales and customer success forward security questionnaires to whichever engineer answered the last one.
- You have scanners running, but nobody triages the output, so the findings list only grows.
- Incidents and near misses are handled by whoever is online, and nothing changes afterwards.
- You are entering a regulated market or selling to buyers who will ask for evidence, not promises.
If two or three of these are true, the work already exists. It is just spread thinly across people who were hired to do something else.
Which profile first
The job titles overlap, so it helps to think in terms of what the person will spend their week doing.
| Profile | Strong at | Right first hire when |
|---|---|---|
| AppSec generalist | Code review, threat modelling, pipeline hygiene, working with developers | You build and ship software, and most of your risk lives in your own code and dependencies |
| Cloud or platform security | IAM, network boundaries, infrastructure as code, cloud posture | Your product is mostly configuration and managed services, with little custom code |
| Detection and response | Logging, alerting, incident handling | You already have a mature build process and the main gap is seeing attacks in production |
| GRC or compliance | Policies, audits, risk registers, customer assurance | A certification is a hard commercial requirement and engineering basics are already in place |
For most product companies the answer is the AppSec generalist. They sit closest to where vulnerabilities are created, they can answer most customer questions honestly, and they can grow the other functions later. A compliance-first hire in a company without engineering basics tends to produce documents that describe controls nobody runs.
Whoever you hire, look for someone who has shipped code, can say no without becoming the department of no, and writes clearly. The first security person spends more time persuading than configuring.
The first 90 days
Resist the temptation to hand over a tool budget on day one. The first quarter should look roughly like this:
- Days 1-30: listenMeet every team lead, read the architecture docs, sit in on planning, map where code goes from laptop to production.
- Days 31-60: baselineInventory repositories, pipelines, cloud accounts and third-party access. Pick the few risks that matter most and write them down.
- Days 61-90: three fixesShip three visible improvements, such as branch protection everywhere, secret scanning in CI and a triage rota, then publish a one-page plan for the next two quarters.
By day 90 you should have a short written risk picture, a handful of improvements engineers have noticed, and a plan that leadership has agreed to. You should not have a new platform that nobody has integrated.
When a fractional lead is the better first step
Sometimes the honest answer is that you are not ready to hire. A part-time, senior security lead working a few days a month is often the better opening move when:
- You cannot yet write a job description, because you do not know which of the profiles above you need.
- The workload is real but not yet full-time, and a junior hire would be left alone with decisions above their level.
- You need someone senior to face customers and auditors now, while you build the case for a permanent role.
- You want the first permanent hire to inherit a working baseline rather than a blank page.
The point of a fractional engagement is to make itself unnecessary. It should end with a defined role, an interview loop, a running backlog and a handover, not with an open-ended retainer. We describe how that month-to-month rhythm works in a separate post on fractional security leadership.
What we would do
If you are an engineering leader reading this with no security person today, here is the order we would take:
- Write down the last five security questions that slowed delivery and who ended up answering them. That list is your job description.
- Decide whether the work is mostly in code, in cloud configuration, in production monitoring or in audits. Pick the profile from that, not from a title you have seen elsewhere.
- If the answer is unclear, or the work is less than a full week, bring in a fractional lead for a fixed period with a defined handover.
- When you do hire, agree the 90-day outcomes before the start date, and protect the first month for listening.
A first security hire is not a fire extinguisher. Treated well, it is the person who sets up the first station on the line and makes it possible to add the next ones.
Where this sits on the line
In the tower (in development):