The IT Foundation Gap in Cybersecurity

Your security analyst gets an alert. Suspicious activity on a workstation. The EDR console shows the machine communicating with a known bad domain. Protocol says quarantine immediately.

But here's where things get interesting. The analyst with IT fundamentals asks different questions first. What's running on that machine? Who uses it? What business processes depend on it? What does network quarantine actually mean in this environment - does it kill VPN connections, break mapped drives, interrupt database connections?

The analyst without that background sees a button labeled "quarantine" and clicks it.

The difference isn't just operational. It's strategic. And it's costing organizations more than most CISOs realize.

The Real Cost of Security-Only Thinking

I've watched this play out hundreds of times. Security teams staffed with smart people who understand threats, compliance frameworks, and security tools. But when it comes time to actually implement controls or respond to incidents, they're working blind.

Take email security. SPF, DKIM and DMARC aren't just checkboxes on a compliance audit. When you implement these controls without understanding mail flow, you can break legitimate business communications overnight. I've seen organizations accidentally block their own invoicing systems, customer support emails, and partner communications because someone treated these as simple security configurations rather than fundamental changes to how email works.

The person who's administered Exchange servers understands that DMARC policy changes ripple through every system that sends email on behalf of the organization. They know to check for third-party services, marketing platforms, and automated systems before flipping that switch. They understand the difference between a soft fail and a hard reject, and more importantly, they understand what those policies signal to receiving mail servers.

The security-only person sees "enable DMARC" on their project list and moves to the next task.

Why This Gap Exists Now

This wasn't always a problem. Twenty years ago, there were no entry-level security jobs. You came up through IT. You troubleshot servers, configured networks, and dealt with angry users when systems went down. You learned how technology actually worked before you learned how to protect it.

The demand for security talent changed that pipeline. Organizations needed security people fast, and they found ways to hire them directly out of school or boot camps. The intentions were good, but we created a knowledge gap that's now affecting operations.

I straddled an interesting transition point. I got a degree focused on cybersecurity, but there weren't dedicated security roles when I graduated. I spent fifteen years in IT - support, systems administration, network management, and eventually consulting where I architected and deployed IT infrastructure for organizations of all sizes. Only then did I move into security leadership.

That path gave me something I see missing in many security teams today: I understand how the business actually runs on technology. When I talk to IT teams about security requirements, I speak their language. When I need to implement controls, I understand the operational impact. When something breaks, I know where to look first.

The MDR Reality Check

This gap is becoming more critical as the industry shifts toward managed detection and response. Organizations expect their security teams to not just detect threats, but to respond to them quickly and effectively. That means more hands-on keyboard work, more direct system interaction, and more real-time decision making.

But response isn't just about security tools. It's about understanding how to isolate network segments without breaking business operations. It's knowing how to disable accounts without locking out service accounts that keep critical applications running. It's understanding the difference between stopping a process and killing a service that other systems depend on.

When your security team lacks these fundamentals, response times stretch from hours to days. Not because they don't understand the threat, but because they have to research basic operational tasks or wait for IT teams to implement changes they should be able to handle themselves.

The Business Impact CISOs Feel

For security leaders, this translates to several painful realities:

Slower incident response when teams need to pause investigations to figure out basic system operations. I've seen breach responses delayed because security analysts couldn't determine which systems would be affected by network isolation.

Increased vendor dependency as teams rely on external support for tasks they should handle internally. This drives up costs and creates response bottlenecks during critical incidents.

Communication breakdowns with IT stakeholders who lose confidence in security teams that don't understand operational realities. Getting IT buy-in for security initiatives becomes much harder when they view security as disconnected from business operations.

Implementation delays as security projects require constant IT involvement for basic technical tasks. What should be quick configuration changes become multi-week projects requiring coordination across teams.

What Successful Programs Look Like

The security teams that operate most effectively combine deep threat understanding with solid operational fundamentals. They can implement controls without breaking business processes. They can respond to incidents without creating new problems. They can communicate with IT teams as partners rather than customers.

These teams don't happen by accident. They're built through intentional hiring and development practices that value IT experience alongside security knowledge.

Building Better Security Teams

The solution isn't to go back to requiring decades of IT experience before someone can work in security. But it does mean being more intentional about building operational capabilities within security teams.

In hiring, look for candidates who've built systems, not just studied them. Someone who's configured Active Directory, managed mail servers, or deployed applications brings immediate operational value that's hard to teach later.

In development, create pathways for security professionals to gain hands-on IT experience. Partner with IT teams on projects. Encourage lab environments where security staff can break and fix systems. Support certification paths that build operational skills alongside security knowledge.

In team structure, ensure you have people who can bridge the gap between security requirements and operational realities. These don't have to be your most senior people, but they need to be people who understand both worlds.

The goal isn't to turn security analysts into system administrators. It's to build teams that understand how technology actually works so they can protect it more effectively.

Moving Forward

The cybersecurity field has matured rapidly, but our talent pipeline hasn't always kept pace with operational realities. We've optimized for speed of hiring over depth of capability, and organizations are feeling the impact in slower response times, higher costs, and frustrated stakeholders.

Building security teams with solid IT fundamentals isn't just about better technical outcomes. It's about creating security programs that can actually execute on strategy rather than just planning for it.

The organizations that recognize this gap and address it intentionally will have a significant operational advantage. Their security teams will respond faster, implement more effectively, and communicate better with the business stakeholders they need to succeed.

The question for security leaders isn't whether this gap exists, most have felt its impact. The question is what they're going to do about it.