Personal data protection in the process of developing mobile applications

The phone I am currently holding in my hand contains countless amounts of data. This small device already has built-in motion sensors (e.g., accelerometer, gyroscope), environmental sensors (barometer, magnetometer), and position sensors (proximity sensor, magnetometer, GPS) at the hardware level, which generate a wide range of personal data and metadata (e.g., precise location). You can check what sensors your smartphone has using trusted diagnostic applications available in app stores (Google Play, App Store).

Moreover, many smartphone models are equipped with fingerprint readers, cameras, and facial recognition software (biometrics), network cards, Bluetooth, and NFC. Phones can be paired with devices such as smartwatches, smart bands, and fitness trackers, which further expand the capabilities of data collection, including health data, as well as with other Internet of Things devices that can collect highly personal data related to an individual's private life (e.g., a smart home device may collect information about our habits, diet, and even record our conversations). Smartphones can independently facilitate life for people with disabilities or with the help of peripheral devices. They can also be used by children who are capable of utilizing their phones and all their functions.

Depending on the operating system, privacy settings, and installed applications, a smartphone will often contain data such as: basic identifying information, including PESEL, device data (IMEI, serial number, etc.), location, biometric data, financial data (account balance, account number, debt to the telecommunications operator), browsing history, data regarding sexual orientation and gender identity (e.g., through dating applications), health data (e.g., the mojeIKP application), criminal record information (penalty points in mObywatel), email, call history, and contact book, photos (also containing metadata), dietary preferences, highly personal information such as diaries, daily plans, calendars, as well as any data collected on social media.

Thus, a smartphone is more than just a portable computer connected to the internet. It is also a portable source of all data about a person. Therefore, manufacturers of phones and operating systems bear significant responsibility for the security of personal data. However, it should be noted that this responsibility also extends to the developers of mobile software, i.e., mobile applications, which, once installed and granted permissions by the user, may have access to many resources of the given device.

Threats to Personal Data Protection

The broad access to data and the possibility of continuous processing (depending on the settings, the application may continuously monitor certain data), as well as the number of stakeholders involved in production (investors, software houses, freelancers, third-party software, device manufacturers and their operating systems, app stores, advertisers) create a range of risks for the rights and freedoms of individuals whose data is being processed.

Among the threats to personal data protection, the following can be identified:

1. lack of transparency – many entities responsible for the application do not provide appropriate information about the processing of personal data or present it in an unclear manner;
2. lack of voluntary, specific, informed, and unambiguous user consent – in cases where user consent is required, it happens that the content of the checkbox is too general or consent is coerced;
3. lack of security measures – both the application itself and the supporting servers may be inadequately secured, resulting in a high risk of personal data breaches;
4. failure to implement the principles of purpose limitation and data minimization – application developers (knowingly or unknowingly) may collect data unnecessary for the processing purpose and excessive data;
5. failure to implement the data retention limitation principle – some applications store information on servers longer than necessary for the purpose for which they are processed;
6. access of various entities to application resources and data transfers – the application manufacturer may, knowingly or unknowingly, share application data with its subcontractors, advertising providers (including cookies and similar solutions), service providers (libraries, servers, cloud solutions), and supervisory authorities. In many cases, there may be transfers of personal data to countries where the data protection system is inadequate, and safeguards such as standard contractual clauses may not provide appropriate protection.

In this regard, developers or application owners should be aware of the above threats and strive to minimize them. However, the question arises: at what stage of application development should application creators consider personal data protection?

Privacy by design and privacy by default

According to Article 25(1) of the GDPR, the entity responsible for creating a mobile application in order to meet the requirements of the GDPR and protect the rights of individuals whose data is processed should implement appropriate technical and organizational measures at the stage of determining the methods of processing as well as during the processing itself (the temporal aspect of protection in the design phase), designed to effectively implement the principles of data protection, such as data pseudonymization and minimization (the aspect of default data protection). Data protection in the design phase should be implemented considering the state of technical knowledge, the cost of implementation, as well as the nature, scope, context, and purposes of processing and the risk of infringement of the rights or freedoms of natural persons with varying probabilities of occurrence and severity of threats arising from processing.

The above is referred to as the principle of incorporating data protection in the design phase, or privacy by design.

This principle encompasses aspects of default data protection (privacy by default); both principles intersect, mutually complement, and reinforce each other.

The principle of data protection by default is indicated in Article 25(2) of the GDPR, which states that the data controller implements appropriate technical and organizational measures to ensure that, by default, only personal data that is necessary for each specific purpose of processing is processed. This obligation pertains to the amount of personal data collected, the scope of its processing, the duration of its storage, and its accessibility. In particular, these measures ensure that, by default, personal data is not made accessible without the intervention of the data subject to an indefinite number of natural persons.

Data protection by default means that a ready product should, by default, and thus already in its factory settings, take into account the processing of only the data necessary for the purpose of processing and not for longer than is necessary.

These principles are of significant importance for mobile applications. As indicated in Recital 78 of the GDPR: “where applications, services, and products are developed, designed, selected, and used that rely on the processing of personal data or process personal data in order to fulfill their function, manufacturers of these products, services, and applications should be encouraged to take into account the right to the protection of personal data during the development and design of such products, services, and applications, and to provide data controllers and data processors with the means to comply with their data protection obligations, taking into account the state of the art.”

The European Union Agency for Cybersecurity (ENISA) in its report titled “Privacy and data protection in mobile applications” highlights privacy by design strategies, i.e., explicit architectural goals realized during the design phase within privacy, to achieve a certain level of privacy – developed based on the GDPR by Dutch researchers. These are:

1. Minimize – a strategy implementing the principle of minimization. As an example, ENISA cites limiting the application's access to the device's sensors;
2. Hide – protecting data from disclosure or unauthorized access, e.g., through default data encryption;
3. Separate – preventing data correlation through physical or logical separation;
4. Abstract – minimization of details regarding processed data through grouping or summarization. ENISA provides the example of limiting geolocation used by an application to define location more generally rather than pinpointing the device's exact location;
5. Inform – implementation of the principle of transparency; users should be adequately and transparently informed about data processing, including any changes and breaches;
6. Control – users should have control over how their data is processed – the application developer should ensure that users can express and withdraw consent, choose which data is to be processed, update data, and delete it. ENISA provides the example of a situation where a user can block the application's access to sensors and photos stored on the phone's memory. In such a case, the application developer should allow continued use of the application, even if its functionality is limited;
7. Enforce – maximum engagement should be ensured in creating, maintaining, and adhering to data processing policies. As ENISA points out, this strategy requires those responsible for the application to primarily create, maintain, and enforce a privacy policy for the application;
8. Demonstrate – implementation of the principle of accountability; the data controller should be able to demonstrate that they have adequate technical and organizational measures in place. Processing activities should be recorded, audits conducted, and appropriate reports prepared. As an example of an activity carried out under this strategy, ENISA mentions the execution and documentation of a DPIA.

The above principles and proposed strategies and tactics impose on data controllers, and indirectly also on mobile application developers, the obligation to design and configure their products in such a way that they can effectively ensure compliance with all principles regarding the processing of personal data, i.e., the principles of lawfulness, fairness and transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability.

Thus, an example of implementing the principle of transparency may involve considering UI/UX issues and access to information about processing during the design phase by enabling the user to easily access the application's privacy policy, e.g., two to three clicks using one hand (in the spirit of the three-click rule). The privacy policy should be displayed in accordance with the principles of universal design and digital accessibility. This is particularly important when the target user may be children or individuals requiring special treatment.

To achieve transparency, solutions related to layered information for data subjects can also be implemented.

Mobile Application Lifecycle and Personal Data Protection

There are various descriptions of the software lifecycle; however, in principle, the following stages can be distinguished: analysis and identification of requirements, design, programming, testing, deployment, and maintenance.

Moreover, the entity responsible for the application development process may choose from a range of software development methodologies, which will determine how to design the privacy of a given solution. In waterfall methodologies, it is possible to define the purpose and nature of processing and the requirements set by the GDPR in the context of a given solution already at the design stage, as well as to select technical and organizational measures that will effectively allow for the implementation of personal data processing principles. It seems that a more challenging task will face entities opting for agile solutions, which rely on time-limited sprints. However, this difficulty will be apparent, as agile methodologies allow for quick responses to changing circumstances and parameters, enabling the application to be adapted to current needs and threats. However, it will be necessary to appropriately define requirements/user stories and roles within the team concerning data protection. For example, the Product Owner should ensure that the principles of personal data processing take priority in the product backlog and during task execution, while the Scrum Master should be responsible for ensuring that privacy requirements are implemented in sprints and that the product complies with the GDPR.

ENISA, in its report, cites as an example of a security-focused software development methodology that can be applied within agile methodologies, the Secure Development Lifecycle for Agile Development based on the Microsoft Secure Development Lifecycle (SDL). The implementation of the SDL framework into agile methodologies will essentially involve the implementation of SDL requirements in three categories depending on the frequency of actions:

• The first category consists of requirements for each sprint – these will be security requirements, without which no application can be published (e.g., SDL requirements for the firewall, notifying the DPO of changes regarding the application's privacy);
• The next category includes requirements for the three "buckets," which are implemented regularly throughout the application lifecycle. These will generally be tasks that do not need to be completed in every sprint. From the perspective of personal data protection activities, this may include, for example, reviewing and updating personal data protection documentation;
• The final category is for activities that are performed only once during the project execution. An example in the area of data protection would be appointing a DPO and involving them in the process.

In accordance with the principles of privacy by design and privacy by default, the application developer will therefore need to consider personal data protection at every stage of application development, regardless of the adopted methodology, as well as the version of the product reaching the end user (MVP or full version of the program).

For simplicity, I will divide the mobile application lifecycle into three stages: the design stage, the execution stage, and the implementation stage. In each stage, I will indicate example activities related to IT and business processes, as well as personal data protection.

1. Area: IT/Business
2. Design Stage
   - idea
   - market research, creating a profile of the potential user
   - budgeting, securing funding,
   - selection of technology and architecture,
   - selection of methodology and contractors,
   - analyses,
   - identification of requirements and their documentation,
   - design,
   - mock-ups.
3. Execution Stage:
   - programming,
   - implementations,
   - testing,
   - content creation.
4. Implementation Stage:
   - preparation for publication,
   - publication of the application in the store (e.g., App Store, Google Play),
   - maintenance.

1. Area: Data Protection
2. Project Stage
   - risk analysis and DPIA, analysis of third-party solutions,
   - selection of technical and organizational measures to effectively implement the principles of personal data processing,
   - creation of data protection documentation,
   - identification of the scope of necessary data, purposes, and legal bases for processing, including the scope of permissions that the application must obtain (access to information stored on the device, e.g., location, camera, memory, contacts, camera, etc.), default data protection,
   - identification of privacy requirements for the app store,
   - agreements with suppliers and contractors (data processing agreements, co-administration agreements, etc.),
   - assessment of the obligation to appoint a DPO and its possible appointment and notification,
   - identification of data transfers,
   training for individuals involved in the project.
3. Execution Stage:
   - privacy policy, content of consents and checkbox privacy notices,
   - regulations,
   - conducting reviews, monitoring changes affecting the nature, scope, context, and purposes of processing and the risk of infringement of the rights or freedoms of natural persons,
   - finalizing data protection documentation,
   - testing application security,
   - testing solutions related to the exercise of data subjects' rights,
   - informing the DPO of changes in privacy matters.
4. Implementation Stage:
   - conducting reviews, monitoring changes affecting the nature, scope, context, and purposes of processing and the risk of infringement of the rights or freedoms of natural persons,
   - updating the privacy policy,
   - testing,
   - exercising data subjects' rights,
   - monitoring and handling data breaches.

Other Legal Requirements Regarding the Security and Transparency of Mobile Applications

In addition to the general requirements imposed by the GDPR, mobile applications may also be subject to specific regulations that impose particular obligations on entities responsible for the applications.

Regarding the regulations that private entities will be subject to, it is worth noting:

• Regulation of the Minister of Health of December 17, 2020, on the detailed organizational and technical conditions that mobile applications for transmitting data contained in information about issued prescriptions and the method of exchanging information in electronic form between the Internet Patient Account and mobile applications should meet (Journal of Laws of 2020, item 2330), in which the legislator indicates the requirements that the application should fulfill, through which the user can receive information about the issued prescription in electronic form,
• Regulation of the Minister of Digital Affairs of May 28, 2020, on the mobile application for settling the fee for the transport of persons (Journal of Laws of 2020, item 954), which establishes, among other things, minimum security requirements for applications supporting the provision of services in the field of mediation in the transport of persons;

In terms of regulations concerning entities from the public sector, it is necessary to indicate:

• Articles 19e – 19i of the Act of February 17, 2005, on the computerization of the activities of entities performing public tasks (Journal of Laws 2005 No. 64, item 565, as amended), which establish the "public mobile application," i.e., the application known as "mObywatel";
• The Act of April 4, 2019, on the digital accessibility of websites and mobile applications of public entities (Journal of Laws of 2019, item 848, as amended), which imposes on public entities the obligation to ensure digital accessibility in mobile applications by referring to the requirements contained in the annex to the Act, which must meet the criteria specified in points 9, 10, and 11 of the EN 301 549 V2.1.2 standard, which refers to the WCAG 2.1 standard. These provisions are of great importance in the context of the principle of transparency, as they require that mobile applications of public entities be digitally accessible, i.e., meet the principles of functionality, compatibility, perceivability, and understandability.

The last Act contains – as it seems – the only legal definition of a mobile application in Polish law: "publicly available software with a touch interface designed for use on portable electronic devices, excluding applications intended for use on portable personal computers."

Summary

In the process of developing a mobile application, personal data protection should permeate every stage of the application lifecycle – from the inception of the idea to its publication in the app store, and subsequently its maintenance. The entity responsible for the application, to which we can attribute the role of data controller, should be aware of the threats present in the mobile ecosystem, as well as the requirement to incorporate data protection by design and by default.