Infra + security: why more & more CISOs are starting to own infrastructure
Discussing the convergence of infra and security and what this means for CISOs, founders, and the industry as a whole
Over the past year, I have started to see a growing trend that in more and more organizations, CISOs are taking ownership of infrastructure teams. Where CISOs aren’t directly taking over infrastructure teams, they are exerting more direct control over how infrastructure is designed and operated. Like many structural shifts in cybersecurity, this is developing gradually, but as soon as this trend catches critical mass (and I believe it will), it may forever change the role of CISO and where security fits in the enterprise, as well as how security products are built. That’s exactly what today’s issue of Venture in Security is going to be about.
This issue is brought to you by... BlinkOps
Your SecOps deserves a platform that runs your way.
Every SOC runs differently. Tools, processes, people, constraints. None of it looks like the next team's setup.
Your SecOps deserves a platform that runs your way.
BlinkOps gives you Agentic SOC and Agentic SOAR, both built to flex. Start with plug-and-play solutions for AI SOC, Agentic IAM, Cloud Security, GRC, and more. Customize them when needed. Build from scratch. Or co-build with our forward-deployed engineers.
One platform to agentify your SecOps, with enterprise governance, security, and scale.
The old model of security under IT
Let me start by saying that I am well aware that who security reports to is all over the map. I have met a number of CISOs reporting to general counsel aka legal (which is not at all uncommon), COOs (Okay, I guess I get what this setup was probably meant to achieve), and CFOs (I have lots of questions about this setup). However, most commonly, security sits under IT, or to put it simply, most often, CISOs respond to the CIO. There is a whole separate discussion that not every company has a CIO, which is why at tech startups, CISOs can also commonly be a part of the CTO organization, but we’ll also put that debate to the side…
From a function within IT led by a security manager to a standalone function under CISO
For the sake of simplicity, let’s ground this in how things have historically worked. Security didn’t start as a standalone discipline, and instead it lived inside IT as just another sub-function. It was usually led by a security manager who may have had a different title, but their main role was to support IT and infrastructure teams, managing firewalls and antivirus, and doing some compliance.
Over time, as companies became more digitized, cyber threats also became much more visible. A lot of that was driven by high-profile breaches, pressure from the regulators, and the growing (even if kind of slow) realization that cyber risk is business risk. Companies started to need someone who could be held accountable for managing risk and preventing, detecting, and responding to security incidents when they happen. In 1994, Steve Katz became the first CISO at Citicorp, and over the past 30 years, the CISO role has become super common.
Even though on paper, CISOs were C-level execs, and security was its own function, in many, or I would even say most cases, security leaders inherited the same constraints as the security teams before them. Even though their role grew in visibility and responsibility, most CISOs had pretty limited control over infrastructure. When security needed something implemented, it still had to align with IT and engineering to actually get it done, and that didn’t always go well.
A big part of the problem was that most CISOs were now reporting to the CIOs, who continued to own infrastructure and IT. Effectively, we ended up with a model where one C-level executive reports to another. This wasn’t just an ego problem, as this setup has had broader implications. I often talk about the fact that most security gaps are caused by issues that security can discover, but can’t fix on its own, without the help of IT and infrastructure teams. To actually reduce risk, security needs to have enough political capital to negotiate prioritization with other teams, and the best way to do it is to, well, be on equal footing with leaders of these other teams. In simpler words, it’s harder for CISOs to push the CIO to prioritize some work when the CIO is their boss, which is exactly what has been happening.
From configuring infrastructure, to reviewing it, and then to guiding it
During the same time that the org structure and reporting lines were changing, the scope of security teams’ responsibilities when it comes to infrastructure was changing as well. Early on, when security was a function within IT, it was hands-on, configuring firewalls, managing controls, and operating IT tooling directly. At that time, there wasn’t much of a line between IT and security, so it’s just how things were.
As security became a separate function under CISO, environments grew more complex, and responsibilities scaled, so security moved into more of a review role. The focus became on auditing configurations, approving changes, and identifying risk, but overall, it was still largely about reacting to decisions made elsewhere. In other words, when a security person would show up at your desk, you knew you had done something wrong, implemented something without their approval, etc.
Fast forward to today, and in a growing number of organizations, security has evolved into what I would define as a guiding function. Instead of configuring controls themselves or simply reviewing what others have built, security is defining the policies and risk boundaries that establish how infrastructure gets designed and operated from day one, what controls have to be met, etc. You can see this trend in different areas of security, from product security to identity and cloud. The innovation companies like Aryon are bringing to cloud security, companies like DevArmor, Prime Security, and Clover Security are bringing to product security, C1 and Oblique to identity security, and others are creating guardrails for proactive or pre-emptive security. Broadly speaking, security teams are realizing that the only way to manage ever-growing complexity and an expanding attack surface is to think in terms of systems, not by chasing individual issues, but by defining how those issues can (or cannot) get created in the first place.
The new model of infrastructure under security
Security guiding infrastructure is a big step forward from where we were before, but it’s still just a stepping stone. It improves outcomes, but it doesn’t fully solve the underlying problems. More specifically,
Security is still often treated as something adjacent to day-to-day operations, which really means that security isn’t baked into how infra is provisioned and managed.
Security can set policies, but it still depends on other teams to implement and prioritize them.
Security and infra end up having to deal with competing priorities (infra teams are measured on uptime, performance, and cost, while security is measured on risk reduction).
The biggest challenge is that in this model, CISOs end up with accountability without control: they are ultimately responsible for risk, but since infra is owned by someone else, they are still one step removed from the systems that create that risk.
This is why it makes so much sense that at more and more companies, instead of security simply guiding infrastructure, it is starting to own it. At a growing number of organizations, infrastructure teams are starting to report into the CISO or operate under a security-led function that combines both domains.
What’s really driving this shift is a recognition that the line between infrastructure and security was always somewhat artificial, and it tends to break down at scale. In today’s environments, every infrastructure decision is a security decision: how services connect, how identities are granted access, how traffic flows, how environments are segmented, all these are as much infrastructure problems as they are security problems. When those decisions are owned by one team and the consequences by another, there will always be issues. By bringing infrastructure under security, organizations are ending up with a model where the same function that defines risk is also responsible for how systems are built and run. This solves a lot of the challenges around alignment, incentives, and prioritization, and for companies operating at high scale and complexity (which most of the enterprises today are), I think this direction is starting to look like an inevitability.
The trend I am talking about isn’t universal, but it’s definitely growing pretty fast. Not every security leader has the ambition, skillset, or desire to run infrastructure, but a growing number of them do. The new generation of security leaders is more comfortable operating closer to infrastructure, thinking in terms of systems, reliability, and performance, not just controls and policy. These CISOs don’t see infrastructure as “someone else’s domain,” but as the primary surface where security is actually enforced. As complexity continues to grow and the gap between responsibility and control becomes harder to ignore, more organizations are willing to try this model of ownership. It may not become the default overnight, but the direction is that more CISOs are pushing toward owning infrastructure (not because they want to, but because increasingly, they have to).
What this means for security founders
The convergence of security and infrastructure has real consequences for founders. Historically, security teams focused on detection and response, prevention, and security posture. Most of the vendor solutions in the market targeted a single team (security). Anything that touched more than one team was seen (and continues to be seen) as a bad idea because the more departments are involved in the purchase, the longer it takes, and the more people need to be aligned for the transaction to go through.
Over the past several years, things have been changing. There is a growing realization that a) most security problems cannot be solved without bringing in infrastructure, IT, and engineering, and b) it’s becoming harder and harder to sell products that have no operational value beyond helping organizations reduce risk. I talked a week ago about how CISOs are expecting to see ROI, and how the best ROI isn’t just risk reduction, but a combination of that with operational efficiency.
In the coming years, I expect to see more security products that solve problems on the edge, between security & infrastructure, security & IT, security & engineering, and so on. And, when more and more CISOs end up owning both security and infra, not only will it be easier to sell those products, but also it’ll be expected that new-generation security startups do more than just security. This isn’t a futuristic trend, it’s already happening (just look at startups like Vivid Security and Gambit Security building on the intersection of infra and cyber, and many others).
Great article, thanks for sharing, Ross.
This was a great read Ross, thanks for posting!