Hire generalists first, then specialists where your risk concentrates. A common order is a security lead, an application or cloud security engineer, then a governance and compliance role, and only later detection and response or specialist roles. Match each hire to your biggest current risk rather than to a standard org chart.
One person: the security lead
The first hire does everything: policy, vendor reviews, incident response, audit support and engineering liaison. Look for someone with breadth, a track record of working with developers, and comfort saying no politely.
Their first job is to decide what not to do. Pick the three risks that matter most and ignore the rest for a year.
Two to four people: add depth where code and cloud live
The second hire is usually an engineer who can embed with product teams. For a software company, that means application or cloud security. They review designs, tune scanners and build guardrails into pipelines.
The third hire often handles governance, risk and compliance. Audits, questionnaires and evidence collection eat senior time, and offloading them lets engineers keep building defenses.
Five to ten people: split by function
At this size, functions emerge.
- Product and application security. Reviews, testing, developer enablement.
- Infrastructure and cloud security. Identity, configuration, network and secrets.
- Governance, risk and compliance. Policy, audits, third party risk.
- Detection and response. Monitoring, incidents, exercises.
You do not need all four as separate teams. Some can stay as part time duties until volume justifies a person.
Use partners wisely
Outside help can fill gaps: a managed monitoring provider, periodic penetration testing, or a part time advisor. The rule is that you keep the decisions and the knowledge. Outsource work you can describe clearly, not judgment calls about your own risk.
Embed security champions
A small team cannot review everything. Ask engineering managers to nominate a champion on each team, give them a bit of training and a direct line to security, and let them handle first level questions.
Define success for each role
Write a short list of outcomes for every hire before opening the role. For an application security engineer, that might be that every new service gets a design review and the top finding categories shrink each quarter. Clear outcomes make hiring decisions sharper and reviews fairer, and they stop a new hire from drifting into whatever is loudest.
Hire for what you cannot teach
Technical skills can be learned. Communication, curiosity and the ability to build trust with engineers are harder to teach. When two candidates are close, choose the one developers will actually talk to.
Quick check
What should the first security hire be?
A generalist lead who can work with engineers and set priorities. Specialists make sense after the biggest risks are understood.
When should I hire a compliance person?
When audit and questionnaire work starts taking meaningful time from your engineers, often around the second or third hire.
Last reviewed: 19 October 2026.
