Why Cloud Security Matters
The shift to cloud computing has fundamentally changed how organisations store, process, and access data. While cloud providers invest billions in securing their infrastructure, the shared responsibility model means that organisations cannot rely on providers alone to keep their data safe. Security in the cloud is a partnership, and misunderstanding the boundaries of that partnership is one of the most common causes of breaches.
According to IBM's Cost of a Data Breach Report, 82% of data breaches involve data stored in the cloud — whether public, private, or hybrid environments. The UK National Cyber Security Centre (NCSC) has published 14 cloud security principles that serve as the gold standard for evaluating and configuring cloud services. Despite this guidance, 45% of cloud breaches are caused by misconfiguration, not sophisticated attacks. Simple errors such as leaving storage buckets publicly accessible, failing to enable encryption, or granting overly permissive access rights account for nearly half of all incidents.
For UK organisations, the stakes are particularly high. GDPR enforcement, sector-specific regulations, and increasing supply chain scrutiny mean that a cloud security failure can result in regulatory fines, reputational damage, and loss of contracts. Understanding the fundamentals is the essential first step to building a secure cloud posture.
The Shared Responsibility Model
The shared responsibility model is the foundational concept of cloud security. Every major cloud provider — AWS, Azure, and GCP — operates under this model, which divides security obligations between the cloud provider and the customer. The provider is responsible for securing the underlying infrastructure (the "security of the cloud"), while the customer is responsible for securing what they put in the cloud (the "security in the cloud").
The exact division of responsibility shifts depending on the service model you use. In Infrastructure as a Service (IaaS), the customer takes on the most responsibility, managing everything from the operating system upwards. In Platform as a Service (PaaS), responsibility is shared more evenly, with the provider managing the runtime and operating system. In Software as a Service (SaaS), the provider handles almost everything, but the customer retains responsibility for data, identity, and access management.
Shared Responsibility by Service Model
| Responsibility Area | IaaS | PaaS | SaaS |
|---|---|---|---|
| Physical Security | Provider | Provider | Provider |
| Network Infrastructure | Provider | Provider | Provider |
| OS Patching | Customer | Shared | Provider |
| Application Security | Customer | Customer | Provider |
| Data Classification | Customer | Customer | Customer |
| Identity Management | Customer | Customer | Customer |
| Encryption Keys | Customer | Customer | Customer |
Source: AWS, Azure, and GCP Shared Responsibility Model Documentation
You Can Outsource Operations, but Not Responsibility
A common misconception is that moving to the cloud transfers security responsibility to the provider. In reality, you can outsource the operation of your infrastructure, but you cannot outsource the accountability for protecting your data. If a misconfiguration in your cloud environment leads to a breach, your organisation — not the cloud provider — bears the regulatory and legal consequences. Understanding exactly where your responsibilities begin and end for each service you consume is the single most important step in cloud security.
Identity and Access Management (IAM)
Identity and Access Management is widely regarded as the most critical security control in any cloud environment. If an attacker gains access to a privileged identity, they can bypass virtually every other control in place. All three major cloud providers offer comprehensive IAM services — AWS IAM, Azure Active Directory (now Microsoft Entra ID), and GCP IAM — but the effectiveness of these tools depends entirely on how they are configured and enforced.
The core principle behind IAM is least privilege: every user, service, and application should have only the minimum permissions required to perform its function. Combined with multi-factor authentication, role-based access control, and continuous audit logging, a well-implemented IAM strategy dramatically reduces your attack surface and limits the blast radius of any compromise.
IAM Best Practices Across Cloud Providers
| Best Practice | Why It Matters | Cloud Implementation |
|---|---|---|
| Enforce MFA Everywhere | Compromised credentials are the leading cause of cloud breaches; MFA blocks 99.9% of automated attacks | AWS IAM MFA, Azure AD Conditional Access, GCP 2-Step Verification |
| Use Role-Based Access Control | RBAC simplifies permission management and ensures consistent access policies across teams | AWS IAM Roles, Azure RBAC, GCP IAM Roles |
| Implement Least Privilege | Limits the blast radius of a compromised account by granting only the permissions needed for each task | AWS IAM Access Analyzer, Azure PIM, GCP IAM Recommender |
| Use Service Accounts with Minimal Permissions | Applications and automation should use dedicated service accounts, never human credentials | AWS IAM Roles for Services, Azure Managed Identities, GCP Service Accounts |
| Enable Audit Logging | Continuous logging provides visibility into who accessed what and when, essential for incident response | AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs |
| Rotate Credentials Regularly | Limits the window of exposure if credentials are leaked or compromised | AWS Secrets Manager, Azure Key Vault, GCP Secret Manager |
| Use SSO Where Possible | Centralises authentication, reduces password fatigue, and simplifies offboarding | AWS SSO (IAM Identity Center), Azure AD SSO, GCP Cloud Identity |
| Implement Just-in-Time Access | Grants elevated permissions only when needed and automatically revokes them after a set period | AWS IAM Session Policies, Azure AD PIM, GCP IAM Conditions |
Source: CIS Benchmarks for AWS, Azure, and GCP; NCSC Cloud Security Guidance
IAM Is Your Most Critical Cloud Security Control
Security experts consistently rank identity and access management as the single most important control in cloud environments. A misconfigured IAM policy can expose your entire cloud estate to unauthorised access, regardless of how well you have implemented encryption, network controls, or monitoring. Invest the time to get IAM right — review policies regularly, enforce MFA without exception, and use automated tools to detect overly permissive access before it becomes a vulnerability.
Encryption: At Rest and In Transit
Encryption is a fundamental defence mechanism that protects data from unauthorised access, even if other security controls fail. In a cloud environment, encryption must be applied at two critical stages: when data is stored (at rest) and when data is being transmitted between systems (in transit). All three major providers offer robust encryption capabilities, but the level of control you have over encryption keys varies by configuration.
The key decision for most organisations is whether to use provider-managed keys or customer-managed keys. Provider-managed encryption is the simplest option and is often enabled by default, but it means the cloud provider controls the encryption keys. Customer-managed keys give your organisation full control over the key lifecycle, which is often required for regulatory compliance or when handling highly sensitive data.
Encryption Controls Across Cloud Providers
| Encryption Type | What It Protects | Implementation | Default Behaviour |
|---|---|---|---|
| Server-Side Encryption at Rest | Data stored in cloud storage, databases, and disks | AWS SSE-S3/SSE-KMS, Azure Storage Service Encryption, GCP Default Encryption | Enabled by default on all three providers with provider-managed keys |
| Customer-Managed Keys | Data at rest with keys controlled entirely by the customer | AWS KMS CMK, Azure Key Vault, GCP Cloud KMS | Must be explicitly configured; customer manages key rotation and access policies |
| Provider-Managed Keys | Data at rest with keys managed by the cloud provider | Automatic server-side encryption on all providers | Default on all providers; zero configuration required |
| Encryption in Transit (TLS 1.2+) | Data moving between client and cloud services, and between cloud services | Enforced via HTTPS endpoints, load balancer TLS termination, and service-to-service encryption | TLS 1.2 minimum enforced by default on most services |
| Certificate Management | TLS certificates for custom domains and internal services | AWS Certificate Manager, Azure App Service Certificates, GCP Certificate Manager | Managed certificates available for common services; custom domains require configuration |
| Key Management Services | Centralised management, rotation, and auditing of encryption keys | AWS KMS, Azure Key Vault, GCP Cloud KMS | Must be explicitly provisioned; supports automatic key rotation |
| Client-Side Encryption | Data encrypted before it leaves the customer environment; provider never sees plaintext | AWS Encryption SDK, Azure Client-Side Encryption, GCP Tink Library | Never enabled by default; requires application-level implementation |
Source: AWS, Azure, and GCP Encryption Documentation; NCSC Cloud Security Principle 2
Customer-Managed Keys vs Provider-Managed Keys
For most workloads, provider-managed encryption offers a strong baseline and requires no additional configuration. However, if your organisation operates under strict regulatory requirements — such as financial services regulation, healthcare data standards, or UK government classifications — you may need customer-managed keys (CMKs). CMKs give you full control over key creation, rotation, and revocation, and ensure that even the cloud provider cannot access your data without your explicit authorisation. The trade-off is increased operational complexity and the responsibility of managing key availability and backup.
Network Security in the Cloud
Cloud network security operates on the principle of defence in depth, using multiple layers of controls to protect workloads from unauthorised access. Unlike traditional on-premises environments where the network perimeter is well-defined, cloud environments require a different approach. Every resource must be individually secured, and the network must be architected to minimise the attack surface.
All three major cloud providers offer a comprehensive suite of network security tools, from virtual private clouds and security groups to web application firewalls and DDoS protection services. The key is understanding when to use each control and how they work together to create a layered defence.
Network Security Controls Across Cloud Providers
| Control | What It Does | When to Use |
|---|---|---|
| VPC / VNet | Creates a logically isolated virtual network within the cloud, providing full control over IP addressing, subnets, and routing | Always — every cloud deployment should run inside a VPC or VNet; never deploy resources on the default network |
| Security Groups | Instance-level stateful firewall rules that control inbound and outbound traffic to individual resources | Apply to every instance; define the minimum required ports and source IP ranges; deny all by default |
| NACLs / NSGs | Subnet-level stateless access control lists that provide an additional layer of traffic filtering | Use as a coarse-grained outer perimeter at the subnet level, complementing instance-level security groups |
| Private Endpoints | Allow access to cloud services without exposing traffic to the public internet; traffic stays on the provider backbone | Use for all connections to storage, databases, and managed services; eliminates public internet exposure |
| WAF (Web Application Firewall) | Inspects HTTP/HTTPS traffic and blocks common web exploits including SQL injection, XSS, and OWASP Top 10 threats | Place in front of all public-facing web applications and APIs; configure managed rule sets for OWASP protection |
| DDoS Protection | Absorbs and mitigates volumetric, protocol, and application-layer distributed denial-of-service attacks | Enable on all internet-facing resources; AWS Shield, Azure DDoS Protection, and GCP Cloud Armor all offer tiered protection |
Source: AWS VPC Documentation, Azure Networking, GCP VPC Documentation; CIS Benchmarks
Public vs Private Subnets
One of the most important architectural decisions in cloud networking is the separation of public and private subnets. Public subnets contain resources that need to be directly accessible from the internet, such as load balancers and bastion hosts. Private subnets contain resources that should never be directly reachable from the internet, such as application servers, databases, and internal services. By placing your sensitive workloads in private subnets and routing all external traffic through load balancers and NAT gateways, you significantly reduce your attack surface and limit the impact of a compromised component.
Compliance Frameworks and UK NCSC Guidance
Cloud security does not exist in a vacuum — it must align with relevant compliance frameworks and regulatory requirements. For UK organisations, the NCSC's 14 Cloud Security Principles provide the most authoritative guidance for evaluating and configuring cloud services. Beyond NCSC, a range of international standards and certifications help organisations demonstrate their security posture to customers, regulators, and partners.
All three major cloud providers maintain extensive compliance programmes and hold certifications across multiple frameworks. However, it is important to understand that the provider's compliance certification does not automatically extend to your workloads. You must configure your cloud environment in accordance with each framework's requirements and maintain evidence of compliance for your specific deployments.
Key Compliance Frameworks for Cloud Security
| Framework | Description | Relevance to Cloud | Provider Support |
|---|---|---|---|
| ISO 27001 | International standard for information security management systems (ISMS) | Provides a structured approach to managing cloud security risks; widely recognised by UK and international clients | All three providers are ISO 27001 certified; compliance tools available to help customers align |
| Cyber Essentials | UK government-backed baseline cybersecurity certification | Mandatory for UK government contracts; cloud environments must meet the 5 technical controls | Provider infrastructure meets requirements; customers must configure their workloads accordingly |
| SOC 2 | Service Organisation Controls for security, availability, processing integrity, confidentiality, and privacy | Demonstrates that cloud services meet trust service criteria; commonly required by enterprise customers | All three providers hold SOC 2 Type II reports; available under NDA |
| NCSC 14 Cloud Security Principles | UK government guidance covering 14 areas from data in transit to supply chain security | The gold standard for UK organisations evaluating cloud services; covers technical and governance controls | AWS, Azure, and GCP publish responses to all 14 principles in their compliance documentation |
| GDPR | EU and UK regulation governing the processing and protection of personal data | Cloud processing must comply with data protection principles; data residency, encryption, and access controls are key | All providers offer EU/UK data residency options, data processing agreements, and GDPR compliance tools |
| PCI DSS | Payment Card Industry Data Security Standard for organisations handling payment card data | Cloud environments processing card data must meet all applicable PCI DSS requirements | All three providers are PCI DSS Level 1 certified; shared responsibility applies to customer workloads |
Source: NCSC Cloud Security Guidance, ISO, PCI Security Standards Council, ICO GDPR Guidance
The NCSC 14 Principles: The Gold Standard for UK Cloud Security
The NCSC's 14 Cloud Security Principles are the definitive framework for UK organisations evaluating and securing cloud services. They cover data in transit, asset protection, separation between customers, governance, operational security, personnel security, secure development, supply chain security, secure user management, identity and authentication, external interfaces, service administration, audit information, and secure use of the service. Each principle provides specific questions organisations should ask their cloud provider and actions they should take to secure their own workloads. Any UK organisation using cloud services should use these 14 principles as the foundation of their cloud security assessment.
Master Cloud Computing
Cloud security is just one pillar of cloud computing expertise. Our accredited Cloud Computing course covers architecture, migration, security, cost optimisation, and multi-cloud strategy — giving you the skills to design, deploy, and secure cloud environments with confidence.
Explore Our Cloud Computing Course