Data Processing Agreement (DPA)

General definition

Data Processing Agreement (DPA) is the contract that the EU General Data Protection Regulation (GDPR) requires between a controller (the organisation that decides why and how personal data is processed) and a processor (a vendor that processes it on the controller’s instructions). Article 28 makes the contract mandatory and lists what it must contain. The UK GDPR carries the same requirement, and similar processor contracts exist under other laws, for example the Business Associate Agreement under HIPAA in the United States.

Article 28(3) requires the DPA to set out the subject matter, duration, nature and purpose of the processing, the types of personal data and categories of data subjects, and the obligations of both parties. In particular the processor must:

• process personal data only on the controller’s documented instructions, including for international transfers
• ensure that staff with access are bound by confidentiality
• implement appropriate technical and organisational security measures (Article 32)
• engage sub-processors only with the controller’s authorisation and pass the same obligations down to them
• help the controller respond to data subject requests, breaches and impact assessments
• delete or return the data at the end of the service, and make available the information needed to demonstrate compliance, including audits

A DPA usually arrives as a standard document from the vendor with annexes: a description of the processing, the security measures, the current sub-processor list and, where data leaves the EU or UK, Standard Contractual Clauses. Controllers should read the sub-processor list and the hosting region carefully, because that is where data residency is actually decided.

For a chat platform the DPA is not a formality. Messages, attachments, presence and login records are personal data, and in healthcare, finance and education they can be special-category data. The controller needs the processor to support retention limits, per-user erasure and access logs, and needs to know whether the vendor, or anyone the vendor uses, can read the content.

In the Ethora ecosystem

Ethora publishes a DPA and signs one with dedicated, self-hosted and Enterprise customers, listing the sub-processors involved in running the service. The deployment model changes what the DPA has to cover. On the managed cloud, Ethora hosts the App and is a processor in the usual sense. On a dedicated server, Ethora TechOps operate the platform inside your own AWS, DigitalOcean or other cloud account, so you choose the region (EU-only is possible) and the data never leaves infrastructure you own. On a self-hosted deployment you run the open-source stack yourself and Ethora processes nothing.

The platform features that make a DPA workable in practice are built in: configurable retention, per-user erasure to answer deletion requests, a compliance audit trail with immutable log export, and access controls in the admin panel. For US healthcare customers the equivalent contract is a Business Associate Agreement covering protected health information, which Ethora signs on Enterprise and dedicated plans.