5.3.2. Recasting regulations to support the free flow of data

infrastructure in their territory in order to supply the services in question, which would have been more directly relevant.

However, a correct application of these principles would lead to the conclusion that data

location restrictions – or more broadly: legal requirements that affect the free flow of data – in relation to specific services – understood as services usually required against remuneration, as provided by the Treaty and the Services Directive - can be legitimate only to the extent that these requirements are objectively justified by an overriding reason relating to the public interest, and that they are proportional in the light of this public interest objective.

Applied logically and consistently, this should imply that such restrictions should be

identified by Member States, and that the policy objective should be explicitly stated, explaining why the policy objective constitutes an overriding reason that can only be

achieved through the imposed restriction. In the absence of this approach, the necessity and proportionality test could not be applied.

In such cases and to that extent, a data location restriction could be justified and the free flow of data could be legitimately impeded. Examples would include police databases, classified information, and official registers – none of which would be considered as an element of a ‘service’ under the Treaty, since (and to the extent that) they are a part of government functions which are not provided for remuneration. When such a justification could not be provided, the requirement must be recast into a functional requirement.

5.3.2. Recasting regulations to support the free flow of data Once it has been determined that data should fall within the remit of the free flow of data policy – either as a logical consequence of the application of the Treaties, the Services Directive or the e-Commerce Directive, or as a part of a future Free Movement of Data right that could be construed along the principles outlined above – any legal requirements in relation to the data would need to be recast in accordance with the functional requirements translation table provided above.

It should however be recognised that this is not a trivial exercise. It implies the screening and simplification of national laws – a similar exercise to what was also required by the implementation of the Services Directive73 - but more importantly it can also require the establishment of coordination and harmonisation mechanisms between the Member States in order to establish any technical or organisational requirements that may be relevant for specific data types. These will likely vary from sector to sector.

Examples of the need for such coordination and harmonisation mechanisms can be drawn from the functional requirements translation table, in combination with the data from the identified national restrictions:

Figure 39 – Policy objectives and harmonisation needs

Policy objective Need for coordination and harmonisation?

73 See the Commission’s guidance on simplification in the Handbook on implementation of the Services Directive; http://bookshop.europa.eu/en/handbook-on-implementation-of-the-services-directive-pbKM7807096/; Chapters 5 (on simplification) and 7 (on permissible limitations to the free movement of services) are particularly salient.

Accessibility to a regulator or supervisor

Protection against third party modification, or against modification by the person subject to the storage requirement

Security of the infrastructure

Trustworthiness of the service provider

Trustworthiness of the service provider’s personnel Elimination of data location restrictions implies that a regulator in Member State A must be able to access data in Member State B. This policy objective can be phrased in a technologically neutral manner (i.e. without imposing specific approaches, technologies or solutions) as has been done in the functional requirements translation table.

However, to facilitate accessibility, the regulators or supervisors may require harmonisation on data formats, language or semantics, and access procedures.

Resulting requirement: interaction between regulators or supervisors to establish and mutually recognise suitable data formats, language or semantics, and access procedures. The policy objective can be phrased in a technologically neutral manner (i.e. without imposing specific approaches, technologies or solutions) as has been done in the functional requirements translation table. However, if regulators want to recognise specific requirements (e.g. specific encryption technologies), then this requires harmonisation.

Resulting requirement: coordination between legislators, regulators or supervisors to establish and mutually recognise any appropriate approaches, technologies or solutions The policy objective can be phrased in a technologically neutral manner (i.e. without imposing specific approaches, technologies or solutions) as has been done in the functional requirements translation table. However, if regulators want to recognise specific requirements for specific types of infrastructure (e.g. certification against specific security standards), then this requires harmonisation.

Resulting requirement: coordination between legislators, regulators or supervisors to establish and mutually recognise any appropriate security standards and certification approaches. The policy objective can be phrased in a technologically neutral manner (i.e. without imposing specific requirements) as has been done in the functional requirements translation table. However, if regulators want to implement a prior notification/authorisation scheme for specific types of service providers, then this requires harmonisation.

Resulting requirement: coordination between legislators, regulators or supervisors to establish and mutually recognise any prior notification and authorisation requirements (within the limitations permitted by the Services Directive for authorisation schemes). The policy objective can be phrased in a technologically neutral manner (i.e. without imposing specific requirements) as has been done in the functional requirements translation table. However, if regulators want to align on the required qualifications, background check and/or duty of confidentiality and secrecy, then this requires harmonisation.

Resulting requirement: coordination between legislators, regulators or supervisors to establish and mutually recognise any required qualifications, background check and/or duty of confidentiality and secrecy.

The complexity stems from the fact that these requirements do not follow a one-size-fits-all model where a single security standard, certification, authorisation etc. could be applied across all industries in a homogeneous way. In practice, it can only be established in a sector by sector basis, where any pre-existing legal frameworks and cooperation platforms can be leveraged to facilitate harmonisation and mutual recognition.

This does not necessarily imply that a free movement of data principle could only be implemented through a purely vertical (sector specific) approach. Indeed, it is perfectly possibly to introduce a generic free movement of data rule in a horizontal initiative, e.g.

through a legal instrument that scopes the right as applying to the data processing activities of any services in the sense of the Treaty, and indicating that exceptions are only permissible if they are objectively justified by an overriding reason relating to the public interest, and that they are proportional in the light of this public interest objective. The sector specific element implies however that, beyond this horizontal intervention, sector specific coordination mechanisms – e.g. via national regulators or national expert groups – are necessary to address the practical implications of this right.

In other words: the statement of the free movement of data can and should be done horizontally, but it should be acknowledged that implementing measures – agreeing on harmonised security requirements, data formats, access mechanisms etc. – will need to be organised at the sector specific level. This too is not new: the Services Directive contained both an administrative cooperation obligation between Member States (Chapter VII) and permitted the creation of a convergence programme (Chapter VIII) through codes of conduct “particularly by professional bodies, organisations and associations”. A similar approach could be applied to address sector specific concerns.

In practice therefore, the process requires a three-step approach: when data falls within the scope of the free movement of data, a Member State would have to:

 Screen its legislation to determine whether it has introduced any requirements (either directly or via any competent regulators or supervisors) that impact the free flow of data (comparable to the administrative simplification duty imposed upon the

Member States by the Services Directive);  If so, to simplify the requirements by translating them into functional requirements based on the principles set out above;  And if the resulting functional requirements result in specific technical or

operational requirements, to coordinate with other Member States in order to

harmonise and mutually recognise these technical or operational requirements.

It is possible that these steps would be implemented slightly differently by the Member States, depending on national sensitivities and local markets. However, a shared statement of the principle would seem to be particularly useful to communicate clearly to legislators and regulators (including professional bodies, organisations and associations) that the free flow of data is the standard rule and expectation in the digital single market, and that exceptions should be objectively necessary and proportionate.

The outcome of the process thus is not necessarily the removal of any technical or organisational requirements, but rather to ensure that these are harmonised across the Member States wherever possible. In the absence of this approach, service providers can be subject to overlapping, duplicate or contradictory requirements, creating compliance costs that are particularly hard to bear for SMEs. By way of example, Figure 5 in section 2.3.2. identified 7 sets of legal sources containing requirements for IT providers in the financial industry. These are highly similar but not identical, and there is no clear mutual recognition mechanism between the national regulators, implying that an IT provider targeting this industry needs to assess on a country-by-country basis which certifications, accreditations and authorisations it needs.

This can be resolved either by harmonising the relevant requirements, or by mutual recognition. This is done for financial data on a voluntary basis by some regulators: the