Businessman signing document showing the practice of using data processing agreement under GDPR
Is Data Processing Agreement a Silver Bullet Under GDPR? by Kate Bronstein, Global Data Protection Officer

Is Data Processing Agreement a Silver Bullet Under GDPR?

This article is about the practice of using 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.

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 the 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 a 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 the material world? If some service or work doesn’t require any particular personal data inside – don’t provide access to it. Take the data out or anonymize it. This is critically important for data subjects.

Example of popular non-processing

Let’s take a closer look at phases of software development to deepen our understanding and identify the reason for 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 the 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 the 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 work related to communications with data subjects.

In all other cases, developers do 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 for 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 have access to our production environment, which may entail some processing of controller’s personal data”.

The key words here are: “may” access and “some” processing. Does “may process” sound like a 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 a controller discloses personal data to a party, which is not even a data processor.

“Some” processing also does not seem like a 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.

Let’s brainstorm the case

By ensuring the proper level of security, the 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 the software developer is not a processor?

It means that getting access from data controller does not necessarily entail a processor’s status on the 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 a 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 provides the delivery company with open envelopes, but enter into a DPA with the provider to protect the disclosed data? Will this DPA be a sufficient measure of protecting patient’s medical records? Obviously no.

Then why do 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 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 the controller’s interest – this controller denies individual’s right to control dissemination of its personal data. Such disclosure of the individual’s data will not be GDPR compliant.

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 (Legitimate Interests Assessment): if hiding of personal data from your vendor will not somehow affect the services, then disclosure of data is unnecessary and hence – unlawful.

Imagine if a data breach happened on the supplier’s side when an initial disclosure by controller was unlawful: is there a chance that the Data Protection Authority will ignore this aggravating circumstance?

When is Data Processing Agreement a risk for data controller?

Classic examples of DPA being inapplicable or not necessary:

  1. 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.
  2. When instead of processing activities, the controller specifies the “services and works under a 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”).
  3. When the only subject of DPA is an 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 a 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 obligation 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 the 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 provision 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 protecting 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 the data controller should decide when it is ready to disclose the data to a recipient, and this is what data subjects expect.

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, blur, anonymize, exclude, hide, limit access rights, etc.

D.             The market needs an official position and clarifications from Data Protection Authorities about the risks of formally entering into “empty” DPAs.

E.             The privacy community should elaborate on compliant templates of documented instructions; and 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 of 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?