DPA with Microsoft 365: Mandatory 2026 Adjustments for GDPR

Main article: DPA template Art. 28 GDPR — that article sets out the full list of the eight mandatory contents and the contract template; this article deals with the six minimum stipulations of Art. 28(3) GDPR and the Microsoft 365-specific adjustments. The two figures therefore do not refer to the same list.

What Art. 28 GDPR requires of a DPA as a minimum

Art. 28 GDPR requires two things: you may only work with Data Processors that provide sufficient guarantees of appropriate technical and organisational measures (paragraph 1), and the processing must be governed by a contract or another legal act with a statutorily prescribed minimum content (paragraph 3).

The selection decision under paragraph 1 and the drafting of the contract under paragraph 3 are two separate steps. A signed standard document answers only the second. The contract must stipulate at least the following; the full list of mandatory contents is set out in the main article:

This is exactly where the work lies with Microsoft 365: the subject matter, the type of data and the categories of data subjects differ in every company, whereas a vendor document can only describe them in general terms. Practice recommendation: keep the six items per tenant in a dedicated, dated annex and refer in it to the six adjustments described below.

All statements about Microsoft products and features in this article reflect the position as at 2 May 2026; the legal requirements have been examined in greater depth.

1. Activate the EU Data Boundary

Activate the EU Data Boundary (available since February 2024) as a tenant setting in the admin centre so that data and telemetry are processed in the EU, and additionally record the place of processing contractually — a tenant setting is a technical configuration, not a contractual stipulation.

Why this belongs in the contract: Art. 28(3) GDPR requires the subject matter as well as the nature and purpose of the processing to be stipulated; this minimum catalogue does not mention the place of processing — recording it contractually as well is a practice recommendation. At the same time, the place of processing determines whether there is a Third Country transfer at all; in the record of processing activities, the Third Country transfer together with its safeguard is a separate field (Art. 30(1) GDPR). If the data flow leaves the EU, the evidence route from point 4 applies.

Practice recommendation: file the configuration evidence with the date, the tenant designation and the responsible person. Repeat the export whenever the tenant configuration changes and whenever the Microsoft DPA version changes; an event-based trigger is easier to keep track of than a calendar interval. Record the chosen triggers in writing — this supports Accountability under Art. 5(2) GDPR.

2. Copilot tenant isolation

Set sensitivity labels for personal data holdings (PII) and restrict Copilot access by role before you release the service; without this isolation, Copilot can access all tenant data. Also record the release as a separate processing operation in the DPA annex.

The legal core: Art. 28(3) GDPR requires the nature and purpose of the processing, the type of personal data and the categories of data subjects to be stipulated. If a service accesses existing repositories across the whole tenant, these items no longer match what was agreed for mailboxes and file storage. Art. 9(1) GDPR is added to this: health data, trade union membership or data on religious beliefs are subject to a general prohibition on processing with narrow exceptions — operational repositories regularly contain such data, for example in personnel folders. Whether a data protection impact assessment is additionally required depends on the risk situation; Art. 35(1) GDPR expressly names the use of new technologies as a typical trigger for this prior check.

Practice recommendation: first roll out labels to the repositories containing personnel and health-related data, then enable a limited pilot group, document the result, and only then release the service broadly.

3. Document US sub-processors

Keep the roughly 150 US sub-processors in a dedicated, dated DPA annex, reconcile it monthly against the list in the Microsoft Trust Center (a practice cadence; Microsoft updates the list monthly) and mirror every change into your record of processing activities — so that, in the event of an inspection, you do not have to rely on a vendor source alone.

Why mirroring matters: the record of processing activities contains the categories of recipients and the Third Country transfers together with their safeguards as separate fields (Art. 30(1) GDPR); anyone acting as a Data Processor documents Third Country transfers including appropriate safeguards under Art. 30(2)(c) GDPR. This is precisely where two common errors occur: outdated recipient lists and missing Third Country references for US services.

Practice recommendation: a change log following the pattern from point 1; what matters is that the recipient categories named in the record of processing activities are updated along with it.

4. Schrems II / DPF annex

For every transfer to a Third Country, document which safeguard carries it, and file this assessment as a dated annex to the DPA — Microsoft is DPF-certified, but a dedicated annex remains recommended; EDPB 03/2026 confirms this need.

The standard of assessment: transfers to third countries need a safeguard — in practice standard contractual clauses (SCCs), the Data Privacy Framework (DPF) or binding corporate rules (BCRs). This safeguard must not only be chosen but documented: in the record of processing activities it sits in the same row as the transfer, and for Data Processors Art. 30(2)(c) GDPR expressly requires documentation. Without this assignment, it is impossible to show in response to a query what an individual data flow is based on.

Practice recommendation: also record whether the chosen safeguard actually holds in the recipient country — this assessment is known as a transfer impact assessment (TIA). In practice this is one sheet per safeguard: which data flow, which safeguard, date of the assessment, source, planned review date. This is at the same time the basis for switching quickly to a different safeguard if the need arises.

5. Right to audit

Record in the DPA how you verify compliance: what evidence you receive, who reads it and what applies if it fails to arrive. Microsoft only permits inspection of the SOC 2 report; either document that you accept this form of verification, or extend the audit right to include an on-site audit with validation of the ISO 27001 certificate.

Why the verification question is not a secondary issue: Art. 28(1) GDPR permits cooperation only with Data Processors that provide sufficient guarantees of appropriate technical and organisational measures. This selection decision has continuing effect and must be evidenced through Accountability (Art. 5(2) GDPR) — and it is the point at which a supervisory review, after the DPA and the record of processing activities, turns next: to the concept of technical and organisational measures and how well it fits the risk profile of the processing operations.

Practice recommendation: tie the review to the reporting period of the evidence provided: if a new SOC 2 report is available, it is read and the result noted with a date. Where you accept a form of verification that is offered, record the decision with a date instead of leaving the gap open. If the evidence fails to arrive, set a written grace period, record the failure with a date and reassess whether the selection decision under Art. 28(1) GDPR still holds — this assessment, with its result and date, belongs in the same file as the DPA annex.

6. Telemetry configuration

Limit diagnostic data centrally via GPO or Intune to the 'Required' level and record the chosen level together with the rollout route in the DPA annex; in the default setting, telemetry sends diagnostic data to Microsoft.

Why this deserves a line of its own in the contract: diagnostic data is a different processing operation from the use of productive data — a different purpose, different types of data, potentially a different set of recipients. Art. 28(3) GDPR, however, requires the nature and purpose of the processing as well as the type of personal data to be stipulated. Anyone who only describes the use of the applications has not covered this second processing operation. If the data flows to a Third Country, the safeguard and documentation route from point 4 applies in addition.

Practice recommendation: export the configuration status from the management solution in use and version it together with the DPA annex, so that changes to the level remain traceable.

Austria: what AT companies must additionally observe

The same DPA obligations apply to Austrian companies: Art. 28(1) and (3) GDPR apply directly, and there is no separate Austrian rule on processing on behalf of a controller. What differs is the national superstructure.

In addition, the duty of data secrecy under § 6 DSG applies in Austria: Controllers, Data Processors and their employees are bound to secrecy. For fining practice, § 11 DSG is relevant: it provides for a proportionate application of Art. 83 GDPR, in particular a reprimand instead of a fine for first-time infringements. This does not change the framework of Art. 83 GDPR.

Evidence: what must be available in the event of a supervisory query

Expect this order of review: record of processing activities, then the DPA, then the concept of technical and organisational measures, then the data protection impact assessment — the DPA is therefore, as a rule, read against your record. According to the Federal Commissioner for Data Protection (BfDI) activity report 2024, 85 % of all supervisory queries begin with the submission of the record.

The exception in Art. 30(5) GDPR applies only cumulatively: fewer than 250 employees and no risk to the rights and freedoms of data subjects and no regular processing and no special categories under Art. 9 GDPR or data on criminal convictions. Anyone who handles personnel data or runs a CRM processes regularly — in which case the exception does not apply.

Three statutory deadlines apply to you as Controller regardless of how quickly a vendor supplies information:

Practice recommendation: agree in the DPA annex an internal supply deadline for information requests and incident information that falls clearly before the statutory deadlines above. This internal deadline is an agreement, not a statutory deadline — it protects you only if it fits your own response time.

The framework within which infringements relating to processing on behalf of a controller sit: for infringements of the obligations in Art. 25 to 39 GDPR — including Art. 28 — Art. 83(4) GDPR provides for fines of up to EUR 10 million or, in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher.