Definition

PCI DSS on cloud infrastructure requires a precise mapping of all 12 requirements (and their sub-requirements) against the shared responsibility model of the cloud service provider (CSP), distinguishing controls that are fully inherited (e.g., AWS physical security → Requirement 9.1), shared (e.g., OS patching → Requirement 6.3.3), and customer-owned (e.g., application-layer WAF → Requirement 6.4.2). The CSP's own AoC and the published Customer Responsibility Matrix (CRM) are the foundational documents for this exercise.

Why it matters

The pressure on PCI DSS v4.0 programmes is shifting in specific, observable ways:

• AWS, Azure, and OCI each publish PCI DSS AoCs and CRMs; QSAs must verify that the customer's RoC only claims inherited controls that appear as 'AWS Responsibility' in the AWS PCI CRM — mismatches are a top RoC finding.
• Requirement 12.8.2 requires a written agreement with all TPSPs including CSPs; the CSP Terms of Service alone does not satisfy this — a separate PCI addendum or Order Form referencing the AoC is required.
• Cloud-native CDEs on OCI (used by several UAE government-linked payment processors) require mapping Requirement 10.2 log management to OCI Logging Analytics, which stores logs outside the CDE — a scope clarification that QSAs must accept in writing.
• Multi-cloud CDE architectures (AWS + Azure) double the CRM reconciliation workload; without a unified control inventory tool (e.g., Wiz, Orca Security), gaps in Requirement 6.3.3 patch compliance are routinely missed.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• CSP PCI DSS AoC (latest version) — downloaded from AWS Artifact, Azure Service Trust Portal, or OCI Compliance Documents; version and issue date recorded
• CSP Customer Responsibility Matrix — requirement-level split table; annotated with customer's inherited vs. owned control decision
• TPSP written agreement / PCI addendum — contract reference, PCI DSS version, AoC linkage clause, and annual renewal date
• Cloud security posture management (CSPM) tool findings (Wiz or Orca) — control ID, resource, compliance status, and last-assessed date
• Penetration test report for cloud-hosted CDE — scope confirmation that cloud management plane and inter-region traffic were in scope per Requirement 11.4.3

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: Cloud Architect downloads the current PCI CRM for AWS/Azure/OCI and maps each of the 12 Requirements to a three-column matrix: CSP-owned, shared, customer-owned.
• Day 31–60: Security Engineer deploys CSPM tool (Wiz or Prisma Cloud) across all CDE AWS accounts/Azure subscriptions; runs PCI DSS v4.0 compliance benchmark and exports findings.
• Day 61–90: Legal reviews CSP contracts and adds PCI DSS TPSP addendum referencing the AoC per Requirement 12.8.2; obtains counter-signature from AWS/Azure account manager.
• Day 90+: QSA reviews completed cloud control matrix and CSPM evidence during RoC fieldwork; customer-owned gaps remediated and evidenced before AoC issuance.
• Ongoing: Re-download CSP AoC annually; re-run CSPM benchmark monthly and track open findings by Requirement ID on CISO dashboard.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• Control inheritance accuracy — 100% of 'inherited' controls validated against current CSP CRM at each RoC; zero unjustified inheritance claims
• CSPM PCI benchmark pass rate — target ≥90% of cloud resources compliant; critical findings (Requirement 6.3.3, 10.2, 1.3) remediated within 7 days
• TPSP agreement coverage — 100% of CSPs and SaaS providers with a signed PCI addendum on file before RoC fieldwork
• Cloud patch compliance (Requirement 6.3.3) — target ≥98% of CDE VMs within 30 days of critical patch availability
• Log retention in cloud (Requirement 10.7) — 100% of CDE audit logs retained for 12 months with 3 months immediately available in OCI Logging Analytics or Azure Monitor

A the next two quarters working plan

MAST Consulting Group runs this PCI DSS v4.0 work in four moves. Each move is short, evidence-producing, and signed off by a Lead Practitioner before the next begins.

• Frame (week 1). Confirm scope, regulators in play, and the decisions the work has to enable — referenced against the 12 PCI DSS v4.0.1 requirements. Without that framing, the rest becomes a documentation exercise the audit committee will not read.
• Diagnose (weeks 2–4). Walk through Attestation of Compliance and network and dataflow diagrams as they exist today. Capture not just gaps but the design decisions behind every existing control — those are usually where audit findings hide.
• Design (weeks 5–8). Make the contested choices early and pre-clear them with the PCI Security Standards Council. Document the rationale; PCI DSS v4.0 reviewers care more about reasoned decisions than perfect ones.
• Operate (weeks 9–12). Move evidence collection into network segmentation testing tools and FIM (Tripwire, OSSEC, Wazuh). A control that depends on a separate GRC tool nobody opens will fail within two cycles.

Pitfalls we keep seeing

Across MAST Consulting Group's PCI DSS v4.0 portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: shared admin accounts that survive into production. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: logging that records the event but not the actor. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: CDE diagrams that don't match what segmentation testing finds. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: ASV scans with carried-over false positives that were never re-validated. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on PCI DSS v4.0 engagements because the integrations are cheap and the evidence is defensible:

• SIEM (Splunk, Sentinel, Chronicle) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• tokenisation gateways from acquirers and PSPs — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• network segmentation testing tools — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs PCI DSS v4.0 programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this playbook is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for PCI DSS v4.0 programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.