Building a Security Practice Inside an Established Operator

April 27, 2026 · 12 min read

When a regional operator — a managed-services provider, a mid-sized IT shop, a infrastructure-focused consultancy — decides they need a security practice, the first thing they usually do is try to import the structure of a security practice from somewhere larger. SOC job ladders. Tier 1 / Tier 2 / Tier 3 analyst rotations. Incident response runbooks modeled on what Mandiant or CrowdStrike publishes. Tooling budgets modeled on the gear an enterprise SOC runs.

Almost all of it misfires, and the organization ends up either spending a lot of money on capabilities that don’t fit or abandoning the effort entirely and telling themselves they didn’t really need a security practice after all. Both outcomes are common enough that we’ve seen the pattern dozens of times. The failure isn’t about commitment or budget; it’s about architecture. The shape of a security practice that works inside an established operator is meaningfully different from the shape of one that works inside a security-first organization, and the difference has to be designed in from the start.

Why imported patterns fail

Large security organizations are staffed by specialists. An L1 analyst isn’t expected to do architecture; an architect isn’t expected to run IR drills; an IR lead isn’t expected to do vendor evaluation. The org chart is wide and the roles are thin.

A regional operator can’t staff that way. Revenue-per-head doesn’t support it. The organization is already composed of generalists — senior engineers who do architecture and operations and on-call and client communication and vendor management. Trying to bolt a specialist pyramid onto that generalist foundation produces a structure that is simultaneously over-resourced for the work volume and under-capable for the work variety, because the generalists end up doing all the real work anyway and the specialists can’t be kept busy.

The other failure mode is importing incident response patterns designed for an organization that can go dark for 72 hours during a breach while the IR team runs the playbook. Regional operators usually cannot. They have clients who need to stay up, on-call rotations that still need to happen, and commercial relationships that will not pause while the security function handles its first real incident. The playbook has to be designed for operational continuity throughout, which most imported playbooks are not.

What small-senior actually looks like

The shape that works in an operator context is what we call small-senior. Not a pyramid; a short horizontal structure. Fewer people, each operating at a higher level than they would in a large organization, with more breadth and less specialization.

The roles are:

Three to five total humans, scaled with external capacity as needed. That’s the whole structure for most regional operators. Under 50 engineers in the parent organization, you’re in small-senior territory.

The phased build-out

A security practice inside an existing operator is built in four phases. Each one takes roughly a quarter. Trying to compress is the second-most-common failure mode (the first is trying to import patterns); trying to do them in parallel is the third.

Phase one: program skeleton (months 1–3)

Before any tooling, before any hires, before any client-facing work, the practice needs a skeleton. That means:

The charter is the document that keeps the practice from accreting scope creep. Every proposed expansion of the practice’s work gets held up against the charter, and if it doesn’t fit, it either changes the charter (deliberately) or gets declined. Without a charter, a security practice inside an operator will absorb every vaguely-security-flavored problem in the organization until it collapses.

Phase two: baseline capabilities (months 3–6)

Now the work. The first operational capabilities to stand up are the ones that produce the most visibility per unit of effort:

This phase establishes that the practice produces visible value. Without visible value, the parent organization will rescind its commitment the first time budgets get tight. With visible value, the practice survives its first crisis and gets to keep building.

Phase three: operational integration (months 6–9)

Now the harder work: integrating the security practice with the operations function that already exists. The practice cannot operate as a separate island if it’s going to actually improve the organization’s posture. It has to be woven into the work that’s already happening — change management, incident response, client onboarding, system retirement.

This is the phase where the practice usually encounters its first real resistance. Operations people don’t want a new approval step. Client teams don’t want to explain to clients that their system has findings. Sales teams don’t want to slow deals down with security questions. Every one of these resistances is legitimate — they’re protecting things that matter — and every one of them has to be negotiated, not overridden.

The practice lead’s job in this phase is to make the integration cheap for everyone else. Security approval that happens in 24 hours, not 2 weeks. Findings that come with remediation paths attached, not just scorecards. Client-facing reporting that’s good enough for the client-facing teams to actually use. If the integration is cheap, it happens. If it’s expensive, it gets routed around.

Phase four: client-facing capability (months 9–12)

The last phase — and the one that almost every operator wants to do first — is offering security services to the organization’s clients. This is last because it should be. The practice needs to work internally before it can credibly be offered externally. Every operator that leads with client-facing security services has a practice that cannot keep its internal house in order, and clients notice. The clients who don’t notice are the wrong clients.

Once the internal practice is stable, client-facing offerings can be built on top: security assessments, vulnerability management services, compliance support, incident response retainers. The services are structured as extensions of the internal capabilities, not as separate products. That structure keeps the practice coherent and keeps the client-facing work from diluting what’s been built.

What good looks like at twelve and twenty-four months

At twelve months, a security practice built this way has: an operating charter that’s been iterated against reality, a vulnerability management function that runs continuously, documented remediation tracking with real SLAs, integration with the organization’s change and incident processes, the beginnings of a client-facing offering, and a small senior team that can cover the work without heroics.

At twenty-four months, it has: a measured and improving MTTR on remediation, a credible incident response capability tested at least once in a real incident, a client-facing service line generating revenue, renewed internal commitment from leadership who now see the practice as load-bearing, and — most importantly — operational muscle memory. The practice runs because the organization has internalized how it runs, not because one person is pushing it along.

Both of those states are achievable. Neither is guaranteed. The variable that determines whether they’re reached is not budget, not headcount, and not tooling. It’s whether the build-out is architected correctly from the start — small-senior, phased, integrated, visible — or whether it imports patterns from a larger context that doesn’t fit.

Where this doesn’t work

The honest closing. Small-senior security practices don’t scale past a certain size. Somewhere between 75 and 150 parent-organization engineers, the short-horizontal structure stops absorbing the load. Organizations at that size need to transition to a larger, more specialized structure — and the transition is harder than building one or the other cleanly from the start.

For operators below that size, though — regional MSPs, mid-sized IT shops, infrastructure consultancies, the organizations that make up the working middle of the industry — the small-senior shape is not a compromise. It’s the correct architecture, and it produces better outcomes per dollar than the enterprise structure it’s sometimes asked to imitate. Most organizations that try to build in this range and fail do so because they asked the wrong structural question. The right question isn’t “how do we build a security practice like Mandiant’s” — it’s “how do we build one that fits an operator like us.”

If that’s a question you’re carrying, tell us about it.

← All essays