What is cloud security? Shared responsibility and key pillars

The starting point: shared responsibility

Every serious discussion of cloud security begins with the shared responsibility model, because it defines who is accountable for what. The provider is responsible for the security of the cloud — the physical data centres, the underlying hardware, and the virtualisation layer that isolates customers from each other. You are responsible for security in the cloud — how you configure identity, access, networking and data protection on top of that infrastructure. Our shared responsibility model explained article covers exactly where that line sits and how it shifts depending on the type of service you use.

The key pillars, in a line each

Cloud security is made up of several distinct disciplines that work together rather than one single control:

• Identity and access management — controlling who can do what, following least privilege, so access matches genuine need. See our what is identity and access management explainer.
• Encryption — protecting data at rest and in transit so it is unreadable without the right keys, even if it is intercepted or exposed. See our what is encryption in the cloud explainer.
• Network security — controlling what traffic can reach what, using tools such as firewalls to filter unwanted requests. See our what is a firewall explainer.
• Monitoring and threat detection — continuously watching for unusual or malicious activity so it can be caught early rather than discovered after the fact. See our what is observability explainer.
• Compliance and governance — meeting the regulatory and organisational standards that apply to your data and industry, and being able to demonstrate that you do.
• Zero trust — the principle that no request is trusted by default, inside the network or out, and every access attempt is verified explicitly. See our what is zero trust security explainer.

The most common real-world failures

In practice, cloud security incidents tend to trace back to a small, repeating set of causes rather than exotic attacks: misconfiguration of settings that were left at an insecure default, over-permissive access granted for convenience and never tightened, storage left exposed to the public internet when it should not have been, and systems left unpatched after a known fix was already available. None of these are failures of the underlying cloud platform — they are failures of how the platform was configured and maintained.

Why it matters, and why the responsibility question matters most

The reason the shared responsibility model gets so much emphasis is that most cloud security incidents sit on the customer side of that line: a configuration choice, a permission left too broad, a patch not applied. That is a genuinely reassuring fact once it is understood correctly — it means cloud security is largely within your control, and it is why the pillars above are learnable practices rather than mysteries reserved for specialists. It does not mean the cloud is inherently insecure, nor that providers bear no responsibility; it means the highest-leverage security work most organisations can do is getting their own configuration right.

Careers and certification

Cloud security is one of the more in-demand specialisms in cloud computing, and certifications reflect that directly. The AWS Certified Security – Specialty exam goes deep into identity, encryption, network security, monitoring and incident response on AWS, building on the foundational security concepts every AWS Certified Cloud Practitioner candidate first meets. Vendor-neutral certifications such as ISC2 Certified in Cybersecurity cover the same pillars from a broader, non-cloud-specific angle. Our cloud security engineer career path guide covers how this area of specialism tends to develop in practice, from foundational study through to a security-focused role.