PCI DSS 4.0.1 Readiness Assessment for the Microsoft Cloud
Microsoft holds a PCI DSS 4.0.1 Attestation of Compliance for Azure, SharePoint Online and OneDrive for Business — but that attestation covers Microsoft's side of the shared-responsibility line, not your tenant, your subscriptions, or the card numbers your staff paste into email. IT Partner assesses the Microsoft 365 and Azure portion of your cardholder-data environment against PCI DSS v4.0.1 in 3 weeks for a fixed $4,950: we confirm where primary account numbers and sensitive authentication data actually flow (email, SharePoint, OneDrive, Teams, Dataverse, Azure workloads), map all 12 requirements to Microsoft's published responsibility matrix and to your configuration, review the controls that decide most Microsoft-estate findings — MFA for all access into the CDE, 12-month log retention, DLP for card numbers, encryption in transit and at rest, vulnerability and patch management, change control, and the payment-page script inventory and change-detection requirements for pages hosted in Azure — and hand you a prioritized remediation plan plus the evidence list your QSA or Self-Assessment Questionnaire will ask for. We are Microsoft engineers, not a Qualified Security Assessor: we do not issue a Report on Compliance or an AOC, we do not sign your SAQ, and nothing we deliver will call you 'PCI certified'.
What this engagement is
'Is Microsoft 365 PCI compliant?' is the question we get, and the accurate answer is that it is the wrong question. PCI DSS v4.0.1 — published by the PCI Security Standards Council in June 2024 and the only active version since v4.0 retired at the end of 2024 — is a standard that applies to your organization, not to a product. The 51 requirements that were future-dated in v4.0 became mandatory on 31 March 2025, so every assessment in 2026 is against the full standard: multi-factor authentication for all access into the cardholder data environment (8.4.2), twelve months of audit-log history with the most recent three months immediately available (10.5.1), authenticated internal vulnerability scans (11.3.1.1), user-access reviews at least every six months (7.2.4), an inventory and integrity check of every script on a payment page (6.4.3) with change-and-tamper detection at least weekly (11.6.1), mechanisms that protect staff against phishing (5.4.1), a documented scope confirmation every twelve months (12.5.2), and an incident procedure for card numbers found where they should not be (12.10.7). Merchants and service providers who took the 'we outsource payments' position now find their Microsoft estate inside the conversation — because that is where the card numbers went once someone emailed an order form, saved a gateway export to SharePoint, or built an order-processing app in Dataverse or Azure. Microsoft's side is genuinely strong. Azure, SharePoint Online, OneDrive for Business and Azure Communication Services carry PCI DSS 4.0.1 attestations at Service Provider Level 1, and the Attestation of Compliance and the responsibility matrix that goes with it are published on the Service Trust Portal; Microsoft's Azure PCI documentation also extends to Dynamics 365 and Power Platform. Two things follow. First, the responsibility matrix is the document your QSA will hold up against your configuration, and most of the requirements it assigns to 'customer' or 'shared' are exactly the tenant and subscription settings this assessment reviews. Second, the services that are not on that list matter as much as the ones that are: Exchange Online and Microsoft Teams are not named in Microsoft's PCI DSS attestation at the time of writing, so card numbers in mailboxes and chats sit outside anything Microsoft has attested to. The defensible answer there is almost always scope reduction — keep account data out of email and chat, detect it with Purview data loss prevention when it arrives anyway, and have the 12.10.7 procedure ready — rather than trying to drag a mail system into the CDE. We confirm the current in-scope service list against Microsoft's live AOC at the start of every engagement, because it changes. The engagement starts with data flow, because scope is where PCI assessments are won or lost. We confirm, with you, every path by which a primary account number or sensitive authentication data reaches a Microsoft service — hosted-checkout receipts and exports, phone orders typed into a Dataverse form or captured on a recorded Teams call, donation platforms feeding SharePoint lists, customer emails with card numbers in them, an order or payment application running on Azure App Service, SQL, Storage or a virtual machine — and which systems are 'connected-to' the CDE through identity, network or management paths. We then work the twelve requirements as they land on the Microsoft estate. Entra ID and Conditional Access carry Requirements 7 and 8, using Microsoft's own Entra ID PCI DSS guidance as the map: 12-character passwords under 8.3.6, MFA for every account with CDE access under 8.4.2, replay-resistant methods under 8.5.1, and the six-monthly access review that Entra access reviews can automate. Purview Audit — and Microsoft Sentinel or Azure Monitor where you run them — carries Requirement 10, where the 180-day default retention of Audit (Standard) is one of the most common gaps against 10.5.1. Purview DLP, sensitivity labels and retention carry Requirement 3, including the 3.4.2 control that stops PAN being copied out of a remote session, and the credit-card sensitive information type that finds account data where nobody expected it. Defender for Office 365 and Defender for Endpoint carry Requirements 5 and 11.3, including authenticated vulnerability scanning through Defender Vulnerability Management. On the Azure side we review network security groups, Azure Firewall and segmentation for Requirement 1, encryption and key management for Requirements 3 and 4, Defender for Cloud's PCI DSS v4 regulatory-compliance standard — or the same built-in Azure Policy initiative assigned in audit mode where you do not license Defender for Cloud — for Requirements 2 and 6, and the 6.4.3 script inventory and 11.6.1 change-detection controls for any payment page you host or serve from Azure. Where you license the Compliance Manager PCI DSS template, we use it as the evidence workbook; where you do not, ours does the job. Every requirement lands in a gap register as in place, partially in place, absent, not applicable or Microsoft-responsible, with the evidence reference beside it and the responsibility-matrix line it maps to. The remediation roadmap is sequenced by exposure and effort and separates the settings your own administrators can change next week from the projects worth scoping — a card-number DLP rollout, audit-retention licensing or a SIEM, an Azure segmentation redesign, a payment-page monitoring control. The evidence checklist is written for the person who will actually ask for it: your QSA if you are on a Report on Compliance, or whoever signs the SAQ if you self-assess. We are not that person. IT Partner is not a Qualified Security Assessor or an Approved Scanning Vendor; we issue no ROC or AOC, run no ASV scans, sign nothing, and the report says so on its first page. Your acquirer and the card brands decide your merchant level and which SAQ applies — the report is built to make that conversation short.
Success criteria
What you receive
How the work unfolds
Confirm merchant or service-provider status as you understand it from your acquirer, the SAQ type or ROC path you are on, the payment channels in use, and every Microsoft service and Azure subscription that could carry account data. Walk the data flows with finance, operations and IT. Set up time-bound, read-oriented access to Microsoft 365, Entra ID, Purview, Defender and the in-scope Azure subscriptions.
Pull the current PCI DSS 4.0.1 AOC and responsibility matrix from the Service Trust Portal, verify the in-scope service list against what you actually use, and build the requirement map: Microsoft-responsible, shared, customer-responsible, and not applicable to the Microsoft estate.
Evidence collection and scoring across Entra ID and Conditional Access, Purview Audit, DLP, sensitivity labels and retention, Defender for Office 365 and Defender for Endpoint, SharePoint, OneDrive and Teams sharing settings, Dataverse and Power Platform where account data lands, and the Compliance Manager PCI DSS assessment where you license it. Nothing is changed.
Inventory of CDE and connected-to subscriptions and resources, network segmentation and firewall rules, the Defender for Cloud PCI DSS v4 standard or the Azure Policy initiative in audit mode, encryption and key management, diagnostic logging, management-plane access, and the 6.4.3 and 11.6.1 controls for any Azure-hosted payment page.
Walk the draft gap register with IT and the compliance owner, resolve open evidence questions, rank gaps by exposure and effort, and assemble the remediation roadmap and the QSA/SAQ evidence checklist.
Deliver the report, roadmap and evidence checklist to leadership, finance and IT — with your QSA on the call if you choose — and agree what your team executes internally versus what is scoped as follow-on work.
Prerequisites
Who does what
IT Partner
- Confirm scope and document the data flows across the Microsoft estate.
- Verify Microsoft's current attestation and map every requirement to the responsibility matrix.
- Collect evidence and score every testable requirement against Microsoft 365 and Azure configuration, changing nothing.
- Produce the gap register, the remediation roadmap and the QSA/SAQ evidence checklist.
- Deliver the readout in plain language for leadership and in requirement language for your assessor.
- State scope limits explicitly in the report — what was assessed, what was not, and why.
Your team
- Provide access, stakeholders, prior reports and payment-channel information on the agreed schedule.
- Own the determination of merchant level, SAQ type or ROC path with your acquirer and the card brands, and any legal interpretation of the standard.
- Own the assessment of non-Microsoft systems — POS terminals, payment gateway, on-premises networks, third-party SaaS — and their place in your overall scope.
- Validate draft findings for factual accuracy within the review window.
- Decide remediation priorities and own risk acceptance for gaps deliberately left open.
- Execute the roadmap internally or scope follow-on implementation separately.
- Engage a QSA, an ASV or an internal security assessor for the formal validation your acquirer requires, and maintain the assessed posture between assessments.
What's not included
Limitations & technical notes
Frequently asked questions
Is Microsoft 365 PCI compliant?
Microsoft 365 is not a thing that can be PCI compliant; your organization is. What Microsoft offers is a PCI DSS 4.0.1 Attestation of Compliance, at Service Provider Level 1, for a named list of services — Azure, SharePoint Online, OneDrive for Business and Azure Communication Services at the time of writing — plus a responsibility matrix that says which requirements Microsoft covers, which you cover, and which are shared. Exchange Online and Teams are not on that list. So the honest answer is: Microsoft has done its part for the services it attests, and whether your Microsoft 365 is defensible depends on where card data lands and how you have configured identity, logging, DLP, encryption and vulnerability management around it. Measuring that gap is this assessment.
Are you a QSA? Can you certify us or sign our SAQ?
No, and we will not pretend otherwise. IT Partner is not a Qualified Security Assessor, an Internal Security Assessor or an Approved Scanning Vendor. We do not issue a Report on Compliance or an Attestation of Compliance, we do not sign or submit your Self-Assessment Questionnaire, and no deliverable will describe you as 'PCI certified' — a phrase the PCI Security Standards Council does not use for organizations either. What we are is the Microsoft 365 and Azure engineering team that knows exactly which setting evidences which requirement, so that when your QSA or your own SAQ asks, the answer is already in the binder.
We use a hosted checkout — Stripe, Square, PayPal, Shopify. Do we even have a cardholder data environment in Microsoft 365?
Possibly not, and if so the assessment ends with 'here is how to keep it that way', which is a good outcome. But the cases where card numbers leak into a Microsoft estate are almost never the checkout: they are the refund request a customer emails with the full card number, the phone order an agent types into a Dataverse form, the gateway export someone saved to SharePoint, the donation-platform CSV, the invoice paid over a recorded Teams call. The data-flow work in week one finds those paths. One more point for fully outsourced merchants: the January 2025 revision of SAQ A removed the payment-page script requirements but added an eligibility criterion — you must confirm your site is not susceptible to script attacks — and if that site runs on Azure, the assessment documents the evidence behind that confirmation.
What about card numbers customers email us?
Exchange Online is not on Microsoft's PCI DSS attested-service list, so a mailbox holding card numbers is unattested territory and, in practice, a scope problem you cannot configure away. The defensible pattern is scope reduction: a stated policy that account data is never accepted by email, a Purview DLP policy using the credit-card sensitive information type that detects it when a customer sends it anyway, a procedure for what staff do with that message (12.10.7 requires one), and a payment channel that does not involve typing a card number into Outlook. Encrypted email does not change this — it protects the message in transit and at rest, but it does not make a mail system a place account data should live.
Our payment page runs on Azure. What do 6.4.3 and 11.6.1 mean for us?
Two of the most consequential 4.0.1 requirements for anyone serving a payment page. 6.4.3 requires every script that loads in the consumer's browser on that page to be inventoried with a business justification, explicitly authorized, and integrity-checked — including analytics tags, chat widgets and CDN libraries. 11.6.1 requires a change-and-tamper detection mechanism on the HTTP headers and the script content the browser receives, run at least weekly unless a targeted risk analysis justifies a different frequency. Azure hosting gives you neither on its own; they are controls you build or buy. The assessment documents what is in place, where the page sits relative to the CDE, and what a compliant control needs to do — and if you have moved to an iframe or redirect from a PCI-listed provider, what that changes about your obligations.
Does Purview Audit satisfy the 12-month log retention rule?
Not by default. Requirement 10.5.1 wants twelve months of audit-log history with the most recent three months immediately available. Purview Audit (Standard) retains 180 days by default; Audit (Premium), which comes with the higher enterprise plans, retains Exchange, SharePoint, OneDrive and Entra ID records for one year, and a 10-year retention add-on exists for longer obligations. Azure activity and diagnostic logs have their own retention settings per workspace. The assessment states your current tier and retention, and where the gap is, the roadmap gives you the choice between a licensing change and exporting to a SIEM such as Microsoft Sentinel — which also carries the automated log-review requirement in 10.4.1.1 that a retention setting alone does not.
Which Microsoft licenses do we need to pass?
There is no single answer, and we distrust anyone who gives one. Microsoft 365 Business Premium and E3 with Entra ID P1 and Defender for Business or Defender for Endpoint Plan 1 cover a lot of ground: MFA, Conditional Access, device compliance, endpoint protection, basic DLP and audit logging. The gaps that most often need a license rather than a setting are audit retention (Audit Premium), authenticated vulnerability scanning depth (Defender Vulnerability Management), Azure regulatory-compliance reporting (Defender for Cloud plans) and Compliance Manager premium templates. The roadmap flags each licensing-bound item so you buy a plan only where a setting genuinely cannot cover the requirement.
We take card payments over the phone, sometimes on Teams calls. Is that a problem?
It is the finding we most often deliver with a straight face. If agents key card numbers into a Dataverse or SharePoint form, that workload is in your CDE and is assessed as such. If calls are recorded — Teams compliance recording included — and the recording captures the card number or the security code, you are storing sensitive authentication data after authorization, which the standard prohibits outright and no configuration remediates except stopping the capture. Merchants solve this with pause-and-resume recording, DTMF masking, or moving the payment step to a PCI-listed telephony provider; Azure Communication Services is on Microsoft's attested list if you build on it. We document the data flow and the options; building the payment channel is separate work.
Are Dynamics 365, Dataverse and Power Apps in scope?
Yes, whenever account data lands in them — an order entity with a card field, a Power Apps form used by phone agents, a Power Automate flow that moves gateway exports into a table. Microsoft's Azure PCI DSS documentation extends to Dynamics 365 and Power Platform, so the platform side is attested; the customer side — environment segregation, Power Platform DLP policies on connectors, field-level security, audit logging in Dataverse, who can export — is yours and is reviewed in week two alongside the Microsoft 365 workloads.
How is this different from your CIS, SOC 2 or HIPAA assessments?
Same evidence base, different yardstick. PCI DSS is the most prescriptive of the frameworks we assess against — it names the password length, the retention period, the scan frequency — and it applies only where card data is, so scope is a larger part of the work than in a CIS or SOC 2 engagement. Choose this assessment when an acquirer, a processor or a customer is asking about card data; choose the CIS Controls v8.1 Gap Assessment for a general security yardstick, the SOC 1, SOC 2, ISAE 3402 pre-audit assessment when a customer wants an auditor's report, and the HIPAA Compliance Assessment for protected health information. Evidence gathered in any of them is reusable in the others, and we say which items carry over.
What does the evidence checklist look like?
A table per requirement: the artifact your assessor will ask for — a Conditional Access policy export, the DLP policy definition and its match report, the audit-retention policy, a Defender vulnerability report with remediation dates, an Azure Policy compliance export, a script inventory — where it lives, who owns it, and how fresh it has to be. It is organized to drop into your compliance binder or, if you license Microsoft Purview Compliance Manager's PCI DSS premium template, into that assessment; Microsoft counts the v3 and v4 PCI templates as one, and some enterprise plans include an allowance of premium templates. The retainer that keeps the binder current month to month is a separate service.
Can you fix what you find?
Yes, as separately scoped follow-on work — deliberately not bundled into the assessment, so the findings stay honest and you keep leverage on what to fix and with whom. There is no lock-in in either direction: stop any engagement at any time, owing only previously approved invoices. Quick wins — MFA gaps, a DLP policy for card numbers, an audit-retention setting, an access-review schedule — are written so your own administrators can execute them from the roadmap; project-scale items map to services we run. If you buy your Microsoft licensing through IT Partner, break-fix support during business hours is included at no extra charge; this assessment and any remediation are project work and are quoted separately.
We are a SaaS provider, not a merchant. Does this still apply?
It applies more, not less. Service providers carry everything merchants do plus the service-provider-only requirements — executive accountability for the compliance program (12.4.1), scope confirmation every six months (12.5.2.1), and detection of critical-control failures — and your customers' QSAs will ask you for an AOC and a responsibility matrix of your own. The assessment maps which of Microsoft's attestations you can inherit for your Azure-hosted platform, which requirements are shared, and which you must evidence yourself, and it shapes the evidence checklist so your own QSA engagement starts from a prepared position rather than a blank request list.
Why $4,950 and three weeks?
Because the scope is fixed: one Microsoft 365 tenant, up to three Azure subscriptions carrying CDE or connected-to workloads, the twelve requirements as they land on the Microsoft estate, fifteen working days. The price is quoted in writing before work begins and you pay after you approve delivery. If your environment is genuinely bigger — multiple tenants, a large Azure estate, several distinct payment applications — we say so on the scoping call and quote the difference before anything starts, not after.