Optimising security costs: when buying is right

There is a quote for a security product on the table, and two camps in the room. One side works out what an incident would cost. The other works out what the licence costs. Both have numbers, both argue cleanly, and neither camp answers the question that decides where the money goes: who runs the thing after you sign?

Optimising security costs is our own subject, we have been writing for months about Swiss SMEs spending too much on security. That has a side effect we helped create. In day to day work, "check before you buy" quickly turns into "stop buying anything". It is the same reflex with the sign reversed, and it costs just as much.

Both reflexes skip the same question

The buying reflex is the better known of the two. After an incident, after a customer questionnaire, or after a good demo, the stack grows by one product, because acting feels better than waiting.

The saving reflex is younger and looks smarter. You cut the renewal or turn the offer down. The minutes record a saving, and twelve months later nobody checks whether the work the product used to do is now being done by someone else. Usually nobody does it.

Both reflexes treat a security product as a purchase. It is a commitment to operate something. That is why two companies with almost identical licence lists end up protected to very different degrees, and also why security costs cannot sensibly be planned as a percentage of the IT budget. We wrote up what to do instead in What IT security costs in an SME.

What the quote does not show

In our experience a company pays for four things when it buys a security product. The licence is in the quote. Setup sometimes is. The other two items are almost never in there.

The third item is the ongoing decisions. Every product that blocks something produces exceptions, and every exception is a decision: who is allowed anyway, for how long, on what grounds.

The pattern behind it looks the same in many companies. IT switches a rule on, on day two the first legitimate cases come in, and because nobody is named to decide on exceptions, the rule ends up either permanently in "log only" mode or on an exception list that nobody reviews afterwards. In the licence agreement, both versions look like business as usual.

The fourth item is the evidence. The alerts, reports and logs a product produces only become a measure once somebody acts on them. An alert without an owner is an entry in a log and not protection, and with monitoring tools that is, in our experience, the most common silent failure. We took that apart in Security monitoring in an SME.

These two items are the real price, and they show up in no quote comparison, because they are not paid in francs but in working time and responsibility. Anyone comparing security costs is therefore usually comparing the smaller half.

Optimising security costs: the three conditions

A security spend pays for itself when three things are true at the same time. None of the three is a verdict on the quality of the product.

One: the spend replaces something. If you cannot say in one sentence what gets switched off, cancelled or not renewed after the rollout, you are buying an addition and not an improvement. In our experience this is the line that most often stays blank. The three questions we ask before every renewal are in Consolidating security tools.

Two: there is an operator with a name. Not "IT", not "the provider". A person with a time budget and a first appointment. This condition decides more about the effect of a security spend than the choice of product does. If nobody internally can take the role on, that is a procurement question in its own right, and more a case for security responsibility on a part time basis than for another product.

Three: the trigger is a risk decision. ISO/IEC 27001 sets out this order in clause 6.1.3: first you determine the risks and the controls that treat them, then you compare the result against the control catalogue in Annex A. Read the other way round, every catalogue turns into a shopping list. What goes wrong there is in ISO 27001 gap analysis.

Two out of three is not enough. A good product with an operator that replaces nothing lets the stack grow. A good product from a genuine risk decision without an operator becomes a line on an invoice. In the budget, both look like security.

When the customer supplies the reason to buy

One document triggers an order more reliably than anything else: a large customer's security questionnaire. Somebody reads a line in it as though a product name were printed there, and two weeks later the quote for it is on the table.

What these questionnaires usually ask for is a state and not a vendor: whether access is controlled, whether data can be restored, whether incidents get reported. In many cases you can evidence that state with a configuration and a named responsibility, and then the answer is a sentence in the questionnaire instead of a new line in the budget.

There is the case where you have to buy even though the three conditions are not cleanly in place. A contract requires it, or a customer makes it a condition. The conditions do not disappear then, they move back in the sequence: you still need an operator, and something still has to give way for it. That order is less comfortable and still cheaper than the version where the product sits unconfigured in the subscription a year later.

The floor that comes before the first purchase

What has to be in place first, the Center for Internet Security has written down in public. CIS sorts its 18 Controls into Implementation Groups. It calls the first one the "on-ramp to the CIS Controls" and describes it as "a foundational set of 56 cyber defense Safeguards" (CIS, Implementation Group 1). It is meant for companies that are "typically small to medium-sized with limited IT and cybersecurity expertise", and the Safeguards are meant to be "implementable with limited cybersecurity expertise".

In plain terms: there is a stated lower bound, it is written for companies without their own security team, and according to CIS it is aimed at general, non-targeted attacks.

More interesting than the number 56 is the kind of items on the list. Inventory, configuration, accounts and access, data recovery, logs. In our experience that is mostly configuration and responsibility work on things a company already owns, and that is exactly why this part looks so unspectacular in a budget. It creates no line item, only effort.

The Swiss ICT minimum standard goes one step less far. It lists its tasks but deliberately refuses to set a target value, and requires every organisation to define its own risk appetite. How to work with that without turning it into an audit across 106 lines is in The ICT minimum standard in an SME.

The four line items that carry nothing

In our experience four line items turn up most often on a security invoice without carrying a decision. Anyone wanting to bring security costs down starts here, before touching the measures that work.

A product for a risk that was never assessed. It is not misconfigured, it simply answers a question nobody asked.

A capability that is already in the existing subscription. Microsoft states, for example, that Microsoft 365 Business Premium includes Defender for Business, designed for organisations with up to 300 users (Microsoft Learn). Paying for a second product alongside it for the same job means paying twice. We sorted out what each tier contains in Business Premium vs E5.

A report nobody reads. Monthly analyses that have run unchanged for a year are a subscription on paper.

A multi-year contract for a product nobody has operated yet. The term lowers the unit price and takes away the decision window in which you would have noticed that the second condition is missing.

What you should keep, even when it looks expensive, is everything that makes the difference during an incident and has a person responsible for it. That the benefit of it only partly translates into a number is uncomfortable, and still not an argument against the spend. What is measurable and what is theatre is in Measuring cyber security ROI.

Two lines on the next quote

Take the offer that lands on your desk next and write two lines beside it. "Replaces:" and "Operator:". Then fill them in before anyone talks about the price.

If both lines hold, the price is a negotiation. If one stays blank, what you have in front of you is not a buying decision but an open question in operations, and no licence solves that. The clean form of it is a no with a date: not now, come back when responsibility is settled.

The same exercise is worth doing backwards across the running line items. That is the part we do most often in our mandates, and it rarely produces a savings programme. It produces a shift: fewer products and more operated measures, and usually less money overall. If you want a second opinion while doing it, a short first conversation is worth more before the signature than after it. How we get to the right size without adding is in Right-sizing IT security.

One question stays, the one we put to every new mandate: which line item on your security invoice has no operator with a name today?

Frequently asked questions

How can an SME optimise security costs without losing protection?

By starting with the line items that carry no decision: a product for a risk that was never assessed, a capability already included in the existing subscription, a report nobody reads, and a multi-year contract for a product nobody has operated yet. Measures with a responsible person stay in place.

When is buying a security tool the right decision?

When three conditions are true at the same time: the spend replaces something existing, there is an operator with a name and a time budget, and the trigger is a risk decision rather than a line in a control catalogue. If one is missing, the purchase becomes a line on an invoice and not a measure.

Which costs of a security product are not in the quote?

Two of the four items. The ongoing decisions about exceptions, meaning who is allowed anyway, for how long and on what grounds. And the evidence work, meaning handling alerts and reports. Neither is paid in francs, both are paid in working time and responsibility.