gdpr
GDPR Requirements for restricted use corporate webapp
<p>The GDPR is very complicated, and while its requirements may be crystal clear to those who are intimately familiar with it, it is not at all clear to most as to what the exact requirements are in all circumstances.</p>

<p>My company has a web based product where access is granted only to individuals who are allowed to use the app, by our company, or other companies that have contracted for the use of our product by their own users.  I.e. a user can not simply go to our webpage and create an account for themselves, we have to do it for them.</p>

<p>We currently require and store only information required for business purposes, such as name, phone #, email address, company, etc.  This information is stored in an encrypted database.</p>

<p>We don't "process" this personal information in any way, shape or form, beyond using it to validate users at login time, to contact users when issues arise, to identify current users of specific resources, etc.</p>

<p>The user data is stored in a database, with a UUID.  Any other database field that references the user specifically, contains only the UUID.</p>

<p>There may be other information, for example messages "posted" to an internal memo board, which might contain any sort of information the user, or someone else, might add, including names, email addresses, phone numbers, etc.</p>

<p>Additionally, we log information that is strictly used for debug purposes when problems occur, such as IP addresses.  I do believe, though, that all collected IP addresses are for machines that are part of product, and not specific IP addresses of user machines, although I could be mistaken on that point.</p>

<p>The only cookies we store on the users browser are session based, and are not persistent.</p>

<p>We currently believe that our requirements for GDPR should be fairly simple:</p>

<ul>
<li>The responsibility we have for removing a users personal data is limited to deleting, or simply overwriting the data in the user record in the database.</li>
<li>Arbitrary personal information contained in memo board posts <strong><em>doesn't need to be removed</em></strong>, as it would be difficult, if not impossible, to find such information.  For example, the user may be named Peter Rabbit, but might be referred to in a memo as simply Peter, or Pete, or Pete Rabbit.</li>
<li>We <strong><em>may</em></strong> be required to scan the memo board posts for exact names, email addresses and phone numbers, and remove them from the memos.</li>
<li>On first login, and every subsequent 12 months, we will issue an opt-in message to the user asking permission to store his/her information, etc.</li>
<li>There will be a mechanism for the user to request removal of their personal information.</li>
<li>As the personal information is required for business purposes, if a user opts-out, or requests removal of their information, we will delete their account and remove/overwrite their user record the database, after possibly scanning the memo board posts for exact matches to the fields in the user record.  Of course there will be appropriate safeguards to avoid someone else maliciously trying to delete another users account.</li>
</ul>

<h2>Questions</h2>

<ul>
<li>Do we need to scrub logfiles of user names and IP addresses that <strong><em>might</em></strong> be attached in some way to users, even when those logfiles might be scattered across hundreds of different machines on the internet?  How would we even be able to discern the connection between a user an an IP address?</li>
<li>Given the stated constraints on the use of personal data in our app, does this strategy seem sound and complete, or are there other considerations that we have missed?</li>
</ul>

<p>Your use case is sufficiently complex that you should seek professional assistance. In particular, you may want or need to get a Data Protection Officer for the company to assist with this.</p>

<p>You have an overly narrow understanding of “personal data” and “processing”.</p>

<ul>
<li><p>Personal data means <em>any</em> information <em>relating</em> to an identifiable natural person. This is not just PII, but also covers linked data. A person may be directly identifiable through things such as a name, but also indirectly identifiable. Your UUIDs do not make data non-personal, though they would allow for a kind of <em>pseudonymization</em> if the identifying data is stored separately so that it cannot be combined. This doesn't apply for you: the identifiers are just a database query away.</p>

<p>Data isn't non-personal just because it <em>usually</em> doesn't identify an individual. IP-addresses can be an identifier, for example when a user of your app works from home rather than from the office.</p></li>
<li><p>Processing means any operations on this data, including collection, organization, storage, retrieval, and erasure.</p></li>
</ul>

<p>Cookies are irrelevant for GDPR as long as any processing of personal data is legal. However, the ePrivacy Directive may require you to ask for consent before you store <em>any</em> data on a user's device.</p>

<p>Under the GDPR, any processing needs a legal basis. You have considered asking users for <em>consent</em> (opt-in). However, proper consent is subject to additional requirements and is often not appropriate. For example, consent must be freely revokable. If a user is forced to use your application by their employer, they cannot give free consent.</p>

<ul>
<li><p>The GDPR delegates rules for processing in the context for employment to the individual member states. They likely have more specific rules that are applicable for you.</p></li>
<li><p>A more suitable legal basis is likely your client's <em>legitimate interest</em> (opt-out). This does require an analysis that balances the legitimate interest against the data subject's (user's) interests, rights, and freedoms. In most cases, this will be pretty clear.</p></li>
<li><p>Some processing may be covered by <em>legal obligations</em>. For example, you may be required to keep invoices for some retention period.</p></li>
</ul>

<p>How you have to handle requests for erasure depends on the legal basis.</p>

<ul>
<li><p>If the legal basis was consent, there is an absolute right for erasure, because consent can be freely revoked. Then, you cannot keep anything. This alone is a good reason to try to avoid depending on consent.</p></li>
<li><p>If the legal basis was legitimate interest, there may be an <em>overriding legitimate interest</em> that allows you to (partially) deny a request for erasure. For example, there might be an overriding legitimate interest to keep shared documents available.</p></li>
</ul>

<p>Where you provide services for another company rather than directly to users, the question arises who the Data Controller is. By default, the two companies might be considered <em>joint controllers</em>, which means you both have full obligations to ensure compliance. However, if you sign a Data Processing Agreement so that you process personal data only as per the other company's instructions, you can get the simpler status of Data Processor in that relationship.</p>

<ul>
<li>For example, the Processor doesn't have to directly comply with user requests (erasure, access, …), that is the Controller's job. The Processor must only <em>assist</em> the Controller with compliance.</li>
<li>It is the Controller's responsibility to select appropriate legal bases for the purposes of processing. The Processor just performs that processing on the Controller's behalf, and doesn't need to find a legal basis of their own. That also means they are not allowed to process the data for their own purposes.</li>
</ul>

<p>On to your concrete questions:</p>

<p>1. Yes, log files may contain personal data such as some IP addresses. Scrubbing them is the wrong approach. Instead,</p>

<ul>
<li>define a <em>purpose</em> why you need to process these log files, like ensuring security and proper functionality of the app</li>
<li>select an appropriate <em>legal basis</em>, like legitimate interest</li>
<li>implement appropriate <em>safety measures</em>, such as only keeping logs for some retention period, or masking parts of the IP. Such measures also influence the outcome of the legitimate interest balancing test.</li>
</ul>

<p>Note that these steps are closely related to creating Records of Processing, which you likely have to do as well.</p>

<p>2. Your question shows a good faith effort to comply with the GDPR, and you try adhere to the <em>data minimization principle</em>, which is good.</p>

<p>However, you seem to be making suboptimal choices towards compliance, sometimes have an incorrect understanding of the GDPR's implications, and you seem to be missing some formal requirements for compliance (e.g. a records of processing document). I would therefore recommend seeking professional assistance with your compliance effort.</p>
