Nobody runs a server room any more, and almost nobody decided to stop. It happened one purchase at a time: a payroll system that was only ever offered as a subscription, a developer who needed a test environment on a Tuesday, a marketing team that signed up for something with a company credit card. Somewhere in the middle of that, the company's data ended up in six data centers it does not own, reached through logins it does not fully control, and the question of who is protecting it became genuinely hard to answer.
Cloud security is the name for the answer.
What Is Cloud Security?
Start with what the cloud is, because the security follows from it. NIST's definition of cloud computing in SP 800-145 calls it a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction, and says the model is composed of five essential characteristics, three service models and four deployment models. Every clause in that sentence creates a security problem. Shared means somebody else is on the same hardware. On-demand and rapidly provisioned mean things appear without a purchase order. Minimal management effort means the safety rails you used to build by hand are now settings in a console, and settings can be wrong.
Cloud security, then, is a domain of security practice rather than a product. It covers the identities that can reach your cloud accounts, the configuration of the services inside them, the data those services hold, the network paths between them, the workloads and containers running on them, and the audit logs that record what happened. It sits inside the wider field of cyber security alongside network security and endpoint security, and it exists as a separate discipline for one reason: in the cloud, the control plane is an API, and an attacker with a valid credential does not need to touch a single machine.
The phrase covers three quite different situations that people describe with the same words. Infrastructure you rent and run yourself, such as virtual machines and storage in AWS, Azure or Google Cloud. Platforms you build on, where the operating system is somebody else's problem. And software you simply use, from Microsoft 365 to Salesforce to whichever tool the finance team found. The security work in each is different, and the confusion between them is where most bad advice starts.
What Cloud Security Covers and What It Does Not
A domain page earns its keep by drawing edges, so here are both sides of this one.
Inside cloud security: identity and access management for cloud accounts and SaaS tenants, service configuration and the drift it accumulates, storage and database exposure, encryption and key management for data at rest and in transit, cloud network design such as virtual private clouds and segmentation, workload and container protection, secrets in code and pipelines, cloud audit logging, and the posture and entitlement tooling that watches all of it.
Outside cloud security, and this is the part vendors blur: the physical data center, the power, the hardware and the hypervisor, all of which belong to the provider and are covered by its own audits. The laptop your administrator logs in from is endpoint detection and response territory, not cloud security, even though a compromise there ends in your cloud console. The office network and its perimeter still need a firewall. The person who approves a payment request because the email looked right is a training problem. Cloud security also does not cover whether the provider stays in business or keeps a region running.
The boundary matters because buyers get sold across it. A proposal for cloud security services that quietly includes endpoint agents and a firewall refresh is not wrong, but it is three purchases wearing one label, and the parts have very different price behavior.
How the Shared Responsibility Model Works
Every major provider publishes a version of the same diagram. AWS states it plainly: it is responsible for security "of the Cloud" while the customer is responsible for security "in the Cloud", meaning AWS protects the infrastructure of hardware, software, networking and facilities, and the customer owns what it deploys on top. The same page splits controls into three kinds: inherited controls the customer gets entirely from AWS, such as physical and environmental controls; shared controls, where patch management and configuration management apply in both places in different contexts; and customer-specific controls that are yours alone.
Where the line falls depends on which service model you bought.
| Service model | The provider secures | You secure |
|---|---|---|
| Infrastructure as a service | Facilities, hardware, network, virtualization | Guest operating system, patching, applications, data, identity, network rules, configuration |
| Platform as a service | Everything above plus the operating system and runtime | Your application code, its dependencies, data, identity, service configuration |
| Software as a service | Almost the entire stack | Who has an account, what those accounts can do, what data you put in, sharing settings, connected third-party apps |
Read the SaaS row again, because it is the one that surprises people. The provider running the application does not decide who in your company has an administrator role, whether those accounts have multi-factor authentication, which external app you granted a permanent token to, or whether a departing employee still has access. Those are your controls in someone else's product, and they are the exact controls attackers went after through 2026, usually by calling a help desk and asking politely. That is social engineering applied to a cloud tenant rather than a hack of the cloud itself.
Why Cloud Security Is Different From Traditional Security
Four differences do most of the work, and none of them is about the technology being newer.
There is no perimeter to defend. On-premises security assumed a boundary with a firewall on it. A cloud account has no inside. It has an API endpoint reachable from anywhere on the internet, and whether a request succeeds is decided entirely by whether the credential presenting it is allowed. Identity is the perimeter now.
The blast radius of a setting is enormous. In a data center, a mistake exposed one server. In the cloud, a policy attached to the wrong role can expose every object in a storage account at once, instantly, to everyone, and the change takes one click and leaves the environment looking normal.
Assets appear and vanish. Containers live for minutes. A test environment spun up for a demo can sit forgotten for two years holding a copy of production data. Traditional inventory processes assume things stay still long enough to be counted.
Nobody is fully sure what they own. Departments buy SaaS directly, developers connect services with API keys, and integrations grant each other standing access. The result is real: IBM's 2026 Cost of a Data Breach report found that public cloud was the most expensive place for breached data to live, at an average USD 5.38 million against USD 4.56 million for data held on premises, and that a public cloud breach took 184 days to identify and another 67 to contain, 251 days in total. The same study found 53 percent of breached organizations had not encrypted sensitive data at rest and in motion, which is a decision, not an accident, since encryption in cloud storage is usually a checkbox.
What Are the Main Cloud Security Risks?
The Cloud Security Alliance surveyed over 500 industry experts for its Top Threats to Cloud Computing 2024 and published the eleven they named. The order tells you where to look first: misconfiguration and inadequate change control came first, identity and access management second, and insecure interfaces and APIs third. Notice what is not at the top. Not a flaw in the provider's platform, not an exotic zero day, not a shared-tenancy escape. The top three are all things the customer configures.
Misconfiguration. Storage left open, a database with a public endpoint, logging switched off to save money, default settings never reviewed. These are not sophisticated failures and they are found by anyone scanning the internet, usually within hours of the mistake.
Identity and access. Roles granted more permission than the job needs, service accounts with keys that never rotate, administrator accounts without multi-factor authentication, and joiners and leavers handled by memory. Cloud logins are also a favorite target for credential stuffing, because the same password protects the console and the email account.
Insecure interfaces and APIs. Cloud services are operated through APIs, so an exposed API key is not a hint, it is the front door. Keys committed to a repository, embedded in a mobile app or pasted into a support ticket all end the same way.
Two more belong on any honest list. Third-party and vendor exposure, because a SaaS tool you approved has its own logins, its own subcontractors and its own breach risk, which is what vendor risk management exists to size. And insider threat, which in the cloud is less about malice than about a well-meaning employee sharing a folder with a link that says anyone with the link.
How a Cloud Breach Actually Happens
Descriptions of cloud risk stay abstract, so here is the sequence that repeats. It rarely starts with a technical exploit and it almost never touches the provider.
- A valid credential is obtainedA phished session token, a help desk call that reset an MFA factor, or an API key found in a public repository
- The attacker logs in and looks aroundAPI calls that list users, roles, storage and connected apps. To the platform this is normal administrative traffic
- Permissions are widenedA new service account, an added role, or a token granted to an app that already had broad access, so the original credential no longer matters
- Data is copied outBulk export through the same API, often to cloud storage the attacker controls, at speeds no human workflow would produce
- Extortion, then publicationA demand arrives weeks later, and the data appears on a leak site whether or not it is paid
- Detection, if logging was onAnomalous API volume, a role created outside change control, or a login from an unusual place. All three are visible only if cloud audit logs are collected and read
What Are the Types of Cloud Security Controls?
Controls stack. Each layer assumes the one outside it will eventually fail.
In practice that stack turns into a short list of purchases and habits. Multi-factor authentication on every cloud and SaaS account, with phishing-resistant factors for administrators, since an SMS code does not survive a convincing phone call. Least privilege, reviewed on a schedule, which is the operational half of zero trust rather than a product you install. Cloud security posture management, which reads your configuration through the provider's API and flags what drifted, and which is the one tool category with no on-premises equivalent. Log collection into a SIEM or a managed service, because cloud audit logs are useless if nobody is subscribed to them. Vulnerability scanning of the images and dependencies you deploy, run in the pipeline rather than after release. And encryption with keys you control for anything regulated.
Cloud Security and Compliance
Regulators did not write separate rules for the cloud. They wrote rules about data, and the data followed you there.
The practical consequence is a document most companies do not have: a written statement of which requirements the provider satisfies, which you satisfy, and which are shared. Auditors call this a responsibility matrix. Building it takes an afternoon and it prevents the most common audit finding in cloud environments, which is two parties each assuming the other handled a control.
Cloud Security Best Practices
CISA and NSA published five joint cybersecurity information sheets on cloud security, covering identity and access management, key management, network segmentation and encryption, securing data in the cloud, and risk from managed service providers. That set is a better starting point than a vendor's pillar list, because it is free of product and it names the five things governments concluded matter most. What follows is that guidance turned into an order of operations.
When to Hire a Cloud Security Firm
The honest test is not company size. It is whether anyone employed here can look at a permissions policy and say confidently whether it is too broad. Plenty of capable IT teams cannot, because cloud identity is its own specialty and it changes quarterly.
Key takeaways
- Cloud security protects data, applications and infrastructure running in cloud services. It is a domain of practice, not a product category.
- The shared responsibility model splits the work: providers secure the platform, customers secure identities, configuration, data and access. The split shifts by service model, and the SaaS row is the one people misread.
- Misconfiguration, identity and access management, and insecure APIs are the top three cloud threats named by the Cloud Security Alliance's survey of over 500 experts. All three sit on the customer's side.
- Public cloud was the most expensive place for breached data in IBM's 2026 study, at USD 5.38 million on average, and those breaches took 251 days to identify and contain.
- A cloud breach usually starts with a valid credential and proceeds entirely through ordinary API calls, which is why cloud audit logging decides whether it is caught.
- A provider's compliance report covers the provider. Your customers are asking about your half, and a written responsibility matrix is what settles the argument.
- Identity controls outrank everything else. MFA everywhere, least privilege, and no permanent administrative roles is the first day of any cloud program.
Common questions
What is cloud security in simple terms?
It is protecting the data and systems you keep in someone else's data center. The company running that data center secures the building, the machines and the software underneath. You secure who can log in, what they are allowed to do, how the services are configured and what happens to the data. Cloud security is the practice of doing your part well.
What are the four areas of cloud security?
There is no official four, despite how often the number appears. The grouping that holds up in practice is identity and access, configuration and posture, data protection including encryption and keys, and monitoring and response. Network controls and workload protection are usually treated as parts of the second and fourth. Any list that presents its categories as canonical is presenting a vendor's product lines.
Is the cloud more secure than on-premises?
For the layers the provider owns, almost always. Hyperscalers run physical security, hardware replacement and hypervisor patching better than a mid-sized company can. For the layers you own it is harder, because everything is reachable from the internet and one setting can expose everything. IBM's 2026 data shows breached data in public cloud costing more on average than data held on premises, which reflects that split rather than a weakness in the platforms.
Who is responsible for security in the cloud?
Both parties, in defined portions. The provider is responsible for security of the cloud, meaning the infrastructure it operates. The customer is responsible for security in the cloud, meaning identities, configuration, data and access. Some controls, such as patching, are shared and apply differently at each layer. Write the split down as a responsibility matrix, because assuming the other side has a control is the most common cause of a gap.
What is the biggest cloud security risk?
Misconfiguration, by the Cloud Security Alliance's ranking and by what actually turns up in assessments. Public storage, over-broad permissions, disabled logging and unchanged defaults account for a large share of exposures, and none of them requires an attacker to do anything clever. Identity failures sit immediately behind, and the two combine constantly.
What is CSPM?
Cloud security posture management. It reads your cloud configuration through the provider's API and compares it against a baseline, then flags what is exposed or has drifted. It is the closest thing to a cloud-native scanner and it has no real on-premises equivalent, because on-premises there was no API describing the whole estate. It finds problems; it does not fix them or decide which ones matter.
What is a CASB?
A cloud access security broker sits between users and cloud applications to enforce policy: which SaaS tools may be used, what data can be uploaded, and what unmanaged devices are allowed to do. It grew up to solve shadow SaaS, and its functions are increasingly bundled into broader access platforms rather than bought alone.
Does cloud security cover SaaS applications like Microsoft 365?
Yes, and that is where most incidents now happen. Your responsibility in a SaaS tenant is smaller than in rented infrastructure but it is not zero: account provisioning, administrator roles, MFA, sharing settings, retention and every third-party app you have granted a token to. The vendor secures the application. Nobody but you decides who is in it.
Does the cloud provider back up my data?
Generally not in the way people assume. Providers protect against their own hardware failure, not against your deletion, a ransomware event in your tenant, or an administrator making a mistake. Retention windows in SaaS tools are often measured in days. Treat backup as your responsibility and test a restore, because the first time anyone learns the window was thirty days is usually on day thirty-one.
What certifications matter for cloud security work?
For practitioners, the vendor certifications from AWS, Azure and Google Cloud carry the most weight for hands-on roles, with the Cloud Security Alliance's CCSK and ISC2's CCSP as the platform-neutral options. For firms rather than people, what matters is a published attestation covering their own operations and named experience in your cloud platform, since a firm certified on one provider is not automatically competent on another.
How much does cloud security cost?
There is no reliable published figure, and any single number should be treated with suspicion. The variables that move it are the number of cloud accounts and SaaS tenants, whether you are buying a one-time assessment or continuous monitoring, and whether the provider is permitted to change things or only to report them. Ask for pricing per account or per workload, and ask what happens to the price when the environment grows.
On this page
- What Is Cloud Security?
- What Cloud Security Covers and What It Does Not
- How the Shared Responsibility Model Works
- Why Cloud Security Is Different From Traditional Security
- What Are the Main Cloud Security Risks?
- How a Cloud Breach Actually Happens
- What Are the Types of Cloud Security Controls?
- Cloud Security and Compliance
- Cloud Security Best Practices
- When to Hire a Cloud Security Firm
Daniel Reyes
Daniel Reyes is a CISSP who spent twelve years in security operations, most recently leading a detection and response team for a mid-sized healthcare group in Texas. He reviews every resource and breach report on Cyber Security Firms for technical accuracy before it publishes.
Most of the people he has trained arrived having been told too much: a dozen acronyms, six vendors, and no clear idea which risk was theirs. His approach is to explain what an attack actually does before naming the tool that stops it, on the basis that most breaches start with something a reader could have recognised.