Security Basics 07｜It should be fine: four vague phrases in a technical answer

Every time you ask an engineer or a supplier: can we actually restore from our backups? Does yesterday's vulnerability affect us? Have the permissions of the colleague who left been revoked? If the answer begins with — it should be fine, it should be running, in theory we are not affected, normally that would already be closed — do not nod and end the conversation just yet.

Because whether those four phrases appear together or on their own, in plain language they mean one thing: they are answering from memory or from logical inference, and they have not opened the system and seen it with their own eyes. This is the seventh piece in our security basics series. In Security Basics 01｜An advisory just landed: how do you know whether it affects you and How a Non-Technical Owner Can Tell If an Engineer Is Right we set out a core principle: you do not need to understand the technology yourself, but you do need to hear whether you are being given an inference or a fact.

Why technical people like to add these four phrases

In fairness to engineers first: someone who says one of these is not necessarily fobbing you off or lying. In a software system, between "it was configured correctly back then" and "it is still working properly today" sit countless links that can change quietly — the server disk filled up, a plugin's automatic update failed, a certificate expired, or a release accidentally overwrote the configuration.

As the UK's National Cyber Security Centre (NCSC) warns in its 10 Steps to Cyber Security: Vulnerability management guidance: an organisation cannot rely on automatic updates or existing configuration alone. It must also monitor update status continuously, actively understand the circumstances in which an update fails (insufficient storage, too large a version gap, or a manual restart being needed before it takes effect), and write clearly into the update policy who is responsible for carrying it out and who is responsible for checking and confirming it.

When you throw a question out in a meeting or a message and the other person does not have the admin panel and the logs open in front of them, what comes to mind is "it was designed this way", and out comes "it should be fine". That is an honest reflection of "this is how I remember it" — but taking memory for the current state is precisely where many security incidents begin.

Unpacking the four phrases: what they have in mind vs. what may actually have happened

Take the four apart and each one hides a common blind spot:

• One: should (there should be backups, we should not be affected) — this means they are going on a memory from several months ago. A schedule was genuinely set up at launch, but they have not looked today at the date of the most recent backup file. If the disk filled up recently and the backup has been failing every day, their remembered "there should be" is, today, "there is none".
• Two: in theory (in theory nobody can reach it from outside, in theory this vulnerability cannot touch us) — this means they are describing the design in a textbook or an architecture diagram, not the live state. The diagram shows the database closed to the outside world, but perhaps someone opened a firewall rule temporarily while rushing a fix recently, and forgot to close it again afterwards.
• Three: normally (normally the system updates itself, normally an alert would fire) — this means they are assuming every external condition is in perfect order. But security incidents happen precisely when things are not normal: the mailbox receiving the alerts filled up long ago, the key for the bot that sends them expired, or the automatic update is stuck halfway on a compatibility problem.
• Four: by rights (by rights the supplier handles that, by rights they cannot log in once they have left) — this means they are guessing at someone else's actions from common sense, and nobody has actually checked an account list or a contract clause. You assume the supplier by rights looks at it, the supplier assumes you look at it, and the ground in between becomes land nobody tends.

One table to turn a vague inference into a verified fact

When you hear one of these four, you do not need to question anyone's competence, and the room does not have to go cold. Following the principle set out in How a Non-Technical Owner Can Tell If an Engineer Is Right ("you do not have to remember the reasoning behind every question, only that a good answer contains three things: a specific person, a specific time and a specific fallback"), you can gently pull the question back from how it was set up to what it actually looks like now:

Give them time to check, but do not accept an unchecked answer

Often the reason a technical person reaches for a vague phrase is that the owner has signalled, in the conversation, that they want to hear "no problem" right now. When you are impatient for a reassuring answer, the fastest thing they can give you is "it should be fine".

The most effective way to break that habit is to separate "answer me now" from "go and find out". Next time you hear one of the four, you can say directly: do not answer me from memory right now — take a little time, go and look in the back end, and once you have confirmed it just send me the current version number or a screenshot. Once they know that what you want to see is a result from opening the system today, those vague inferences turn into specific times, numbers and records of their own accord.

Nerd Technic is a systems software company that came out of custom development, and what we do now is the long-term maintenance of AI systems. In How a Non-Technical Owner Can Tell If an Engineer Is Right we wrote: "a health check has only three conclusions — we can take it over as it is, it needs tidying first, or rebuilding would cost you less. You will not get an equivocal answer." Long-term maintenance is about how soon someone responds when something breaks and how often security updates happen, and both belong in writing in the contract. If you have had enough of hearing "it should be fine" every time you ask about the state of your system, a system health check is a place to start. Book a system health check