SMB cybersecurity: where small businesses are actually exposed

Why small businesses are exposed in a specific way

A small business rarely loses data because an attacker developed a novel exploit for it. The usual path is more mundane: a spoofed invoice that arrives from the company's own domain, a remote desktop service reachable from the internet with a reused password, or a file share exposed by a router rule nobody remembers adding.

These are configuration outcomes, not sophisticated attacks. They persist because nobody's job includes looking at the outside view, and because the systems involved were set up to work, not to be safe from the public internet.

Five exposures that appear again and again

1. Email that anyone can forge. Without SPF, DKIM and a DMARC policy that actually enforces, a supplier or customer has no reliable way to tell a real invoice from a fake one. This is the highest-value, lowest-cost gap in most small businesses. It is also the one most likely to be described as "we have antivirus" in conversation.

2. Remote access facing the world. Remote Desktop on port 3389 and SMB on port 445 were designed for networks where everyone was already trusted. Exposing them to the internet exposes every credential-stuffing list in existence to the same login prompt.

3. A DNS record pointing at something retired. A subdomain that points at a decommissioned hosting account is a takeover waiting to happen. It costs nothing to check and takes ten minutes to clean up.

4. No DNSSEC, so answers can be forged. DNSSEC does not encrypt anything. It makes a forged answer detectable, which matters most for the records that direct mail and logins.

5. Browser headers that were never added because nobody asked. HSTS, Content-Security-Policy and framing protection are cheap and commonly absent. On a simple brochure site the consequences are modest; on a site with a login form they are not.

Start with what is cheap to change

A pragmatic order is: publish a DMARC policy in monitoring mode, confirm SPF and DKIM pass for your real senders, then move DMARC to quarantine and eventually reject. In parallel, close remote-access ports that should never have been open, and clean up DNS records that point at retired infrastructure.

None of that requires new products. It requires an inventory and someone with the authority to change records.

Header hardening and DNSSEC come next. They are slightly more involved and considerably less urgent than email authentication, but they are still configuration work rather than projects.

What to ask an IT provider

Ask for the current DMARC policy and who owns it. Ask which ports on the public IP addresses accept connections from the internet and which of those are deliberate. Ask what happens to DNS records when a hosting account is closed. Ask for a dated report rather than a verbal assurance.

A provider who can answer those four questions is measurably ahead. A provider who cannot is not necessarily negligent — but the gap is now visible, which is the useful part.

Measure it, then re-measure it

An external posture assessment gives you a baseline you can compare against next quarter. The comparison matters more than the absolute score: a finding that disappears after a change is proof the change worked, and a finding that reappears is a process that regressed.

The recorded assessment shows what the output looks like. If you want the equivalent for your own domain, request an assessment — scope and authorisation are agreed before anything runs.