2

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.

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.

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.

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.

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

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.

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.

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

We currently believe that our requirements for GDPR should be fairly simple:

  • 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.
  • Arbitrary personal information contained in memo board posts doesn't need to be removed, 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.
  • We may be required to scan the memo board posts for exact names, email addresses and phone numbers, and remove them from the memos.
  • 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.
  • There will be a mechanism for the user to request removal of their personal information.
  • 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.

Questions

  • Do we need to scrub logfiles of user names and IP addresses that might 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?
  • 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?

closed as off-topic by Nij, Trish, A. K., Pat W., jimsug Apr 2 at 3:04

This question appears to be off-topic. The users who voted to close gave this specific reason:

If this question can be reworded to fit the rules in the help center, please edit the question.

  • Counterquestion: do you need to store the IP of the user? could you instead use a cookie on the user's PC to identify him? – Trish Mar 18 at 17:22
  • We don't store any IP addresses, but they do appear in logfiles that are used for debugging issues, etc., as they can often be traced back to a specific ill-behaving or mis-configured machine. The IP address is then used to go to that machine and look at its logfiles for issues, etc... The IP addresses in question are usually those of our system nodes, although some of the tools we use, tomcat, apache, etc., have their own logfiles that could contain the IP addresses of user machines, and we may or may not be able to avoid those IP addresses being logged. – Alan Amaral Mar 22 at 15:33
2

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.

You have an overly narrow understanding of “personal data” and “processing”.

  • Personal data means any information relating 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 pseudonymization 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.

    Data isn't non-personal just because it usually 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.

  • Processing means any operations on this data, including collection, organization, storage, retrieval, and erasure.

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 any data on a user's device.

Under the GDPR, any processing needs a legal basis. You have considered asking users for consent (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.

  • 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.

  • A more suitable legal basis is likely your client's legitimate interest (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.

  • Some processing may be covered by legal obligations. For example, you may be required to keep invoices for some retention period.

How you have to handle requests for erasure depends on the legal basis.

  • 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.

  • If the legal basis was legitimate interest, there may be an overriding legitimate interest that allows you to (partially) deny a request for erasure. For example, there might be an overriding legitimate interest to keep shared documents available.

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 joint controllers, 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.

  • 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 assist the Controller with compliance.
  • 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.

On to your concrete questions:

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

  • define a purpose why you need to process these log files, like ensuring security and proper functionality of the app
  • select an appropriate legal basis, like legitimate interest
  • implement appropriate safety measures, 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.

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

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

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.

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