GDPR and Your Office 365 Tenant: The Questions Clients Keep Asking

GDPR enforcement begins May 25. That is five weeks and three days from the date on this post, and the volume of GDPR questions landing in our inbox has roughly tripled since January. Most of them come from clients we moved to Office 365 over the past two years — organizations that assumed, reasonably, that putting mail and documents in Microsoft's cloud would make compliance somebody else's problem. It doesn't. It changes whose problem which parts are.

We are not lawyers, and this post is not legal advice. What we can offer is the practitioner's view: across a portfolio that now covers more than 15,000 migrated mailboxes in government and enterprise tenants, the same eight or nine GDPR questions keep coming up, and most of them have concrete, technical answers that your counsel will still need to bless. This is the checklist we walk through with clients. It is about Office 365 compliance mechanics, not legal theory.

One framing point before the details. GDPR splits the world into controllers (you) and processors (Microsoft, for the data you put in their cloud). Microsoft has been loud about its own processor obligations — contractual commitments, audit reports, the works. None of that discharges your controller obligations. Knowing where the line sits is most of the battle.

Where your data actually lives

The first question is always data residency, and the honest answer is more nuanced than the datacenter map suggests. Office 365 stores data in a geography determined by your tenant's signup country. European tenants land in the EU datacenters (Dublin and Amsterdam, primarily). You can see the actual locations for each workload under the tenant's organization profile — Exchange Online, SharePoint Online, and Skype for Business Online are listed separately, because they can and do differ.

Things clients are surprised by:

• Residency is per-workload, not per-tenant. Your mailboxes may sit in the EU while some ancillary service data does not. Microsoft publishes which data categories stay in-geo and which don't; read that list rather than assuming.
• A US-headquartered tenant with EU employees keeps EU employees' mailboxes in US datacenters. GDPR does not require EU residency — it requires a lawful transfer mechanism (Microsoft relies on Privacy Shield and the EU Model Clauses) — but plenty of works councils and DPOs want residency anyway. For the largest tenants, Multi-Geo capabilities, announced at Ignite last fall and now reaching customers, will eventually let you pin specific users' mailboxes and OneDrive sites to a satellite geography. If you are under a few thousand seats, this is not yet your tool.
• Residency is not sovereignty. If someone insists on German data trusteeship, Microsoft Cloud Germany exists as a separately operated environment — with a feature set that lags the global cloud badly enough that we have talked every client but one out of it.

Our position: residency questions are usually proxy questions. What the DPO actually needs is the transfer-mechanism paperwork and a data-flow diagram. Produce those first.

Retention and deletion want opposite things

GDPR's right to erasure (Article 17) collides head-on with every retention obligation you already carry. Public-sector clients have records schedules; financial clients have supervisory rules; everybody has litigation holds. The regulation acknowledges the conflict — erasure yields to legal retention duties — but your tenant configuration has to express that logic, and most tenants we audit express nothing at all.

The mechanics in Office 365, as of April 2018:

• Retention policies in the Security & Compliance Center are the current tool of record. They apply across Exchange, SharePoint, OneDrive, and Office 365 Groups, and they can both keep data for a period and delete it afterward. The older Exchange retention tags and messaging records management still work, but new design effort should go into the unified policies.
• A retention policy that keeps everything forever is now a liability, not a safety blanket. Storage minimization is an explicit GDPR principle. "Keep all mail indefinitely because storage is cheap" was defensible in 2015. It reads very differently to a regulator in 2018.
• Litigation hold beats erasure, and that's fine — but document the hold's scope and review cadence so you can demonstrate the exception is genuine.

The design conversation we run with clients is a two-axis matrix: data categories on one axis, retention drivers (statutory, contractual, operational) on the other. The tenant policies fall out of the matrix. Doing it in the other direction — configuring policies first and rationalizing later — produces the tenants we get called in to untangle.

Data subject requests: Content Search is your workhorse

Articles 15 through 20 give data subjects rights of access, rectification, erasure, and portability. Operationally, every one of them starts the same way: find everything the tenant holds about person X. In Office 365 that job belongs to Content Search in the Security & Compliance Center, and Microsoft has recently added a dedicated Data Subject Request case type built on the same eDiscovery machinery.

Some field notes from running DSR rehearsals with clients this quarter:

New-ComplianceSearch -Name "DSR-2018-0417" `
  -ExchangeLocation All -SharePointLocation All `
  -ContentMatchQuery '"jane.doe@contoso.com" OR "Jane Doe"'
Start-ComplianceSearch -Identity "DSR-2018-0417"
New-ComplianceSearchAction -SearchName "DSR-2018-0417" -Export

• Rehearse now, with a fictional subject. The 30-day response clock is short. The first DSR a client runs cold typically takes two weeks of fumbling; the second takes two days. Buy the fumbling at rehearsal prices.
• Name-based queries over-collect and under-collect simultaneously. "Jane Doe" pulls in every mail mentioning a different Jane Doe and misses the row where she is only an employee ID. Expect a human review pass; the tooling gets you a corpus, not an answer.
• Don't forget the places Content Search doesn't reach. Skype for Business conversation histories land in mailboxes and are searchable; third-party SaaS connected to the tenant is not. Your DSR runbook needs a system inventory, not just a search query.
• Erasure is harder than access. Purging a person's data from mailboxes under retention policy requires deliberate, documented exception handling. Do not let a well-meaning admin hard-delete their way through a request.

What the processor agreement actually covers

Microsoft's GDPR commitments live in the Online Services Terms — the data processing terms are baked into the volume licensing paperwork every tenant already has, which surprises clients who expected to sign something new. Those terms make Microsoft your Article 28 processor for customer data in the services: they commit to processing only on your instructions, to breach notification, to sub-processor transparency, and to supporting your compliance obligations.

What the paperwork does not do:

• It does not classify your data. You still need to know what personal data you hold and why.
• It does not configure your tenant. Every retention policy, every access control, every audit setting is controller-side work.
• It does not cover the humans. Your admins with eDiscovery rights, your delegated partner access, your service accounts with application impersonation — all controller-side risk. Audit them. Azure AD sign-in reports and the unified audit log (turn it on; it is still not on by default) are your evidence trail.
• It does not answer for shadow IT. The marketing team's unsanctioned mailing tool is your problem, and no Microsoft document mentions it.

Worth knowing: Compliance Manager, which reached general availability in February, gives you a scored, evidence-tracked breakdown of exactly this controller/processor split for GDPR. We have started using it as the working document in client workshops — not because the score means much, but because the task list is a decent forcing function.

The five-week punch list

For clients who are starting late, this is the priority order we are recommending between now and May 25:

1. Turn on the unified audit log and verify mailbox auditing on privileged mailboxes. Evidence first.
2. Inventory admin and delegated access — global admins, eDiscovery managers, partner relationships. Cut what you can't justify.
3. Stand up a DSR runbook and rehearse one request end to end, including the export and the review pass.
4. Rationalize retention — even a coarse first-pass policy beats the accidental forever-hold most tenants run.
5. Collect the paperwork — Online Services Terms, audit reports from the Service Trust Portal, your data-flow diagram — into one folder your DPO can hand to a regulator.

None of this makes you compliant by itself. All of it makes the conversation with counsel and regulators dramatically shorter, and every item is genuinely useful hygiene even if GDPR never knocks.

If you're facing this

We have spent the spring running exactly these workshops across government and enterprise tenants, and the pattern is always the same: the technical work is days, not months, once someone frames the questions correctly. If your tenant needs a GDPR-shaped audit before May 25 — or a calm second opinion after it — get in touch. We can usually tell you within a day which of these items actually applies to your estate.