How Microsoft 365 quietly drifts into PCI scope

The customer service mailbox is the worst offender. Customers send card details unprompted, and well-meaning staff archive the message rather than delete it. The finance shared drive picks up spreadsheets that contain refund details, often with full PANs, because a manual reconciliation needed them at some point.

Teams chats are the newest entrant. A store manager attaches a photo of a card to ask whether a transaction looks legitimate. A finance team member screenshots a payment provider's portal. The PAN ends up in OneDrive as part of a Teams attachment, and it's still there a year later.

Once a PAN lands there, the storage system is technically in scope, and an auditor will say so. SAQ A is no longer the right form. The conversation gets significantly more expensive.

PCI DSS aside, a tenant full of PANs is a data breach in waiting. An attacker who phishes a single customer service mailbox doesn't need anything sophisticated to extract them. The regulatory exposure under UK GDPR is significant on its own, and the brand damage is worse.

The control isn't a binder. It's a continuous data hygiene practice.

DLP policies in Purview catch and quarantine PANs in transit. The built-in 'credit card number' sensitive information type is reasonable out of the box and can be tuned. Apply it to Exchange, SharePoint, OneDrive and Teams.

Pair it with a clear, enforceable policy that bank card details are never to be sent or stored by email or chat. Customer service should have a fixed line of response: 'we can't accept card details by email, please use the secure payment link'. Train it, audit it, and let the DLP catch the exceptions.

Then run quarterly cleanups of the obvious offending mailboxes and document libraries. Most retailers can get to a defensible position in a week of focused work, and stay there with a small recurring effort.

Microsoft 365 isn't the only place PANs hide. CRM systems, helpdesk tools and order management platforms all accumulate them through the same well-meaning customer service workflows. The same principles apply: DLP at the boundary, policy at the front, cleanup at the back.

Ecommerce platforms are usually safer because the PAN never passes through them, but check the order confirmation emails and the abandoned cart workflows. If there's any chance a PAN appears there, the platform is suddenly in scope.

Days one to thirty: turn on Purview DLP for the credit card sensitive information type across Exchange, SharePoint, OneDrive and Teams. Start in monitor mode so you can see how often it triggers and where.

Days thirty to sixty: tighten the policy to block-and-notify on email, and to apply a sensitivity label on documents. Run a sweep of the customer service mailbox and the finance shared drive and clear historical PANs.

Days sixty to ninety: train customer service on the 'never by email' policy, publish a one-page guide, and put a recurring quarterly audit in the compliance calendar.

Evidence that DLP is configured, that policies are enforced, that historical content has been remediated, and that staff have been trained. They don't need perfection. They need to see that you treat this as an ongoing control, not a one-off project.

That posture also happens to be the one that actually keeps you safer between audits, which is the bit that matters.

If you have a Qualified Security Assessor (QSA) for your PCI assessment, bring them into this conversation early. They've seen the patterns before, and they can confirm what evidence will satisfy them in the final assessment.

The worst version of this story is a firm that did a lot of cleanup work and then discovered, in the audit, that the QSA wanted it documented differently. The work was right; the evidence wasn't. A thirty-minute conversation upfront saves that outcome.