001 Compliance

What "unsupported software" means on your insurance renewal

Your renewal form asks whether you run supported software versions. What that question means, why insurers ask it, and how to answer it honestly.

Somewhere in your cyber liability renewal there is a question like this:

Are all operating systems and applications currently supported by their vendor and receiving security updates?

Most owners tick yes without checking, because the question reads like a formality. It is not a formality. It is one of the more consequential questions on the form, and a meaningful number of small businesses are answering it wrong.

What the question is actually asking

Software is maintained by whoever made it for a defined period. During that period, when somebody finds a security flaw, the maintainer publishes a fix and you install it. Then support ends on a date the maintainer chose, often years in advance.

After that date, flaws keep being found — researchers do not stop looking — and they keep being published, with details. But no fix is ever released for your version.

Nothing happens to your system on that date. It does not slow down or break. It simply stops being defended, and the number of publicly documented ways into it grows every month from then on.

That is what “unsupported” means. Not old. Not slow. Undefended, permanently, in a way that is documented publicly.

Why insurers care so much

Because it is the single most predictive question they can ask cheaply.

An insurer cannot audit your systems for the price of a small business policy. What they can do is ask a question whose answer correlates strongly with claims. Running unsupported software correlates strongly, because the majority of successful attacks on small businesses are not targeted. They are automated: a flaw is published, tools sweep the internet looking for anyone running the affected version, and whoever has not patched gets found.

If you are on a supported version and patching, those sweeps pass over you. If you are not, you are in the set they are looking for.

We have watched that traffic from the inside. On one machine we were asked to look at, the login for the server itself had recorded 45,878 failed attempts — none of them a person, all of them programs working through a list. The full picture of what that machine looked like is here. Nothing had gone wrong yet. That is the normal state of affairs right up until it is not.

The part that should worry you more than the premium

An insurance application is a formal declaration. If you state that your systems are supported and receiving security updates, and it later emerges during a claim that they were four years past end of life, you have a problem considerably larger than a higher premium.

Whether a specific claim gets denied depends on the policy wording, the jurisdiction, and how the misstatement is characterized — that is a question for your broker, not for us. But the general principle is not controversial: material misstatements on an application can affect coverage, and this is a material question. It is on the form precisely because it matters to the risk.

How to answer it honestly in twenty minutes

You do not need a developer, and you do not need to know what any of the words mean.

Ask whoever maintains your system two questions in writing. Which operating system version does our server run, and what is its end-of-support date? And the same for the software your website or application is built on. Ask for dates, not reassurance. Dates are checkable and reassurance is not.

Understand that some of this is already public. Servers announce a certain amount about themselves to anybody who asks, and it is indexed. That cuts both ways: it is one more reason to get the dates in writing from your host, and a reminder that an insurer’s assessor and an attacker’s scanner are reading the same records you are.

Write the answers down with the date you got them. Next year’s form asks the same question, and next year’s answer needs to be a fact rather than a memory.

If the answer comes back badly

Two things are worth knowing before you decide what to do.

The first is that this is usually cheaper to fix than people expect, because the fix is not a rebuild. The dangerous thing is the machine and the versions on it, not your software. Moving the same software onto hosting that is still maintained is a well-understood piece of work measured in weeks, and it buys you the answer to the insurance question immediately while leaving the larger question — whether the software itself should be modernized — as a decision you take calmly, later, on your own schedule.

The second is that “unsupported” is not one question but several, because a system has layers. The operating system, the language the software is written in, the database, and the components the software was assembled from all have their own dates, and they are rarely all current or all expired. Answering the form honestly means knowing which are which.

What we would say to your broker

Nothing, because we are not your counsel and we do not tell insurers anything about anybody.

What we would tell you is this: the question on the form has a factual answer, that answer is knowable in under an hour, and the number of businesses that have never established it is much larger than the number that would say so out loud. If yours is one of them, that is worth an hour before the next renewal rather than a conversation during a claim.

If you want somebody to establish it properly and write it down, that is part of what an audit produces, and you can write and tell us what you are running first. The reply is free and it will say honestly whether you need us.

Recognise any of this in your own system? Describe what breaks and a person replies within one business day. Free, and a person is what’s at the other end.

Write to us  ·  The work  ·  What things cost  ·  All writing