understanding of data requirements in the EU Member States

Nature of the barrier Objective / driver behind the barrier

A specific mandate under law or from a specific body is required to export the data

Storage facilities must be within national borders, or they may be outside national borders but a copy must be made to a mirror system within national borders

Maintaining national control over cultural systems and services for the protection of national heritage against loss Clarification that the rule was intended to protect physical artefacts with heritage value, which may be lost abroad. Duplication of electronic data should not pose the same problem.

Ensuring accountability and verifiability Clarification that the fundamental requirement is to ensure the integrity and auditability of the information. Local storage or mirroring a system is not the only way of achieving this goal.

Potential solution?

2.4. Establishing an analytical framework for identified barriers – defining a common understanding of data requirements in the EU Member States

The section above has provided a first insight in some of the principal regulatory barriers that may restrict the free flow of data for processing and storage purposes within the European Digital Single Market, along with the drivers behind them, and some of the solutions that might be explored to resolve them. It should be recognised that the scope of this overview is not exhaustive; however, given the methodology that relied on national experts to obtain key examples of barriers to the free flow of data, the listing undoubtedly contains the principal barriers and can at any rate be considered as representative for the state of play across the EU.

While the overview above did not yet aim to identify non-regulatory barriers – these will be further examined in the sections below - it is however possible at this stage to provide a provisional analytical framework that can be used to describe and assess these barriers, based on their key characteristics. The purpose of this analytical framework is twofold:

 Firstly, the framework is intended to provide an overview of existing data requirements that may be encountered across the EU. It should thus be possible to classify every barrier mentioned above into a specific section of the analytical framework, and to describe it accurately.  Secondly, it is intended to allow the definition of common solutions to common problems, allowing barriers to be mitigated or overcome.

Broadly, the following structure could be proposed in relation to regulatory barriers, which is intended to be designed so that it can be applied to any type of data (i.e. it is not dependent on sector specific elements). The elements in bright blue designate specific types of barriers encountered:

Figure 20 – Classification of identified regulatory barriers

Regulatory barriers to the free flow of data

Direct barriers Indirect barriers

Geographic location storage requirements

E.g. servers must be located in country X (BG,PL, RO) or data can only be stored nationally (DE, SE, PT, SV, NL)

Unique national technical requirements

E.g. data must use national formats (HR, SV)

Accessibility to supervisors

E.g. supervisors must be able to get access (AT, BE, IE, NL, PT)

Generic technical requirements

E.g. interoperability (FI)

Prior authorisation schemes

E.g. storage systems must be approved by supervisor (SI, RO)

Prohibitions against third party access / disclosure

E.g. data may not be made accessible to third parties (BG, CZ, NL)

Mandatory use of a specific infrastructure

E.g. data must be kept by administration X (AT, CZ, LU, NL)

Segregation requirements

E.g. data must be kept on segregated systems

Subcontracting restrictions

E.g. subcontractors must obtain prior approval (AT, LU, NL)

Destruction requirements

E.g. Data must be destroyable in situation X (BE, DK)

16

Most of the types of requirements can be grouped together and correspond to a specific public policy interest as shown above. However, this does not imply that implementation of barriers to the free flow of data in the specific cases as described above always achieves their intended policy objectives. Although the policy objective may be legitimate, the implementation of barriers to the free flow of data may be ineffective or disproportionate in light of the intended objective. By way of a specific example, it is clear that accounting documents must be accessible to tax authorities. However, this legitimate policy objective does not imply that data must be stored locally.

Looking at the objectives in general, these can briefly be assessed as follows:

Figure 21 – Barriers, aims and policy objectives

Type of barrier Policy Objectives

Geographic location storage requirements

Tends to be imposed to ensure a public policy interest, typically either accessibility to national supervisors, such as the Gambling17 or Tax Authorities18 19 .  The policy objective can still be achieved through cooperation with foreign supervisors, except when the exclusive availability to certain bodies is required to achieve the policy objective.

National technical Tends to serve a public policy interest in terms of interoperability, availability and 17 The requirement to maintain local systems and/or mirror systems within national borders (in relation to gambling systems), see for BG: Gambling Act, promulgated, State Gazette, No. 26/30.03.2012, lastly amended and supplemented, SG No. 1/3.01.2014, effective 1.01.2014, article 6(4), PL: Gaming Law of 19 November 2009, article 16d and RO: Government Decision no.111/2016 approving the Norms of application of 24 February 2016 on gambling, articles 127 and 136. 18 Accounting data (for tax purposes), for DE: Procedural rules for accounting and records, § 146 AO and § 147 (federal legislation) and SE: Swedish Bookkeeping Act, Chapter 7, sections 2-4. 19 Other restrictions that fall under this category relate to national (and regional) (classified) archive information, see PT: Decree-Law No16/93 of 23 January, as amended by Law No 14/94 of 11 May).

requirements

Accessibility to supervisors

Generic technical requirements

security20 .  The policy objective can only be achieved when a specific requirement is necessary and no appropriate equivalent requirements are commonly adopted in the market. Tends to serve a public policy interest by ensuring that compliance with national requirements can be verified (mainly found in relation to the Financial or Tax authorities)21 .  The policy objective can still be achieved through cooperation with foreign supervisors. Tends to serve a public policy interest in terms of interoperability, availability and security22 .  The policy objective can only be achieved if these requirements are known and realistically available to foreign service providers.

Prior authorisation schemes

Tends to serve the public interest by ensuring that compliance with national requirements can be verified (e.g. when storage service providers must be authorised by the government)23 .  The policy objective can still be achieved, for example through cooperation with foreign supervisors.

Mandatory use of a specific infrastructure

Tends to serve the public interest by ensuring that data is centralised with a single body, where access can be tightly secured and controlled, and where appropriate use (in accordance with national policy) can be verified24 .  The policy objective to maintain national control over healthcare and social security systems and services (and in the case of Luxembourg the business register) can only be achieved when there is no alternative to such centralisation.

Prohibitions against third Tends to serve both public and private interest by ensuring privacy, confidentiality and security of the data (health25, privileged data26, banking data27) 20 Public register information, see HR: Law on the State Information Infrastructure, Official Gazette of Republic of Croatia no 92/2014 passed on 15 July, 2014 and Regulation on Organizational and Technical Standards for Connecting to the State Information Infrastructure, official Gazette of Republic of Croatia no 103/2015 and classified information, see SV: Classified information Act, articles 14 and 15. 21 Financial data (access by Financial Authority), see AT: Federal Act on the Supervision of Securities, art. 25, 26, specified by Regulation Auslagerungsverordenung, BGBI. II Nr. 215/2007, latest amendment BGBI. II Nr. 272/2011, BE: Circular PPB 2004/5 on healthy management practices in outsourcing by credit institutions and investment companies issued by the Belgian Banking, Finance and Insurance Commission on 22 June 2004, IE: Central Bank UCITS Notice, October 2013, Annex II and NL: Circular Cloud Computing 2011/643815 issued by the Dutch Central Bank on 6 December 2011, PT: Regulation of the Bank of Portugal implementing Article 39(1) of Law No 25/2008 of 5 June and Article 5 Law No 25/2008 of 5 June, lastly amended by Law No 118/2015 of 31 August; Accounting data (access by Tax Authorities), see BE: Income Tax Code 1992 and subsequent amendments, Article 315, Notice from the Revenue Commissioners published in Iris Oifigiuil (Official Journal), 27 January 2012, drawn up in exercise of powers conferred on them by s. 887 of the Taxes Consolidation Act 1997(substituted by s.232 of the Finance Act 2001). 22 Health data, particularly patient records, see FI: Law on electronic processing of client data within social and health care, issues by the decision of the Finish Parliament on 1 July 2007, § 10. 23 Health data, see AT: Federal Act on Data Security Measures when using personal electronic Health Data or Health Telematics Act 2012, §6, 14 and 20.Civil register, see SV: Central Population Register Act, Articles 12, 19 and 23a; National archives, see SV: Zakon o varstvu dokumentarnega in archiveskega gradiva ter arhivih (Uradni list Rs, st. 30/2006); National security information, see RO: Government Decision no. 575/2002 approving the national standards for the protection of classified information. 24 Examples were found predominantly in relation to health data and/or patient records, see AT: Health Telematics Act 2012, § 6, 14 and 20 and the Federal Act on Federal Computing Centre (BRZ), BGBI. Nr 757/1996, lastly amended BGBI. I Nr 71/2003 and ICT Consolidation Act, BGBI. I Nr 35/2012, CZ: Medical Services Act No. 372/2011 Sb, Ministerial Decree No. 98/2012 Sb. and Recommendation No. ZD03/94, FI: Law on electronic processing of client data within social and health care, 1 July 2007; ((e-)prescriptions), see: EL: Law No 3892/2010 (FEK 189 A’) Electronic Registration and Run prescriptions and referrals for medical examinations, § 6 1, 2, 5, NL: Guidelines on the handling of health records, issues by the KNMS in January 2010 and GZB- requirements for software from the Association of Care providers for Care communication. But also with regard to business registers, see LU: 19 December 2012 - Law concerning the register of businesses and companies, and accounting and annual accounts of companies, modifying certain other legal provisions, Art. 2 and Grand Ducal Regulation relating to the execution of the aforementioned law, Art. 1er, 2, 2bis, 10, 13, 14, 15, 23. 25 See BG: Health Act; promulgated on 10 August 2004, last amendments in force as of 01 January 2016), Art. 27, 28, CZ: Medical Services Act, NL: Guidelines on the handling of medical records and GBZ-requirements for software providers.