Beyond the Security Team of One: Scaling Cybersecurity from Startup to Scale-up

🧬 Evolution Through Value Streams - Traditional security team scaling fails when following headcount instead of value streams - Security organisations thrive when evolving based on business impact rather than company size.

🎯 Reality of Security Team Ratios - With security-to-developer ratios of 1:50 to 1:120, traditional scaling isn't sustainable - Success requires shifting from "doing security" to "enabling security at scale" - Platform teams and enabling patterns can help security teams achieve 3-5x impact

Thanks for reading! Subscribe for free to receive new posts and support my work.

Team Topologies provides a framework to balance security needs with business growth.

Introduction

A few years back, as result of a reorganisation in a company I worked for, I came across with a book that proposed different ways to organise teams and collaboration for engineering organisations, based on the needs of the business to enable fast flow of value. The book is called "Team topologies", introduced by Matthew Skelton and Manuel Pais. I had seen this methodology used in many companies to reshape their whole organisation for better productivity and efficiency.

"Team Topologies is the leading approach to organizing business and technology teams for fast flow of value, providing a practical, step-by‑step, adaptive model for organizational design and team interaction."

Based on Conway's Law, which says that software architectures inevitably reflect the organisational communication patterns of the companies that create them. The way teams communicate and collaborate directly shapes the systems they build. Team Topologies builds on this principle by deliberately designing team interactions to produce desired architectural outcomes.

In the dynamic world of startups and scale-ups, where agility and adaptability are crucial for survival and growth, security organisations must evolve alongside the companies they protect. The Team Topologies model offers a promising solution to address these challenging ratios, providing a team-oriented framework that helps security groups deliver value efficiently despite limited resources.

The challenge of organising security teams becomes particularly important in large engineering organisations, where hundreds of developers may be supported by only a handful of security engineers. Industry surveys and my experience indicate that the ratio of security developers to engineers typically ranges from 1:50 to 1:120 (depending industry), creating significant odds against security teams' effectiveness.

The Four Fundamental Team Types in team topologies:

When it comes to teams, Team topologies advocate for the following four types:

Stream-Aligned Teams: Focused on a single, valuable stream of work, such as a product or service. They are cross-functional and empowered to build and deliver end-to-end functionality.

In cybersecurity, these teams focus on specific security domains or products:

• Examples include Application security teams, Infrastructure security teams, or Security Operations teams.

They operate with high autonomy and are responsible for end-to-end security in their domain

Platform Teams: These teams build and maintain a set of security tools and services that other teams can leverage. This might include identity and access management solutions, logging and monitoring infrastructure, and vulnerability scanning tools.

• Create self-service capabilities for other teams
• Example: Security tooling team that maintains SIEM, vulnerability scanners, and security automation platforms

Enabling Teams: Provide expertise and support to Stream-aligned teams, helping them overcome obstacles and build up their capabilities. Security experts who help bridge knowledge gaps, and provide guidance:

• Reduce dependencies on security experts by teaching rather than doing the work. Think of Security Champions concept for example.Example: Security architecture team that assists other teams in implementing secure designs

Complicated Subsystem Teams: Specialised teams that deal with technically complex domains that require deep expertise.

• Focus on specific security domains that need deep technical knowledgeExample: Cryptography team or security research team

In my experience the most common team patterns in cybersecurity are the Stream aligned teams and Enabling teams, at least when talking about Startups and Scale ups.

Team Interaction Patterns

The book introduces another important concept, which is the way these team interact with other teams in the organisation. We have the following options:

1. Collaboration: Deliberate working together between teams with a defined mission and timeline, requiring high bandwidth communication.

• Security platform teams working closely with stream-aligned teams
• Regular knowledge sharing sessions between enabling teams and other security teams
• Cross-team security incident response exercises

2. X-as-a-Service: One team provides something for other teams to consume asynchronously with minimal collaboration, typically through self-service platforms or APIs.

• Security platform team providing self-service security tools
• Automated security scanning in the SDLC (Static Analysis, Dependency scanning, Secret scanning, etc.)
• Security policy as code frameworks

3. Facilitating: One team helps another team learn or develop a new capability through teaching and mentoring, with the goal of making the receiving team self-sufficient.

• Enabling teams conducting security training
• Security architecture reviews and consultations
• Threat modeling processes and workshops

Team Topologies for Security teams in Startups

As cybersecurity needs expand across organisations - whether they're innovative startups disrupting markets or scale-ups experiencing rapid growth - security teams face a transformation challenge. The evolution from a single security generalist or small team handling all security concerns to a multi-tiered security organisation requires careful planning. This transition point typically emerges when the traditional "security does everything" approach starts showing signs of strain, often manifesting in delayed responses to security incidents, mounting security technical debt, and overwhelmed security professionals trying to juggle too many responsibilities. The introduction of specialised security platforms and dedicated platform teams becomes not just beneficial but essential for sustainable scaling. However, this transformation requires thoughtful decisions and clear organisational principles to ensure that security operations maintain their effectiveness while becoming more scalable.

So what are the options we have when we look at the different phases of growth of a startup? Let's see some examples:

Early-Stage Startup (1-100 employees)

At this stage, security is often handled by a small (one person usually, depending the core business), versatile team that combines multiple roles:

• One stream-aligned team handling both application and infrastructure security
• Security lead acting as an enabling team to support developers
• Leverage managed security services to fill gaps

Growth Stage (100-300 employees)

As the organisation grows, the security structure evolves:

• Dedicated small stream-aligned teams for application security and infrastructure security, usually same small team covering both domains.
• Small platform team creating security tooling and automation
• Part-time enabling team providing security guidance across the organisation

Scale-up Stage (300-3000 employees)

The security organisation becomes more sophisticated:

• Multiple stream-aligned teams focused on different security domains
• Dedicated platform team for security infrastructure
• Full-time enabling team for security architecture and consultation

At this stage we have a full security organisation

Common Pitfalls in Security Team Evolution

Based on my experience helping organisations transform their security teams, here are critical pitfalls to avoid and strategic approaches to consider:

Early-Stage Pitfalls (1-100 employees)

1. The "Security as Afterthought" Trap

What Usually Happens:

• Security person hired too late
• No security considerations in early architecture decisions
• Accumulation of security debt (Link to my other article)

Strategic Approach:

• Engage security expertise even as a part-time consultant early
• Build security into architectural decisions from day one
• Create lightweight but scalable security processes

2. The "One-Person Army" Syndrome

What Usually Happens:

• Single security person trying to do everything
• No documentation or knowledge transfer
• Burnout and potential single point of failure

Strategic Approach:

• Focus on high-impact, automated solutions
• Build security champions program early
• Create documented processes and playbooks

Growth Stage Pitfalls (100-300 employees)

1. The "Tool Proliferation" Problem

What Usually Happens:

• Too many security tools purchased without integration strategy
• Teams overwhelmed with alerts and notifications
• Limited return on security investments

Strategic Solution:

• Develop a tool integration strategy
• Focus on platform team development
• Implement automated correlation and prioritisation

2. The "Scaling Wall" Challenge

What Usually Happens:

• Security becomes a bottleneck
• Increasing friction with development teams
• Rising number of security incidents

Strategic Solution:

• Implement security-as-code practices
• Develop self-service security capabilities
• Create clear escalation paths and SLAs

Scale-up Stage Pitfalls (300-3000 employees)

1. The "Communication Breakdown"

What Usually Happens:

• Siloed security teams, little communication and alignment across different security teams.
• Inconsistent security practices across teams
• Duplicate efforts and inefficiencies

Strategic Solution:

• Implement clear interaction patterns
• Regular cross-team security forums

2. The "Legacy Drag" Effect

What Usually Happens:

• Old security practices don't scale
• Technical debt in security infrastructure
• Resistance to change from established teams

Strategic Solution:

• Regular security architecture reviews
• Planned technical debt reduction
• Change management strategy for security evolution

Do these sounds familiar to you?

Recommendations when implementing Team Topologies

If you are looking to implement team topologies or improve your security organisation, I recommend focusing on:

1. Quick Wins First

   • Identify immediate pain points

   • Implement high-impact, low-effort solutions

   • Build credibility for larger changes (Iterative approach)

2. Sustainable Growth

   • Design for scale from the start

   • Build automated and self-service capabilities

   • Focus on knowledge transfer and documentation

3. Cultural Transformation

   • Create feedback mechanisms

   • Celebrate security wins and learnings

These are simple but powerful tips when considered in any process to improve the security team organisation.

Final thoughts

Remember that team structures should remain flexible and adapt to changing security needs and organisational growth. Regular review and adjustment of team topologies ensure continued effectiveness of your security organisation, remember that what brought you here wont take you to the next level your business will need.

Team Topologies provides a flexible and scalable framework for organising cybersecurity teams in startups and scale-ups. By understanding and implementing these patterns appropriately, organisations can build security teams that effectively protect their assets while supporting rapid growth and innovation.

The key to success lies in starting with a minimal viable structure and evolving it gradually based on organisational needs. Regular assessment and adjustment of team structures ensure that security capabilities grow in alignment with business requirements.

Stay tuned for the follow up on how teams could evolve when adding AI agents into the mix.

If you want to discuss this topic or have ideas on how to organise better security teams, please contact me via Linkedin or drop some comments in this article.

Thanks for reading! Subscribe for free to receive new posts and support my work.