“Call it what it is. It’s finger pointing,” says Joseph Apuzzo. “Whenever there is an issue, everyone always kind of thinks that their job is on the line.” When an incident hits, the hardest question is often the simplest one: who owns it? In CommandLink’s first podcast episode, Joseph sits down with a panel from both the network and security sides to unpack where NetOps and SecOps actually break, why it keeps happening, and how to bridge the gap:
- Joseph Apuzzo, Senior Director of Security Solutions Engineering, CommandLink
- Austin Amraen, SOC Director, CommandLink
- David Morrison, Senior Solutions Engineer, Versa Networks

Why This Keeps Happening 

“Easiest way to describe it is communication,” David said. Network and security teams are usually siloed, often intentionally. The tools a network administrator uses don’t always align with the tools a security administrator uses. And many people see security as an inhibitor to productivity, so teams start to treat security as the enemy. 

Austin agreed from the security side. Companies often set up the two teams separately early on, and as they grow, the teams drift further into their own buckets. They share many of the same goals, but there’s always a tiff: “Well, I need this secured. Well, I need this open for this reason.” That tension can cause more problems than it solves. 

Four Ways to Bridge the Gap 

1. Replace Finger Pointing With Conversation 

When something breaks, emotion takes over. Joseph described the cycle plainly: you’re blaming me, I’m blaming you, instead of working together. On top of the silos, there is often a bureaucratic wall that keeps each team focused only on its own job. 

His recommendation is simple: have joint meetings. “Have a biweekly where the network team and the security team actually talk to each other.” 

David agreed it would help, but said a meeting alone doesn’t fix the root cause. 

Why it matters: As long as each team feels its job is on the line, it will blame the other instead of working together. A regular joint meeting gives both teams a place to actually talk. 

2. Recognize It as an Evolutionary Problem 

“This is an evolutionary problem,” David said. Companies started with networks first: someone stringing cables between desks, then an IT hire, then an entire connected building. “Security didn’t come until, unfortunately, way late.” 

By the time security arrived, the two functions had already been built separately for years. Politics keep them that way. The chief security officer and the head of IT are typically not the same person, and they often don’t report into the same structure. 

Why it matters: A weekly meeting is a good start, but the bigger task is breaking the cycle that keeps these roles segmented. As David put it, “They once were or you could make the argument that they might have been, but they’re definitely not in 2026.” 

3. Unify the Tools So Both Teams See the Same Picture 

Each team sees only part of the story. Austin explained that the network side looks at firewall bandwidth, connections, routing and circuits: is it up, is it down, is anything throttling? Security looks through logs for anything that isn’t supposed to come through, such as bad traffic or C2 communications. Those two views are almost always gapped apart. 

“You have to bring it together and both have to see the same picture,” Austin said. With separate tools, a call goes to one team, another call goes to the other, “and you’ve got a 30-minute blind time between the two.” With a shared view, security can flag what it sees, and the network team can confirm it on the same screen. 

David added an example of what happens without it. A web application firewall thinks it is seeing a denial of service attack and starts intentionally throttling traffic. The network team is “running around with their heads on fire” trying to figure out why throughput is so low. Meanwhile, the security team looks at the same event and says the tool “is doing exactly what it should do.” 

Why it matters: “When everyone can see the same thing, everyone’s working on the same team,” Austin said. When both teams can see what the other is seeing, “you actually get a bigger picture.” 

4. Decide Who Owns It 

Unification raises a harder question. “But who owns it?” Joseph asked. There has to be a marriage between the teams, but who takes the lead, and when? Budgets are another sticking point. When NetOps and SecOps are separate, so are their budgets. Joining them creates a much larger budget, and someone has to own it. 

David said it comes down to corporate culture, and he has seen it both ways. In the last couple of years, cost has pushed companies toward unifying tools. Modern devices can handle more than one function, and when a box costs $50,000 or $100,000, companies want to use it to the best of its ability. 

Size works against unification. “The bigger the company, typically the more siloed things become,” David said. 

Why it matters: Ownership is where unification succeeds or stalls. In David’s opinion, “the structure of companies that are more unified are typically more successful.” 

Where the Industry Is Headed 

NetOps and SecOps break down for reasons that build on each other. Communication is siloed. Finger pointing takes over when an incident hits. The two functions grew up separately, with different leaders and reporting structures. And each team works from its own tools, seeing only part of the picture.  

Are companies actually bringing NetOps and SecOps together? David said yes, there is more integration. Whether it’s happening at a scale where you could confidently say the whole industry is moving that way is harder to say. There are many companies, and they all do it differently. 

What he has seen is consistent, though: the companies that do it successfully are the ones moving toward unification. 

The panel’s path forward: talk regularly, unify the tools so both teams see the same thing, and settle who owns the incident and the budget. 

As David put it, these roles may once have been separate, “but they’re definitely not in 2026.”