Using MDS Under GDPR

Article 4.1 GDPR defines personal data as “any information relating to an identified or identifiable natural person […]; an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”.

Recital 26 GDPR adds that “[t]o determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments”.

Therefore, to determine whether a given dataset must be considered personal data, one must conduct a “Reasonable Reidentification Test”, i.e. consider whether it is reasonably likely that someone may access the dataset and use it in such a way that it relate to a given identifiable individual, taking into accounts “all the means reasonably likely to be used” and possible evolution of the available technology. If the conclusion of the test is positive, then the dataset must be considered personal data and is subject to GDPR; conversely, if the conclusion is negative, then the dataset may be considered anonymous data, and as such is not subject to GDPR.

This methodology is exemplified in the ECJ’s case law¹ and guidance from data protection authorities², which specify that “means reasonably likely to be used” to reidentify the data subject include other datasets which are reasonably likely to be combined with the considered dataset, and unlawful means (e.g. database hacking) as well as lawful means (e.g. a court order to obtain additional datasets)³.

Directly identifying vs indirectly identifying personal data: Supervisory authorities distinguish between data which is in itself sufficient to reidentify a data subject (directly identifying personal data) and data which allows for such reidentification only when combined with other information (indirectly identifying personal data, or pseudonymized data). Although in both cases, GDPR applies, authorities consider that when personal data is only indirectly identifying, “the application of [GDPR] will justifiably be more flexible than if information on directly identifiable individuals were processed”⁴.

Supervisory authorities already applied this definition and the Reasonable Reidentification Test to mobility data in various opinions and guidelines (although only in the case of personal vehicles and devices – never in the case of shared vehicles)⁵.

Under their analysis, any data that can be related to the driver “by cross-referencing with other files and especially the vehicle identification number (VIN)”, including technical “metadata” such as “vehicle maintenance status” is to be considered indirectly identifying personal data, and as such is subject to GDPR⁶. Conversely, anonymizing mobility data requires, at a minimum, “suppressing any link between usage data and the considered vehicle serial number in a non-reversible manner”⁷.

This line of reasoning appears to apply to shared vehicles as well as to personal vehicles.
Indeed, vehicle unique IDs can be used to ask mobility operators (as necessary through a court order as in the 2016 Breyer case⁸) to provide the respective rider’s details (e.g. their name or email address), in order to reidentify them – such being considered “means reasonably likely to be used” as per Recital 26 GDPR.

However, when the vehicle ID is randomized in a non-reversible manner, the resulting randomized ID will not allow for reidentification of the rider if it cannot be retraced to the ID initially attributed to the vehicle by the mobility operator who holds the rider’s details (“native vehicle ID”, such as contained in the device_id and vehicle_id fields⁹).

Therefore, MDS users must consider that native vehicle IDs and any data associated therewith (including technical data about the vehicle) are personal data within the meaning of GDPR.

Supervisory authorities’ guidance also raises the question whether location data alone (i.e. not associated with a native vehicle ID) should be considered personal data.

In guidelines relating to personal vehicles, supervisory authorities have assumed that this is the case¹⁰. Their reasoning is based on the premises (i) that recurring mobility patterns may be observed in location data of a given vehicle and (ii) that such recurring mobility patterns are those of a single individual (the vehicle owner or user), so that (iii) observing such mobility patterns may reveal personal data such as that owner’s or user’s home address or workplace¹¹.

Those premises are generally not verified in the case of shared vehicles. Indeed, (i) those are, by definition, shared by large numbers of different riders and (ii) they generally are not picked up in closest proximity to the rider’s home address; therefore, (iii) there is no reason to assign two similar or even identical trips to a same single rider, nor does it seem reasonable to search for home addresses or workplaces in location data relating to a given vehicle.

However, in low-density environments, it is possible that vehicles may be singled out based on location data only, by looking up the vehicle ID of the vehicle spotted on a given location on a given date and time (timestamped GPS data).

In such a case, as explained above, a mobility operator (and any person or entity who could order it to provide this information) could also look up the identity of any rider associated with the vehicle, e.g. the last person who rode the vehicle¹².

Therefore, a cautious approach is to consider single vehicle location data as personal data as well.
Location data may however be anonymized by aggregating it in such a way that no single vehicle can be individualized anymore (see Question 1.4).

As a conclusion:

• MDS datasets which include native vehicle IDs are to be considered personal data and are, as such, subject to GDPR. This means that any data which is associated with a given native vehicle ID in a dataset is also personal data.
• It is also recommended to treat single vehicle location data as personal data, especially in low-density environments where such location data may be sufficient to single out a given vehicle.

Based on the foregoing, MDS users may reasonably consider that:

• Data pushed/collected through the Metrics, Policy, Geography and Jurisdiction APIs does not contain any personal data, and therefore is not subject to GDPR.
• Data pushed/collected through the Agency and Provider APIs, inasmuch as it contains the vehicle_id or device_id fields or single vehicle location data, is personal data, as recipients of such data may use it to obtain information relating to a given rider, through means deemed reasonably likely to be used such as a court order against the respective operator.
• However, data pushed/collected through the Agency and Provider APIs, where it does not contain the vehicle_id or device_id fields or single vehicle location data, is not considered personal data, as without such data recipients are not reasonably likely to be able to reidentify a given rider.

This general conclusion may be refined on a case-by-case basis, as the specific circumstances in which MDS data is shared/used may vary. MDS users should especially consider local legislation (whether they can get a court order against an operator to obtain riders’ information), available data processing techniques (which may come to a state where it is possible to reidentify riders of shared vehicles based on aggregated location data, e.g. by disaggregating it) and other specific circumstances (such as the likelihood of a data breach revealing riders’ information with associated vehicle IDs).

---

¹ See esp. Breyer v. Bundesrepublik Deutschland, ECJ, October 19th 2016, C‑582/14

² WP29’s opinion 4/2007 on the concept of personal data

³ In the 2016 Breyer case above, the ECJ held that IP addresses contained in connection logs of a website are personal data for the reason that the website owner may obtain a court order to oblige Internet Service Providers to provide them with the names of the holder of the considered IP address. Such a court order was considered a mean reasonably likely to be used to reidentify the data subject (i.e., in that case, the holder of the IP address).

⁴ WP29’s opinion 4/2007 on the concept of personal data, p.18

⁵ See EDPB’s Guidelines 01/2020 on processing personal data in the context of connected vehicles and mobility related applications (final version); CNIL’s Compliance framework on connected vehicles and personal data; WP29’s Opinion 03/2017 on processing personal data in the context of Cooperative Intelligent Transport Systems (C-ITS) and WP29’s Opinion 13/2011 on geolocation services on smart mobile devices. The EDPB recognizes that “data processing in the context of commercial vehicles used for professional purposes (such as public transport) and shared transport and MaaS solutions may raise specific considerations which fall out of the scope of [these existing] guidelines”.

⁶ EDPB’s Guidelines 01/2020 on processing personal data in the context of connected vehicles and mobility related applications (final version), §29 : “Much of the data that is generated by a connected vehicle relate to a natural person that is identified or identifiable and thus constitute personal data. For instance, data include directly identifiable data (e.g., the driver’s complete identity), as well as indirectly identifiable data such as the details of journeys made, the vehicle usage data (e.g., data relating to driving style or the distance covered), or the vehicle’s technical data (e.g., data relating to the wear and tear on vehicle parts), which, by cross-referencing with other files and especially the vehicle identification number (VIN), can be related to a natural person. Personal data in connected vehicles can also include metadata, such as vehicle maintenance status. In other words, any data that can be associated with a natural person therefore fall into the scope of [GDPR]”.

⁷ CNIL’s Compliance framework on connected vehicles and personal data, p.25

⁸ Breyer v. Bundesrepublik Deutschland, ECJ, October 19th 2016, C‑582/14

⁹ Such vehicle ID may be a “license plate” as well as a purely digital ID. What is crucial is that it is attributed by the operator who holds riders’ details, so that said operator may find and (if asked or ordered to do so) provide information relating to a rider based on a given vehicle ID.

¹⁰ See EDPB’s Guidelines 01/2020 on processing personal data in the context of connected vehicles and mobility related applications (final version), §63; CNIL’s Compliance framework on connected vehicles and personal data, p.26; WP29’s Opinion 03/2017 on processing personal data in the context of Cooperative Intelligent Transport Systems (C-ITS), p.6 and WP29’s Opinion 13/2011 on geolocation services on smart mobile devices, pp.7, 9 and 10.

¹¹ See esp. WP29’s Opinion 05/2014 on anonymization techniques, p.31: “The mobility patterns of human beings […] may be sufficiently unique that the semantic part of location data (the places where the data subject was at a specific time), even without other attributes, is capable of revealing many traits of a data subject.”

¹² A parallel may be drawn with WP29’s analysis of geolocation through MAC addresses of Wifi access points: WP29 recognizes that such MAC addresses may be shared by so many different peoples that they are unlikely to allow identification of a single individual, so that they should not considered personal data within the meaning of GDPR. (WP29’s Opinion 13/2011 on geolocation services on smart mobile devices, p.11: “In very densely populated areas, even with the help of signal strength information, the MAC address will point to several apartments as the potential access point location. In these circumstances it is not possible without unreasonable effort to ascertain precisely the individual living in the apartment where the access point is located.”)

It all depends on the purposes, extent and other modalities of such collection and processing.

GDPR does not prohibit collecting and processing personal data¹³. Quite the contrary, it is explicitly about enabling the free flow of personal data – provided that appropriate guarantees are applied to preserve individuals’ privacy.

Those appropriate guarantees include making sure that:

• Personal data is collected and processed for specified, explicit and legitimate purposes (purpose limitation) (see Question 2.1), is adequate, relevant and limited to what is necessary in relation to those purposes (data minimization) (see Question 2.2), is accurate and up to date (data accuracy) and is deleted or anonymized when it is not necessary anymore for the contemplated purposes (storage limitation) (see Question 2.3) (Article 5 GDPR).
• The processing of personal data has a legal basis (Article 6 GDPR) (see Question 2.7).
• Data subjects are informed in a transparent manner about the processing of their data and are able to exercise their rights in relation to their data (Articles 12-14 GDPR) (see Question 2.5).
• Compliance of the processing is documented appropriately (Articles 24, 30 and 35 GDPR) (see Question 2.11).
• Appropriate agreements are in place with the persons/entities who access or process the data (Articles 26 and 28 GDPR) (see Question 2.9).
• Security and confidentiality of the data are ensured through appropriate technical and organizational measures (Article 32 GDPR).
• Where mandatory or advisable, a Data Protection Officer (DPO) is appointed (Articles 37 seq. GDPR) (see Question 2.12).
• If applicable, transfers of data to non-EEA countries are secured with appropriate measures (Articles 44 seq. GDPR) (see Question 2.13).

Further guidance on those requirements and how to comply with each of them is provided under Part II “How to comply in practice” below.

---

¹³ See Recital 13 GDPR (“The proper functioning of the internal market requires that the free movement of personal data within the Union is not restricted or prohibited for reasons connected with the protection of natural persons with regard to the processing of personal data.”) and the full title of GDPR (“Regulation […] on the protection of natural persons with regard to the processing of personal data and on the free movement of such data”).

Personal data within the meaning of Article 4.1. GDPR is “any information relating to an identified or identifiable natural person […]; an identifiable natural person is one who can be identified, directly or indirectly” (see Question 1.1).

The only consequence of having a given dataset qualify as personal data is that it is subject to the requirements of GDPR. Collecting or processing such personal data is not prohibited – it must only be done in compliance with GDPR principles and appropriate guarantees.

“Sensitive data” refers to specific subsets of personal data.

Strictly speaking, sensitive data only covers “data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership […]; genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health [and] data concerning a natural person’s sex life or sexual orientation” (Article 9.1 GDPR).

In a broader meaning, sensitive data may also refer to offence-related data within the meaning of Article 10 GDPR, i.e. “personal data relating to criminal convictions and offences or related security measures”.

Such sensitive personal data and offence-related data are subject to specific, additional requirements within the general realm of personal data¹⁴.

Therefore, not all personal data is sensitive data. GDPR recognizes that all types of personal data are not equally sensitive, and allows for a flexible, risk-based approach, with different appropriate guarantees to be chosen and applied depending on the varying level of sensitivity of the personal data processed.

Based on the definitions above, no MDS data is to be considered “sensitive” in itself within the meaning of Article 9.1 GDPR¹⁵.

Indeed, MDS data does not contain any “data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership […], genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health [or] data concerning a natural person’s sex life or sexual orientation”.

Although supervisory authorities often consider that location data may be used in a way that reveals sensitive personal data (e.g. where it reveals that someone regularly drives their car to a given place of worship, thereby revealing their religious beliefs)¹⁶, it is reasonably not the case with shared vehicles, which because of their shared nature generally do not allow to observe recurring mobility patterns of a single individual.

Under which circumstances MDS data may qualify as offence-related data, however, is more ambiguous.

In a first version of its guidelines on connected vehicles, the European Data Protection Board held that personal data may qualify as offence-related data either (1) because it is used to detect, prosecute and/or sanction criminal offences or (2) because it reveals facts that could qualify as a criminal offence under applicable criminal law. This resulted in a very large scope: for instance, the EDPB held that location data of a vehicle qualifies as offence-related data merely because it reveals that a criminal offence (e.g. crossing a white line) has been committed, regardless of whether the data is actually processed to detect/prosecute this offence¹⁷.

According to this analysis, MDS users who collect single vehicle location data should treat it as offence-related data wherever road offences (e.g. crossing a white line, unauthorized parking, etc) are sanctioned by criminal law¹⁸. This would result in high restrictions as Article 10 GDPR states that such offence-related data may be processed “only under the control of official authority or when the processing is authorized by Union or Member State law providing for appropriate safeguards for the rights and freedoms of data subjects”19.

However, the EDPB appears to have softened its analysis, as the final version of its guidelines only refers to offence-related data as data processed “for the purposes of criminal investigation and prosecution of criminal offence”.

This can be interpreted as meaning that supervisory authorities do not consider personal data should qualify as offence-related data merely because it reveals facts that could qualify as a criminal offence under applicable criminal law.

Therefore, MDS users who collect and process single vehicle location data should be able to do so regardless of the restrictions under Article 10 GDPR, as long as they do not process such data with the aim of identifying, investigating or prosecuting criminal offences²⁰.

If they process the data to such aims (i.e. identifying, investigating or prosecuting criminal offences) then they must consider whether such processing meets the requirement of Article 10 GDPR, i.e. especially whether it is carried out “under the control of [an] official authority” such as a city or transport authority.

---

¹⁴ Collecting/processing sensitive personal data within the meaning of Article 9.1 GDPR is only authorized in a limited number of situations, listed under Article 9.2 GDPR. Collecting/processing offence-related data is lawful “only under the control of official authority or when the processing is authorized by Union or Member State law providing for appropriate safeguards for the rights and freedoms of data subjects” (Article 10 GDPR).

¹⁵ However, MDS data could be combined with sensitive data (for instance where a MDS user also has access to the names and political opinions of riders and decides to combine those different datasets). Such a situation lies outside the scope of this guidance; in any case, it should be subject to a very strict data protection impact assessment (see Question 2.11).

¹⁶ EDPB’s Guidelines 01/2020 on processing personal data in the context of connected vehicles and mobility related applications (final version), §63

¹⁷ EDPB’s Guidelines 01/2020 on processing personal data in the context of connected vehicles and mobility related applications (first version), §64: “It is possible that personal data from connected vehicles could reveal the commitment of a criminal offence or other infraction (“offence-related data”) and therefore be subject to special restrictions. For instance, the instantaneous speed of a vehicle combined with precise location data or data indicating that the vehicle crossed a white line could be considered offence-related data. As a result, processing of such data can only be carried out under the control of official authority or when the processing is authorized by Union or Member State law providing for appropriate safeguards for the rights and freedoms of data subjects as stated in art. 10 GDPR.” This initial stance was in line with that of the French supervisory authority, as expressed in its own compliance framework on connected vehicles (CNIL’s Compliance framework on connected vehicles and personal data).

¹⁸ Conversely, where such road offences are not sanctioned by criminal law under the considered country’s domestic laws, the related data should not be qualified as offence-related data as defined by Article 10 GDPR.

¹⁹ EDPB’s Guidelines 01/2020 on processing personal data in the context of connected vehicles and mobility related applications (final version), §§56 et 68: “Furthermore, data collected by connected vehicles may be processed by law enforcement authorities to detect speeding or other infractions if and when the specific conditions in the law enforcement directive are fulfilled. In this case, such data will be considered as relating to criminal convictions and offences under the conditions laid down by art. 10 GDPR and any applicable national legislation. […] Indeed, some categories of personal data from connected vehicles could reveal that a criminal offence or other infraction has been or is being committed (“offence-related data”) and therefore be subject to special restrictions (e.g., data indicating that the vehicle crossed a white line, the instantaneous speed of a vehicle combined with precise location data). Notably, in the event that such data would be processed by the competent national authorities for the purposes of criminal investigation and prosecution of criminal offence, the safeguards provided for in art. 10 GDPR would apply.” The final version of these guidelines was adopted after a public consultation where some stakeholders underlined that the scope of offence-related data as initially envisaged by the EDPB was too broad and against the provisions of Article 10 GDPR itself.

²⁰ Note that there is a specific regime for competent authorities (e.g. police authorities) who use MDS data to identify, investigate or prosecute criminal offences: such competent authorities are subject not to GDPR but to the Law Enforcement Directive (LED) (see Question 1.6).

Anonymized (or anonymous) data is “information which does not relate to an identified or identifiable natural person or [which was] rendered anonymous in such a manner that the data subject is not or no longer identifiable” (Recital 26).

Thus, anonymous data means the opposite of personal data. It is not subject to GDPR and other privacy and data protection laws and regulations.

As explained under Question 1.1, determining whether a given dataset is personal data or anonymous data depends on a Reasonable Reidentification Test, i.e. assessing whether the dataset, alone or in combination with others, taking into account “all the means reasonably likely to be used”, may be related to an identified or identifiable individual.

There are different ways in which MDS datasets could be anonymized. At a minimum, this requires removing or randomizing native vehicle IDs (i.e. vehicle IDs assigned by the mobility operator who holds the riders’ details) in a non-reversible way²¹ and aggregating location data relating to individual vehicles in such a way that no vehicle may be singled out anymore.

As they depend on the then-current state of the art and the peculiar circumstances of the processing (including other available information that may be combined with the considered dataset), anonymization techniques are to be assessed on a case-by-case basis, with an aim at making sure that no portion of the resulting dataset may be retraced to an identifiable individual – even indirectly, even in combination with other datasets. In this respect, any appropriate anonymization technique must be non-reversible²².

In particular, the appropriate aggregation threshold to reach proper anonymization will depend on many factual circumstances, including the volume of aggregated data, the geographical area and number of vehicles covered and the then-current state of available technology (which will determine what falls within the scope of “means reasonably likely to be used”).

It is the responsibility of the data controller (see Question 1.8) to check (and be able to demonstrate) whether the contemplated aggregation techniques are so that no vehicle may be singled out in the resulting aggregated dataset.

It is worth reminding that anonymization is in no way a prerequisite under GDPR.

GDPR does not prohibit the collection or processing of non-anonymized data (i.e. personal data). It actually provides for many situations where such collection and processing is perfectly valid and legitimate.

Therefore, MDS users should consider whether they need anonymized or non-anonymized MDS data depending on the goal they wish to achieve. Certain legitimate purposes will require non-anonymized MDS data (e.g. monitoring individual vehicles) whereas some other purposes may be fulfilled using anonymized data only (e.g. statistics about the use of mobility services).

---

²¹ CNIL’s Compliance framework on connected vehicles and personal data (p.25)
²² For guidance on technical aspects of anonymization techniques, see WP29’s Opinion 05/2014 on anonymization techniques.

GDPR applies to EU-based entities who process personal data within the meaning explained above. In certain very specific cases, it also applies to non-EU based entities who process personal data relating to individuals located in the EU.

Legal Justification:

GDPR applies to any processing of personal data “in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not” (Article 3.1 GDPR).

It also applies to the processing of personal data “of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to (a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or (b) the monitoring of their behaviour as far as their behaviour takes place within the Union” (Article 3.2 GDPR).

In other words, MDS users must comply with GDPR when they process (or commission someone to process) MDS data which qualifies as personal data (see Question 1.1) and

• They (and/or the person they have commissioned to process the data) are based or have an establishment in the EU (e.g. EU cities; EU-incorporated mobility operators and mobility data solution providers); or
• They use MDS data to offer goods or services to data subjects located in the EU or to monitor the behavior of such data subjects in the EU (e.g. non-EU incorporated companies who use MDS data to monitor mobility in an EU city).

This means that EU-based entities must comply with GDPR even when processing MDS data that relates to vehicles located outside of the EU (e.g. EU-incorporated companies who use MDS data to monitor mobility in US cities).

On the other hand, non-EU based entities who use MDS data will generally not be subject to GDPR. They will only be subject to GDPR if, for some reason, they use MDS data to monitor the behavior of individuals located in the EU or to offer goods or services to such individuals²³. However, if they commission a EU-based mobility data solution provider to process the data on their behalf, such provider must comply with GDPR – as it is established in the EU²⁴.

Post-Brexit UK and GDPR: As the United Kingdom is no longer part of the EU, entities based in the UK are only subject to GDPR if they use MDS data to monitor the behavior of individuals located in the EU or to offer goods or services to individuals, as explained above. Brexit also means that the UK is now considered a “third country” within the meaning of GDPR, so that data transfers from the EU to the UK are subject to additional requirements. As of today, such EU-UK data transfers are authorized by an adequacy decision from the European Commission, as this decision deemed that the UK provides an adequate level of protection of personal data.

---

²³ Note that the criterion here is that of the location of data subjects – not their nationality or residence. This means that GDPR does not apply when a non-EU municipality processes personal data relating to EU citizens who are on its territory (e.g. EU tourists in a US city).

²⁴See EDPB’s Guidelines 3/2018 on the territorial scope of the GDPR, p.12: “In the case of a data processor established in the Union and carrying out processing on behalf of a data controller established outside the Union and not subject to the GDPR as per Article 3(2), the EDPB considers that the processing activities of the data controller would not be deemed as falling under the territorial scope of the GDPR merely because it is processed on its behalf by a processor established in the Union. However, even though the data controller is not established in the Union and is not subject to the provisions of the GDPR as per Article 3(2), the data processor, as it is established in the Union, will be subject to the relevant provisions of the GDPR as per Article 3(1).”

Another important EU data protection regulation is the Law Enforcement Directive (Directive (EU) 2016/680 of April 27th 2016) (“LED”).

It applies to the processing of personal data by “competent authorities for the purposes of the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties, including the safeguarding against and the prevention of threats to public security” (Article 1.1 LED).

When processing personal data for such purposes, competent authorities must not apply GDPR: they must apply those provisions of their country’s domestic laws which transpose the LED²⁵.

Although it was not originally designed for such purposes, MDS data may be used by police services to document criminal offences such as road traffic offences committed by drivers (e.g. speeding or parking offences), as defined in the applicable domestic criminal law. Provided that the processed MDS data qualify as personal data (see Question 1.1), LED will apply to those situations instead of GDPR.

Note that this generally does not cover cities’ enforcement of regulations imposed on mobility operators (as opposed to drivers), as such regulations are generally not sanctioned by criminal penalties.

Principles of the LED are mostly similar to those of the GDPR. LED contains additional requirements such as an obligation to make a clear distinction between “personal data based on facts” (such as MDS data) and “personal data based on personal assessments” (e.g. of a police officer involved in the investigation) (Article 7 LED), and between the various categories of data subjects (suspects, convicted persons, victims, other parties to a criminal offence) (Article 6 LED); competent authorities must keep logs of any collection, alteration, consultation, disclosure including transfers, combination and erasure of personal data (Article 25 LED). It also allows Member States to provide limitations to certain rights of data subjects, such as the right to information.

As a directive, the LED had to be transposed into the various Member States’ domestic laws, with possible variations from one Member State to another. Therefore, competent authorities within the meaning of LED who use MDS data must look into their domestic laws for those provisions which transpose and adapt LED locally.

---

²⁵ As a EU directive, LED is not directly enforceable – it must be transposed in each Member State’s domestic laws.

GDPR is an EU regulation. As opposed to a directive, a regulation is directly enforceable in all EU Member States, without a need to be transposed in each Member State’s domestic law.

Therefore, complying with GDPR should be enough to collect and process MDS data in all the EU.

However, certain domestic laws/regulations (such as local open data regulations) may need to be taken into account when assessing certain aspects of GDPR compliance such as the legal basis for the processing (e.g. whether there exists a legal obligation for the city to collect MDS data – see Question 2.7).

MDS users should also consider checking guidance from the supervisory authority of the Member State in which they are incorporated, as this authority may qualify as their lead authority for the purpose of GDPR compliance control and proceedings, and different supervisory authorities may make slightly different assessments of the same situation ²⁶.

Also, as explained under Question 1.6, competent authorities who use MDS data for the prevention, investigation, detection or prosecution of criminal offences or the execution of criminal penalties are subject to the Law Enforcement Directive (LED) instead of GDPR; therefore, they must comply with those provisions of their domestic laws which transpose and adapt the LED.

Practitioners may also wonder whether the processing of MDS data is subject to EU directive colloquially known as the “ePrivacy Directive”.

The ePrivacy Directive is a 2002 directive (revised in 2009) about the processing of personal data and the protection of privacy in the electronic communications sector (Directive 2002/58/EC).

It applies cumulatively with GDPR in certain specific situations, namely:

• When location data is processed by an electronic communications service provider or network operator (Article 9 of the Directive); and
• When electronic communications networks are used “to store information or to gain access to information stored in the terminal equipment of a subscriber or user” (Article 5.3 of the Directive)²⁷.

In both cases, the Directive requires that, in principle, the user’s consent be collected. MDS users may wonder whether they need to apply this Directive and obtain such consent.

In general, this Directive will not apply to the collection or processing of MDS data, as:

• MDS users are generally not electronic communications service providers or network operators within the meaning of the Directive.
• MDS data is not “stored in the user’s terminal equipment”:
  • MDS data is not “stored” in the vehicle or derived from data stored in the vehicle. Rather, it is partially derived from raw data emitted by the vehicle through a GPS chip.
  • Plus, in general, shared vehicles should not be considered users’ terminal equipment within the meaning of the Directive. Indeed, the rationale of the ePrivacy Directive is to protect users’ terminal equipment inasmuch as it is “part of the private sphere of the[se] users” (Recital 24 of the Directive); this implies that there is a close connection between the user and the protected equipment (e.g. that the user is the owner of that equipment). In the case of shared vehicles, by definition, there is no such connection, as (i) vehicles are used by a virtually unlimited number of users and (ii) a single user is not expected to use the same vehicle regularly. Therefore, shared vehicles do not appear to fall within the sphere of protection of the ePrivacy Directive²⁸.

For those reasons, consent requirements of the ePrivacy Directive do not appear to apply to the processing of MDS data.

Besides these laws and regulations which are strictly about privacy and data protection, MDS users and mobility operators are advised to pay attention to EU legislative initiatives such as the draft Data Governance Act and the forthcoming Data Act. Although these are still under discussion and subject to potentially substantial changes, they are expected to have an impact in that they encourage data sharing practices, especially business-to-government data sharing.

---

²⁶Article 56 GDPR: “The supervisory authority of the main establishment or of the single establishment of the controller or processor shall be competent to act as lead supervisory authority for the cross-border processing carried out by that controller or processor[.]”

²⁷ The concept of an “electronic communications service” for the purpose of the ePrivacy Directive is defined by Article 2.4 of the European Electronic Communications Code (Directive (EU) 2018/1972) as “a service normally provided for remuneration via electronic communications networks, which encompasses, with the exception of services providing, or exercising editorial control over, content transmitted using electronic communications networks and services, the following types of services: (a) internet access service […]; (b) interpersonal communications service; and (c) services consisting wholly or mainly in the conveyance of signals such as transmission services used for the provision of machine-to-machine services and for broadcasting”. Both the EDPB and WP29 clarified that Article 9 of the ePrivacy Directive only applies to such electronic communications service providers (EDPB’s Guidelines 01/2020 on processing personal data in the context of connected vehicles and mobility related applications (final version), §11; WP29’s Opinion 13/2011 on geolocation services on smart mobile devices, pp.8 to 10).

²⁸ This second argument may not apply where shared vehicles are assigned to a given user on a long-term basis, e.g. in the context of long-term hire schemes. However, even in that case, the ePrivacy Directive should not be applicable, as MDS data is not stored or derived from data stored in the vehicle, within the meaning of Article 5.3 of that Directive.

Legal Justification:

Organizations involved in the processing of personal data may qualify either as data controller or as data processor under GDPR:

• A data controller is the “natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of [a] processing of personal data” (Article 4.7 GDPR). Where several entities qualify as data controllers, they are deemed joint controllers and they share the corresponding obligations (Article 26 GDPR).
• A data processor is the “natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller” (Article 4.8 GDPR).

As clarified by supervisory authorities²⁹, these qualifications are a matter of intellectual and factual influence over the reasons why personal data is collected and processed (“purposes”) and the “essential means” for such processing.

Such influence may be based on legal prerogatives (e.g. where a city is legally empowered to organize mobility services), on a contractual distribution of rights and obligations (e.g. where a party may impose certain restrictions on the other party’s processing of the data), and/or on a purely factual influence determined by skills and resources.

On the other hand, the fact that the considered entity has (or has not) access to the data is generally deemed irrelevant³⁰. Also, qualifications stipulated by parties in an agreement may always be challenged by supervisory authorities if those find that they do not reflect the real influence of each party over the processing.

This results in the concepts of data controller and data processor being extremely context sensitive.

Below are some insights on how to apply these qualifications to the different types of actors involved in the processing of MDS data. However, one should keep in mind that determining the proper qualification will always require a case-by-case analysis, to be performed for each activity/project involving the processing of MDS data.

Cities may either collect and process MDS data themselves or commission a mobility data solution provider to process it under their instructions. They may also procure services based on the processing of MDS data, without giving any specific instructions as to how exactly the data is processed in the context of those services.

In any case, it is likely that the city will qualify as a data controller where MDS data is processed to fulfil needs connected to the city’s prerogatives as an official authority (such as mobility and transport management).

This is supported by supervisory authorities’ analysis that the qualification of data controller may stem from legal provisions: “More commonly, rather than directly appointing the controller or setting out the criteria for its appointment, the law will establish a task or impose a duty on someone to collect and process certain data. In those cases, the purpose of the processing is often determined by the law. The controller will normally be the one designated by law for the realization of this purpose, this public task. For example, this would be the case where an entity which is entrusted with certain public tasks (e.g., social security) which cannot be fulfilled without collecting at least some personal data, sets up a database or register in order to fulfil those public tasks. In that case, the law, albeit indirectly, sets out who is the controller.”

As explained above, the fact that the city never receives or accesses MDS data itself (or that it only receives or accesses anonymized data) is not relevant: a city may qualify as data controller even where the collection and processing of MDS data is entirely entrusted to a mobility data solution provider³¹.

In this case, however, the city may rely on the solution provider’s assistance to secure compliance with its obligations as data controller. A mobility data solution provider may, for instance, help the city organize data minimization (by filtering the categories of MDS data necessary to fulfil the city’s specific needs), storage limitation (by deleting data which is not necessary anymore to fulfil those needs) and data security and confidentiality (by setting up appropriate technical and organizational security measures such as granular access control).

There are very limited cases where a city will qualify neither as data controller nor as data processor. This would be the case where a city only collects pre-anonymized MDS data, i.e. MDS data which was already anonymized not at the city’s request; in this situation, the city is not involved in the processing of any personal data³², so that it is not subject to GDPR.

Mobility operators may process the raw data from which MDS data is derived for certain purposes specifically related to their own activities, e.g. management of riders’ accounts, billing, management of fleets of vehicles, etc.

They generally determine the purposes and essential means of such processing themselves, so that they qualify as data controllers for these processing activities.

They may also take part in specific operations or partnerships aiming at sharing MDS data or MDS-derived information with cities or other third parties. To the extent that it plays a decisive role in organizing such sharing, a mobility operator may qualify as (joint) data controller for that purpose too.

Mobility data solution providers may work in a variety of ways.

Some solution providers use MDS data to perform specific commissioned work on behalf of a city or operator and receive detailed instructions from that city/operator about how to process the data. Such detailed instructions may cover which data to collect, how long it must be retained, whether it must be anonymized, etc.

On the other hand, some solution providers will use MDS data to provide standard services to cities and/or operators, and receive little to no instructions about which data to collect and how to process it. Some may decide to use MDS instead of another data format without being instructed accordingly.

Also, some solution providers and mobility operators may decide to set up partnerships with an aim at promoting the sharing of MDS data or MDS-derived information with certain cities. Under such partnerships, they may jointly decide which types of data will be shared, with whom, for which duration, etc.

In the first case, it is likely that the mobility data solution provider will qualify as the city’s/operator’s data processor, as it does not play a decisive role in determining the reasons why MDS data is collected and processed and the essential means for such processing. This also applies, for instance, to researchers who are commissioned to evaluate certain aspects of a mobility program using MDS data, where the evaluation was requested by another entity (e.g. a city).

In the second and third cases, the mobility data solution provider may qualify as data controller, inasmuch as it determines some essential means of the processing of personal data and has an autonomous (economic) interest in carrying out such processing³³. In the case of partnerships with mobility operators, the mobility data solution provider may share this qualification of data controller with the respective mobility operator, as both parties have converging interests in processing the data and they agree on the ways to process it³⁴.

Therefore, in sum, mobility data solution providers are likely to be data processors. However, in some limited circumstances, depending on the nature of their solution and the way they provide it, they may qualify as (joint) data controllers³⁵.

The respective responsibilities of data controllers and data processors are summarized in the table below, and explained in more detail in Part II “How to comply in practice” thereafter.

This distribution of obligations and liabilities must be reflected in specific agreements to be concluded between controllers and processors (Article 28.3 GDPR) and between joint controllers (Article 26 GDPR), as applicable (see Question 2.9).

---

²⁹ EDPB’s Guidelines 07/2020 on the concepts of controller and processor in the GDPR (see also former WP29’s Opinion 1/2010 on the concepts of controller and processor). These guidelines especially clarify that a data controller is an entity who determines the purposes and essential means of the processing of personal data.
³⁰ See Fashion ID GmbH & Co. KG v. Verbraucherzentrale NRW eV, ECJ, July 29th 2019, C‑40/17, §69
³¹ What is relevant to determine that a city is a data controller is that MDS data is processed to serve the city’s specific needs.
³² Anonymization itself is an operation qualified as processing of personal data, so that a party may qualify as data controller merely because it anonymizes (or commissions someone to anonymize) personal data.
³³ Fashion ID GmbH & Co. KG v. Verbraucherzentrale NRW eV, ECJ, July 29th 2019, C‑40/17, §80
³⁴ EDPB’s Guidelines 07/2020 on the concepts of controller and processor in the GDPR, §§51 seq. (“Joint participation in the determination of purposes and means implies that more than one entity have a decisive influence over whether and how the processing takes place. In practice, joint participation can take several different forms. For example, joint participation can take the form of a common decision taken by two or more entities or result from converging decisions by two or more entities regarding the purposes and essential means.”)
³⁵ Although such situations are not the most usual, the joint controller qualification should be considered especially in situations where a mobility data solution provider and a mobility operator work together with a close intuitu personae to develop and promote e.g. a specific data solution, a joint business offer or a joint research project.

GDPR leaves much room for organizations who collect and process personal data to determine what, in their case, constitutes a legitimate purpose to do so.

At a minimum, a legitimate purpose should be a purpose that is not unlawful under applicable laws and regulations; Recital 47 of GDPR also provides a few examples such as prevention of fraud and direct marketing.

Supervisory authorities have provided additional guidance as to how to identify such legitimate purposes. These include (but are not limited to) purposes which benefit to the community or which are encouraged by EU or Member States’ laws and policies³⁶.

Here are a few examples of purposes for which MDS data may be used:

• Building useful statistics for urban planning and development;
• Data-driven policy-making;
• Monitoring of fleets of vehicles (either by mobility operators or by cities);
• Enforcement of regulations imposed on mobility operators by cities.

All of these purposes are manifestly legitimate, as they are explicitly encouraged by a number of EU regulations and policies.

For instance, the 2019 Open Data Directive considers that mobility data “is associated with important socioeconomic benefits having a particular high value for the economy and society”³⁷, and the 2010 Directive on Intelligent Transport Systems (ITS) states that “the increase in the volume of road transport in the Union associated with the growth of the European economy and mobility requirements of citizens is the primary cause of increasing congestion of road infrastructure and rising energy consumption, as well as a source of environmental and social problems. The response to those major challenges cannot be limited to traditional measures, inter alia the expansion of the existing road transport infrastructure. Innovation will have a major role to play in finding appropriate solutions for the Union”³⁸.

In many cases, those purposes may also be found to be legitimated by domestic laws which empower cities to organize, monitor and control mobility services on their territory.

---

³⁶ See WP29’s Opinion 06/2014 on the notion of legitimate interests, pp.35-36: “In general, the fact that a controller acts not only in its own legitimate (e.g. business) interest, but also in the interests of the wider community, can give more ‘weight’ to that interest. The more compelling the public interest or the interest of the wider community, and the more clearly acknowledged and expected it is in the community and by data subjects that the controller can take action and process data in pursuit of these interests, the more heavily this legitimate interest weighs in the balance. […] The more explicitly recognized it is in the law, in other regulatory instruments – be they binding or not on the controller – or even in the culture of the given community overall without any specific legal basis, that the controllers may take action and process data in pursuit of a particular interest, the more heavily this legitimate interest weighs in the balance.”
³⁷ Directive (EU) 2019/1024 on open data and the re-use of public sector information, Recital 66
³⁸ Directive 2010/40/EU on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport, Recitals 1 and 2 (see also Commission Delegated Regulation (EU) 2017/1926 with regard to the provision of EU-wide multimodal travel information services)

It depends on the purposes for which it is collected. The principle of data minimization (Article 5.1 GDPR) requires that only the data which is necessary to fulfil the contemplated (legitimate) purpose be collected.

Certain purposes, such as building statistics about the use of mobility services, may be adequately fulfilled using only anonymous data such as aggregated trips.

On the other hand, certain other purposes will require more granular data, including native vehicle IDs and single trips. For instance, those may be necessary for real-time monitoring of fleets of vehicles, to report a malfunctioning vehicle or to enforce regulations imposed on mobility operators.

MDS is built around different APIs which allow MDS users to collect different feeds of data, depending on the user’s needs.

For instance, the Metrics API may be used when the user only needs to collect aggregated data, e.g. for statistical analyses. As explained above (see Question 1.4), such aggregated data (as it does not contain single vehicle IDs or single vehicle location data) may be considered anonymous data. However, it may be insufficient to fulfil certain legitimate needs such as real-time monitoring of fleets of vehicles.

It depends on the nature of the data (personal data or anonymized data) and on the purposes for which it was collected in the first place.

Anonymized data (see Question 1.4) can be retained with no time limit, as it is simply not subject to GDPR.

Personal data may be retained as long as the respective MDS user has a legitimate purpose to do so. In other words, it must be deleted or anonymized when the purpose for which it was collected in the first place is sufficiently fulfilled or does not exist anymore.

As explained under Question 1.1, MDS datasets are considered personal data when they contain native vehicle IDs (i.e. vehicle IDs assigned by the mobility operator who holds riders’ details such as names and email addresses) and/or single vehicle location data.

Such native vehicle IDs and single vehicle location data may be necessary for purposes such as monitoring of fleets of vehicles or enforcement of regulations imposed on mobility operators. Such monitoring/enforcement is generally performed in real-time (or quasi real-time); in any case, we recommend that vehicle IDs are deleted or randomized in a non-reversible manner when the MDS user does not need to single out specific vehicles anymore. This can be achieved by organizing the automatic deletion/randomization of native vehicle IDs contained in MDS datasets a certain number of days after each dataset is collected.

This also depends on the contemplated purposes, and the various roles of the persons/organizations involved.

GDPR data confidentiality principle requires that recipients of personal data be limited to those who need to access/use it to fulfil the contemplated purposes, and that “any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law” (Article 32 GDPR).

This is closely connected to the principles of “legitimate purpose” and data minimization explained above (see Questions 2.1 and 2.2). MDS users should ensure that their employees, agents, vendors, and partners only access the data which is necessary to fulfil a legitimate purpose determined by the respective data controller.

For instance, this requires mobility operators to assess whether data sharing requests are valid, i.e. issued by a person having competence to do so, such as a city official or a verified partner or mobility data solution provider. When sharing data spontaneously, they should ensure that the data is pushed to the intended recipient through secured communication channels (e.g. secured APIs).

This also requires cities to set up rigorous access control measures³⁹ to make sure that only the intended competent agents and services (and, as applicable, vendors) may access the data. Cities can implement these measures themselves or can rely on mobility data solution providers’ solutions which already include access control mechanisms, such as data visualization platforms with granular user account management features.

---

³⁹ On access control (and more generally data security and confidentiality), see esp. the CNIL’s 2018 Guide to Security of personal data, the ICO’s Security Guidance and EDPB’s Guidelines 01/2021 on Data breaches.

Transparency towards data subjects, i.e. making sure that data subjects know when, how and why their data is processed and are able to control it, is a key principle under GDPR.

When personal data is not collected directly from data subjects (as is the case for MDS users), Article 14 of GDPR requires that a privacy notice be pushed to data subjects to inform them about the processing of their data.

As per this article, a comprehensive privacy notice must contain the following information:

• The identity and the contact details of the controller (as identified under Question 1.8) and, where applicable, of the controller’s representative ;
• The contact details of the Data Protection Officer, where applicable (see Question 2.12);
• The purposes of the processing for which the personal data are intended (e.g. urban planning, scientific research project on mobility flows, enforcement of regulations for mobility companies), the legal basis for the processing (as identified under Question 2.7) and, where this legal basis is a legitimate interest of the data controller or a third-party, a description of this legitimate interest;
• The categories of personal data collected (as identified under Question 1.1), the source from which this personal data originates (i.e., in most if not all cases, mobility operators), and if applicable, whether it came from publicly accessible sources (which is generally not the case);
• The recipients or categories of recipients of the personal data (i.e., as applicable, mobility data solution providers and/or other MDS users, such as regulatory agencies or transport authorities when they directly receive MDS data);
• The period for which the personal data will be stored (as determined following the methodology described under Question 2.3), or if that is not possible, the criteria used to determine that period;
• Where applicable, that the controller intends to transfer personal data to a recipient in a non-EEA country or international organization and the guarantees applied to such transfer (see Question 2.13);
• The existence of the right to request access to and rectification or erasure of personal data or restriction of processing concerning the data subject and to object to processing as well as the right to data portability and the right to lodge a complaint with a supervisory authority;
• Where processing is based on data subjects’ consent (which, as explained under Question 2.7, is generally not the case), the existence of the right to withdraw consent at any time;
• Where the data is used to make automated decisions with an impact on data subjects or for profiling purposes (which is generally not the case),  meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing for the data subject. (If such automated decision-making or profiling is envisaged, it is highly recommended to perform a Data Protection Impact Assessment as described under Question 2.11 to check its compliance, as this type of data processing is generally considered sensitive by data protection supervisory authorities.)

This information must be presented in a clear and transparent language, so it is generally recommended not to go into too much technical detail about, for instance, the specifications of MDS data. It is important, however, that data subjects may understand the general logic and main aspects of the processing of their data, identify the appropriate contact persons, and know how to exercise their rights⁴⁰.

Article 14.3 GDPR requires that the privacy notice be pushed to data subjects “if a disclosure to another recipient is envisaged, at the latest when the personal data are first disclosed” and within no more than 1 month after the data is first collected⁴¹.

The timing for pushing the privacy notice to data subjects will therefore depend on whether MDS data is pushed to other MDS users in real-time or not.

In any case, as not all MDS users have rider-facing interfaces allowing them to properly push privacy notices to riders, a good practice would be for mobility operators and other MDS users to cooperate in using operators’ apps to display (links to) other MDS users’ privacy notices. For instance, mobility operators could insert in their privacy notices the list of entities with whom they share MDS data, with links to each of these entities’ own privacy notices⁴².

This obligation to inform data subjects comes with only a few limited exceptions, on which MDS users may consider relying depending on their specific circumstances.

It is possible not to push any privacy notice to data subjects especially:

• Where the provision of a privacy notice proves impossible, would involve a disproportionate effort (in particular for processing scientific or historical research purposes or statistical purposes) or would render impossible or seriously impair the achievement of the objectives of the data processing (Article 14.5.b) GDPR) In such cases the controller shall take appropriate measures to protect the data subject’s rights and freedoms and legitimate interests, including making the information publicly available.
• Where the collection or disclosure of MDS data is expressly organized by EU law or the Member State’s law to which the data controller is subject, provided that such law includes appropriate measures to protect the data subjects’ legitimate interests.
• Where MDS data is processed by a competent authority for purposes that fall within the scope of the Law Enforcement Directive (i.e. purposes related to investigation, prosecution or sanction of criminal offences) and the applicable Member State’s law explicitly authorizes not to inform data subjects (e.g. in order not to impede criminal investigations).

It is worth noting that supervisory authorities have a very narrow interpretation of these exceptions, so that MDS users should carefully assess whether it is legitimate to rely on them⁴³.

It is up to each MDS user who qualifies as data controller to determine whether they may rely on these exceptions, with due regard to applicable laws, the contemplated purposes of their use of MDS data and the modalities of its processing.

In any case, it is highly recommended to document the justification for not pushing a privacy notice to data subjects.

For instance, should MDS users wish to rely on the “disproportionate effort” exception, they must demonstrate how exactly the efforts necessary to push a privacy notice to data subjects are not proportionate to the consequences of those data subjects not receiving such a notice. When performing this assessment, MDS users may take into account any measure they have taken to reduce the possible impact of the processing on data subjects, such as undertaking a data protection impact assessment, pseudonymizing the data, minimizing collected data and storage periods, or implementing robust technical and organizational measures. As recognized by supervisory authorities, this “disproportionate effort” exception is especially relevant for MDS users who do not have the appropriate contact details to push a privacy notice directly to data subjects, as a basic principle of GDPR is that it does not impose the collection of additional personal data for the sole purpose of compliance⁴⁴. In any case, MDS users who rely on the “disproportionate effort” exception must make sure that a privacy notice is publicly available, so that data subjects may find the information that was not pushed to them.

---

⁴⁰ WP29’s Guidelines on transparency under Regulation 2016/679, §§12-13: “With written information […], best practices for clear writing should be followed. […] The information provided to a data subject should not contain overly legalistic, technical or specialist language or terminology.”
⁴¹ This articulation between these two terms is clarified by WP29 in its Guidelines on transparency under Regulation 2016/679, §27.
⁴² In any case, publishing the list of recipients is an obligation on mobility operators as per Article 14 GDPR, as they must inform data subjects about “the recipients or categories of recipients of the personal data” and supervisory authorities recommend that each recipient be named individually (WP29’s Guidelines on transparency under Regulation 2016/679, p.37).
⁴³ WP29’s Guidelines on transparency under Regulation 2016/679, §57
⁴⁴ WP29’s Guidelines on transparency under Regulation 2016/679, §64 (“Where a data controller seeks to rely on the exception in Article 14.5(b) on the basis that provision of the information would involve a disproportionate effort, it should carry out a balancing exercise to assess the effort involved for the data controller to provide the information to the data subject against the impact and effects on the data subject if he or she was not provided with the information. This assessment should be documented by the data controller in accordance with its accountability obligations. In such a case, Article 14.5(b) specifies that the controller must take appropriate measures to protect the data subject’s rights, freedoms and legitimate interests. This applies equally where a controller determines that the provision of the information proves impossible, or would likely render impossible or seriously impair the achievement of the objectives of the processing. One appropriate measure, as specified in Article 14.5(b), that controllers must always take is to make the information publicly available. A controller can do this in a number of ways, for instance by putting the information on its website, or by proactively advertising the information in a newspaper or on posters on its premises. Other appropriate measures, in addition to making the information publicly available, will depend on the circumstances of the processing, but may include: undertaking a data protection impact assessment; applying pseudonymization techniques to the data; minimizing the data collected and the storage period; and implementing technical and organizational measures to ensure a high level of security. Furthermore, there may be situations where a data controller is processing personal data which does not require the identification of a data subject (for example with pseudonymized data). In such cases, Article 11.1 may also be relevant as it states that a data controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purposes of complying with the GDPR.”)

Data subjects (i.e., in the case of MDS, riders) have a series of rights under GDPR, including a right of access (Article 15 GDPR), a right to rectification (Article 16 GDPR), a right to erasure (“right to be forgotten”) (Article 17 GDPR), a right to restriction of processing (Article 18 GDPR), a right to data portability (Article 20 GDPR) and a right to object to the processing of their personal data (Article 21 GDPR).

Article 12 GDPR requires data controllers to facilitate exercise of these rights and to answer each data subject’s requests.

However, Article 11 GDPR states that “if the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with [GDPR]. Where, in [such cases], the controller is able to demonstrate that it is not in a position to identify the data subject, the controller shall inform the data subject accordingly, if possible. In such cases, Articles 15 to 20 shall not apply except where the data subject, for the purpose of exercising his or her rights under those articles, provides additional information enabling his or her identification.”

Also, Article 12 GDPR provides that data controllers must take steps to verify that the person who makes the request is the actual data subject. If such verification is not possible, they must reject the request so as to avoid disclosing or erasing the data based on the request of an unauthorized, possibly ill-intentioned third party (which would amount to a data breach).

As explained under Question 1.1, MDS data does not contain directly identifying personal data such as riders’ names or email addresses. This means that MDS users are not in a position to identify data subjects or verify their identity when they make a request for access or erasure, except by collecting additional, directly identifying data (such as riders’ names or email addresses) which only the respective mobility operators may provide).

As per Article 11 GDPR above, MDS users have no obligation to search or obtain such additional, directly identifying data for the sole purpose of identifying and verifying the identity of the person who makes the request. It is possible that this person will spontaneously include such data in their request, although it is not likely (as they would have to first obtain that data from the respective mobility operator).

For those reasons, MDS users (such as cities) are advised to process data subject requests they receive in the following way:

• First, check whether the MDS user actually has any data that matches the request (which may refer to a given vehicle ID or a given trip with its date and time). It is possible that no match can be found, especially where the MDS user only has aggregated data – in such case, the MDS user must only inform the data subject that it does not have any data that matches the request.
• Second (if data that matches the request is found), check whether the person who made the request provides sufficient proof that the data actually relates to them (e.g. that they actually are the rider who made the trip). This verification will generally not be possible based on the data the MDS user has at hand, and the MDS user is not supposed to actively search for additional, directly identifying data, so that they may lawfully answer the data subject that their request cannot be fulfilled due to a risk of data breach.
• In the case of requests for erasure of data, MDS users should also be aware that such requests must be grounded on certain specific legal justifications listed under Article 17 GDPR (“right to be forgotten”), failing what the MDS user has no obligation to erase the data. For instance, the data subject must bring forth objective reasons relating to their particular situation to object to the processing of their data (as per Article 21 GDPR).

In most cases these checks will lead to the conclusion that the concerned MDS user may lawfully reject the request – and even that they must reject it, where it is uncertain that the person who made the request is the actual rider to whom the data relates.

Processing data subjects’ requests as a data controller/as a data processor: Answering data subjects’ requests is the duty of the data controller (see Question 1.8). Data processors’ duty is only to forward the requests they receive to the respective data controller and assist that data controller in processing those requests. A data controller may sometimes instruct a data processor to answer data subjects’ requests directly, although it is not a practice encouraged by GDPR.

As per Article 19 GDPR, mobility operators are required to take proportionate steps to notify MDS users with whom they have shared MDS data in case they rectify or delete data based on a data subject’s request. Although GDPR does not clarify what such a notification should contain, a cautious approach would be to flag the specific datasets that were rectified/deleted so that MDS users would be able to reflect that rectification/deletion in their own databases.

Article 6 GDPR requires that any processing of personal data be based on one of the following 6 “legal bases”, i.e. that such processing be carried out only if and to the extent that one of the following conditions applies.

• Consent – The data subject has consented to that processing of their personal data – to be valid, such consent must be freely given, specific, informed and unambiguous, and the data subject must be able to withdraw it at any moment (Articles 4.11 and 7 GDPR); or
• Contract – The processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract; or
• Legal obligation – The processing is necessary for compliance with a legal obligation to which the data controller is subject; or
• Vital interests – The processing is necessary in order to protect the vital interests of the data subject or of another natural person; or
• Public interest – The processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the data controller; or
• Legitimate interest – The processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.

In the case of MDS, the “contract”, “public interest” and “legal obligation” legal bases are likely to be the most relevant. If not, the data controller may also weigh whether its “legitimate interests” (or those of a third party) may justify the contemplated processing of MDS data, taking into consideration the data subjects’ interests and fundamental rights and freedoms.

In any case, identifying the appropriate legal basis depends on first identifying who is the data controller in the case at hand. Indeed, most legal bases are defined in relation to a given data controller: for instance, a municipality may have a legal obligation to collect certain data, which a private company may not have.

Therefore, different data controllers will consider relying on different legal bases, as exemplified below.

Mobility operators may store and process data as necessary to provide their mobility services pursuant to their own terms and conditions. They may also process that same data for purposes which reasonably fall within the scope of the “legitimate interest” legal basis, provided that a proper balance with data subjects’ interests and fundamental rights and freedoms is ensured (see below).

They may also rely on the “public interest” legal basis when sharing MDS data with municipalities or public/private entities vested with an official authority in the fields of mobility or transport management.

Municipality and public entities may have a legal obligation to collect and process mobility data. Such a legal obligation must be embodied in EU law or in a Member proper management and functioning” State law⁴⁵; it must apply to the municipality/public entity and be binding⁴⁶; also, it must be sufficiently clear as to the nature and object of the processing of personal data it requires⁴⁷. This may be the case where a Member State’s law or decree obliges municipalities to verify the distribution of shared vehicles in the public right of way.

Where there is no such specific legal obligation, the collection and processing of MDS data may still be justified where it is necessary “for the performance of a task carried out in the public interest or in the exercise of official authority vested in the data controller”. Supervisory authorities consider this legal basis “need to be interpreted in a way as to allow public authorities some degree of flexibility, at least to ensure their proper management and functioning”⁴⁸, and that it may apply to private entities as well as public authorities, where such private entities participate in tasks carried out in the public interest or cooperate with public authorities. They emphasize the case of transport management⁴⁹ and underline that this legal basis may be used by private entities who share data with public authorities⁵⁰.

In most countries, mobility management will be considered a task carried out in the public interest, with the respective authority being vested in municipalities and/or public or private entities. EU laws and regulation themselves consider that proper mobility management and urban development is in the public interest. Therefore, subject to a proper assessment of their own prerogatives in the fields of transport and mobility, municipalities and public/private entities may rely on this legal basis to justify their collection and processing of MDS data.

However, Article 6 GDPR specifies that public authorities cannot rely on the “legitimate interest” legal basis to justify processing of personal data in the performance of their tasks.

Mobility data solution providers may qualify as data controllers or as data processors, depending on the type of services they provide and the general context thereof (see Question 1.8).

When acting as data processors, they are not concerned with the question of legal bases, as such is the prerogative of the data controller. Their role and responsibility is only to process data in compliance with the data controller’s documented instructions.

When acting as data controllers, depending on its nature and context, their processing of MDS data may be justified either on the “public interest” legal basis (as explained above) or on the “legitimate interest” legal basis – provided that a proper balance with data subjects’ interests and fundamental rights and freedoms is ensured (see below).

Processing MDS data based on legitimate interests: The “legitimate interest” legal basis is specific in that it calls for a proper assessment of the balance between, on one hand, the legitimate interest pursued by the data controller or third parties, and, on the other hand, data subjects’ interests and fundamental rights and freedoms. This assessment must be documented, as applicable in a more comprehensive data protection impact assessment (see Question 2.11).

Supervisory authorities have provided highly detailed guidance about how to perform such an assessment⁵¹. Data controllers who intend to justify their processing of MDS data based on legitimate interests must (i) identify the interests pursued through the processing (e.g. commercial interests, scientific research, etc), (ii) establish how it is legitimate, (iii) identify data subjects’ interests and fundamental rights and freedoms which could be altered or otherwise impacted by the processing of their data, (iv) weigh the pursued legitimate interests against these data subjects’ interests and fundamental rights and freedoms, (v) if relevant, consider implementing additional safeguards to reduce the impact on such data subjects’ interests, rights and freedoms, and (vi) perform the overall balance, taking into account the impact of those additional safeguards.

Where no other legal basis may be invoked, then the data controller must consider obtaining consent from data subjects (i.e. riders) to collect and process their personal data.

To be valid, such consent must be freely given, specific, informed and unambiguous, and the data subject must be able to withdraw it at any moment (Articles 4.11 and 7 GDPR). Therefore, if necessary, such consent should be requested and obtained by using an appropriate opt-in module⁵¹.

---

⁴⁵ See WP29’s Opinion 06/2014 on the notion of legitimate interests, p.19: “It is also important to emphasize that Article 7(c) refers to the laws of the European Union or of a Member State. Obligations under the laws of third countries […] are not covered by this ground. To be valid, a legal obligation of a third country would need to be officially recognized and integrated in the legal order of the Member State concerned, for instance under the form of an international agreement. On the other hand, the need to comply with a foreign obligation may represent a legitimate interest of the controller, but only subject to the balancing test of Article 7(f), and provided that adequate safeguards are put in place such as those approved by the competent data protection authority.”
⁴⁶ ibid.: “The controller must not have a choice whether or not to fulfil the obligation. Voluntary unilateral engagements and public-private partnerships processing data beyond what is required by law are thus not covered[.]
⁴⁷ ibid.: “The legal obligation itself must be sufficiently clear as to the processing of personal data it requires. […] The controller should not have an undue degree of discretion on how to comply with the legal obligation.”
⁴⁸ ibid., p.23
⁴⁹ ibid., p.22
⁵⁰ ibid. p.21: “Article 7(e) also covers situations where the controller does not have an official authority, but is requested by a third party having such authority to disclose data. For example, an officer of a public body competent for investigating crime may ask the controller for cooperation in an on-going investigation rather than ordering the controller to comply with a specific request to cooperate. Article 7(e) may furthermore cover situations where the controller proactively discloses data to a third party having such an official authority.”
⁵¹ WP29’s Opinion 06/2014 on the notion of legitimate interests
⁵² Supervisory authorities have adopted extended guidelines illustrating how to build such a compliant opt-in module – see EDPB’s Guidelines 05/2020 on consent under Regulation 2016/679.

As explained above (Question 2.7), processing personal data under GDPR may be justified if and to the extent that such processing is “necessary for compliance with a legal obligation to which the data controller is subject”.

Therefore, local regulations may provide a legal basis for mobility operators to share data with a municipality (or any public/private entity defined in the regulation) and for that municipality (or public/private entity) to collect it, provided that the regulation is binding⁵³​ and sufficiently clear as to the type of data to be shared⁵⁴. Subject to local deliberative processes, it may also warrant that data sharing requirements were adopted democratically, taking into consideration citizens’ opinions.

However, embodying data sharing requirements in laws or regulations is not necessary, if and to the extent that the municipality’s intended use of the data is related to its official authority and/or to a task carried out in the public interest, such as mobility management or urban development. In such cases, indeed, mobility operators may rely on the “public interest” legal basis to justify the sharing of their data, as recognized by supervisory authorities.

Regarding the insertion of data sharing requirements in tenders, such requirements will only have little impact on the assessment of the legal basis for the collection and processing of MDS data, as supervisory authorities clarify that such contractual requirements will not amount to a “legal obligation” to share/collect the data⁵⁵.

However, they may serve to frame and document mobility operators’ participation to “a task carried out in the public interest” or their cooperation with the municipality in its official authority.

Data sharing requirements may also be helpful in organizing and documenting compliance with other principles and obligations such as data minimization, security and confidentiality, by specifying the types of data to be shared, sharing protocols, and applicable security measures.

In any case, with regard to accountability obligations under Article 24 GDPR, it is best that mobility operators and municipalities document the legal basis and modalities of the data sharing, whether it is through requirements set forth in the respective tenders or in a non-binding document.

Beyond GDPR, cities may wish to insert data sharing requirements into tenders as a way to formally document expectations for what data will be shared, in what formats, and with what degree of accuracy and availability.

---

⁵³ ibid.: “The controller must not have a choice whether or not to fulfil the obligation. Voluntary unilateral engagements and public-private partnerships processing data beyond what is required by law are thus not covered[.]”
⁵⁴ ibid.: “The legal obligation itself must be sufficiently clear as to the processing of personal data it requires. […] The controller should not have an undue degree of discretion on how to comply with the legal obligation.”
⁵⁵ ibid., p.19: “The controller must not have a choice whether or not to fulfil the obligation. Voluntary unilateral engagements and public-private partnerships processing data beyond what is required by law are thus not covered[.]”

Articles 26 and 28 GDPR impose specific contractual requirements in relationships between a data controller and its data processor (Article 28 GDPR) and between two or more joint controllers (Article 26).

Therefore, depending on the various parties’ qualifications, they may be required to implement specific agreements, the content of which is determined by the abovementioned GDPR provisions⁵⁶.

In general, the contractual framework between a city and mobility operators does not need to be directly impacted by GDPR, as mobility operators generally do not qualify as cities’ data processors or joint controllers.

Indeed, mobility operators and cities generally process MDS data for different independent purposes, and the role of mobility operators is most often limited to transmitting data which is further used by cities in an autonomous manner.

Absent any such qualification, cities and mobility operators are free (from a GDPR perspective) to organize the content of their contractual relationships.

As explained above, although it is not mandatory under GDPR, tenders (and other forms of city/operator agreements) may be used to frame the sharing of data and facilitate GDPR compliance, e.g. by inserting requirements about the types of data to be shared, sharing protocols, and security measures to be applied by operators.

Depending on the nature of the relationship between the city and the mobility data solution provider, the parties may be required to insert Article 28 GDPR controller-to-processor clauses in their service agreement.

On the other hand, when mobility data solution providers qualify as a city’s data processor, the city and the provider need to sign a dedicated agreement in line with Article 28 GDPR. 

This type of agreement is generally called a “Data Processing Agreement” (DPA). It must include the specific clauses imposed by Article 28.3 GDPR⁵⁷. These clauses require that the mobility data solution provider, as data processor:

• Process the personal data only on documented instructions from the city, including with regard to transfers of personal data to a third country or an international organization, unless required to do so by Union or Member State law to which the mobility data solution provider is subject; in such a case, the provider must inform the city of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest;
• Ensure that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;
• Take all measures required pursuant to Article 32 GDPR (i.e. technical and organizational security measures);
• Respect the conditions referred to in Article 28.2 and 28.4 GDPR for engaging another processor (i.e., simply put, that the city’s approval is given prior to the engagement of any further data processor, and that further data processors provide appropriate guarantees in terms of GDPR compliance);
• Taking into account the nature of the processing, assist the city by appropriate technical and organizational measures, insofar as this is possible, for the fulfilment of the city’s obligation to respond to requests for exercising the data subject’s rights (which are listed under Question 2.6);
• Assist the city in ensuring compliance with its obligations to perform data protection impact assessments (see more under Question 2.11), consultation of supervisory authorities and obligations relating to data breaches, taking into account the nature of processing and the information available to the mobility data solution provider;
• At the choice of the city, delete or return all the personal data to the city after the end of the provision of services, and delete existing copies unless Union or Member State law requires storage of the personal data;
• Make available to the city all information necessary to demonstrate compliance with the obligations above and allow for and contribute to audits, including inspections, conducted by the city or another auditor mandated by the city.

These specific clauses are only mandatory where the mobility data solution provider qualifies as the city’s data processor⁵⁸. They may be supplemented/specified as the parties may find necessary/relevant to optimize or facilitate GDPR compliance taking into account the specific context and nature of services provided.

Depending on the nature of their relationship, mobility operators and mobility data solution providers may need to enter into Article 26 or 28 GDPR clauses (controller-to-processor clauses or joint controllers clauses).

Also, as mobility data solution providers may qualify, depending on the configuration, either as mobility operators’ data processors or as joint controllers, these may be required to implement either the clauses required by Article 28.3 GDPR (see above) or a joint control agreement as per Article 26 GDPR. 

A joint control agreement is more flexible than a Data Processing Agreement: it must “determine their respective responsibilities for compliance with the obligations under [GDPR], in particular as regards the exercising of the rights of the data subject and their respective duties to provide the information [to data subjects] […]. The arrangement may designate a contact point for data subjects. […] [It] shall duly reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects. The essence of the arrangement shall be made available to the data subject”.

These provisions leave much more flexibility to the parties to organize their respective roles and obligations, provided that GDPR compliance is ensured; this should encourage mobility data solution providers and mobility operators to draft tailor-made agreements appropriate to the contemplated use cases. Even if Article 26 GDPR does not specifically mention it, such agreements may also include provisions about data security and confidentiality.

When mobility data solution provider and mobility operator qualify as two independent data controllers (or when the mobility data solution provider is the data processor of the city), GDPR does not impose the conclusion of any specific agreement or clauses between them. However, it may be a good practice to insert privacy and data protection clauses in data sharing agreements, to reflect each party’s own sphere of liability as an independent data controller (or, as applicable, as the city’s data processor) and to promote data security and confidentiality throughout the processing chain.

---

⁵⁶ Standard contractual clauses may also be required in case of a transfer of MDS data from the European Economic Area to a non-EEA country (see Question 2.13).
⁵⁷ A standard DPA in line with Article 28.3 GDPR was adopted by the European Commission on 4 June 2021, which MDS users may consider using or taking inspiration from when engaging in a controller-to-processor relationship. See https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32021D0915&locale-en.
⁵⁸ Article 25 LED provides similar requirements between competent authorities which process personal data for the purposes of criminal investigation and prosecution of criminal offences and their data processors.

In general, the contractual framework between mobility operators and riders consists in the operator’s terms and conditions which are accepted by riders on the operator’s app.

It is best to distinguish these terms and conditions and the privacy notice described under Question 2.5, as GDPR does not require that privacy notices be “accepted” as contracts, and contract law may sometimes make it difficult to further modify/update the privacy notice. Rather, operators should only make sure that privacy notices are displayed in such a way that riders have an opportunity to read them before starting to use their service.

As explained under Question 2.5, operators should include in their privacy notices a list of recipients with which they share MDS data. Although it is not required by GDPR, operators may also consider displaying links to the recipients’ respective privacy notice, as a good practice to enhance transparency towards riders (who will then be able to know how each recipient further processes their data).

Article 35 GDPR requires that the data controller perform a data protection impact assessment (DPIA) where the contemplated processing “is likely to result in a high risk to the rights and freedoms of natural persons”.

Supervisory authorities have issued helpful guidance as to how to determine whether there is such a “high risk” and, as applicable, how to perform the DPIA⁵⁹.

A DPIA must be conducted where the contemplated processing involves at least 2 of the following criteria⁶⁰: evaluation or scoring of data subjects; automated decision-making with legal or similar significant effect on data subjects; systematic monitoring of data subjects; sensitive data or data of a highly personal nature; large-scale processing; matching or combining datasets; data concerning vulnerable subjects; innovative use or applying new technological or organizational solutions, or when the processing in itself prevents data subjects from exercising a right or using a service or a contract.

Processing of MDS data may be found to meet several of these criteria, especially to the extent that it is carried out on a large scale (such as a metropolis), that it could allow systematic monitoring of data subjects (e.g. where MDS data is used to detect road offences) and that it involves new technological or organizational solutions. Also, supervisory authorities consider that location data, although not strictly speaking sensitive, may under certain circumstances be considered “data of a highly personal nature”⁶¹.

Therefore, in many cases, MDS users will need to (or at least should) perform a DPIA prior to starting to collect/process MDS data.

Performing a DPIA as a data controller/as a data processor: The responsibility to perform the DPIA lies with the data controller (Article 35 GDPR). However, data processors are required to assist the data controller in performing it (Article 28.3 GDPR), for instance by providing comprehensive information about their technical and organizational resources involved in the processing.

Performance of the DPIA must be documented by a DPIA report. It should establish the compliance of the intended processing of MDS data with applicable principles and obligations, as described in this Q&A, and at least (Article 35.7 GDPR):

• A systematic description of the envisaged processing operations and the purposes and legal bases of such processing;
• An assessment of the necessity and proportionality of the processing operations in relation to the purposes;
• An assessment of the risks to the rights and freedoms of data subjects; and
• The measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance, taking into account the rights and legitimate interests of data subjects and other persons concerned.

Many tools exist on the market that facilitate the performance of DPIAs and edition of DPIA reports. The CNIL (French data protection authority) published a free step-by-step tool (cnil.fr/fr/node/23992) and the ICO (UK data protection authority) a sample DPIA report (ico.org.uk/media/2258461/dpia-template-v04-post-comms-review-20180308.pdf) which MDS users may find useful.

Performing a compatibility test where MDS data is processed for a new purpose: Article 6.4 GDPR states that when personal data is processed for a purpose other than that for which it was initially collected, the data controller shall ensure that this new purpose is compatible with the initial purpose. If not, then the new processing may only be carried out based on data subjects’ consent or on EU or a Member State’s law.

MDS data is derived from raw data generated by vehicles initially collected by operators for internal purposes such as monitoring of vehicles or user billing. Therefore, its sharing with other MDS users and further processing by such MDS users must be subject to a compatibility test. Factors considered under this test depend on the specific nature and context of the contemplated further processing; as per Article 6.4 GDPR, they must include at least:

• Any link between the purposes for which the personal data have been collected and the purposes of the intended further processing;
• The context in which the personal data have been collected, in particular regarding the relationship between data subjects and the controller;
• The nature of the personal data, in particular where it includes sensitive data or offence-related data;
• The possible consequences of the intended further processing for data subjects;
• The existence of appropriate safeguards, which may include encryption or pseudonymization.

Such factors must be balanced against each other to make sure that the intended further use of MDS data is compatible with its initial collection by mobility operators. This compatibility test should be documented in the DPIA.

Performing a DPIA requires both technical and legal skills and resources and good knowledge of the contemplated project. MDS users should make sure that all internal stakeholders are involved, and, as necessary, outsourced technical and legal advisors. If a mobility data solution provider is involved in a data processor capacity, its assistance may be requested (see above). If the data controller has a Data Protection Officer, it must be consulted.

DPIA reports may be requested by supervisory authorities to verify compliance of the processing.

---

⁵⁹ WP29’s Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk” for the purposes of Regulation 2016/679.
⁶⁰ When only 1 criterion is involved, although a DPIA is not mandatory, WP29 considers that it is appropriate to conduct one.
⁶¹ WP29’s Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is “likely to result in a high risk” for the purposes of Regulation 2016/679, p.10

A Data Protection Officer (DPO) is a person whose position is to assist and advise the data controller/data processor in complying with GDPR (and more generally data protection laws and regulations). The DPO may be in-house or outsourced (e.g. with a law or consulting firm), and in any case must be involved in all strategic decisions regarding processing of personal data. 

Article 37 GDPR makes it mandatory for an organization to appoint a DPO (a) where the organization is a public authority or body, (b) where “the core activities of [the organization] consist of processing operations which, by virtue of their nature, their scope and/or their purposes, require regular and systematic monitoring of data subjects on a large scale” or (c) where “the core activities of [the organization] consist of processing on a large scale of [sensitive data]”. 

Therefore, all cities and other public/governmental MDS users are required to appoint a DPO – as per criterion (a). Mobility operators may be required to do so as well because of criterion (b). 

Even where appointing a DPO is not mandatory, it is still advisable to appoint a DPO to make sure that the legal and technical aspects of privacy and data protection in the context of MDS are well implemented.

GDPR puts a specific emphasis on transfers of personal data to countries which are not part of the European Economic Area (EEA) (i.e. the EU + Norway, Iceland, and Liechtenstein). Such transfers may only take place provided that the level of protection guaranteed by GDPR is not undermined in the non-EEA country (Article 44 GDPR).

In practice, this means that MDS data originating from the EU may be transferred to/accessed by a recipient located in a non-EEA country only:

• Where the non-EEA country was deemed by the European Commission to provide adequate protection for personal data. As of today, this includes the following countries: Andorra, Argentina, Canada (commercial organizations only), Faroe Islands, Guernsey, Israel, Isle of Man, Japan, Jersey, New Zealand, Switzerland, the United Kingdom (post-Brexit), and Uruguay. An adequacy recognition procedure is currently pending for South Korea⁶².
• Or where appropriate guarantees are set up with the recipients to organize an adequate level of protection for the transferred MDS data. This is generally achieved by signing standard contractual clauses adopted by the European Commission with the recipient⁶³; some MDS users may also consider using binding corporate rules within the meaning of Article 47 GDPR to secure intra-group data transfers.

Since a ruling from the ECJ on July 16th 2020, Privacy Shield cannot be used as a means to secure transfers of personal data to the USA.

When transferring MDS data from the EEA to a non-EEA country which does not benefit from an adequacy decision, MDS users are advised to rely on standard contractual clauses adopted by the European Commission on June 4th 2021, bearing in mind that the signing of these clauses is not in itself sufficient to secure the transfer – a substantial assessment of the recipient’s ability to adequately protect the transferred MDS data is required in each case.

Note that these specific requirements also apply to transfers of personal data to international organizations.

---

⁶² Adequacy decisions generally apply to transfers of data which are subject to GDPR only – not to the Law Enforcement Directive. A notable exception is the very recent UK adequacy decision.
⁶³ A new version of the standard clauses was adopted and published on June 4th 2021 by the European Commission:
ec.europa.eu/info/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en