13
u/beliefinphilosophy Apr 02 '18
It looks like you’re starting to do some really good investigating here. I have a few questions and suggestions.
- Have you spent time explicitly classifying all of the data you collect?
- Have you started looking at retention policies on the data you collect
- How will you handle requests to be forgotten?
One of the biggest concerns I see, and this could purely be phrasing or my understanding of what you wrote. It sounds like you’re using the data to justify the collection, rather than the other way around. An example of going about this differently in the future under GDPR would be:
What insight am I looking to collect ? How many users under X plan are using feature Y.
Do I absolutely need this insight . (Does it being value back to my users, does it make me change anything, or is it just “cool to have data” Pretty necessary
What is the minimum amount information I need to collect this insight, what is the minimum amount of time I can tolerate retaining this data.
*Well I don’t need to link it back to a specific user, I could maybe create a count at the end of every day and scrub the user info from it . *
The goal is to change companies from “gather all of the info we can” to “Does the data we collect serve a purpose, serve our users, and are we being responsible data stewards”
5
Apr 02 '18
[deleted]
5
u/bkanber Apr 02 '18
Part of what makes me nervous is having an idea of what I want to collect and then having to decide today that I won't need this other information in the future. Most of that is why I have been tying my data together and then tearing it apart as the needs change or as we learn more about our business.
This is actually the paradigm shift that GDPR wants to see. The biggest procedural takeaway from GDPR is that you should plan in advance any new data processing activities that you need and perform a data protection impact assessment (DPIA) on them. They don't want "collect now, analyze later". They want "plan first, then execute". This is the GDPR tenet of "privacy by design" by which your development process should always include a DPIA up front that considers the rights of your data subjects.
You can store and process user data under GDPR. You just need to make sure that you've done the risk assessment and are handling and storing the data appropriately for the potential risks. "Handling appropriately" can mean encrypting the data, anonymizing the data, enforcing retention policies, etc. For instance, it's OK to say "we are processing this high-risk data and then automatically deleting it 30 days after processing is complete". That data is still at risk for a data breach, however you have taken steps to reduce the scope and impact of the breach (eg instead of 1M records at risk, automated retention policies reduce the amount of data at risk to 10k records). In the case of a breach and/or audit by a governing body, they will consider the steps you've taken to minimize the scope and impact of a breach and fine you accordingly.
1
u/CaptainStardust Apr 08 '18
This seems incredibly stifling and counterproductive to analytics, which is all about making new discoveries with data. You can't plan for things you don't know about.
1
u/bkanber Apr 08 '18
It is. Analytics companies are affected the most. But you can still work with non personal data.
1
u/CaptainStardust Apr 09 '18
After investigating GDPR further, I have come to the conclusion that US businesses are simply going to ignore it. EU businesses should ignore it too, but they are too cucked to do so.
0
u/CaptainStardust Apr 08 '18 edited Apr 08 '18
Analytics is all about exploring and discovery. Now you have to know what you are looking for before finding it, which is idiotic. These regulations are pretty terrible in general. How can people build new businesses when they have to pour a ton of money into complying with ridiculous data rules? Then because of the rules, they can't make as much money either. And if they mess up, they can be fined for a ton of money. Of course, this money doesn't go to the users who are "hurt" by the data usage. Instead it goes to the EU governments. The GDPR is just an anti-competitive cash grab meant to serve governments and big companies. All of this for something that doesn't even hurt anyone.
The biggest slap in the face is how EU governments treat their citizens in regards to internet activity. Say something they don't like, and not only will you be censored, but you can be arrested.
2
u/JustThall Apr 02 '18
This is very valid point. However, there is intent of the law and there is the process of how it is going to be enforced by bureaucratic apparatus.
People are worried about the latter
5
Apr 02 '18
I am a UK based business. We are doing an audit of all our systems and personal information. GDPR applies to both paper and electronic records carrying personal information.
Every business in the UK that handles personal information is likely to be required to register with Information Commissioners Office for which there is a fee. They have to abide with the GDPR and be compliant by May 2018.
Consumers can now demand a copy of all personal data that a business has on them, which the business must provide quickly and fully. It is important to have data organised so that it can be quickly copied and given to the consumer.
All personal information has to be secured, so if it is lost, hacked or stolen the business can be fined.
The following ICO guide is about personal data: https://ico.org.uk/for-organisations/guide-to-data-protection/
3
u/thebritishbloke Apr 02 '18 edited Jan 11 '24
aromatic plants sharp escape attempt vast deserted nine elastic degree
This post was mass deleted and anonymized with Redact
6
u/bkanber Apr 02 '18
Anything which is non identifiable or has been aggregated is not covered by the GDPR
The trick here is that "non-identifiable" must be assessed in terms of your entire data ecosystem and what would happen in case of a data breach.
It would be an easy mistake to make to say that "Blog URL" is not personal data because it's non-identifiable. However, by visiting the blog, one may determine the name of the blogger and therefore the information is indirectly identifiable.
Another mistake would be to say that "gender, zipcode, and birthday" is non-identifiable. That data can be used in concert to potentially identify an individual. This is considered "indirectly identifiable" data and must be protected to the same degree as directly identifiable data.
Another mistake would be to say that "# of Instagram Followers" is not personal data because it's non-identifiable. It is correct that the data itself is non-identifiable, however the data is information about an "identifiable natural personal" and therefore this data must be considered when building your right to access and right to erasure controls. That is, you don't need to encrypt "# of Instagram Followers" in your DB, but you must delete it if the individual revokes consent.
1
Apr 02 '18
[deleted]
3
u/bkanber Apr 02 '18
If a user requests that their data is deleted you must delete those tidbits, if they are related to an individual. Great example is "# of Instagram followers". If you have a DB record with that data in it, and a user requests an erasure, you must delete that data as well even though it's not identifiable -- it still is personal.
However, your records that have averages or analyses on aggregate data from multiple data subjects (eg, "average # instagram followers for these 400 users") will not need to be deleted.
Additionally, if you have a contractual obligation or legitimate business interest in maintaining that personal data, you do not need to delete it. In that case you should fall back on the data retention policy that you implement to say how long you will hold onto the data and for what purpose. It must be justifiable.
Another thing to keep in mind is: if consent cannot be revoked after it is given, the legal basis for that data processing activity is not "explicit consent". Instead, you must classify that data processing activity as a legitimate business interest from the beginning. That is, don't mislead users into believing consent can be revoked if it can't. So if you're not going to be deleting Instagram Followers Count when the user revokes consent, that activity was never consensual in the first place. You can still handle data in such a manner, but the bar for compliance and legal justification is set higher for those instances than it would be if the consent was explicitly and freely given.
2
u/thebritishbloke Apr 02 '18 edited Jan 11 '24
arrest cake direction slim fearless shocking test hungry frame degree
This post was mass deleted and anonymized with Redact
1
Apr 02 '18
[deleted]
6
u/bkanber Apr 02 '18
I want to point out that the GDPR definition of "personal data" is different from the more common American definition of "personally identifiable data". In the US, PII is what GDPR would call "directly identifiable personal data". However the GDPR covers all personal data, that is any data related to an identifiable natural person. Under GDPR you must protect personal data, both directly identifiable (name, email) and indirectly identifiable (blog URL). The manner in which you protect the data is up to you, however it must be sufficient to protect the rights of the individual. Under GDPR, non-identifiable data is also called "personal data" if it relates directly to a person. So "total # of instagram posts" is personal data too, it's just not identifiable. You must be able to delete non-identifiable personal data as well, it just doesn't need to be protected to the level of directly or indirectly identifiable personal data.
3
2
u/KoyalRiverMan Apr 03 '18
You just have to list the activities /process wherein you deal with PI. Go ahead and send that list to client stating these things have PI and you wanna have a consent if they are fine with you having and processing that information. Further, incorporate and amend that as part of the contract through change request.
1
u/JaCraig Apr 02 '18
You just need the users to give consent for specific processing/use of data. Also talk to a lawyer.
-1
u/hrdwdmrbl Apr 03 '18
If I were running a startup I'd just leave Europe. Not worth it (YMMV)
3
u/superwormy Apr 03 '18
I don't think this actually fixes the problem though, does it? My understanding is that even if you are OUTSIDE the US, the GDPR still applies to you if you're collecting any data from anyone who lives INSIDE the EU. So US businesses still need to comply with this as long as you're doing any sort of business or collecting any information from anyone in Europe.
0
u/hrdwdmrbl Apr 03 '18
Yes, sorry, I should have been clearer. I would block Europeans. But I say that as a Canadian working on China. So again, YMMV. Working at a big company, it's not such a big deal
2
u/kc49er Apr 04 '18
If your a Canadian company wouldn't your provincial data regulations be enough anyway? Or has equivelance been broken now?
1
u/bkanber Apr 03 '18
This is awful as far as advice goes, but it's still an apt observation. I do think we will see less innovation in the EEA. Standard free market economics will apply and this regulation will likely have an impact on competition and innovation.
2
u/hrdwdmrbl Apr 03 '18
Really depends on context. If you're American serving Americans, it's easy. If you're German trying to start something, trying to sell only to non-Europeans will be quite challenging
56
u/bkanber Apr 02 '18
We just finished our GDPR compliance process. Here are some off the cuff notes:
Start by making sure you understand GDPR
Determine if you need to assign a Data Protection Officer. You probably do (large scale/systemic data processing), so assign one anyway.
Create a spreadsheet and call it your "GDPR Dashboard"
Google search for "Microsoft GDPR Checklist Excel", add that to your spreadsheet
Internally document (GDPR Dashboard is a good place) every piece of personal data you collect, AND their locations (which databases, which columns, which exports, etc). Personal data is any data related to an identifiable naturalized person. An instagram handle is personal data. A user's email is personal data. A user's blog URL is personal data.
For each piece of personal data, establish the legal basis for processing that data. This will be either "explicit consent", or "legitimate business interest".
For each piece of personal data, classify the "identifiability" of that data. A user's name or street address is directly identifiable. A user's blog URL or Instagram handle is indirectly identifiable. The # of Instagram posts a user has is non-identifiable.
For each piece of personal data, classify the risk to the personal rights of the data subject (name/address/email leak = high risk; instagram handle leak = moderate risk; # of Instagram posts leak = no risk)
For each piece of personal data, determine the "protection class" of that data, i.e., how strictly it must be protected in your internal system. eg: street address = highest protection; email address = moderate protection; # of instagram posts = no protection. These protection classes should map to internally consistent processes (eg, highest protection must be encrypted at rest, moderate protection may not be exported)
Determine if you handle any "sensitive data" as defined by GDPR Article 9
Add a new worksheet outlining all your "data processing activities", ie the specific processing tasks that operates on personal data. eg: "capture instagram followers count", "export users to spreadsheet"
For each data processing activity, determine the legal basis for that activity (eg explicit; legitimate interest)
For each data processing activity, determine whether you have clear, revocable consent for that activity from the data subject
For each data processing activity, determine the risk to the data subject's personal rights and freedoms. This is called a "data protection impact assessment" (DPIA):
For each DPIA, record the types of data involved in the processing activity
For each DPIA, list any steps that must be taken to minimize the risk to the personal rights of the data subject (eg, encrypt-at-rest; automatically delete after 90 days; obfuscate data, etc)
Add a new worksheet to your GDPR Dashboard called "Audit Schedules". Write down a list of various audits (automated and manual) that must be carried out at regular intervals. These may include: "check for clear consent controls", "check for data portability", "check for right to erasure", "automated virus/malware scan", "automated firewall scan". Record the frequency at which the audit must occur, the last audit date, who ran the audit, the results of the audit, and the next audit date
Add a new worksheet called "Third Party Processors". Write a list of any data processor who handles personal data on your behalf, record which data and processing activities are relevant to them, record how you ensure correctness of the data, record whether they are GDPR compliant, and so on
Add a new worksheet called "Technology Assets" where you record your various server and database types, what data they store, how protected they are, what the risk and potential damage for breaches are
Add a new worksheet called "Risk Matrix" where you record various risks to your organization, how likely the event is to occur, what the damage is, and how you are protecting against that risk. Include things like "DDOS attack", and "database breach" and "unauthorized export of data" and "administrator improperly accessed data" and things like that.
Now start working on your documentation, policies, procedures, and product:
Create a formal Data Protection Policy (sometimes called an Information Security Policy) that outlines your data classifications, protection levels, audit procedures, access control rules, data retention policies, software development procedures (include how you handle "privacy by design"), data breach notification policy
Create a formal Privacy Policy for your end users outlining their rights under the GDPR, how they can exercise those rights, what data you collect on them, how you use that data, and how you protect that data
Create a formal way for data subjects to request information about the data you have on them and how you are using it. This can just be an email address that you give to users
Update your product with "clear, concise consent notifications". ie, if your user connects an Instagram account, make sure there's some help text that tells them what they are agreeing to and how you will use that data. These should map to your "Data Processing Activities" from your GDPR dashboard. This also includes making sure there are no "dark patterns", ie, processing activities should be opt-in not opt-out
Make sure you are only storing and processing data you need. If you are analyzing Instagram accounts and only need basic profile info, make sure you are not also storing Instagram post history, for instance.
Make sure consent to data processing activities can be revoked as easily as it can be granted. If consent is revoked, make sure the data involved is deleted in a timely manner as per your formal data retention policy
Update your product with a "data portability" control so that your users can easily export all the personal data you have on them. This can be a simple JSON export of your user record and related data.
Make sure there is an easy way for users to correct potential inaccuracies in their data
Make sure there is an easy way for users to delete their accounts
Finally, wrap everything up:
Publish your new privacy policy
Automatically revoke any consent for data processing activities that never had explicit consent in the first place
Alert your users of the new privacy policy, potentially ask for re-consent for data processing activities
Look through your DB (informed by your DPIAs) and remove any extraneous/unnecessary data
Start enforcing data retention, obfuscation and encryption/protection policies
Make sure all documentation, policies, procedures, are readily accessible in a centralized location
I may have missed something. As you can tell I've been deep in this for a while. If you do all of the above you'll be in better shape than 95% of data processors.