Small business cloud security checklist: what to do first

Cloud security for a small business comes down to four things: who can log in, what anyone on the internet can reach, whether you can restore after an attack, and whether you'd notice one. Turn on multi-factor authentication for every account, close every port you don't use, patch what faces the internet, and keep a backup your production keys can't delete.

That's most of the work, and it fits in an afternoon.

What are the key factors in cloud security for a small business?

Look at how breaches actually start, and the priorities sort themselves. Verizon's 2025 Data Breach Investigations Report found:

• Stolen or abused logins were the way in for 22% of breaches.
• Exploited vulnerabilities, including in edge devices and VPNs, were 20%.
• Third parties (a vendor, a contractor, a supplier's software) were involved in 30%, double the year before.
• Ransomware showed up in 44% of all breaches. In the same release, an IDC analyst put it at 88% of breaches at small and medium businesses.

So the four factors are identity, exposure, recovery and visibility. Logins and exposure are how attackers get in. Recovery decides whether ransomware is a bad week or the end of the company. Visibility decides whether you find out from your logs or from a customer.

What should a small business do first?

Do them in this order. Items 1 to 4 fit in that afternoon. Items 5 to 8 take a month of spare hours.

1. Put MFA on every account, and give everyone their own

Every login that can touch your infrastructure needs a second factor: the cloud console, your code host, your CI/CD system, your domain registrar and your email. Microsoft reported in 2019 that MFA can block over 99.9% of account compromise attacks. CISA's advice for small businesses adds the part people skip: require MFA "using technical controls, not faith." If the setting can be turned off per user, someone will turn it off.

No shared logins either. Every person gets an account, and every script or service gets its own key. When someone leaves, you remove one account and nothing else breaks.

2. Close everything that doesn't need to be open

Start every firewall at deny-all and open only the ports you serve. Your database should never answer on a public IP: put it on a private network and let only your app servers reach it. Use TLS for traffic between your users and your app, and between your services.

3. Patch what faces the internet first

You can't patch everything this week, so start with what an attacker can reach: web servers, VPN appliances, admin panels and anything else with a public IP. CISA keeps a catalog of vulnerabilities attackers are known to exploit and tells small businesses to fix those first, then turn on automatic updates wherever you can.

4. Keep a backup you can't delete from production

Ransomware goes after your backups too. CISA's #StopRansomware guide says to keep "offline, encrypted backups of critical data" and to test restoring them on a regular basis. In practice that means at least one copy in a separate account, with keys your production servers don't hold. Then restore something once a quarter and time it. Our disaster recovery playbook covers the backup rules in detail.

5. Cut permissions down, including third parties

Give each person and each service the least access it needs. Then review it every quarter, and don't stop at your staff: API keys, CI/CD tokens, contractor accounts and vendor integrations are the third-party side of that 30%. Delete the keys nobody can explain.

6. Send logs somewhere central and alert on the few that matter

Collect logins, admin actions and configuration changes in one place, and alert on failed logins, new users, new keys and firewall changes. A few alert rules on a log collector are enough to start.

7. Write your infrastructure as code

Terraform or OpenTofu turns every firewall rule and server setting into a file someone reviews before it ships. Changes clicked into a console drift, and nobody remembers why port 8080 is open.

8. Write a one-page incident plan

Who gets called, what gets shut off, how you tell customers. One page, tried once, beats a long plan nobody has read.

What does your cloud provider secure, and what's on you?

On a cloud where you rent virtual machines, the provider secures the hardware and the platform underneath them, and you secure everything you put on top. AWS describes the split the same way: the provider protects the infrastructure, and what's left to you depends on which services you use.

The column that matters is the "You" column. A provider with a perfect audit report can't stop a leaked password or a database left open to the internet.

How much security does a small team actually need?

Less than vendors suggest. The Center for Internet Security's Implementation Group 1 is a set of 56 safeguards it calls "essential cyber hygiene", aimed at small and medium organizations with limited IT and cybersecurity expertise. You don't need a security team or a security monitoring platform to start. Work through the checklist above, then use IG1 as the list of what's left.

What should you ask a cloud provider about security?

Ask any provider these five questions. Here's how we answer them.

1. Has an independent auditor checked your controls? A SOC 2 Type II report checks a provider's controls over a period of months, not on one day. We hold SOC 2 Type II, with an annual audit covering security, availability and confidentiality, and we're PCI DSS compliant.
2. Will you sign a BAA? If you store health data, HIPAA needs a business associate agreement with your cloud provider. We sign BAAs on request. Our HIPAA hosting guide covers the rest of what HIPAA asks of you.
3. Where does my data live, and who owns the hardware? We run in US regions only, in American-owned facilities we operate ourselves, so you know which country and which company sits under your data. That matters more as data residency rules tighten.
4. What access controls does the console give me? In our console you can turn on two-factor authentication with an authenticator app, add users with scoped permissions, and give each script its own read-only or read-write API key. Network ACL lists include a built-in deny-all list you can attach to any tier of your VPC.
5. How fast does a person answer when something breaks? During an incident, a support queue measured in days is a risk of its own. Our median support response time is under 2 minutes, and a real person answers.

If a provider can't answer one of these plainly, don't sign up with them.