A few weeks ago at the Web Summit, we heard a sentence that got stuck in our minds.
“GDPR displaces the problem. The problem is not data protection, but data collection” – said Edward Snowden
We code and we are passionate about developing privacy-preserving software. So this statement got us thinking: isn’t the real problem actually that developers don’t know much about the legal requirements that come with the development of their applications?
In this article, we would like to provide you with a way of development thinking that could help you overcome this challenge, or at least offer you a gift from Pryv: a little roadmap to privacy-compliance (or the 10 facts you should know when developing personal data collecting apps).
A little roadmap to privacy
As we acknowledge the need to restrain abusive data collection practices, we also believe that, with the right knowledge and intent, the collection and processing of personal data can actually help a lot.
For this reason, we’ve decided to gather and further explain some facts about data, privacy, GDPR and compliance that (we hope) will help and guide you when confronted with the collection of personal data. Just like a roadmap brings you straightforward where you want to be.
So here are the 10 facts that we think you should know – or some tips that could help you achieve privacy:
#1. Different kinds of data need different kinds of attention.
The law distinguishes sensitive data from personal data. And did you know that personal data that are sensitive data in regard to the law requires specific protection?
For example, collecting health-related data will require you to be more cautious about consent and security than collecting the language personal preference of your customers.
Tip: Always be aware of the kind of data you aim at collecting and using- today, tomorrow and in the further development of your project: so you can build your data infrastructure right from day 1.
#2. Data minimisation is a thing.
Did you know that the law also requires you to only collect and process data that are actually needed for the purpose of your application? GDPR calls it “data minimisation”. And it applies to any personal data collecting app. To yours, too. If you doubt it, let’s check it out together.
Tip: With that in mind, you should then always have a strict purpose for your application, and define the data that are strictly necessary to achieve that purpose. Don’t worry if you cannot project from now your future data needs, we prepared you another “tip” for this below.
#3. Metadata matters.
And more importantly, they can give way more information than you think.
For example, by consenting to give you their geolocation data, your customers could certainly provide you with more information on their daily habits than they do with their actual logs about it.
Tip: Make sure that your customers are always aware of what data you collect and what you are doing with their data, who can access it, and for what purpose. Be clear and transparent.
#4. GDPR key concepts are a good start…
The right of access. The right to rectification. The right to be forgotten. The right to restriction of processing. The right to data portability. The right to object…
Tip: If your application falls under GDPR, these are the rights (or at least some of) that you should be able to provide to your customers. So make sure you take that under consideration when building your data model.
#5…but Privacy-by-design is the thing!!
GDPR is a good start if you’re looking for general guidelines to achieve privacy: by having these key concepts in mind, you will more likely tend towards a Privacy-by-design approach, and will thus likely make your code also more “regulation-proof”.
Tip: Privacy isn’t only about compliance. It is also about transparency, and building trusted relationships with the users of your application. And as outlined in our previous article, using a privacy-by-design approach will probably save you a lot of trouble in the long run!
#6. Consent is (not) an issue.
Consent is 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.”
Moreover, unless explicitly agreed for a concrete period of time, the consent must be easy to give and revoke at any given time.
Tip: You should always keep in mind that consent isn’t given by default. And your customers shouldn’t be asked to implicitly consent with your architecture either.
Now, have you ever heard of dynamic consent? If not, better get to know about it, as it will give you the flexibility and scalability you are looking for.
#7. Scalability meets compliance.
Today, you prepare your code to be GDPR-compliant. Tomorrow, the ePrivacy Regulation will ask you additional layers of protection and code adaptation. And for what you know, your app could also soon be categorized as a medical device under the new Medical Device Regulation, or it could just be the market itself that suddenly requires you to adapt your software accordingly.
Tip: Ensure scalability across legal frameworks. Not only with regard to existing and forthcoming regulations, but beyond. Regulations come and change, scalability is by-design.
#8. Proven compliance is a must-have.
Indeed, documentation is boring…(we know right?!), but required. We bet that you tend to postpone this part. The truth, however, is that within the context of managing personal data, your code will be audited. You will have to prove that you collect consent properly, store and share the data compliantly, aggregate and analyse on-purpose, and that you can validate that the data has been deleted, whenever the will for this is given.
Tip: Play smart, not hard! Evaluate a ready-to-use privacy-by-design solution, which is already documented, so you can free yourself from the hard work of documenting your code. We heard our customers say that they really appreciate us having this for them.(check it out)
OR:
- Document your decisions and development processes to prove that you know what you do and how.
- Document your code to make it audit-able.
- Document how you collect the data and for what purpose
- Document each time a process access data.
- Document each time data is erased.
Note that some of this documentation should be generated by your digital solution itself.
#9. Data breaches happen.
But only to others, right?! 😉 As developers, it is always tempting to go to « the cool stuff » and then unconsciously skip some very important steps.
Tip: Mind-shift. By having in mind that a breach could happen to you, you will take more precaution and arm yourself (and your software) to handle the crisis. So take this risk seriously and don’t forget about security.
#10 (….)
We listen. Carefully. So if you are a developer of a personal data-based app, what do you think would be the 10th fact to consider, so we can make this « cheat-sheet » excellent?
Now it’s all about you.
At Pryv, we aim at empowering companies and developers so that they can rapidly create and scale breakthrough, GDPR compliant products, and know what to keep in mind when developing personal data collecting apps. So we hope this article will help carry out our mission.
And if you’re interested to know more about our API and data model, you can check it out at api.pryv.com
Our next article coming very soon!
Yours,
Stephanie & Evelina
Resources: