Legal Issues to think about for mobile app Developers

By Paul Foley

The General Data Protection Regulation 2016/679 (GDPR) requires a data controller to implement data protection by design and by default (Article 25 GDPR). Organising for and engineering data protection and security requirements into a Mobile APP (APP) is difficult, particularly as APPs are generally developed using the Agile development process. 

This short article seeks to outline what data protection by design and default means and entails.

Legal Issues to think about for mobile app Developers

An APP is an application software program (that is not an operating system), that is either preloaded on or that can be downloaded onto a smartphone, tablet or other mobile device (device), enabling the device user to access and the use the services provided by the APP.  The development of APPs and the devices on which they run, has emerged to become of the world’s largest industries.

There are Native APPs which are developed for a specific platform e.g. the Android platform (from Google Play Store), or the iOS Platform (Apple APP Store)). Then there are Web APPs which usually run on a browser and are usually written in HTML5. They can be accessed in the same way as the web pages on the browser and do not rely on APP stores, therefore they are free from any type of updates triggered at the smartphone level. Finally, Hybrid APPs. These APPs result from a combination of a Native APP and a Web APP.

The APP itself may be written by combining various functions, some of which may be written by the developer (such as the front end and the backend ecommerce engine), whereas other functions may be developed by a third party and licensed in by the developer. Third party functions may consist of third-party libraries hosted by a third party which help developers, for example, track user engagement (analytics), connect to social networks and generate revenues by displaying ads. However, in addition to the services provided by these libraries, libraries may also collect personal data for their own use.

The provider of the APP and the services which it enables, may be a provider of digital ID services, the provider of a Covid contact tracing APP, a booking APP, a digital content provider supplying via an APP and its device, news, films, TV music or games to their customers mobile devices, or a retailer who wishes to develop its online distribution of its products. Then there is the fintech sector, where APPs are developed to provide regulated payment services under PSD2 for the users of their services. These are very heavily regulated.

Data Protection by Design and Default

The data controller must implement appropriate technical and organisational measures, (1) such as pseudonymisation, which are designed to implement the Data Protection Principles, such as data minimisation, in an effective manner (Article 25(1) paraphrase) and (2) for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed. That obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility (Article 25(2) GDPR paraphrase)

The EDPB argue Article 25 means (in summary form) that controllers should be able to demonstrate that they have the appropriate measures and safeguards in the processing to ensure that the Data Protection Principles and the rights and freedoms of data subjects are effective. More practically, user service settings (e.g. no automatic opt-ins on customer account pages) must be automatically data protection friendly, and that only data which is necessary for each specific purpose of the processing should be gathered at all.

The Data Protection Principles (Principles)

The Principles are set out in Article 5 GDPR. The security obligation for controllers is applied in Article 5(1)(f) and is further amplified in Article 32 GDPR and for processors in Article 28 GDPR.

The Principles relating to the processing of personal data require that personal data is

(a) processed lawfully, fairly and in a transparent manner in relation to the data subject; (

b) collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes;

(c) adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed (‘data minimisation’);

(d) accurate and, where necessary, kept up to date;

(e) kept in a form which permits identification of data subjects for no longer than is necessary (‘storage limitation’);

(f) processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures (‘integrity and confidentiality’) (Article 5(1) GDPR).

The controller is responsible for, and must be able to demonstrate compliance with all six of the Principles in Article 5(2) GDPR.

Lawful Data Processing

Processing will be lawful only if and to the extent that at least one of six provisions in Article 6 applies including (a) the data subject has given consent to the processing of his or her personal data for one or more specific purposes. (Article 6(1)(a))

From a developer and from a marketing perspective Article 6(4) is important. Where the processing for a purpose other than that for which the personal data have been collected is not based on the data subject’s consent or on a Union or Member State law,  the controller must, in order to ascertain whether processing for another purpose is compatible with the purpose for which the personal data was initially collected, take into account, inter alia:

(a) any link between the purposes for which the personal data have been collected and the purposes of the intended further processing;

(b) the context in which the personal data have been collected, in particular regarding the relationship between data subjects and the controller;

(c) the nature of the personal data, in particular whether special categories of personal data are processed, pursuant to Article 9, or whether personal data related to criminal convictions and offences are processed, pursuant to Article 10;

(d) the possible consequences of the intended further processing for data subjects;

(e) the existence of appropriate safeguards, which may include encryption or pseudonymisation. (Article 6(4))Security

The Article 5(1)(f) security obligation is amplified by Article 32 and requires the controller to take into account the state of the art and adopt a risk based approach. More particularly it requires a controller and processor to as appropriate (which is explained in Article 32(2) GDPR) implement:

(a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing. (Article 32(1) (paraphrase))

Adherence to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate compliance with the requirements set out in Article 32(1).(Article 32 (3)).

Development Tips

At the outset of a development, it is advisable to use a Data Protection Impact Statement (Article 35 GDPR) (not reproduced here) as a checklist even if the development itself would not mandate one. Note the prior consultation requirement in Article 36.

Check the Android and iOS guides on APP permissions. These are useful to understand why APPs may need access to personal data and how to structure consents. Note the specific requirements for consent in Article 7 GDPR.

The processing of special categories of personal data (Article 9) is prohibited, unless one of ten grounds apply including in Article 9(2) (a) the data subject has given explicit consent to the processing of those personal data for one or more specified purposes, except where Union or Member State law provide that the prohibition referred to in Article 9(1) may not be lifted by the data subject. This is a developing area of law and Union and member state developments need to be checked.

Note the conditions applicable to a child’s consent in Article 8. This is also a developing area of law at EU level and in many member states and so requires considerable due diligence.

On top of GDPR provisions, in the area of APPs, privacy and data protection requirements also stem from the Directive on privacy and electronic communications 2002/58/EC (ePrivacy Directive). Note the incoming ePrivacy Regulation which is the final stages of negotiation.

Map the potential data flows to and from the APP. Identify the personal data that will be collected and processed and consider when Encryption, Anonymisation ( data that is anonymised is not personal data) or Pseudonymization of personal data should be used The latter refers to the processing of personal data in such a way that data relating to a natural person can no longer be attributed without additional information.

Personal data which has undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person (recital 26). The application of pseudonymisation to personal data can help controllers and processors to meet their data protection obligations (recital 28). Pseudonymisation is a data security measure which enables controllers and processors to demonstrate compliance with their obligations under Articles 5(1)(f).

The architecture of the APP should facilitate the exercise by data subjects of their rights being: (i) to request a copy of their personal data (Article 15), (ii) the right to be informed (transparency) (Article 13 & 14 GDPR) (iii) the right to rectification (Articles 16 & 19 of the GDPR) (iv) to erasure (Articles 17 & 19 of the GDPR), (v) the right to obtain from the controller restriction of processing where one four grounds apply (Article 18), (vi) a new limited right to data portability (Article 20) (vii) the right to object to processing of personal data (Article 21 of the GDPR) and (viii) a right not to be subject to automated decision making and profiling without appropriate safeguards (Article 22).

The architecture of the APP should also facilitate the reporting of data breaches to the supervisory authority under and where required by Article 33 and to communicate a data breach to the data subject as required under Article 34.

ENISA point out, that the exercise of the right to erasure is of particular interest in the case of users deleting the APP from their mobile devices.

Never allow a third party, whether a data hoster, or cloud service provider or a service provider, process personal data without putting in place a signed data processing agreement in recommended form.

Paul Foley is a solicitor admitted to practice in Ireland and in England. He has over 20 years experience in Corporate Law and Internet Law and Regulation. He has an extensive Cyber Security practice. He is published by many international publishers including Thomson Reuters (on International Trade Law). He can be contacted at paul@paufoleylaw,ie 

LinkedIn: linkedin.com/in/paulfoleylaw

Twitter: @paulfoleylaw

See more stories here.