21

I am providing a B2B service where customer data of businesses are stored in an SQL table. As I never need to query for this personal data, the data at rest there is asymmetrically encrypted with the associated businesses public key.

Since the information is encrypted, I cannot query for any personal customer data.

Example of the customer table:

------------------------------------------------------------
| business | firstname     | lastname      | private-data  |
------------------------------------------------------------
| 12345    | xXencryptedxX | xXencryptedxX | xXencryptedxX |
------------------------------------------------------------
| 12345    | xXencryptedxX | xXencryptedxX | xXencryptedxX |
------------------------------------------------------------
| 12345    | xXencryptedxX | xXencryptedxX | xXencryptedxX |
------------------------------------------------------------
| 12345    | xXencryptedxX | xXencryptedxX | xXencryptedxX |
------------------------------------------------------------

For a GDPR information request I would need to fetch every single entry (tens of millions), associate the private key of the linked business, decrypt every single entry and do a string comparison search for every entry.

Given the enormously high cost of processing the data, am I obligated to do so as per a GDPR information request or could I argue that this would be a disproportionate effort as per Article 14?

After all, I am demonstrating my willingness to ensure high effort security by voluntarily only storing it encrypted.

18
  • 3
    Very smart, but person X could be Customer of many different companies resulting in me needing to encrypt the data with lots of different keys. – dmuensterer Oct 6 '20 at 11:26
  • 14
    shouldn't the company be the data controller and you just handle the processing for them? You have no other relation with the customer. – Trish Oct 6 '20 at 11:55
  • 3
    @DaleM, good point. Thinking hard about it, it could still break. The steps in public-key crypto usually are: 1) generate a random single-use two-way key, 2) encrypt the message using the single-use key, 3) encrypt the single-use key using the public key, and 4) store the encrypted single-use key along with the encrypted message. The private key is used to decrypt the single-use key. So repeated encryptions of the same clear text give completely different results. This "same input, different output" happens a lot in crypto, and it's absolutely on purpose. – Jason Oct 6 '20 at 23:24
  • 4
    This is straying pretty far from the legal arguments; the point is that @dmuensterer is correct that the computational costs of searching this database are huge. – Jason Oct 6 '20 at 23:26
  • 4
    A suggestion for anyone reading this and wondering about the technical aspects of searchable encryption (in general and this specific case): I recommend you don't discuss this here but instead post a question on the appropriate network site: Cryptography. – SEJPM Oct 7 '20 at 13:19
33

It is the data controller's responsibility to respond to data subject requests. If you provide a B2B service, you are most likely a data processor who only acts on the controller's behalf, on the controller's explicit instruction. This will depend on your contract with the controllers, your customers (see Art 28).

Typically a processor would merely forward any data subject requests to the controller. Only if you are contractually obligated to serve data subject requests would it be possible for you to respond directly. If a processor were to fulfil a data subject request on their own initiative, that would arguably be a GDPR violation. However, the processor has to assist their controller with compliance per Art 28(3)(e), e.g. by implementing an admin interface through which the controller can service GDPR requests.

The core issue here is that controllers and processors have slightly different obligations in order to be GDPR compliant. Controllers owe compliance to the data subjects, but processors only act on the controller's behalf and owe compliance to their controllers – they have no direct relationship with data subjects.


Assuming you were a controller, then yes, I would assume you would have to decrypt any data that you are able to decrypt in order to fulfil a data subject request. Access requests can only be denied if:

  • Art 12(5): they are “manifestly unfounded or excessive” (which the controller has to demonstrate), or
  • Art 15(4): the access would “adversely affect the rights and freedoms of others”.
  • Art 11(2): the controller can demonstrate that they are actually unable to identify the data subject so no data subject rights in Art 15–20 apply.

A request is not automatically excessive just because it will require substantial CPU time, this exception is more often triggered when data subjects request the same data very frequently (e.g. every week). You are not required to provide or search data that you don't have access to (e.g. E2E encrypted data).

Your use of per-field encryption is a very strong security measure (depending on how keys are managed). But GDPR is not about achieving maximum technical data protection, but merely requires appropriate safety measures (see GDPR Chapter 4, especially Art 32). Asymmetric encryption of small fields within a database is unlikely to be appropriate, taking into account the cost of processing and the data subject's ability to exercise their rights. A different security measure to ensure that every business only sees the correct data would be through testing and code review of your SQL queries, and full disk encryption of the server storing the database. In practice, asymmetric encryption is most often just used to encrypt a symmetric key, which is then used for the actual data. But which measures are appropriate also depends on the risk to data subjects – your approach could make sense for very sensitive data.

Art 14 does not play a role here. It is about transparency of processing: that you need to (a) notify the data subject that you're processing their data, if feasible, and that you (b) provide information about this processing, usually in form of a privacy policy. Art 14 is the pendant to Art 13, which applies when data is obtained directly from the data subject. The Art 15 right to access and the Art 20 right to data portability are distinct from the right to be informed. In any case, it is the controller's responsibility to fulfil these rights.

6
  • 3
    I think the key point here is that the GDPR request goes to the controller, who might need to involve the OP in decrypting just the data associated with their business. The OP wouldn't need to decrypt everything, looking for other business's data regarding the same user. – Barmar Oct 7 '20 at 17:50
  • 3
    Indeed. The fact that my company could only act as the processor is what I missed and an enormous relief. For my businesses customers, I will just provide a list of their (private) customers while it's their responsibility to respond to GDPR requests. Thank you. – dmuensterer Oct 8 '20 at 8:34
  • @dmuensterer It's worth pointing out that exactly what obligations a processor vs. controller has is also dependent on the local implementation of GDPR in national law. In the Czech republic for example some requirements that per GDPR could be thought of as Controller only also apply to the processor. – DRF Oct 8 '20 at 18:35
  • 1
    @DRF Actually, as far as my understanding of regulations vs directives goes, there is no necessary implementation of a regulation in state law necessary as it has automatically legal binding force in all member states whereas directives need to be implemented by each member state. Regulations can be complemented by state/country law though. – dmuensterer Oct 8 '20 at 18:42
  • @dmuensterer Yes. Sorry I wrote that in a misleading manner. A state/country law can adapt/complement the GDPR. Not even making it strictly stronger though. In my country for example the national law capped fines for governmental entities (very low too). – DRF Oct 8 '20 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.