Development Guide to a GDPR-Compliant App

GDPR is an abbreviation that stands for the General Data Protection Regulation designed for data privacy. It was approved by European Union Parliament on 14th April 2016, but it came into force on 24th of May 2018 and applied since May 25th.

GDPR regulation makes companies responsible for appropriate personal data protection. Although it does not indicate any particular activities that should be taken, companies are obligated to use every possible and affordable method to protect the data they process.

General Data Protection Regulation clearly defines improper personal data protection and processing consequences. Companies that are not GDPR compliant can be fined up to 20 million euros or 4% of annual revenue in the case of a data breach (depending on which amount is higher).

There are some criteria that affect the final fine value. According to the GDPR.eu portal, they include:

• nature & severity – what, how and why the data breach happened, how many people were affected, how harmful it was and how long it took to resolve the problem,
• intention – the beach was intentional or an effect of neglect,
• mitigation – whether the company took some activities to mitigate the breach effects,
• the level of preparation – how the company prepared itself to prevent such accidents, the level of organisational and technological preparation,
• history – whether the company breached any data protection provisions before or proven to be GDPR compliant (e.g. by receiving certification),
• cooperation – whether the company worked hand in hand with administration officials to discover and alleviate the breach,
• data category – the kind of data leaked,
• notification – whether the company informed appropriate organs that the breach took place,
• other circumstances.

That’s why hiring a reliable and experienced software developer is crucial (especially one who works hand in hand with lawyers). The objective is not only to build a GDPR-compliant mobile app (or web app) but also to be prepared to discover and immediately react to every threat.

When you hire a software developer, investigate whether they:

• don’t belittle GDPR compliance,
• cooperate closely with GDPR lawyers,
• are able to implement solutions for data branches prevention and discovery,
• appropriately address every GDPR aspect,
• can help you to build processes for data processing and protection.
• are available for maintenance and/or ongoing support. This way, they could easily “hop back on” the project in the case of any breach or GDPR changes.

Many people think that if their company is established outside the European Union, they are not obligated to be GDPR compliant.

The truth is, you are beholden to obey GDPR resolution if at least one of your app users is a European Union citizen.

In practice, if you’re launching an app and it’s in one of the European languages (which increases the probability of reaching this region) and won’t exclude people based on location (what might be considered discrimination), you must obey the rules.

GDPR always applies when you have EU users in your app.

The GDPR defines that the managing director or executive board are responsible for proper personal data protection. Employees could be responsible only if they disobeyed the rules intentionally or with gross negligence.

Data Protection Officer

You can also hire a Data Protection Officer to ensure you have all procedures needed and apply to all GDPR requirements. You’re not obligated to do that unless your app is built to process sensitive data or monitor people in detail.

An external data protection officer (not hired as an employee) can also be blamed for breaches or violations if they provided insufficient or incorrect advice or did not properly monitor the company’s data processing procedures.

Obviously, we all see a name or home address as personal data, but the definition goes further. There was a time when everyone wondered whether an email was personal or not (just try to identify the owner of an email like john@samplemailbox.com). So, what’s the definition of such?

Personal data are all details about a person that allows us to identify it within a reasonable amount of effort and resources. The combination of identifiers might also be needed to identify a person; those data can still be considered personal.

That means we can include something in this category if we can define a person relatively effortlessly and without spending much money. According to this definition, location data, users’ IP addresses or even identification numbers might be considered personal.

Following this definition, we’ll discover that also cookies are personal consumer data because of setting a cookie ID. Some cookies can be used to track web and mobile app users’ activities throughout the internet and build a comprehensive profile of an identifiable person that can be targeted by adverts.

There is another European privacy regulation on the way – the e-Privacy Regulation. It’s expected in 2023, it will widen the data protection to other entities (which means a company email will be treated as a personal one) and include metadata in the protected data catalogue.

This regulation is also expected to make life easier in terms of cookie consent as it should allow using browser settings for cookie tracking and not gaining consent for non-privacy intrusive cookies (e.g., monitoring what was purchased).

Sensitive data is a subcategory of personal data that refers to information about:

• racial or ethnic origin,
• political views,
• religion and beliefs,
• trade-union membership,
• biometric and genetic,
• health condition,
• sex life and sexual orientation.

The processing of those kinds of data is often regulated by some other documents like HIPPA, EHR or FDA in healthcare that specify those aspects even in more detail.

To understand the GDPR, it’s crucial to differentiate between data processors and data controllers.

A data controller is a party that decides what data will be collected, about whom and for what purpose. A data controller usually gains benefits from data collection.

A data processor is a party that processes personal data in the controller’s name (e.g. cloud services providers). It has data entrusted by its customers and doesn’t decide about the scope and purposes of the processing.

Although any organisation can be a data controller and a data processor at the same time, it’s a common practice to entrust the processing of the data to 3rd party companies like hosting providers or marketing app owners (marketing automation apps, meeting schedulers, analytical tools).

A data controller is solely responsible for any breaches, even if they were caused by the data processor they hired. Therefore, GDPR requires data controllers to verify processors and protect data using all means possible.

Data processors and controllers – examples

Let’s take a look at two scenarios – when you’re a food delivery app owner and a marketing automation app owner.

Food delivery app

Let’s say that, in this case, you provide a space for different restaurants to show their menus and allow your app users to order some dishes.

In this case, you’re the controller, and you define the processes. If you don’t have your own infrastructure, you probably have a hosting provider who is the processor (who processes the data for you). You can choose the service provider and are responsible for it.

If they order a meal, you also share your users’ personal data with restaurants, so those are third-party companies. You need to inform app users about this and gain their consent, e.g. by ordering, they agree to pass their data to the restaurant.

Marketing automation app

In this case, you are a controller and a processor at the same time. You can control processes regarding your app and your clients’ data, but the data you store in your client’s name is not yours. You are a processor for your customers’ clients’ information (but they are controllers for their purposes).

If you don’t have your own infrastructure, you probably entrust the processing to a hosting provider (who is a sub-processor for your clients).

The GDPR obliges companies (app owners) to respect the rights of both their website and mobile app users and guarantees them many privileges.

You certainly need to address GDPR regulations if:

• users can sign up for your app and create accounts,
• users need to provide an email or login,
• people might do shopping in your app with a shipping feature,
• you have an analytics tracking tool installed (especially Google Analytics, Firebase or similar),
• and so on.

What activities are illegal under GDPR?

If you’re about to develop a GDPR-compliant mobile app (or web app), you need to remember that it’s forbidden to:

• collect and process users’ data without permission,
• collect and process more users’ data than they agreed on,
• collect and process more data than required for a particular purpose,
• process data after the consent was withdrawn (although there are certain exceptions),
• pass data to 3rd parties without clear information and users’ consent.

What’s privacy by design and default

Privacy by design and default rule means that privacy practices must be immersed part of software development from the very beginning.

You need to design data-related processes and think about how you’ll protect users’ data before starting your app’s development. Hiring a GDPR-oriented app developer can help you do that seamlessly and effectively.

What are the purposes of processing

The GDPR obliges every company to request permission to collect, store and process personal data. For this reason, you need to clearly define to your app users for what purposes the data will be processed before you ask for consent.

You might need data for invoicing, bookings, placing orders or communication (informational like push messages about the order status or promotional).

Remember that you cannot use the data for any other purpose than the agreed one.

Checklist:

• We clearly defined the purposes of data collection and processing.

What data you’ll collect (proportional to the purpose of the processing clause)

For GDPR compliance, you can’t collect too much data, only those that are strictly necessary for a particular purpose. In each case, the amount of data must be justified.

Of course, you can ask for non-obligatory information, but you can’t forbid access to the app if they are not provided.

Let’s take a look at a free mobile game to understand the situation. During registration, you might ask for a name and an email, but you can’t force users to share a surname or phone.

Checklist:

• We know what data we want to collect for every purpose we defined.
• The amount of data collected is appropriate for the purpose of processing.

Where will the data be stored

You need to define where the collected data will be stored and whether they will be entrusted to any 3rd party. You should also sign a personal data entrustment agreement and inform users about the processing and sub-processing of their data if applicable.

Checklist:

• We know where the data will be stored (and who the processors and sub-processors are).
• The data storage is localised in United Europe.
• If we entrust data processing to 3rd party, we’ll sign an appropriate agreement.

How to take care of data security

GDPR requires the controller to ensure that the data will be secured in the best possible way (the best possible ways clause), even if they entrust processing to a 3rd party. Data encryption is just the tip of the iceberg.

For this reason, you can say “yes” to those statements:

• We have clear customer data protection procedures defined.
• Every employee who has access to data uses 2 Factor Authentication.
• We use pseudonymization whenever possible.
• We encrypt the data we receive and send.
• We use pseudonymization where possible.
• We took care of secure communications with 3rd party services.
• We provide systematic monitoring, and we can anticipate potential issues before they occur and prevent them.
• We know exactly how the infrastructure is secured.

Who will have access to the personal data, and how will they be managed

You need to know precisely who will have access to your data and which entitlements they have. That refers to your employees and 3rd party representatives (like the support team).

• We know exactly who will have access to our data (employees or 3rd party staff).
• We know in which situations those people will have access to the data.
• We log every login of such people and every manual data entry change.
• We have different levels of access (e.g. for downloading files) and can manage them easily.
• We can immediately take back access from those people.
• The system can detect breaches based on unusual or unexpected activities.

How to collect personal data? Transparency of data collection, informed consent and the right to be informed

According to Article 5(1)(b), you must inform users why you’re collecting their data and how you’ll process them. It’s called the right to be informed so they can express informed consent.

Users who share their personal information must be informed about who gathers their personal details (who the controller and processors are) and how those will be used (for what purposes).

The data cannot be processed for purposes other than those accepted by users when they share them. They need to provide their explicit consent for a specific processing purpose.

Contact forms

How to ask app users for permission in a contact form and not overwhelm people by adding thousands of checkboxes?

If the data collection and processing agreement are strictly necessary to fulfil the request, you don’t need to add checkboxes. To gain informed consent, you can use an informational clause instead, and in this case, the action of sending a form will be granting the agreement at the same time.

An informational clause is a sentence that provides all necessary information about who, how, for what and when will be processing users’ data, and it fulfils the right to be informed (you can read more on this below).

Automated details gathering

You can also gather such information as IP addresses, cookie identifiers or customer IDs; in each case, you need permission to do that.

Checklist:

• We ask for permission every time we collect data (by checkbox or activity taken).
• We inform users who the controllers and processors are.
• We notify users for which purposes their data will be processed.
• We have clear procedures to log consent and informational clauses.
• We know how to gain consent for automated details gathering.

Agreements management – how to record consents

Asking for permission is not enough for GDPR compliance. Now, you need to record the permission and store it in a way that doesn’t leave room for changes. It’s up to you to prove that users provided you with consent and that you process their data lawfully.

Checklist:

• We know how the consent was granted (informational clause, checkbox, application settings).
• We use marketing automation or CRM tool to store consent or keep email confirmations of forms submitted.
• We store information about all opt-ins (consents granted) and opt-outs (consents withdrawn) in a non-modifiable way with the date and time of expressing the consent/withdrawal.

Consent to profiling and automated decision-making

There are many cases when you might need to segment users depending on the values of some variables, or you might want to make an automated decision about a user. In such cases, you also might need additional users’ agreements.

• We described profiling and automated decision-making in data protection policy.
• We clearly explain in a privacy policy what indirect data we collect.
• People can access their data and correct them if needed.
• We inform people how they can object to profiling (including marketing purposes).
• We don’t gather too much data according to the purpose.
• This type of processing doesn’t have legal or other significant effects on people (if so, you definitely should consult with lawyers before you start).

The right to restrict the processing of personal data (erasure, to be forgotten)

The right of erasure is also called the right to be forgotten. Your users can demand erasure from your database, and you have 30 days to process such a request. That also means that third-party services can no longer process the data.

There are, however, some circumstances in that you might not fulfil the request. People might demand you stop processing personal data, but you might still store them (for more information on this point, I suggest you check the Right to erasure by ICO).

Keep in mind that erasure also refers to backup systems. You must be sure that the data won’t be used after the backup is restored.

Checklist:

• Our app allows people to send a request to be forgotten or they are informed how to proceed in Privacy Policy.
• We know when we can refuse the request.
• We’re able to process the request within 30 days.
• We have procedures to:
  • delete users who request to be forgotten (and we have a person responsible for that),
  • handle requested data stored in backups,
  • prevent 3rd parties from further processing the data.

When can’t you remove users’ data?

According to GDPR.eu, there are a few circumstances when you can’t remove users from your database:

• The data is being used to exercise the right of freedom of expression and information.
• The data is being used to comply with a legal ruling or obligation.
• The data is being used to perform a task that is being carried out in the public interest or when exercising an organization’s official authority.
• The data being processed is necessary for public health purposes and serves in the public interest.
• The data being processed is necessary to perform preventative or occupational medicine. This only applies when the data is being processed by a health professional who is subject to a legal obligation of professional secrecy.
• The data represents important information that serves the public interest, scientific research, historical research, or statistical purposes and where erasure of the data would likely to impair or halt progress towards the achievement that was the goal of the processing.
• The data is being used for the establishment of a legal defense or in the exercise of other legal claims.

The right to access their personal data (Subject Access Request)

Under GDPR, every person has the right to access the personal details you’ve collected. It’s called a Subject Access Request (SAR) or Data Subject Access Request (DSAR).

You, as a controller, need to explain to users how the data was collected, how it is processed, and who has access to it (including your employees and 3rd party companies).

Remember, however, that you cannot share personal data in response to every single request. The request should be made personally, by telephone, traditional post, or electronically. You should record the receipt of such a request and ensure that the person who is to receive the data is the one to whom they are related (otherwise, it’s a breach).

Checklist:

• We have a procedure for providing people with access to their personal information.
• We can clearly explain to them:
  • how their data were collected,
  • how their data are processed,
  • and who has access to their data (and when).
• We know how to verify whether the request was made by the authorised person.
• We evident and store every such request for legal purposes.

The right to data portability

GDPR allows people to transfer their data from one electronic system to another whenever they need it (so-called data portability). It’s your job to make it secure and reliable.

• We have procedures to follow user requests of this kind.
• We are ready to transfer user data from our system to another.
• We know how to ensure data security.

The Right to Rectification

People have the right to correct their data if it’s inaccurate or incomplete. How they will be able to do that is up to you – that might be a contact address for such a case mentioned in the Privacy policy on your website, an option in the menu after login to the account or some other way. People can do that by themselves or with your support assistant. The point is they should be able to do that.

• We offer people an easy way to rectify their data (using their profile in the app, by an online form or by contacting us via email indicated in the Privacy Policy).
• We have a procedure for processing such user requests if they require our activity (via support).
• We store information about the request.

The right to object

Users have the right to object guaranteed, which means they can object to how their data is processed in terms of marketing, sales and other purposes.

If you receive such an object, you must immediately stop processing the data for marketing purposes. However, there might be some cases when the objection not applies.

You have one calendar month to respond to such an objection (verbal or written).

• We clearly explain in the Privacy Policy how users can object to processing their data.
• We know how to deal with both verbal and written objections.
• We know when we have the right to refuse an objection and how to inform the person about that.
• We are prepared to respond to objections within 30 days.

Integrations with third-party services & SDKs

Do not assume all Third Party Software or SDKs in your application are GDPR compliant. If a third party breaches your users’ personal information, you are responsible for this loss.

• We can define all third-party services we use in our app.
• We have access to and understand their personal data policies.
• We assessed the risk associated with using those services.

Cookies & analytics tracking tools

Every time you load cookies in your app (mobile or web), and there are not strictly necessary ones, you need the user’s consent to create them in a user’s device.

The most controversial group are analytical and advertisement (marketing) cookies that allow to follow and track users to display some adverts to them.

Using cookies, some analytics tracking tools might send data to 3rd parties. Therefore, you need additional consent to run them in your app (e.g. Google Analytics).

• We know what analytical tools we use in our app.
• We know their data privacy policies.
• The tools are off by default until a user doesn’t agree to turn them on.

Localisation tracking

Nowadays, localisation tracking of mobile app users is extremely popular. You can send in-app messages or notifications when people are near some locations (stores, restaurants, events and so on).

If you want to make your mobile app GDPR compliant, you should verify whether you’re not collecting localisation information without consent or to a too large extent.

• Our mobile app collects strictly necessary localisation data only.
• Our mobile app doesn’t collect information about localisation if a user doesn’t provide or has withdrawn consent.

Data breach reaction

According to GDPR, you must immediately inform the appropriate organs and your users if any breach appears. You also need to take action to alleviate the effects and retrieve the detriments.

However, there might be no need to inform any organs if there is a minimal probability of violating users’ rights (e.g. a computer with personal data was stolen but was locked and encrypted). In such a case, however, I recommend you consult with lawyers whether you need to take action or not.

That means you must be aware of such an event, and that requires appropriate preparation.

• We’ll be notified immediately if a breach occurs.
• We have procedures to follow in the case of a breach to alleviate the effects.
• Our development team is ready and prepared to react in no time in such a case.
• We’re ready to notify users within 72 hours if the breach occurs.
• We’re ready to inform appropriate organs about issues.

App users’ data retention

You cannot store data forever but need clear data retention rules (in other words: you need to know precisely when it’s time to delete data from your database).

• We have clearly defined the data retention policy.
• We don’t store data longer than necessary.
• We would erase data if users were not active for X months/years.
• We delete people who opted out from marketing communication if their data is not required for other purposes (like invoicing).
• We know the circumstances that obligate us to keep personal information in our systems even if users request the removal.

Clear documentation for the data privacy policy

Users must be aware of all aspects mentioned above, so you should express them clearly in Privacy Policy.

• We have comprehensive knowledge and procedures about how we process personal data.
• We published them in our Privacy Policy.
• Users can easily access the Privacy Policy when their data are concerned.
• The Privacy policy is published in advance and has an effective date.