DPA with Microsoft 365: Mandatory 2026 Adjustments for GDPR

Practitioner note: This is not legal advice. For specific situations, consult a qualified attorney or compliance officer.

TL;DR

  • Microsoft's standard DPA is insufficient — it covers Art. 28 GDPR core duties but leaves six critical gaps
  • EU Data Boundary must be actively configured in the tenant settings
  • Copilot tenant isolation required — otherwise Copilot can read all tenant data without sensitive labels
  • ~150 US sub-processors need their own annex; refresh monthly from Microsoft Trust Center
  • Right-to-audit limited to SOC 2 access — extend with ISO 27001 validation in writing

1. Why Microsoft's standard DPA is not enough

Microsoft's online services Data Protection Addendum covers the core obligations under Art. 28 GDPR, but six configuration and contract gaps remain. Each gap must be closed in your own annexes and operational settings before the DPA can be considered audit-ready. SMEs should treat the standard DPA as a starting point, not a finished contract.

2. Activate EU Data Boundary

Microsoft's EU Data Boundary (live since February 2024) keeps customer data and most telemetry within EU data centers. Activate it through the Microsoft 365 admin center as a tenant setting and document the activation date in your records of processing. Without this step, data continues to flow to US regions for support and diagnostics.

3. Enforce Copilot tenant isolation

Copilot can access all tenant data unless restricted. Apply sensitive labels to personal data, restrict Copilot access by role, and disable broad indexing of HR or finance shares. Document the labeling policy as part of your TOM (Technical and Organizational Measures) catalog.

4. Document US sub-processors and DPF status

Microsoft uses approximately 150 US-based sub-processors. Maintain a current annex listing each one, refreshed monthly from the Trust Center. Microsoft is DPF-certified, but a Transfer Impact Assessment (TIA) annex is still recommended — the EDPB confirmed in March 2026 that controllers retain assessment duties even under an adequacy decision.

5. Extend the right-to-audit clause

Microsoft permits only SOC 2 report inspection rather than on-site audits. Either accept this limitation in writing with a documented rationale, or supplement the DPA with an ISO 27001 certificate validation clause. Supervisory authorities accept both approaches when the choice is recorded.

6. Restrict telemetry to "Required"

Microsoft's default diagnostic data level transmits file metadata to the US (a known concern from the LG München litigation). Restrict telemetry to the "Required" level via Group Policy or Intune across all endpoints, and document the configuration in your TOM concept.

7. Review cycle and version control

The DPA stays valid until the master agreement ends, but Microsoft updates the terms periodically. Review the DPA version quarterly via the Microsoft Trust Center, log the version and date in your compliance documentation, and amend your records of processing whenever sub-processor categories change materially.

Summary

The Microsoft 365 DPA is GDPR-acceptable only after six adjustments: EU Data Boundary, Copilot isolation, sub-processor annex, DPF/TIA evidence, expanded right-to-audit, and telemetry restriction. Treat each as a configurable control, not a contract clause to be ignored. The German source article includes additional context on Schrems II migration paths.

View GDPR Kit →

Frequently Asked Questions

Is the standard Microsoft DPA sufficient for GDPR compliance?

No, it is not sufficient. The standard Microsoft data processing agreement (DPA) covers the core obligations under Art. 28 GDPR but leaves 6 critical points open: EU Data Boundary must be actively configured, the DPF guarantee for US sub-processors requires a separate annex, Copilot tenant isolation is mandatory (otherwise Copilot can access all tenant data), telemetry configuration must be restricted to 'Required', the sub-processor list with approximately 150 US providers must be updated monthly, and a right-to-audit clause must be added (MS only permits SOC 2 report review). These adjustments must be documented in separate annexes.

Who is liable in the event of a sub-processor incident?

Microsoft, as the principal processor, is primarily responsible to you (Art. 28(4) GDPR). MS passes the processor obligations on to sub-processors — for example, to hyperscaler region operations or telemetry providers. In the event of an incident, you are liable as the controller to data subjects, MS is liable to you, and the sub-processor is liable to MS (chain of liability). In practice: damages claims are directed at MS, MS conducts internal recourse. Systemic sub-processor problems may overturn DPF status — therefore keep Plan B actively in place.

What should be done if the Data Privacy Framework (DPF) is overturned?

Step 1: Immediately initiate migration to an EU alternative — Stack-IT (Schwarz Group), IONOS Cloud or MagentaBusiness Cloud are functionally comparable to M365. Step 2: Historical transition periods of 0-3 months (Privacy Shield 2020). Step 3: Activate SCC 2021/914 + TIA as backup safeguards. Step 4: Minimize data flows — immediately transfer sensitive data to an EU region. Recommendation: prepare Plan B, run the EU alternative in test mode. Migration duration M365 → Stack-IT: 2-6 months.

Which Microsoft 365 features are especially GDPR-critical?

Top 3 risks: 1) Copilot — can access all tenant-wide data without sensitive labels. 2) Telemetry — the default diagnostic data level transmits file metadata to MS (Munich Regional Court risk). 3) E-mail archives in Exchange Online — with active litigation hold, deletion is not possible. Solution: apply sensitive labels for PII, restrict telemetry to 'Required' (via GPO/Intune), limit Copilot access by role, activate Customer Lockbox.

Do we need to re-sign the DPA annually?

No, the data processing agreement (DPA) remains valid until termination of the main contract. HOWEVER: Microsoft periodically updates the DPA terms. You should review the DPA version quarterly (in the Microsoft Trust Center) and incorporate changes into your own record of processing activities (ROPA). For material changes (e.g. new sub-processor categories), written form is recommended. Audit tip: document the date and version of the currently valid DPA in your own compliance documentation.

Sources