Security Guardians: How to Scale Security
The underlying problem
In almost every organization, the security team is—and will continue to be—small relative to the rest of the organization. Meanwhile, the company grows: more product teams, more services, more AI agents, and more system integrations—often accelerated by acquisitions. If the prevailing mindset is that security is “handled by the security team,” that team will sooner or later become a bottleneck, and security will begin to be perceived as what slows down delivery rather than what protects it.
The instinctive response—adding more people to the core team—does not solve the root of the problem, because the gap between what the organization produces and what a core team can review widens with each new team. What does scale, however, is changing who is responsible for security.
At BigCheese, we use the strategy described below, which is closely aligned with AWS’s ” culture of security ” and, specifically, with the AWS Security Guardians program.
Culture of security vs. security culture
It is worth distinguishing between two concepts that are often confused. The security culture refers to the culture of the security team: its practices, its tools, and its way of working. The “culture of security,” on the other hand, is a characteristic of the entire organization: the extent to which every team—whether product, data, or operations—takes security on as part of its job rather than delegating it.
The goal is not for everyone to become security experts, but rather for security to cease to be the exclusive responsibility of a single department. The security team shifts from being the one who does the work to being the one who defines the framework, provides tools, and enables others; and each team takes ownership of the security of what it builds and operates. It’s the same principle of shared responsibility that we already apply between the cloud provider and us, brought into the organization.
What Is a Security Guardian?
A Security Guardian is a member of a product or operations team who voluntarily takes on the role of security liaison within their team. They do not stop doing their job or become an auditor: they act as an extension of the security team within their own team—the point of contact that brings security context to day-to-day decisions and, conversely, provides the central team with feedback on what happens in practice. This concept is even defined by AWS in its official documentation.
Its value is twofold. For the team, it brings safety awareness down to the level where technical decisions are made, so that best practices are discussed while they can still be implemented at no cost. For the security team, each Guardian acts as an early warning sensor: it detects friction, needs, and risks long before they reach a formal review, allowing the central team to expand its reach without increasing its size.
How to Put Together the Program
A Guardians program isn’t imposed—it’s built. It’s best to start with a diverse group of volunteers representing different teams and backgrounds, rather than handpicking individuals, because the role thrives on genuine motivation. That initial group needs a clear organizational goal—something that gives it meaning beyond simply “handling security”—and real support from the core team in the form of training and mentoring so they can get started with confidence.
From there, it is the community that sustains the program over time. Guardians need a space where they can continuously share knowledge, resolve questions, and compare experiences across teams, so that what one person learns becomes a shared resource for everyone. And they need their work to be measured and recognized: both through qualitative indicators—such as the quality of the security conversations they facilitate—and quantitative metrics, as well as through visible recognition that values the time they dedicate. An open and ongoing two-way feedback channel is what keeps the model alive and prevents it from degenerating into an empty title.
AWS actually suggests how to incorporate guardians into operational teams in its Well-Architected documentation.
How the platform supports it
Culture is the hard part, but without the right tools, Guardians can’t fulfill their role. The key is to give them visibility into their own team’s security without forcing them to become specialists. Consolidating security findings and compliance controls in a single, shared location—for example, using Security Hub and Security Lake—and then presenting each Guardian with the security posture of their team or accounts on a dashboard tailored to their scope turns a flood of alerts into something actionable: each person sees what’s relevant to them, within the context of their team.
On that basis, the core team can define the controls and guardrails once and let each team apply them, so that the Guardian works within a common framework rather than coming up with its own criteria. Automation helps make the role sustainable: routing findings to the right team, automatically opening tickets, and reminding team members of pending tasks prevents the role from depending on people’s willingness to review dashboards. This way, the Guardian can devote their time to what truly requires judgment, rather than to repetitive tasks that the platform can handle on its own.
The Role of the Core Team
In this model, the security team doesn’t shrink or lose relevance—it changes its role. It shifts from reviewing every change to defining the framework, building the tools that the Guardians use, training the community, and arbitrating difficult decisions. In other words, its success is no longer measured by how many reviews it conducts but rather by how much security it ensures without direct intervention.
That is the true sign of maturity in a culture of security: when most good security decisions are made by the teams on a day-to-day basis, and the central team can focus on the risks that truly require its attention.
