Security is not the department of “No”; it’s the department that gets told “No”
Explaining why security is not, in fact, a department of “No” (never has been, and never will be), what it is instead, and what the future is likely to hold
Nearly once a week, I hear someone say that security needs to stop being a department of “No” and that instead, it needs to become a “business enabler”. Every time someone says it, I can’t help but wonder where this idea originated and how it was able to become so widespread. In this piece, I explain why security is not, in fact, a department of “No” (never has been, and never will be), what it is instead, and what the future is likely to hold.
This issue is brought to you by… Tines.
AI lessons every CISO needs to act on in 2025
What do CISOs really think about AI in security?
Tines surveyed 50+ CISOs to get the scoop. Check out the full report, CISO perspectives: Separating the reality of AI from the hype, to learn what’s top of mind for security leaders as they align AI with their cybersecurity strategies.
The report sheds light on the impacts of AI adoption, from increased pressure on already stretched teams to critical concerns around data privacy.
Read the full report for practical insights on making AI work within modern security environments.
Business is an act of taking risk
Before we talk about security, I think it’s critical to define the context in which security operates. To do that, we have to discuss some business fundamentals. I know that governments, non-profits, and other types of organizations also need security, but since the private sector to a large degree is what defines our industry, let’s focus on that for the sake of this piece.
It shouldn’t be a surprise to anyone that business is, at its core, an act of risk-taking. Founders bet their life savings on unproven ideas, investors gamble money they have an obligation to return on uncertain markets, and entire industries are working to bring to life something that might never work. From day one, companies face existential threats: the idea might not resonate; the product might not be possible to develop; the product might not fit the market; the market might not materialize; a competitor might out-execute them; tax or trade regulations might change overnight making the business no longer viable, etc. The list of things that can go wrong is so long and so context-dependent that it would be a futile exercise to even try to put it together. What matters is that for any company, survival isn’t guaranteed, it’s earned through constant, calculated bets across every dimension of the business. This doesn’t change regardless of the stage of the company: a multi-billion player can still fail for a myriad of reasons, and examples of Kodak, Xerox, BlackBerry, Motorola, Yahoo, Enron, Compaq, and many others illustrate that incredibly well.
In the endless sea of risks, security risks are just one more threat companies might consider. While they may be serious, they rarely rise to the level of “stop everything” unless everything is on fire. When we analyze the past 100 years of history, it becomes clear that in terms of impact on the company, cybersecurity risks have financial consequences but they are rarely existential. Companies get killed because of being too late or too early to market, growing too slowly or too quickly, lack of product-market fit, internal politics, and a myriad of other reasons, none of which include security. If anything, security breaches are usually a lagging indicator that shows cultural challenges, poor decision-making, and a lack of operational discipline. Adrian Sanabria has been keeping track of companies that went under following a security incident and so far there are fewer than 30 organizations - substantially less than many would assume.
Since business is an act of risk-taking, it’s not surprising that security risk is not seen as one of the top concerns by most companies. Most organizations won’t halt a product launch, delay a new feature that has the potential to change the company trajectory, or give up momentum simply because of a potential security risk. If the business survived product risk, market risk, competitive risk, execution risk, and regulatory risk, to name a few, it’s not going to die on the hill of security friction - especially if that friction slows the path to growth.
In most companies, security is not a department of “No”
This brings us to the main topic of the article - that security is not a department of “No”. To understand why this perception persists, we have to look at when security gets to say “No", and more importantly, when it doesn't. It’s the contrast between these two that reveals the deeper truth about the position of security inside the company.
Security often steps in around the edges - denying SSH access to production, blocking questionable browser extensions, enforcing MFA, or flagging minor policy violations. These are without any doubt impactful decisions since they enable the company to avoid some of the most common and obvious attack vectors. However, while these decisions may create a sense of influence and control for the security team, they are not signs of enormous power. Security gets to flex in these areas because the cost to the business is low. These changes are safe spaces - there is no direct impact on revenue, no delay to the launch of new products, no risk that an important deal will go sideways, and no disruption to business momentum. In other words, these changes don’t in a significant way slow down the ability of the company to generate revenue. It’s in these narrow boundaries that the myth of security as a gatekeeper persists.
As soon as the stakes get higher, this picture changes. The moment there is a risk that security can impact the ability of the company to ship a key feature by a certain date, hit a quarterly revenue target, or launch a critical partner integration, security doesn’t get to say “No”. The truly consequential business decisions, the ones that carry strategic weight, are made by product, engineering, go-to-market, and executive teams. In those rooms, security is at best an advisor, but not a key player with the power to say “No”.
When people say security should be “an enabler,” what they usually mean is that security doesn’t have the authority to block decisions. Instead, it’s expected to let the business move forward with what it wants to do and then find a way to make that path as secure as possible, given the circumstances and the budget it has access to.
In a small number of companies, security can be a department of “No” (but it still isn’t)
While in most organizations, security doesn’t have the power to justify the title of a department of “No”, there are types of businesses when it may be different. I am talking about companies where security and compliance are existential risks.
For security to be treated as an existential risk, an organization has to be the top target for attackers. A perfect example of this is top cryptocurrency exchanges such as Coinbase and Binance which are seen as some of the most lucrative targets for attackers, right up there next to top US banks. In organizations like these, security does indeed hold enormous power to shape the roadmap, delay the launch of new features and products, and influence which third parties can integrate their software. However, paradoxically the security leaders in these companies are often the least likely to abuse that power. Their CISOs tend to be technically strong, business-minded execs who approach security as a product and engineering challenge, not a policing function.
The second category includes organizations where the existential risk is compliance. In heavily regulated industries like healthcare and financial services, security’s role is closely tied to what can be shown to regulators and auditors. The definition of success of the security team is about passing audits, maintaining certifications, and avoiding regulatory penalties. In these environments, security leaders do hold significant influence (and the ability to say “No”), but that power is often shared with legal and compliance teams.
One way or another, the vast majority of organizations don't fall into these two categories, hence why I think it’s safe to make a statement that security, in most cases, is not the department of “No”.
Visibility is one area the security team can fully control
Despite being tasked with protecting the organization, security usually operates without any real control over the systems it’s supposed to secure. It doesn’t own IT or infrastructure, doesn’t implement identity and access management, doesn’t run CI/CD pipelines, and doesn’t manage product roadmaps. It can’t shift budgets, set engineering priorities, or influence who gets promoted. In practice, it’s asked to drive outcomes across domains it doesn’t have full control over, giving it a role full of responsibility but with no real power. This lack of ownership creates real tension, because the only tool CISOs have to get something done is policy, and the only argument people are willing to listen to is compliance (if something isn’t a part of compliance requirements, good luck getting it implemented). The end result is a system where security teams are asked to defend environments they don’t control by figuring out what needs to be done and telling others who don’t want to do any extra work to make changes.
When security lacks the authority to prevent risks from being introduced in the first place, its role naturally shifts toward a) providing visibility into risks, and b) educating the business about the implications of risks. This isn’t a failure of the team, but a direct consequence of the fact that by the time security steps in, many of the important decisions have already been made. In those situations, visibility becomes the fallback: if security can’t be there to help course-correct the direction, at least it can understand the potential consequences and make them visible. It’s a way of staying engaged, ensuring the issue is known, even if it's not acted on.
The fact that visibility is now the core function of the security team is a direct consequence of how complex the role has become. Security teams today are navigating fast-moving product roadmaps, decentralized architectures, and growing regulatory pressures, often with limited authority and resources. In that environment, all security teams in most organizations are given the power to do is to get visibility into their risks. It may sometimes be different at technology companies that have stronger reasons to invest in proactive controls, but for the majority of the companies, visibility is where security ends. The challenge is that with limited ability to enforce change, many teams fall into what can only be called the “scan-and-ticket” cycle: they scan systems, find issues, log them as tickets, and hand them off to teams that may or may not follow through.
Let me be clear - stopping on visibility isn’t laziness or negligence; it’s a coping mechanism that allows security to stay involved without slowing down the business. It creates a record of diligence, ensures the team is doing what it can, and keeps security in the loop without becoming a bottleneck. Still, this approach often leads to risk deferral rather than risk reduction: the Jira ticket becomes the deliverable, the handoff becomes the closure, and the real issue (fixing the vulnerability, changing the config, pushing the update, etc.) can quietly stall out. The intent is good, and the effort is real, but the outcomes don’t always reflect the urgency of the risks. It’s enough involvement to avoid blame, but not always enough to change the outcome.
This isn’t a critique of security teams, just a call out how the system works. As I said recently on LinkedIn, “The dirty secret of cybersecurity is that most breaches aren’t technical failures, they’re business decisions. Companies know their identity systems are complex, their third-party access is sprawling, and their cloud configs are a mess, but fixing those problems is inconvenient, expensive, or politically risky. They end up accepting the risk, hoping for the best, and buying more tools to “monitor” the problem instead of solving it. In that sense, many breaches are not just predictable, they’re budgeted for.”
Visibility is valuable, but only when paired with influence, collaboration, and support from leadership. Security should be positioned not just to identify problems but to help drive solutions. Until then, even the best teams will continue operating with one hand tied behind their back, just doing their best to communicate risks but not having any power to prevent them from impacting their organization.
Startups that succeed mirror today’s reality of security
Startups that sell to CISOs and security teams
If you look at the startups that got a lot of traction selling to security teams over the past several years, it becomes clear that the vast majority either enable companies to stay in business and sell their products (compliance automation), detect and respond to existential threats (ransomware and attacks that make headlines), or provide visibility into just about anything (think of all the posture management tools that generate long to-do lists most of which will never get done).
The moment a tool introduces any kind of friction, it usually struggles to grow even if it greatly improves security. No company that tries to prevent misconfigurations will get as much traction as a company that merely provides visibility into misconfigurations, even though from the security purist’s perspective prevention should make more sense. The problem is that prevention is a tool for the security team to say “No” - something that many security people would like to do, but are rarely given enough power to actually implement. This reality is also why aspiring founders must be careful when they talk to CISOs to validate their ideas: the solutions security leaders get excited about and the solutions they have the power to implement are often not one and the same.
The silver lining is that as an industry, we are learning that the only way to implement preventive controls is to focus on user experience. A tool that prevents a developer from being able to ship a feature in time for an earnings call will probably not survive, but one that gives them the ability to bypass a security alert if required could stand the chance. I hope that as an industry, we can finally start moving away from visibility towards actionability. For that to happen, we don’t simply need more founders building actionable solutions (founders aren’t the bottleneck); we need security leaders with enough influence internally to not only implement them but to help startups evolve and mature.
AI is the latest exhibit in a long history of technologies that outpace security’s ability to influence adoption. Just like with cloud, mobile, and SaaS before it, AI is being quickly integrated into products, workflows, and business models, often without a clear security plan in place. The pressure to move fast, capture value, and stay competitive means that security is once again left reacting to decisions that have already been made. As with all technologies, AI security is likely to follow the same pathway:
It’ll start with governance and making sure we’re compliant with emerging regulations.
We will then see the rise of posture management.
After it’s understood how attackers will exploit AI, we will see detection and response.
Eventually, someone will attempt to put forward a vision of prevention.
Until there are enough headlines showing how companies lost a lot of money because of the lack of controls around AI, we will probably not see investment in AI security following the sheer amount of discussions about the importance of AI security.
Startups that sell to teams that get the downstream work from security
Another recent phenomenon in the security market is the rise of startups that don’t sell security outcomes to security teams, but rather sell enablement around them. These companies recognize a growing reality: security identifies risks but doesn’t have the resources, expertise, or authority to fix them. The work gets pushed downstream, to developers, platform engineers, DevOps, or IT, and that's where the real friction lies. Instead of targeting CISOs with dashboards and policy engines, these startups aim to make life easier for the people actually asked to do the work.
Chainguard is a clear example of this shift. While CISOs may champion the solution, Chainguard isn’t really selling to them. It is selling to the engineering teams responsible for patching, maintaining, and securing containers, the same teams who are often handed security tickets to do this work. By abstracting away painful tasks like building secure container images, Chainguard turns security work into a solved problem for the people actually on the hook to implement it.
This model works because it aligns the incentives. Developers don’t want to ignore security - they just don’t want it to slow them down or add cognitive overhead. Engineers don’t care about visibility into the security risks, but they are very happy if they suddenly don’t need to do the work that security teams were previously asking them to do. When selling to developers, the products that succeed aren’t the ones that talk about security, but the ones that remove friction from having to deal with it.
Why security reminds me of human resources
In many ways, security reminds me of human resources (HR). The comparison starts with the fact that both security and HR are seen as departments of “No”, but it doesn’t end there. HR is essential, valuable, and full of untapped potential, and when leveraged well, it can be a true game changer for a company’s profitability and long-term outcomes. However, most organizations have yet to realize the potential of HR when done right. Instead, it’s generally treated as a liability shield, a function designed to check boxes, pass audits, and minimize legal exposure of the company. The deeper strategic value often goes unrealized. It takes a determined, business-minded leader to change that reality, someone who sees HR not just as writing nonsense policies nobody will ever read or organizing annual engagement surveys nobody cares about, but as an enabler of growth and trust.
Once you think about this analogy, you can’t unsee it. Like HR, security is often brought in too late, after the damage is done or when a policy needs enforcing, and similar to HR, security can’t directly control people’s behavior - it can only educate, guide, and influence. Despite this, both functions are frequently held accountable for outcomes beyond their control: just as a head of HR might be fired over an employee’s misconduct, a CISO can lose their job after a social engineering incident, even if the right training and safeguards were in place. It’s a flawed but common dynamic: both roles are expected to prevent failures without owning the levers that cause them. You can create a great culture or implement strong security awareness, but one bad actor or one moment of human error can still unravel it all. The consequences often fall hardest on the people tasked with preventing the unpreventable. Both HR and security are at their best when brought to the table early, but too often, they’re treated as reactive functions and cost centers, until something goes wrong.
Few people get excited when a human resources employee approaches their desk because when everything is well, HR is invisible. This is no different for security. If you’ve ever been a part of a high-performing company, you know that when a strong People and Culture leader does their job well, it can feel like magic. Security is the same: when the right security leader does earn a real seat at the table, the impact is incredible - security shifts from reactive to strategic, from a roadblock to a business accelerator, and that’s when the magic happens.
Looking into the future: changing the approach
When I think about the future of security and the CISO role, it’s clear to me that the path forward requires embracing the idea of influence without authority. This isn’t a new concept - every product manager learns about its importance early in their career. As a PM, for years I had to set the direction and drive execution working with people who never reported to me. Product manager’s success depends on their ability to earn trust, build relationships, and make it easy for others to do the right thing, not on formal reporting relationships or the ability to tell people what to do (sometimes I wish that’s how it worked, but it simply isn’t).
If influence without authority worked for product managers, I don’t see why it wouldn’t work for security leaders. A big part of me is surprised that this simple yet powerful approach hasn’t yet become the “security leadership 101” that every security professional, manager, and exec gets taught the moment they join the industry. I think a part of the problem is that the ability to write policies and procedures tricked many security professionals into thinking that they could achieve lasting change by simply defining something in a policy and enforcing it from the top. In life, nothing quite works that way. If security teams want to achieve lasting change and make their companies more secure, they have to spend time building relationships, earning trust, trying to help companies reach their goals, and evangelizing about security. Policies simply won’t do it.
Another two critical skills for security professionals are storytelling and behavioral psychology, or more broadly, decision science. These aren’t traditionally associated with security, but they’re increasingly essential. Interestingly, they’ve always been foundational to successful product leaders. Just like product managers have to sell their roadmaps to executives to secure buy-in and resources, security leaders must make a compelling case for prioritizing risk mitigation in environments that are constantly pulled toward speed and delivery. Storytelling also plays a central role in both functions, product and security. Despite all the talk about “data-driven decision-making,” people rarely make decisions based on stats alone. What actually moves teams, leaders, and boards are narratives - stories that frame a problem in relatable, urgent terms. In both product and security, the ideas that win are the ones that resonate emotionally, that help people visualize the risk, the benefit, or the path forward. A well-told story can align a room in a way a spreadsheet (or a risk register) never could.
There are many conversations about the need to embed security earlier in the development process, provide paved paths instead of gates, automate risk reduction, act as a business enabler, and so on. Before any of that, I think security needs to learn to influence without authority, tell stories that move others, and understand how people make decisions.
If you are interested in these topics, here are a few books I would recommend to get started. I read many of them years before I ended up in security, and I think every security leader should do the same. Happy reading!
Crucial Conversations: Tools for Talking When Stakes are High
The Art of Quiet Influence: Timeless Wisdom for Leading without Authority
The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever
Predictably Irrational: The Hidden Forces That Shape Our Decisions
Image: a collage of pics from different sources - KnowBe4, IT Security Expert Blog, Security Boulevard, AFK Blog
I think this is a good post overall but fails to take in the three lines of defense responsibilities seen in larger organizations
https://www.theiia.org/globalassets/documents/resources/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense-july-2020/three-lines-model-updated-english.pdfhttps://www.theiia.org/globalassets/documents/resources/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense-july-2020/three-lines-model-updated-english.pdf
For example the CIO and their department of developers own cyber risk for applications that they build. Not cyber. Cyber owns governance to drive accountability of developers to follow policies and organizational best interests.
If organizations don’t hold developers accountable for their own security it will never get done
Well said