Before you read on, I want to be clear: I appreciate security engineers and value building secure applications. But I also believe we should start addressing security in larger organizations differently.

Imagine a large organization, not necessarily an IT organization, but one that does have at least a few in-house developed software products. Thousands of users and an IT department of only a few dozen people managing mostly off-the-shelf applications. Alongside this, a few software development teams work on the in-house developed applications. Now imagine you’re an architect working with those development teams.

What I see happening again and again

As an architect working with those teams, it’s my job to surface the trade-offs involved in building a new application. Performance vs. complexity, cost versus security, and so on. I bring in SMEs to help articulate the pros/cons of a design and the consequences of alternatives under consideration. In other words, I help formulate trade-offs for decision making.

Once these trade-offs are clear, I bring them to the responsible product owner, asset owner, or manager. I ensure they understand the implications and consequences and then let them decide how to proceed. Ultimately, it is their responsibility to decide which risks, including security risks, to accept, reduce, or fully mitigate. Based on those decisions, a design is finalized and implementation starts.

Notably, in most cases this only happens after repeatedly asking security teams for guidelines or policies that often never arrive.

Then, halfway through implementation, security suddenly enters the stage. They want to review the designs and start recommending extra security measures to be implemented. These statements are usually disconnected from the actual context of the application, the phase it is in, and the risk appetite at that time. Even more frustrating, they are often presented as absolutes (“you must never do this” or “you must always do that”) rather than as trade-offs to be decided on by the product owner. Or sometimes it’s just a simple NO as part of a change approval board, no explanation given, no conversation about the trade-off possible.

What causes this?

It’s not that security teams want to block progress. The problem is organizational: security is separated from product development and rewarded for reducing security risk, not for enabling successful delivery. But organizations make a profit by taking calculated risks, not by overinvesting in risk reduction. And for that reason a team responsible only for minimizing security risk can never make the right decision for the whole product.

Or in other words: a team with one side of the trade-off in the name, can never make the right decision on behalf of the whole.

This is not a new idea. We have seen similar things when parts of the organization were optimized either for development or operations and were not collaborating effectively to achieve the larger, overarching goal of producing constant, reliable change.

Analogous to the DevOps movement, I believe security teams should stop positioning themselves as a separate team of gatekeepers.

So, what should we do instead?

Product leadership should define the risk appetite per product and. Security teams should write clear policies, advise architects and product owners, but leave individual trade-offs to the product owner.

Product owners may get it wrong. But if that happens, it is their responsibility, not that of the security team.

Now, I recognize that a safety net is still needed to protect the organization against excessive risk-taking. But this can also be achieved without security teams involving themselves in individual decisions. Instead, they can report to senior management on how teams and products align with the agreed risk appetite, allowing management to intervene when necessary. In that model, security is no longer on the critical path and no longer responsible for every individual decision. Their responsibility becomes delivering high-quality advice at the right time and escalating systemic risk trends, rather than blocking individual implementations.

Conclusion

Separating security into a standalone responsibility creates friction and consistently undermines good risk decisions. Security decisions should be made within the product context by the product owner, advised by the architect, the security team, and other relevant SMEs. Security teams should act as trusted advisors, not gatekeepers or veto holders. As a safety net, they can report how products align with the agreed risk appetite to senior management, enabling intervention when necessary. To change the interaction between security and product teams, management must empower product owners to take decisions around security risk, scoped to their product, and reposition security teams as advisors, not deciders.