Category: GDPR

Categories
GDPR Privacy Regulation

GDPR Article 35 and Article 25 Square Off

For those not buried in the details of the European General Data Protection Regulation (GDPR), there is often confusion about be the differences between Data Protection Impact Assessments (Article 35) and Data Protection by Design and Default (Article 25). Many people assume that DPIAs, as the impact assessments are called, are synonymous with with Data Protection by Design and Default. This article we highlight some of the key differences.

Article 35 Data Protection Impact Assessments

  • Applies to: processing of personal data that likely poses a high risk to individuals, especially where there is automated processing, processing large scale special categories of information or systematic monitoring of public spaces
  • Requires: documentation of the measures to address the risk and demonstrate compliance with the regulation
  • When: prior to processing

Article 25 Data Protection by Design and Default

  • Applies to: all processing of personal data
  • Requires: implementing appropriate technical and organizational measures designed to implement data protection principles and only process the personal data necessary for the specific purposes
  • When: at the time of determination of the means of processing AND at the time of processing

I’ve obviously summarized the language of the articles but only to highlight the differences. So let me dive a little further. First off, you’ll notice the first key distinction on the applicability. DPIAs are only necessary for high risk processing, whereas Data Protection by Design (and default) applies to ALL processing of personal data. Of course, to get to a DPIA, most organizations rely on some threshold analysis which would suggest whether or not the processing is high risk. This is not necessary for Data Protection by Design because it applies to all processing.

The second key distinction is that DPIAs are about documenting your measures and compliance whereas Data Protection by Design is about implementing measures. Article 35 DPIA is about proving you’re complying whereas Article 25 Data Protection by Design and Default is about trying to comply (i.e. the measures are “designed” to implement data protection principles). Presumably, if you’ve designed data protection into your processing, the DPIA is about ensuring that you’ve formally documented it (with all your i’s dotted and t’s crossed). An example might help. If you’re planning on collecting contact information of potential customers at a concert, you might implement an organizational measure (a policy) that tells your employees to ensure they tell potential customers what their data will be used for. That is a measure designed to comply with the data protection principle of transparency. Will some of your people forget to tell them? Perhaps. Perfection is not the goal. Change this up to you’re planning on video recording individuals at the concert and doing demographic analysis on ethnicities in attendance. Now you fall under the systematic monitoring clause of Article 35 (and special categories clause as well). You have to document how you’re complying with the regulation, including all the technical and organizational measures. Maybe only three employees have access to the data. Maybe you’re doing this under the lawful basis of being carried out in the public interest. Maybe you had notice printed on the back of the ticket before everyone entered. Document. Document. Document is what DPIAs are all about.

The final key distinction is about timing. For DPIAs, you need to do that anytime prior to processing. The idea here is if you don’t have the documentation or can’t prove your complying with the regulation, that would stop you from processing the personal data at high risk to the individuals (or at least give you pause). Because, Data Protection by Design is about implementing measures rather than documenting those measures, it must be done (1) when you determine what processing you’re going to do and (2) at the time of processing. The reason for this is because the measure may have different effects at different times. For instance, one measure (in accordance with the data minimization principle) might be to exclude collection of certain information, say ethnicity, when asking for contact information. This might be implemented on the form being used to collect data by not having an ethnicity field. Since we create the form at the “time of determination of the means of processing” we’re implementing that measure at that time. Another measure might be to audit the forms to make sure employees aren’t secreting marking codes next to minority names and contact information. That measure would obviously be at the “time of the processing itself.”

Categories
GDPR Privacy Regulation

Lawful Basis under GDPR: Performance of a Contract

The newly enacted General Data Protection Regulation (GDPR) in the European Union provides for six lawful bases for processing data. Just as a baseline for readers who may not be familiar with the GDPR, in general processing is prohibited unless you have a lawful basis.  Article 6 of the regulation provides for the list of bases:

  1. Consent
  2. Necessary for performance of a contract
  3. Necessary for compliance with the law
  4. Necessary to protect vital interest of the data subject
  5. Necessary for task carried out in the public interest
  6. Necessary for a legitimate interest of the controller or third party

The most common justification by organizations is probably (6) legitimate interest. The easiest example of this would be fraud prevention. An organization has a legitimate interest in preventing fraud from occurring. Of course, the balancing test for legitimate interest must still be carried out. You can’t justify doing just anything you want on the basis of fraud prevention.

The basis which garners the most press and most debate is consent. In fact, the regulation devotes an entire article to what constitute valid consent. The Working Party 29, the official EU advisory group on data protection , also published a 30 page guide to consent. Consent is essentially a last resort for organizations wanting to use data. If you can’t find a valid basis under the other five, consent is your only option.

Bases 3, 4 and 5 are fairly narrow and of limited general purpose use, only available in certain circumstances.

Which leaves us #2 performance of a contract, the subject of this post. In full, the text of the regulation on this reads: “processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract.”

Unfortunately, many are read this option too broadly as, simply, part of a “contract.”  In other words, their feeling is that, anything put into the contract, makes this a valid basis for processing. But let’s look a little closer.

“processing is necessary for the performance of a contract to which the data subject is party”

First off, it’s clear the data subject must be a party to a contract. It can’t be a contract between two organizations concerning the data subject (or their information).  What about the other part of that sentence “necessary for the performance of a contract?” While performance is not defined under the Principles of European Contract Law (PECL), non-performance is in Art 1:301:

“`non-performance‘ denotes any failure to perform an obligation under the contract, whether or not excused, and includes delayed performance, defective performance and failure to co-operate in order to give full effect to the contract.”

Article 7 of PECL goes on to describe, in more detail, issues of performance. One can deduce from the counter definition that performance means completion of an obligation under the contract (in a timely, non-defective and cooperative way).  Article 6:101 describes that a statement in a contract gives rise to an obligation to a party, if the other party reasonably expected it to give rise to that obligation, taking into account (a) the apparent importance of the statement to the other party; (b) whether the party was making the statement in the course of business; and (c) the relative expertise of the parties. Clause (a) is crucial in the analysis for the lawful basis of performance of a contract under GDPR.

In order for “performance of a contract” to be the lawful basis, the processing of data must be necessary to fulfill an obligation, under the contract, of the controller which is important to the data subject.

Let’s look at a clear example: I hire you to design and print business cards for me. Without my name and contact information, it would be impossible for you to fulfill your obligation under the contract. I’ve set you up for failure and arguably non-performed my obligations for failure to co-operate if you’re not allowed to use that information. Processing of that data is necessary for your performance.

Let’s look at one more common one, payment processing. You hire my consulting firm to provide privacy by design training and the firm expects payment for that service. In receiving that payment, I’m in receipt of your personal information, which may be supplied to a payment processor, used to create an invoice, etc. From the contracts perspective, the obligations are that you pay the firm and that the firm provides training services.  Processing payment is for the firm’s benefit (aka in their legitimate interest in facilitating payment) not to fulfill an obligation to you.

The bottom line is, just because there is a contract, doesn’t mean the lawfulness of processing is based on performance of that contract. It has to support and be necessary to perform your obligations under the contract.