Cloud Compliance Checklist — Legal Requirements for Cloud Environments

Migrating to the cloud does not exempt organizations from regulatory obligations — quite the opposite, it adds new layers of complexity. The shared responsibility model between cloud providers and customers means that part of the compliance burden falls on the organization, even when infrastructure is managed by AWS, Azure, or GCP.

This article serves as a practical checklist — a comprehensive overview of legal requirements that organizations in the EU must meet in cloud environments in 2026.

What Regulations Apply to Cloud Environments?

GDPR — Personal Data Protection

GDPR is the foundational legislation governing personal data processing in the EU. In the cloud context, key requirements include:

• Data residency — EU citizens’ personal data should be stored within the EEA or in countries with adequacy decisions. Transfers to the US require mechanisms such as the EU-US Data Privacy Framework.
• Data Processing Agreement (DPA) — a mandatory agreement with the cloud provider defining the purposes, scope, and protective measures for processed data.
• Right to erasure — the organization must ensure permanent data deletion on request, which in the cloud requires verification of backups and replication.
• Records of processing activities — documentation of what data is processed where and for what purpose in the cloud.
• Data Protection Impact Assessment (DPIA) — for high-risk processing operations, including migrating sensitive data to the cloud.

NIS2 — Network and Information Systems Security

The NIS2 Directive (effective since October 2024) extends cybersecurity requirements to more sectors and imposes new obligations:

• Risk management — systematic risk analysis covering cloud environments
• Supply chain security — auditing cloud providers as part of the supply chain
• Incident reporting — notification of significant incidents within 24 hours (initial) and 72 hours (full)
• Management accountability — executives bear personal responsibility for adequacy of security measures

DORA — Digital Operational Resilience Act

DORA (effective since January 2025) targets the financial sector with specific requirements for cloud service usage:

• ICT provider registry — complete inventory of cloud services with criticality classification
• Exit strategy — documented migration plan from each cloud provider
• Resilience testing — regular business continuity tests, including cloud provider failure scenarios
• Threat-Led Penetration Testing (TLPT) — advanced penetration tests covering cloud infrastructure

PCI DSS 4.0 — Payment Card Data

For organizations processing payment card data in the cloud:

• Segmentation — isolation of CDE (Cardholder Data Environment) in the cloud
• Encryption — card data must be encrypted both in-transit and at-rest
• Logging — central log collection from cloud components processing card data
• Responsibility — clear mapping of PCI DSS requirements to cloud provider and customer

How Does the Shared Responsibility Model Work?

The shared responsibility model is the foundation of cloud compliance. Responsibility is divided between the provider (CSP) and customer:

Layer	IaaS	PaaS	SaaS
Physical infrastructure	CSP	CSP	CSP
Network	CSP	CSP	CSP
Operating system	Customer	CSP	CSP
Middleware / Runtime	Customer	CSP	CSP
Application	Customer	Customer	CSP
Data	Customer	Customer	Customer
Identity and access	Customer	Customer	Shared
Security configuration	Customer	Customer	Customer

Key principle: data and its classification is ALWAYS the customer’s responsibility, regardless of service model.

📚 Read more: Cloud Security · Public Cloud

Cloud Compliance Checklist — Step by Step

1. Data Inventory and Classification

• Identify all data processed in the cloud (personal, financial, health, technical)
• Classify data by sensitivity level (public, internal, confidential, restricted)
• Map data flows — where data enters the cloud, where it is stored, with whom it is shared
• Identify data subject to specific regulations (GDPR, PCI DSS, DORA)
• Document data location — in which regions/data centers it is stored

2. Cloud Provider Assessment

• Verify provider certifications (ISO 27001, SOC 2 Type II, C5, CSA STAR)
• Analyze the SLA agreement — availability guarantees, response times, compensations
• Review the DPA (Data Processing Agreement) — GDPR compliance
• Evaluate exit strategy — ability to migrate data to another provider
• Check data center geography — availability of EEA regions
• Verify sub-processors — who else processes your data

3. Security Architecture

• Implement data encryption at-rest and in-transit (TLS 1.2+, AES-256)
• Configure key management (KMS) — customer-managed keys for sensitive data
• Deploy network segmentation — VPC, security groups, network policies
• Configure IAM — principle of least privilege, MFA for all users
• Deploy logging and monitoring — CloudTrail/Activity Log, SIEM integration
• Configure backup and disaster recovery — automated backups, tested recovery procedures

4. Governance and Processes

• Establish cloud security policy — who can provision what, which services are allowed
• Deploy Infrastructure as Code — versioned, auditable configuration
• Configure alerting — notifications for unusual activities, cost overruns
• Establish change management process — review and approval before production changes
• Deploy Cloud Security Posture Management (CSPM) — continuous configuration verification
• Document incident response procedures in the cloud context

5. Continuous Monitoring and Audit

• Configure automated compliance scans (AWS Config, Azure Policy, GCP Organization Policy)
• Deploy regular audits — internal (quarterly) and external (annual)
• Monitor configuration drift — detecting and remediating deviations from baseline
• Track regulatory changes — new requirements may necessitate configuration updates
• Generate compliance reports for executives and auditors
• Conduct penetration tests of cloud infrastructure (minimum annually)

Most Common Cloud Compliance Mistakes

1. Assumption of compliance — assuming that “since AWS has ISO 27001, we are also compliant.” A provider’s certification does not transfer to the customer.
2. No data classification — without knowing what and where is stored, compliance is impossible.
3. Overly broad permissions — admin accounts with full access, shared credentials.
4. No exit strategy — vendor lock-in prevents meeting DORA portability requirements.
5. Ignoring logs — collecting logs without analyzing them is wasteful — logs must be actively monitored.
6. Shadow IT — teams provisioning cloud resources outside the official governance process.

How Often to Update Compliance?

Activity	Frequency
Automated configuration scans	Continuously (real-time)
IAM permissions review	Quarterly
Internal audit	Quarterly
Penetration tests	Annually (minimum)
External audit	Annually
Provider contract review	Annually
Security policy updates	After regulatory changes
Disaster recovery tests	Semi-annually

Summary

Cloud compliance is not a one-time project but a continuous process. It requires collaboration between IT, security, legal, and business teams. The key is automation — manually checking compliance in a dynamically changing cloud environment is inefficient and error-prone.

Start with data inventory and classification, then assess the current compliance state using CSPM tools, and finally implement continuous monitoring and auditing processes. Remember: in the shared responsibility model, you are responsible for data and configuration — not the cloud provider.

📚 Related glossary terms: Public Cloud · Cloud Security · SSL/TLS · Cloud Data Protection

Learn more from our knowledge base:

• 12 Tips to Improve Cybersecurity in Your Organization

Explore our services:

• Cloud — secure cloud infrastructure
• Compliance — regulatory compliance support