Author's Note (June 2026)
I originally wrote Cybersecurity Silos: Lessons from Silo in January 2025 after thinking about how fragmentation across teams and technologies creates risk. Revisiting it now, I'm less convinced silos themselves were ever the central problem.
Over the time between then and now — through work spanning security engineering, architecture, risk and compliance, consulting, and executive advisory — my perspective has shifted. Organizations specialize as they mature. The harder question is whether governance, ownership, and decision-making evolve quickly enough to function across that complexity. This article revisits the earlier thinking through that lens.
The original argument, and where it fell short
The earlier piece used Silo — the show, eventually the book series — as a frame for an argument that ran roughly: teams isolate, communication breaks down, attackers exploit the gaps, and the answer is to dismantle the divisions. Integrate the tools. Run joint exercises.
None of that is wrong. It also isn't sufficient.
What I underweighted is that specialization is not a defect of maturity. It is the cost of operating at scale. A security organization that has separated SecOps from architecture from GRC from product security has usually done so because each function requires depth no single team can sustain. Forcing them back into a single undifferentiated unit does not produce resilience. It produces a generalist function performing every job at lower fidelity.
The interesting failure mode is not that organizations have specialized. It is that they reach a level of complexity where the specializations can no longer translate to each other, and no governing layer exists to mediate the gap.
What actually breaks
The visible symptom looks like a communication problem. The underlying problem is almost always governance.
Ownership fragments. Multiple teams touch a risk surface — identity, vendor data flows, a production environment — and no single function owns the outcome. Each team owns its slice; the seams between slices belong to no one.
Accountability converges without context. When something fails, accountability lands on a CISO, a CIO, or a senior executive who was not in the room for the decisions that produced the failure. The role carries the consequence without the authority that should have preceded it.
Decision authority is undefined. Teams escalate decisions that should have been made locally, and make decisions locally that should have been escalated. Neither pattern is corrected because no operating model defines where the line sits.
Incentives diverge. Engineering is measured on velocity. Security is measured on control coverage. Compliance is measured on audit outcomes. The business is measured on revenue. Each function optimizes rationally for its own metric. The composite outcome is not what anyone intended.
Translation fails. A vulnerability described in engineering terms does not arrive at the executive table as a business decision. A board-level risk appetite does not arrive at the engineering team as an actionable constraint. The languages do not connect, and no one is paid to connect them.
None of this is solved by collaboration alone. It is solved by building the governance and operating model required to function across specialization.
Visibility is not the same as authority
A persistent assumption in security thinking — one I held in the earlier article — is that visibility is the precursor to control. Aggregate the data, the logic goes, and better decisions follow.
In practice, visibility without decision authority produces a slower, more anxious version of the same outcome. Teams see the problem. They cannot act on it without an approval that has to traverse three other functions. The signal exists. The system around the signal does not.
A SIEM consolidating data from a dozen tools does not create resilience. A defined decision path — who acts, on what threshold, with what authority, accountable to whom — does. Tooling is the easy half of the problem.
Security and engineering optimize for different constraints
The friction between security and engineering is often described as cultural. It is more honestly structural. Engineering teams are evaluated on what they ship and how quickly. Security teams are evaluated on what they prevent and how thoroughly. These are not the same objective function, and no amount of joint training resolves the underlying difference.
A mature organization does not try to dissolve the tension. It builds an operating model that holds both — security with decision authority at defined points, engineering with autonomy inside defined guardrails, and an executive layer that arbitrates the cases neither side can resolve locally. The tension becomes productive instead of corrosive. That is governance work, not collaboration work.
Accountability stays centralized when execution distributes
One of the more uncomfortable patterns in modern security organizations is that execution has distributed faster than accountability. Product teams own deployment. Platform teams own infrastructure. Data teams own pipelines. Each makes security-relevant decisions every day.
Accountability for the composite outcome still sits with a CISO. The role is increasingly responsible for outcomes it cannot directly control. The answer is not to recentralize execution — that ship has sailed. It is to make the governance layer rigorous enough that distributed execution produces auditable, defensible, traceable decisions. The CISO's job is not to make every decision. It is to ensure every decision is made by the right party, against the right standard, with the right record.
Risk, compliance, engineering, and operations now overlap
The boundaries that used to separate these domains have eroded. Compliance programs that do not understand engineering produce controls that engineering teams route around. Engineering functions that do not understand risk ship features that compliance later has to defend in front of an auditor. Operations functions that do not understand either produce incidents whose root cause was a governance gap, not a technical one.
This is most visible in enterprise procurement. A buyer's security questionnaire is no longer a checklist. It is a stress test of whether the selling organization can produce evidence — not assertions, evidence — that its controls are operating. Organizations that built compliance as a documentation function fail this test quickly. Organizations that built compliance as an operating capability, integrated with engineering and operations, pass it without strain. The difference is governance maturity, not technical maturity.
The same pattern shows up in third-party risk. Vendor management cannot be owned solely by procurement, solely by security, or solely by legal. It is a cross-functional execution problem requiring defined ownership, escalation paths, and review cadence. Most organizations still treat it as a recurring questionnaire exercise. The ones that do not gain a meaningful risk advantage.
AI compresses the timeline
AI doesn't create new governance problems — it exposes existing ones faster than organizations can respond. Decision velocity is increasing faster than oversight structures can adapt. Organizations that had marginal governance for traditional systems will have failed governance for AI-influenced systems within a short horizon.
The right preparation is not an AI governance program bolted on as a separate function. It is a governance operating model that was already capable of absorbing new decision surfaces. The question of who decides, against what standard, with what record, is the same question regardless of the technology underneath.
What this changes
The shift in framing changes what work matters most. It is less useful to ask whether teams are siloed. They will be. Specialization is the cost of operating at scale.
The more useful question is whether ownership exists for the seams between functions, not only for the functions themselves. Whether decisions are being made at the right altitude — neither escalated unnecessarily nor made locally without the right context. Whether the executive layer receives risk in a form it can act on, and whether the engineering layer receives constraint in a form it can implement. Whether the organization can produce evidence, not narrative, that its controls operate. Whether governance has kept pace with the complexity of the business it is meant to govern.
These are the questions that determine whether specialization becomes resilience or fragmentation. The silos are not the variable. The governance is.
Back to Silo, briefly
The show works because the silo's isolation is not, on its surface, irrational. It functions. People have jobs. The system runs. The failure is invisible from inside any single floor — it becomes visible only when someone forces the question of who actually decides, against what authority, with what context the rest of the system cannot see.
The parallel to enterprise security is closer than the original article allowed. The silos are not the problem. The absence of a governing layer that can see across them, and the absence of a clear answer to who decides when the floors disagree — that is the problem. Build that layer, and specialization becomes a strength. Skip it, and no amount of integration tooling will compensate.
Original publication: January 2025. Revised June 2026 to reflect evolving perspectives on governance, specialization, and cross-functional cybersecurity leadership.
