
There is nobody in the security market who gets paid to tell you: that is enough. The vendor lives off the next module, the MSP off the next service, the auditor off the next finding. All incentives point in the same direction, and that direction is more.
That is why the question of how to right-size your IT security almost never gets asked. Yet it can be answered. Just rarely by someone who wants to sell you something in the same conversation.
Why the default answer is always more
Under-provisioning has a lobby. Every incident in the news, every vendor study, every renewal presentation tells the same story: the threat is growing, so your stack has to grow with it. The story is even half true. The threat level keeps evolving, nobody disputes that.
The second half does not follow from it. From a growing threat it follows that your measures have to match your risk. It does not follow that a new product gets added every year.
Over-provisioning, on the other hand, has no lobby and no headline. It appears in no threat report. It sits as license line items in your accounting, spread across a dozen contracts, and only becomes visible when someone puts the total next to the functions that are in operation. In our experience that happens in very few companies, because nobody is responsible for doing it.
Add to that a quiet driver: comparison. What do others in our industry have? What does the framework recommend? A framework like ISO 27001, though, is a catalog of possible measures and was never meant as a shopping list. Read the catalog as a target state and you build the security architecture of a corporation into a company with 120 employees. It feels thorough. Above all, it is expensive.
How a stack reaches this size
No company decides on a Monday morning to operate twelve security products. The state builds up in layers, and every layer had a good reason at the moment it was added.
After the phishing incident four years ago came the email security gateway. The auditor flagged missing logging, so a SIEM arrived. The new MSP brought its own endpoint product, and the old one kept running because of the remaining contract term. The cyber insurer required MFA and vulnerability scanning, and the broker conveniently recommended a provider right away. Then the head of IT changed, and the new one knew a better backup tool from his last company.
Each of these decisions is understandable on its own. The pattern behind them only becomes visible from a distance: every product has an entry story. Almost none has an exit story. Inside the company there is a trigger, a budget and an advocate for every addition. For switching something off there is none of that, only the diffuse unease that a security product is better left untouched. So the inventory grows, year after year, one renewal signature at a time.
What stands as sizing in most SMEs was therefore never decided by anyone. It is the sum of occasions. That also explains why it so rarely matches the business: nobody ever measured it against the business in the first place.
Over-provisioned does not mean on the safe side
All of this would be half as bad if too much security only cost too much money. A buffer, unnecessary but harmless. Unfortunately it does not work that way.
Every tool you buy needs someone who configures it, maintains it and reacts to its alerts. That is the uncomfortable constant behind every security budget: protection comes from operating a measure, the license on its own delivers nothing. An SME with 50 to 500 employees has no SOC team in the basement. It has an IT department that also handles laptop replacements and the ERP upgrade on the side.
When that IT department is responsible for twelve security products, the predictable happens. Two or three run properly. The rest is installed, half configured, and reports into a mailbox nobody reads. On paper you are broadly covered. In practice you have bought yourself a facade, and the facade has a double price: the license costs and the false feeling of being covered.
The third price is the quietest. The money and attention tied up in the facade are missing in the places that carry the load in the end. We regularly see environments with advanced detection tooling in which nobody has rehearsed a restore from backup in years. Or in which departing employees still have active accounts weeks later. The same company is then over-provisioned and under-provisioned at once, and both for the same reason: what gets bought is what feels good, instead of what the company can operate.
How to concretely scale back a stack that has grown this way is covered in our post on consolidating security tools. Here we are dealing with the question before that one: how do you even recognize which size is right for you?
The yardstick sits in your business, not in the offering
Right-sizing means: the size of your security measures derives from three reference points, and none of them appears in a brochure.
The first is your exposure. What do you run that is reachable from outside? Who depends on you, as a customer or as a recipient of data? What would your company be usable for from an attacker's point of view, even if nobody is targeting you specifically? A manufacturer with remote maintenance access and connected machines has a different exposure than a fiduciary firm with client data, and both differ from the software provider whose platform runs at thirty customers. The same tool list for all three is guaranteed to be wrong for two of them.
The second is your business risk. Which three scenarios would cost you the most? Usually they are surprisingly unspectacular: several days of production downtime, the loss of customer or engineering data, a blocked bank account after payment fraud. Measures that contribute to none of your expensive scenarios are candidates for the cut list, no matter how good their demo was. How to order your existing budget along these scenarios is covered in our post on distributing the security budget correctly.
The third is your operating capacity, and it is the hardest limit. The right amount of security is the amount your team can fully operate. Fully means: configured, up to date, with a human who reacts to alerts and has time in the calendar to do so. A measure that does not meet this condition only lengthens your inventory list.
From these three reference points you get a sizing that may have little to do with the industry average. Maybe you need fewer products than your competitor and, in return, a properly rehearsed emergency process. Maybe in one place you even need more than you have today. Both are fine. The only wrong move is leaving the question to the offering.
Three test questions to locate where you stand
You do not need a project to find out whether your IT security is right-sized. One hour is enough, together with the willingness to sit through three answers that will probably be uncomfortable.
First: which of our measures does someone operate day to day? Go through the list and mark only what is configured, maintained and where someone reacts to alerts. Ask for names instead of responsibilities on paper. "The MSP handles that" only counts if you know what the MSP does according to the contract and what it last reported. Everything unmarked is inventory.
Second: does our spending contribute to our most expensive scenarios? Take the three scenarios that would cost you the most and check which of your measures concretely does something against them. Concretely means: you can say in one sentence how the product prevents, shortens or cushions the scenario. If the largest budget item contributes to none of the three, you have your answer.
Third: what could we switch off without our risk measurably increasing? If the answer with more than ten products in use is "nothing", that is rarely a sign of precision. More often it is a sign that nobody has ever asked the question. Asking it alone changes the next renewal conversation noticeably.
Enough is a decision
There is a reason these questions get asked so rarely, and it is human. Nobody has ever been criticized for an additionally purchased security product. For a switched-off one, yes, namely when something happens afterwards, regardless of whether the product would have prevented it. This asymmetry means that without a deliberate counter-impulse every organization drifts toward over-provisioning. Caution looks like buying. Responsibility looks different: it records which risks you carry, which you cover and why, and then stands by the list, even if it is shorter than the competitor's.
Sizing your IT security is therefore a leadership decision and should be treated as one. Someone in the company has to set the yardstick, document the reasoning and defend both against the market's constant pressure. In larger companies a CISO does that. In an SME this role does not need a full-time position, but it needs a name (we broke down what this role costs here).
If you want to run this assessment with someone who gains nothing from your list getting longer: that is exactly what we are here for, with no product behind us. A first conversation is non-binding, and more often than you would think, the list at the end is shorter than before.
And because we honestly want to know ourselves: when did someone at your company last deliberately switch off a security measure?




