GDPR

The General Data Protection Regulation (GDPR) is the EU's comprehensive privacy regulation, effective since 2018, governing how organisations process personal data of EU residents. Key requirements: lawful basis for processing, data minimisation, subject rights (access, rectification, erasure, portability, objection), breach notification within 72 hours, Data Protection Officer for many organisations, and the EU Data Boundary for data residency. Microsoft 365 supports GDPR compliance through Microsoft Priva (subject rights requests, privacy risk management), Microsoft Purview (data classification, retention, eDiscovery), EU Data Boundary (data processed and stored within the EU), and the Microsoft Data Protection Addendum in licensing agreements. Non-compliance fines can be substantial — up to 4% of annual global revenue.

Controller vs processor: who GDPR actually points at

GDPR's obligations attach differently depending on the role. A customer running Microsoft 365 is almost always the data controller — the party that decides why and how personal data (employee records, customer emails, files) gets processed. Microsoft, as the platform provider, is the data processor, acting on the controller's instructions and bound by the Microsoft Data Protection Addendum. That split matters in practice: Microsoft is responsible for keeping the infrastructure secure and honouring processing instructions, but the controller — the customer's own organisation — is the one who has to answer a subject access request, decide what "personal data" exists in their tenant, and justify the lawful basis for processing it. Buying a GDPR-compliant platform doesn't make an organisation's own use of that platform automatically compliant.

Worked example: a subject access request

An employee emails HR asking what personal data the company holds about them — a textbook subject access request under Article 15. Without tooling, this becomes a manual hunt across mailboxes, SharePoint sites, Teams chats, and HR systems. With Microsoft Priva's Subject Rights Requests feature, an admin creates a request scoped to that person's identity, and Priva searches Exchange, SharePoint, OneDrive, and Teams for content associated with them, surfaces it for review, and lets the admin redact anything belonging to a third party (a colleague copied on an email, say) before exporting the response. The 72-hour breach-notification clock is a separate, faster-moving obligation: it starts from when the organisation becomes aware of a personal-data breach, not from when the investigation concludes, which is why an incident-response runbook needs its own explicit GDPR notification step rather than treating it as an afterthought once the technical fix is in.

Common pitfalls

The most common Microsoft 365 GDPR mistake is treating retention and privacy as the same problem — a Purview retention policy that keeps mail for seven years for legal-hold reasons can directly conflict with a data-minimisation principle that says personal data shouldn't be kept longer than necessary, and reconciling the two requires an actual documented retention schedule, not a single blanket policy. The second is assuming the EU Data Boundary alone satisfies every residency requirement — it covers where data is processed and stored for in-scope EU services, but support access, some diagnostic data flows, and non-EU-Boundary services can still fall outside it, so the specific workloads in scope need checking against the current Boundary documentation rather than assumed. The third is DPO confusion: not every organisation using Microsoft 365 needs a Data Protection Officer under GDPR — it depends on scale and the nature of processing — but many assume the requirement applies universally and either skip a genuinely required appointment or create one unnecessarily.