Compliance
DPA
Data Processing Agreement
A Data Processing Agreement (DPA) is a legally binding contract between a data controller, the organisation that determines the purposes and means of processing personal data, and a data processor, the organisation that processes that data on the controller's behalf, setting out the terms under which the processor is permitted to handle it.
Why DPA matters in a Microsoft estate
DPA matters because customers, resellers, and procurement teams need evidence that controls are defined, operated, and reviewable. A useful glossary definition should help a reader connect the term to audit preparation, policy work, or repeatable assurance activity.
How DPA shows up in practice
Under UK GDPR and the EU GDPR, a DPA is not optional or a nice-to-have: Article 28 specifically requires one wherever a controller engages a processor, and it must contain a defined set of mandatory terms, including the subject matter, duration, nature, and purpose of processing, the type of personal data and categories of data subjects involved, the processor's obligation to only process data on the controller's documented instructions, confidentiality commitments for anyone with access, appropriate technical and organisational security measures, terms governing the use of sub-processors (including a requirement to flow down equivalent obligations to them), assistance obligations to help the controller respond to data subject rights requests and breach notifications, and provisions for data deletion or return at the end of the engagement.
For organisations operating in a Microsoft 365 and Azure environment, DPAs surface in two directions that are easy to conflate: Microsoft itself acts as a data processor for customer data in Microsoft 365 and Azure, with its processor obligations set out in the Microsoft Products and Services Data Protection Addendum referenced from the Microsoft Customer Agreement, while the customer organisation is simultaneously the controller for its own tenant data and often also a processor in its own right when it handles personal data on behalf of its own customers.
That means most MSPs and SaaS vendors serving other businesses need their own DPAs in place with their customers, not merely reliance on Microsoft's. A DPA is distinct from, though closely related to, an International Data Transfer Agreement or Standard Contractual Clauses, which are the separate mechanism required when personal data is transferred outside the UK or EEA to a jurisdiction not covered by an adequacy decision.
Organisations sometimes mistakenly assume a signed DPA alone covers cross-border transfer compliance when Microsoft's own data residency and transfer mechanisms need to be checked separately for the specific Microsoft 365 or Azure regions and services in scope. In practice, DPA review is a standard item in vendor and supplier due diligence, and gaps most commonly surface around sub-processor transparency (whether the processor discloses and allows objection to new sub-processors), breach notification timelines that are tight enough to meet the controller's own 72-hour regulatory reporting obligation, and whether the DPA's security measures actually reflect what the processor does in practice rather than generic boilerplate language.