---
title: "Rethinking security roles and organizational structure for the cloud"
source: "https://www.tigera.io/blog/rethinking-security-roles-and-organizational-structure-for-the-cloud/"
---

[Technical Blog](https://www.tigera.io/category/technical-blog/)

# Rethinking security roles and organizational structure for the cloud

By [Ratan Tipirneni](https://www.tigera.io/blog/author/ratan/) on Aug 30, 2022 • 4 min read

As more and more applications and application development move to the cloud, traditional security roles and organizational structures are being shaken up. Why is that and what are the benefits of a cloud-first approach for business?

## Traditional vs. cloud model

Application development in the traditional model, especially in larger companies, can be thought of as a linear process—similar to a baton being passed between teammates (e.g. the application team hands off the baton to the security team). In this model, each team has their own area of expertise, such as networking, infrastructure, or security, and the application development process is self-contained within each team.

The downside to this model is that responsibilities are siloed, and interactions and hand-offs between teams create friction. For example, if one team needs something from another, they need to submit a ticket and deal with wait time. In the traditional model, it’s not unusual for the application development and deployment process to last weeks or months, and then there are bug fixes and new release rollouts to contend with.

A cloud model, on the other hand, offers several benefits, including automation, abstraction, and simplicity. The high degree of automation in cloud-native infrastructure in general leads to:

- Better utilization of resources

- Faster time to deployment and rollout

- A need for less people (savings on investment)

Because everything is abstracted and highly automated, you only need a small team to work across everything, including a persona I like to call “Cloud DevOps.”

## Rethinking security roles and organizational structure for the cloud

There is not a 1:1 mapping of personas from the traditional model to the cloud model. So DevOps in the traditional model is very different from DevOps in the cloud model. In the traditional model, functions and roles are siloed (e.g. networking engineers, DevOps engineers, infrastructure engineers). In the cloud model, these functions are not siloed; they are ‘collapsed’ into one role: cloud DevOps engineer.

Benefits of this collapse include:

- **Velocity** – Everything gets compressed (speed of deployment, etc.)

- **Less friction** – In the traditional model, there’s quite a bit of friction that arises due to a lack of alignment of goals, objectives, and incentives between roles and teams. All of that now goes out the door since one person is making decisions.

However, just because an organization moves to the cloud doesn’t mean the traditional personas are collapsing. For example, an organization operating in the cloud might still have a separate security team. I’ve noticed this collapse more in small and mid-sized companies.

In terms of organizational structure, there are a few ways companies have handled moving to the cloud. Some tried taking their existing processes and tools and applying them to the cloud (thinking the cloud was just inexpensive infrastructure that could be outsourced). So instead of implementing automation or other new processes, they outsourced this function, thinking that more workers meant the ability to scale quickly. But that doesn’t work in the cloud.

In order to reap the benefits cloud has to offer, companies need to rethink their team structure and business processes. In contrast to the above-mentioned type of company, there are some companies that have taken a step back and understood that they need to fundamentally redesign and come up with a new approach. Cloud-first companies do a good job of this because they don’t have a legacy mindset, processes, tools, or structure to deal with.

## Smaller companies are getting it right

We’re seeing a class of companies (small and mid-size companies) reaping the benefits of moving to the cloud, whereas larger companies are not necessarily seeing the same benefits. The reason? Larger companies are replicating their traditional structures and processes in the cloud, whereas smaller companies are building processes from the ground up that are optimized for the cloud. These smaller companies are centralizing traditional roles and functions into one new persona—cloud DevOps—that spans security, networking, and troubleshooting. With their cloud-first approach, these companies have the most to gain in the growing world of cloud.

***Learn more about the basics of cloud-native architecture with our learn guide, [Cloud-native architecture: Pros, cons, and basic principles.](https://link.tigera.io/ueUTr)***

 

This article originally appeared on [Forbes](https://www.forbes.com/sites/forbestechcouncil/2022/04/07/rethinking-security-roles-and-organizational-structure-for-application-development-in-the-cloud/?sh=217f354e6f2a).

[Best Practices](https://www.tigera.io/tags/best-practices/)

## Related posts

[![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

#### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Aug 27, 2026

Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a...

[Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

[![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

#### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Aug 24, 2026

The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms...

[Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

[![VM Migration – What Happens to Your NSX Segments in Kubernetes?](https://www.tigera.io/app/uploads/2026/08/VM-Migration-What-Happens-to-Your-NSX-Segments-in-Kubernetes.png)](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/)

#### [VM Migration – What Happens to Your NSX Segments in Kubernetes?](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/)

By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/)
on Aug 5, 2026

Planning a migration off NSX usually starts with a networking conversation. Segments, VLANs, routing topology and BGP peering are not things that map cleanly to Kubernetes-native constructs the way the NSX distributed firewall maps to...

[Read more](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/)

<!-- plugin=object-cache-pro client=phpredis metric#hits=3192 metric#misses=33 metric#hit-ratio=99.0 metric#bytes=1512795 metric#prefetches=0 metric#store-reads=165 metric#store-writes=12 metric#store-hits=157 metric#store-misses=22 metric#sql-queries=30 metric#ms-total=503.21 metric#ms-cache=25.89 metric#ms-cache-avg=0.1471 metric#ms-cache-ratio=5.1 -->
