Does GDPR apply if my web app stores personal data on the user&#39;s phone only?
<p>My web app stores personal data about the user, but on the user's phone only (HTML5 Local Storage). The data is <em>never</em> touched by any server or database. I can't see the data. My server can't see the data. I do not store it anywhere outside of the user's phone. I do not send it anywhere.</p>
<p>I <em>do</em> offer to back up the user's personal data, but the data is then <em>encrypted</em> on the user's phone (using client-side JavaScript) <em>before</em> it's being sent to my server, and the encryption-key is stored on the user's phone only (end-to-end encryption). It's therefore <em>impossible</em> for me to decrypt the data since I don't have the encryption-key.</p>
<p>Does GDPR apply to me?</p>
<p><strong>ADDED INFO:</strong> The purpose of storing this data is to help the user keep track of his or her personal diet and other health-related information. This is stored together with the user's first name, to enhance the user experience. I guess this could be considered identifiable information.</p>

<blockquote>
<p>Does GDPR apply if my web app stores personal data on the user's phone only?</p>
</blockquote>
<p>No.  If you are not processing Personally Identifiable Information (PII) then the GDPR does not apply to you.  This is what a web browser does when it asks to remember your username and password for this web site.  You are providing a tool, the user is using that tool to process their own data.</p>
<blockquote>
<p>I do offer to back up the user's personal data</p>
</blockquote>
<p>At this point you are processing the users PII, and the GDPR does apply to you.  Even though you do not have enough information to identify an individual, as it can be used with other information to identify an individual it is PII.  <a href="https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/what-is-personal-data/" rel="noreferrer">From the ICO:</a></p>
<blockquote>
<p>Can we identify an individual indirectly from the information we have (together with other available information)?</p>
<ul>
<li>Even if you may need additional information to be able to identify someone, they may still be identifiable.</li>
<li>That additional information may be information you already hold, or it may be information that you need to obtain from another source.</li>
<li>When considering whether individuals can be identified, you may have to assess the means that could be used by an interested and sufficiently determined person.</li>
</ul>
</blockquote>

<p>You're probably a data controller, but you have taken pretty good steps to limit your compliance obligations.</p>
<p>Personal data is any information relating to an identifiable person. You are a data controller if you participate in determining the purposes and means of processing.</p>
<p>The provider of a website is typically a data controller for any data that is processed via that website, even if the processing is handled entirely client-side.</p>
<p>The relevant case law in this instance is the <em>Fashion ID</em> case. A company included a Facebook “Like” button on their website. Loading this embedded button caused transmission of personal data such as IP addresses to third parties (here: Facebook). The company argued that it wasn't the controller e.g. because this processing happened in the user's browser, not on the company's servers. The European Court of Justice found that the company was a joint controller for the data collected and shared by loading the Facebook button, even though the company did not itself process the data. But by embedding the Facebook button, it participated in determining purposes and means of processing.</p>
<p>For your service, this means that you should determine for which processing activities you are participating in the determination of purposes and means.</p>
<ul>
<li><p>The core purpose of your app seems to be diet tracking, and this data doesn't leave the user's device. It may be possible to make an argument that you're not a controller because you didn't participate in determining this purpose, which every user does for themselves. I'd be uncomfortable making that argument, but it depends on the details.</p>
</li>
<li><p>By providing the web app, you are definitely doing some processing activities such as serving the assets, and you are clearly a data controller for these activities (even if you outsourced them). You would also clearly be a data controller for things that your webapp does that aren't explicitly triggered by the user, such as collecting analytics, sending crash reports, or embedding third party resources.</p>
</li>
<li><p>You are offering encrypted backups. These encrypted blobs are still information that relates to an identifiable person (even though you might not have the means to identify the person from the blobs). Thus, storage is processing of personal data and you are the controller for this processing activity.</p>
</li>
</ul>
<p>The UK ICO has also published a checklist to determine whether you are a controller. Only with regards to the core purpose of your webapp, I think the relevant questions would have to be answered as follows:</p>
<ul>
<li><strong>YES</strong> – We decided to collect or process the personal data.
<ul>
<li>You decided to offer a webapp for these purposes.</li>
</ul>
</li>
<li><strong>YES</strong> – We decided what the purpose or outcome of the processing was to be.
<ul>
<li>You decided that the purpose of processing is diet tracking.</li>
</ul>
</li>
<li><strong>YES</strong> – We decided what personal data should be collected.
<ul>
<li>You designed the software to collect certain kinds of data, and not collect others.</li>
</ul>
</li>
<li><strong>UNCLEAR</strong> – We decided which individuals to collect personal data about.
<ul>
<li>The software collects data from users, but users can decide for themselves whether to use the software.</li>
</ul>
</li>
<li><strong>UNCLEAR</strong> – We obtain a commercial gain or other benefit from the processing, except for any payment for services from another controller.
<ul>
<li>Depends on how you offer your service.</li>
</ul>
</li>
<li><strong>UNCLEAR</strong> – We are processing the personal data as a result of a contract between us and the data subject.
<ul>
<li>Depends on how you offer your service. But if users have to accept terms of service before they can create an account, that could indicate that a contract exists.</li>
</ul>
</li>
<li><strong>NO</strong> – The data subjects are our employees.</li>
<li><strong>NO</strong> – We make decisions about the individuals concerned as part of or as a result of the processing.
<ul>
<li>For example, a decision in this sense would be to set insurance premiums based on the data entered into the software.</li>
</ul>
</li>
<li><strong>NO</strong> – We exercise professional judgement in the processing of the personal data.
<ul>
<li>Unless perhaps the software provides nutritional guidance based on the data entered into the software. Are you a doctor or other health professional?</li>
</ul>
</li>
<li><strong>YES</strong> – We have a direct relationship with the data subjects.
<ul>
<li>You are not a sub-sub-contractor, and are directly offering the web app to users.</li>
</ul>
</li>
<li><strong>YES</strong> – We have complete autonomy as to how the personal data is processed.
<ul>
<li>No one is instructing you which features the app should provide.</li>
</ul>
</li>
<li><strong>MAYBE</strong> – We have appointed the processors to process the personal data on our behalf.
<ul>
<li>Processors on your behalf might be web hosters or CDNs for your purpose of serving the webapp. But it doesn't seem like you have delegated tasks relating to the functionality of the webapp itself.</li>
</ul>
</li>
</ul>
<p>Given these considerations, GDPR will apply to you if you also fall under the GDPR's territorial scope: if you live in the EU/EEA/UK, or if you target people in the EU/EEA/UK with your service.</p>
<p>Doing stuff client-side and using encryption is still a great approach because this is a good starting point for ensuring the security of processing as required by Art 32 GDPR. And if you can legitimately argue that you are not the controller for certain processing activities, this reduces your compliance obligations.</p>
<p>Further reading:</p>
<ul>
<li><a href="http://curia.europa.eu/juris/document/document.jsf?text=&amp;docid=216555&amp;doclang=EN" rel="noreferrer">ECJ judgement from 29 July 2019 in case C-40/17 “Fashion ID”, ECLI:EU:C:2019:629</a></li>
<li><a href="https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor-gdpr_en" rel="noreferrer">EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR from 7 July 2021</a></li>
<li><a href="https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/key-definitions/controllers-and-processors/" rel="noreferrer">ICO's Guide to Data Protection: Controllers and Processors</a></li>
</ul>
<p>Which set of guidelines applies (EDPB or ICO) depends on where you want to offer your service. The linked EDPB guidelines were published after the UK's Exit Day and are not directly relevant in the UK, but the Fashion ID judgement is relevant for interpreting both the UK and EU GDPR.</p>

encryption gdpr