Organizations today are taking great strides when it comes to innovation but unfortunately, security and governance continue to lag behind. Although the DevOps teams ratio is around 10:1, the average DevSecOp ratio is only 100:1. A recent study shows that organizations who prioritize DevSecOps are 3x as likely as their peers to use security as a way to speed up application delivery.

We need to understand what’s causing this gap and what actions we can take to bridge it.

It’s important to reinforce that day-to-day security measures like checking for third-party vulnerabilities and responding to incidents aren’t the cause for concern. Instead, where voids tend to appear is with things such as hacker mindsets (proactively searching for new possible attack vectors) and in performing tasks like in-depth risk analyses and threat models, all of which play key roles in enabling enterprises to create robust, holistic security architectures.

Two Models for Addressing the Problem

1. Fully Shared Responsibilities

This framework calls for each development team to integrate at least one T-shaped individual (someone capable of many things and an expert in one) who specializes in security. This person needs to be able to translate security threats into actionable items that their team can implement and communicate concerns in ways business owners and leaders will understand.

Keep in mind that the security-focused person shouldn’t be allocated all of the security work otherwise, the silo will simply be transformed from a macro one (where there’s a distinct security team) to a micro one (where there is an isolated team member). Over time, the job of doing security analyses should be spread throughout the team so that the T-shaped person can stay on top of best practices, find new tools and methods, facilitate workshops, and ultimately lead security strategy.

  • Reduce incidents more quickly and prevent them down the road by increasing the ownership security has in the development of new products, services, and solutions.
  • Increase the Dev-to-Ops-to-Sec ratio. Not only will this embed security within your development processes, but it will also allow more people to bring their diverse experiences to the decision-making table.
  • Signal to your employees and end-users alike that security is a top priority for your organization.
  • The cost associated with finding and recruiting the right people can be high, and the transition itself can take time.
  • High-performing, autonomous teams tend to thrive on stability and will be extra sensitive to personnel changes.
  • Teams may feel the lack of centralized contact for security, which is why channels of communication always need to be open between team members and security-focused persons within the enterprise.

A fully shared responsibilities model is often ideal for companies with cross-functional, autonomous teams that each work on products or services with very different risk profiles.

2. Security as an Enabling Team

In this model, a central security team supports multiple product development teams, getting involved from day one of a project to make sure they can provide security-specific feedback at each stage of the process. An important caveat here is that the security team shouldn’t actually perform analyses or implementations. They should simply promote best practices and provide guidance on which other teams can act.

Switching to the security-as-an-enabling team model can sometimes be an easier transition for enterprises because it doesn’t require the same degree of structural change that a fully shared responsibilities model does. Ultimately, the biggest challenge with this approach tends to be making the shift without confusion or regression.

  • The timeframe to enablement is shorter.
  • Enterprises don’t need to hire too many new team members, avoiding hassles associated with recruitment and team disruption.
  • Effective communication is critical to the success of this approach.
  • For product development teams already working at maximum capacity, introducing new responsibilities can be challenging.

This approach works well for companies that have a smaller number of teams to begin with, especially if those teams (or members of them) have a pre-existing interest in security. 


Remember that team design shouldn’t be static. The best fit for you today might get in the way of better, faster developments tomorrow, which is why you need to be prepared to adapt as your organization grows. A fully managed platform maximizes the internal team’s ability to focus only on the core business, and in most cases also results in a more secure DevOps toolchain, because responsibility for security is with the platform provider, not an internal IT team trying to do hundreds of other things. 

Why do Enterprises Trust Our Managed DevOps SaaS Platform?

Platform-Benefits-Graphics-SaaSManaged SaaS Model

Run our Managed SaaS single-tenant environment in any AWS region of your choice. Managed 24/7 with bespoke security and access controls.

Cloud-ArchitectureCloud-Native Toolchain

We take the complexity, resource strain and risk away while delivering a fully managed, integrated and secure DevOps toolchain in the cloud.

SOC-2-Security-BadgeBuilt for the Enterprise

Constantly evolving from a feature set and security posture, our SOC 2 Type 2 and AWS MSP Certifications, are key credentials of a trusted partner.


See for yourself how our Managed DevOps SaaS Platform will help transform your business. 

Engage an Expert