Engineering headcount is easy to plan. You raise, you hire, you ship more.
Security headcount doesn't follow. Security hires are scarce and expensive, and each one takes months to ramp up. So the gap between what engineering produces and what security can review gets wider every quarter.
Most companies respond by asking for more security headcount. That fails, and the reasons are structural.
The linear growth trap
The tempting model is a ratio: one security person for every X developers. It's easy to put in a budget, and it assumes security work grows in proportion to developers.
It doesn't. Security work grows with what engineers produce and what they run:
- Every pull request is something that could introduce a flaw.
- Every new service adds to the attack surface.
- Every cloud resource is a configuration that can drift.
- Every dependency is code nobody on your team wrote.
A team of 10 developers using AI coding tools and a modern cloud stack can generate more code and infrastructure than a team of 30 did a few years ago. Headcount is the wrong unit for measuring security load.
If you hire in proportion to developers, you'll be behind from the start. And if every hire is spent doing the same manual work, the ratio never improves.
Why security work multiplies instead of adding up
Adding a developer doesn't add one unit of security work. It adds several, and they compound.
Code. More developers means more commits, more reviews and more dependencies, and each of those needs checking.
Cloud. Every service and environment adds configuration to get right. Misconfiguration is a continuous risk, since a setting that was correct on Monday can be wrong by Friday.
Applications. More applications and APIs means more running surface to test, and each release can change what's exposed.
Coordination. More teams means more people asking security questions, waiting on reviews and requesting exceptions.
Security demand grows with code, cloud, applications and developers all at once. A model that scales with one of those can't keep up with four.
Where security headcount actually goes
Look at how a small security team spends its week. A lot of it isn't security judgment:
- Triaging scanner output to find what's real
- Chasing developers to fix known issues
- Answering the same questions repeatedly
- Preparing evidence for audits and customer security reviews
- Reviewing changes that are low risk but still need a human to look
This is where hiring fails. A new person inherits the same manual workflow, so you've added capacity without adding leverage. If one person spends 60% of their time on triage and follow-up, the second hire spends 60% of theirs on it too.
The question to ask before opening a requisition is how much of your current team's time goes to work a system could do.
Automation as a force multiplier
Automation changes the shape of the curve. Instead of every unit of security work needing a person, most of it runs continuously, and people handle the exceptions that need judgment.
In practice, that means automating the layers where volume is highest:
- Detection in the workflow. Scanning code, cloud configuration and running applications automatically, where developers already work, rather than in periodic reviews.
- Prioritization. Filtering findings down to what's exploitable or relevant, so humans see a short list instead of a long one.
- Developer-ready remediation. Giving engineers clear, specific fixes so security doesn't have to translate every finding.
- Evidence collection. Producing audit and customer-review evidence as a byproduct of normal operation.
Automation doesn't replace security professionals. It decides what they spend time on. One person with the right tooling covers ground that would otherwise take a team.
A scalable operating model
A model that holds up as engineering grows has three parts.
Automate the baseline. Every repo, cloud account and application gets the same checks by default. Coverage doesn't depend on someone remembering to request a review.
Put security in the developer's path. Findings show up in the pull request or pipeline, with context to act on. The fix happens at the cheapest point, before the code ships.
Reserve people for judgment. Humans handle threat modeling, architecture decisions, risk acceptance and incident response, which are work that gets harder to automate, not easier.
For a fintech without a dedicated security team, this is the realistic route. You can't hire your way to coverage with one or two security people. You can get there by making each of them far more effective.
The economics
Compare the two models in terms a CFO can use.
Headcount-led: Cost rises with every hire. Coverage rises only as fast as hiring and ramp time allow. Output per person stays flat because the workflow doesn't change. Each departure takes institutional knowledge with it.
Leverage-led: Cost rises more slowly because most coverage comes from systems. Output per person climbs as automation absorbs routine work. Coverage extends to new code and infrastructure by default.
The useful metric is security coverage per dollar and per security professional, not the ratio of security staff to developers. Track what share of repos, cloud accounts and applications are covered automatically, how long findings take to reach the right developer, and how much of the team's week goes to repetitive work. If those improve while engineering doubles, the model is working.
Mistakes to avoid
- Hiring to fix a workflow problem. If the team is buried in triage, a new hire will be too.
- Buying tools that add alerts without reducing work. More findings with no prioritization increases load.
- Treating automation as all-or-nothing. Start with the highest-volume, lowest-judgment work and expand.
- Measuring security by headcount ratios. Ratios hide whether the work is getting done.
Where to start
- List where your security team's time went last month and mark what could run without a person.
- Check what share of your code, cloud and applications is covered by automated checks today.
- Pick the highest-volume manual task and automate that first.
- Revisit the headcount question after, with real numbers on what's left.
Security shouldn't require a new hire every time engineering adds another hundred developers. When it does, the model is wrong, not the hiring plan.
Rezliant Maestro is built for fintech teams that need security coverage without a dedicated security org. See how it works
FAQ
What's a good developer-to-security ratio?
There's no reliable universal number, and any figure you find should be sourced before you rely on it. The ratio matters less than how much of your code, cloud and applications is covered, and how much of your security team's time goes to routine work.
When should a startup make its first security hire?
When you have enough judgment-heavy work, like architecture review, risk decisions and incident response, to keep a person busy. Before that, automated coverage gives you a baseline without the hire.
Does automation replace security engineers?
No. It removes repetitive work so engineers spend time on decisions that need judgment.
How do I make the case for automation to a CFO?
Show cost per unit of coverage, and compare it with the cost and timeline of hiring to reach the same coverage.