Ten cloud security best practices, in priority order
These are ordered by the threat data above, not by convention. Work down the list. Each one gives you what it means, why it sits at that rank, and the first concrete step.
1. Fix identity first
Identity and access management is now the top-ranked cloud threat. An attacker with a valid login does not need an exploit. They walk in, and your monitoring sees a normal session.
Three things close most of this gap. Turn on multi-factor authentication for every human account, with no exceptions for executives or contractors. Apply least privilege so each account holds only the permissions its job needs. Delete shared admin accounts, because a login four people use is a login nobody owns.
First step: list every account with administrative rights in your cloud console. Most teams find more than they expected, and some belong to people who left.
2. Find and close misconfigurations continuously
A misconfiguration is a setting that quietly exposes something: a storage bucket open to the internet, a database reachable from any address, logging switched off, a default password left in place. These appear during normal work, not through carelessness. Someone opens a port to debug an issue on Friday and never closes it.
The word to hold onto is continuously. A one-off review finds today's problems. Configuration drift puts new ones in next month. Cloud security posture management tools scan settings against a baseline and flag changes; every major provider now ships a basic version at no extra cost.
First step: switch on your provider's native security posture tool and read what it already found.
3. Control third-party and vendor access
A third party is involved in 48% of breaches. Most companies grant a vendor access during onboarding and never review it. The contract ends, the integration stays, and the credential keeps working.
List every external party with access to your cloud: managed providers, contractors, SaaS integrations, agencies, auditors. For each, record what they can reach, who approved it, and when it expires. Give access an end date by default.
First step: pull the list of service accounts and API keys, and find the ones nobody can explain.
4. Encrypt data, and manage the keys deliberately
Encrypt data at rest and in transit. Every major provider does this by default now, so the interesting question is not whether you encrypt but who holds the keys.
Provider-managed keys are fine for most workloads and cost you nothing to run. Customer-managed keys give you control over rotation and revocation, and they matter when you handle regulated data or need to prove separation. Decide which data justifies the extra work rather than applying one policy everywhere.
First step: confirm encryption is on for every storage service and database, including backups and snapshots. Snapshots are the ones people miss.
5. Make backups immutable, and test the restore
Ransomware crews look for your backups before they encrypt anything. A backup sitting in the same cloud account, with the same credentials, is not a backup. It is a second copy of the problem.
Immutable backups cannot be altered or deleted for a set period, even by an administrator. Keep at least one copy in a separate account or region with separate credentials. Then test the restore, because an untested backup is a hypothesis.
First step: find the date of your last successful restore test. If there is no date, that is your answer.
6. Log everything, and make sure someone reads the alerts
Cloud platforms can log every API call, login and configuration change. Most companies turn logging on and stop there. The logs fill up, nobody watches them, and the evidence of an intrusion sits unread for months.
Decide what deserves an alert and who receives it. Failed logins on admin accounts, new accounts with elevated rights, changes to security groups, storage permissions opened to the public. Keep the alert list short enough that people still react to it.
First step: name the person who reads the alerts. If no name comes to mind, that is the gap.
7. Secure the APIs and interfaces you expose
Every cloud application exposes interfaces, and each one is a door. Insecure interfaces and APIs sit high on every cloud threat ranking because they are often built fast, documented poorly, and forgotten.
Authenticate every endpoint, including the internal ones. Rate-limit them. Validate what comes in. Keep an inventory of what you expose, because you cannot protect an endpoint nobody remembers building. Our guide to securing your website against cyber threats covers the application-layer side in more depth.
First step: list your public endpoints and check which ones require authentication.
8. Patch what faces the internet on a shorter clock
Exploited vulnerabilities account for 31% of breaches. In the cloud, the patching duty depends on your service model: with virtual machines the operating system is yours, with managed services it is the provider's.
Split your patching into two clocks. Anything reachable from the internet gets days. Anything internal gets your normal cycle. Trying to patch everything at the same speed means the urgent work waits behind the routine work.
First step: list what is reachable from the internet, then check when each item was last patched.
9. Segment your cloud networks
Segmentation decides how far an intruder gets after the first success. Flat networks let one compromised workload reach everything. Segmented networks make them stop and work for each step, which buys you detection time.
Separate production from development. Separate the systems holding sensitive data from the ones that do not. Use security groups and private subnets rather than relying on one perimeter.
First step: check whether your development environment can reach production data. It often can.
10. Write the incident playbook before you need it
The worst time to work out who calls the lawyer is during the breach. A playbook does not need to be long. It needs to name people and steps.
Cover these: who declares an incident, who can shut down a compromised account, who talks to customers, who talks to the regulator, and where the backups are. Two pages is enough for most companies. Print it, because you may not be able to log in.
First step: write down who has authority to disable a production account at 2am.
The ladder above shows the same ten practices against the evidence that puts each one at its height.
