Cloud Security: The Complete Guide

Cloud security encompasses the measures, processes, and tools that protect data, applications, and infrastructure in the cloud: from identities and access rights to networking, encryption, logging, and workload security. It differs from traditional security in that there is no longer a fixed perimeter. Resources come and go via code, and any identity with too many privileges is a point of entry.

Organizations are investing heavily in it. Gartner expects global spending on information security to grow by 12.2% to $246.2 billion in 2026. Cloud security is growing the fastest: by 28.8% to $17.1 billion.

Zero trust assumes that no user, device, or workload can be trusted by default, not even within the organization's own network. Three principles:

• Explicitly verify each access attempt based on identity, device, and context;
• Grant the minimum necessary permissions for the shortest possible time;
• Assume a breach: segment and log, so that an attacker doesn't get very far and you can detect them.

In practice: single sign-on with MFA, access to applications via an identity-aware proxy (zero-trust network access) instead of a VPN, segmentation between workloads, and separate identities for workloads and AI agents. Read more in our blog about Zero Trust.

Kubernetes comes with its own risks: clusters with overly broad permissions, unprotected network traffic between pods, insecure images, and a publicly accessible API server. The most important measures are:

• access via SSO and RBAC with least privilege;
• network policies that block everything by default, for example, using Cilium;
• Pod Security Standards and Policies using Kyverno or OPA Gatekeeper;
• Scan and sign images, and allow them only from trusted registries;
• runtime detection, for example, using Falco;
• a standardized upgrade process for Kubernetes and the nodes.

The complete list and its relationship to NIS2 are provided in the Kubernetes guide, Section 7.

The sooner you find a bug, the less it costs. That’s why you should incorporate security into your platform’s pipeline and golden paths:

• Scan code, dependencies, and secrets with every merge request;
• Scan Infrastructure as Code for misconfigurations before it is deployed, for example, using Trivy or Checkov;
• Build container images from minimal base images, scan and sign them, for example using Sigstore;
• Create an SBOM (software bill of materials) for each release. Under the Cyber Resilience Act, this will become the standard;
• policies as code, so that the pipeline enforces the security guidelines.

You can read about how to implement this in a developer platform in the guide on platform engineering.

Under NIS2, you must report a significant incident within 24 hours via an early warning, within 72 hours via an incident report, and within one month via a final report. Government agencies are also subject to the BIO and BIO2 regulations. Have your legal counsel or compliance officer assess how these apply to your organization.

Data stored in a European region by a U.S. provider may be subject to U.S. laws, such as the CLOUD Act. Whether this poses a risk depends on the data, your industry, and your customers. Mitigation measures range from encryption using your own keys to a European or dedicated environment for the most sensitive data. You can read about the considerations for each dataset in the guide at Cloud Migration, Section 5. A Data Sovereignty Assessment can map this out in a week.

Many organizations retain control and policy-making in-house, while outsourcing monitoring and follow-up. To learn how to make that decision, read the guide on outsourcing IT management.