Squad

A squad is a small, cross functional team that owns a specific feature set or service area. The model gives the team autonomy to make delivery decisions, choose appropriate tools, and manage the service end to end. Squads work best when they stay small enough to coordinate closely and move quickly.

Expanded Definition

In security and technology organisations, a squad is more than a project team. It is a durable, cross-functional unit that owns a bounded service, product area, or operational outcome from design through support. The defining feature is not simply size, but decision rights: a squad can prioritise work, select tools within guardrails, and coordinate the people needed to deliver and operate the service. That autonomy makes the model useful where speed and accountability matter, but it also creates governance pressure because responsibilities that were once centralised become distributed across the organisation.

The term is often borrowed from product and agile operating models, so usage in the industry is still evolving. Some organisations use it to describe a delivery team, while others expect the squad to include engineering, security, operations, and data roles. At NHI Management Group, the key distinction is that a squad should own outcomes, not just tickets, and should understand the security consequences of the service it runs. The most common misapplication is treating a squad as a temporary project group, which occurs when teams are assembled for delivery but lack durable ownership of the service after launch.

Examples and Use Cases

Implementing the squad model rigorously often introduces coordination overhead at the boundaries, requiring organisations to weigh local speed against enterprise consistency.

• A platform squad owns an internal secrets service, including provisioning, rotation, and incident response, so application teams do not manage credentials ad hoc.
• A product squad is responsible for a customer-facing API and its telemetry, using NIST Cybersecurity Framework 2.0 as a shared language for resilience and risk management.
• An identity squad manages joiner-mover-leaver workflows for human and non-human accounts, reducing handoffs between IAM, engineering, and operations.
• A security squad embeds with an application squad to review threat modelling, access patterns, and logging requirements before release.
• A data squad owns a governed pipeline and the controls around who can change schema, access datasets, and approve downstream integrations.

In practice, squads work best when the service boundary is clear and the team has authority to act within it. Without that boundary, the model can create duplicate tooling, inconsistent controls, and confusion over who approves risk decisions.

Why It Matters for Security Teams

For security teams, the squad model changes where accountability sits. Security outcomes are easier to maintain when the team that builds or operates a service also owns its access controls, logging, patching, and escalation paths. But if squads are given autonomy without guardrails, security reviews can become inconsistent, secrets can sprawl across teams, and critical decisions can be made without enterprise oversight. That is especially relevant where squads manage identity workflows, automation, or agentic systems, because ownership of non-human identities, credentials, and tool permissions must stay explicit.

The model also affects incident response and governance. A squad that owns a service end to end should know which controls map to resilience, which issues require escalation, and which decisions cannot be local. The benefit is faster remediation and clearer responsibility. The cost is that security maturity must be distributed, not assumed. Organisations typically encounter the limits of the squad model only after a breach, audit finding, or service outage exposes that no single group had true ownership of the control gap.