Cloud Security Stack
Compliance and governance

Compliance

GDPR in a Microsoft 365 tenant: what actually needs configuring

Most GDPR work is documentation, not configuration. The parts that genuinely are technical, and where Microsoft 365 helps rather than hinders.

13 min read · Reviewed 22 August 2026 · UK and EU GDPR. Written against the regulation and Microsoft's published capabilities.

Almost none of GDPR is a product setting

The regulation is about lawful basis, purpose limitation, transparency, and the rights of individuals. Those are decisions and records, not switches. An organisation with a perfectly configured tenant and no record of processing activities is not compliant, and one with a messy tenant and good records is much closer than it looks.

This matters because vendors sell GDPR as a technical problem. The technical part is real but small, and treating it as the whole job is why organisations are surprised by their first subject access request.

The parts that genuinely are technical

01

Finding personal data you did not know you held

Content search and Purview classifiers across Exchange, SharePoint, OneDrive and Teams. You cannot honour a deletion request in data you cannot locate, and almost every organisation holds more than it thinks.

02

Answering a subject access request in time

One month, extendable to three. The work is search plus review plus redaction of third-party data, and doing it manually the first time is how organisations discover the deadline is tight.

03

Retention that actually deletes

A retention policy that keeps everything forever is a liability under storage limitation, not a safety measure. Deletion has to actually happen and you need to be able to show it did.

04

Data residency and transfers

Where the tenant stores data at rest, and which services process outside that region. This is a configuration and contract question combined, and it changes as Microsoft adds services.

Where the effort actually sits
TechnicalDocumentation
Record of processing activities
Lawful basis for each purpose
Privacy notices
Locating personal data
Subject access requests
Retention and deletion
Breach notification within 72 hours
Processor contracts

A rough split rather than a legal position. Take advice on your own processing before relying on any of it.

The 72 hour clock is the one to rehearse

Notification of a personal data breach to the supervisory authority is due without undue delay and within 72 hours of becoming aware. The organisations that miss it are almost never the ones without tooling. They are the ones who had never decided who declares a breach, or who could not establish what data was affected quickly enough to say anything useful.

Rehearse that decision path. It is worth more than another licence.

The verdict

Our pick

Do the record of processing activities first

It is the artefact everything else hangs off, a regulator will ask for it, and writing it forces the questions that reveal what you actually need to configure.

Who should skip

Do not start with data loss prevention policies. Enforcing rules about data you have not yet mapped produces false positives, business workarounds, and no compliance benefit.

Disclosure. Some links on this site are affiliate links. Scoring weights are published before any programme is joined, and commission is never a ranking input. Full policy, and the method behind this guide.