INTRODUCTION — BASICS ABOUT GDPR

What is GDPR?

The General Data Protection Regulation (GDPR) (EU) 2016/679 is a regulation in EU law on data protection and privacy. Its aim is to give explicit control over personal data to its subjects. The Regulation was adopted on April 27th, 2016 and it becomes enforceable from May 25th, 2018, after a two-year transition period.

So, May 25th, 2018 is a red-letter day for many companies. It’s a major change regarding data privacy.

Who is GDPR directed to?

Citizens of the entire EU, as well as Norway, Iceland, and Liechtenstein, will become the subjects of GDPR but the regulations will have a global impact for organizations.

If you are a company owner who processes the personal data of EU citizens or citizens of the aforementioned countries, GDPR applies to you. Even if your company is registered outside of the EU, Norway, Iceland, or Liechtenstein.

This means that you need to understand GDPR and start working on a plan to meet its requirements.

Controller, Processor, Data Subject & Data Protection Officer — definitions

Let’s explain a few definitions used in the GDPR world.

Controller (or administrator) — a natural or legal person which uses the data to achieve business goals. In our case, it is usually the application owner .

— a natural or legal person which uses the data to achieve business goals. In our case, it is usually the . Data processor — a natural or legal person which processes the data on behalf of a controller. For example, 3rd party services like Google, Amazon, Fabric, HockeyApp and so on are all data processors. Sometimes collaborating/outsourced development companies may also be considered data processors.

— a natural or legal person which processes the data on behalf of a controller. Sometimes collaborating/outsourced development companies may also be considered data processors. Data subject — a natural person whose data is processed. Basically, in our case, it is an app user .

— a natural person whose data is processed. Basically, in our case, it is an . Data Protection Officer — a natural person designated by the controller or processor to help them and their users with GDPR compliance. This is only required if the amount of processed personal data is significant and/or such data is sensitive.

GDPR — administrative fines

The controller and processor are subject to administrative fines if they infringe the provisions laid out in the GDPR, even if the infringement is not intentional. There are two fine tiers.

a) Up to 10,000,000 EUR or up to 2 % of the annual turnover of the preceding year (whichever is higher) — for the controller, processor, monitoring body and certification body who infringe their obligations.

b) Up to 20 million EUR or up to 4% respectively — for a controller who infringes the principles of personal data processing. For example, personal data processing without user consent, data subjects’ rights infringements or transferring personal data to a non GDPR-compliant recipient in a third country.

You can find more details about these fines in Article 83 of the GDPR.

WHAT GDPR MEANS FOR APP OWNERS

Never before have the needs of application users in this area been so strongly and comprehensively protected. This is why we have to take a fresh look at the way we plan and developing an app in order to fully meet GDPR requirements.

Note that the regulation itself does not contain any exact step-by-step guidelines. It only gives us a list of the general rules that we must keep in mind when creating software.

With this in mind, we can expect a legal approach based on precedents that will occur in the future and which we are not able to predict at this point. Until the first decisions of the courts appear in this matter, we can only presume in which direction the final interpretation of the regulations EU judges will take.

You must also be aware that the lack of adequate security of personal data may result in the outflow of users from your applications. What’s more, the appropriate protection of this need may be a magnet that will additionally attract users and customers.

So, this means that taking the appropriate preparation to meet GDPR standards becomes an added value for your business and can be reflected in future revenues. We hope that our guidelines, which you can read below, will help you to take advantage of these upcoming law changes.

We’ve analyzed several common use cases related to personal data processing in mobile app development and have prepared some guidelines for you. Let’s check them out!

USE CASES

1. I only have access to pseudonymous data from my app, for example, installation ID and other metrics on Google Analytics or similar tools. What exactly do I have to do to become GDPR compliant?

Personal data are any pieces of information about a natural person or any personally identifiable information about that person which gives you the ability to identify them. You should always keep this in mind when you are planning your app development. It doesn’t matter whether the information is directly and closely related to a given person but it’s crucial if they have the ability to identify the person or not.

If the de-anonymization requires manpower and resources which are disproportionate to the information obtained, your solutions meet GDPR requirements.

2. I have an app where users can create content e.g. write comments or chat. They might put some personal data there. Does this matter in terms of GDPR?

Yes, it matters, and this should be taken into account during your app planning & development because, according to GDPR guidelines, each user has the right to request the deletion of personal data that could lead to his or her identification.

You have no influence whether your app’ users place someone’s else personal data within your application. Subjects whose personal data was published without their permission should have the opportunity to contact your Data Protection Officer (or the controller directly if there is no DPO). In such a case, they can send a request to delete such data from your system and you are obligated to provide them with such an option.

3. I use Google Analytics, Firebase, Crashlytics or HockeyApp as a 3rd party solution to support my development. Are they GDPR compliant?

You need to be sure that any 3rd parties solutions you use are GDPR compliant. You can confirm this in their Terms Of Service. For example, at the time we’re writing this post, Fabric claims to be ready for GDPR by May 25th, 2018.

GDPR resolution guidelines impose an obligation on us to check whether the services we use have security certificates in line with GDPR assumptions. According to regulations, we are jointly responsible for the leakage of personal data from third parties.

4. Am I obligated to have a written contract with every 3rd party that processes the data?

A written contract is not obligatory. The Regulations offer a certain amount of freedom here and also introduces a broader concept of “another legal act”.

What needs to be done to ensure that the contract or another legal act meets the requirements for GDPR? It’s simple. Check whether the provider whose services you will use has a certificate of compliance with GDPR. Certification is voluntary, but if you want to be sure whether the service provider is prepared to meet the requirements of GDPR, check whether it has such a certificate.

5. Do I need to have a Data Protection Officer on board?

No, you don’t have to. GDPR provides a certain freedom of choice in this regard.

The Data Protection Officer can be either an employee of the Controller or the Processor, as well as a person from outside the group of employees. This gives us some freedoms with our options and the ability to reduce costs.

The outsourcing model, based on a contract for the provision of services, can be adapted to our needs and scale. When it comes to the number of hours of cooperation, they can be significantly limited.

To sum up, you don’t have to create a DPO position in your company. You can engage a DPO from outside in accordance with your needs.

6. My application uses only emails and logins (without a first and last name). Does this count as personal data?

Yes, they do. There is no easy method of mass verification to see if e-mail address do or do not contain personal data. However, we use nicknames on many portals and it is possible to link them to other data.

We must remember that, whenever we are not sure if the elements of the application can help identify the user, we should assume that this is what can happen.

7. In the application, we log in with Facebook, Google etc. The app sends a token to the backend, which automatically reads the user’s ID (or e-mail address), but not the first and last name. During the validity period of a token (30 min) I can theoretically use it to manually extract personal data. Does this violate assumptions laid out in the GDPR?

The answer to this question is very difficult. There will be no clear-cut answer. We must accept, as in the first case, that any piece of information about a user which gives you the ability to identify a natural person may violate GDPR rules. On the other hand, we can also assume that this data must be obtained with reasonable expenses and costs, which slightly softens the tone of the previous rule. At present, we are unable to determine how the authorities will approach this.

8. I have a store app where personal data is needed for shipping. What should I include in my terms of service?

Store app terms of service must contain a clause indicating that all information about the subject that the consumer enters in the app (name/surname/phone number/address/e-mail and other), are protected. What’s more, the terms of service should also include a full list of user’s rights, such as the right to access, edit & delete their personal data, for example.

Moreover, you must have the user’s consent to process his or her personal data for the purposes of application functionality. So, in every app, there must be a simple way for the user to confirm their acceptance of these regulations. Furthermore, you have to be simple and clear about the regulations the users are accepting.

9. I have a bug reporting system in the app (like Crashlytics or HockeyApp) and personal information can be found there. Does it matter?

First of all, you need to be sure that your bug reporting service provider meets GDPR requirements.

What’s more, it is important what kind of data is included in the reports and who has access to them. With this in mind, we will be able to identify several different answers. Let’s consider 3 cases:

a) The people who view reports already have legitimate access to all the data (e.g. the company has its own development team) — bug reporting is irrelevant.

b) Reported data is anonymous or pseudonymous (so much so that, in a reasonable time and with sensible means, they cannot be de-anonymized). This way of reporting bugs is the best way to provide all the necessary data for the QA team and it meets the requirements of GDPR.

c) Reports contain personal data and we outsource the development team. In this case, the external company must become an entity that processes personal data, as defined by GDPR, or the reports must be filtered and possibly anonymized before transferring them.

10. Are my development team and QA team obligated to have any certificates or training on personal data protection?

No, they do not have to. The only person who is required to have specialist knowledge on this subject is the Data Protection Officer. As we mentioned above, he or she doesn’t even have to be a team member.

Of course, it will be highly advantageous for your business if your Dev and QA team have some knowledge about GDPR, as they can deliver compliant products faster and without violating GDPR rulings.

11. My app processes personal data (not specific data outlined in Article 9) but, on the basis of analytics or crashy reporting, it can be determined that a user is likely to have some dysfunction (e.g. he or she uses large text sizes, so they probably have poor eyesight). Does Article 9 (Processing of specific categories of personal data) apply to me?

No, it doesn’t. We are not dealing here with data that has been given, but with the assumption that it is so. In order to fully determine this, we would have to use significant work and resources, which means you are not in violation of the GDPR rules.

12. I’ve had a personal data leak in my system. What should I do?

You should report such a leak to the supervisory body within 72 hours after having become aware of it, unless you can prove that said leak doesn’t violate the rights or freedoms of natural persons. When the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.

This is one of the most significant changes that GDPR introduces. You can read more about it in Article 33.