PCI Cloud Compliance Professional (PCCP) common mistakes
PCCP · Understand the traps and how to avoid them.
Treating every component in a cloud account as automatically in scope for PCI DSS, or conversely assuming that using a cloud provider removes systems from scope because the provider is 'PCI compliant'.
Candidates conflate the provider's own compliance attestation with the customer's cardholder data environment (CDE) boundary, and they never draw an explicit data-flow and account/subscription boundary. Cloud makes it easy to spin up resources touching card data, so scope silently expands or contracts without analysis.
What to do instead
Build a data-flow diagram first, identify where cardholder data (CHD) is stored, processed, or transmitted, then classify each system as CDE, connected-to, security-impacting, or out of scope, and document the justification per system. Distinguish the provider's responsibility from yours before deciding scope.
Assuming the cloud provider covers requirements like encryption, patching, logging, or access control because those appear in the provider's compliance package.
The shared responsibility model is often read as a single blanket statement rather than a per-requirement, per-service matrix. Managed services (e.g., managed databases, object storage, key management) split controls differently than IaaS, and candidates apply one mental model to all service types.
What to do instead
For each in-scope service, map every applicable PCI DSS v4.0 requirement to 'provider', 'customer', or 'shared', citing the provider's responsibility documentation and the specific service. Note where the customer retains obligations even for managed services (e.g., key custody, IAM policy, log retention, configuration of encryption).
Claiming network segmentation without validating it, or relying on a single control (e.g., a subnet or security group) as the only boundary between the CDE and other environments.
Candidates assume logical cloud constructs equal effective segmentation and skip testing. Segmentation in cloud must be proven, not asserted, and a single misconfigured route, peering, or permissive security group can collapse the boundary.
What to do instead
Define the segmentation boundary explicitly, document all controls enforcing it (security groups, NACLs, routing, private endpoints, firewalls, IAM), and require periodic penetration testing and configuration review to confirm the boundary holds. Treat any unverified path as in scope until proven otherwise.
Encrypting data but leaving key management unaddressed, such as storing keys alongside the data, using provider-managed keys without documenting custody, or never defining key rotation and access controls.
Candidates treat 'encryption enabled' as the complete control and stop there. PCI DSS requires documented key management processes, restricted key access, and separation of duties, which are distinct from turning on encryption at rest.
What to do instead
Document the full key lifecycle: generation, distribution, storage, rotation, retirement, and access. Specify who can use keys versus who can administer them, enforce least privilege on key policies, and record how key management is split between you and the provider, including any customer-managed key options.
Relying on a single factor or overly broad roles for administrative access into the CDE, or granting standing privileges to cloud console and API users.
Cloud IAM is powerful and easy to over-permission; candidates focus on authentication method but neglect authorization scope, session controls, and monitoring of privileged actions. Standing admin rights feel convenient and are rarely challenged.
What to do instead
Enforce multi-factor authentication for all access into the CDE, apply least privilege with narrowly scoped roles and just-in-time elevation, and log and review all privileged and administrative actions. Tie each role to a documented business need and review entitlements periodically.
Treating vulnerability scanning and patching as satisfied by the provider's image maintenance, or scanning only a subset of in-scope assets on an ad-hoc basis.
Candidates assume managed services and base images are patched for them and never establish an inventory-driven scanning cadence. Ephemeral and auto-scaled resources are missed, and scan results are not tied to remediation tracking.
What to do instead
Maintain an authoritative asset inventory of in-scope components, define scan frequency and coverage (including containers and ephemeral instances), and track findings to remediation with owners and dates. Confirm in writing which patching layers the provider handles and which remain yours, and verify configuration baselines against hardening standards.
Enabling logging but failing to centralize, protect, retain, or review logs, and having no tested incident response plan that accounts for cloud provider escalation paths.
Candidates equate 'logging on' with meeting the requirement and overlook tamper resistance, retention periods, time synchronization, and active review. Incident response plans written for on-premises rarely address provider notifications, shared forensics, or cloud-native evidence capture.
What to do instead
Centralize logs in a protected, access-restricted store with defined retention, integrity controls, and synchronized timestamps; define who reviews what and how often. Build and test an incident response plan that specifies provider contact and escalation, evidence preservation in cloud, and roles during an incident.
Presenting a provider's compliance certificate as the organization's own evidence of PCI DSS compliance, or producing evidence that is stale, undated, or not tied to the specific requirement.
Candidates confuse the provider's attestation with their own assessment and gather artifacts without mapping them to requirements. Cloud configurations change constantly, so undated or untested evidence does not demonstrate the control was operating during the assessment period.
What to do instead
Assemble evidence that maps each requirement to your own implemented control, with dates, scope, and system identifiers, plus the provider's responsibility documentation where relevant. Ensure evidence reflects the assessment period and refresh it for configuration drift; distinguish design evidence from operating-effectiveness evidence.
Ignoring third-party and subservice-provider risk, such as not tracking which cloud services or vendors touch CHD or not requiring them to meet PCI DSS obligations.
Candidates focus on the primary cloud provider and forget downstream services, integrations, and SaaS tools that may store or process card data. Governance over these relationships is often informal and undocumented.
What to do instead
Maintain a register of all third parties and services with access to or impact on the CDE, document their PCI DSS status and responsibilities, and define contractual and review requirements. Reassess when services or architectures change, and record how each relationship is monitored.
Treating compliance as a one-time project rather than an ongoing program, so scope, controls, and evidence are never revisited after the initial assessment or major architecture change.
Candidates study requirements as static checklist items and underestimate how cloud change velocity (new services, auto-scaling, redeployments) causes drift. Governance, ownership, and change-management linkage are often absent.
What to do instead
Establish a compliance program with named owners, scheduled reviews, change-management triggers that reassess scope and controls, and continuous monitoring of key configurations. Document how architecture changes feed back into scope definition and evidence collection.