One of the trickiest challenges we see, especially in regulated environments, is pinning down who actually owns what when it comes to cloud security.  

It’s rarely as clear-cut as “security owns security.” There’s often platform teams managing infrastructure, security teams writing policies, and engineering teams deploying code, with overlapping responsibilities. And when something slips through, everyone points fingers or scrambles to fix it last minute. 

What’s missing in a lot of organisations is a shared model for who’s responsible, accountable, consulted, and informed across the lifecycle of a change. 

Build a working-level RACI, not a theoretical one

We’ve seen RACI (Responsibility Assignment Matrix) models used to death in PowerPoint decks but they often fail because they’re designed from the top down. They map out ideal responsibility, not actual working relationships. 

Instead, start by mapping out one real-world scenario. For example: 

A new service is being deployed that handles customer data. Who’s:

• Deciding how IAM roles are set up?
• Writing the Terraform?
• Approving the VPC layout?
• Reviewing the security implications?
• Monitoring for misconfigurations? 

Write those actions down and talk it through with the teams involved. You’ll probably uncover areas where: 

• Multiple people think they own the same thing 
• Nobody owns it 
• Or worse, ownership depends on who’s free at the time 

Once you’ve walked through a few scenarios, you can begin to group them into patterns and turn it into a working framework. 

A simple RACI can be really helpful here, not to replace collaboration, but to make it explicit who leads. 

Here’s a basic example (adapt it to suit your org) and key definitions for anyone unfamiliar with RACI: 

Keys:

R – Responsible (Those actually completing the task)

A – Accountable (Responsible for the outcome and standard of completion)

C – Consulted (Provides input / expertise on the subject at hand)

I – Informed  (Not directly involved but is kept up-to-date)

The key here isn’t perfection, it’s clarity. Everyone knows who to go to, and who’s on the hook. 

You need shared understanding, not just tooling 

We’ve seen teams roll out platform tools with policy-as-code baked in, thinking it’ll solve the responsibility problem. But unless you’re clear on who owns those policies, and who’s supposed to update or override them, you’re still relying on implicit trust and good intentions. 

It’s not about adding more process. It’s about giving teams just enough structure to avoid misaligned expectations. 

Hope this gives you something useful to try with your teams. If you’re struggling with the ownership question internally, you’re not alone, but it’s absolutely solvable with the right conversations. 

Need some support? Get in touch for a call to discuss if we can help.