Does Azure's PCI DSS validation cover your PCI DSS on Azure assessment?
Your payment flow has to run on Azure, and the QSA assessing it will ask a direct question: what does Azure's validation cover? Microsoft states that Azure is validated as compliant with PCI DSS version 4.0 at Service Provider Level 1 by a QSA, and that the AOC can be downloaded from the Service Trust Portal. That validation can reduce your own effort, but it does not validate the workloads, configurations and applications you build and host on Azure. Microsoft is explicit that its own status does not automatically carry over to what customers build on the platform.
Your organization owns its assessment. An independent QSA issues the Report on Compliance or the Attestation of Compliance for your environment, and no Microsoft document replaces that. The useful question is therefore not whether Azure is compliant but which Azure services sit inside your cardholder data environment and which party meets each requirement for each of them. Confirm the service list in Microsoft's AOC against the services in your architecture, and confirm the scope of each service with Microsoft rather than assuming it. Azure's PCI DSS audit documentation also covers Dynamics 365, Power Platform and select Microsoft 365 services under separate AOCs, which matters if any of them touch payment data.
Start with the Azure PCI DSS Shared Responsibility Matrix, which shows for each requirement whether Azure, you or both are responsible. Use it to build your own responsibility table for each in-scope service, then agree that split in writing with your QSA before testing begins. Treat the built-in Azure Policy initiative for PCI DSS as a partial view only: it maps some controls to policy definitions, but it does not show that a requirement is met. Plan to own the controls the matrix assigns to you, including access reviews, logging configuration, network segmentation and key management decisions on your side.
How to get Azure's AOC and Shared Responsibility Matrix
This sequence gets Microsoft's PCI DSS documentation for Azure from the Service Trust Portal and sets it against your own design. The outputs are documents your QSA can read, and they describe what Microsoft covers, not whether your cardholder data environment is compliant.
Open the Azure PCI DSS offering page
Start from Microsoft's Azure PCI DSS offering page on Microsoft Learn. The page describes Microsoft's PCI DSS v4.0 Service Provider Level 1 validation by a QSA, explains the Shared Responsibility Matrix, and points to the Service Trust Portal for the current documents. Whoever owns the cardholder data environment should read it first, because it sets the boundaries of what Microsoft's validation covers. You know this step is done when the team agrees on which Azure offering and deployment model (commercial or Azure Government) applies to the project.
Sign in to the Service Trust Portal
Access the Service Trust Portal using an account that your organization controls and that can accept Microsoft's terms for accessing compliance documents. The portal holds Microsoft's audit documentation for Azure and related services. Confirm with your compliance lead that the account and any access approvals match your internal process for handling third-party assurance material. You know this step is done when the PCI DSS documents section of the portal is visible to your team.
Download the commercial Azure AOC
From the PCI DSS documents in the portal, download the Attestation of Compliance for Azure. This AOC is the document that records Microsoft's validation status for the commercial Azure service. Save the file to your evidence repository with the download date and portal location recorded. Confirm the assessment period, the version and the issuing QSA on the document itself, because the portal may hold more than one version over time. You know this step is done when the AOC is stored and its key fields are noted.
Download the Azure Government AOC if needed
Microsoft issues a separate AOC for Azure Government. If any part of your cardholder data environment or related workload runs in Azure Government, download that AOC as well and treat it as a distinct document. Do not assume the commercial AOC covers Azure Government regions or services. Ask Microsoft or your QSA to confirm which AOC applies to each environment you plan to use. You know this step is done when each deployment region in your design maps to one named AOC.
Download the Shared Responsibility Matrix
Download the Azure PCI DSS Shared Responsibility Matrix from the same portal section. The matrix lists each PCI DSS requirement and indicates whether Azure, the customer or both carry responsibility for it. Your architects and QSA will use it to decide which controls you must still implement, document and evidence. Keep the version that matches the AOC you downloaded. You know this step is done when the matrix and the AOC are stored together with matching version references.
Map the matrix to your services and controls
Walk through the matrix against your own architecture, listing each Azure service your cardholder data environment uses and confirming that it falls inside Microsoft's assessed services. Mark every requirement where the matrix assigns the customer or a shared role to you, and assign an owner, an implementation and an evidence source. Services outside Microsoft's PCI DSS scope need their own review. You know this step is done when every in-scope service and every customer responsibility has a named owner and an evidence location.
Hand the documents to your QSA as inputs
Give the AOC, the Shared Responsibility Matrix and your service-to-control mapping to your QSA as inputs to the assessment. The QSA decides how much reliance to place on Microsoft's documents and tests your own controls independently. Neither document certifies your environment, and your organization still owns its PCI DSS validation through its own Report on Compliance or Self-Assessment Questionnaire and Attestation of Compliance. Confirm the current document versions with Microsoft's portal before the assessment starts. You know this step is done when the QSA confirms in writing which documents it will rely on.
Which PCI DSS controls Azure meets and which you still own
Microsoft's PCI DSS validation covers the Azure platform itself: the physical data center, the underlying hypervisors and host infrastructure, and the network fabric that Microsoft operates. Microsoft states that Azure is validated as compliant with PCI DSS version 4.0 at Service Provider Level 1 by a QSA, and the Attestation of Compliance can be downloaded from the Service Trust Portal. Those platform-level requirements are where Azure's assessment provides the most direct reliance for your assessor.
- Physical facilities: Data center access, environmental controls and media handling for the Azure infrastructure are generally carried by Microsoft.
- Hypervisor and host layer: Patching and hardening of the underlying hosts and virtualization stack are typically Microsoft's responsibility.
- Platform network fabric: Microsoft operates the core network beneath your virtual networks.
- Service-level evidence: The AOC and the Azure PCI DSS Shared Responsibility Matrix describe these platform controls for each requirement.
- Scope of the platform claim: Azure's validation does not extend to services you build or host on Azure.
Confirm in the matrix which platform controls Microsoft claims for each requirement, and ask your QSA which of them they will accept without retesting.
Many requirements are split between Microsoft and your team. Microsoft may run a control at the platform layer while you configure, operate or evidence it for your workloads. Typical examples include logging, key management, network segmentation and vulnerability management, where the platform offers a capability but your configuration decides whether the requirement is met for your cardholder data environment.
- Logging and monitoring: Azure provides log sources, but you choose what to enable, where logs go, how long they are retained and who reviews them.
- Encryption and key management: Azure offers encryption at rest and managed key services, while you decide key scope, rotation and access.
- Network controls: Azure supplies network security capabilities, while you define the rules that restrict traffic into and out of the cardholder data environment.
- Vulnerability and patch management: Microsoft patches the platform, while you patch operating systems, images and applications you deploy.
- Access control: Azure provides identity services, while you assign roles and perform the access reviews.
For each shared requirement, ask who performs the activity, who holds the evidence and whether the written agreement with Microsoft and your internal records say the same thing.
Microsoft's validation does not automatically cover what you build on Azure. Your application code, the way your subscriptions are administered, how cardholder data is handled and the policies and reviews that govern the environment remain your responsibility. The PCI SSC states that using a cloud service provider does not remove an organization's ultimate responsibility for payment data security, and that this responsibility cannot be outsourced.
- Application code and secure development: Your software, its input validation and its web application protection are yours to build and test.
- Subscription and identity administration: Who holds Owner or privileged roles, how they are approved and how their use is reviewed sit with your team.
- Cardholder data handling: Storage, retention limits, masking and the locations where card data flows are defined by your design.
- Policies, procedures and reviews: The security policy, risk analysis, awareness program, incident response plan and periodic reviews belong to your organization.
- Evidence for your scope: Records showing your controls operated over time must come from your own systems and staff.
When the matrix assigns a requirement to the customer, confirm that your team has an owner, a procedure and evidence ready before the assessment begins.
The Azure PCI DSS Shared Responsibility Matrix shows, for each requirement, whether Azure, the customer or both are responsible. Read it requirement by requirement rather than relying on a summary, and treat its assignments as the starting point for your own responsibility map. The Azure Policy built-in initiative for PCI DSS also maps controls to policy definitions, but Microsoft presents that mapping as only a partial view of compliance.
- Start from the matrix: Work through each requirement and record the party named for it.
- Check the service list: Confirm each Azure service you use appears in the covered services of the AOC, since services outside that list are not validated by Microsoft's assessment.
- Separate AOCs: Azure and Azure Government have separate AOCs, so use the one that matches your deployment.
- Treat policy mappings as partial: Azure Policy results show configuration state, not a full assessment of any requirement.
- Record your reading: Keep a dated copy of the matrix and the version of the AOC you relied on.
Before relying on any assignment, verify the mapping in the matrix itself and confirm the interpretation with your QSA.
Which Azure services are covered by Microsoft's PCI DSS audit
Microsoft's PCI DSS audit does not cover every service you can run on Azure, so you must check each service in your cardholder data environment against the covered list before you rely on it. Microsoft's audit documentation covers Azure, along with Dynamics 365, Power Platform and select Microsoft 365 services, and it issues separate AOCs for Azure and Azure Government. A provider's own validation as a service provider does not show that each service it offers was assessed. The PCI SSC makes the same point: customers should ask which services are covered, because that answer determines what falls inside their own assessment scope. Any Azure service that is not on the covered list stays in your scope and must be assessed with the same rigor as your own systems.
Start with an inventory. List every Azure resource type that stores, processes, transmits or could affect the security of account data, including networking, compute, storage, databases, key management, identity, logging and any managed add-ons. Then compare each item with the covered services named in the current Azure PCI DSS documentation on Microsoft Learn, and record the date and version you checked. Do not assume a service is covered because its parent product family is. Confirm the exact service names and any regional or government distinctions with your QSA before the assessment starts, and get the QSA's agreement on how uncovered services will be tested and evidenced.
For each service that is not covered, decide whether to remove it from the cardholder data environment, replace it with a covered alternative, or accept the additional assessment effort. Work this decision with your QSA early, because an uncovered service that handles account data can expand the scope of every related requirement, from network controls to logging and access reviews. Keep the resulting scope decision and its justification in your documentation, since it is the basis for the Shared Responsibility Matrix work that follows.
What Azure Policy PCI DSS initiatives can and cannot prove
The built-in Azure Policy initiative for PCI DSS gives you machine-checked evidence about resource configuration. It does not describe how your organization runs, staffs or routes card data, so the cards below separate what it proves from what your assessor will still need to see.
What the built-in initiative maps
The Azure Policy built-in initiative for PCI DSS links PCI DSS requirements to policy definitions that evaluate Azure resource configuration, such as whether storage is encrypted or whether network access is restricted. Each definition reports compliant or non-compliant resources against a mapped requirement. Ask your QSA how they want the mapping used. Treat it as a starting point for configuration evidence, not as a finding that a requirement is met.
Partial view of compliance
Microsoft describes the initiative as only a partial view of compliance. A green score means the mapped configuration checks passed on the day they ran. It does not mean every PCI DSS requirement is satisfied, and many requirements have no policy definition at all. Confirm which requirements the initiative maps in your environment before you present its score as coverage.
Configuration checks it can evidence
Policy compliance reports give your assessor dated, resource-level records for configuration checks, such as encryption settings, logging enablement and network rules on in-scope resources. Export and retain these reports as evidence of the control state over the assessment period. Confirm that the initiative version and assignment scope match the subscriptions that hold your cardholder data environment.
Tenant-wide processes it cannot show
A policy definition cannot prove that your change approval, incident response or access review processes run as documented. Those processes sit in ticketing systems, meeting records and sign-offs that you must produce separately. Identify which of your Requirement 12 and Requirement 7 processes need their own evidence trail before the assessment starts.
Personnel controls it cannot cover
Background screening, security awareness training and the handling of employee departures involve people, not resources. Azure Policy has no view into these controls. Keep training completion records, screening documentation and offboarding checklists in your own HR and security systems, and confirm with your assessor which records they will sample.
Cardholder data flows and compensating decisions
A policy assessment does not trace where card data travels, which applications touch it or whether an out-of-scope system is actually out of scope. Compensating controls and customized approach decisions also need documented reasoning that a policy result cannot provide. Maintain your own data-flow diagrams, scoping decisions and risk analyses, and confirm the initiative version in your environment before you cite its results.
Why a cloud provider's AOC does not finish your scoping
Azure's Attestation of Compliance covers Microsoft's own environment as a service provider. It does not tell your QSA what you built on top of it. The PCI SSC is direct on this point: using a cloud service provider does not remove your ultimate responsibility for payment data security, and that responsibility cannot be outsourced. The written agreement and responsibility matrix are where the split between you and Microsoft is recorded, requirement by requirement. Start with Microsoft's Azure PCI DSS Shared Responsibility Matrix, then mark every requirement where your team owns the configuration, the operation or the evidence, such as firewall rules on your virtual networks, access reviews in Microsoft Entra ID, key rotation for your application keys, and log review for your own workloads.
The SAQ D note to requirement 12.8.1 makes the same point from the other direction. A PCI DSS compliant third-party service provider does not make your entity compliant, and it does not remove your responsibility for your own compliance. For a QSA, the matrix becomes evidence only when it is specific enough to test. A line that says "Azure: network security" gives an assessor nothing to sample. A useful line names the Azure service, the customer control that runs on it, the owner, and the artifact that proves the control operated, such as a policy assignment export, a change record or a sampled log. Ask Microsoft which services are inside the AOC scope for your region and account type, because a provider's validation does not show that every service it offers was assessed.
Treat the matrix as a living document. Re-check it when you add a service, change a network boundary or move a workload, and confirm with your QSA how they will accept it, since the final judgment on scope and reliance belongs to the assessor. Azure Policy's built-in PCI DSS initiative can support this work by showing which policy definitions map to which controls, but Microsoft describes that mapping as only a partial view of compliance. Use it to find gaps in your own configuration, not as a substitute for the matrix or for the assessment.
Controls you still own on Azure
Azure's validation covers the platform, not the cardholder data environment you build on it. The cards below cover the PCI DSS controls that stay with your organization, and the evidence a QSA will ask you to produce for each one.
Cardholder data retention and protection
You decide where account data lands in Azure SQL, Cosmos DB, Storage accounts and backups, and how long it stays there. Keep a data inventory, confirm that stored PAN is masked or rendered unreadable, and check that backups, snapshots and logs do not hold unprotected copies. A QSA will ask for data-flow diagrams, retention settings, encryption and key management records, and sample queries that prove no sensitive authentication data is stored. You own this control in full, even though Azure provides the encryption primitives.
Identity and access reviews
Entra ID roles, subscription role assignments, privileged identity groups and service principals are configured by your team. Review who holds access to the cardholder data environment on a schedule, remove access that no longer matches a business need, and enforce multi-factor authentication for administrators. Assessors typically request role assignment exports, access review records, and evidence that approvals were recorded. Azure Policy can flag drift, but the access decisions are yours.
Logging and review of your resources
Azure's own logging does not tell you whether your resources are monitored. Enable diagnostic settings, activity logs and resource logs for every in-scope service, send them to a protected workspace, and set retention to meet the requirement. Someone in your organization must review the logs and act on alerts. Ask your QSA which log sources they will sample, and prepare evidence that reviews happened, not just that logging was switched on.
Vulnerability and patch management
Virtual machines, container images, App Service runtimes and any software you install remain your responsibility to scan, patch and track. Run authenticated vulnerability scans, address findings within the timelines your policy sets, and keep an inventory of components that touch the CDE. Evidence includes scan reports, patch records, and change tickets. Scanning by Microsoft tooling does not replace your own scan program or an ASV scan where one is required.
Security policies and awareness
Written security policies, risk assessments, roles for personnel with CDE access, and security awareness training are organizational obligations that no cloud provider can carry for you. Keep policies current, review them at the intervals the standard expects, and record training completion. A QSA will ask for signed policy versions, training records and evidence that staff understand their duties. Your responsibility matrix should show which Azure controls you rely on for each policy statement.
Incident response for your environment
When an alert fires in your Azure subscriptions, your team must triage, contain and report it. Define the response plan, assign on-call owners, and test the plan with tabletop exercises that include Azure-specific scenarios such as a compromised service principal. Assessors will ask for the plan, test records, and past incident tickets showing that the process ran. Microsoft's response activities do not replace your own incident process for your data and workloads.
How the Azure component fits into your PCI DSS assessment
This sequence settles what Azure covers, what you still own, and what your QSA needs before issuing a ROC or SAQ with your Attestation of Compliance. Each step ends with a document or check that the next step depends on.
Define the cardholder data environment and its Azure services
Your team lists every Azure service that stores, processes or transmits cardholder data, plus every system that could affect the security of that environment, such as identity, logging and key management. Map data flows and the subscriptions, resource groups and regions involved. Confirm which Azure offering applies, since Microsoft's Azure AOC is separate from the Azure Government AOC. The output is a scoped service inventory that your QSA reviews before anything else proceeds. Ask the QSA early whether they expect a ROC or an SAQ, because that choice shapes how much evidence you prepare.
Confirm Azure's covered services against your inventory
Download Azure's PCI DSS Attestation of Compliance from the Service Trust Portal and check it names the validated environment and the version it covers, which is PCI DSS v4.0 at Service Provider Level 1. Compare each service in your inventory against the list of services in that scope. Microsoft's validation does not confirm that every service you build on Azure was assessed, so any service outside the list becomes part of your own assessment. The output is a written list of covered and uncovered services for your QSA to confirm.
Obtain the Shared Responsibility Matrix
Download Microsoft's Azure PCI DSS Shared Responsibility Matrix from the same Service Trust Portal location. It shows, requirement by requirement, whether Microsoft, you or both are responsible. Read it against your service inventory, because the matrix describes the platform while your configurations, identities, data handling and policies determine what you actually meet. The output is a marked-up copy of the matrix tied to the services in your CDE, with open questions logged for your QSA and Microsoft account team.
Agree responsibilities in writing
Turn the matrix into a responsibility record for your environment. For each requirement, state who meets it, which Azure feature or configuration supports it, and which document or log proves it. Include the parties you rely on beyond Microsoft, such as an implementation partner or managed service provider. The PCI SSC expects written agreements and responsibility matrices to set out which party meets which requirement, and it holds that outsourcing a cloud provider does not transfer ultimate responsibility for payment data security. The output is a signed internal responsibility matrix that your QSA can review.
Prepare evidence for customer-owned requirements
Collect the evidence for each requirement that remains yours. Typical items include network and data-flow diagrams, Azure Policy assignments and compliance state exports, role assignments and access reviews, key management records, log retention settings, vulnerability scan and penetration test reports, security policies and incident response records. Azure Policy's PCI DSS built-in initiative maps some controls to policy definitions, but Microsoft describes that mapping as a partial view, so treat exported compliance results as supporting evidence rather than proof. The output is an evidence index that links each requirement to a named artifact, owner and collection date.
Hand the package to the QSA and resolve findings
Provide the QSA with the scoped inventory, Azure's AOC, the Shared Responsibility Matrix, your signed responsibility record and the evidence index. The QSA tests each claim, requests samples, interviews staff and records findings. Fix gaps the assessor raises and document each remediation so the evidence reflects the fixed state. DeployOpen can prepare systems, configurations and evidence for this review under a written scope, but it does not test on the QSA's behalf or issue any report. The output is an assessor-accepted set of findings with closed items.
Complete the ROC or SAQ and sign the AOC
Once the QSA is satisfied, the QSA completes the Report on Compliance, or you complete the applicable Self-Assessment Questionnaire with the relevant guidance. Your organization then signs its own Attestation of Compliance on the official PCI SSC template, and the QSA signs where the ROC requires it. Keep the Azure AOC and matrix with the assessment file, because your QSA and any payment brand may ask for them. Certificates do not count as validation. Durations for this stage depend on the environment's complexity and the assessor's schedule, so confirm timing with your QSA in writing.
Common questions about PCI DSS on Azure
Does Azure's PCI DSS AOC mean we can skip requirements?
No. Azure's Attestation of Compliance covers the Azure platform as a service provider, not the systems you build on it. Microsoft states that its PCI DSS status does not automatically validate services customers build or host on Azure. Your cardholder data environment still needs its own assessment, and your QSA can rely on Azure's validation only for the requirements Microsoft's responsibility matrix assigns to Azure. Every requirement assigned to you, or to both parties, remains yours to evidence. Start with the Azure PCI DSS offering on Microsoft Learn and map each requirement line by line.
Do we need a separate AOC for Azure Government?
Microsoft's PCI DSS audit documentation provides separate AOCs for Azure and Azure Government, so the AOC you rely on must match the cloud where your cardholder data environment runs. Do not substitute one for the other in your assessment file. Confirm with Microsoft through the Service Trust Portal which document applies to your tenant and region, and check that your QSA accepts that document as evidence for the services you use. If your environment spans both clouds, each side needs its own scope definition and evidence.
What should we do about Azure services that are not on the covered list?
Treat any service missing from Microsoft's PCI DSS coverage as outside Azure's validation. A provider's compliance as a service provider does not show that every service it offers was assessed, so you need to ask which services are covered before you place cardholder data on them. If a service is not covered, you can either exclude it from the cardholder data environment through design, or bring it into your own assessment with compensating evidence, and your QSA will decide whether that evidence is sufficient. Record each service and its status in your scope documentation so the decision is traceable.
Who signs the responsibility agreement with Microsoft?
Your organization signs its own agreements, and the responsibility split is recorded in writing between you and Microsoft. The PCI SSC expects written agreements and responsibility matrices to set out which party meets which requirement. Microsoft publishes the Azure PCI DSS Shared Responsibility Matrix, which shows whether Azure, the customer or both are responsible for each requirement. Use that matrix as the starting point, then confirm with your legal and procurement teams which contract terms apply to your subscription. Your QSA will review the matrix and the contract together, so keep both current when services or regions change.
What effort must we fund and staff after moving to Azure?
Effort depends on how much of the cardholder data environment you build yourself and how many requirements the responsibility matrix assigns to you. The main recurring work includes access reviews, log review, vulnerability and penetration testing, configuration management, change control, policy upkeep and evidence collection for each assessment cycle. Some tasks are one-time, such as scoping, network and data-flow diagrams, and initial hardening. Ask any provider for a written breakdown of one-time and recurring tasks, the roles that perform them, and the evidence each produces. Staff time inside your own organization is usually the largest cost, so budget for it alongside any external fees.
Can an implementation partner perform the PCI DSS assessment for us?
An implementation partner can prepare your Azure environment, configuration, documentation and evidence, but it cannot perform the assessment or issue the Report on Compliance or Attestation of Compliance. Only a Qualified Security Assessor, or the appropriate PCI SSC process, can validate compliance. DeployOpen plans, builds, hardens and documents self-hosted open-source platforms inside a client's own infrastructure and prepares controls and evidence for assessment, but it does not issue audit reports, attestations or certifications. Keep the implementation partner and the QSA independent so the assessor can test the work objectively.
How DeployOpen prepares your Azure CDE and evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own Azure subscriptions, so the cardholder data environment you build can be traced back to the Shared Responsibility Matrix and the evidence your assessor will ask for. We prepare systems, controls and evidence; your QSA or other independent assessor decides the outcome and issues the report.
How we scope
- Confirm which Azure services your cardholder data flows touch, and check them against the services covered in Microsoft's AOC.
- Map each PCI DSS requirement to Azure, your team or both, using the Shared Responsibility Matrix as the starting point.
- Agree the scope, deliverables and timelines in writing before work starts, since engagements are fixed-scope.
How we build
- Build the Azure environment in your own subscriptions with network controls, logging and access configured to your agreed scope.
- Configure the Azure Policy mappings as a partial view, then add checks for the controls Microsoft's matrix assigns to you.
- Document configuration standards, diagrams and inventories as the environment is built, not after the assessment begins.
How we hand over
- Deliver the written record of each customer-owned control, the responsibility split and the evidence source for each one.
- Provide the evidence package in a form your QSA can sample, including configuration exports, logs and change records.
- Walk your team through operating the controls so the evidence keeps being produced after the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the initial scope.
- Re-check the responsibility matrix and Azure's current AOC when your services or the PCI DSS version change.
- Ask your QSA early which evidence they expect, so gaps are closed before the assessment rather than during it.
