Article 28 GDPR
Legal Text
1. Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.
2. The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.
3. Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects and the obligations and rights of the controller. That contract or other legal act shall stipulate, in particular, that the processor:
- (a) processes the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the processor is subject; in such a case, the processor shall inform the controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest;
- (b) ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;
- (c) takes all measures required pursuant to Article 32;
- (d) respects the conditions referred to in paragraphs 2 and 4 for engaging another processor;
- (e) taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights laid down inCHAPTER III;
- (f) assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor;
- (g) at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies unless Union or Member State law requires storage of the personal data;
- (h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller.
With regard to point (h) of the first subparagraph, the processor shall immediately inform the controller if, in its opinion, an instruction infringes this Regulation or other Union or Member State data protection provisions.
4. Where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor as referred to in paragraph 3 shall be imposed on that other processor by way of a contract or other legal act under Union or Member State law, in particular providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that the processing will meet the requirements of this Regulation. Where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor's obligations.
5. Adherence of a processor to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate sufficient guarantees as referred to in paragraphs 1 and 4 of this Article.
6. Without prejudice to an individual contract between the controller and the processor, the contract or the other legal act referred to in paragraphs 3 and 4 of this Article may be based, in whole or in part, on standard contractual clauses referred to in paragraphs 7 and 8 of this Article, including when they are part of a certification granted to the controller or processor pursuant to Articles 42 and 43.
7. The Commission may lay down standard contractual clauses for the matters referred to in paragraph 3 and 4 of this Article and in accordance with the examination procedure referred to in Article 93(2).
8. A supervisory authority may adopt standard contractual clauses for the matters referred to in paragraph 3 and 4 of this Article and in accordance with the consistency mechanism referred to in Article 63.
9. The contract or the other legal act referred to in paragraphs 3 and 4 shall be in writing, including in electronic form.
10. Without prejudice to Articles 82, 83 and 84, if a processor infringes this Regulation by determining the purposes and means of processing, the processor shall be considered to be a controller in respect of that processing.
Relevant Recitals
You can help us fill this section!
Commentary
Is Data Processing Agreement a silver bullet under GDPR?
This article is about practice of use of Data Processing Agreements under GDPR over the past two years and about common mistakes data controllers usually make herein.
To be on the same page with the readers I suggest to consider, that data processing is a bilateral obligation, which consists of controller’s right to demand a performance of processing and of corresponding processor’s obligation to perform processing in accordance with controller’s instructions, which were preliminary accepted by the processor. In other words, processing is a controller’s offer, accepted by the processor.
i. When is access a processing?
An interesting fact: “access to data” was not listed in Article 4 (2) of GDPR as a processing activity. Precisely speaking: “provision of access” is a processing activity, because this is a “disclosure by transmission, dissemination or otherwise making available”, but getting access is not necessarily “an operation performed on data”.
Actually, access to data may be obtained unintentionally or even against the will of the data recipient. It means, when someone provides access to personal data – it processes personal data by performing an active action: operation on personal data by making this data available to third parties. Whereas, when someone gets access to personal data – it is not always a performance of an operation on personal data, not always an action or even a voluntary action of data recipient.
Getting access to data is always a consequence of data controller’s behavior: action (e.g. provision of authorized access) or inaction (lack of security, negligence, etc.).
In software development while coding, we usually deal with unintentional and accidental access to controller’s data, which might happen someday or might never happen. We often don’t (?) know when exactly the software developer will have access to controller’s data, which means, that access here is not a contractual obligation or processor’s will, but an independent event.
Software itself is a PLACE to store and process data. Likewise a bag, an envelope, a folder, a box or a safe. It is usually empty while produced, until it is filled with content. So creation of paper box is not similar to analysis of documents inside of this box. Creation doesn’t require access to the content. And for modification of the box, you usually take everything out before fixing the container, don’t you?
So why should actions be different in a digital world if they have the same meaning and legal nature as similar actions in material world? If some service or work doesn’t require particular personal data inside— don’t provide access to it. Take data out or anonymise it. This is critically important for data subjects.
ii. Example of popular non-processing
Let’s take a closer look at phases of software development to deepen our understanding and identify the reason of common misunderstanding of the role of personal data processing in software development.
There are six phases in software development: 1) requirements gathering and analysis, 2) design, 3) implementation or coding, 4) testing, 5) deployment, 6) maintenance. The first three stages are not related to access or processing of controller’s personal data. This is a creation of an empty box. Testing might sometimes require some personal data, but it could be anonymized or pseudonymized – test data. The deployment, maintenance, support and further modifications are usually conducted when the product is deployed in the controller’s production environment. This means, that developer’s team shall have access to controller’s team production environment to perform the services. However, it is a very rare case when a developer needs controller’s data to perform their services: e.g. when a developer needs to contact data subjects for direct support or processing of user’s requests or for other related to communications with data subjects.
In all other cases, developer does not care about data subjects’ identity. So personal data in the controller’s production environment could and must be anonymized or pseudonymized in 90% of cases, because developers do not need this data for service provision.
If so, what is the motivation of data controllers to enter into Data Processing Agreement with as much vendors as possible? Usually the explanation comes down to the following argument: “vendor may access to our production environment, which may entail someprocessing of controller’s personal data”.
The key words here are: “may” access and “some” processing. Does “may process” sound like data processing instruction? Is this processing obligatory for the vendor? Does controller have the right to oblige their vendor to access the controller’s data? It seems, that the answer is “no”. If the vendor “may” access the data, but is not obliged to do it, this means that the moment of access depends on the vendor solely and the controller does not control the data or its processing. This case demonstrates, how controller discloses personal data to a party, which is not even a data processor.
“Some” processing also does not seem like data processing instruction, which is an obligation by its legal nature. And an obligation should have a definite subject matter. It could not be something vague, random or at vendor’s discretion. And the controller loses the control on data again in this case.
Such “potential access” arises as a side effect of the provision of services in controller’s unprotected environment. But it is not a service of processing itself.
Also the difference between actual processing and potential processing is in the final result of data processing: actual processing influences the data somehow and has an effect expected by the parties, while potential processing has zero influence as it does not exist.
iii. Let’s brainstorm the case
By ensuring the proper level of security, controller may avoid any unnecessary disclosure of data via “potential access” and exclude the related confusion between an actual processing of data (result of legal obligation) and unreasonable disclosure (result of controller’s negligence).
When granting access to software developers, the controller usually does not expect or require any particular processing from the vendor, on the contrary, they seek to limit the risks of data alteration or leakage by long lists of prohibitions and security requirements. Therefore, the controller does not actually need the processing services, which it imposes on the vendor, but is trying to protect themselves from the risks.
Does this approach really protect from risks so well, or vice versa - increases them?
After all, the GDPR does not impose any responsibility on the recipient, but imposes responsibility on the processor. But what if software developer is not a processor?
It means that getting access from data controller does not necessarily entail a processor’s status on recipient’s side and hence does not turn this recipient into a data processor. What is more interesting— an accidental access to personal data is considered as data breach according to Article 4 (12) of GDPR.
The ICO provides a very representative example in its Guide to GDPR Controllers and processors: a mail delivery service is contracted by a local hospital to deliver envelopes containing patients’ medical records to other health service institutions.
The delivery service is in physical possession of the envelopes but may not open them to access any of the personal data or other content they contain. The delivery service will not process the personal data in the envelopes and packages it handles. It is in possession of the envelopes and packages but, as it cannot access their content, it cannot be said to be processing (it is not even ‘holding’) the personal data they contain. Indeed, the delivery service will have no idea as to whether the items they deliver contain personal data or simply other information. This means that, regarding the content of the envelopes and packages it delivers, the delivery service is neither a controller in its own right nor a processor for the clients that use its services, because:
- it does not exercise any control over the purpose for which the personal data enclosed in the items of mail entrusted to it is used;
- it has no control over the content of the personal data entrusted to it;
- it has no instructions from controller to process personal data inside envelopes and packages.
However, the delivery service will be a controller of the name & address information on the items to be delivered.
The question is: what if this hospital will provide the delivery company with open envelopes, but enter into DPA with the provider to protect the disclosed data? Will this DPA be a sufficient measure of protection patient’s medical records? Obviously no.
Then why data controllers simply disclose personal data to software developers instead of “closing the envelopes”? Why they are forcing their suppliers to have access to confidential data instead of keeping it closed and secure?
Is there a clear purpose and legal basis for such data processing as “potential disclosure to suppliers”, communicated t in privacy notice to all data subjects? If not — it is against the spirit and letter of GDPR: when data controller discloses personal data without informing data subjects in comprehensive way about it, to enable them to make rational decision about secondary use or disclosure of their data in controller’s interest – this controller denies individual’s right to control dissemination of its personal data. Such disclosure of individual’s data will not be GDPR compliant.
iv. Is there a legitimate interest for disclosure to all vendors?
Data subject trusts the controller and expects that controller takes rational decisions about disclosure of the data, not some spontaneous ones, and that each of these decisions is weighted and individuals’ data is properly protected.
DPA doesn’t address these expectations when data is shared without a real need or purpose, instead of being anonymized, blurred or hidden. If data subject has even provided a consent for data sharing with an open list of third parties, this sharing should always be limited by the principle of purpose limitation and principle of confidentiality.
Imagine you are trying to apply a legitimate interest as legal basis for disclosure of personal data during software development or modification of system. How will you explain the necessity for keeping personal data open and freely accessible during these services? Let’s try to conduct a legitimate interest assessment test (three-part test) for this case:
1) purpose test: the interest of data controller to develop and modify software is real and present, it corresponds with current activities or benefits that are expected in the very near future—true;
2) necessity test: the disclosure of personal data to supplier is necessary for development and modification of software, such disclosure is less intrusive for the rights of individuals compared to other options for achieving the same goal —false. This means that any data item that is not necessary to disclose for development and modification of software is processed unlawfully;
3) balancing test: there is a balance between controller’s purpose on one hand, and the impact on the rights of the data subjects on the other hand: organization's interests override an individual’s —false. Together with the balancing exercise we also should take into account the reasonable expectations of data subjects.
I suggest to data controllers even an easier one-step LIA: if hiding of personal data from your vendor will not anyhow affect the services, than disclosure of data is unnecessary and hence – unlawful.
Imagine a data breach happened on supplier’s side when an initial disclosure by controller was unlawful: is there a chance that Data Protection Authority will ignore this aggravating circumstance?
v. When is Data Processing Agreement a risk for data controller?
Classic examples of DPA being inapplicable or not necessary:
- For processing of contact details of teams, sales, signatures and other administrative data both parties usually exchange to enter, perform, control and close the contract (actually, both parties are data controllers here and DPA is inapplicable). A mutual data disclosure/sharing agreement might be an additional option here.
- When instead of processing activities, the controller specifies the “services and works under Master service agreement” (actually, DPA should specify the processing activities, e.g. those, which are listed in Article 4 of GDPR as types of “processing”).
- When the only subject of DPA is obligation to have access to controller’s personal data (access should always be for some purpose, legal basis and should be inextricably linked to specific actions that the processor must perform in addition to access).
So DPA is a controller’s solution to mitigate risks of data breach on vendor’s side, kind of “legal security measure”. Does this measure protect controller’s data properly? This is a good question, the answer to which depends on legal nature and wording of DPA.
Of course, sometimes at some stages of software development, the developer might process personal data in a processor’s role, e.g. autonomous driving development (when video is processed); maintenance, support and modification of systems in production. But this is far from 100% of all services IT companies usually provide.
At the first glance DPA looks like an excellent measure of data protection. But, in fact, it often does not contain a subject matter and is often fictitious , since it does not have a particular processing obligations that would actually be fulfilled by the vendor.
Once the data processing agreement is fictitious – it might easily be contested in court by either party. After all, any vendor-not-actual-processor is a potential source of a risk. Having contested the DPA in court or by Data Protection Authority, such vendor will leave the controller’s disclosure without any legal basis and moreover, will show that DPA as a “legal security measure” was nominal and ineffective.
No matter that disclosure in our case above was regulated by signed DPA, since this agreement has no subject, it may be declared as invalid by court. It means that vendors have no liability under this DPA and no obligations to perform it – from the date of signing.
In addition, considering that in civil law the DPA is classified as a real contract (not consensual), the rights and obligations of which begin from the moment of the actual providing of data for processing — the suppliers cannot apply security measures until personal data and documented instructions are actually received. And, while the moment of potential access and start of processing is not clear and may be determined solely by the vendor (as discussed above) — the controller may miss the moment of providing instructions, which leads to a complete lack of security for this period.
The assumption that DPA is a real contract is most likely correct also because it is impossible for the vendor to start processing or protect the data it doesn’t actually process, but theoretically may access someday. If the vendor doesn’t perform the processing activities, they are not able to implement security measures to nothing.
We can also assume that DPA might be a deal under a suspensive condition. Then there is a problem: who should control the moment of the start of actual processing? How do parties become aware, that processing has started? We know that usually the DPO is not involved in production and development itself. Nobody informs their and counterparty’s DPOs about the start of data processing. It might just happen or not happen ever for years. Only data controller should decide when it is ready to disclose the data to a recipient, and this is what data subjects expect.
vi. Conclusions
A. Do not enter into DPAs with each vendor without necessity. Controllers may continue to rely on Non-disclosure agreements, amended with all kinds of obligations and security measures they need.
B. Remember, that receiving access is not always a processing. Ensure that each DPA covers real processing activities not the potential or imaginary ones. Otherwise you increase your workload exponentially.
C. Controllers shall take maximum security measures to avoid provision of access without legal basis (Article 6 of GDPR) and especially without necessity (when vendor's contractual obligations could be performed without data processing). Hash, blurr, anonymise, exclude, hide, limit access rights, etc.
D. The market needs an official position and clarifications from Data Protection Authorities about the risks of formal entering into “empty” DPAs.
E. The privacy community should elaborate on compliant templates of documented instructions; should answer some questions, such as: who is entitled to issue/accept documented instructions on behalf of the parties; are there necessary terms and conditions to be specified: frequency of processing, term of processing, necessity if processing; has the processor the right to object against instructions, negotiate, decline, withdraw them? It is also desirable to clarify the place of “consent”, “privacy policy” and “controller’s instructions”— in the theory of law: what are they: offer/accept, unilateral deals, singular rights, something else?
First published here: https://www.cpomagazine.com/data-protection/is-data-processing-agreement-a-silver-bullet-under-gdpr/
Decisions
→ You can find all related decisions in Category:Article 28 GDPR
