Microsoft 365 & data protection: identify risks, implement measures and work in compliance with the GDPR

Which data protection issues exist with Microsoft 365?

The data protection risks associated with Microsoft 365 do not lie in one single aspect, but in a combination of transparency, role-allocation, transfer and control issues, as well as the scope of processing.

Transparency and processing for Microsoft’s own purposes

In the past, the German supervisory authorities criticised Microsoft for not disclosing clearly enough which data were processed, to what extent and for which purposes, including Microsoft’s own purposes.

In 2022, the German Conference of Independent Data Protection Supervisory Authorities, the Datenschutzkonferenz or DSK, still concluded that, under Microsoft’s data processing agreement then in place, the Data Protection Addendum or DPA, companies could not demonstrate GDPR-compliant use of Microsoft 365 without more specific knowledge of data flows, purposes and recipients and without additional safeguards.

Some supervisory authorities, such as the Federal Commissioner for Data Protection and Freedom of Information, the BfDI, continue to question the lawfulness of Microsoft’s processing for its own purposes in their 2025 activity report. Meanwhile, the Hessian supervisory authority, the Hessian Commissioner for Data Protection and Freedom of Information, the HBDI, issued a surprisingly positive statement on the use of Microsoft 365 in November 2025.

In that statement, the HBDI considered the processing purposes listed in Microsoft’s Data Protection Addendum to be permissible due to the anonymisation of the data.

Nevertheless, other data protection supervisory authorities have not sent signals as clear as those from Hesse. As a result, Microsoft’s transparency and processing for its own purposes remain potential points of contention.

Third-country aspects and subprocessors

Microsoft’s EU Data Boundary has improved the situation with regard to the place of data processing, as most processing now takes place only within the European Union. However, exceptions remain for example, for remote access, support cases, network transit and service-specific transfers. Microsoft cannot completely rule out access from third countries in support and maintenance scenarios.

Data from certain core online services are also stored only in the EU, but are not necessarily processed there. At the same time, however, potential transfers to the United States are covered by the European Commission’s adequacy decision, the EU-US Data Privacy Framework.

In addition, Microsoft uses numerous subprocessors. In the past, the DSK criticised Microsoft for not providing sufficiently transparent information about new subprocessors, thereby preventing companies from properly assessing changes.

Here too, the Hessian supervisory authority took a different view in its statement of November 2025 and considered the form of notification and the involvement of new subprocessors to be appropriate and permissible.

However, new questions may arise from the latest changes to Microsoft’s Data Protection Addendum from May 2026, which provide for shortened objection periods for the involvement of subprocessors for AI functionalities. In this respect, the situation must be continuously reassessed on the basis of the current contractual and factual circumstances. Transfers to third countries and the applicability of the EU Data Boundary should also always be reviewed.

Telemetry and burden of proof

Telemetry and diagnostic data, in particular, have repeatedly been regarded as critical in the past. In some cases, it remained unclear exactly which data Microsoft collects, transmits and potentially uses, including for its own purposes. Depending on the Microsoft product and Windows environment, different types of telemetry and diagnostic data may be involved to varying degrees.

From the perspective of the supervisory authorities and also the Federal Office for Information Security, the BSI, it is therefore important to configure any settings for telemetry and diagnostic data correctly and as data-sparingly as possible. Compared with earlier statements by these bodies, however, it must be taken into account that Microsoft now provides additional safeguards for the processing of these data and places them under the protection of the Data Protection Addendum.

Where certain data continue to be collected, for example for logging in relation to security aspects or for device management, the controller company must justify that processing.

Five selected points of criticism from the supervisory authorities at a glance:

• Microsoft does not disclose sufficiently which data it processes, how and for what purposes.
• Microsoft processes some data for its own purposes without a clear legal basis.
• Despite the EU Data Boundary, third-country access remains possible and the binding nature of instructions may be undermined.
• Companies have only limited control over subprocessors.
• The collection and use of telemetry and diagnostic data remain unclear.

The risk differs significantly depending on which service is activated in the tenant. But where there are issues, there are also levers. The following measures are important building blocks for a defensible use of Microsoft 365.

Which measures should companies implement specifically?

GDPR-compliant use of Microsoft 365 requires correctly configured, documented and service-specific operation. Good settings alone are not enough, but they solve a large part of the practical problems. The following five points are examples of relevant measures.

1. Limit the scope of use and minimise data

Activate only the services and functions that you actually need. Do not enable the entire M365 bundle by default. The fewer services, data categories and additional functions are active, the better you can justify, limit and document the processing.

In addition, use restrictive default configurations and sharing options. If AI is used, also define, document and limit the relevant Copilot use cases.

2. Reduce telemetry and analytics

Disable non-essential telemetry, analytics and reporting functions where technically possible. The criticism raised by authorities is aimed in particular at insufficient transparency regarding collected usage data.

This is also important in view of special employee data protection requirements, in order to prevent impermissible profiling or behavioural monitoring of employees. The BSI has also published recommendations on disabling telemetry in Windows.

3. Review contracts and allocation of roles

Do not accept the Data Protection Addendum without review. Assess whether it meets the requirements of Article 28 GDPR, particularly with regard to transparency, subprocessors and possible processing for Microsoft’s own purposes. The DSK expressly recommends working towards data protection-compliant agreements and, where necessary, negotiating additional agreements.

4. Assess third-country access separately

Even with the EU Data Boundary, transfers to the United States remain possible for example through remote access or support cases. Align tenant and storage locations with the EU, review support processes and document remaining third-country aspects, insofar as you rely on European data hosting in addition to the adequacy decision applicable to Microsoft Corporation in the United States.

5. Permissions, transparency and deletion concepts

Three further building blocks are part of the minimum setup:

• Authorisation concept: Implement need-to-know and least privilege consistently, assign differentiated roles and limit admin rights and access to analytics.
• Employee information: Inform your employees clearly about which M365 services you use, which data are generated and which restrictions apply.
• Deletion and offboarding concept: Define binding deletion periods, retention rules and offboarding processes, particularly for Exchange, Teams, SharePoint and OneDrive.

Companies that implement these measures consistently reduce data protection risks even though fully risk-free operation is hardly possible given the very broad range of possible uses and the potentially intrusive processing activities associated with them.

In addition to these measures, many companies also need to consider whether a data protection impact assessment is required.

When is a data protection impact assessment required for Microsoft 365?

A data protection impact assessment, or DPIA, is not mandatory simply because a company uses Microsoft 365. The decisive question is whether the specific processing is likely to result in a high risk to data subjects under Article 35 GDPR.

In practice, however, there is much to suggest that a DPIA is appropriate where Microsoft 365 is used across the company. Two criteria are almost always met: processing takes place on a large scale, and it concerns particularly vulnerable persons above all employees. Depending on the setup, additional risks may arise from the use of AI and from the comparison or combination of data, for example in more extensive analytics.

Rule of thumb

If a company uses Microsoft 365 only to a very limited extent and in a data-sparing manner, a DPIA may not be necessary in an individual case — but this should be examined carefully. If, by contrast, Microsoft 365 serves as the central collaboration and communication platform for the entire organisation, a DPIA will in most cases be appropriate or even necessary. Where Copilot agents, AI use in meetings, extensive analytics or sensitive data are involved, a DPIA is clearly required.

Quick assessment in five questions

Answer these five questions for an initial assessment:

1. Do you use the service across the company or for large parts of the workforce?
2. Do you process employee data, sensitive data or confidential content?
3. Do you use recordings, transcriptions or AI summaries in meetings?
4. Do you analyse application usage or use extensive diagnostic and telemetry data?
5. Do you integrate many external interfaces or automated AI agents?

Assessment: With 0–1 “yes” answers, there is probably no high risk. From 2 “yes” answers, a DPIA is likely to be appropriate. From 3 “yes” answers, you will probably need a DPIA.

How do supervisory authorities currently assess Microsoft 365?

The German supervisory authorities continue to take a partly critical view of Microsoft 365 but in a more differentiated way than the DSK did in 2022. In its report of November 2025, the Hessian data protection authority, the HBDI, stated for the first time at authority level that Microsoft 365 can be used in compliance with data protection requirements under certain conditions.

The European Data Protection Supervisor, the EDPS, also confirmed in July 2025 that the European Commission’s use was compliant with data protection law — after the Commission had previously implemented specific corrective measures.

What this means in practice

Have the authorities “cleared” Microsoft 365? No. Do they consider data protection-compliant use possible under strict conditions? In part, yes — but only with review, configuration and documentation effort.

What needs particular attention when using Microsoft Copilot?

Stricter requirements apply to Copilot than to classic M365 services. The key point is to distinguish between forms of use:

• Copilot Chat without complex integrations can be managed with clear rules and configurations — but file uploads, web search or lack of transparency already increase the risk.
• Copilot in meetings with transcription, summaries or audio/video analysis interferes more deeply with personal data — only enable this function after a separate review.
• Copilot agents with tenant access, external data sources or other AI models require more detailed assessments due to greater risks for IT security and data protection.

As a general rule, enable Copilot only with a clearly defined use case, create an AI policy, do not use AI outputs without review and inform employees in advance.

Conclusion: Microsoft 365 & GDPR: it depends on how it is used

Using M365 in compliance with the GDPR is possible but it is neither self-evident nor something that can be answered in general terms. The days of a categorical “not possible” are over, but there is equally no general all-clear.

The decisive factor is not the product name, but the specific tenant with the specific services that have been activated. The most important levers are: limiting the scope of use to what is necessary, disabling non-essential telemetry, actively reviewing contracts, tightly controlling permissions and informing employees transparently. Companies that also use Copilot should assess and approve each function separately.

A specifically configured and documented operation is not an optional extra, but the prerequisite for defensible use.

Frequently asked questions

#1 Can Microsoft Office 365 still be used in compliance with the GDPR?

Yes, data protection-compliant use is possible in principle but only with a documented case-by-case assessment and adapted configuration. The supervisory authorities have not issued a blanket ban, but they do expect companies to be able to independently justify their specific use.

#2 Is the EU Data Boundary sufficient for GDPR compliance with Microsoft 365?

No, the EU Data Boundary alone is not sufficient. It covers storage and large parts of processing within the EU, but does not exclude exceptions such as remote access, support cases and network transit. Companies must assess the residual risks themselves. However, Microsoft Corporation is also certified under the EU-US Data Privacy Framework for transfers to the United States.

#3 Is a DPIA mandatory for Microsoft 365?

A DPIA is not automatically mandatory, but in most cases it is appropriate or even necessary where Microsoft 365 is used company-wide with employee data or sensitive customer data. The decisive factor is the threshold assessment under Article 35 GDPR. Where processing is large-scale, involves sensitive data, extensive analytics or AI functions, the threshold is usually met.

#4 Which Microsoft 365 services carry the highest data protection risk?

The highest risk lies with services involving extensive data analysis: Copilot in meetings, Copilot agents, add-on services such as Viva Insights, as well as automation and analytics using Power Platform services. However, security applications may also lead to extensive data analysis. Standard services such as Exchange or SharePoint can be managed much more effectively with appropriate configuration.

#5 May Microsoft use data from Microsoft 365 for its own purposes?

Microsoft contractually reserves certain processing activities for its own purposes. Whether this is permissible is currently disputed among the supervisory authorities. While the Hessian supervisory authority considered anonymised or aggregated processing operations permissible in its statement of November 2025, the DSK reached a different conclusion in 2022.

#6 How does Microsoft Copilot change the data protection risk?

Microsoft Copilot can significantly increase the data protection risk, depending on the type of AI functions used. Meeting summaries, audio recaps, real-time translations and voice simulations, as well as agents with tenant access and automated tasks, may be particularly critical. Review each Copilot function separately and only approve it once the purpose has been clearly defined.

#7 Which data protection settings should companies change in Microsoft 365?

Relevant levers include reducing telemetry and diagnostic data to the necessary minimum, disabling unneeded services and add-on functions, restricting external sharing in SharePoint and OneDrive, and implementing restrictive permission concepts. The BSI has also published recommendations on disabling telemetry in Windows.

Do you need a data processing agreement for Microsoft 365?

Yes, a data processing agreement under Article 28 GDPR is mandatory. Microsoft provides the Data Protection Addendum, DPA, for this purpose, and it automatically becomes part of the licence agreement. However, do not accept the DPA without review. Pay particular attention to transparency, processing for Microsoft’s own purposes and subprocessors, as well as changes introduced by new versions of the DPA.