Brutalist Security Meets Team of Teams: Implementation Guide

This guide continues from Brutalist Security Meets Team of Teams: Introduction and covers organizational fit, implementation runbook, governance structure, and operational practices for integrating Security Brutalism with the Team of Teams methodology.

Who Should Use This Approach

This integrated methodology works best for organizations with operational complexity, rapid growth, and a need for agility in the face of evolving security threats. It isn't universally applicable.

Organizations with multiple product lines, business units, or geographically dispersed teams benefit from the decentralized structure of Team of Teams paired with the consistently applied security of Security Brutalism. Because the Team of Teams model scales naturally, embedding security responsibilities within each autonomous unit lets security scale alongside organizational growth. Companies already running agile or DevOps practices can fold Security Brutalism principles into existing workflows, which enables effective DevSecOps through empowered teams and automated controls. Organizations holding sensitive data, critical infrastructure, or facing a high threat landscape gain the most from the robust, uncompromising nature of Security Brutalism. The same goes for organizations that want shared responsibility for security across all teams, since this produces a stronger security culture than centralized, siloed approaches, and for those willing to accept that strong controls are sometimes less convenient in the short term in exchange for long-term resilience. None of this works without a genuine commitment to communication and collaboration, since the Team of Teams model depends on both.

This approach also helps organizations facing specific operational problems. It establishes a baseline of strong security across teams with inconsistent practices and varying maturity levels. Empowered teams with direct security ownership react faster to threats and vulnerabilities within their own domain, which relieves the bottlenecks that build up when one centralized group owns everything and lets security efforts run in parallel. As the organization grows, embedding security within each team provides a more scalable solution than trying to stretch a central team across an expanding footprint. It also pushes development teams toward greater ownership of security in their own products and services.

The approach fits less well elsewhere. In small, highly centralized organizations, the overhead of building security champions and formal guilds can outweigh the benefit, and a more direct approach is often sufficient. Organizations with a genuinely low threat profile and non-sensitive data may find the rigor of Security Brutalism excessive. Highly regulated environments with rigid, top-down compliance requirements can struggle to reconcile them with a decentralized Team of Teams structure without careful planning. And because both Security Brutalism and Team of Teams require structural change, organizations with strong resistance to change or collaboration will struggle to adopt either.

Implementation Runbook

This runbook outlines the phases, activities, and considerations for implementing Security Brutalism within a Team of Teams framework. The goal is to establish a robust, uncompromising security posture by integrating foundational security principles into a decentralized, collaborative organizational structure. It's intended for security leadership, engineering leadership, team leaders, and security champions.

Phase 1: Vision and Strategy Definition

Start by articulating what Security Brutalism means in concrete terms: mandatory multi-factor authentication for all access, strict least-privilege controls enforced at every level, automated and frequent vulnerability scanning, immutable infrastructure where applicable, and clear, non-negotiable security baselines for all systems. Make sure this approach supports the organization's broader business objectives rather than hindering innovation or agility, and identify the key risk areas it's meant to address. Define the initial scope, whether that's specific product lines or infrastructure components, and plan a phased rollout that allows for learning and adjustment along the way, with key stakeholders identified early. Finally, establish measurable success metrics: adoption rates of security controls, reduction in vulnerabilities, and incident response times.

Phase 2: Organizational Structure and Roles

Nominate or recruit a security champion within each team to act as the primary point of contact for security matters in that team, and create guilds or communities of practice where champions and specialists can collaborate, share knowledge, and help define and enforce security standards. Clearly define the central security architecture team's role in setting the overall framework and providing specialized expertise, alongside each autonomous team's own responsibilities for implementing controls, participating in reviews, and responding to vulnerabilities in their domain. Establish clear communication pathways so security information flows between teams, champions, and the central security team without friction.

Phase 3: Defining "Brutalist" Security Standards and Tooling

Translate Security Brutalism principles into concrete, actionable standards covering password complexity, encryption, and logging and monitoring policies. Identify and deploy the foundational tools that support these standards, vulnerability scanners, static and dynamic code analysis, IAM, SIEM, prioritizing tools that can be automated and woven into existing team workflows. Build secure configuration baselines for operating systems, applications, and infrastructure components, and turn them into templates teams can apply consistently. Wherever possible, automate the controls themselves, using infrastructure-as-code to enforce secure configurations and automated scanning within CI/CD pipelines.

Phase 4: Team Enablement and Training

Run security awareness training for all team members that emphasizes why brutalist principles matter and what each person's responsibility is. Give security champions more specialized training so they can effectively advocate for and implement security within their teams, and provide hands-on training on the specific tools and processes teams will actually use. Build accessible documentation covering standards, tools, and best practices, and let the security guilds contribute to and maintain it.

Phase 5: Implementation and Integration

Begin with a small number of pilot teams who implement the approach and provide feedback before wider rollout. Embed security checks and controls directly into existing development pipelines so security becomes a standard part of planning, design, and deployment rather than a separate gate. Use what you learn from the pilot to gradually extend the rollout to other teams, and put mechanisms in place to monitor implementation continuously and collect feedback on how usable the standards and tools actually are in practice.

Phase 6: Governance and Enforcement

Formalize the Brutalist Security standards into clear, enforceable policies, and put processes in place to monitor adherence across all teams. Define what happens when teams fall out of compliance, and conduct periodic security audits to assess how well the controls are working and where they need to improve.

Phase 7: Continuous Improvement

Review and update the security standards periodically as threats, technologies, and team feedback evolve. Hold lessons-learned sessions after incidents or major security initiatives to surface what could improve, and stay willing to adapt the overall approach as the organization's experience with it grows.

Brutalist Security Council

A Brutalist Security Council serves as the central governing body and driving force behind the Security Brutalism approach within the Team of Teams environment.

Structure and Membership

The council should include security leadership (a CISO or senior security leader who chairs it), representatives from the security architecture team who define the overall framework and standards, lead security champions from each major product line or business unit, engineering and IT leadership representatives who can flag friction points and keep the approach aligned with development practices, and a risk or compliance representative to make sure the approach satisfies regulatory and internal policy requirements. Five to eight members keeps the group large enough for diverse representation and small enough for effective decision-making, and terms should rotate to bring in fresh perspectives while preserving continuity.

Responsibilities and Functions

The council champions the Security Brutalism vision across the organization, making sure people understand the rationale and the benefit, not just the rules. It holds ultimate authority for defining and refining the core security standards based on evolving threats, lessons learned, and input from the security guilds, and it works to keep those standards applied consistently across all autonomous teams, addressing deviations as they appear. It acts as a hub for sharing best practices and facilitating cross-team collaboration on security matters, and it evaluates and approves the foundational security tools and technologies that teams will use. When security issues span multiple teams or need organization-wide attention, the council takes them on directly, and it serves as the escalation point when conflicts or roadblocks threaten the implementation.

Driving continuous improvement is also part of the council's role: reviewing security metrics and KPIs, analyzing incident reports and post-mortems, gathering feedback from teams on what's actually working, sponsoring pilots for new approaches, and overseeing updated guidelines and training as they're needed. The council reports regularly to executive leadership on the state of security, progress made, and risks that remain.

Operational Mechanisms

The council should meet monthly or bi-monthly with a structured agenda and detailed minutes, and maintain clear feedback loops with security and technology teams so input actually reaches decision-making. Decisions should follow a defined process, whether consensus-based or majority vote, so the group can move efficiently rather than stalling on every issue. And the council's activities, decisions, and updated standards should be communicated clearly across the organization, since a governing body that operates invisibly undermines the buy-in the whole model depends on.

Security Brutalist Sync

Adapting McChrystal's daily sync concept for Security Brutalism calls for a focused, efficient version, shorter and more targeted than the original 90-minute daily updates.

Participants and Format

The sync brings together representatives from the central security architecture team, lead security champions from each major product line or team cluster, representatives from key operational teams like Incident Response, SOC, and Threat Intelligence, and rotating members depending on the incidents or topics at hand. It runs as a brief virtual meeting with a strict time limit of fifteen to thirty minutes, kept concise and action-oriented in the spirit of McChrystal's original model.

What Gets Shared

Each sync covers a consistent set of topics: brief overviews of ongoing or recently resolved security incidents along with their impact and key learnings, updates on newly identified threats and critical vulnerabilities relevant to the organization's technology stack along with recommended immediate actions, announcements of changes to security standards or policies, cross-team dependencies or blocking issues affecting multiple teams, high-level summaries of security metrics like vulnerability remediation progress and incident volume trends, successful implementations or lessons learned from different teams, and upcoming security initiatives, training sessions, or audits.

How Often to Meet

A daily sync, similar to McChrystal's original cadence, shares the most current information and helps surface emerging threats quickly, but it takes real time and can produce meeting fatigue when there's little to report. It suits high-threat environments or organizations going through significant infrastructure or security change. Meeting every other day, on a Monday-Wednesday-Friday schedule, balances timely updates against time commitment and fits a moderate threat landscape with a steady pace of change, though it introduces a slight delay in critical information reaching the group. Meeting twice a week, on Monday and Thursday, costs the least time and still provides regular touchpoints, but it makes information less timely and can slow the response to fast-moving threats, so it works best in lower-threat or more stable environments. Starting with the Monday-Wednesday-Friday cadence and adjusting based on the volume and criticality of what comes up is a reasonable default.

What Makes It Work

The sync stays useful only if the group holds to the time limit and keeps the agenda tightly focused on critical updates, treats the discussion as action-oriented rather than just informational, and gives each representative a clear channel to cascade information back to their own team. Reviewing the sync's effectiveness periodically, and adjusting its format or frequency when it stops earning its place on the calendar, keeps it from becoming just another meeting.

Key Considerations for Overall Success

Strong executive support is essential, since without it the rest of the structure has little weight behind it. Communication needs to stay transparent and consistent so every team understands the goals and what's expected of them. Even though the underlying principles are uncompromising, teams need real autonomy and trust to own security within their own boundaries, and automation is the main lever for integrating security into team workflows without creating constant friction. Education and collaboration should carry more weight than strict enforcement if the goal is a genuine security culture rather than a compliance exercise. And because no two organizations look the same, the specific activities and timelines here need to be adapted to your own context, with room to iterate as you go.

Conclusion

The integrated Security Brutalism and Team of Teams approach works best for large, scaling, complex organizations that need agility while facing real security challenges. These organizations recognize the value of a resilient, transparent security foundation that doesn't come at the cost of speed, innovation, or team autonomy.

Getting there takes careful planning, clear communication, and real collaboration to manage the consistency, coordination, and silo risks that come with a decentralized model. Done well, the result is a security posture that scales with the organization while keeping the agility today's threat landscape demands.