Brutalist Security Meets Team of Teams: Introduction

Security Brutalism gets its strength from strict adherence to core principles such as hardened systems, network segmentation, regular patching, enforced multi-factor authentication, and zero trust. These fundamentals act as the concrete barriers that make common exploits and opportunistic attacks harder to pull off. But a program built on these principles still needs the right culture to work, one that supports adaptability, collaboration, and continuous learning. That's where Gen. McChrystal's Team of Teams model becomes useful.

Instead of a rigid hierarchy, small empowered units handle specific security functions such as threat intelligence, incident response, vulnerability management, and security awareness, while staying connected to each other and to the rest of the business. This connection depends on shared consciousness and a common purpose, similar to how cells communicate within an organism. Applied to security, it means leadership, IT, and technical teams share findings, threats, and vulnerabilities on an ongoing basis. When threat intel spots a new tactic, vulnerability management can scan for exposures, incident response can prepare playbooks, and IT can deploy fixes, all happening in parallel rather than in sequence. That parallel response is what makes the model faster than a traditional chain of command.

Combining Security Brutalism with Team of Teams builds redundancy directly into the security posture. If one team gets compromised or overwhelmed, others can step in, so the organization relies on a network of capabilities instead of a single point of failure. The constant feedback loops built into this structure also drive continuous improvement, since lessons from incidents or threat intelligence spread quickly and get used to strengthen both the core controls and the teams' processes.

Getting this right depends heavily on organizational buy-in. When security becomes part of how the whole organization works, rather than a separate department's job, it draws in participation from every corner. Developers writing secure code, HR running security awareness training, and IT operations maintaining secure configurations all become part of the defense, and this shared ownership is what turns the fundamentals into something that actually holds up.

The two approaches reinforce each other well. Security Brutalism favors clear, effective controls delivered through lean teams that prioritize action over bureaucracy, and Team of Teams spreads these responsibilities across autonomous, specialized units, each handling a different piece of the security stack. Security Brutalism supplies the proven fundamentals, hardening, patching, MFA, zero trust, and Team of Teams keeps those fundamentals evolving through shared learning and quick adaptation. Because everyone across threat intel, incident response, IT, and engineering shares context, teams can also make decentralized decisions fast, acting within their domain without waiting on top-down direction. The result is an organization built to hold under pressure while staying agile enough to respond as threats change.

Putting this into practice

There's no single blueprint here. Each organization needs to adapt the model to its own culture and environment, but a few patterns tend to show up.

Each autonomous team can take ownership of a baseline of brutalist controls in its own domain, covering secure coding practices, access controls, and testing protocols. Security professionals embedded across teams can form guilds or communities of practice to keep standards consistent and share knowledge. A smaller central security team can act as the architect of the overall framework, setting foundational principles, choosing core technologies, and providing tooling and guidance to the rest.

Liaisons with a strong security focus can sit between teams, making sure security gets built into daily workflows and that information about threats flows where it needs to go. Automation carries a lot of the weight here too, through code scanning, infrastructure-as-code with security built in, and automated compliance checks, all of which reduce friction and keep controls consistent. The infrastructure given to teams should carry strong security defaults from the start, through secure OS configurations, network segmentation, and authentication that's hard for individual teams to weaken. And feedback on security gaps should stay direct, pointing out vulnerabilities and non-compliance plainly, in keeping with the uncompromising spirit of Brutalism.

What this can offer, and where it gets hard

Combining layered, uncompromising controls with distributed ownership tends to produce a more resilient posture. Teams react faster to incidents in their own domain, and security responsibility built into each team strengthens the culture across the organization. Since Team of Teams scales naturally, the security approach scales along with it.

The challenges, however, are very real too. Keeping standards consistent across many autonomous teams takes ongoing effort, and Security Brutalism's uncompromising edge can create friction with teams focused on speed. Coordinating across a decentralized network needs clear communication and defined responsibilities, and security knowledge can end up siloed inside individual teams if collaboration isn't actively maintained. We'll cover both problems in the next posts.

Combining Security Brutalism with Team of Teams builds a strong, resilient foundation while keeping the agility and scale that come from empowered, autonomous teams. Getting there takes careful planning, clear communication, and real collaboration.