The contract must describe the actual processing
A data processing agreement (often referred to as DPA or *AVV* in German) supplements the service contract. It becomes relevant when a provider processes personal data on behalf of its client-for instance, in cases of hosting, support, newsletter distribution, or cloud applications. What matters is the actual use of the data, not the document's title.
The agreement aims to clarify responsibilities. Among other things, it explains the scope of the commissioned processing, the applicable instructions, and how the provider assists in protecting the data. A comprehensive standard text fails to serve its purpose if it describes a completely different product. Clients should therefore review the agreement's provisions in conjunction with the service proposal, technical documentation, and intended use.
Whether a data processing arrangement exists-and which regulations are required-depends on the specific relationship and applicable law. A general checklist cannot replace this legal assessment. Therefore, expert advice should be sought in cases involving unclear roles, sensitive data, or unusual processing activities. Well-documented data flows, responsibilities, and contract details provide a reliable factual basis for this assessment.
Controllers and processors have distinct roles
The controller determines the purposes and essential means of the processing. The processor processes personal data on the controller's behalf and in accordance with their documented instructions. These terms denote roles under data protection law, not a general hierarchy between companies. A large platform provider can act as a processor, while a small client acts as the controller for the processing in question.
Roles may vary depending on the specific function. A provider might process customer data on behalf of the client but use certain contract or billing data for its own purposes. In such cases, the provider should clarify which role it assumes for specific operations. A blanket statement claiming that all data is processed solely on the client's behalf is of little use if the product description or privacy notice also mentions the provider's own use of the data.
A contract cannot alter the actual roles simply through the use of a specific label. Therefore, it is essential to understand who decides on the use of the data before signing. If the provider determines a new purpose independently of the client, this may fall outside the scope of the agreed data processing. Such boundaries require a clear explanation so that responsibilities, information provided to data subjects, and other legal bases can be correctly assessed.
Subject matter, duration, and data types require specific details
The agreement should clearly indicate which service is being provided and which personal data is involved. General wording-such as "provision of agreed services"-is often insufficient to understand the flow of data. A support system, for instance, might involve contact details, message content, and technical usage data. The categories of data subjects-such as customers, employees, or job applicants-should also align with the actual use of the data.
The nature and purpose of the processing are equally important. Storing, transmitting, analyzing, and deleting describe distinct operations. The purpose explains why these actions take place-for instance, to handle support requests or operate a customer platform. The more precisely this connection is described, the easier it is to determine later whether a new product feature is still covered by the existing mandate or requires a new decision.
The duration must align with the service provided and the deletion process. Processing may occur during the contract term, while backup copies persist for a limited period thereafter. This distinction should not be obscured by vague retention policies. Buyers need a realistic picture of when active data is removed, how long technical copies remain, and which legal obligations might prevent immediate deletion.
Instructions must be workable in practice.
Processors are required to process personal data based on documented instructions, unless a legal obligation dictates otherwise. With standard software, a significant portion of these instructions is already embedded in the main contract, the choice of product, and the settings. The data processing agreement should reflect this. A general clause regarding arbitrary individual instructions is of little use if there is no clarity on the point of contact or the technical framework for their implementation.
Clarify which changes constitute a new instruction. Activating an analytics function, selecting a new storage location, or extending retention periods can alter the processing. Some settings are controlled by the customer, others solely by the provider. Buyers should understand the available options and their consequences. A contract cannot compensate for the lack of-or misleading-product controls simply by granting abstract rights.
Under the General Data Protection Regulation (GDPR), the provider must notify the customer if they consider an instruction to be unlawful. The agreement should outline a practical procedure for such scenarios: who is to be notified, what happens pending clarification, and which processing activities can be suspended? Clear points of contact and escalation paths are more valuable than wording that merely reiterates the statutory principle.
Confidentiality and security must be commensurate with the risk
Individuals processing data on behalf of the provider must be bound by confidentiality obligations or subject to a corresponding statutory duty. For buyers, it is also important to understand how access is restricted in day-to-day operations. Does support staff have access to content by default, or is access granted only for a specific case? Roles, permissions, and logging mechanisms should align with the promised service.
Technical and organizational measures describe how processing is safeguarded. These may include access controls, encryption, backups, recovery procedures, and regular audits. A mere list of standard security terms reveals little about their actual implementation. Buyers should be able to identify which data is protected and when, who controls keys or access rights, and which measures specifically apply to the chosen product.
Security is not a static feature. Systems and risks evolve as providers adjust their infrastructure. The agreement should allow for meaningful improvements without inadvertently lowering the agreed level of protection. Customers require sufficient information regarding significant changes. What constitutes a "significant" change depends on the service but could involve, for instance, new storage locations, altered access methods, or the removal of a key protective measure.
Additional service providers must not remain invisible
Many providers do not deliver their services in isolation. They utilize data centers, email services, or support firms that may act as additional data processors. The data processing agreement should specify whether a specific or general authorization applies. In the case of a general authorization, customers must be informed of intended changes and given a genuine opportunity to object.
A list of additional processors is only useful if it remains comprehensible. Details regarding the name, task, and processing location help assess which part of the service the company handles. A mere collection of company names without functional descriptions obscures the data flow. Likewise, it should be clear where up-to-date information can be found and how customers are notified of new or replaced providers.
The primary provider remains responsible for imposing essentially the same data protection obligations on its additional processors. Buyers do not need to negotiate every sub-contract themselves but require sufficient assurance regarding the supply chain. The ability to object to a new provider must be more than merely theoretical; the contractual consequences, potential alternatives, and-where applicable-the right of termination must be clearly understood in the context of the main contract.
Support mechanisms must be accessible for handling data subject rights and incidents.
Individuals may exercise rights regarding their personal data. The controller remains responsible for handling these requests but often requires support from the service provider. The contract should outline how data can be located, rectified, exported, or deleted. In the case of self-service features, it is important to know whether they cover all relevant data or if additional requests to the provider are necessary.
In the event of a personal data breach, the processor must inform the controller without undue delay after becoming aware of it. For the buyer, the information received and the communication channel used are what matter. A support form that is difficult to locate can result in a loss of valuable time. Designated emergency contacts and ongoing updates help assess the impact, the data affected, and the measures taken.
Support may also be required for data protection impact assessments and inquiries from supervisory authorities. The scope and practical limitations depend on the service provided and the information available. Broad promises of assistance should therefore align with support terms and potential costs. Buyers need to be able to identify which forms of evidence are provided as standard and when a special investigation or expert input requires a separate agreement.
Deletion, return, and auditing require a realistic approach
Upon completion of the service, personal data must be deleted or returned at the controller's discretion, unless there is a legal obligation to retain it. This choice must be technically feasible. Buyers should know the format in which they will receive data, how long an export remains available, and when active systems are cleared. An unreadable export format renders a formal right of return practically worthless.
Backup copies often cannot be individually purged immediately. In such cases, limited retention, protection against normal use, and a transparent deletion routine are required. Wording regarding subsequent removal during the standard cycle should specify a clear timeframe. It should also be clear whether logs, support attachments, and test copies are subject to the same rules or are retained longer due to other obligations.
The provider must supply information demonstrating compliance with its obligations and facilitate audits. Widely used cloud services often employ independent reports, certificates, and standardized disclosures for this purpose. These can be meaningful provided the scope, timeframe, and relevant service match the requirements. A broader right to audit remains important but should take into account the security of other customers, confidentiality, and a proportionate process.
A data processing agreement (DPA) does not resolve international data transfers on its own
If data is processed outside the European Economic Area or made accessible from there, additional issues arise. A DPA under Article 28 does not automatically constitute the complete legal basis for this. Buyers should be aware of processing locations, potential remote access, and the companies involved. A statement of "EU hosting" is insufficient if support or administration can regularly be performed from a third country.
Depending on the country and the specific circumstances, an adequacy decision, Standard Contractual Clauses (SCCs), or other instruments may be relevant. Determining which legal basis applies and what additional measures are required must be done on a case-by-case basis for the specific transfer. The contract should not conflate different documents that have similar acronyms. A Data Processing Agreement (DPA) governs commissioned processing, whereas SCCs address other transfer-related issues depending on the context of use.
Changes must also be taken into account. The introduction of a new sub-processor or support location can alter a previous assessment. Consequently, customers require information before the new processing begins, as well as sufficient time to conduct a proper review. Legal advice is particularly valuable in cases involving complex transfer chains. While clear contractual details establish the factual basis, they do not replace the necessary legal assessment.
A good agreement can be explained in terms of the product itself.
Before signing, a knowledgeable person should be able to describe the data flow in simple terms. What data reaches the provider? What is it used for? Who has access to it, and when is it deleted? The answers provided across the product, the main contract, the DPA, and security documentation must be consistent. Inconsistencies should prompt further inquiries rather than leading to the assumption that a specific addendum will automatically resolve everything.
Involve data protection, information security, procurement, and the responsible business unit in a manner commensurate with the risk. Each perspective identifies different potential gaps-whether regarding legal roles, protective measures, contractual consequences, or unsuitable product functions. For a small, low-risk service, the review process can remain straightforward. Extensive or sensitive processing warrants a more in-depth analysis. The key is conducting an appropriate review, not applying the exact same volume of documentation to every provider.
While a clear DPA does not guarantee security on its own, it makes verifiable expectations transparent. It links the commissioned processing to instructions, protective measures, support, sub-processors, and the conclusion of service usage. If these statements accurately reflect the actual service, buyers can better assess responsibilities and identify changes at an earlier stage. Any outstanding legal questions should then be addressed through qualified professional advice rather than speculation regarding standard clauses.