PCI Cloud Compliance Professional (PCCP) cheat sheet

PCI DSS v4.0 has 12 requirements grouped into 6 goals; the standard applies wherever cardholder data (CHD) is stored, processed, or transmitted, including cloud-hosted systems.

Three scope-expanding data types: cardholder data (PAN plus expiry, name, service code), sensitive authentication data (full track, CAV2/CVC2/CVV2/CID, PIN blocks), and SAD is never permitted post-authorization.

CDE (cardholder data environment) = systems that store, process, or transmit CHD/SAD plus connected-to or security-impacting systems; scoping reduces both assessment effort and ongoing cost.

Cloud scope decision rule: any IaaS/PaaS/SaaS component that touches CHD, or can affect the security of a component that does, is in scope unless segmentation or compensating controls are validated.

PAN masking is not truncation for scope purposes: display shows first six/last four max, but stored data is still CHD unless irreversibly truncated, tokenized, or hashed with strong cryptography.

Requirement 12.5.2.1 (v4.0) requires at least every 12 months a documented confirmation that personnel follow security policies and procedures; v4.0 future-dated requirements became mandatory 31 March 2025.

The cloud provider's own PCI DSS AOC covers its service, not the customer's configuration; the customer remains responsible for its own CDE and for validating the provider's scope covers the service used.

SAQ selection depends on channel and architecture (e.g., SAQ A for fully outsourced e-commerce, SAQ D for service providers and most custom cloud integrations); the AOC and ROC are the evidence of validation.

Shared responsibility is contractual, not a PCI DSS construct: the Responsibility Matrix or equivalent must state, control by control, which party implements each of the 12 requirements.

Provider AOC scope check: confirm the assessed service name, the PCI DSS version, the AOC validity dates, and whether the specific service tier you use is listed.

Reusable provider evidence: AOC, ROC summary, responsibility matrix, pen test attestations, and SOC 2 reports; the customer still must evidence its own controls on top of provider controls.

For SaaS fully managing CHD, the customer typically retains Requirement 12 obligations (policy, risk assessment, training, incident response, vendor management) and any customer-side access control.

For IaaS, the customer usually owns the guest OS, middleware, application, data, IAM configuration, logging, and vulnerability management; the provider owns physical and hypervisor layers.

Requirement 12.8 (v4.0) requires a TPSP inventory, written agreements with acknowledgment of responsibility, due diligence, and at least annual review; 12.8.4 requires monitoring of TPSP PCI DSS compliance status.

Requirement 12.9.2 requires providers to support their customers' PCI DSS compliance; absence of that written support is a scoping risk, not merely a documentation gap.

If a provider cannot evidence PCI DSS for a component in scope, the customer must either scope it out by architecture/segmentation or apply compensating controls with documented, tested evidence.

Segmentation purpose: reduce the CDE and its assessment scope; segmentation must be validated by penetration testing (Requirement 11.4.5) at least annually and after significant changes.

PCI DSS Requirement 1.3 restricts all traffic into and out of the CDE; 1.4 requires controls between trusted and untrusted networks, and 1.5 applies to all cloud computing environments.

Cloud segmentation primitives: VPC/VNet, subnets, security groups/NACLs, route tables, private endpoints, WAF, and host firewalls; network policies must deny by default and be documented.

Shared-hosting risk: on flat networks, all co-located workloads become connected-to systems; segmentation must be enforced by infrastructure controls, not by convention or naming.

Requirement 1.4.2: inbound traffic from untrusted networks to the CDE is limited to necessary ports/protocols; 1.4.3: no direct public access between CDE and internet, with DMZ or equivalent.

Requirement 2.2 hardening standards must cover every system component type in scope, including cloud-native services; configuration baselines must be documented and reviewed at least annually.

Requirement 4.2.1 requires strong cryptography and security protocols for PAN transmission over open, public networks; internal segmentation does not remove this obligation.

Compensating controls are valid only when a requirement cannot be met due to a legitimate technical or documented business constraint; they must meet the intent of the requirement and be reviewed at least annually.

Requirement 3.5.1.2 (v4.0) requires key management procedures covering generation, distribution, storage, rotation, retirement, and destruction, with documented cryptographic architecture.

Key custodian model: split knowledge and dual control apply to clear-text key components; in cloud KMS, map these to IAM separation of duties and multi-party approval workflows.

Requirement 3.6.1.1 covers key-management policies; 3.6.1.2 covers secret/private key protection; 3.6.1.3 covers key distribution to custodians; 3.6.1.4 covers key changes at defined cryptoperiods.

Requirement 3.5.1.1: PAN is rendered unreadable wherever stored (encryption, truncation, tokenization, one-way hash); hashing requires strong cryptography over the whole PAN with a keyed or salted approach.

Envelope encryption: data keys encrypt data, key-encryption keys wrap data keys in a KMS/HSM; the master key never leaves the HSM boundary, reducing exposure surface.

Requirement 3.5.1.2 also requires that key-encrypting keys be at least as strong as data-encrypting keys and that keys are not stored with the data they protect.

Requirement 3.2.1 prohibits storing SAD after authorization, even encrypted; this is an absolute rule with no compensating control path.

Key rotation triggers: cryptoperiod expiry, suspected compromise, personnel change with key access, and algorithm deprecation; rotation evidence is a common assessment gap in cloud KMS.

Requirement 7 restricts access by business need-to-know; 7.2.1 requires an access control model with defined roles; 7.2.2 requires least privilege for all access, including cloud console and API access.

Requirement 8.3.6: passwords/phrases must be at least 12 characters (v4.0); 8.3.9 requires change at least every 90 days for non-MFA accounts or when compromise is suspected.

Requirement 8.4.2 requires MFA for all access into the CDE; 8.4.3 requires MFA for all remote network access originating from outside the entity's network.

Requirement 8.5.1: MFA factors must not be shared or reused; 8.6 covers application and system account management, including interactive login prohibition for system accounts.

Privileged access: use just-in-time elevation, break-glass accounts with break-glass logging, and separate admin identities; root/global admin accounts must be inventoried and monitored.

Requirement 10.2 requires audit logs for all access to CHD, root/administrative actions, access to audit logs, invalid access attempts, and changes to identification/authentication/authorization controls.

Requirement 10.4.2.1 (v4.0): review logs of all security events at least daily; automated mechanisms such as SIEM alerting are permitted if documented and tuned.

Requirement 10.5.1 requires retention of at least 12 months, with at least 3 months immediately available for analysis; cloud log storage lifecycle policies must reflect this.

Requirement 11.3.1: internal vulnerability scans at least every 3 months; 11.3.2: external scans at least every 3 months by a PCI SSC ASV.

Requirement 11.3.1.1 (v4.0) requires authenticated internal scans; 11.3.2.1 requires external scans to be performed after any significant change, not just quarterly.

Requirement 6.3.1: critical/high vulnerabilities are ranked and addressed within a defined timeframe; 6.3.3 requires all system components to be protected against known vulnerabilities via patching.

Requirement 6.3.2: bespoke and custom software is reviewed at least annually and after changes to identify vulnerabilities (manual or automated code review).

Requirement 5.2.1: anti-malware is deployed on all system components except those whose configuration explicitly precludes it (e.g., some containerized/immutable workloads), with documented periodic evaluation.

Requirement 11.4.1: penetration testing methodology defined and industry-accepted; 11.4.2: internal pen test at least annually; 11.4.3: external pen test at least annually.

Requirement 11.4.5 (v4.0): segmentation controls and methods are tested at least every 6 months and after any change to segmentation controls.

Cloud patch ownership split: provider patches managed services and hypervisor; customer patches guest OS, containers, middleware, and application dependencies; evidence must show both sides.

Requirement 10.3.3: audit logs are promptly backed up to a central log server or equivalent that is difficult for the originating system to alter or delete.

Requirement 10.3.4: file integrity monitoring on audit logs; 10.3.4.1 requires FIM change alerts to be reviewed and investigated, with a documented response process.

Requirement 10.6.1 (v4.0) requires time synchronization technology across all system components, with a documented, consistent time-synchronization mechanism.

Requirement 12.10.1: incident response plan covers roles, communication, containment, escalation, and notification; 12.10.2: reviewed at least annually.

Requirement 12.10.5: incident response plan is monitored and responded to at least annually (e.g., tabletop exercise or simulation).

Requirement 12.10.6 (v4.0): incident response procedures are updated based on lessons learned and industry developments.

Requirement 12.10.4: security incident response personnel are available on a 24/7 basis; cloud on-call rotations and escalation paths are evidence for this.

Cloud log sources to include: control-plane audit logs (e.g., CloudTrail, Activity Log), data-plane access logs, VPC flow logs, WAF logs, KMS key-use logs, and identity provider sign-in logs.

Validation types: SAQ (self-assessment for eligible merchants/service providers), ROC (Report on Compliance for Level 1), and AOC (Attestation of Compliance summarizing results).

Level 1 service providers and Level 1 merchants require an annual ROC by a QSA plus an AOC; Level 2 providers typically use an SAQ plus AOC.

Evidence for cloud controls: configuration exports, IaC policy-as-code results, change tickets, screenshots with timestamps, and log extracts; evidence must cover the full assessment period, not a snapshot.

Sampling in assessments: PCI DSS allows sampling of system components and business facilities where populations are homogeneous; the QSA defines the sample, and cloud auto-scaling populations must be sampled representatively.

Segmentation testing evidence (11.4.5) must show the test was performed by a qualified internal resource or QSA, at least every 6 months, and after segmentation changes.

The ROC/AOC is valid for the assessment period stated; customers should verify validity dates and that the provider's assessed scope matches the service consumed.

Compensating control worksheets must include the constraint, the objective, the identified risk, the control definition, validation, and maintenance; review annually.

Gap analysis before assessment: map each requirement to a control owner and evidence artifact; missing evidence is treated as a control failure regardless of actual practice.

Requirement 12.1 establishes a security policy, reviewed at least annually, that is published, communicated, and owned by a designated security-responsible executive (12.1.2, 12.1.3).

Requirement 12.3.1 (v4.0) requires targeted risk analyses for each PCI DSS requirement, performed at defined frequency and after significant changes.

Requirement 12.3.4 requires a formal, documented risk assessment of the CDE performed at least annually and upon significant changes.

Requirement 12.4 defines responsibilities for PCI DSS compliance across the entity, including a charter for the security team and assignment of roles.

Requirement 12.6.1: a security awareness program is reviewed at least annually; 12.6.2: personnel receive training upon hire and at least annually.

Requirement 12.8.1: maintain a list of TPSPs with a description of the service and which requirements they manage; 12.8.2: written agreements define TPSP responsibilities.

Requirement 12.8.4: at least annually monitor TPSP PCI DSS compliance status; 12.8.5: maintain information about which PCI DSS requirements are managed by each TPSP and which by the entity.

Requirement 12.10.7 (v4.0): incident response procedures are in place for immediate compromise of PANs, covering detection and reporting to payment brands and acquirers.