GDPR and Microsoft 365: the practical checkpoints

The contractual framework

Article 28 of the GDPR requires a contract governing processing on the controller's behalf. For Microsoft 365, that is the Microsoft Products and Services Data Protection Addendum (DPA), incorporated into the product terms. It sets out Microsoft's commitments as a processor, the security measures, the use of sub-processors and the transfer mechanisms. The data protection officer should know which version applies and should have referenced it in the record of processing activities, alongside every use of Microsoft 365 that involves personal data.

Data location and transfers

The EU Data Boundary aims to store and process customer data, and part of the pseudonymised data, for Microsoft's main cloud services within the European Union and EFTA. It was rolled out in phases, and some flows remain outside its scope, notably for support and security; check the current documentation for the exceptions. The tenant's data storage location can be checked in the admin centre.

Where transfers outside the EU remain, the DPA relies on mechanisms such as standard contractual clauses, and Microsoft is also certified under the EU–US Data Privacy Framework. That framework may be challenged in the courts: the transfer analysis should be documented and revisited when the legal context changes.

Data subject requests

Right of access (Article 15), right to erasure (Article 17): answering these requests means finding a person's data across mailboxes, OneDrive, SharePoint and Teams. Microsoft Purview search and eDiscovery tools make this possible, and Microsoft Priva offers a dedicated subject rights request module; check the licences currently required. Above all, a procedure is needed: who receives the request, who searches, who validates the scope, how the response is delivered, and within what timeframe.

Minimisation and retention periods

The storage limitation principle translates in Microsoft 365 into retention and deletion policies. In most tenants we audit, nothing is configured: everything is kept indefinitely, including the accounts and mailboxes of former employees. Points to address: retention of email and Teams conversations, what happens to leavers' OneDrive, deletion of obsolete shared mailboxes, and clean-up of abandoned SharePoint sites.

Confidentiality is the other side of the coin. Sensitive personal data (HR files, health data, identity documents) regularly ends up in sites or folders shared far too widely: "anyone with the link" links, "everyone except external users" groups, guests never removed. Purview sensitivity labels and DLP policies can detect and protect this content, but they assume you have first identified where the data lives. SharePoint sharing reports are a good starting point for measuring actual exposure.

Security and access logging

Article 32 requires appropriate security measures, and Article 33 requires breaches to be notified to the supervisory authority, in principle within 72 hours. Without logs, it is impossible to determine which data was accessed during an account compromise. Check: the unified audit log and mailbox auditing are enabled, log retention according to licences, the ability to identify the items accessed by a compromised account, and administrators' access to user content (eDiscovery roles, mailbox delegations, Customer Lockbox for access by Microsoft engineers). New uses such as Microsoft 365 Copilot, which works within existing access rights, often justify a data protection impact assessment.

What an audit checks

• Reference to the current DPA and the inclusion of Microsoft 365 uses in the record of processing.
• The tenant's data location, the scope of the EU Data Boundary and the transfer analysis.
• The procedure for handling data subject requests and the tools used.
• Retention policies and the handling of leavers' data.
• Access logging, administrators' rights over content and the ability to assess a breach.