Six Questions Every Security Stack Should Answer

Most enterprise security stacks were accumulated rather than designed. A tool bought to address a specific incident five years ago is often still running, performing a job that two or three later purchases now also perform, and maintained by someone several handovers removed from whoever originally selected it. No one plans an estate this way; it emerges one procurement cycle at a time, and it is close to universal. A Gartner survey of large enterprises, conducted in late 2024, put the average at 45 cybersecurity tools, while 2025 research from the IBM Institute for Business Value and Palo Alto Networks put the average organisation at 83 security solutions across 29 vendors. In Pentera’s 2025 survey of enterprise CISOs, 45 per cent reported their stack had grown over the past year. Wherever a given estate falls within that range, the direction is consistent: stacks grow faster than the organisation’s ability to maintain a live picture of them.

What has changed in recent years is who asks about the stack, and how quickly they expect an answer. Boards increasingly expect cyber spend to be defended in business terms. Auditors and regulators, particularly under frameworks such as DORA and NIS2, expect evidence rather than assurance. Procurement teams expect a substantiated case before agreeing to another multi-year term, and an incoming security leader expects a straight answer within days of arriving. The gap between the question and the answer is where the problem becomes visible: a query that should take minutes to resolve instead becomes a research project measured in weeks.

The six questions below are the ones a security estate should be able to answer at any time, not only when a specific request forces the exercise.

1. What do we actually own?

There are usually at least three versions of this answer: what appears in the architecture diagram, what appears in the CMDB, and what is actually deployed, actively licensed, and doing work today. These three versions drift apart over time, and in many organisations the discrepancies only surface when a renewal notice arrives for something nobody remembers configuring. An answer grounded in the third version, current deployment and licensing reality, is the foundation for every question that follows.

2. What does each tool actually cover?

Owning a tool and understanding its coverage are separate matters. A platform bought for one purpose frequently ends up covering, or partially covering, several others as its vendor expands the feature set over successive releases. What a tool is licensed to do and what it is actually being used to do are therefore two distinct facts, and the distance between them tends to be where underused capability accumulates, a subject question six returns to.

3. Where does coverage overlap, and is that overlap intentional?

Some overlap is deliberate. Layered controls are overlap by design, and removing a layer without understanding why it exists creates gaps rather than closing them. The more demanding analytical task is distinguishing between the two cases: identifying which overlaps constitute defence in depth, and which are simply two purchases made several years apart, the second duplicating the first without anyone noticing at the time.

4. What would break if we removed this?

This is the question procurement and finance most often need answered ahead of a renewal, and it is rarely a quick one to produce. A credible answer requires knowing not only what a tool does in principle, but what would actually stop functioning if it were withdrawn, which risks would reappear, and which other tool, if any, would need to absorb the coverage. Teams that can produce this answer quickly negotiate renewals from a position of evidence; teams that cannot tend to renew by default, because renewing is faster than demonstrating that the alternative is safe.

5. Are we actually mapped to the frameworks we’re accountable to?

Most security teams have completed a framework mapping exercise at some point. Fewer can say with confidence that the mapping still reflects the estate as it exists today. Frameworks such as MITRE ATT&CK, NIST, and CIS Controls continue to evolve, and stacks change more frequently than mapping exercises are repeated. MITRE’s own team has described control-to-framework mapping as labour-intensive and often subjective, which goes some way to explaining why most mappings age out quietly rather than staying current of their own accord.

6. Is any of this shelfware?

Underused security spend is more common than most budget conversations acknowledge. Osterman Research found that 28 per cent of per-user security software spend was underutilised or entirely unused, with individual cases running considerably higher, and in CSO’s Security Priorities study, half of security leaders reported not using all the features of the technologies they already own. Shelfware rarely draws attention to itself; it simply continues to renew until someone asks what it is for.

Answering all six at once

None of these questions is new, and most teams could answer some of them well given time. The difficulty lies in answering all six quickly, simultaneously, and without standing up a dedicated project each time the need arises. The answers live in real data: contracts, usage, configuration, framework mappings, and the institutional knowledge held by the people who operate each tool day to day. In most organisations that data exists, but it is distributed across systems and individuals rather than assembled in one place.

This is the gap ESProfiler was built to close, bringing capability, framework coverage, spend, and usage together into a single current view, so that these six questions have a documented answer on any given Monday rather than a three-week research project behind them. For organisations that want to establish where their own estate stands today, a Security Reality Baseline is a fixed-cost engagement that delivers precisely that: a clear account of what is owned, what it actually covers, and where the risks and opportunities sit, produced within four to six weeks.