Monday I said security is a fabric, not a stack. Here's where that actually unzips, and why it's a nightmare to fix.
A few years back, I was advising fellow security team members at oiur mid-sized software services firm. They'd just wrapped up a grueling multi-month vendor evaluation and were on the hook for a new tool that cost $250K a year. Right before they signed, I asked them to do something basic: map out their current controls against the exact risk this new purchase was supposed to fix.
Twenty minutes into a whiteboard session, the reality hit. They already had three existing tools that, if properly configured and layered together, dropped the risk down to an acceptable level. The new software was redundant. At best, it was a $250K band-aid they didn't need. They just needed someone to show them how to rationalize what they already owned.
They walked away from the deal. That felt like a win in the moment, but looking back, it really wasn't. Think about the waste: months of work, hundreds of hours of engineering time, and a near-miss on a $250K spend. The only reason they didn't bleed that cash wasn't a robust evaluation process. It was a single, accidental conversation. That kind of oversight shouldn't rely on luck.
The security industry builds a visibility gap straight into its business model. Vendors sell point solutions for point problems. Every pitch deck follows the same script: here's a scary risk scenario, and here's our product that fixes exactly that scenario. It feels logical and clean. It trains buyers to think in silos. Spend enough time in those meetings and you stop asking "what do we already have?" You start asking "which of these vendors is better?"
The result is security teams that are elite at spotting risks and matching them to software, but completely blind when it comes to reasoning across their environment as a whole. Not a lack of intelligence. A lack of practice. The wrong skills keep getting reinforced.
Call this missing skill what it is: systemic control reasoning. It's the ability to understand how your tools talk to each other, where they overlap, where one covers for the weakness of another, and what actually slips through the cracks when the whole apparatus is running. Nobody teaches this. It's not on the CISSP. Vendors certainly won't bring it up. Even the major security frameworks just give you a grocery list of individual controls rather than a blueprint of how they function as a fabric.
The conversation about over-tooling treats it as a budget issue. "Security teams just spend too much." That's a lazy take. The spending isn't the root problem. It's the symptom. Teams lack the mental framework to judge necessity against what they already have implemented and operating.
When you actually understand the fabric of your environment, your buying habits change completely. You stop evaluating new tools in a vacuum and start measuring them against the residual risk left over after your current stack does its job.
Two questions look almost identical: "Do we have a tool for this risk?" and "Does our current setup reduce this risk to an acceptable level?" They produce completely different answers.
The teams that get this right do one thing differently: they map their environment before they map their risks. Not a high-level generic slide. A functional map. What each tool does, what it relies on, where its blind spots are. They treat security as a fabric, not a collection of line items.
When a new threat surfaces or a vendor shows up with a pitch, their first move is automatic. Overlay the risk onto the map. Where does the current defense hold? Where does it fail? What's actually left exposed? You can't honestly evaluate a new tool until you've had that conversation.
You don't need a big budget to do this. A shared spreadsheet, a quarterly working session, a standing meeting where someone asks "what do we actually own, it is implemented in depth, and is it still doing what we think it's doing?" is plenty. The format matters way less than building the habit.
**The second shift is moving your language from coverage to sufficiency. **Coverage asks: do we have a tool for this? Sufficiency asks: is the risk handled when everything runs together? That one change shifts how teams talk about gaps, defend budgets, and justify decisions to leadership. It moves security from reactive panic-buying to deliberate architecture.
Most security programs don't need more software. They need a clear, unvarnished picture of what their current software is doing when no one is looking. The bad guys see your entire environment as one connected system. They're banking on the fact that your team doesn't.