Should security own risk?
Maybe. We should stop arguing about risk ownership and start owning risk surfaces.
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:
The other day, I was catching up with Mayank Dhiman, who runs security at Sierra, and we started talking about risk ownership. It’s a topic we’ve both had to wrestle with, especially at startups where security maturity is evolving fast, and the “who owns what” conversations aren’t always productive. We are both software engineers who are eager to actually make progress on risk mitigation rather than just talking about ownership or passing risk around.
Then I opened up LinkedIn and saw a few posts making bold proclamations about how security should work. You know those short, snappy, and prescriptive, usually with some hot take about what security teams should or shouldn’t do. One in particular argued that security shouldn’t own risk. Another insisted that security needs to do more work to focus on the risks that need to be fixed, which requires some ownership.
I get that these are meant to spark conversation. But I think these posts often miss the nuance. There’s no single right way to run a security organization, just as there’s no single way to run product, engineering, or ops. Many things need to be taken into account, e.g., context, company stage matters, team structure, and even business model. I’ve been honest about my feelings that there should be more security engineering if we want more efficient and effective security organizations, but I’ve also been honest that operational security organizations have their place.
So rather than debate who owns risk in the abstract, I want to offer a more useful framing: security should own risk surfaces.
Security has always had a strained relationship with ownership. Ask most security leaders, and they’ll tell you the same thing: “We don’t own risk. The business owns risk. We surface it.”
There’s a good reason for that stance. At larger companies, trying to “own” all risk isn’t just unrealistic. It’s operationally impossible. If you try to assign every single risk to the security team, you create the same problem as if no one owns anything: total diffusion of responsibility. The team will get overwhelmed. The work will stall. Everyone loses.
But the opposite extreme isn’t much better. If security teams only surface risks without taking any accountability for solving them, they become little more than ticket generators with hundreds of JIRA tickets and no progress. This makes engineering teams understandably frustrated because it just feels like more toil. It also makes security into operational works that are program managing.
This dynamic leads to the familiar pattern: security surfaces a bunch of risks, tries to influence engineering to prioritize them, and gets ignored because there’s no delivery capacity. So now security is stuck tracking risk in spreadsheets, reporting it to the board, and watching the same issues linger for months.
It’s performative risk management with high activity and low progress.
Why “Owning Risk Surfaces” Is a Better Frame
Here’s the middle ground: instead of owning all risks or owning none, security should own specific risk surfaces.
What does that mean?
A risk surface is a bounded area of technical responsibility where security can deliver real, measurable value. It could be a product area, a platform component, a specific set of permissions (e.g., IAM), or a category like customer data access or third-party integrations.
The key idea is that a security engineer (or small team) owns the mitigation strategy for that surface and can deliver engineering outcomes that reduce risk directly. They aren’t just raising flags, but building guardrails with context.
This has a few big advantages:
It gives the security team focus, so they’re not trying to boil the ocean.
It creates real accountability. They can commit to reducing risk in specific areas.
It integrates better with engineering because security is taking ownership of delivery, not just recommendations. It also has to work with the engineering owner of that space.
And most importantly, it moves the org beyond checkbox security. Here are some examples of what that looks like.
Let’s say your company has recurring issues around IAM misconfigurations, e.g., overly broad permissions, lack of MFA, and unclear ownership. Rather than file a bunch of JIRA tickets for the infra team, you assign a security engineer to own the IAM risk surface. That person builds tooling to detect permission creep, works with the platform team to roll out least-privilege defaults, and maintains that surface going forward.
Or maybe your app ingests sensitive customer data and allows user-generated code execution. Rather than just report the risk, you assign a security engineer to the runtime security surface. They build sandboxing and isolation, monitor execution flows, and plug into the product team’s roadmap.
This model also applies to build systems, vendor integration, corporate access, and more. If there’s a consistent, high-leverage problem area, it probably deserves to be a risk surface.
So, how do you choose or define a risk surface?
This is the hardest part. You can’t own everything. So you need to choose surfaces that meet three criteria:
High business impact: Risks in this area could materially affect customers, availability, or compliance.
Reasonable scope: It’s narrow enough that a person or team can take ownership without being stretched thin.
Opportunity for leverage: There’s an actual path to mitigation, ideally through automation, architecture, or refactoring.
This is where business context becomes critical. You need to understand what the company cares about, how the product works, and what the engineering teams are actually capable of supporting. This requires real collaboration.
You also need security engineers who can operate like product engineers: defining problem spaces, proposing solutions, building tooling, and owning delivery. That’s not the typical security skillset, which is why this model requires intentional hiring.
One thing I’ve written about before is that most security organizations are too focused on surfacing issues and not enough on fixing them:
Owning risk surfaces changes the accountability model. You’re not measured by how many risks you detect or how many Jira tickets you assign. You’re measured by how much risk you reduce.
It’s a more outcome-oriented way to do security, but it requires the team to act more like engineers and less like compliance analysts. That means building, maintaining, and shipping, not just consulting.
This isn’t a fit for every org. It works best at companies with lean teams, strong technical culture, and leadership alignment around risk reduction as a priority.
But if those conditions exist, it can unlock a more scalable and proactive security model. Why does this matter, though?
One reason this framing works is that it balances responsibility with capability.
Security shouldn’t be the team that gets blamed when a breach happens, especially if they weren’t empowered to prevent it. But they also shouldn’t be the team that just passes work to others and washes their hands of it.
Owning risk surfaces gives security teams a clearer role: this is our area, and we’re responsible for driving it down. You’ll still need collaboration with engineering, product, and leadership. But you’re no longer in the ambiguous middle where influence is your only tool.
This also changes the way you think about metrics and success. Instead of reporting the number of risk acceptances or the number of tickets filed, you can track something much more meaningful: how much residual risk did we reduce in our area of ownership?
That’s a better conversation to have with your CTO, your board, and your team.
This shift in framing aligns with a broader trend I’ve been writing about: security needs to become more technical, more integrated with engineering, and more accountable for delivery.
We’ve spent too long playing the game of security theater — surfacing risks we can’t fix, deferring to engineering to prioritize, and accepting that nothing will really change.
We can own in a targeted way and focus on producing results, which makes it easier to deliver value to the company. I’m always happy to talk more about this, so definitely reach out if you want help thinking about risk surfaces. It’s an idea I’m hoping to evolve, so any feedback would be appreciated.
And for those of you still debating whether security owns risk: maybe we’ve been asking the wrong question all along.