Apps - GDPR Compliance and Privacy Notice Checklist

This post provides a guideline to ensure compliance with the General Data Protection Regulation (GDPR) when developing Apps and for drafting Privacy Notices (i.e. Privacy Policy) for Apps.

This Checklist is not exhaustive. Each App needs to be reviewed individually before being published in an App-Store.

1.    Development / Design Phase

1.1.    General

For all personal data collected and processed through the app it must be documented internally:

1. What type of data is collected?
2. For what purpose is each type of data used and necessary?
3. When and how is each type of data deleted?
4. Is it possible to give the user access to (a copy of) his or her data within latest 30 days?
5. What third party tools/SDK/services are used?

1.2.    Data Input Forms

1. Data Input forms may only collect information that is strictly necessary for the specific purpose (e.g. newsletter registration form does not require name or birthday)-
2. It must be clear to the user whether a field is optional or mandatory.
3. It must be clear to the user for which purpose the information of each field is used. In case of doubt, a tooltip should inform about the use purpose and/or link to the privacy policy. (e.g. birthdate is used to determine age since minimum age to use service is 16).

1.3.    Login / Registration

If the App provides for registration and account login functionality the following must be complied with:

1. Upon registration the user must be made aware that he accepts the “terms and conditions” of the app/service. The user must be able to read and save the terms and conditions.
2. A link to the privacy policy should be included on the registration page. Important note: The user may not be asked to agree to the Privacy Policy in whole.
3. If the user email shall be used for marketing purposes this generally (with few exceptions) requires additional prior explicit consent.
4. User email address should be validated through double opt in (individual link sent to user by email) to ensure that the user is owner of the given email address.
5. The user must be able to delete a user account. Upon deletion of the account and or app, user data on the device must be deleted (also user data stored on SD cards). Data stored on the company’s server must be deleted also, except the company is obliged to keep the data for a longer period.

1.4.    Privacy Notice:

1. Each App must have its own specific privacy notice (see below). It is not sufficient to link to the general Privacy Notice of the company’s website.
2. The Privacy Notice must be accessible from within the App (e.g. menu “Legal” – “ Privacy Notice”)
3. In the App Store a link to the Privacy Notice must be placed, so that users can read it prior to downloading and installing the app.

1.5.    Tracking, Analytics and Ad SDKs (Software Development Kits)

1. If the app uses third party SDKs for tracking, analytics or marketing/advertising (e.g. Adobe Analytics, Google Analytics, Crashlytics, Google Mobile Ads, AdMob or similar), such code may only be activated after the user have given his explicit prior consent. Prior to or without such consent, no connection to third party services or servers may be established by the app. Consent language, consent banner and consent logging must be reviewed by the legal department.
2. Users must be able to withdraw their consent at any time (e.g. through the “Settings” menu of the app)-
3. Consent and withdrawal of consent must be logged by the company (server-sided)-

1.6.    Other Third Party DSK:

Any other Third Party SDK that establishes a connection to a third party service or server (e.g. to provide map or video functionality, social media plugins, payment service providers) may be integrated only after prior approval by the legal department.

1.7.    OS Permissions

1. The App may only request such permissions (camera, location, address book/contacts, microphone, etc.) that are necessary to enable the service of the app. It must be clear for the user, when such permission is used and for which purposes it is used (e.g. “access to camera is used when users want to scan QR-Code”).
2. Location data should be collected only when necessary and for the period of time (interval of location collection) necessary. Where possible location data should be blurred (e.g. instead of the exact location only the postal code/area/country is stored). Historic location data may be stored only if strictly necessary for the service, Users should be made aware when location data is collected and should be able to opt-out.

1.8.    Further Requirements

1. Access to device identifiers such as IMEI or UDID, IMSI, MAC-address MSISDN or similar require prior approval by the legal department.
2. If an in-app browser is used, the user must be made aware of the privacy policy of the website displayed in the in-app browser.
3. IP-addresses should be stored in shortened form only, except there is a strict need to store full IP addresses. If full IP addresses are stored, the storage period should be clearly defined (e.g. 7 days).

1.9.    Data Security

(not exhaustive, based partly on information provided by the Bavarian data protection authority)

1. Communication (data transfer) with between the app and the backend must be encrypted.
2. If the app implements a user account with password and username, the following security aspects should be considered (not mandatory):

• Does the service have sufficient HTTPS encryption to protect the personal data?
• Does the service explain to the user how to choose a strong password?
• What is the minimum length required for a password?
• Is a strong password "forced" by the service or can a user also use a weak password?
• Is the user shown the strength of his chosen password (e.g. password quality bar)?
• Is the user also offered a multi-factor authentication (e.g. via SMS code or device identification) if sensitive data is involved?
• Does the user receive an e-mail to successfully confirm the e-mail address stored in the account (possibly with URL token) and to complete the registration?
• Will the user be informed whether there were failed logins and whether other devices are logged in (i.e. further sessions are active)?
• Is the existing (old) password queried again by the user when the password is changed?
• Is the user informed about a password change by e-mail?
•  Does the password forget function send an e-mail with a temporary valid URL to the user's stored e-mail address?
• Is data in rest (i.e. that is stored locally on the device) sufficiently encrypted / protected?
• Are access data transformed with a cryptographic method suitable for password storage (e.g. KeyChain for iOS, PBKDF2 for self-implementation) before they are stored locally?
• Are passwords masked (possibly selectable) when they are entered in the app to prevent "shoulder-surfing"?
• Is data transmission encrypted (with HTTPS)?
• Is Perfect Forward Secrecy used with HTTPS?
• Is it prevented that personal data is transferred via HTTP-GET parameters?
• Are trustworthy SSL certificates used and are they also checked to prevent man-in-the-middle attacks?
• Is SSL pinning (fixed "wiring" of the SSL Certificate in the app) used?
• Are token values used instead of account data (e.g. customer number) for a session reference to the backend?
• Is the back end sufficiently protected against attacks based on OWASP Top 10 (2013)?
• Can the backend web server be accessed via HTTP instead of HTTPS (e.g. SSL stripping attack)?
• Is a (JSON) SSLStrip attack possible?

Short checklist for using TLS

• TLS1.2 only (No more SSL3, TLS1.0, TLS1.1)
• only cipher suites that support Perfect Forward Secrecy
• SSL pinning (public key pinning is recommended, exceptionally also CA pinning)
• selection of a trustworthy certificate authority
• certificates with 4096-bit RSA
• no SHA-1 when signing certificates (instead, at least SHA-256)
• no outdated cryptographic algorithms (e.g. RC4, DES, ...)
• no support of http on the same server (danger of SSL stripping attacks)
• current and systematic patch management (e.g. due to heartbleed, poodle, CCS attacks) of the SSL components
• TLS client certificates to make man-in-the-middle attacks more difficult

2.    Information in Privacy Notices (Privacy Polices)

Privacy notices for apps must be designed specifically for the respective app. It is not sufficient to use the company’s general website privacy policy.

The privacy notices must be accessible form within the app and from the download/installation page of in the App store.

Privacy Notices must in particular contain the following:

1. Name and the contact details (address, email, phone) of the company responsible for the data processing of the app (data controller)
2. Contact details of the data protection officer, if any, of such company (e-mail address sufficient)
3. For each type of personal data processed by the app (e.g. profile data, order data, payment data, tracking data/analytics data):

• Description of type of data
• Use purpose (e.g. fulfill payments)
• Legal basis for processing (according to Art 6 GDPR), e.g. consent or fulfillment of a contract, balance of interest (in latter case the interests pursued by the company must be stated e.g. “improving of app security by identifying unauthorized access attempts”).
• recipient of the data (category or where possible company names), including third party service providers, hosters (e.g. AWS, Google, affiliated companies)
• storage period of the data (or the criteria to determine that period)
• whether the provision of the data is required and possible consequences of failure to provide such data

Privacy Notices must also contain the following information:

1. If data is transferred to non-EU countries: name of country and which data export mechanism is used (e.g. EU standard contractual clauses)
2. existence of automated decision-making, including profiling, if any
3. Information on rights of data subjects (right to withdraw consent, lodge a complaint with a supervisory authority, access to and rectification or erasure of personal data, restriction of processing, object to processing as well as the right to data portability)
4. App permissions: what permissions are required (under each OS platform), when are permission used and for which purpose (e.g. access to camera is used, when users want to scan QR code)
5. Privacy Notice must answer the following questions (if applicable):

• How is email address used?
• How can a user account be deleted?
• How are push notifications used?
• How are IP addressed used?
• How are device identifiers used?
• Is data stored locally on the device or remote at a backend/third party server)

The Privacy Notice must be in concise, transparent, intelligible, and easily accessible form, using clear and plain language.

A layered approach is recommended: relevant information is provided directly in the user interface / input forms (e.g. profile picture upload field contains tooltip informing the use purpose and who can see the picture). More detailed information is contained in the privacy notices document. Lengthy privacy notices should include a summary of the most important aspects, or each section is summarized and details for each section is shown under a “see more” button/link.