Do I need to offer a data processing agreement I recently created a browser extension that allows you to pretty-format a web page and save it in various formats (Word, PDF, etc). I have made it publicly accessible through the browser extension gallery, so anyone can install and use it. The way this extension works is it uploads the content of the page you are viewing to my own server, the server processes it, and then lets you download the resulting file. This all works fine, but I recently started getting questions from users concerned about the fact that their data (possibly private and sensitive) gets uploaded to the internet. They were asking me to provide a GDPR-compliant data processing agreement, so they can install it on their company's computers. I do not have any kind of agreements, and in fact I do not even own a company at all. This browser extension, and the server that it uploads the data to is all my personal effort, and I never bothered to do any legal work around it. In this case, am I legally obliged to create a company and have any data processing agreements in place? (not sure if it matters, but I live in the UK, and I rent my server in the USA)
No, you're not required to sign any contracts. But since you're offering a service, you do have to manage some compliance tasks. You are a data controller under the UK GDPR, regardless of whether you have a company. This brings with it various compliance requirements. For example, you MUST post a privacy notice in accordance with Art 13 GDPR that explains how you process user's information. You must sign data processing agreements with your data processors, such as your server providers. And you should reconsider transfers of data to the US, since such transfers are illegal or at least quite questionable in the wake of the 2020 Schrems II ruling. You now have prospective users that are asking you for an Art 28 data processing agreement (DPA). These are likely other organizations that are data controllers of their own. For them to use your browser extension, they either need to find a legal basis that allows them to share their user's/employee's data with you (controller to controller transfer), or they need you to act as their data processor (controller to processor transfer). The third alternative is not to use your plugin at all. Of these, a C2P arrangement is most convenient for these other orgs, but involves a bit of paperwork to set up first. If you want to act as their processor, this doesn't mean you'd have to create a company (though a corporation might be very desirable as a liability shield). Being a processor means that you're contractually bound to only use the personal data as instructed by the controller, and not for your own purposes. This restricts what you can do, and has some special compliance requirements. For example, you cannot engage new subprocessors without your controller's approval. However, processor status can also be convenient for you because you're not responsible for interacting with the controller's data subjects, e.g. you're not responsible for handling their data subject access requests. Note that it's possible to simultaneously be a controller for some users, and a processor for others. E.g. Google Docs is offered directly to users as a B2C product so that Google is a controller, but also as a B2B product as Google Workspace, where Google acts as a data processor. Personally, I'd rather not sign any contracts unless I'm doing it as a business, and adequately compensated for providing this service. GDPR is only one compliance aspect out of many, making it unwise to offer a SaaS product as a hobby. For example, copying other people's web content has copyright implications… A potential alternative for some of the organizations asking you might be to make it possible for them to self-host your backend, so that they are not required to rely on you as a data processor. If you have no plans to commercialize your software, making it Open Source could be a solution. But you're in no way required to do that if you don't want to.
First of all, in a GDPR contest, the process described is not strong anonymization. It may be hard for an outsider to go from the stored record to any PII, it is much easier for an outsider to &quot;single out&quot; an individual. This means that given a known individual, one can determine whether that person is among those listed in the records, or can determine this to a significant degree of probability. For this only the algorithm and the rotating salts are needed, one need not break the hash. Note also that the GDPR specifies that if a person can be singled out with the assistance of the site operator the data is not considered anonymized. Thus this data needs a lawful basis under the GDPR, and the various other GDPR requirement all apply. However, even if the data were totally anonymized, and say just added to a count of users with this or that User Agent, the process of reading local data (including but not limited to cookies) itself requires informed consent, and so a cookie banner or other interaction with similar info under the e-Privacy directive (EPD). The EPD, being a directive and not a regulation, must be implemented by national laws, and the exact provisions in those laws may differ somewhat from country to country. But I believe that all of them require consent before any local data is read.
What would be the legal validity of this behaviour? Your changes to the browser source of the website contract or license of Terms of Service (TOS) - essentially a "click-wrap" license - before agreeing to it means nothing in a legal sense, other than to void the contract. The other party (the website) can't possibly agree to those contract changes without them being submitted as contractual changes and agreeing to them, if they did agree to them. That's basic contract law. That website TOS probably has a clause that says that if you don't agree to the TOS in full, as written, without modifications, you can't use the website. And the TOS may also say that they reserve the right to prevent you from using the site by closing your account or even blocking your access. Your "witness" to the contract changes is meaningless, as your witness is not a party to the contract. And any witness to the fact that you have changed the terms of the TOS before agreeing to it would work against you in a civil proceeding as proof of your attempt at modifying the contract.
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.
Term 1 isn't going to hold up, but that is not a GDPR matter. It's just a matter of basic consumer protection law in the EU. You can't offload responsibility for your mistakes. Looking at 2, Dale M. already pointer out that it's now how the GDPR works. You are the Data Controller. X,Y and Z are Data Processors. Article 28(1) of the GDPR is in direct conflict with your disclaimer. You accept zero responsibility, the GDPR says you are fully responsible. That's the exact opposite.
The GDPR only require explicit (hard) consent if you use the cookie to store personal data. Given the conditions you cite, the data you store is not personal data, so this cookie does not require consent. In theory, someone having access to both session cookie and "analytics cookie" could relate the two, but that is highly non-trivial. You may have to do DPIA to demonstrate that this is non-trivial, or that you have mitigation in place to mitigate staff abusing such access. But provided things are as you say, the "analytics" cookie does not require consent.
I'd rather not, but this might be compliant if you make sure that the personal data under your responsibility remains secure and protected even if it is processed abroad. Since the UK has left the EU, it is sometimes necessary to distinguish between implications of the EU GDPR and the UK GDPR. These are functionally equivalent, but in the matter of international data transfers the practical details have diverged. In my answer that you cited, I argued that any website processes personal data, and is thus potentially in-scope for the GDPR. If you cause another organization to process this personal data outside of the UK, you are performing an international data transfer (called “restricted transfer” in UK guidance). For example, such non-UK processing occurs if you use cloud services that run outside of the UK. The UK ICO has guidance on international data transfers. As in an EU GDPR context, you can only perform the transfer if the data remains suitably protected, or one of the exceptions applies. The data remains suitably protected if the target country was attested and “adequate” level of data protection, or if you have implemented appropriate safeguards. As of 2022, the list of countries considered adequate is generally equivalent to the EU list of adequacy decisions. Notably, the US is no longer on that list after the Schrems II decision that invalidated the Privacy Shield Agreement. Since this decision was made before Exit Day, it also applies in the UK. This leaves “appropriate safeguards” for UK→US restricted transfers. In the linked ICO page, read the section Is the restricted transfer covered by appropriate safeguards?. In brief, you will need to perform a Transfer Impact Assessment, and sign Standard Contractual Clauses with the US data importer. In a Transfer Impact Assessment (TIA), you check that the data remains protected despite the transfer into a country without an adequate level of data protection. There is no official guidance on conducting a TIA, but the IAPP has a template and the EU EDPB has recommendations on supplemental measures to protect data transfers, which might reduce the risk and affect a TIA in your favor. It's worth noting that the EDPB recommendations were written in the wake of the Schrems II ruling, and can be summarized as “compliance is impossible when using US-based cloud services”. But this is your assessment, and TBH it seems the UK is a bit more relaxed than the EU in this regard. The Standard Contractual Clauses (SCCs) are a pre-formulated contract that binds the foreign data importer to handle the data properly. In essence, this translates relevant aspects of the UK GDPR into contract law. Many service providers already provide a Data Processing Agreement that includes SCCs by reference, but you'll have to make sure that these contracts have been entered in a legally binding manner. Sometimes these apply automatically as part of the terms of service, sometimes you need to explicitly sign these documents. But SCCs are one detail where UK GDPR compliance and EU GDPR compliance diverges a bit. The old EU SCC templates from 2004/2010 can no longer be used and have been replaced. For compliance with the EU GDPR, the new 2021 SCCs must be used. For compliance with the UK GDPR, you have two options. You can either use the 2022 International Data Transfer Agreement (IDTA), or you can use the 2021 EU SCCs along with the 2022 UK International Data Transfer Addendum which modifies the EU SCCs in some details. Don't want to deal with TIAs and SCCs? Switch to a hosting provider that only processes the personal data under your control in the UK, or in a country with an adequacy decision (e.g. EU, Canada, Israel).
Not Allowed Under the GDPR The suggested method does not seem to comply with the GDPR, and would not be lawful for a Data Controller that is subject to the GDPR. Specific Provisions Let's consider some specific provisions of the GDPR: Article 4 Article 4 paragraph (11) states: &quot;consent&quot; of the data subject means any freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her; If the choice is &quot;obscure&quot; then it is not clear, and legal consent has not been given. Article 7 Article 7 paragraph 3 reads: The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent. It does not appear in the situation described that the data subject has been clearly informed that consent is being given. Recital 42 Recital 42 reads in relevant part: In accordance with Council Directive 93/13/EEC a declaration of consent pre-formulated by the controller should be provided in an intelligible and easily accessible form, using clear and plain language and it should not contain unfair terms. ... Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment. The specified means do not seem to comply with R42 Recital 32 Recital 32 reads: Consent should be given by a clear affirmative act establishing a freely given, specific, informed and unambiguous indication of the data subject’s agreement to the processing of personal data relating to him or her, such as by a written statement, including by electronic means, or an oral statement. This could include ticking a box when visiting an internet website, choosing technical settings for information society services or another statement or conduct which clearly indicates in this context the data subject’s acceptance of the proposed processing of his or her personal data. Silence, pre-ticked boxes or inactivity should not therefore constitute consent. ... If the data subject’s consent is to be given following a request by electronic means, the request must be clear, concise and not unnecessarily disruptive to the use of the service for which it is provided. The format in the question seems to rely on inactivity as a way of giving consent, and is surely not clear.