Why the Capability Matrix Doesn't Age Well
The capability matrix takes weeks to build and months to go wrong. Why 'what breaks if removed' is the first column to fail, and what that costs at renewal.
There's a specific document almost every security architect has built at some point. A spreadsheet, usually. One row per tool, columns for what it does, who owns it, what it costs, what it overlaps with, what breaks if it's removed. It's the artefact you actually need when a renewal is being questioned or a consolidation programme wants evidence rather than opinion.
Most people build it once. Very few keep it.
What it takes to build
A rough version of it looks something like this:
Tool | Capability | Owner | Overlap With | What Breaks If Removed |
|---|---|---|---|---|
Vendor A EDR | Endpoint detection, automated isolation | SOC Lead | Vendor C XDR | Manual triage until a replacement is configured |
Vendor B SIEM | Log aggregation, alerting | Security Engineering | None confirmed | Loss of centralised alerting |
Vendor C XDR | Cross-domain detection | SOC Lead | Vendor A EDR | Partial, depends on which capability is tested |
Three rows, and already there's a judgement call buried in row three: is that overlap with Vendor A deliberate layered defence, or two purchases five years apart that nobody's reconciled. Multiply that by the 45 to 76 tools a typical large enterprise stack actually runs, and the spreadsheet stops being an afternoon's work and becomes a multi-week project, usually done by interviewing every tool owner individually, cross-referencing contracts, and reconstructing decisions nobody wrote down at the time.
Why it goes stale almost immediately
Say the project gets finished. The real problem starts the following month.
Ownership changes. The person who filled in "owner" for twelve of these tools leaves, gets reassigned, or simply stops being the one who actually manages it day to day. Nobody updates the sheet, because updating it was never anyone's job, building it was.
Tools get added and removed outside the process. A new tool gets bought to solve an urgent problem. Nobody circles back to add a row. A tool gets quietly decommissioned. Nobody removes one either. Six months in, the sheet and the actual environment have already diverged in both directions.
"What breaks if removed" degrades the fastest. This is the most valuable column and the first one to go wrong, because the answer changes as configurations change, as integrations get added, and as usage patterns shift. An answer that was accurate at go-live can be confidently wrong a year later, and nobody finds out until a renewal decision gets made on it.
Framework mappings move even when the stack doesn't. MITRE ATT&CK, NIST, and CIS Controls all get revised. A mapping that was defensible against last year's framework version isn't automatically defensible against this year's, and re-checking every tool against every update isn't a task anyone schedules voluntarily.
The maintenance problem is the real problem
None of this reflects poorly on anyone's discipline. Any manually maintained artefact describing a system that changes faster than the artefact does ends up here. The spreadsheet was never wrong on the day it was finished. It's wrong by definition six months later, and by then it's usually forgotten rather than corrected, right up until someone needs it for a board meeting or a renewal decision and discovers it's a snapshot of an environment that no longer quite exists.
A better spreadsheet template doesn't solve this. Column headers were never the bottleneck. The bottleneck is that keeping any point-in-time document current requires someone to notice every change, understand its implications, and go back and edit a file that nobody's incentivised to touch. That's a process problem, and it's the specific reason this exercise tends to get done once, with real effort, and then quietly abandoned.
That's the gap ESProfiler was built to close: it keeps the underlying map current automatically as the stack itself changes, so the answer to "what does this tool do, and what breaks if we remove it" stays accurate on the day it's needed rather than the day someone last had time to update a file. If you want to see what that looks like against your own stack, a Security Reality Baseline is a fixed-cost, fixed-time way to find out.