PCI DSS overview

The Payment Card Industry (PCI) Data Security Standards (DSS) is a global information security standard designed to prevent fraud through increased control of credit card data. The PCI Security Standards Council (PCI SSC) is a global forum that brings together payments industry stakeholders to develop and drive adoption of data security standards, including PCI DSS.

Compliance with PCI DSS is required for any organization that stores, processes, or transmits cardholder data, which, at a minimum, consists of the full primary account number (PAN) - a unique payment card number that identifies the issuer and the particular cardholder account. Cardholder data may also appear in the form of a full PAN plus additional information such as cardholder name, expiration date, and service codes. Sensitive authentication data that may be transmitted or processed (but not stored) as part of a payment transaction contains additional data elements that must also be protected, including track data from card chip or magnetic stripe, PINs, PIN blocks, etc. For more information, see PCI DSS glossary.

The PCI DSS designates four levels of compliance based on transaction volume, with Service Provider Level 1 corresponding to the highest volume of transactions at more than 6 million a year. The assessment results in an Attestation of Compliance (AoC), which is available to customers and Report on Compliance (RoC) issued by an approved Qualified Security Assessor (QSA). The effective period for compliance begins upon passing the audit and receiving the AoC from the QSA and ends one year from the date the AoC is signed.

Azure and PCI DSS

Microsoft Azure maintains a PCI DSS validation using an approved Qualified Security Assessor (QSA), and is certified as compliant under PCI DSS version 3.2.1 at Service Provider Level 1. The Attestation of Compliance (AOC) produced by the QSA is available to customers for download. Customers who want to develop a cardholder data environment (CDE) or card processing service can leverage the Azure validation, thereby reducing the associated effort and costs of getting their own PCI DSS validation.

It is, however, important to understand that Azure PCI DSS compliance status does not automatically translate to PCI DSS validation for the services that customers build or host on the Azure platform. Customers are responsible for ensuring that they achieve compliance with PCI DSS requirements. Azure provides the following resources to help customers meet their own PCI DSS compliance obligations:

  • Azure PCI DSS Shared Responsibility Matrix specifies areas of responsibility for each PCI DSS requirement, and whether it is assigned to Azure or the customer, or if the responsibility is shared.
  • Azure Blueprints is a service that helps customers deploy and update cloud environments in a repeatable manner using composable artifacts such as Azure Resource Manager templates to provision resources, role-based access controls, and policies. Resources provisioned through Azure Blueprints adhere to an organization’s standards, patterns, and compliance requirements. The overarching goal of Azure Blueprints is to help automate compliance and cybersecurity risk management in cloud environments. To help customers deploy a core set of policies for any Azure-based architecture that requires PCI DSS validation, Azure has released the Azure Blueprint for PCI DSS. When assigned to an architecture, resources are evaluated by Azure Policy for compliance with assigned policy definitions.


  • Azure
  • Azure Government

Services in scope

Microsoft online services in scope are shown in the PCI DSS Attestation of Compliance (AoC) that is available separately for Azure and Azure Government:

  • Azure (for detailed insight, see Microsoft Azure Compliance Offerings or PCI DSS AoC)
  • Dynamics 365 (for detailed insight, see PCI DSS AoC)
  • Microsoft Cloud App Security
  • Microsoft Defender for Endpoint (formerly Microsoft Defender Advanced Threat Protection)
  • Microsoft Graph
  • Microsoft Healthcare Bot (not in scope for Azure Government)
  • Microsoft Intune
  • Microsoft Managed Desktop (not in scope for Azure Government)
  • Microsoft Stream
  • Power Apps
  • Power Automate (formerly Microsoft Flow)
  • Power BI
  • Power BI Embedded

Microsoft 365 PCI DSS compliance

For more information about Microsoft 365 compliance, see Microsoft 365 PCI DSS documentation.

Audit reports

You can access audit reports and certificates in the Azure or Azure Government portal by navigating to Home > Security Center > Regulatory compliance > Audit reports or using direct links based on your subscription (login required):

The following documents are available:

  • Azure PCI DSS AoC package (zipped archive) contains AoC documents for both Azure and Azure Government.
  • Azure PCI DSS Shared Responsibility Matrix specifies areas of responsibility for each PCI DSS requirement.

Frequently asked questions

Why does the Attestation of Compliance (AoC) cover page say "June 2018"?
The June 2018 date on the cover page is when the AoC template was published. Refer to Section 3 with signatures for the date of the assessment.

How long is the PCI DSS AoC valid?
The effective period for compliance begins upon passing the audit and receiving the AoC from the Qualified Security Assessor (QSA) and ends one year from the date the AoC is signed.

Where can I get the Azure PCI DSS audit documentation?
For links to audit documentation, see Audit reports. You must have an existing subscription or free trial account in Azure or Azure Government to login. You can then download audit certificates, assessment reports, and other applicable documents to help you with your own regulatory requirements.

Why are there multiple Azure Attestations of Compliance (AoC)?
The Azure PCI DSS AoC package has AoCs corresponding to Azure and Azure Government cloud environments. You should use the AoC that corresponds to your cloud environment.

What is the relationship between the PA DSS and PCI DSS?
The Payment Application Data Security Standard (PA DSS) is a set of requirements that comply with the PCI DSS. These requirements replace Visa's Payment Application Best Practices and consolidate the compliance requirements of the other primary card issuers. The PA DSS helps software vendors develop third-party applications that store, process, or transmit cardholder payment data as part of a card authorization or settlement process. Retailers must use PA DSS certified applications to efficiently achieve their PCI DSS compliance. The PA DSS does not apply to Azure or Azure Government.

What is an acquirer and does Azure use one?
An acquirer is a bank or other entity that processes payment card transactions. Azure does not offer payment card processing as a service and therefore does not use an acquirer.

To what organizations and merchants does the PCI DSS apply?
PCI DSS applies to any company, no matter the size, or number of transactions, that accepts, transmits, or stores cardholder data. If any customer ever pays a company using a credit or debit card, then the PCI DSS requirements apply. Companies are validated at one of four levels based on the total transaction volume over a 12-month period. Level 1 is for companies that process over 6 million transactions a year; Level 2 for 1 million to 6 million transactions; Level 3 is for 20,000 to 1 million transactions; and Level 4 is for fewer than 20,000 transactions. Azure maintains a PCI DSS validation at Service Provider Level 1.

Where do I begin my organization's PCI DSS compliance efforts for a solution deployed on Azure?
The information that the PCI Security Standards Council makes available is a good place to learn about specific compliance requirements. The Council publishes the PCI DSS standard and supporting documents such as the PCI DSS Quick Reference Guide and Prioritized Approach for PCI DSS that explain how customers can help protect a payment card transaction environment. PCI DSS can help protect a payment card transaction environment and how to apply it.

Compliance involves several factors, including assessing the systems and processes not hosted on Azure. Individual requirements vary based on which Azure services are used and how they are employed within the solution.