PCI DSS Fundamentals and Scope in Cloud Environments
PCI DSS Fundamentals and Scope in Cloud Environments
This domain tests whether you can draw the cardholder data environment (CDE) boundary when the hardware belongs to someone else, and defend that boundary to an assessor.
PCI DSS applies wherever cardholder data (CHD) is stored, processed or transmitted, and to every system that can impact the security of those systems. The 12 requirements and six goals do not change in the cloud; where controls live and who can evidence them does. Treat scope as three rings: the CDE, systems connected to it, and security-impacting systems - identity, logging, key management, and any pipeline that can change CDE configuration.
Three requirements anchor scoping: 12.5.2 (scope documented and confirmed at least every 12 months and on significant change), 12.5.2.1 (inventory of in-scope components with function and operating system), and 12.5.3 (senior management confirms scoping validation where segmentation reduces scope).
Worked example. A team stores PAN in a managed database in a dedicated cloud account. A separate shared CI/CD account holds the deployment role that can alter that database's encryption and network settings. The team calls the CI/CD account out of scope because it never touches PAN. That fails: scope follows the ability to affect the CDE, so the account is in scope. Isolating the pipeline role - narrow permissions, approval gate, full logging, validated by config review - manages the risk but does not remove the account from scope.
Traps. Treating the provider's attestation as your compliance; declaring "we never store PAN" while SAD or tokens still flow through your systems; forgetting that architecture change reopens scope; assuming tokenization descopes everything without validating the token environment.