When is a supplier a processor?
A processor handles personal data on behalf of a controller. The controller determines the purposes and essential means, while the processor performs data operations as part of its service. Typical examples may include hosting a customer database, operating an HR platform, distributing a newsletter, external archiving or processing payroll.
Not every service provider that encounters data is a processor. Purely incidental access may require confidentiality and security safeguards without creating an Article 28 processing relationship. Conversely, a supplier that independently determines why data are used and controls essential features of the process may be a controller even if the contract calls it a processor.
For example, an outsourced data protection officer does not automatically become a processor merely because the adviser reviews documentation. The Polish supervisory authority has indicated that an external DPO’s statutory function should be based on a services agreement rather than, as a rule, an Article 28 DPA for the DPO function itself.
Processor, separate controller or joint controller?
Where each party independently determines its own processing purposes, both may be separate controllers. This often occurs when a professional supplier has its own statutory or professional duties and does not act solely under the customer’s instructions.
Joint controllers determine purposes and means together. They require an Article 26 arrangement transparently allocating responsibilities, particularly for data-subject rights and privacy information. Using a DPA for what is actually joint controllership may conceal the issue rather than solve it.
The relationship can be mixed. A SaaS provider may process end-user data for the customer while acting as a separate controller for customer representative details, billing records or security information retained for its own legal obligations. The contract should separate those roles and datasets.
What must an Article 28 agreement contain?
The contract or other binding instrument must be in writing, including electronic form. It must describe the subject matter and duration of processing, its nature and purpose, the types of personal data, categories of data subjects and the controller’s rights and obligations.
The processor must act only on documented instructions unless Union or Member State law requires otherwise. It must bind authorised personnel to confidentiality, implement Article 32 security measures, comply with subprocessor rules and assist the controller with data-subject requests, security, breaches and, where applicable, data protection impact assessments.
At the end of the service, the processor must, at the controller’s choice, delete or return personal data and delete existing copies unless applicable law requires retention. It must also provide information needed to demonstrate compliance and allow audits, including inspections, under workable arrangements.
How should subprocessors be addressed?
A processor may not engage another processor without the controller’s prior specific or general written authorisation. Under a general authorisation, it must inform the controller of intended changes so that the controller has an opportunity to object.
The DPA should set out how the subprocessor list is updated, the notice period, information about the new entity and the consequences of a justified objection. Merely changing a web page without effectively notifying the customer may not provide a meaningful ability to respond.
The subprocessor must be subject to substantially the same data-protection obligations. The initial processor remains liable to the controller for the subprocessor’s performance. In cloud supply chains, the review should cover not only names but also service scope, processing locations and the transfer mechanism for any data leaving the EEA.
How should a controller assess the processor before appointment?
A controller may appoint only processors providing sufficient guarantees of appropriate technical and organisational measures. The review should be proportionate to risk and the nature of the service. A simple event-registration tool may justify a lighter assessment than a provider handling medical data or a complete workforce database.
Evidence may cover architecture, access management, encryption, backups, security testing, incident response, certifications, audit reports, retention, processing locations and material breach history. A certification can support the assessment but does not automatically discharge the controller’s responsibility.
In its decision concerning McDonald’s Polska, the Polish data protection authority stressed that a long relationship and references did not amount to an adequate assessment of the processor’s guarantees. The practical lesson is broader: supplier selection should leave a record of the information reviewed, risks accepted and safeguards agreed.
How should incidents and cooperation be organised?
The processor must notify the controller of a personal data breach without undue delay after becoming aware of it. The GDPR does not give the processor a separate 72-hour period. That deadline applies to a controller’s notification to the supervisory authority, so the contractual processor deadline should leave enough time for assessment and a reporting decision.
The DPA should specify an emergency channel, the minimum content of an initial alert, rolling updates, preservation of evidence, cooperation on risk assessment and communications, and reasonable cost rules. Requiring a complete forensic report within a few hours may be unrealistic. Early notification followed by staged updates is often more effective.
For the controller’s response plan, see Personal data breach in Poland: what should a business do within the first 72 hours?.
Is a standard DPA template sufficient?
A template is a starting point, not proof of compliance. The processing annex should reflect the actual service. Wording such as “all data required to perform the agreement” makes it difficult to assess scope, risk, retention and security.
The DPA should also be consistent with the main commercial contract. In a technology service, the connected allocation of service levels, security and liability is discussed in SaaS agreements with business customers under Polish law. A wider review of processors, records and actual data flows may form part of a GDPR audit for a small or medium-sized business in Poland.
Commission Implementing Decision (EU) 2021/915 provides standard contractual clauses between controllers and processors that can satisfy Article 28(3) and (4). They should not be confused with Decision (EU) 2021/914 on transfers to third countries. If personal data leave the EEA, the parties must separately establish an appropriate transfer mechanism and assess it where required.
How the issue appears in practice
Practical example — hypothetical scenario
A Polish company implements an HR platform for recruitment and employee records. The vendor supplies a one-page DPA stating only that it “processes data in accordance with GDPR”. A subprocessor list is available at a changeable web address, and the vendor may update it without notice. The agreement does not set an incident-notification process or explain how backups are deleted after termination. Several months later, the vendor adds a US analytics service and uses selected data to develop its own benchmarking feature. Unauthorised access occurs, but the customer is informed four days later. The company cannot quickly determine the data categories, number of individuals or location of copies. The problem is not merely a lack of detailed clauses. Roles were not separated and supplier oversight was absent. The contract should distinguish processing on customer instructions from the vendor’s independent purposes, describe data and operations, identify authorised subprocessors, govern changes, require appropriate security and rapid incident notice, and address return and deletion including backups. Before signature, the company should document its review of supplier guarantees and the transfer mechanism.
Matters to determine or verify before proceeding
- Who actually determines the purposes and essential means in each processing activity?
- Which data operations are necessary for the service and which support the vendor’s own purposes?
- Which categories of individuals and data, including special-category data, are involved?
- How have the processor’s security and compliance guarantees been assessed?
- Which subprocessors are approved, and how will the controller learn about changes?
- Where are data stored, and are there transfers outside the EEA?
- How quickly must the processor report an incident, and what must the first notice contain?
- How will data, logs and backups be returned or deleted at the end of the relationship?
Key issues at a glance
| Issue | Key information |
|---|---|
| Processor | Processes personal data on behalf of the controller and generally under documented instructions. |
| Separate controller | Determines its own purposes and essential means; a DPA does not replace the controller’s lawful basis and obligations. |
| Joint controller | Jointly determines purposes and means; an Article 26 arrangement is required. |
| Subprocessor | Requires specific or general written authorisation and equivalent data-protection obligations. |
| Incident | The processor notifies without undue delay; the contract should allow the controller to meet its 72-hour deadline where notification is required. |
| Transfer outside the EEA | An Article 28 DPA is not by itself a lawful third-country transfer mechanism. |
| End of service | The controller generally chooses return or deletion; continued retention requires a legal basis. |
Legal basis
- Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (GDPR), in particular Articles 4(7) and 4(8), 26, 28, 29, 32–36, 44–49, 82 and 83.
- Commission Implementing Decision (EU) 2021/915 of 4 June 2021 on standard contractual clauses between controllers and processors under Article 28(7) GDPR and Article 29(7) of Regulation (EU) 2018/1725.
This article provides general information and does not constitute legal advice for a specific matter. The appropriate solution depends on the facts, documents and business objective.
Summary
A useful DPA starts with the correct role allocation, not with a template. It should describe the real service, give the controller workable control over subprocessors and changes, and support security, data-subject rights and a clean exit. I can classify the parties’ roles, draft or review an Article 28 agreement, assess a supplier and design a processor-management process for a business operating in Poland.