The goals of a first security year stay the same from 20 to 200 engineers: ownership, inventory, a protected code path, a fix routine, and incident readiness. What changes is who does the work, how formal the process is, and how you keep teams consistent. Small teams rely on people, larger ones on defaults.
What stays constant
OWASP's Software Assurance Maturity Model notes that there is no single recipe that works for all organizations and describes itself as risk driven. That fits here. A 20 person company and a 200 person company face different risks, but they need the same foundations in roughly the same order.
What shifts with size
| Topic | Closer to 20 engineers | Closer to 200 engineers |
|---|---|---|
| Owner | CTO or a delegate, part time | A dedicated lead, often with one or two helpers |
| Inventory | A spreadsheet reviewed monthly | Automated discovery feeding a catalog |
| Code path | Everyone knows the rules | Rules enforced by settings and templates |
| Scanning | Central config, a few repos | Organization wide defaults, exceptions by request |
| Review meeting | One weekly meeting for all | Team level reviews plus a monthly cross team one |
| Questionnaires | The owner answers | Intake queue, answer library |
| Training | Onboarding talk | Role based material, champions in teams |
| Incident readiness | One shared contact sheet | Rota, severity ladder, exercises by team |
Three things that break first as headcount grows
- Informal knowledge. At 20 people, everyone knows who can approve an exception. At 120 they do not. Write it down before you need it.
- Inconsistent repositories. New repos appear with different settings. Fix this with templates and organization level defaults rather than reminders.
- The owner becomes a bottleneck. If every decision routes through one person, delegate by category with clear limits.
What a mid point looks like
Around the middle of the range, companies often hit a stage where the part time owner model strains but a full team is not yet justified. The practical move is to split roles before splitting headcount: one person for program and customer assurance, one for tooling and automation, with engineers in each team owning fixes. See the post on which tasks can be part time.
How to scale a roadmap without rewriting it
Keep the outcome per quarter the same, and change the delivery mechanism. For example, "every repository has protected branches" can be met by a spreadsheet check at 20 engineers and by an organization level rule at 150. The milestone is stable; the method scales.
What not to copy from bigger companies
Large company programs include committees, formal risk registers and heavy tooling suites because they have hundreds of teams to coordinate. A 40 person company that copies them spends its year on process. Adopt a practice when its absence has caused you a real problem.
Safeguard's asset discovery, policies and gates, and reachability analysis scale the same checks from a few repositories to many, so the milestone does not change as the company grows. You can start with the free scan.
Quick check
At what size do we need a dedicated security hire?
There is no fixed number. Use signals: skipped weekly reviews, unowned findings, and customer questions queuing behind feature work.
Should a small company use the same roadmap as a large one?
Use the same sequence of goals, but with lighter methods. Skip committees and heavy process until a real problem asks for them.
Sources
Last reviewed: 19 October 2026.
