Cloud security starts with one idea: when you move data and applications to a provider, you hand over some control but keep the accountability. Learn the split of responsibilities first, then secure identities, data, configuration and logging in that order, because most cloud failures sit there.
What changes when you move to the cloud?
NIST's guide to public cloud security, SP 800-144, describes the shift in a sentence: data and services move from inside the organization to outside it. The same document says cloud computing means different things to different people, and lists common traits such as on-demand scalability, pooled resources and metered services reachable from nearly anywhere.
That last trait is the security point. A server in your own building is reachable through your network. A cloud resource is reachable through the internet unless you decide otherwise, so a single wrong setting can expose it.
The publication dates from December 2011, so it does not cover modern services. It remains useful for the questions it asks you to put to a provider before you outsource, and for its framing of what you give up.
Who is responsible for what?
Providers describe a shared responsibility model, and the exact line depends on the service type. In general, the provider secures the physical facility and the underlying platform. You secure what you put on it: identities, data, configuration and your own code. The more of the stack you manage yourself, the more of it is yours to protect.
Read the provider's own documentation for the service you use, and write the split down. Many incidents begin with a team that assumed the provider handled something it did not.
What should you secure first?
Work in this order, because each step limits damage from the next.
- Identity. Strong sign in with multi-factor authentication for people, and tightly scoped credentials for machines. Give every identity the minimum it needs.
- Data. Know what you store, where it lives, and who can read it. Encrypt it, and keep keys under separate control.
- Configuration. Public storage, open network rules and default settings are common causes of exposure. Review them on a schedule.
- Logging. Turn on audit logs before you need them, and send them somewhere an attacker with a stolen credential cannot erase them.
- Inventory. List every account, region and service in use, including the ones a team started without telling anyone.
A constructed example
A small team stores customer exports in a storage bucket for a partner to download. To make it simple, someone sets the bucket to public read. Months later the link appears in a search index. The provider's platform worked as designed. The mistake sat in the customer's part of the model. A scheduled review of public resources, or a rule that blocks public buckets by default, would have caught it.
How to check or apply this
- Write down the shared responsibility split for each cloud service you use.
- List all cloud accounts and the people and services that can reach them.
- Require multi-factor authentication for every human login and remove long-lived keys where you can.
- Search for publicly reachable storage and open inbound rules, and close what has no reason to be open.
- Enable audit logging in every account and store the logs separately.
- Repeat the review every month and after any large change.
For the application layer that runs on top of this, Safeguard offers dependency scanning with reachability analysis, and policies that can gate a pull request. It does not replace the cloud configuration work above.
Quick check
Is the cloud provider responsible for my data security?
Partly. The provider protects the platform. You are responsible for how you configure access to your data and who can reach it.
Is a 2011 NIST document still worth reading?
For its questions and framing, yes. For specific services and controls, use current provider and standards documentation.
Sources
Last reviewed: 18 October 2026.
