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.
