Moving to the cloud does not move your security problems to someone else. It changes which ones are yours. Many small teams assume the provider “handles security,” then discover after an incident that the part that failed was the part they were responsible for. This guide explains the split and the basics that stay with you.

The Shared Responsibility Model

Every major cloud provider describes some version of a shared responsibility model. The provider secures the underlying infrastructure: the physical data centers, the hardware, and the core services they operate. You secure what you put into the cloud and how you configure it: your accounts, your data, your settings and your users.

How the line falls depends on the service type. With infrastructure services, where you rent virtual machines, you manage the operating system, patching and applications. With platform services, the provider manages more of the stack and you manage your applications and data. With software-as-a-service tools, the provider runs nearly everything, but you still control who has access and what they share. Always read the provider’s current documentation for the exact division, because it differs between services.

The practical rule: identity, access, configuration and data are almost always your job.

The Five Areas That Stay With You

Accounts and identity

The administrator account for your cloud environment is the most valuable credential you own. Protect it with multi-factor authentication, do not use it for daily work, and keep the number of people with administrative rights small. Prefer named individual accounts over shared logins so actions can be traced.

Configuration

Most cloud breaches trace back to configuration mistakes rather than clever attacks: storage open to the public, management ports exposed to the internet, or overly broad permissions. Review defaults before relying on them, and revisit settings after any change.

Data

Know what you store, where, and how sensitive it is. Use encryption options the provider offers, both for stored data and data in transit, and understand who holds the keys. Back up data you cannot afford to lose, since provider durability is not the same as protection against your own deletion or an attacker’s.

Network exposure

Expose only what must be reachable. Administrative interfaces such as remote desktop or SSH should not be open to the whole internet. Use private networking, a VPN or the provider’s secure access features instead.

Logging and visibility

Turn on activity logging for your account so you can answer “who did what and when.” Logs you did not enable cannot be recovered after the fact. Send them somewhere that an attacker with a stolen account would find hard to erase.

Who Owns What: A Quick Reference

Area	Provider typically handles	You typically handle
Physical data centers	Facilities, hardware, power	Nothing directly
Core service operation	Availability of the platform itself	Choosing and configuring services
Operating systems (virtual machines)	Underlying host	Guest patching and hardening
User accounts and permissions	Providing the tools	Setting, reviewing and removing access
Data and its classification	Storage platform	What you store and how it is shared
Logging	Making logs available	Enabling, retaining and reviewing them

The boundaries shift by service, so treat this as orientation rather than a contract.

A Realistic Example

Consider a hypothetical twelve-person software consultancy that moves its project files and test servers to a cloud provider. The team assumes the provider’s reputation covers them. A review shows a test server whose remote administration port is reachable from anywhere, a storage container shared by link with no expiry, and three former contractors who still have active accounts. None of these is the provider’s fault; all are configuration and access decisions that belong to the customer. The team closes the exposed port behind a VPN, replaces the open link with named access, removes the old accounts, and switches on activity logging. The whole cleanup takes a few hours, and the main lesson is that the review should have happened at setup rather than months later.

Habits That Keep You Safe Over Time

• Use separate environments. Keep test and production apart so a casual experiment cannot touch real data.
• Tag and track resources. Forgotten servers and storage are classic sources of cost and risk. Label owners so unowned resources can be found and removed.
• Apply least privilege. Start with minimal permissions and add only what is needed.
• Review regularly. Cloud environments change quickly, so schedule recurring checks of access, exposure and logs.
• Use built-in tooling. Providers offer configuration checkers and recommendations. Look up what your provider currently offers rather than assuming.

When to Seek Help

If you handle regulated data such as health or payment information, requirements for where data lives and how it is protected vary by jurisdiction and industry. Consult a qualified professional rather than relying on general articles, including this one.

Frequently Asked Questions

Is the cloud less secure than running our own servers? Not inherently. Providers often operate with strong physical and platform protections that small teams could not match. The risk comes from misconfiguration and weak access control on the customer side, which exist in on-premises setups too.

Does the provider back up our data automatically? Not necessarily in the way you need. Providers protect the durability of their platform, but recovery from accidental deletion, corruption or ransomware is usually your responsibility. Check the current documentation for your service.

What is the first thing to secure in a new cloud account? The root or owner administrator account. Enable multi-factor authentication, stop using it for routine tasks, and create separate accounts with limited rights for daily work.

Do small teams need a dedicated cloud security tool? Often the free or built-in features of the provider are enough to begin with. Add specialized tools when your environment grows or when a specific need appears.

How can we tell if something in our cloud account is misconfigured? Use the provider’s built-in configuration review features, compare settings against a checklist, and test from outside, for example by checking whether a storage link opens without signing in.

Next Step

Log in to your main cloud account today and verify three things: multi-factor authentication on the owner account, a current list of everyone with administrative access, and whether activity logging is switched on.