PCI-DSS 4.0 on Azure: Isolating the Payment Enclave to Keep Assessment Scope Small

The common mistake: scope expansion

Payments startups integrating with acquiring banks usually face a QSA before they go live. In payment infrastructure, compliance scope drives cost and effort. Under PCI-DSS v4.0, a system that can communicate with servers that store, process, or transmit Primary Account Numbers (PAN) is treated as connected to the cardholder data environment (CDE) and falls into assessment scope unless segmentation controls isolate it.

A common pattern in early-stage payment platforms is a single Azure virtual network where the analytics cluster, marketing microservices, and tokenization database sit in adjacent subnets with no filtering between them. Without segmentation controls, an assessor has no basis to exclude the neighboring systems, so each of them must meet the applicable PCI-DSS requirements.

That widens evidence collection and lengthens the assessment, which is why segmentation is worth doing before the assessor arrives rather than after.

The architecture: ring-fencing the CDE

The core of an Azure payment enclave design is four decisions:

• A dedicated management group. The CDE subscription sits in its own management group branch, so stricter enclave policies apply there on top of the platform baseline without affecting other workloads.
• No public endpoints. Databases and Key Vaults have public network access disabled and are reachable only through Private Link private endpoints.
• Keys in Key Vault Managed HSM (Requirement 3). Customer-managed encryption keys are held in FIPS 140-2 Level 3 validated HSMs, with key rotation policies.
• Tamper-resistant audit logging (Requirement 10). Diagnostic logs go to Log Analytics for analysis and are archived to storage with an immutability policy. PCI-DSS 4.0 asks for at least twelve months of audit log history, with the most recent three months immediately available (Requirement 10.5.1).

Deny-mode policy enforcement

Several PCI-DSS 4.0 requirements translate directly into Azure Policy rules, such as strong cryptography for data in transit (Requirement 4.2.1) and protection of public-facing web applications (Requirement 6.4). These can be enforced with deny-effect policies in Azure Resource Manager. Multi-factor authentication into the CDE (Requirement 8.4) is enforced through Entra ID Conditional Access rather than Azure Policy.

Here is one such rule, which refuses any Azure SQL server that allows TLS below 1.2:

{
  "policyRule": {
    "if": {
      "allOf": [
        { "field": "type", "equals": "Microsoft.Sql/servers" },
        { "field": "Microsoft.Sql/servers/minimalTlsVersion", "notEquals": "1.2" }
      ]
    },
    "then": { "effect": "deny" }
  }
}

What the QSA checks

Segmentation only reduces scope if the assessor can verify it. PCI-DSS 4.0 requires segmentation controls to be confirmed by penetration testing (Requirement 11.4.5), so the enclave boundary has to hold up under test, not just on a diagram.

A control traceability matrix that maps each Azure Policy assignment and network control to the PCI-DSS requirement it supports lets the QSA trace a requirement to live configuration.