Cybersecurity roles aren't silos — they're one connected system

Every big cybersecurity incident taught us the same lesson, and we keep ignoring it.

MGM Resorts, September 2023. The attacker didn’t burn a zero-day. They called the help desk, got a credential reset without proper verification, used the newly-minted MFA, pivoted through the environment, and eventually encrypted ESXi hosts. Losses: roughly $100 million, disclosed in MGM’s October 2023 Form 8-K to the SEC, plus a reputational hit that persisted into the next year.[1]

Now ask: whose job was that? Awareness training owned the decision the help-desk agent made. IAM owned the process that accepted the reset. Zero-trust architecture owned the blast radius. The SOC owned detection latency. Incident response owned containment. Leadership owned the policy that didn’t exist. Six jobs. Six cert paths. Usually six reporting lines. One incident.

Cybersecurity teaches itself as a list of specializations. The incidents we fail to prevent don’t respect that mental model.

The silo mental model is everywhere

Open any “cybersecurity career paths” article, certification study guide, or conference track schedule. You’ll see the same canonical list: SOC Analyst, Penetration Tester, AppSec Engineer, Cloud Security Engineer, GRC Analyst, Threat Intel Analyst, IAM Engineer, Incident Responder. Each gets its own paragraph, its own cert path, and its own origin-story success profile.

This is useful for hiring rubrics and bootcamp marketing. It is also a lie about how the work actually gets done.

The signals reinforcing the silo view are everywhere: job boards list discrete roles, cert vendors sell discrete paths, conference tracks sort attendees by specialization, enterprise org charts put each function in a separate box, training platforms teach each topic in isolation. The result is predictable — a practitioner three years into “SOC analyst” who has never read an IAM design doc, an AppSec engineer who has never operationalized a threat intel report, a GRC analyst who has never touched a detection rule. They know their lane. They don’t know why the last major breach at their company happened at the exact seam they never had reason to look at.

What the seams actually look like

Here are four places roles depend on each other, pulled from real incident retrospectives rather than reference architectures.

1. IAM quality drives SOC quality.The SOC can only tune alerts well if identity context is reliable. Stale entitlements from a weak mover/leaver process surface as overprivilege during incidents — meaning detection rules tuned for a role no longer match reality. If you’re an SOC analyst who keeps getting vague “this user accessed something unusual” alerts, the upstream problem is often the IAM team’s, not yours.

2. Supply-chain state feeds exposure prioritization. Vulnerability management without reachability context is counting the wrong thing. A team that treats dependencies as “the AppSec team’s problem” and exposure management as “the vuln team’s problem” builds a workflow where the handoff itself is where critical bugs stall. Log4Shell was famously hard to remediate not because the patch was complex but because no single role owned do we even ship Log4j, and where?[2]

3. Data classification determines restore priority.In a ransomware recovery, the team with the backup infrastructure doesn’t know which systems to bring up first. That’s the data classification team’s call. That’s the privacy team’s call. That’s the business continuity team’s call. In a real event, these three groups often first meet in a Slack channel at 3am — which is the wrong time to discover they have different prioritization frameworks.

4. Cloud misconfig is almost always an identity + governance problem. The exposed S3 bucket is the symptom. The IAM role design that went unreviewed is the cause. The ownership policy nobody enforced is the structural cause. The cloud security engineer gets paged, but the fix lives three layers up.

The 50-domain map

We built a living map of how cybersecurity, AI security, and quantum-safe engineering actually connect — the SecProve Cyber Systems Model. Fifty practice domains organized into five practitioner-mental-model layers (Govern, Control, Build, Detect, Futures), with explicit relationship types between them.

Every edge on the map is one of four things: a prerequisite (A must be in place before B works), a constraint (A sets policy for B), an enablement (A materially improves B), or an operational coupling(A and B must collaborate during the work). These aren’t abstractions — each edge is backed by concrete incident patterns where the relationship fails and something lands in a post-mortem.

The map isn’t novel because it lists the domains. It’s novel because it forces you to see the seams. When you hover Identity & Access Management, the map lights up every domain that inherits its quality: Zero Trust, Cloud Security, AppSec, Data Protection, SOC, Detection, Recovery, Exposure Management, Agentic AI. When you hover SOC, the map shows you every upstream assumption your alert queue depends on.

Pick a career path in the toolbar and the map redraws as the domain constellation a practitioner in that role has to keep warm. Pick a certification and the map highlights what that cert centrally covers versus what it merely touches. Pick an incident and step through it one domain at a time to see the cascade.

What this means for careers

The advice “pick a specialization” isn’t wrong. You need depth somewhere. But it stops short. The more durable question is: pick a specialization, and learn the two or three adjacent domains you’ll need to collaborate with constantly.

The strongest SOC analysts have opinions about IAM. The strongest pentesters know enough about exposure management to target what’s actually reachable. The strongest GRC analysts can read a detection rule well enough to tell when a control evidence claim is fictional. The career moves that compound — SOC → detection engineer, IAM engineer → security architect, AppSec → product security — all happen along seams the silo view makes invisible.

What this means for hiring

The best interview question isn’t “walk me through your SOC experience” or “what’s your preferred exploit stack.” It’s describe a time your team hit a wall because another team’s work wasn’t what you thought it was. The answer reveals whether the candidate has thought in seams or only inside their own lane.

Companies that hire for single-lane depth end up with teams full of specialists who can describe their role but can’t close an incident. The practitioners who actually close incidents are the ones who have been on enough bridge calls to know every role’s failure modes cold.

What this means for program design

Most cybersecurity programs don’t fail because a tool wasn’t available. They fail because a seam wasn’t staffed. The breakdown patterns are depressingly consistent across organizations:

• Good policies, weak enforcement.
• Strong tools, weak architecture.
• Good visibility, poor ownership.
• Alerting without prioritization.
• Teams organized in silos.
• Crypto-agility deferred until it’s too late.
• Securing-AI work assigned to the AI-using team.

Each of those is a seam failure. The solution isn’t a better SIEM. It’s program design that deliberately staffs the seams. NIST CSF 2.0 added Govern as a first-class function in 2024 partly because too many programs were treating governance as a distinct lane instead of an integrating one.[3] Frameworks keep trying to push practitioners toward the systems view. The mental models we inherit keep pulling them back.

The takeaway

Specialties aren’t going away. The work requires depth, and nobody’s asking analysts to be jack-of-all-trades. But the mental model that the specialties are independent is wrong, and every serious incident retrospective proves it.

If you’ve been treating your career, your hiring, or your program like a list of roles that happen to share an office, take fifteen minutes with the domain map. Pick your role. See what it depends on. See what depends on it. See the seams.

That’s the actual map of the work. The list of roles is just the directory.

References & further reading

1. MGM Resorts International (2023). Form 8-K (filed October 5, 2023). U.S. Securities and Exchange Commission. The $100M figure is from the company’s own disclosure. See also CISA’s advisory on the help-desk social-engineering tradecraft used by the Scattered Spider threat actor (AA23-320A).
2. CISA (2021). Apache Log4j Vulnerability Guidance. Link. The response challenge was asset and dependency discovery, not patch complexity.
3. NIST (2024). Cybersecurity Framework (CSF) 2.0. Link. Adds Govern as a sixth core function, explicitly positioned as integrating across the other five.