In Part One, Zach Frankhouser, Globalgig’s NetSec Practice Lead, and Adam Riccitelli, an Incident Response Lead at S&P Global, explored the gap between deploying a security control and making it effective.
Once those controls are live, a harder question follows: Who has the capacity to operate all of it effectively?
Security operations now span network, endpoint, identity, cloud, SaaS and AI. Each layer adds more telemetry, more alerts and more decisions. The challenge is connecting those signals, working out what matters and acting on it fast enough to contain the impact.
When the Security Stack Outgrows the Team
Zach: There’s a version of this problem I see all the time. An organization can have a really mature security environment on paper, but the operations behind it are still split across different tools and teams.
I was speaking with one CISO recently who was dealing with exactly this. They’d invested heavily in technology, but the team was already receiving more alerts than they could realistically investigate in a day. He knew more visibility would only add to the pressure.
At that point, the question isn’t really whether you have the right tools anymore. It’s whether your team can actually operate them together as one security program.
Adam: Adding capability is usually the easier part. The harder part is making all those controls work together operationally. The firewall is logging. The endpoint platform is alerting. The SIEM is ingesting. Nothing looks obviously broken. But siloed signals don’t make a unified security operation.
Zach: A control can be generating data and still only show one part of the picture. A change in network behaviour might look harmless on its own, but combined with something unusual on the endpoint or identity side, it can tell a very different story.
The stack can look more mature every year while the operating model around it falls further behind.
Ownership Is a Decision; Operations Is the Work
Outsourcing security operations isn’t new. MSSPs and external SOCs can extend coverage, add expertise and ease pressure on internal teams.
The problem is when that support becomes a black box. The provider sees the alerts first, decides what matters and controls the tools, while your team is left raising tickets and waiting for someone else to act.
Zach: I think of it as ownership versus operations. Ownership is accountability; it's deciding what "normal" looks like for your environment, which incident matters, and what happens next. Operations is the work around it: monitoring, tuning, first-line investigation, integration, keeping the tools healthy across every time zone.
Operations Can Be Shared; Ownership Can’t
Adam: I’m increasingly seeing a hybrid model where the internal incident response team stays close to the same alert queues and evidence as the SOC. They’re effectively a second layer. If something isn’t picked up quickly enough, or the SOC doesn’t escalate it, the internal team can see it and step in.
That matters because the internal team brings context that an external provider may never have. The team can reassess the judgment, investigate further and retain control of incidents that need to stay in-house for legal, compliance, access or confidentiality reasons.
Zach: There is a test in that. If your provider reviewed an alert last Tuesday and decided it did not warrant escalation, how would your team know?
Adam: If the honest answer is the monthly service review, or the next incident, the operation is running without you.
Judge the External Model by What It Simplifies
Zach: There’s another separation worth challenging. Sometimes tooling gets split because the provider operates one way and the internal team another. I’ve seen customers using one SIEM while their provider uses a completely different platform.
That’s when you have to ask: Does the security model require that separation or did the service model create it?
Adam: Two systems aren’t automatically a problem. But if analysts are jumping between platforms, comparing alerts manually or trying to work out which system has the fuller picture, that separation starts creating work of its own.
That’s the test I’d use for any external operating model: Does it simplify your operations or complicate them?
Zach: A good partner should be able to build and support the operation without creating dependency. The knowledge, tuning and intelligence built around your environment should stay with you, even if the relationship ends.
Where AI Earns Its Place
Zach: There are two very different promises here. One is "AI will make the analyst faster." The other is "AI will make the decision for the analyst." But the output is only as good as the data underneath it. If the logs are incomplete, you’re asking AI to reason over a bad picture.
Adam: Where I do find it useful is removing friction. Natural-language search in a SIEM is a good example. Instead of remembering the exact query syntax, I can ask for a user’s logons over the last 24 hours and get to the investigation faster.
The bigger opportunity for me is triage. If an analyst logs on and sees 1,000 alerts, I don’t want AI investigating every one and deciding what happened. I want it to surface the five most likely to need attention now.
Zach: And that distinction matters. Helping an analyst prioritize what deserves attention is very different from allowing AI to decide what happens next.
Adam: Even with level-one triage, there’s still a verification problem. You need consistency, and you need to be able to explain why a decision was made. These systems aren’t deterministic in the way traditional security automation is. Give the same situation to a model more than once, and you can’t always assume you’ll get exactly the same judgment back. That matters when the action you’re asking it to take has a real security consequence.
Zach: AI doesn’t fix the underlying operating-model problem. And simply putting a human in front of every decision isn’t the answer either. If AI is operating at machine speed and someone has to approve hundreds of actions, you’ve just created another bottleneck.
I think of it almost like a CPU checking the output of a GPU. AI can process huge amounts of information quickly, but you still need a more deterministic control layer around it.
That means setting clear boundaries around what AI can access, decide and act on, and when it has to escalate. Humans set those boundaries and stay accountable, but they shouldn’t have to approve every step.
The Best Model Knows What Belongs Where
Zach: When I step back, the strongest model isn't a choice between building internally, outsourcing or "letting AI run it." It’s working out what each is genuinely best placed to do.
Adam: Internal teams own the decisions and the accountability. That doesn't move.
Zach: A managed partner adds capacity and expertise where you need it. For one organization, that might mean co-managing the day-to-day SOC. For another, it might be much narrower: keeping a particular platform tuned, maintaining integrations or bringing in specialist support where the internal team doesn’t have enough depth or time.
Adam: And AI accelerates the investigation. Under human judgment, on data you can trust.
Zach: Get that right, and each corner reinforces the others. Get them wrong, outsource too much, automate too much or force the team into a service model that doesn’t fit, and you can end up adding complexity instead of removing it.
The goal isn’t to generate more security activity. It’s to increase how much of it your team can understand and act on.
AUTHORS
Zach Frankhouser - Global NetSec Practice Lead
Zach Frankhouser is a network and security sales leader with over 15 years of experience across enterprise connectivity, managed infrastructure, WAN modernization, and cloud-delivered security. Combining a background in technical solution development with enterprise sales leadership, he works with organizations navigating network modernization, cloud-driven traffic changes, and evolving security architectures.
Prior to Globalgig, Zach held leadership roles across enterprise networking and managed services. At Globalgig, he leads strategic SASE and security initiatives focused on secure enterprise connectivity, operational scalability, and long-term infrastructure modernization.
Adam Riccitelli - Lead Cyber Incident Response Analyst at S&P Global
Adam is a cybersecurity professional with more than 10 years of hands-on experience across incident response, technical investigations, and risk mitigation. He holds CISSP, AWS Security, and three SANS GIAC certifications, and regularly works across both technical and executive teams to translate complex security findings into practical actions.
He is also an active contributor to the cybersecurity community through organizations including FIRST and OWASP, and has contributed as a subject matter expert and guest speaker with Hack The Box.