Skip to main content
Microsoft Solutions Partner — Security · 11,000+ engagements

PCI DSS 4.0 Microsoft Consulting Enterprise Guide (2026)

PCI DSS 4.0 compliance on the Microsoft tech stack — 12 requirement areas mapped to Entra ID, Defender XDR, Purview, Sentinel, Intune, and Azure Key Vault HSM by a senior-architect-led Microsoft Solutions Partner founded in 1997.

What is PCI DSS 4.0 and how do enterprises achieve compliance on Microsoft? PCI DSS 4.0 is the Payment Card Industry Data Security Standard published by the PCI Security Standards Council, with full enforcement that began March 31 2024 and a final transition deadline of March 31 2025 for future-dated requirements. It defines twelve requirement areas across network security, secure configuration, cardholder data protection, encryption, malware defense, secure development, access control, authentication, physical security, logging and monitoring, security testing, and governance. On the Microsoft tech stack, Entra ID Conditional Access and PIM satisfy Requirements 7 and 8, Defender XDR satisfies Requirement 5 and feeds Requirement 10, Microsoft Purview satisfies Requirement 3 (data protection), Microsoft Sentinel satisfies Requirement 10 (logging and monitoring), Intune satisfies Requirement 2 (secure configuration), and Azure Key Vault HSM satisfies Requirement 3.6 (cryptographic key management). EPC Group delivers it through a five-phase Scope, Gap, Implement, Validate, Sustain accelerator at fixed fee.

PCI DSS 4.0 is the current Payment Card Industry Data Security Standard with full enforcement that began March 31 2024. On the Microsoft tech stack, Entra ID + Conditional Access + PIM satisfy Requirements 7 and 8, Defender XDR satisfies Requirement 5 and feeds Requirement 10, Purview satisfies Requirement 3, Sentinel satisfies Requirement 10, Intune satisfies Requirement 2, and Azure Key Vault HSM satisfies Requirement 3.6. EPC Group delivers a fixed-fee five-phase Accelerator covering Scope, Gap, Implement, Validate, and Sustain.

Key Facts

  • PCI DSS 4.0 has 12 requirement areas with more than three hundred sub-requirements across defined and customized approaches
  • Mandatory MFA for all non-console administrative access and all access into the CDE — phishing-resistant MFA preferred
  • Cardholder Data Environment (CDE) scope is the single biggest cost driver — tokenization-first design collapses scope materially
  • Microsoft Entra ID Conditional Access, PIM, and ID Governance satisfy Requirements 7 and 8 natively
  • Azure Key Vault Premium provides FIPS 140-3 Level 3 validated HSMs for Requirement 3.6 cryptographic key management
  • Microsoft Sentinel and Purview Audit Premium provide centralized logging and one-year-plus retention for Requirement 10
  • Microsoft Solutions Partner founded in 1997, 70+ Fortune 500 clients, 216+ M&A tenant consolidations
  • EPC Group five-phase PCI DSS Accelerator delivers an Attestation of Compliance in 24 to 38 weeks, fixed fee scoped after a discovery call

The 12 PCI DSS 4.0 requirement areas mapped to Microsoft platforms

PCI DSS 4.0 organizes more than three hundred sub-requirements into twelve high-level areas. Each area maps to specific Microsoft platform capabilities — every enterprise CDE on Microsoft activates the controls below, sequenced through the EPC Group five-phase accelerator so the QSA receives evidence in the format they prefer.

Requirement 1

Install and maintain network security controls

What it requires: Network segmentation and firewall controls that isolate the Cardholder Data Environment (CDE) from out-of-scope networks. PCI DSS 4.0 expanded this from traditional firewalls to any network security control — including cloud-native security groups, Web Application Firewalls, and microsegmentation.

  • Azure Firewall Premium with TLS inspection, IDPS, and threat intelligence-based filtering
  • Azure Network Security Groups and Application Security Groups for east-west microsegmentation
  • Azure Web Application Firewall on Application Gateway or Front Door for public-facing CDE entry points
  • Azure Virtual Network peering with deny-by-default rules between CDE and out-of-scope subnets
  • Microsoft Defender for Cloud network security posture management with PCI DSS regulatory dashboard
  • Azure DDoS Protection Standard for public-facing CDE workloads

Notes: PCI DSS 4.0 requires documented network diagrams and data-flow diagrams that are refreshed at least annually and after every significant change. EPC Group ships these as living documents in Microsoft Visio with version control in SharePoint.

Requirement 2

Apply secure configurations to all system components

What it requires: Hardened build standards for every component in the CDE — operating systems, databases, web servers, hypervisors, and network appliances. PCI DSS 4.0 requires that defaults be changed, unnecessary services be disabled, and configurations be tracked against an approved baseline.

  • Microsoft Defender for Cloud secure configuration baselines mapped to CIS, NIST, and Microsoft Cloud Security Benchmark
  • Azure Policy and Azure Blueprints to enforce baseline configurations as code
  • Microsoft Intune device configuration profiles for workstations and mobile devices in CDE scope
  • Azure Automation State Configuration (DSC) for Windows and Linux drift prevention
  • Microsoft Defender Vulnerability Management for missing patch and misconfiguration detection
  • Microsoft Sentinel watchlists tracking approved component inventory with deviation alerting

Notes: PCI DSS 4.0 introduced the concept of customized approaches alongside defined approaches. EPC Group documents both paths so the QSA reviews evidence in the format they prefer rather than the format the customer guessed at.

Requirement 3

Protect stored account data

What it requires: Cardholder data at rest must be unreadable wherever it is stored. PCI DSS 4.0 sharpened the cryptographic key management requirements and added stricter controls for Sensitive Authentication Data (SAD) — which generally must not be stored at all after authorization.

  • Azure Key Vault Premium with FIPS 140-3 Level 3 validated Hardware Security Modules for key custody
  • Azure Storage and Azure SQL Database transparent data encryption with customer-managed keys
  • Microsoft Purview Data Map and Data Catalog for cardholder data discovery and classification
  • Microsoft Purview Information Protection sensitivity labels enforcing encryption at the file level
  • Microsoft Purview DLP policies blocking PAN in email, Teams, SharePoint, and endpoints
  • Azure Confidential Computing with Intel SGX or AMD SEV-SNP for in-memory cardholder data isolation

Notes: EPC Group recommends a tokenization service in front of the cardholder data store wherever feasible. If the data the application sees is a token rather than a Primary Account Number, the application server falls out of CDE scope and the audit shrinks materially.

Requirement 4

Protect cardholder data with strong cryptography during transmission

What it requires: Cardholder data in transit across open or public networks must use strong cryptography and authenticated protocols. PCI DSS 4.0 made TLS 1.2 the floor and is on a glide-path toward TLS 1.3 as the expected default.

  • Azure Front Door and Application Gateway with TLS 1.2 minimum, TLS 1.3 preferred, and certificate management automated
  • Azure Key Vault managed certificates with automatic rotation and renewal
  • Microsoft Exchange Online and SharePoint Online enforce TLS 1.2+ for all email and collaboration traffic
  • Azure VPN Gateway with IKEv2 and AES-GCM for site-to-site connectivity from on-premises CDE
  • Microsoft Defender for Cloud certificate inventory and expiration monitoring with Sentinel alerting
  • Azure API Management policies enforcing mutual TLS for partner and acquirer integrations

Notes: Wireless networks in or adjacent to the CDE require WPA2-Enterprise minimum with PCI DSS 4.0 strongly recommending WPA3. EPC Group ships an Intune Wi-Fi profile pattern enforcing this across managed devices.

Requirement 5

Protect all systems and networks from malicious software

What it requires: Endpoint and server protection covering anti-malware, behavioral detection, and removable media controls. PCI DSS 4.0 explicitly recognized that next-generation EDR and behavior-based detection meet the requirement, not just legacy signature-based antivirus.

  • Microsoft Defender for Endpoint with EDR in block mode and tamper protection enforced
  • Microsoft Defender for Office 365 Plan 2 for email-borne malware, phishing, and Safe Attachments / Safe Links
  • Microsoft Defender for Cloud Apps governing shadow IT discovery and SaaS data exfiltration paths
  • Microsoft Intune device compliance policies enforcing Defender presence and current definitions
  • Microsoft Defender Antivirus with Attack Surface Reduction (ASR) rules in enforcement mode
  • Microsoft Defender XDR automated investigation and response for CDE-scoped device groups

Notes: PCI DSS 4.0 requires periodic evaluation of any system components considered not at risk from malware — EPC Group documents this evaluation as a Sentinel workbook so it refreshes continuously rather than as a one-time spreadsheet.

Requirement 6

Develop and maintain secure systems and software

What it requires: Secure software development lifecycle, vulnerability identification, change control, and protection of public-facing applications. PCI DSS 4.0 added bespoke and custom software inventory requirements and significantly expanded change control documentation.

  • Microsoft Defender for DevOps integrating GitHub Advanced Security and Azure DevOps scanning into Defender for Cloud
  • GitHub Advanced Security with CodeQL static analysis, Dependabot, and secret scanning enabled across CDE repositories
  • Microsoft Defender Vulnerability Management with CVSS-based prioritization and Sentinel ticketing integration
  • Azure WAF Bot Manager and managed ruleset (OWASP Top 10) for public-facing CDE applications
  • Azure DevOps Boards and Pipelines change-control evidence (work item linkage, approvals, deployment gates)
  • Microsoft Purview compliance manager PCI DSS 4.0 assessment template tracking control implementation status

Notes: PCI DSS 4.0 Requirement 6.4.3 introduced a payment-page script integrity requirement that is among the toughest changes for e-commerce merchants. EPC Group implements a Subresource Integrity and Content Security Policy pattern with Defender for Cloud Apps monitoring.

Requirement 7

Restrict access to system components and cardholder data by business need to know

What it requires: Least-privilege access control, role-based authorization, and documented access matrices. Every account with access to the CDE must have its access justified, reviewed, and re-certified on a defined cadence.

  • Microsoft Entra ID Conditional Access enforcing risk-based and device-compliant access to CDE applications
  • Microsoft Entra Privileged Identity Management (PIM) with just-in-time activation for CDE administrators
  • Microsoft Entra ID Governance access reviews on a quarterly cadence with manager attestation
  • Microsoft Entra entitlement management packaging CDE roles into reviewable access packages
  • Azure RBAC with custom roles scoped to CDE subscriptions, resource groups, or resources only
  • Microsoft Purview Insider Risk Management for unusual cardholder-data access pattern detection

Notes: EPC Group ships a CDE Access Matrix as a Power BI report sourced from Microsoft Graph, Entra ID Governance, and Azure RBAC so the matrix refreshes automatically rather than living as a stale spreadsheet at audit time.

Requirement 8

Identify users and authenticate access to system components

What it requires: Unique identification of every user, multi-factor authentication for all access to the CDE (no exceptions for trusted networks), and strong password and session management. PCI DSS 4.0 was the requirement most impacted by MFA changes — MFA is now mandatory for all non-console administrative access and all access into the CDE.

  • Microsoft Entra ID with phishing-resistant MFA (Windows Hello for Business, FIDO2 keys, certificate-based authentication)
  • Microsoft Entra Conditional Access policies enforcing MFA for every CDE application sign-in
  • Microsoft Entra Password Protection with custom banned-password lists for cardholder data administrators
  • Microsoft Entra ID Protection risk-based sign-in and user risk policies forcing re-authentication
  • Microsoft Authenticator app with number matching and additional context for phishing resistance
  • Microsoft Entra Workload Identities and managed identities for non-human CDE access without shared secrets

Notes: PCI DSS 4.0 explicitly forbids storing or transmitting passwords in cleartext. EPC Group audits Azure Key Vault, GitHub Actions secrets, and Azure DevOps variable groups during Phase 2 to ensure no plaintext credentials remain in pipelines or configuration stores.

Requirement 9

Restrict physical access to cardholder data

What it requires: Controls over physical facilities, media handling, point-of-sale device monitoring, and visitor management. For cloud-first merchants, much of this requirement transfers to the Microsoft data center — but POS device monitoring, on-premises payment processing rooms, and removable media handling remain customer responsibilities.

  • Microsoft Azure data centers — ISO 27001, SOC 1/2/3, and PCI DSS 3.2 audited; PCI DSS 4.0 attestation in flight
  • Microsoft Cloud Shared Responsibility Matrix documenting which controls Microsoft owns vs customer
  • Microsoft Intune Endpoint DLP blocking USB write to removable media on CDE-scoped devices
  • Microsoft Defender for Endpoint device control policy restricting USB device classes
  • Microsoft Purview Audit logging file copy to removable media events with Sentinel alerting
  • Azure IoT Central or Defender for IoT for connected POS device telemetry and tamper detection

Notes: EPC Group provides a Shared Responsibility evidence package mapping each PCI DSS 4.0 sub-requirement to Microsoft attestations from the Service Trust Portal — saving weeks of QSA evidence-gathering compared to building it from scratch.

Requirement 10

Log and monitor all access to system components and cardholder data

What it requires: Comprehensive audit logging across every component touching the CDE, log integrity protection, daily log review, and one-year minimum retention. PCI DSS 4.0 elevated automated log review from recommendation to expectation — manual daily review at scale is no longer credible to QSAs.

  • Microsoft Sentinel as the centralized SIEM ingesting Microsoft 365, Entra ID, Defender XDR, Azure resource logs, and on-premises Syslog
  • Microsoft Purview Audit Premium with one-year default retention (configurable to ten years) and PCI-relevant crucial events
  • Microsoft Sentinel analytics rules implementing PCI DSS 4.0 detection use cases (privileged access, cardholder data access, configuration change)
  • Microsoft Defender XDR unified incident view across endpoint, identity, cloud apps, and Office 365 for CDE-scoped assets
  • Azure Monitor Log Analytics workspace with immutable storage for log integrity protection
  • Microsoft Sentinel workbooks providing daily log review dashboards and Power Automate exception ticketing

Notes: The Sentinel hub at /microsoft-sentinel-siem-enterprise-2026 covers ingestion economics, analytics engineering, and SOAR — all of which apply directly to the PCI DSS 4.0 Requirement 10 monitoring program.

Requirement 11

Test security of systems and networks regularly

What it requires: Vulnerability scanning, penetration testing, intrusion detection, and file integrity monitoring. PCI DSS 4.0 added authenticated internal vulnerability scanning and tightened external Approved Scanning Vendor (ASV) cadence.

  • Microsoft Defender Vulnerability Management for authenticated internal scanning with CVSS and threat intelligence prioritization
  • Microsoft Defender for Cloud regulatory compliance dashboard with PCI DSS scoring and remediation guidance
  • Microsoft Sentinel and Defender for Cloud Threat Intelligence correlating IDS, anomaly, and Fusion alerts for CDE assets
  • Azure DDoS Protection Standard providing always-on traffic monitoring and adaptive mitigation
  • Microsoft Defender for Endpoint file integrity monitoring (FIM) on CDE servers with Sentinel alerting
  • Microsoft Purview Change Analysis tracking configuration drift across Azure resources

Notes: EPC Group coordinates external ASV scanning with a partner vendor on the PCI Council ASV list, then chains scan results into Defender Vulnerability Management for unified remediation tracking and Sentinel-fed SLA reporting.

Requirement 12

Support information security with organizational policies and programs

What it requires: The governance umbrella — security policy, risk assessment, third-party management, incident response plan, security awareness training, and PCI DSS program governance. PCI DSS 4.0 added a Targeted Risk Analysis (TRA) requirement for every customized control.

  • Microsoft Purview Compliance Manager PCI DSS 4.0 assessment template with task assignment and evidence linkage
  • Microsoft Purview Insider Risk Management policies covering data exfiltration, departing user, and privacy violations
  • Microsoft Defender XDR incident response playbooks for CDE-scoped breach response
  • Microsoft Sentinel SOAR Logic Apps playbooks for automated containment of CDE incidents
  • Microsoft 365 SharePoint for policy publishing, training records, and Targeted Risk Analysis evidence
  • Microsoft Viva Learning with annual mandatory PCI DSS and cardholder-data-handling training tracked per user

Notes: PCI DSS 4.0 introduced Targeted Risk Analyses as a defined deliverable. EPC Group ships a TRA template with every customized approach we recommend so the QSA has the documentation to accept the approach without re-litigation.

Microsoft Platform Mapping

The Microsoft control stack — every PCI DSS 4.0 area has a native owner

PCI DSS 4.0 maps directly into the Microsoft security and compliance product family. Each platform component owns a primary set of requirements and feeds evidence into Microsoft Purview Compliance Manager, where the QSA reviews status in the format they prefer. The full Sentinel hub at the Microsoft Sentinel SIEM + SOAR enterprise guide and the Defender XDR hub at the Microsoft Defender XDR enterprise guide cover those two platforms in depth. Purview deep coverage at the Microsoft Purview enterprise data governance guide and Entra ID at the Microsoft Entra ID enterprise guide.

Entra ID + Conditional Access + PIM

Requirements 7, 8 — access control and authentication, MFA, PIM

Microsoft Defender XDR

Requirements 5, 10 — malware protection, EDR, unified incident management

Microsoft Purview (audit, DLP, IRM)

Requirements 3, 9, 10 — data protection, audit, DLP, insider risk

Microsoft Sentinel SIEM

Requirements 10, 11 — centralized logging, analytics, SOAR

Microsoft Intune

Requirements 2, 5, 9 — secure configuration, endpoint compliance, removable media

Azure Key Vault Premium / HSM

Requirement 3 — cryptographic key custody, FIPS 140-3 Level 3

Azure Firewall + WAF

Requirements 1, 6 — network security controls, public-facing application protection

Defender for Cloud + Defender for DevOps

Requirements 2, 6, 11 — posture management, DevSecOps, scanning

Azure App Service Environment v3 / Container Apps

Requirement 6 — secure hosting for payment workloads

Cardholder Data Environment (CDE) scope minimization patterns

Audit cost and complexity are dictated by what is in CDE scope. Every enterprise PCI DSS engagement EPC Group runs starts with a scope-reduction workshop using one or more of the five patterns below. Tokenization-first design is the single highest- leverage move, often cutting scope by sixty percent or more.

Pattern 1 — Tokenization-first scope minimization

The single most powerful scope-reduction lever is to never store the Primary Account Number (PAN) in customer systems at all. EPC Group designs around a tokenization service from the payment processor or a standalone token vault. The application server, database, log store, backup tier, and downstream analytics platforms all see only the token. The CDE collapses to the tokenization service itself, the network path between the payment page and the tokenizer, and the small number of administrative consoles that touch the vault. Audit scope drops from hundreds of systems to a single-digit number of components. EPC Group has executed this pattern with merchants taking annual card-not-present transaction volumes from low millions to high tens of millions and has cut the QSA Report on Compliance (ROC) from three months of fieldwork to four to six weeks.

Pattern 2 — Network segmentation isolating the CDE from corporate IT

Where tokenization is not feasible — closed-loop card programs, certain B2B settlement environments, or merchants with legacy applications that hold PAN — strong network segmentation is the next-best scope-shrinking lever. EPC Group designs an Azure landing zone where the CDE lives in dedicated subscriptions with deny-by-default Azure Firewall Premium between every subnet, Network Security Groups for east-west microsegmentation, Private Endpoints for Azure PaaS services in scope, and Conditional Access policies forbidding CDE access from non-compliant devices. The QSA reviews the segmentation evidence — firewall rules, NSG configurations, network diagrams, and penetration test results validating segmentation — to confirm that out-of-scope networks have no path to the CDE.

Pattern 3 — Cloud-native CDE on Microsoft Azure

For merchants standing up a new CDE or modernizing an aging one, a cloud-native design on Microsoft Azure compresses the build calendar and surfaces compliance-aligned defaults. EPC Group deploys an Azure landing zone with management group hierarchy separating CDE from out-of-scope subscriptions, Azure Policy enforcing the Microsoft Cloud Security Benchmark and PCI DSS-relevant guardrails, Azure Key Vault Premium for cryptographic operations, Azure SQL with customer-managed keys for cardholder data storage, Azure Container Apps or App Service Environment v3 for payment workloads, Defender for Cloud across every subscription, and Sentinel as the SIEM. Every component arrives with PCI-relevant audit logging configured by default.

Pattern 4 — Hybrid CDE bridging on-premises and Azure

Many enterprise merchants run hybrid CDEs where the merchant-of-record processing lives on-premises and the customer-facing e-commerce or mobile-app interfaces live in Azure. EPC Group designs ExpressRoute private connectivity between on-premises CDE and Azure, with Azure Firewall Premium inspecting traffic at the edge, Microsoft Defender for Identity covering the on-premises Active Directory plane, Microsoft Sentinel ingesting on-premises Syslog and Windows Event logs via Azure Monitor Agent, and Microsoft Defender for Endpoint protecting CDE servers in both environments. The architectural decision EPC Group walks every hybrid customer through is what stays on-premises, what migrates to Azure, and what sits in tokenization in between so the long-term scope shrinks rather than expanding.

Pattern 5 — PCI DSS overlay on FedRAMP / public-sector environments

Public-sector and federal contractor merchants accepting card payments in FedRAMP-aligned Azure Government environments combine PCI DSS 4.0, FedRAMP Moderate or High, and the NIST 800-53 Rev 5 control overlay into a single integrated control library. EPC Group ships a control-crosswalk matrix mapping every PCI DSS 4.0 sub-requirement to NIST 800-53 controls and Microsoft Cloud Security Benchmark recommendations. The QSA reviews the same evidence base the FedRAMP 3PAO already accepted, dramatically reducing duplicate work. The cross-link to our /standards-alignment hub covers the multi-framework crosswalk library.

The EPC Group PCI DSS Accelerator — five phases, fixed fee

The accelerator anchors on The EPC Group Lifecycle — Scope, Gap, Implement, Validate, Sustain. Fixed-scope, priced after a discovery call, depending on CDE complexity, regulatory overlay, and managed-service tail. Senior-architect led, no offshore handoff, named architect on-record from kickoff through QSA AOC submission.

Phase 1 — Scope

CDE definition, data-flow mapping, and scope-minimization design — 3 weeks

Phase one defines the Cardholder Data Environment as it actually exists today versus as it is documented to exist. EPC Group runs Microsoft Purview Data Map discovery against Azure data stores, Microsoft 365 SharePoint, and on-premises file shares, then traces every PAN flow through interview-driven workshops with engineering, customer service, and finance. The output is a current-state CDE map, a target-state CDE map applying tokenization and segmentation patterns, and a scope-reduction business case for the steering committee.

  • Cardholder data discovery via Microsoft Purview across Azure, Microsoft 365, and on-premises stores
  • Data-flow diagrams showing every PAN movement between systems with diagrams that update from live config
  • Current-state CDE inventory including every component, every administrator, and every connected system
  • Target-state CDE design applying tokenization, segmentation, and cloud-native scope-reduction patterns

Phase 2 — Gap

PCI DSS 4.0 gap assessment with QSA-aligned evidence inventory — 3 to 5 weeks

Phase two runs a full PCI DSS 4.0 gap assessment against the in-scope CDE, mapping every one of the more than three hundred sub-requirements to a current control status, an evidence source, and a gap remediation owner. EPC Group uses the Microsoft Purview Compliance Manager PCI DSS template as the system of record so progress is visible to leadership and the QSA throughout the engagement.

  • PCI DSS 4.0 sub-requirement-level assessment across all 12 requirement areas
  • Microsoft Purview Compliance Manager assessment populated with current control status and evidence links
  • Gap remediation backlog prioritized by QSA risk, business impact, and implementation effort
  • Customized approach versus defined approach decision matrix for sub-requirements where customization is warranted

Phase 3 — Implement

Microsoft platform configuration, automation, and control deployment — 12 to 20 weeks

Phase three is the engineering phase. EPC Group deploys the Microsoft control stack against the gap backlog — Entra ID Conditional Access for Requirement 8, Defender XDR for Requirement 5 and 10, Purview DLP and Information Protection for Requirement 3, Sentinel analytics rules for Requirement 10 and 11, Defender Vulnerability Management for Requirement 6 and 11, and Azure Key Vault HSM for Requirement 3 cryptographic key custody. Every configuration is captured as Infrastructure as Code in Azure DevOps or GitHub so the QSA can verify the configuration matches the documentation.

  • Entra ID Conditional Access policy set targeting CDE applications with phishing-resistant MFA
  • Microsoft Defender XDR + Sentinel detection content pack for PCI DSS Requirement 10 monitoring use cases
  • Microsoft Purview DLP, Information Protection, and Insider Risk Management for cardholder data protection
  • Azure Key Vault Premium HSM provisioned with PCI-relevant cryptographic key custody and rotation automation

Phase 4 — Validate

QSA collaboration, AOC drafting, and remediation closeout — 6 to 10 weeks

Phase four is the formal QSA engagement. EPC Group brings the evidence package — Microsoft Purview Compliance Manager assessment, Sentinel workbooks, Entra ID Conditional Access JSON exports, Azure Policy compliance state, Defender for Cloud regulatory compliance dashboard, and Azure DevOps change-control records — to the QSA in the format the QSA prefers. We staff a senior architect alongside the customer through every QSA evidence request, gap reproof, and Attestation of Compliance (AOC) draft cycle.

  • QSA evidence package delivered as a structured binder mapping each sub-requirement to Microsoft evidence sources
  • Daily QSA standup during fieldwork to resolve evidence questions and prevent reproof loops
  • Compensating control documentation where defined approach gaps cannot be closed within the audit period
  • AOC review with QSA, executive sponsor sign-off, and submission to acquirer or card brand as required

Phase 5 — Sustain

Continuous compliance, BAU operations, and annual recertification — ongoing

Phase five operationalizes PCI DSS 4.0 as a continuous program rather than an annual scramble. EPC Group stands up Microsoft Sentinel workbooks for ongoing compliance monitoring, Microsoft Purview Compliance Manager for control state refresh, scheduled Power BI reports for the steering committee, and a quarterly Targeted Risk Analysis cadence covering every customized control. Customers either operate the program internally with EPC Group as the architecture-on-call partner or hand the steady-state operation to EPC Group managed services.

  • Microsoft Sentinel continuous compliance workbook with PCI DSS scoring updated in near-real-time
  • Quarterly Targeted Risk Analysis cadence covering every customized approach control
  • Annual PCI DSS recertification readiness assessment 60 days ahead of audit window
  • Optional EPC Group managed PCI DSS service with senior-architect escalation and 24/7 SOC coverage
Pricing & Engagement Economics

PCI DSS 4.0 Accelerator pricing — fixed-fee, scoped after a discovery call

EPC Group prices the PCI DSS Accelerator as a fixed-fee engagement scoped to CDE complexity. The price band reflects scope drivers — tokenization scope-reduction difficulty, hybrid topology, regulatory overlay (FedRAMP, HIPAA, FINRA), administrator population size, and the SAQ versus ROC validation path. Every engagement includes a named senior architect from kickoff through AOC submission.

Foundation tier

Cloud-native CDE on Azure with tokenization-first design, SAQ-D self-assessment path, single-region deployment, fewer than 100 administrators in scope, no regulatory overlay beyond PCI DSS itself.

Enterprise tier

ROC validation path with a Level 1 merchant or major service provider profile, hybrid on-premises plus Azure topology, multi-region, 100 to 500 administrators, and one regulatory overlay (HIPAA or FINRA).

Regulated tier

Full ROC with FedRAMP Moderate or High overlay in Azure Government, multi-CDE topology, more than 500 administrators, multiple acquirer or card-brand reporting requirements, and EPC Group managed-PCI-DSS steady-state operation.

Included in every tier

Named senior architect on-record, fixed-fee with no T&M overruns, Microsoft Purview Compliance Manager assessment populated, Sentinel content pack deployed, Entra ID Conditional Access policy set, and QSA evidence binder.

Optional add-ons

Managed PCI DSS continuous compliance (annual retainer), 24/7 Sentinel SOC for CDE workloads, annual recertification readiness sprint, and Targeted Risk Analysis authoring service for customized approach controls.

QSA fees not included

QSA firm fees for the formal ROC or AOC review are paid directly by the customer to the QSA. EPC Group works with multiple PCI Council-approved QSAs and can broker introductions; QSA cost is set by the QSA firm and depends on scope.

QSA Collaboration

How EPC Group collaborates with your Qualified Security Assessor

The Qualified Security Assessor (QSA) is the independent firm authorized by the PCI Security Standards Council to validate compliance. EPC Group is not a QSA — by design. We are the implementation partner that designs, builds, and operates the Microsoft controls, then prepares the evidence package the QSA reviews. The separation matters because the QSA must remain independent. EPC Group’s job is to make the QSA’s job easy — and to make sure the customer never has to reverse-engineer a control implementation under audit pressure.

Pre-fieldwork preparation

EPC Group ships the QSA a pre-fieldwork evidence binder mapping every sub-requirement to a Microsoft evidence source. The QSA walks fieldwork knowing where every piece of evidence lives before the first interview.

Daily fieldwork standups

During QSA fieldwork, EPC Group runs a daily fifteen-minute standup with the QSA, the customer compliance lead, and the EPC senior architect to resolve evidence questions, surface gaps, and prevent reproof loops.

Customized approach defense

Where customized approach controls are used, EPC Group provides the Targeted Risk Analysis documentation in the format the QSA expects. The QSA reviews the customized approach without re-litigation.

Compensating control closeout

For gaps that cannot close within the audit window, EPC Group authors the compensating control documentation with business justification, risk analysis, and equivalence argument the QSA accepts.

AOC drafting partnership

EPC Group reviews the Attestation of Compliance draft alongside the customer executive sponsor before submission to the acquirer or card brand, ensuring the AOC reflects the actual control posture accurately.

Year-two continuous readiness

After AOC submission, EPC Group hands off a continuous compliance program in Microsoft Purview Compliance Manager and Sentinel so year-two recertification is a refresh — not a rebuild.

Standards alignment — PCI DSS 4.0 inside the broader EPC Group compliance library

PCI DSS 4.0 sits inside a broader regulatory architecture for most enterprise customers. EPC Group maintains control crosswalks between PCI DSS 4.0 and the other frameworks our customers operate under so a single Microsoft control implementation satisfies multiple frameworks. See our standards alignment library for the full crosswalk matrix.

HIPAA
SOC 2
FedRAMP
FINRA
CMMC
GxP

Why EPC Group leads enterprise PCI DSS engagements on Microsoft

1997
Founded · Microsoft consulting
70+
Fortune 500 clients
216+
M&A tenant consolidations
1.83 million
Users migrated

Microsoft Solutions Partner — Security

Microsoft Solutions Partner with the Security designation plus designations covering Modern Work, Infrastructure, Data & AI, Digital & App Innovation, and Business Applications. Senior architects average two decades of Microsoft platform delivery experience.

Four-time author for Microsoft Press and Sams

Founder Errin O’Connor has nearly three decades of Microsoft consulting leadership and is a four-time author for Microsoft Press and Sams across Power BI and SharePoint.

Fixed-fee accelerators

Every PCI DSS engagement is fixed-fee with a costed roadmap and named senior architect on-record from kickoff through AOC submission. No T&M overruns, no offshore handoff, no junior-analyst-led production cutover.

Compliance-native by design

EPC Group ships controls with mapping to PCI DSS 4.0, NIST 800-53, NIST 800-171, HIPAA, FedRAMP, FINRA, CMMC, and GxP — the evidence QSAs and auditors actually accept, not generic Defender for Cloud screenshots.

Frequently asked questions — PCI DSS 4.0 on Microsoft

What changed in PCI DSS 4.0 compared to PCI DSS 3.2.1?

PCI DSS 4.0 is the most significant rewrite of the standard since version 1.0. The most material changes are: mandatory multi-factor authentication for all access into the Cardholder Data Environment (not just remote and administrative access); the introduction of the customized approach alongside the defined approach, allowing organizations to demonstrate the same security outcome through different controls if a Targeted Risk Analysis supports it; a new payment-page script integrity requirement under 6.4.3 protecting against Magecart-style attacks; expanded e-commerce skimming protections; tougher cryptographic key management requirements under Requirement 3; and a significantly expanded role for automated log review under Requirement 10. PCI DSS 4.0 was published in March 2022, with full enforcement that began March 31 2024 for most controls and an extended deadline of March 31 2025 for the future-dated requirements. EPC Group has guided merchants through PCI DSS 4.0 transition assessments against Microsoft-anchored CDEs since the standard was first released, and the Microsoft control stack — Entra ID, Defender XDR, Purview, Sentinel — maps natively to the new requirements without compensating-control gymnastics.

How does PCI DSS scope work — Cardholder Data Environment and connected systems?

The Cardholder Data Environment (CDE) is every system component that stores, processes, or transmits cardholder data — and every system component that is connected to such a system. The scope discipline that determines audit cost and complexity is what is allowed to be CDE-connected. PCI DSS 4.0 names three scope categories: (1) CDE systems — anything storing, processing, or transmitting cardholder data; (2) Connected-to or security-impacting systems — systems that could affect CDE security (jump hosts, directory services, monitoring tools) and are therefore in scope; (3) Out-of-scope systems — systems with no connectivity to CDE and no path to affect CDE security. The single biggest scope-management lever is to design for tokenization so the application server, database, log store, and backup tier hold only tokens — the PAN never enters the broader environment. EPC Group runs Microsoft Purview Data Map discovery against Azure data stores, Microsoft 365 SharePoint, and on-premises file shares to find every place a Primary Account Number actually lives versus where it is documented to live. The discovery delta is usually a six-figure scope-reduction opportunity.

What is the difference between a PCI DSS Report on Compliance (ROC) and a Self-Assessment Questionnaire (SAQ)?

The Report on Compliance (ROC) is a formal audit conducted by a PCI Council Qualified Security Assessor (QSA) for Level 1 merchants and most service providers. The QSA reviews evidence against every applicable sub-requirement, walks the environment, conducts personnel interviews, and produces a multi-hundred-page report that is submitted with the Attestation of Compliance (AOC) to the acquirer or card brand. The Self-Assessment Questionnaire (SAQ) is a self-administered compliance attestation for smaller merchants — Level 2 through Level 4 — depending on transaction volume and processing model. There are multiple SAQ variants (SAQ A for fully outsourced e-commerce, SAQ A-EP for e-commerce with payment-page involvement, SAQ B for imprint-machine merchants, SAQ B-IP for stand-alone IP-connected POS, SAQ C for segmented e-commerce, SAQ C-VT for virtual terminal merchants, SAQ D for everyone else, and SAQ P2PE for point-to-point-encrypted environments). Choosing the correct SAQ variant is itself a scope decision — EPC Group reviews the customer processing model and confirms the SAQ that matches the actual environment, then implements Microsoft controls to satisfy that SAQ.

When are compensating controls allowed in PCI DSS 4.0, and how do they differ from the customized approach?

PCI DSS 4.0 distinguishes two paths for meeting a sub-requirement beyond the defined approach. Compensating controls are temporary measures used when a documented technical or business constraint prevents implementing the defined control — they require business and technical justification, a risk analysis, and equivalent or stronger security to the defined control. The customized approach is a permanent alternative where the organization demonstrates it meets the security objective through different controls than the defined approach prescribes — it requires a Targeted Risk Analysis (TRA) documenting how the alternative meets the same security objective, and the QSA must accept the customized approach during the assessment. Practical guidance: use defined approach wherever possible because QSAs review it fastest, use customized approach for permanent architectural decisions where a Microsoft-native control achieves the security objective more effectively than the defined approach prescribes (Conditional Access policies often qualify), and reserve compensating controls for short-term remediation gaps. EPC Group documents both paths so QSAs review evidence in the format they prefer rather than the format the customer guessed at.

How does Microsoft Entra ID Conditional Access satisfy PCI DSS 4.0 Requirements 7 and 8?

Microsoft Entra ID Conditional Access is the primary enforcement mechanism for PCI DSS 4.0 access control and authentication requirements. For Requirement 7 (need-to-know), Conditional Access combined with Privileged Identity Management (PIM) enforces that CDE administrators activate elevated roles only when needed, only after approval workflow, only with MFA, and only for time-bound windows. For Requirement 8 (authenticate access), Conditional Access enforces phishing-resistant MFA (Windows Hello for Business, FIDO2, certificate-based) on every CDE application sign-in, blocks legacy authentication protocols that would bypass MFA, restricts access to compliant devices managed by Microsoft Intune, and forces re-authentication based on session risk through Entra ID Protection. EPC Group typically deploys 18 to 24 Conditional Access policies targeting CDE-scoped users, applications, and administrative roles, then exports each policy as JSON evidence in the QSA binder. The MFA approach satisfies PCI DSS 4.0 8.4.2 which made MFA mandatory for all non-console administrative access and all access into the CDE regardless of network origin.

How does Azure Key Vault HSM support PCI DSS Requirement 3 cryptographic key management?

Azure Key Vault Premium provides FIPS 140-3 Level 3 validated Hardware Security Modules (HSMs) for cryptographic key custody, which satisfies PCI DSS Requirement 3.6 (cryptographic key management) and 3.7 (key lifecycle management) when configured correctly. The PCI-relevant capabilities include: keys are generated and used inside the HSM and never exposed to the application server or operator; access to keys is controlled through Azure RBAC with key-vault-level and key-level scope; key operations are logged to the Microsoft Sentinel workspace with one-year-plus retention; key rotation is automated through Azure Key Vault key rotation policies; and the Azure Dedicated HSM offering is available for organizations requiring single-tenant HSM hardware with direct administrative control. EPC Group designs the key vault architecture during Phase 3 of the accelerator, separating CDE keys into a dedicated key vault with separate RBAC and separate logging, and integrating Sentinel analytics rules to alert on any anomalous key-operation pattern. The configuration is captured as Infrastructure as Code so the QSA verifies the deployed state matches the documented state.

How does Microsoft Sentinel satisfy PCI DSS Requirement 10 log monitoring and review?

Microsoft Sentinel is the centralized SIEM that satisfies the bulk of PCI DSS 4.0 Requirement 10. The capabilities mapping is: Requirement 10.2 (audit logging events) — Sentinel ingests Microsoft 365 audit logs, Entra ID sign-in and audit, Defender XDR alerts, Azure resource diagnostic logs, and on-premises Syslog through the Azure Monitor Agent, giving comprehensive coverage of CDE component activity. Requirement 10.3 (log content) — Microsoft Purview Audit Premium captures the PCI-relevant detail (user, event type, timestamp, source, success or failure). Requirement 10.5 (log integrity protection) — Azure Monitor Log Analytics workspace immutable storage prevents log tampering. Requirement 10.6 (daily log review) — Sentinel analytics rules implement the PCI-relevant detection use cases (privileged access, failed authentication patterns, configuration change, cardholder-data access anomalies) and Sentinel workbooks provide the daily review dashboard. Requirement 10.7 (log retention) — Purview Audit Premium retains audit logs for one year by default, configurable to ten years for high-value events. The companion hub at /microsoft-sentinel-siem-enterprise-2026 covers ingestion economics, analytics engineering, and SOAR playbook patterns in depth.

What does EPC Group PCI DSS Accelerator cost, and what is the typical timeline?

The EPC Group PCI DSS 4.0 Accelerator is fixed-fee, scoped after a discovery call, depending on CDE scope complexity, regulatory overlay, organization size, and managed-service tail. Typical timeline is 24 to 38 weeks end-to-end across five phases: Phase 1 Scope (3 weeks), Phase 2 Gap (3 to 5 weeks), Phase 3 Implement (12 to 20 weeks), Phase 4 Validate (6 to 10 weeks), Phase 5 Sustain (ongoing). Scope drivers that move the engagement toward the upper end include hybrid on-premises plus Azure CDE topologies, FedRAMP or HIPAA regulatory overlays, multiple acquirer or card-brand reporting requirements, large administrator and developer populations, and merchant categories requiring SAQ D or full ROC. EPC Group runs the accelerator senior-architect-led with no offshore handoff and a named architect on-record from kickoff through QSA AOC submission. The deliverable is a passed Attestation of Compliance plus a sustainable continuous-compliance program in Microsoft Purview Compliance Manager, Sentinel, and Defender XDR that operationalizes PCI DSS as an always-on practice rather than an annual audit scramble.

Continue exploring the EPC Group enterprise Microsoft library

PCI DSS 4.0 on Microsoft sits inside the broader Microsoft Cloud orchestration story alongside Defender XDR, Sentinel, Purview, and Entra ID. These hubs cover adjacent and complementary territory.

Pass your next PCI DSS 4.0 audit the way Microsoft-anchored merchants should

Book a PCI DSS briefing with an EPC Group senior architect. Two-hour working session — CDE scope walkthrough, gap snapshot against PCI DSS 4.0, and accelerator scoping. Zero obligation, board-ready output.

AI assistant — not a human