Where does small business cybersecurity start?
Start with what stops the most attacks for the least effort: multi-factor authentication (MFA) on email and cloud accounts, backups you have actually restored, and current updates. Then look at what you expose to the internet, who has access to what, and what you'd do on the day of an incident. That order matches public guidance from CISA, NIST and CIS.
You don't have to invent the method. CISA publishes Cyber Essentials, a guide for small business leaders built around six elements: yourself as the leader, your staff, your systems, your surroundings, your data and your crisis response. As first steps it recommends automatic backups, MFA starting with privileged, administrative and remote users, and prompt patching.
The Center for Internet Security calls its starting point essential cyber hygiene: CIS Controls Implementation Group 1, a foundational set of 56 safeguards meant for smaller organizations. NIST runs a Small Business Cybersecurity Corner with guidance by topic: ransomware, phishing, MFA, cloud security and incident response. What follows is that material, applied to how a typical small company actually runs.
What should you check first, in priority order?
| # | What to check | What good looks like |
|---|---|---|
| 1 | Accounts and MFA | Email, cloud, banking and code repositories require a second factor; nobody shares passwords |
| 2 | Backups | One copy sits out of an attacker's reach and someone has already restored from it |
| 3 | Updates | Operating systems, PHP, CMS and network gear on supported versions |
| 4 | Domain email | SPF, DKIM and DMARC published, with DMARC at a policy that rejects spoofing |
| 5 | Exposed services | Only what's needed answers from the internet; no databases or SSH open to everyone |
| 6 | Cloud configuration | Root account locked down, activity logging on, alerts that someone reads |
| 7 | Who has access | Current access list; people who left no longer hold keys or accounts |
| 8 | Incident plan | One page that says who to call, what to shut down and where the backups are |
1. Accounts and MFA
Many small business incidents begin with a stolen, reused or guessed password. Turn on MFA for email first, since every other account can be reset from there, then for the cloud console, banking, your domain registrar and your code repositories. Prefer an authenticator app or a hardware key over SMS.
2. Backups that actually restore
A backup you've never restored is an assumption. An attacker inside your network can delete or encrypt any backups it can reach, so at least one copy should live outside your main network or on storage that can't be modified. Schedule a restore test and write down how long it took: that number is your real recovery time.
3. Updates
Many of the flaws exploited in real attacks already had a published patch. CISA maintains the Known Exploited Vulnerabilities catalog, and anything listed there deserves to jump the queue. Watch for software that's out of support: an older system on PHP 7.4 won't get an official fix. This week's alerts summarize which versions are at risk and what to do.
4. Email: SPF, DKIM and DMARC
Without these records, anyone can send mail that looks like it came from your domain and ask your customers for a payment. SPF lists which servers may send for you, DKIM signs each message, and DMARC builds on both to tell receivers what to do with mail that fails and to send you reports. Start in monitoring mode, read the reports, and tighten the policy once your legitimate mail passes.
5. Services exposed to the internet
List everything that answers from outside: website, VPN, remote desktop, admin panels, database ports. Each one is a door. Close what doesn't need to be open or move it behind a VPN, and keep what remains patched and protected. It's the same principle as our server hardening guide.
6. Cloud configuration
The cloud isn't secure by default; it's configurable. What we usually find: a root account without MFA, access keys that are years old, storage made public by mistake, and detection services that alert an inbox nobody opens. If your system runs on AWS, the AWS security audit guide walks through it control by control.
7. Who has access to what
Former vendors, former employees, the developer who built the system back in 2019: any of them may still hold an account, an SSH key or a token in your code. Review access every quarter and remove whatever nobody can justify. One account per person, with only the permissions they use.
8. Incident plan
You don't need a hundred-page manual. You need one printed page: who to call, who decides to shut a system down, where the backups and emergency credentials are, and how to notify customers. CISA frames it as limiting damage and restoring normal operations quickly.
How much can your team do on its own?
Quite a lot. Items 1, 2, 7 and 8 depend more on discipline than on technical depth. A list for this week:
- Turn on MFA for everyone's email and for every admin account.
- Restore one file and one database from backup, and time it.
- Check your site's PHP version with the free check.
- Ask whoever manages your domain for the status of SPF, DKIM and DMARC.
- List the people and vendors with access and remove anyone who no longer needs it.
- Print the incident plan page and put it somewhere people will find it.
Items 3, 5 and 6 do need someone technical: which versions really run, which ports are open and how the cloud is configured aren't visible from an office. That's where an outside review saves weeks.
When is an outside security audit worth it?
When you run your own systems or a cloud account nobody has reviewed since launch, when a large customer sends you a security questionnaire, when you're preparing for an ISO 27001 audit, or after a scare. Also before you hire a pentest: if the basics aren't closed, the report fills up with findings a review would have caught much earlier. We cover that in pentest vs. security audit.
A five-second first step: the check only reads your homepage's public response. Use it only on domains you own or manage.
Check my PHP for freeFrequently asked questions
What is the first thing a small business should do for cybersecurity?
Turn on multi-factor authentication for email and admin accounts, and confirm your backups can be restored. Those two measures stop the most attacks for the least effort.
Is my company too small to be a target?
No. Many attacks are automated: they scan for vulnerable versions, leaked passwords and open services regardless of company size. Being small mostly means fewer people to notice the attack.
Which framework should I follow without an IT team?
CISA's Cyber Essentials is written for small business leaders, and CIS Controls Implementation Group 1 collects 56 essential safeguards. Both are free.
What do SPF, DKIM and DMARC do?
They stop others from sending mail that looks like it came from your domain. SPF authorizes servers, DKIM signs messages, and DMARC tells receivers what to do with mail that fails and sends you reports.
How often should I test my backups?
At least every quarter and after any major change to your systems. Time the full restore: that's how long it would really take you to get back to work.
Is antivirus enough?
No. Antivirus protects the device, but it doesn't stop someone logging in with a stolen password, a public storage bucket in your cloud, or a server running unsupported software.
Does Security OS replace a security team?
It isn't a 24/7 SOC. It audits and monitors cloud, repositories, code and servers, prepares fixes and documents every closed finding. For many small companies it covers the technical work nobody is doing today.
Sources
- CISA: Cyber Essentials
- NIST: Small Business Cybersecurity Corner
- CIS Controls: Implementation Group 1 (IG1)
- CISA: Known Exploited Vulnerabilities Catalog
- IETF RFC 7208: Sender Policy Framework (SPF)
- IETF RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
Written by Samuel Hinojosa and the wITS security team · Updated Oct 25, 2026 · Markdown
