Cloud Security: Risks, Best Practices, and SIEM for the Cloud

Cloud security defines the operational baseline of modern cyber defense. Organizations across Europe migrate critical workloads to three hyperscalers: Amazon Web Services (AWS), Microsoft Azure, and Google Cloud. The attack surface has shifted from physical data centers to three new control points: identities, application programming interfaces (APIs), and configurations defined as code.

The Bitkom Wirtschaftsschutz 2025 study (Economic Security 2025), presented in September 2025, reports that 87% of German companies experienced data theft, industrial espionage, or sabotage during the previous twelve months. Total damage reached EUR 289.2 billion, an 8% year-over-year increase. EUR 202.4 billion of that total (70%) stems specifically from cyberattacks. 46% of affected companies attribute incidents to actors operating from Russia, and another 46% to actors operating from China.

This article defines cloud security, lists the main risks in 2026, explains the best practices that reduce exposure, and shows how a Security Information and Event Management (SIEM) platform built for the cloud detects and contains threats. Three regulatory frameworks anchor the analysis: the NIS2 Directive, the German Bundesamt für Sicherheit in der Informationstechnik (BSI) Cloud Computing Compliance Criteria Catalogue (C5:2026), and the European Cybersecurity Certification Scheme for Cloud Services (EUCS).

What is cloud security?

Cloud security is the combination of policies, controls, processes, and technologies that protect data, workloads, identities, and infrastructure deployed in public, private, hybrid, or multi-cloud environments. Cloud security operates as a continuous lifecycle covering five phases: architectural planning, configuration and deployment, ongoing monitoring, incident response, and provider exit.

Three properties separate cloud security from traditional on-premise information security:

• The perimeter has dissolved. Workloads run on infrastructure shared with other tenants. The physical boundary that firewalls used to defend no longer exists in public cloud.
• The unit of protection has shifted from servers to identities and configurations. One overly permissive Identity and Access Management (IAM) role or one misconfigured storage bucket exposes terabytes of data within minutes.
• Security responsibility is shared. The cloud provider secures the cloud (physical infrastructure, hypervisor, managed service plane). The customer secures workloads in the cloud (data classification, identity, network configuration, application logic, and logging).

Misreading the shared responsibility line between provider duties and customer duties causes a high share of cloud breaches.

How does security function in cloud environments?

Security in cloud environments runs on API events, not on physical network logs. Every meaningful action  –  creating a virtual machine, modifying a firewall rule, granting a permission, or accessing a storage object  –  executes as an API call. The audit trail of those API calls forms the source of truth for cloud detection.

Three platforms produce the bulk of cloud security telemetry: AWS CloudTrail, Azure Activity Logs combined with Microsoft Entra ID sign-in logs, and Google Cloud Audit Logs. A modern security operation feeds all three into a central SIEM for correlation.

Cloud security functions as a continuous control loop across five layers:

• Identity and Access Management (IAM). Establishes who  –  human or machine  –  can perform which action on which resource. Effective IAM uses short-lived credentials, phishing-resistant multi-factor authentication (MFA), and the principle of least privilege.
• Configuration and posture. Ensures every resource is provisioned safely from the start through Infrastructure as Code (IaC), and evaluates the deployed state continuously against the Center for Internet Security (CIS) Foundations Benchmarks for AWS, Azure, and Google Cloud.
• Data protection. Covers encryption in transit, at rest, and in use (Confidential Computing), alongside classification, key management, and data loss prevention.
• Workload and network security. Protects virtual machines, containers, and serverless functions, plus the virtual networks that connect them through segmentation, runtime protection, and vulnerability management.
• Detection and response. Consolidates IAM, configuration, data, and workload telemetry into a SIEM, correlates the data with threat intelligence and behavioral analytics, and drives automated containment through Security Orchestration, Automation, and Response (SOAR) playbooks.

The German market reinforces this five-layer model through the BSI IT-Grundschutz Compendium. Module OPS.2.2 Cloud Usage defines the principles for planning, operating, and exiting a cloud provider relationship. Module DER.1 Detecting Security-Relevant Events mandates SIEM-class capabilities for operators of critical infrastructure (KRITIS  –  Kritische Infrastrukturen).

What are the main risks in cloud security?

The main risks in cloud security cluster around four categories: configuration failures, identity compromise, software supply chain failures, and inadequate logging. The Open Worldwide Application Security Project (OWASP) Top 10 for 2025, announced at OWASP Global AppSec in November 2025 and finalized shortly after, confirms this ranking through analysis of more than 175,000 Common Vulnerabilities and Exposures (CVE) records.

Three structural shifts in OWASP Top 10:2025 matter most for cloud environments:

• A01 Broken Access Control holds the number one position for the fourth consecutive cycle. The category now absorbs Server-Side Request Forgery (SSRF). 3.73% of tested applications carry at least one of 40 Common Weakness Enumerations (CWEs) in this category.
• A02 Security Misconfiguration moved from position five in 2021 to position two in 2025. Modern application behavior depends more on environment configuration than on code.
• A03 Software Supply Chain Failures entered the list as a new category, expanded from the 2021 entry “Vulnerable and Outdated Components.” The new category covers third-party dependencies, build systems, Continuous Integration / Continuous Deployment (CI/CD) pipelines, and update mechanisms.

The OWASP Top 10 Infrastructure Security Risks initiative confirms a parallel pattern: organizations under-invest in logging and detection. Attackers operate inside compromised cloud tenants for weeks without triggering alerts, hidden by poorly tuned monitoring. The BSI IT-Grundschutz threat catalog reinforces this picture by listing provider outages, hardware and software manipulation, and privacy violations as cascading risks that disrupt entire service chains.

Four risk categories define cloud security exposure in 2026: misconfigurations, IAM compromise, supply chain failures, and logging weaknesses.

How do misconfigurations lead to data loss in the cloud?

Misconfigurations lead to data loss in the cloud through five common patterns. A misconfiguration is any deviation between the intended secure state of a cloud resource and its deployed state. Cloud misconfigurations propagate at machine speed because one Infrastructure-as-Code template applied across hundreds of accounts exposes an entire fleet within minutes.

The five most consequential misconfiguration patterns are:

• Publicly exposed storage. S3 buckets, Azure Blob containers, or Google Cloud Storage (GCS) buckets left open to the internet. Developers frequently change an access setting to debug an issue and never revert it. Automated scanners run by researchers and criminals discover these exposures within hours.
• Default and unrotated credentials. Service accounts, API keys, or administrative consoles kept on default values, hard-coded into source code, or left in repositories after the original developer moved on.
• Overly permissive network rules. Security groups and virtual network rules opening management ports to 0.0.0.0/0. Three protocol families show up most often: Secure Shell (SSH, port 22), Remote Desktop Protocol (RDP, port 3389), and database ports (3306 for MySQL, 5432 for PostgreSQL, 1433 for Microsoft SQL Server).
• Unencrypted data and weak key management. Encryption disabled on storage volumes or databases, customer-managed keys not rotated, or sensitive parameters stored in plain environment variables instead of a secrets manager.
• Disabled logging. AWS CloudTrail, Azure Diagnostic Settings, or Google Cloud Audit Logs turned off in a non-production account that later promotes into production, creating a permanent blind spot for investigators.

These five failures combine into the standard cloud breach chain. An attacker scans for the exposed misconfiguration, exploits a default credential or unpatched service, escalates privileges through an over-permissive IAM role, and exfiltrates data through a path without logging. The BSI C5:2026 catalog raises the bar on multi-tenancy isolation, container orchestration controls, and supply chain verification  –  the configuration surfaces where modern breaches start.

What are the most common threats to Identity and Access Management (IAM)?

The six most common threats to Identity and Access Management (IAM) in the cloud are credential theft, token hijacking, privilege escalation, non-human identity abuse, SSRF metadata abuse, and dormant identity reactivation. IAM controls all access in cloud environments. The rest of the security stack becomes secondary once an attacker holds valid credentials, human or machine.

Each threat maps to a specific MITRE ATT&CK technique:

• Credential theft via phishing and infostealers. Users enter credentials on fake login pages, or malware extracts stored session cookies from browsers, bypassing multi-factor authentication entirely. MITRE ATT&CK: T1078 Valid Accounts, T1539 Steal Web Session Cookie.
• Token and session hijacking. Long-lived OAuth tokens, refresh tokens, or cloud Command Line Interface (CLI) session files copied from a developer workstation and replayed from an attacker-controlled environment.
• Privilege escalation through IAM misuse. An attacker with limited access exploits weakly scoped roles, trust policies, or pass-role permissions to assume a privileged role. Privilege escalation through IAM misuse is among the most common escalation paths in AWS environments.
• Non-human identity abuse. Service accounts, CI/CD runners, Kubernetes service tokens, and managed identities hold broad permissions and rarely use MFA. Non-human identities have become one of the highest-value target categories in cloud breaches.
• SSRF and metadata service abuse. Vulnerable applications call internal metadata endpoints (for example, 169.254.169.254 on AWS EC2) and extract instance credentials, enabling rapid privilege escalation across the account.
• Dormant identity reactivation. Former employees, decommissioned service accounts, or test users left enabled in the directory and reused months later.

IAM hygiene that defends against these threats combines five practices: short-lived credentials (federated single sign-on, workload identity federation, IAM Roles Anywhere), phishing-resistant MFA, just-in-time privileged access, continuous review of permission usage versus permission grant, and behavioral analytics that flag identities operating outside the normal pattern. Behavioral analytics forms the foundation of User and Entity Behavior Analytics (UEBA).

What are the best practices for cloud security?

Best practices in cloud security follow one operating principle: assume nothing about default configurations, and verify every resource continuously. The German market translates this principle through three overlapping frameworks: BSI IT-Grundschutz for risk management, the CIS Benchmarks for technical hardening, and BSI C5:2026 for cloud provider attestation.

Seven core practices reduce cloud risk across AWS, Azure, and Google Cloud:

1. Apply least privilege to every identity, human and non-human, with quarterly access reviews and automatic deprovisioning.
2. Treat configuration as code. Version-control every Infrastructure-as-Code template, run pre-deployment security scans, and reject pull requests that violate baseline policies.
3. Assess deployed posture against the CIS Foundations Benchmarks for AWS, Azure, and Google Cloud continuously, through a Cloud Security Posture Management (CSPM) tool.
4. Encrypt data at rest, in transit, and in use. Manage keys in dedicated key management services (KMS) with customer-managed rotation policies.
5. Centralize audit and security logs in a SIEM with retention sufficient to satisfy NIS2 reporting timelines and General Data Protection Regulation (GDPR) data minimization principles.
6. Automate response for high-volume, well-understood incident patterns through SOAR playbooks. Reserve human analysts for novel threats.
7. Plan for provider exit. Define how data, logs, and configurations transfer, delete, and verify when changing provider. BSI module OPS.2.2 enforces this requirement.

How to protect data through Cloud Security Posture Management (CSPM)?

Cloud Security Posture Management (CSPM) protects data through five mechanisms: asset discovery, configuration assessment, compliance mapping, attack-path analysis, and automated remediation. CSPM tools connect to provider APIs  –  AWS Config, Azure Resource Graph, and Google Cloud Asset Inventory  –  and evaluate every resource against policies derived from the CIS Benchmarks, cloud provider well-architected guidance, and regulatory frameworks including BSI C5.

The five CSPM mechanisms work as follows:

• Asset discovery. CSPM produces a continuously updated inventory of every storage bucket, database, virtual machine, container cluster, function, and identity across all accounts and regions. Asset discovery eliminates shadow cloud, where teams provision resources outside central visibility.
• Configuration assessment. CSPM evaluates each asset against baseline policies  –  “S3 buckets must not be publicly readable,” “databases must enable encryption at rest,” “IAM users must enable MFA”  –  and produces a prioritized list of violations.
• Compliance mapping. CSPM translates raw findings into audit language. Each violation maps to its corresponding control in ISO/IEC 27001:2022, BSI C5:2026, the CIS Controls v8 Cloud Companion Guide, GDPR, and NIS2.
• Attack-path analysis. Modern CSPM platforms connect identity, network, vulnerability, and data findings into a graph. The graph shows, for example, that a public-facing virtual machine with a known vulnerability assumes a role with full access to a customer-data bucket  –  the chain an attacker exploits.
• Automated remediation. For well-defined violations (public storage, missing encryption, disabled logging), CSPM platforms apply the fix through the provider API or open a ticket and pull request against the IaC repository. The underlying template gets corrected, not only the deployed resource.

CSPM is a continuous obligation, not a one-off audit. Under NIS2, management bodies bear personal liability for ongoing supervision of cybersecurity measures. Incidents must reach the BSI within tight reporting windows. A daily or hourly posture scan integrated into the SIEM meets this obligation across an estate with thousands of resources.

Why is compliance with legal regulations important?

Compliance with legal regulations is important because non-compliance now produces direct financial, personal, and operational consequences for management bodies, not only for IT teams. Three frameworks define the cloud compliance landscape in Germany and the European Union in 2026.

NIS2 Directive (NIS2UmsuCG in Germany). The NIS2 Directive is formally Directive (EU) 2022/2555 on Network and Information Security. The German implementing act, the NIS2UmsuCG, passed the Bundesrat on 21 November 2025, entered the Bundesgesetzblatt on 5 December 2025, and took effect on 6 December 2025 without a transition period. The act covers roughly 29,500 entities. The threshold test is simple: more than 50 employees or annual turnover above EUR 10 million. Sectors in scope include critical infrastructure, digital infrastructure providers, manufacturers of medical devices and machinery, waste management firms, and food and chemical companies. Penalties reach EUR 10 million or 2% of global annual turnover for essential entities, and EUR 7 million or 1.4% for important entities. Members of management bodies bear personal liability for failure to oversee cybersecurity measures. Registration with the BSI is mandatory within three months of entry into force.

BSI C5:2026. The Cloud Computing Compliance Criteria Catalogue serves as the de facto attestation standard for any cloud provider working with the German federal administration. BSI published the C5:2026 final version on 7 April 2026, replacing C5:2020. The number of audit criteria grew from 121 in C5:2020 to 168 criteria across 17 thematic areas in C5:2026. The new edition introduces explicit controls for five emerging areas: container orchestration, post-quantum cryptography, confidential computing, supply chain security, and multi-tenant separation. C5:2026 aligns with ISO/IEC 27001:2022, the Cloud Security Alliance Cloud Controls Matrix v4 (CSA CCM v4), and NIS2. Type 2 audit periods beginning on or after 1 June 2027 must apply C5:2026.

EUCS and the EU Cybersecurity Act. The European Cybersecurity Certification Scheme for Cloud Services, developed by the European Union Agency for Cybersecurity (ENISA) under the Cybersecurity Act, remains formally voluntary. NIS2 and the EU Data Act give Member States the authority to require public-sector entities and critical infrastructure to use EUCS-certified providers. Current drafts maintain data-localization, jurisdiction-shielding, and personnel-location requirements at higher assurance levels, with direct implications for non-EU hyperscalers.

GDPR applies to every log line containing personal data. In a security context, personal data includes IP addresses, usernames, and most authentication telemetry. A compliant cloud SIEM enforces three controls: retention limits (typically twelve months for security logs, justified by documented purpose), strong encryption, and role-based access to log data. Verifiable deletion at the end of retention closes the GDPR loop.

The economic case for compliance now matches the legal case. Under NIS2, the cost of an enforcement action  –  administrative fine plus personal liability of executives plus reputational damage  –  exceeds the cost of the most advanced SIEM, CSPM, and SOAR platforms combined.

How does SIEM improve cloud security?

SIEM improves cloud security in four concrete ways: telemetry consolidation, event enrichment, behavioral analytics, and automated response. A SIEM collects telemetry from five layers  –  identity, network, workload, application, and Software as a Service (SaaS)  –  normalizes the data into a common model, correlates events across sources, applies detection rules and machine learning, and presents prioritized alerts to security analysts.

The four improvement areas operate as follows:

1. Telemetry consolidation. A SIEM merges fragmented telemetry from multiple cloud providers and SaaS applications into a single investigative surface. Analysts stop pivoting between five consoles to trace one incident.
2. Event enrichment. The SIEM adds threat intelligence, geolocation, asset criticality, and user identity context to raw events. An anonymous API call becomes a contextualized event with attribution.
3. Behavioral analytics. User and Entity Behavior Analytics (UEBA) detects anomalies that signature-based tools miss: impossible travel between distant cities, dormant accounts reactivating, or service accounts accessing unfamiliar resources.
4. Automated response. The SIEM integrates with SOAR playbooks to automate containment steps that do not require human judgment. Response time compresses from hours to seconds.

Measured changes in attacker speed confirm the value of automated response. Unit 42 (Palo Alto Networks) reports that the fastest quartile of intrusions in 2025 reached data exfiltration within 72 minutes, down from 285 minutes in 2024. CrowdStrike’s 2026 Global Threat Report measures average eCrime breakout time at 29 minutes. SIEM platforms that surface alerts without triggering containment cannot match modern attacker tooling.

How does cloud SIEM detect threats in real-time?

Cloud SIEM detects threats in real-time through three engineered stages: low-latency ingestion, layered analytics, and automated response. The three stages operate as one continuous pipeline measured in seconds, not minutes.

Ingestion stage. Each major cloud provider exposes a streaming audit pipeline that a modern SIEM subscribes to:

• AWS CloudTrail delivers Management Events, Data Events, and Insights Events through Amazon S3 with Amazon Simple Queue Service (SQS) notifications, or directly through Amazon EventBridge.
• Azure Activity Logs and Microsoft Entra ID sign-in logs stream through Azure Event Hubs into compatible SIEM platforms.
• Google Cloud Audit Logs  –  Admin Activity, Data Access, System Event, and Policy Denied  –  flow through Google Cloud Pub/Sub into a compatible SIEM platform for centralized analysis.

AWS CloudTrail Lake ingests activity events from non-AWS sources, including Microsoft Azure, enabling a unified investigative store across providers. Ingestion latency targets seconds from event generation to SIEM availability.

Analytics stage. A cloud SIEM runs three analytical layers in parallel:

• Signature- and rule-based detection. Explicit rules use the platform’s query language; the vendor-neutral Sigma format compiles to any major SIEM, preserving detection logic across platform changes. Rules encode MITRE ATT&CK techniques: failed login bursts (T1110 Brute Force), suspicious role assumption (T1078 Valid Accounts), and discovery activity against IAM APIs (T1087, T1069).
• UEBA and machine learning. The engine builds a behavioral baseline for every user and workload identity over several weeks. The engine then scores deviations: impossible travel between distant logins, dormant identity reactivation, service accounts calling unfamiliar APIs, or managers downloading unusual file volumes. UEBA catches credential theft when the credentials themselves remain technically valid.
• Threat intelligence correlation. The SIEM checks every observed IP address, domain, file hash, and certificate against threat intelligence feeds from BSI advisories, ENISA bulletins, and commercial providers, and enriches alerts with attribution context.

Response stage. A SOAR playbook executes containment automatically once an alert crosses a defined risk threshold. The playbook performs five actions: revoke a Microsoft Entra ID session, disable a compromised AWS access key, isolate an Azure virtual machine through Microsoft Defender for Cloud, block an indicator of compromise at the cloud firewall, and open a ticket with enriched context attached. Mature programs reserve human approval for high-impact actions and let routine containment execute without intervention.

What are the differences between cloud SIEM and on-premise SIEM?

On-premise SIEM and cloud SIEM share one purpose  –  collect, correlate, and alert  –  but operate in different environments. Traditional SIEM was designed for finite logs from firewalls, servers, and network devices inside a controlled perimeter. Cloud-native SIEM is designed for millions of ephemeral API events per second, generated by workloads that exist for only minutes.

Gartner separates cloud-hosted SIEM (legacy products installed on virtual machines in a cloud account) from cloud-native SIEM (platforms architected for serverless ingestion, distributed data lakes, and elastic compute). Cloud-hosted SIEM retains the scaling and pricing constraints of its on-premise origins. Cloud-native SIEM removes those constraints but introduces its own ingestion economics.

The table summarizes seven main differences between on-premise SIEM and cloud-native SIEM across deployment, scalability, data sources, operational model, total cost of ownership, detection coverage, and compliance fit:

Dimension	On-Premise SIEM	Cloud-Native SIEM
Deployment	Installed on owned hardware in a private data center. The in-house team provisions, sizes, and patches every component.	Delivered as a managed service from the provider’s hyperscale infrastructure. Provisioning completes within minutes through a console or API.
Scalability	Limited by procurement cycles. Spikes in events per second (EPS) require new appliances or licenses purchased months in advance.	Elastic by design. Ingestion capacity scales horizontally through serverless pipelines and distributed data lakes that handle millions of events per second.
Data sources	Optimized for firewall, endpoint, Active Directory, and network device logs collected inside the perimeter.	Designed for API-driven telemetry: AWS CloudTrail, Azure Activity Logs, Google Cloud Audit Logs, Kubernetes audit events, SaaS audit trails, and identity providers.
Operational model	The customer owns the full stack: hardware, OS, storage, parsers, scaling, backups, and high availability.	The provider operates the platform. The security team focuses on detection engineering, tuning, and response.
Total cost of ownership (TCO)	High capital expenditure (CapEx) for appliances, plus continuous staffing and lifecycle costs.	Operational expenditure (OpEx) model billed by ingestion volume or events per second. Upfront cost is lower, but ingest budgets require active governance.
Detection coverage	Strong for traditional north-south traffic. Visibility into containerized, ephemeral, and serverless workloads stays limited.	Native correlation across multi-cloud identities, APIs, container runtimes, and SaaS, with built-in UEBA and threat intelligence enrichment.
Compliance fit (NIS2, BSI C5:2026, GDPR)	Full physical control over data location. Suits organizations that must keep logs on national territory.	Compliance depends on the provider’s certifications and on data-residency configuration. Fits when the platform supports EU-only processing and confidential computing.

One additional dimension matters: cost and vendor lock-in. CISOs across the DACH region (Germany, Austria, Switzerland) report SIEM renewal as a critical pressure point in 2025-2026. Commercial platforms price on events per second (EPS) or ingestion volume (GB/day). Kubernetes and microservices generate orders of magnitude more log data than on-premise monoliths. Organizations frequently see SIEM bills double within one contract cycle while nominal capacity stays flat. Pressure to stay within EPS caps drives teams to drop entire log sources silently, creating audit blind spots.

German mid-market and enterprise security teams increasingly adopt hybrid architectures. Detection rules use the vendor-neutral Sigma format and live in Git, enabling compilation into the query language of any current or future SIEM. Open-source SIEM and analytics engines handle a portion of ingestion and analytics. Commercial or open-source SOAR platforms orchestrate response. This decoupling preserves the option to change vendor without rewriting two thousand detection rules  –  the largest hidden cost of legacy SIEM.

What are the deployment models for cloud SIEM?

Four deployment models cover cloud SIEM implementations: SaaS cloud-native SIEM, cloud-hosted SIEM in the customer’s tenant, hybrid SIEM, and Managed Detection and Response (MDR) with a sovereign SIEM. The choice depends on three factors: regulatory constraints, existing infrastructure, and security team size.

1. Software as a Service (SaaS) cloud-native SIEM. The provider operates the entire platform. The customer connects log sources, writes detection rules, and consumes alerts. Leading platforms in this category include hyperscaler-native SIEM offerings and established commercial vendors with cloud-native delivery models. Operational overhead is lowest, and time to value is fastest. Data residency depends on the provider’s regional offerings  –  a critical consideration under GDPR and EUCS.

2. Cloud-hosted SIEM in the customer’s tenant. A traditional SIEM product runs on virtual machines inside the organization’s own AWS, Azure, or Google Cloud account. Established enterprise SIEM products support this deployment model on customer-controlled cloud infrastructure. The customer retains full data control and pins storage to specific regions. The customer accepts the operational burden of patching, scaling, and high availability. This model fits when compliance requires data to stay inside a specific national jurisdiction.

3. Hybrid SIEM. Telemetry collection runs in three environments  –  on-premise collectors, cloud-native ingestion pipelines, and SaaS connectors  –  and consolidates either in a centralized SaaS platform or in a self-hosted analytics tier. This configuration dominates mid-sized German organizations operating significant on-premise estates alongside cloud workloads. Hybrid SIEM fits entities subject to both NIS2 and sector-specific KRITIS requirements.

4. Managed Detection and Response (MDR) with a sovereign SIEM. An external MDR provider operates the SIEM, the Security Operations Center (SOC), and the response playbooks on the customer’s behalf. The platform sits inside a European data center to satisfy data-sovereignty constraints. MDR adoption grew rapidly in the DACH region under two pressures: the cybersecurity skills shortage and the NIS2 personal-liability provisions. A documented MDR partnership gives management bodies a defensible audit trail of due care.

Three architectural decisions matter across all four deployment models: where log data sits physically, who has technical and legal access to the storage, and how long data is retained. BSI C5:2026 and EUCS at higher assurance levels require these answers to be documented, auditable, and shielded from third-country legal orders. Confidential Computing  –  processing encrypted workloads inside hardware-enforced enclaves  –  is an explicit control area in C5:2026.

Summary of Cloud Security, Risks, Best Practices, and SIEM for the Cloud

Cloud security in 2026 defines the operating model for any digitally enabled organization in Germany and the European Union. Three forces drive the shift: identity, configuration, and API telemetry now form the primary risk surface; NIS2, BSI C5:2026, and EUCS take effect as binding compliance frameworks; and 87% of German companies report incidents, while the fastest quartile of intrusions reaches data exfiltration in 72 minutes.

The risk picture in cloud security clusters falls into four categories. Broken Access Control, Security Misconfiguration, and Software Supply Chain Failures occupy the top three positions in the OWASP Top 10 for 2025. Logging and detection blind spots complete the four. Misconfigurations (public storage, default credentials, overly permissive network rules) convert small operational errors into headline breaches. IAM compromise through phishing, token theft, SSRF, and non-human identity abuse converts one stolen credential into full account takeover.

Cloud security best practices combine seven elements: least-privilege identity, configuration-as-code with continuous CSPM assessment against the CIS Benchmarks, encryption at every layer, including in use, centralized logging with NIS2- and GDPR-compliant retention, automated response through SOAR, provider exit planning, and continuous evidence collection. The practices are anchored in BSI IT-Grundschutz (modules OPS.2.2 for cloud usage, DER.1 for detection) and attest through BSI C5:2026 and EUCS.

SIEM operationalizes cloud security at the speed cloud attacks demand. A cloud-native SIEM ingests AWS CloudTrail, Azure Activity Logs, Microsoft Entra ID sign-in logs, and Google Cloud Audit Logs at scale. The SIEM correlates events through rule-based detection, UEBA, and threat intelligence. The SIEM drives automated containment through SOAR. The choice between four deployment models  –  SaaS, cloud-hosted, hybrid, and MDR  –  reflects a sovereignty and operational decision, not only a technical one. Writing detection logic in the vendor-neutral Sigma format preserves the option to change platforms without losing years of detection engineering work.

The summary of cloud security, risks, best practices, and SIEM for the cloud reduces to one operating principle: continuous, identity-centric, evidence-driven defense, supported by a SIEM built for the cloud and aligned with NIS2, BSI C5:2026, and EUCS.