The staffing model most SecOps programs use is the one they had three years ago. A pile of analysts at the bottom, a few senior engineers in the middle, a manager at the top, and an architect somewhere at the side. It was the right model when the work was synchronous, alert-driven, and evenly distributed. None of those things are true in 2026.
Modern supply chain SecOps work is asynchronous, advisory-driven, and distributed across thousands of components and hundreds of services. The staffing model has to match the shape of the work. This article describes a staffing model that does, and the path to get there from where most teams currently are.
The four roles
A modern SecOps program needs four distinct roles. They are not job titles. They are functions. A person can hold more than one. A small program might have one person holding all four. A large program will have multiples of each. The point is that the four functions exist and somebody is named for each.
The first role is the threat intake engineer. They monitor advisories, evaluate relevance, and decide whether each advisory becomes an incident, a finding, or noise. Their primary skill is judgment under partial information. They are the first line, and their decisions shape everything downstream.
The second role is the response engineer. They run incidents end to end, from scope through remediation. They are not specialists in any one technology. They are specialists in process, communication, and coordination. They run the runbook, run the handoff, and produce the timeline.
The third role is the platform engineer. They maintain the security tooling, write detections, build automations, and integrate the platforms. Their primary skill is software engineering. They are the leverage of the program, because their work multiplies what the response engineer can do per hour.
The fourth role is the program engineer. They run the metrics, the audits, the policy framework, and the strategic planning. They are the connective tissue between the operational team and the executive sponsor. Their primary skill is communication and rigor. They are the role most often missing in immature programs, and the role most directly correlated with the program's survival across leadership transitions.
The wrong shape
Most teams I see have the wrong shape. They have too many threat intake engineers, not enough response engineers, and almost no platform engineers. The shape was driven by the old SOC model, where intake was the bottleneck. Intake is no longer the bottleneck. Response capacity is, and platform engineering is the way to grow it.
The right shape, for a typical mid-sized company, is roughly twenty percent threat intake, forty percent response, thirty percent platform, ten percent program. For larger companies, the platform percentage grows. For very small companies, the program percentage may be a fraction of a person's time, but it has to be somebody's named responsibility.
If your team is more than fifty percent intake, you are over-staffed for a problem that has been automated. If your team is less than twenty percent platform, you are leaving leverage on the table. If you have nobody dedicated to program work, you will be unable to demonstrate program improvement, and your budget will be at risk.
The automation ratio
A useful measurement is the automation ratio. It is the fraction of intake decisions, scoping queries, and remediation actions that are produced by automation versus produced by a human.
A program with a ratio under twenty percent is operating manually. The team is busy because everything is being done by hand. A program with a ratio over eighty percent is over-automated. The team is missing the judgment calls that automation cannot make. A program with a ratio between fifty and seventy percent is in the right zone. The automation handles the volume, the humans handle the edge cases.
Use platform tools to push the ratio up. safeguard_evaluate_policies automates the intake decision for routine findings. safeguard_get_remediation_plan automates the scope of the fix. safeguard_fix_vulnerability automates the actual pull request creation. Each automation moves a class of work from response engineer time to platform engineer time, and the response engineers are freed for the cases that still require judgment.
The automation work is funded by the platform engineer headcount. If you do not have platform engineers, the ratio stays low and the response engineers stay overworked. The first hire most programs need is not another analyst. It is a platform engineer.
Growth paths
A staffing model without growth paths produces attrition. People leave because they cannot see what comes next. The four-role model has natural growth paths if you make them visible.
Threat intake engineers can grow into response engineers by demonstrating they can run an incident end to end. Response engineers can grow into platform engineers by writing automations that close detection gaps the team has been hand-handling. Platform engineers can grow into senior platform engineers by owning the architecture of a major subsystem. Program engineers can grow into program leaders by owning a strategic initiative.
Across all four, there is a senior individual contributor track and a management track. The management track is not the only path up. Some of the most valuable people in a SecOps team are senior platform engineers who do not manage anyone but produce more leverage than a manager would. Make the senior individual contributor track visible, with title, compensation, and scope, or you will lose those people to companies that do.
Hiring against the model
When hiring, the question is not "do we need more security people." The question is "which of the four roles is the constraint right now." The constraint is the role where work is queuing up despite the existing staff working at capacity.
The signal of a constraint is queueing. If advisories are sitting in intake longer than the program's stated service-level objective, you have a threat intake constraint. If incidents are running over schedule, you have a response constraint. If automations are pending more than two quarters, you have a platform constraint. If metrics are not being published, audits are slipping, or the executive review is improvised, you have a program constraint.
Hire against the constraint, not against the org chart. Sometimes the constraint changes between hiring decisions, and the hire you should have made six months ago is not the hire you should make today. That is fine. Re-evaluate every quarter.
The contractor question
Some programs use contractors heavily. The right way to use contractors is for capacity, not for capability. A contractor can extend the response engineer pool during a busy quarter. A contractor cannot replace the program engineer, because the program work depends on continuity, institutional knowledge, and trust with the executive sponsor.
A useful rule is that no role can be more than thirty percent contractor in steady state. Higher than that and you are buying the appearance of capacity at the cost of long-term capability. The numbers can spike higher temporarily, for a known surge, but they should return to baseline.
What success looks like
A well-staffed modern SecOps program looks like this. The team is small relative to the size of the engineering organization. The roles are named, distinct, and visibly differentiated. The automation ratio is in the right band. Hiring decisions are tied to constraints, not to headcount targets. Growth paths are explicit. Contractor usage is bounded.
The hardest part of the model is not the design. It is the discipline to maintain it through the next leadership change, the next acquisition, and the next budget cycle. Programs that hold the model produce continuous improvement. Programs that drift back to the old shape spend most of their time fighting fires that the better-shaped program would have prevented.
Pick a role. Name it. Hire against it. Repeat.