A Cybersecurity Checklist for Thai SMBs

Attackers target small and mid-sized businesses precisely because they assume the defences are weak, and the assumption is usually correct. The encouraging part is that most breaches exploit a small set of well-understood gaps. Closing them does not require an enterprise budget or a security team — it requires deciding that someone owns the work.

This is a practical baseline for Thai SMBs, ordered by impact per baht spent. If you do only the first three, you have removed the majority of realistic attack paths against a business your size.

What are the most important cybersecurity controls for a small business?

In order of impact: multi-factor authentication on email and remote access, tested offline backups, prompt patching, endpoint protection, and least-privilege access. MFA alone blocks the overwhelming majority of credential-based attacks, and on most business platforms it costs nothing but the hour it takes to enable.

Notice that four of the five are configuration rather than purchase. The instinct to solve security by buying a product is understandable and mostly wrong at this size — the gaps that get Thai SMBs breached are almost always unconfigured basics, not the absence of advanced tooling.

Turn on multi-factor authentication everywhere

Enable MFA on email, remote access, VPN, and every administrative account. Stolen or reused passwords are the entry point for a large share of breaches, and MFA makes a stolen password insufficient on its own. This is the highest-impact hour of security work available to any Thai SMB.

Start with email, because email is the master key — whoever controls it can reset the password on nearly everything else. Then remote access and VPN, then administrative accounts on your servers and cloud platforms.

Prefer an authenticator app over SMS where you have the choice. SMS-based codes are far better than nothing, but SIM-swap attacks are a real risk in Thailand, and an app costs nothing extra.

Patch, back up, and actually test the restore

Keep operating systems and applications current, and maintain at least one backup copy that is offline or otherwise unreachable from your network. Ransomware routinely encrypts connected backups along with everything else. A backup you have never restored from is a hope, not a plan.

The 3-2-1 rule remains the right shape: three copies of the data, on two different media, with one off-site. The off-site copy is what survives fire, flood, theft and ransomware that reaches everything on the network.

Schedule a restore test quarterly and write down how long it took. That number — your actual recovery time, not the vendor's claimed one — is the single most useful figure in your disaster planning, and most businesses discover it is several times longer than they assumed.

Train your people, briefly and often

Most successful attacks begin with a convincing email rather than a technical exploit. Short, regular phishing-awareness training measurably reduces click rates and costs a fraction of incident recovery. Fifteen minutes quarterly beats a two-hour session annually.

Thai-language phishing has improved considerably. The old advice — "look for bad grammar" — is no longer reliable, particularly now that attackers use the same language models everyone else does. Train on the behavioural signals instead: unexpected urgency, a request to change payment details, and any message that discourages verification through another channel.

Make it explicit that reporting a suspected phish is always welcome and never punished, including after someone has already clicked. The time between compromise and disclosure is the variable you can most affect, and fear of blame is what lengthens it.

Know who to call before you need to

Decide in advance who responds to an incident, who can authorise taking systems offline, and who notifies whom. A one-page written plan turns a panicked scramble into a controlled process — and under the PDPA, a documented incident-response capability is expected, not optional.

The plan needs to answer four questions: who decides, who executes, who communicates, and what evidence gets preserved. That last one matters more than people expect. The instinct during an incident is to wipe and rebuild immediately, which destroys the logs needed to establish whether personal data was accessed — which is exactly what you must report on within 72 hours.

Keep a printed copy. If the incident affects your systems, a response plan stored only on those systems is unavailable precisely when you need it.

• Who is the named incident lead, and who covers when they are unavailable?
• Who has authority to disconnect a system or the whole network?
• What are the out-of-band contact details for your IT provider — phone, not email?
• Which systems hold personal data, and therefore trigger PDPA notification obligations?
• Where is the offline copy of this plan?