Cloud Security Compliance Standards – PCI DSS and GDPR

Cloud security compliance standards like PCI DSS and GDPR set the security and privacy obligations that apply once you store, process, or transmit regulated data on AWS, Azure, or GCP. They matter because a cloud provider’s own certifications only ever cover part of the shared-responsibility split, the rest is still your obligation, and getting it wrong carries real fines. The recommended action: map each requirement to who, you or the CSP, actually controls it, before you assume “the cloud is compliant” covers you.

Published: November 2020. Updated: August 2026. Reviewed by Encryption Consulting’s Compliance Advisory Team.

This post covers the general cloud compliance picture for PCI DSS and GDPR. If your specific concern is where PKI keys, audit logs, and administrative access physically reside for data-sovereignty purposes, our Data Sovereignty and Regional Compliance guide goes deeper on that mapping across GDPR, NIS2, DORA, and FedRAMP.

What Is the Cloud Shared Responsibility Model?

The shared responsibility model is the division of security and compliance duties between you and your Cloud Service Provider (CSP), and where that line falls depends on which service model you use. A CSP is always responsible for the physical security of its data centers and for securing the infrastructure underneath whatever service you consume. You are always responsible for how you configure and use that service, your data, your access controls, and your own compliance obligations layered on top. Moving from Infrastructure-as-a-Service (IaaS) to Platform-as-a-Service (PaaS) to Software-as-a-Service (SaaS) shifts more of the technical burden to the CSP, but it never shifts the compliance accountability itself, you still have to verify the CSP actually meets the standard you need, and document that you did.

How Does PCI DSS Apply to Cloud Environments?

PCI DSS (Payment Card Industry Data Security Standard) applies to your cloud environment the moment cardholder data is stored, processed, or transmitted there, and it requires validating both the CSP’s infrastructure and your own usage of it. PCI DSS is a set of security requirements, currently version 4.0.1, created by the payment card brands in 2004 and maintained by the PCI Security Standards Council, and it applies to any business handling payment card data regardless of size.

Responsibility for each requirement still splits by service model, the table below reflects how that split typically falls, though the exact division is always defined in your contract and Attestation of Compliance with the CSP, not assumed from the service model alone.

PCI DSS Requirement				Responsibility assignment for management of controls
				IaaS	PaaS	SaaS
Install and maintain network security controls to protect cardholder data				Client and CSP	Client and CSP	CSP
Apply secure configurations to all system components, no vendor-supplied defaults				Client and CSP	Client and CSP	CSP
Protect stored account data				Client and CSP	Client and CSP	CSP
Protect cardholder data with strong cryptography during transmission over open, public networks				Client	Client and CSP	CSP
Protect all systems and networks from malicious software				Client	Client and CSP	CSP
Develop and maintain secure systems and software				Client and CSP	Client and CSP	Client and CSP
Restrict access to system components and cardholder data by business need to know				Client and CSP	Client and CSP	Client and CSP
Identify users and authenticate access to system components				Client and CSP	Client and CSP	Client and CSP
Restrict physical access to cardholder data				CSP	CSP	CSP
Log and monitor all access to system components and cardholder data				Client and CSP	Client and CSP	CSP
Test security of systems and networks regularly				Client and CSP	Client and CSP	CSP
Support information security with organizational policies and programs				Client and CSP	Client and CSP	Client and CSP

PCI DSS v4.0.1 added two requirements worth flagging specifically for cloud deployments. Disk-level encryption no longer qualifies as “encryption at rest” on its own, except on removable media, so full-disk or volume-level encryption for cardholder data stored in the cloud needs a compensating control such as file- or column-level encryption. And organizations must now formally review the cryptographic suites and protocols actually in use at least annually, including active monitoring for algorithms or protocols moving toward deprecation, a review that is easy to skip in a cloud environment where TLS configuration is partly managed by the CSP.

How Does GDPR Apply to Cloud Environments?

GDPR (General Data Protection Regulation) applies to any organization, anywhere in the world, that collects or processes the personal data of people located in the EU, and it holds you accountable for how your CSP handles that data on your behalf, not just how you handle it yourself. Non-EU companies processing EU residents’ data must appoint an EU representative and remain liable for fines and sanctions regardless of where the company itself is based.

GDPR’s core requirements, several of which have direct technical implications in a cloud environment, are:

1. Lawful, fair, and transparent processing.
2. Purpose, data, and storage limitation. Collect only what is necessary and discard personal data once processing is complete.
3. Data subject rights. A person can ask what data you hold on them and how it is used.
4. Consent. You must obtain consent for processing beyond legitimate purposes, and the person can withdraw it at any time.
5. Personal data breach notification. Regulators must be informed within 72 hours of your organization becoming aware of a breach, which depends entirely on logging and monitoring that actually detects the breach in time.
6. Privacy by design. Build data protection into new systems and processes from the start, not as an afterthought.
7. Data Protection Impact Assessments. Conduct one when starting a new project, change, or product that involves significant personal data processing.
8. Data transfers. You remain responsible for GDPR compliance even when a third party (including your CSP) processes the data on your behalf.
9. Data Protection Officer. Required when your organization engages in significant personal data processing.
10. Awareness and training. Employees need to understand the GDPR requirements relevant to their role.

To actually meet these requirements in a cloud environment, take these additional steps: know exactly where your CSP stores and processes the data; confirm which CSP services and configurations meet your security standard, and configure them accordingly, since GDPR compliance is not automatic just because the CSP itself is certified; put a data processing agreement in place with every CSP and cloud application you use; collect and process only what you need; verify the data processing agreement is actually being honored, not just signed; and confirm you can erase a person’s data on request from every data source inside the CSP, not just your primary database.

How Does Encryption Key Control Affect PCI DSS and GDPR Compliance?

Where your encryption key lives, not just whether data is encrypted, is what determines who can technically access regulated data, and that is exactly what both PCI DSS assessors and GDPR regulators are increasingly asking about.

Key control model	What it means	Compliance relevance
Native (cloud-managed)	Key generated and held inside the CSP’s own key management service (AWS KMS, Azure Key Vault, GCP Cloud KMS)	Satisfies PCI DSS’s requirement to protect stored account data and document key management procedures; the CSP technically can access the key material, which some GDPR data-processing agreements require you to disclose to data subjects
BYOK (bring your own key)	You generate the key material and import it into the CSP’s HSM	Demonstrates key provenance for audit purposes; still leaves a usable copy inside the CSP once imported, so it does not remove the CSP from your data flow diagram
HYOK (hold your own key)	Key material never leaves your own or a third-party external key manager; the CSP calls out to it for every operation	The strongest technical answer to “can the CSP read our data,” relevant where a GDPR data processing agreement or a specific PCI DSS scoping decision requires it, at the cost of making your external key manager’s availability a dependency for every transaction

Most organizations do not need HYOK to pass a PCI DSS assessment or satisfy GDPR, native cloud key management with documented procedures covers the requirement for the large majority of use cases. HYOK becomes relevant specifically when a contract, a regulator, or a data processing agreement requires proof that the CSP cannot access the data at all, not as a default posture. Our AWS KMS vs. Azure Key Vault vs. GCP KMS comparison covers how each provider actually implements BYOK and HYOK if you need that level of detail.

How Does IAM Support PCI DSS and GDPR Compliance?

Both standards require restricting access by business need to know, PCI DSS names this explicitly as a control, and GDPR’s Article 32 requires “appropriate technical and organizational measures” that regulators interpret to include access control.

1. Inventory every identity, human and service, with any access to regulated data or the keys protecting it.
2. Assign a unique ID to every person with system access, never a shared credential, which PCI DSS requires explicitly.
3. Scope every permission to the specific system, database, or key needed, not account-wide or project-wide access.
4. Separate the roles that administer encryption keys from the roles that use them to encrypt or decrypt data.
5. Review access on a fixed cadence, and immediately upon role change or termination, since PCI DSS assessors and GDPR audits both treat stale access as a finding.

What Do PCI DSS and GDPR Require for Key and Credential Rotation?

PCI DSS requires you to define a cryptoperiod, the length of time a key can be used, based on the algorithm, key length, and sensitivity of the data it protects, and to replace keys before that period expires or immediately if a key is suspected compromised. GDPR does not name a specific rotation interval, but Article 32’s requirement for “state of the art” security measures means a key rotation policy that has not been reviewed in years is itself a weak point regulators can point to. In practice, defining a documented rotation policy per key, and actually enforcing it through your cloud KMS’s native rotation feature rather than a manual calendar reminder, satisfies both standards at once.

What Logging Do PCI DSS and GDPR Require in the Cloud?

PCI DSS requires you to log and monitor all access to system components and cardholder data, and GDPR’s 72-hour breach notification requirement is unenforceable in practice without logs detailed enough to establish when a breach actually started.

• PCI DSS: logs need to capture individual user access to cardholder data, all actions by privileged accounts, and any use of identification and authentication mechanisms, retained and reviewed on a schedule your QSA will ask to see evidence of.
• GDPR: Article 30 requires records of processing activity, and Article 33’s 72-hour clock starts from when you become aware of a breach, which means your logging has to be actively monitored, not merely retained, to start that clock on time rather than weeks later.
• In practice on the major clouds: AWS CloudTrail, Azure Monitor diagnostic logs, and GCP Cloud Audit Logs all provide the raw material, but none of the three enable comprehensive logging by default, each requires an explicit configuration decision per service.

What Does Cloud Compliance Cost to Maintain?

Cloud compliance cost is mostly a personnel and process cost, not a licensing cost, annual PCI DSS assessments (self-assessment questionnaires or a Qualified Security Assessor engagement depending on transaction volume), the ongoing work of maintaining a documented cryptographic architecture and key management procedures, and the engineering time to configure and monitor logging correctly across every cloud service in scope. The cloud-native services themselves, KMS key fees, HSM instance costs, log storage, are typically a small fraction of that total compared to the assessment and documentation effort, which is one reason organizations under-budget for compliance maintenance after the first successful audit.

What Does Multi-Cloud Compliance Architecture Look Like?

Running regulated workloads across more than one cloud multiplies the shared-responsibility mapping exercise by however many clouds you use, unless you standardize key control, IAM, rotation, and logging policy once, centrally, and apply it consistently rather than letting each cloud team interpret PCI DSS and GDPR independently.

For the reference architecture behind that kind of centralized approach, see our Multi-Cloud PKIaaS Architecture Guide and the Education Center’s overview of multi-cloud key management.

What Are the Limitations of Relying on CSP Compliance Certifications?

• A CSP’s certification covers its own infrastructure, not your configuration of it. An AWS PCI DSS Attestation of Compliance does not make your S3 bucket policy, IAM permissions, or application code compliant.
• SaaS narrows but does not eliminate your obligations. Even on SaaS, you remain responsible for account access control, data classification, and confirming the vendor’s compliance actually covers your specific use case.
• Not all cloud services within one CSP carry the same certification. A CSP being PCI DSS or GDPR-capable overall does not mean every individual service is in scope for your Attestation of Compliance, you have to verify per service.
• Compliance is a point-in-time attestation, not a continuous guarantee. Configuration drift after an assessment is common, and neither PCI DSS nor GDPR compliance is self-maintaining.

Decision Checklist: Cloud Compliance for PCI DSS and GDPR

1. Map every PCI DSS requirement and GDPR obligation to whether you, your CSP, or both control it, for your specific service model (IaaS, PaaS, or SaaS), don’t assume from the model alone.
2. Decide your key control model (native, BYOK, or HYOK) based on an actual contractual or regulatory requirement, not by default.
3. Document your cryptographic architecture and key management procedures now, PCI DSS v4.0.1 requires it for service providers and expects it as evidence for merchants too.
4. Enable and centrally route logging for every in-scope cloud service before an assessor or a breach forces the question.
5. If you operate in more than one cloud, standardize the above once, centrally, rather than letting compliance posture diverge by cloud team.

What Would Encryption Consulting Recommend?

The organizations that struggle with cloud compliance are rarely the ones missing a specific control, they are the ones that never mapped who owns which control in the first place, and discover the gap during an assessment instead of before one. We recommend treating the shared-responsibility mapping as a living document, reviewed whenever you adopt a new cloud service, not a one-time exercise done at initial cloud migration. Where key management and its documentation is the gap, our Cloud Data Protection assessment benchmarks your current posture against PCI DSS, GDPR, and related frameworks across AWS, Azure, and GCP, and our HSM-as-a-Service offering gives you FIPS-validated, centrally governed key custody that spans all three.

Frequently Asked Questions

If my CSP is PCI DSS certified, am I automatically compliant?

No. A CSP’s Attestation of Compliance covers its own infrastructure and the services it operates directly. You remain responsible for how you configure those services, your access controls, your application code, and any part of the requirement matrix that falls to the client under your specific service model.

Does GDPR require me to keep EU citizens’ data physically inside the EU?

Not automatically, GDPR permits transfers outside the EU under specific mechanisms (adequacy decisions, standard contractual clauses, binding corporate rules), but you remain accountable for ensuring those protections actually apply, and some sector-specific rules or customer contracts may require EU data residency regardless of what GDPR itself permits.

Do I need to use HYOK to be PCI DSS or GDPR compliant?

Almost never as a default requirement. Native cloud key management with documented procedures satisfies both standards for the overwhelming majority of use cases. HYOK becomes relevant when a specific contract, regulator, or data processing agreement requires proof the CSP cannot access your data at all.

What changed in PCI DSS v4.0.1 that specifically affects cloud deployments?

Two changes stand out for cloud environments: disk-level encryption alone no longer qualifies as encryption at rest except on removable media, and organizations must now formally review their cryptographic suites and protocols at least annually, including monitoring for algorithms moving toward deprecation.

How quickly do I actually need to detect a breach to meet GDPR’s 72-hour requirement?

The 72-hour clock starts when your organization becomes aware of the breach, not when it occurred, but a logging setup that only surfaces incidents days or weeks later effectively defeats the requirement. Centrally monitored, actively alerted logging is what makes the 72-hour window achievable in practice.

Have a specific PCI DSS or GDPR cloud compliance question? Reach our team at [email protected].