The renewal arrives as an email, thirty days before expiry. The vendor writes something about partnership, the price is a little higher than last year, and the attachment is a document that only needs a signature. In most companies, that is exactly what happens next: someone signs.
Consolidating security tools, by contrast, sounds like a project. Like a workshop and a target picture. In our experience, that project never happens, for a simple reason: there is no moment in the year when it would be due. Actually, there is one. It sits in that email.
Why consolidation does not happen as a project
Replacing a working tool mid-contract is unattractive, and rightly so. The licence is paid, the migration costs time, and whoever initiates it carries the responsibility if something slips through afterwards. So everything stays as it is. That is not laziness, that is an understandable trade-off.
But this trade-off flips on a single day of the year: the day the contract expires. On that day, dropping the tool costs nothing. No remaining term, no money lost. You do not have to cancel anything, you only have to not renew.
And of all days, this one is treated as an administrative step in most SMEs. The email goes to the person who signed the contract back then, or to accounting, and the question is "Is there budget?" instead of "Do we still need this?". The stack does not grow because someone wants to buy too many tools. It grows because not renewing is rarely on the agenda.
On top of that, rarely anyone owns the full inventory. The firewall renewal sits with the MSP, backup with IT, the awareness platform with HR, the cyber insurance with the CFO. Everyone sees their own contract, rarely anyone sees the whole pile. That is how the situation arises that we regularly find in assessments: a company cannot say offhand how many security tools it is paying for. Not because the number is secret. Because it is written down nowhere.
So our advice is unspectacular: treat every renewal of a security tool as what it is, a purchase decision at full value. Three questions are enough. Together they take maybe an hour, and they are among the best-paid hours in the entire security budget.
Question 1: Which risk does the tool cover today, and who can show it?
Not: what did we buy it for? The rationale from three years ago is history. The question is what the tool delivers today, and whether anyone can prove it.
Proving it means, concretely: who last acted on an alert from this tool, and what came of it? Who has looked at the configuration since it was introduced? Which of the paid modules are even activated?
A picture we keep finding in assessments: a system whose alerts have been running into a shared mailbox for years, a mailbox nobody has opened since a staff change. The tool does what it is supposed to do. It alerts. Only nobody is listening. On paper, the risk is covered. In reality, it has not been since a single person left, and nobody noticed, because the invoice kept getting paid.
If the answers consist of licence counts instead of incidents, alerts or configuration states, then you are not paying for protection. You are paying for the feeling of having something. A tool whose alarms nobody reads lowers not a single risk, it decorates your budget. How to steer your money to where it lowers risk is something we covered in our post on distributing the security budget.
Important: a "we don't know" to this question is no reason for panic and no automatic verdict to cancel. It is a task to find out before signing. That is exactly what the thirty days are for.
Question 2: How much of this can a tool we already pay for do?
Security stacks in SMEs share a typical history. Every tool arrived as the answer to a question that was acute at the time: an audit finding, an incident at a competitor, a convincing salesperson. Each answer was reasonable on its own. Together they add up to three products for one job.
What has quietly changed in the meantime: the platforms you pay for anyway. Over the past years, the large vendors have built in much of what used to be a separate product. Endpoint protection, device management, mail filtering, multi-factor authentication often already sit in the licence that has long been running on another invoice. The specialist tool from back then now competes against something you already own.
So the question before renewal is: which part of this capability do we now have twice? And is the difference the specialist tool still offers worth the full price?
Sometimes it is. A specialised product can be better than the built-in features, and for a specific risk that can be worth it. But someone has to open that calculation, looking at your risk instead of the data sheet.
The limit of this question belongs here too: this is not about pushing everything to one large platform vendor. Concentration risk is also a risk, and at a critical spot a deliberately chosen second product can be exactly right. The point is decision discipline. Duplications are allowed to exist where someone has justified them. Only, most duplications we see are not there for reasons, they were left behind by history. Why fewer, but properly configured tools protect more in our experience than a broad stack is covered in our post on pragmatic cybersecurity.
A side effect of this question that we see again and again: it uncovers licences nobody uses anymore. Accounts of people who left, modules from an old bundle, test installations with an annual contract. That cleanup has a name of its own and its own post on licence management as a cost driver.
Question 3: What happens if we switch it off?
This is the most uncomfortable of the three questions, and the honest answers fall almost always into one of three categories.
First category: nothing. Nobody would notice, no process depends on it, the alarms were running into the void anyway. That is the easiest decision in the entire security budget, and still hardly anyone makes it, because the question was never asked.
Second category: someone would have to do something by hand, or a risk would be open. That is the good answer. It means the tool delivers something, and now you can talk about the price instead of its existence. Renewing is then not a capitulation but a decision, and in the negotiation it helps when the vendor notices that you have checked the alternative. This category also includes the case where the tool fulfils a contractual requirement, for example from a customer contract or an insurance policy. Then the only remaining question is whether the same requirement can be fulfilled at a lower cost.
Third category: we don't know. This answer should interest you more than any vulnerability on a data sheet. A tool that nobody knows the purpose of is also maintained by nobody. It has access to your systems, an admin account that rarely anyone looks at, and a manufacturer with an update cycle. That makes it less a layer of protection than additional attack surface, and one you pay money for.
Honestly, the third category is not the exception, it is the normal case. And it is the real reason why consolidation is a security gain and not merely a savings programme.
Four decisions and one calendar
In the end, four possible decisions fall out of the three questions, and all four are legitimate.
Renew, because the tool demonstrably covers a risk that would otherwise be open. But do it deliberately, and with a negotiation, because the renewal moment is also the only moment the vendor listens to you.
Downsize: fewer users, fewer modules, a shorter term. Often the problem is not the tool but the expansion that was ordered along with an old growth plan.
Migrate into the platform you already pay for. That needs a small migration window, which is why you ask the questions thirty days before expiry and not three. In our experience, such migrations have a quiet side effect: licences surface that nobody would have touched before, and the biggest gain of the project ends up being the list of contracts nobody has to renew anymore.
Let it expire. No drama, no project. The contract ends, that is all.
And the first step, before any of these decisions: pull the renewal dates of all security contracts into a single calendar, with a reminder sixty days ahead. Today, not next quarter. Without this calendar, the vendors decide about your stack. With it, you do.
The next renewal email
Somewhere in a mailbox in your company, an email like this is probably sitting right now. Friendly tone, slightly higher price, attachment to sign.
If you put the three questions to this one contract, you will know more about your security budget within an hour than from any dashboard. And if you notice along the way that you do not know the answers for half the stack, that is no reason for shame. Environments that grew over time almost always look like this. This is exactly the kind of inventory we do in our engagements, sober and without a new tool list at the end. An initial conversation costs nothing and comes without obligation.
We are curious about the reverse test: which of your tools would not survive the three questions today?
