Five Cybersecurity Fundamentals Businesses Should Verify — Not Just Assume

Most organizations we meet have already bought security. There is a password policy, updates are switched on somewhere, antivirus is installed, backups run overnight. On paper the boxes are ticked.

The gap that causes real damage is not usually a missing product. It is the distance between owning a protection and confirming it is configured correctly, still running, and being acted on when it reports something. Those are different questions, and only the first one gets asked at the point of purchase.

Here are five things worth verifying rather than assuming. None of them require a security background to ask about, and the answers tend to be revealing.

1. Is multifactor authentication actually enforced where it matters?

"We have MFA" usually means it is available. The question is whether it is required, and on which accounts.

The accounts that matter most are the administrative ones — the accounts that can change settings, reset passwords, and reach everyone else's data. They are also the accounts most likely to have been quietly exempted, because an administrator got tired of the extra step during a late-night change.

Worth confirming: is a second factor required for every user, including administrators and service accounts? Are there exceptions, and does anyone remember why they exist? Not all second factors are equally strong, so if you are reviewing this anyway, it is a reasonable moment to ask whether the method in use is the one you would choose today.

2. Is everything included in patching, or only the workstations?

Patching tends to be well handled where it is easiest to automate. Windows laptops get updates. What frequently falls outside the process is everything else: servers, firewalls, switches, wireless access points, printers, the line-of-business application nobody wants to restart, and the machine running something that cannot be updated without breaking it.

Worth confirming: what is the actual inventory, and which items on it are inside a patching process? Where something genuinely cannot be patched, is that a recorded decision with protections around it, or has it simply been forgotten?

3. When endpoint protection alerts, who responds?

Modern endpoint protection is good at noticing. What it does next depends entirely on whether a person is watching.

An alert that arrives in an unmonitored mailbox is not protection. Neither is a console that somebody logs into occasionally. The value comes from someone whose job it is to look at what was flagged, decide whether it matters, and do something about it — reliably, including at four in the afternoon on a Friday.

Worth confirming: where do alerts go, who is responsible for reviewing them, and what happened the last time one fired? If nobody can answer the last question, that is the answer.

4. Is email fraud covered by process as well as filtering?

The most expensive email attacks contain no malware at all. Someone receives a message that appears to come from a supplier, an executive or a client, asking for payment details to be updated before a transfer goes out. There is nothing for a filter to catch, because nothing about the message is technically malicious.

Filtering still matters, and it reduces the volume of what reaches people. But the control that stops this particular attack is procedural: any change to payment or banking details gets verified by phone, on a number you already had, before money moves.

Worth confirming: does that rule exist, do the people who process payments know it, and are they confident enough to apply it when the request appears urgent and comes from someone senior?

5. Does the backup cover the right things — and how would you know?

Two separate questions hide inside "we have backups."

The first is scope. Backups often cover the file server but not the line-of-business database, or the servers but not the Microsoft 365 data where most of the organization now works. Cloud platforms protect against their own infrastructure failures; they are not designed to protect you from deletion, corruption or ransomware reaching your data through a compromised account.

The second is verification. A backup job reporting success tells you it ran, not that the data can be recovered. Restore testing is what closes that gap, and whether it is included depends on the backup service you selected — it is worth knowing which you have rather than assuming.

Worth confirming: what is actually in scope, how much data loss and downtime the business could absorb for each important system, and when someone last performed a restore.

The pattern underneath all five

Each of these is really the same question asked five ways: is somebody reviewing this, and is it clear who?

Security decays quietly. Settings drift, exceptions get added during a busy week, a system joins the network without joining the patching process, and the person who understood the alerting console changes roles. None of that announces itself. It simply accumulates until the day something goes wrong and the gap becomes visible. That pattern is security drift, and it is why a one-time cleanup is not the same as keeping an environment current.

Working through these five will not eliminate risk — nothing does. What it does is replace assumptions with answers, and give you a clear view of which protections you genuinely have. That is a reasonable place to start, and it costs nothing but the time to ask.

If you want a hand working through them, our managed cybersecurity and email security pages cover how we approach these day to day, and backup and business continuity explains how recovery gets designed around what a business can actually absorb. For organizations that want this reviewed on a recurring basis rather than once, TechOne Pro is built around exactly that.