A security organization scales when its structure matches the work it must perform, the authority it needs to act, and the coverage it can sustain, not when it adds the next box from an enterprise org chart.
Before changing titles or adding a team, define four things: your threat-driven demand, the functions you must own, the work you can buy externally, and the decision rights that must remain internal. Then allocate people to those functions.
Benchmark charts are useful inputs, but they are not operating models. A 10-person team that copies a large company's separation between SOC operations, detection engineering, threat intelligence, and incident response can end up with four one-person queues, not four durable capabilities.
The crucial distinction is between a role and a function. A role is a person. A function is a repeatable system for turning demand into outcomes, and that distinction is what decides whether a team scales.
In brief:
- Design security structure around four inputs: demand, coverage, authority, and capacity, not an inherited org chart.
- A function is more than a role with a backlog: it needs a visible intake mechanism, a lifecycle with quality controls, and explicit handoffs with the teams it depends on.
- Coordination exposure rises faster than headcount does. Adding people without clarifying ownership and escalation rules can create more coordination burden than capacity.
- Industry estimates commonly place a continuously staffed in-house SOC in the high single digits or above before leadership, engineering, and absence coverage are added, though the number that fits your team depends on scope, shift design, automation, and response authority.
Why benchmark charts don't transfer
Security charts often converge on familiar enterprise patterns: a tiered SOC, detection engineering and threat intelligence in separate boxes, arranged the way a large company's diagram arranges them. Benchmarking can reveal useful functions and reporting relationships, but it cannot determine which of those functions need dedicated capacity in your environment.
The RH-ISAC and Accenture org chart benchmark is a good example of doing this well: it studied 66 organizations, identified 15 higher financial performers among them, and built a suggested structure from those patterns plus industry risk analysis. That's a legitimate way to generate a benchmark, but it's not a substitute for sizing your own team against your own demand, and the report doesn't claim otherwise.
The role-versus-function test
I've made this argument for detection engineering already: treating it as a person who writes rules caps the program at that one contributor's maturity. The same test decides scaling for threat hunting, CTI, and governance, risk, and compliance (GRC): a function exists only once it passes four tests, sequenced the way FIRST.org advises: establish the discipline, add lifecycle practices, formalize partnerships, then add specialist capacity as demand grows.
Test
A function exists when…
Purpose
It owns a repeatable outcome, such as detection coverage, incident readiness, or third-party risk decisions
Demand
It has a visible intake mechanism and a prioritized backlog
Operating system
It has a lifecycle, service levels, quality controls, and documented artifacts
Interfaces
It has explicit handoffs and decision rights with engineering, IT, legal, privacy, and business owners
The failure runs in both directions
Early detection-engineering hiring can create operational work faster than the underlying management system can absorb it, a premature-scaling pattern Ryan McGeehan has documented. A dedicated team can also sit at the center of competing demands from intel, hunting, and red teams even with strong talent in place.
Headcount thresholds matter only once a function passes the four tests above: 60% of organizations now run dedicated detection engineering teams, the SANS 2025 Detection Engineering Survey reports, though closer to 80% fund the work in some form, so adoption still trails investment. A useful trigger for specialization is a function with sustained demand, a visible backlog, and defined quality criteria, with enough volume to justify protecting the capacity.
Coordination costs rise faster than headcount
A group of n people has n(n−1)/2 possible pairwise paths, the formula Brooks worked out in The Mythical Man-Month. That's not a count of actual handoffs, but it shows why adding people without clarifying ownership and escalation rules creates coordination burden, not just capacity. Tiered SOC structures are a version of this: tiering works when alert volume and escalation authority justify it, and the problem is repetitive handoffs, not tiers as a category.
A recurring failure pattern has Tier 1 enriching an alert without decision authority, Tier 2 repeating part of the validation, and Tier 3 receiving the escalation late, matching what I see when I map incident timelines against a copied three-tier model: queue time exceeds investigation time. Teams often respond by adding a tier, which adds handoffs, and headcount added this way buys less than the hiring plan assumed.
When to centralize, embed, or outsource
MITRE's SOC taxonomy runs from centralized and distributed through federated and coordinating models, and each carries a different constraint: centralized breaks down with dispersed business units, distributed needs federation to avoid visibility gaps, and federated assumes a parent organization setting standards.
The question worth asking of any model is the one MITRE's own guidance emphasizes: does this structure match what your organization needs, or just the org chart you inherited.
Keep what compounds, embed what scales
Teams keep in-house the work where organizational context compounds, particularly security roadmap and planning, security administration, and architecture and engineering, per SANS's 2025 SOC survey data.
Embedding pushes expertise outward instead. Phil Venables argues that scaling security often means giving up some direct control and building security engineering capability inside the product and IT teams themselves. Netflix's AppSec team applied a version of this: a shared weekly on-call rotation covering bug bounty triage, pentesting coordination, PSIRT, and security reviews protected the rest of the team's focused project work from interrupt-driven operations.
Outsourcing buys coverage, not accountability
Outsourcing works best against the coverage layer, usually 24/7 triage, where an MDR provider can own contracted operational tasks like monitoring, investigation, and pre-authorized response. Expel describes a common split where the provider handles Tier 1 and Tier 2 work while the internal team owns deep investigation, architecture, and strategy.
What a contract can't assign away is the accountable executive: decision rights for isolation, shutdown, ransom negotiation, notification, and legal privilege have to be named as staying internal, in writing, before an incident forces the question. MDR-to-IR handoffs are a recurring failure point specifically when those decision rights, contacts, and escalation thresholds were never defined.
Signals the operating model is failing
Structural bottlenecks show up in operational data before anyone proposes a reorg. Five signals recur, and each is measurable this quarter:
- Improvement work stalls: Google's site reliability engineering (SRE) model caps operational work at 50% of an engineer's time as a capacity-management principle, not a universal SOC rule. Security leaders can apply the same logic: a team spending most of its time on operational load has little left to fix the load itself.
- Rising handoff counts: Pull ticket audit logs and count team-to-team reassignments per incident. Climbing counts can point to unclear ownership even when staffing is sufficient.
- Authority arrives late: Limited executive involvement in readiness and decision-making is a common incident-response weakness. Post-incident timelines often show it directly: the technical team could act well before anyone authorized action.
- Turnover in triage: 62% of SOC professionals say their organization isn't doing enough to retain staff, the SANS 2025 SOC Survey reports. When exits cluster at Tier 1 and exit interviews cite endless alert triage, the structure is burning its own intake pipeline.
- Manual metrics compilation: 69% of SOCs still rely on manual or mostly manual processes to report metrics, the SANS 2025 SOC Survey reports. If mean time to acknowledge (MTTA), escalation rate by tier, and handoff count per incident can't be pulled automatically, the bottleneck is invisible by construction.
Run a 90-day structure audit
For each security function, list its demand, its accountable owner, its weekly operational load, its unresolved backlog, its required coverage window, its handoffs, and the decisions inside it that need business authorization.
If a function has sustained demand but no lifecycle or owner, build the function before hiring the title. If a provider can cover the clock but can't supply organizational context, retain decision authority internally regardless of what the contract offers to take on. Only then redraw the chart.
Frequently asked questions about security team structure
How should a small security team be structured?
Structure a 1–5 person team around functions, with titles secondary. At smaller companies, security organizations commonly run three to five FTEs concentrated in security engineering and corporate security, with GRC and detection shared or outsourced. Keep generalists who own outcomes end to end, and buy continuous coverage externally once the shift math for around-the-clock monitoring stops adding up internally.
When do you split roles into specialized functions?
Split when a function's constraint trips, not at a headcount milestone. Detection engineering earns dedicated capacity when rule writing becomes an unsustainable side task with no version control or testing. A dedicated GRC hire makes sense when multiple compliance frameworks create a sustained operational backlog. Cloud security may warrant specialization as multi-cloud complexity grows and cloud-native environments become a major detection coverage gap.
What should a mid-market team outsource versus own?
Own the work where your context compounds: roadmap and planning, security architecture and engineering, detection tuning, and incident decision authority. Outsource the coverage layer, meaning 24/7 triage, plus deep specializations like pen testing and forensics. An MDR provider can take on contracted operational tasks, but accountable decisions on containment, extortion response, and disclosure stay internal regardless of contract.
How does team structure change as you scale?
There's no universal staffing sequence, but common inflections include an early builder-type hire, then several generalists organized loosely by function. The next split, into managed teams with their own owners, tends to happen when a team can no longer sustain operational coverage, improvement work, and cross-functional support with the same people.
A security platform engineering team follows when a function is large enough that its unique problems need custom code. Each transition responds to a coverage or coordination constraint, not a fixed number of heads.