European Commission DG Migration and Home Affairs Integrated Border Management (IBM) Feasibility Study to include in a repository documents for Long-Stay visas, Residence and Local Border Traffic Permits Phase1: Analysis of Options Final Report (version 6.0) September 2017
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
European Commission DG Migration and Home Affairs
Integrated Border Management (IBM) Feasibility Study to include in a repository documents for Long-Stay visas, Residence and Local Border Traffic Permits
Phase1: Analysis of Options
Final Report (version 6.0) September 2017
This Final Report has been drawn up in accordance with the European Commission – DG Migration & Home Affairs (DG HOME) Terms of References (ToR) from March 2017 for a “Feasibility Study on Integrated Border Management (IBM) for persons not recorded in EES” by PricewaterhouseCoopers (hereafter: “PwC”).
The document represents the third formal deliverable including management summary.
3
Table of Contents
MANAGEMENT SUMMARY ............................................................................................ 5
1. WHAT IS THE ISSUE? ............................................................................................................................. 5 2. WHAT WOULD THE EU REPOSITORY DO? ............................................................................................. 6 3. WHAT IS THE BEST TECHNICAL SET-UP? ............................................................................................... 8 4. WHAT WILL HAPPEN NEXT? ................................................................................................................. 8
PREAMBLE ..................................................................................................................... 9
1. INTRODUCTION ........................................................................................................ 10
1.1. BACKGROUND ...................................................................................................................................... 10 1.2. PROBLEM DEFINITION .......................................................................................................................... 10
1) Difficulty in authenticating the documents at the borders ....................................................... 10 2) The fragmentation of information across Member States can affect how the situation of third-country nationals is assessed for migration purposes ........................................................... 11
1.3. DRIVERS FOR CHANGE ......................................................................................................................... 12 1.4. SCOPE OF THE STUDY ........................................................................................................................... 13 1.5. STAKEHOLDERS OF THE REPOSITORY.................................................................................................... 14
2. METHODOLOGY ....................................................................................................... 16
3. REPOSITORY MAIN CONSIDERATIONS .................................................................. 19
3.1. OBJECTIVES ........................................................................................................................................ 20 1) Facilitate checks at external border-crossing points and within the territory of the Member States ................................................................................................................................................... 20 2) Assess the TCN situation and contribute to tackle irregular migration. ............................... 22 3) Contribute to the prevention, detection and investigation of terrorist offences or of other serious criminal offences. .................................................................................................................. 23 4) Gather statistics to support evidence based Union migration policy making ....................... 24
3.2. POSSIBLE ALTERNATIVES TO THE REPOSITORY .................................................................................... 25 3.3. USE-CASES .......................................................................................................................................... 27
3.3.1. Verify the authenticity, validity and status of document issued by another MS .................. 27 3.3.2. Verify that the bearer is the rightful owner of the document ............................................... 28 3.3.3. Store and update document information ............................................................................... 29 3.3.4. Consult the history of documents and/or decisions on applications ................................... 30 3.3.5. Consultation for law enforcement purposes .......................................................................... 30 3.3.6. Reporting and statistics ............................................................................................................ 31
3.4. OVERVIEW OF THE RELEVANT DOCUMENTS ........................................................................................ 32 3.4.1. Long-stay visas ......................................................................................................................... 33 3.4.2. Residence permits .................................................................................................................... 33 3.4.3. Residence cards ........................................................................................................................ 34 3.4.4. Local border traffic permits .................................................................................................... 36 3.4.5. Inclusion in the repository ........................................................................................................ 37
3.5. DATA ................................................................................................................................................... 41 3.5.1. Data set ....................................................................................................................................... 41 3.5.2. Access ........................................................................................................................................ 43 3.5.3. Data retention........................................................................................................................... 44
3.6. TO BE PROCESS .................................................................................................................................. 45 3.6.1. Border check .............................................................................................................................. 45 3.6.2. Store and update document information ............................................................................... 46 3.6.3. Consultation .............................................................................................................................. 48
3.7. LEGAL ................................................................................................................................................ 49 3.8. COMPLIANCE WITH DATA PROTECTION FRAMEWORK .......................................................................... 53
3.8.1. Applicable legal texts ................................................................................................................ 53 3.8.2. Data protection principles ....................................................................................................... 53 3.8.3. Repository pursuing objective 1: necessity and proportionality test .................................. 56 3.8.4. Repository pursuing objective 2: necessity and proportionality test .................................. 59
4
4. OPTIONS ASSESSMENT ............................................................................................ 63
4.1. ASSUMPTIONS AND CONSTRAINTS ....................................................................................................... 63 4.2. EVALUATION CRITERIA ....................................................................................................................... 63 4.3. OVERVIEW OF THE OPTIONS ............................................................................................................... 66 4.4. OPTION 0: ‘DO NOTHING: STATUS QUO’ ...............................................................................................67 4.5. OPTION 1: REPOSITORY AS PART OF VIS.............................................................................................. 68
4.5.1. Description ................................................................................................................................ 68 4.5.2. Assessment ................................................................................................................................ 70 4.5.3. Key Findings ..............................................................................................................................76
4.6. OPTION 2: REPOSITORY AS A NEW SYSTEM ........................................................................................... 77 4.6.1. Description ................................................................................................................................. 77 4.6.2. Assessment ................................................................................................................................ 78 4.6.3. Key findings .............................................................................................................................. 83
4.7. OPTION 3: HYBRID OPTION ................................................................................................................. 84 4.7.1. Description ................................................................................................................................ 84 4.7.2. Assessment ................................................................................................................................ 85 4.7.3. Key Findings ............................................................................................................................. 90
5. CONCLUSIONS .......................................................................................................... 91
5.1. ON THE ANALYSIS OF OPTIONS.............................................................................................................. 91 5.2. ON THE ANALYSIS OF OBJECTIVES AND SCOPE ...................................................................................... 91 5.3. POINTS OF ATTENTION ........................................................................................................................ 92 5.4. OPTIONS FOR ROLLING OUT THE REPOSITORY ..................................................................................... 93
ANNEXES ...................................................................................................................... 95
ANNEX 1. – GLOSSARY ............................................................................................................................... 96 ANNEX 2. – LEGISLATIVE OVERVIEW ..........................................................................................................97 ANNEX 3. - VIS ....................................................................................................................................... 100
Security Assessment .......................................................................................................................... 101 Safeguards ......................................................................................................................................... 101
ANNEX 4. – SUMMARY OF MEMBER STATES' ANSWERS TO THE SURVEYS .................................................. 105 ANNEX 5. – DATA SET COMPARISON ......................................................................................................... 113
5
Management summary
1. What is the issue?
Millions of third-country nationals (TCNs) cross the external borders of the Schengen Area every day. Their number is growing each year and at the same time, public safety issues have probably never been so critical. Hence, securing the Schengen Area while keeping the European Union attractive for travellers is the ultimate objective.
In view of this, the harmonisation of applications and processes, the mutual recognition of Member States’ (MSs) documents, smooth communication and the exchange of information between Member States are paramount requirements to achieve this goal. Although different initiatives have been implemented in the Schengen Area,1 certain information gaps remain.
The Visa Information System (VIS) has proven to be an effective tool for border management, internal security and migration risk assessment. It is used as a repository, case-management and information-exchange system between Schengen Member States for TCNs subject to short-stay visa requirements. It automatically compares the information on the document presented with the information contained in the common repository, and gives an answer regarding the existence and validity of such a document in seconds.
On the other hand, some categories of TCNs are not covered by any information system. The information on their documents is only available within the Member States’ national systems. The following figure illustrates this situation regarding TCNs residing in the EU (residence-permit and residence-card holders), coming for longer than 90 days in any 180-day period (long-stay visa holders) or regularly crossing the external borders (local border-traffic permit holders):
Figure 1: Information gap on a category of third-country nationals
As illustrated above, there is currently no common European tool designed to exchange information on this particular category of TCNs, as they are not fully covered by any of the existing or future systems.2 Consequently, two major issues arise from this situation:
Border-check pitfall: border guards only have detailed information on documents issued by their own country, as it is only available at national level. Thus, it is very difficult for them to be
1 See: http://ec.europa.eu/home-affairs/what-we-do/policies_en (consulted 05/2017). 2 They can be present in the Schengen Information System (SIS) if they are subject to an entry-ban alert or if their document has been withdrawn.
EES ETIAS
Eurodac SIS VIS
TCN who reside in the EU, coming for a long stayor who often cross the external borders
Visa-required TCNs coming for short stays
Asylum seekers and some categories of irregular migrants
TCNs’ entries and exits in and out of Schengen, coming for short stays
Visa-exempt TCNs coming for short stays
Future systems
?
Current systems
Law enforcement and border controls
6
certain of the authenticity and validity of a document issued by another MS, as there is no IT tool to confirm the information.
TCN travels: if there is a doubt surrounding a TCN’s long-stay or residence documents, they currently have to wait at the border-crossing point until the matter is solved bilaterally between the border guards and the MS that issued the document. This procedure is cumbersome and time-consuming.
The High-Level Expert Group on Information Systems and Interoperability3 recently outlined the possibility of creating a common European repository containing data on TCNs who are currently out of the scope of the EU-wide systems. This tool could contain data on all long-stay visas, residence permits, residence cards and local border-traffic permits issued, and would thus address this information gap whilst also remedying a potential security loophole in the EU’s border management and internal security framework.
2. What would the EU repository do?
This study consisted of a high-level feasibility analysis for implementing a common European repository containing data on four types of documents:
1. Long-stay visas
2. Residence permits
3. Residence cards
4. Local border-traffic permits
The study analysed the general provisions for the repository and outlined the high-level design principles that would guide the later technical analysis. Following the analysis, the fact sheet below summarises the main findings and points of attention:
Table 1: Fact sheet on the repository’s design principles
For what objective?
The repository has two main objectives:
1) Facilitating checks at external border-crossing points and within the territory of the Member States. A match between the document presented and the data contained in the repository would ascertain that the document is authentic. Additionally, the repository could inform on a potential change of status; e.g. document authentic, but withdrawn last week by the issuing MS.
2) Assess the TCN situation and contribute to tackle irregular migration.
The repository could assemble all the documents linked to the same person; e.g. a person to whom two long-stay visas have been granted and then withdrawn in the past. This information could support Member States in assessing a new application lodged by this TCN, including for short-stay visas.
The function could also include information on ongoing and previous applications; e.g. a person applying for a short-stay visa who already has two long-stay visa applications ongoing in other Member States and another three recently rejected applications.
In addition, it has two ancillary objectives:
3) Contributing to the prevention, detection and investigation of terrorist offences and other serious criminal offences.
3 See http://ec.europa.eu/transparency/regexpert/index.cfm?do=groupDetail.groupDetail&groupID=3435 (consulted 05/2017).
7
4) Gathering statistics and reports on the topic and supporting evidence-based decision-making in the area of EU Migration and Home Affairs.
However, the repository would differ from the VIS in the sense that it would not be used as a case-management system.
For whom? The main end users of the repository are border guards and migration authorities, including all MS administrations involved in the issuing process for any of the documents. In addition, national and European (Europol) law enforcement authorities could be granted special access to the repository under certain conditions, in light of what is already in place for other EU large-scale IT systems. Lastly, relevant national and European authorities could be granted access to the repository in order to gather statistics. The data available would be anonymised.
Which documents?
The study concluded that including long-stay visas and residence permits in the repository is feasible, would bring added value and would meet the set objectives.
The situation is less clear for residence cards. Residence cards are issued to TCNs who are family members of mobile EU citizens, and are granted solely upon proof of family ties. Their legal basis derives from freedom of movement; therefore, they differ from the other documents as they confer primary and individual rights granted to certain TCNs. Nevertheless, these documents allow the bearer to move freely across EU, thus underling the importance of establishing their authenticity.
Local border-traffic permits were discarded, as the study did not find sufficient rationale to add them to the repository. These permits can only be used to cross the external borders of one MS. The presence of a holder outside the limited territorial validity of the permit would already be an infraction per se.
Which data?
The repository could be composed of the following data set: 1) Biographical data: mostly deriving from the elements contained in the
document itself; 2) The document’s history; 3) History of the decisions on past applications4 (linked to the second objective of
the repository “Assess the TCN situation and contribute to tackle irregular migration”);
4) Biometric data5: facial image.
This data set is more limited than the one contained in the VIS, as the repository does not aim at being a common European case-management system. Therefore, it would not need to include the information given by the TCN during the application process.
4 While this data element might be retained in order to address the second objective of the repository “Assess the TCN situation and contribute to tackle irregular migration”, if said objective is retained, this would not be applicable for Residence Cards. For this latter migration risk assessment is not relevant as the Residence Cards stem from a different legal basis and purpose than the other document types under consideration. 5 There are disparities in the way in which Member States capture, store and retain biometric data on long-stay and residence documents. Although more than half of Member States take applicants’ fingerprints, many do not store this information in their national systems. For the moment, biometric data could therefore not be included consistently in the repository for all documents of all Member States, and the repository could thus not be used for identification purposes.
8
3. What is the best technical set-up?
The study then assessed three possible technical options to implement the repository of long-stay and residence documents:
Option 1 – VIS: the repository is part of the existing VIS;
Option 2 – new system: the repository is a new system; or
Option 3 – VIS and new system: a mix of Options 1 and 2, where some documents are incorporated into VIS and others are part of a separate system.
In order to select the best-suited solution, the three options have been described and compared. The analysis concluded that Option 1 – repository as part of VIS is the most adequate for a repository of long-stay and residence documents. As shown in the following table, this option scored the highest for all the selection criteria:
Table 2: Assessment table (1 = high effort, 4 = low effort)
Criterion/option Option 1: Repository as
part of VIS Option 2: Repository as
a separate database Option 3: Mix of options
1 and 2
Data protection and security 4 2 2
Ease of technical, operational and legal implementation
3 2 1
Cost-effectiveness 4 2 2
Option 1 is thus the most secure and cost-effective option and implementable with the least effort. As part of the VIS, the repository could take advantage of the system’s existing and future functionalities. Moreover, the planned VIS evolutions provided in the 2016 VIS Evaluation Report6 include many services that will enhance its performance significantly, most notably in terms of data quality, reporting and statistics and information for migration authorities.
Broadening the VIS to include information on long-stay and residence documents would allow the different Member States’ stakeholders to continue using an existing and well-known system that has already proven its added value and performance. Additionally, it is the option that is most in line with the current vision for border-management systems set out in the European Commission’s Communication of April 2016 on stronger and smarter information systems for borders and security:7 making full use of existing systems and managing data in a more effective and efficient way.
4. What will happen next?
The scope of this study was limited to a high-level analysis of the feasibility of developing a repository and an outline of the best-suited technical option. A more detailed analysis would need to be carried out, especially on the following topics:
A complete necessity and proportionality test on the overall system and for each technical option;
An assessment of the impact of the measures for the different stakeholders involved;
An assessment of the detailed implementation design through broader and more specific stakeholder consultations (eu-LISA on technical matters, other relevant EU agencies and a larger panel of stakeholders at Member State level, such as border guards and migration officers).
6 See: https://ec.europa.eu/home-affairs/what-is-new/news/news/2016/20161014_1_en (consulted 07/2017). 7 See: http://www.eulisa.europa.eu/Newsroom/News/Documents/SB-EES/communication_on_stronger_and_smart_borders_20160406_en.pdf (consulted 06/2017).
9
Preamble
This document is an initial assessment of the feasibility of implementing a repository of long-stay visas, residence permits, residence cards and local border traffic.
It constitutes a high-level analysis aimed at describing how such a repository could be implemented and used. It looks at a number of topics ranging from the use-cases and data set to the possible implementation options at technical level. This initial assessment is expected to allow the decision makers to take an informed decision on which is the most promising design of the repository: integrated with the VIS, not or only partially.
Once the most promising high-level design is identified, a more detailed analysis should follow, examining in detail the impact of the repository for these documents on both the MS and the data subjects. It should examine the repository’s necessity and proportionality and further detail alternative options, which topic is only briefly covered within this document.
10
1. Introduction This chapter provides an overview of the background to the study, in particular the political and legal context behind the potential implementation of a repository of long-stay visas, residence permits, residence cards8 and local border-traffic permits. It also outlines the main drivers for change before introducing the elements analysed by the study and the main stakeholders involved.
1.1. Background
The European Union’s migration and border-management policies comprise various procedures and information systems aiming at facilitating the entry and stay of bona fide third-country nationals (TCNs) whilst securing the integrity of the territory. Different documents can be used by TCNs to cross the external borders and stay in the Schengen Area, depending on the duration and type of visit; these documents are short-stay visas, long-stay visas, residence permits, residence cards and local border-traffic permits.
For short-stay visas, also known as Schengen visas, there is a common format in all Schengen Member States and their application and issuance procedures have been harmonised. The information on these documents and their applications is stored in the Visa Information System (VIS), which is used as an information system for migration authorities (including consulates) and border guards, as well as for national and European law enforcement authorities under special conditions. It provides border guards with reliable information on the authenticity and validity of visas. The introduction of biometric information in the VIS also gives an additional layer of security when verifying the identity of TCNs and contributes to fighting identity fraud.
On the other hand, long-stay visas, residence documents and other types of border-crossing documents are not fully harmonised, and the format of some of these can differ greatly from one issuing Member State to another. Moreover, there is no systematic exchange of information on these types of documents between Member States. This means that border guards have no access to information on documents issued by another Member State. Thus, they have to rely on the document itself and its security features, if available, at border-crossing points.
With regard to Europe-wide IT tools available for Member States, the Roadmap to enhance information exchange and information management including interoperability solutions in the Justice and Home Affairs area published by the Council of the European Union on 6 June 2016, lays down different action points to tackle the information-management gaps in the EU.9 In particular, this study addresses the last action point, no. 50, which proposes assessing the need for a central Residence Permits Repository and whether such a new EU tool is necessary, feasible and proportional in order to meet the following two main objectives:
1. Addressing the information gap for these categories of third-country nationals; and 2. Further securing the external borders and enhancing the internal security of the
European Union.
1.2. Problem definition
1) Difficulty in authenticating the documents at the borders
While records of long-stay or residence documents are usually stored in national databases, border authorities other than those of the issuing MS would not have access to this data and have no tool to verify the document’s authenticity (other than by detecting whether the document is counterfeit) and status. Moreover, verifying the document itself is made difficult by the different formats, the
8 In this document, residence cards refer only to residence cards issued to third-country nationals who are family members of EU citizens or of persons enjoying the right of free movement. 9 See: http://data.consilium.europa.eu/doc/document/ST-9368-2016-REV-1/en/pdf (consulted 20/05/2017).
11
heterogeneous use of security features and – for some documents – the rarity with which they appear at certain border-crossing points.
Currently, Member States can use alerts stored in the Schengen Information System (SIS) to inform other Member States of withdrawn documents. They have another tool at their disposal for detecting counterfeit documents at the borders: the European Image Archiving System (FADO).10 Even if these tools are useful for examining documents presented at the borders and for detecting fraudulent cases, they do not constitute a positive list of all issued documents, like how the VIS is used for short-stay visas and is accessible by all Schengen Member States during border checks. In other words, border guards have no IT tool to support them in verifying the authenticity of the documents.
This information gap can create blind spots in the border-management framework, thus ultimately creating risks for internal security and migration. This is especially important when considering the existing and ongoing strengthening of border checks for other categories of travellers (e.g. ETIAS for short-stay visa-exempt travellers, VIS for short-stay visa holders and EES for all short-stay visitors), which could motivate people with ill intentions to look for other, less secure types of documents that would still allow them to enter the Schengen Area and move across Member States. This phenomenon has already been observed with ID cards, whereby fraudsters target less secure EU ID cards for intra-Schengen movements.11 Forged documents are the gateway used by irregular migrants to enter and move within the EU. According to Frontex’s 2017 Annual Risk Analysis, smugglers frequently provide migrants with fraudulent travel and identity documents. Frontex observes that both the quantity and quality of fraudulent documents circulating in the EU have increased in recent years.12 In fact, smugglers are supported by criminal networks with access to expert counterfeiters who, financed by the strong demand, have set up print shops.13
2) The fragmentation of information across Member States can affect how the situation of third-country nationals is assessed for migration purposes
Currently, information on the migration history of a third-country national and on their issued documents are not stored centrally, making it difficult for Member States to have all the relevant information to hand when assessing a new application, for instance when deciding whether to issue a visa or residence document. For short-stay visas, the VIS provides a way for Member States to share information and collaborate on a case. However, authorities cannot know the history of long-stay and residence documents linked to the applicant, such as whether the person has been issued with another long-stay visa or residence document in another MS.14
This fragmentation could lead Member States to have an incomplete picture of the situation of those third-country nationals. These challenges have already been identified and described by the European Commission, which published the April 2016 communication Stronger and Smarter Information Systems for Borders and Security, in which it commits to work to enable a better use of the data collected. Having data fragmented and spread across many different systems
10 The system was set out in Joint Action 98/700/JHA of December 199810 and is an information system containing data on genuine and false documents (visas, residence permits, passports, driving licences, etc.). Part of the information shared in FADO is also publicly available in the Public Register of Authentic travel and identity Documents Online (PRADO), which is managed by the Council of the European Union. FADO is currently used by all EU Member States, Iceland, Norway and Switzerland. It contains (Art. 2 of the Joint Action):
a) Images of false and forged documents; b) Images of genuine documents; c) Summary information on forgery techniques; d) Summary information on security techniques.
11 Source: Risk Analysis for 2017, Frontex, page 23, http://frontex.europa.eu/assets/Publications/Risk_Analysis/Annual_Risk_Analysis_2017.pdf (consulted 06/2017). 12 Ibid, p. 22. 13 Ibid. 14 It is important to note that this possibility would not be available for residence cards as the only condition for issuance is a family tie with a mobile EU citizen.
12
means that it is much more complex to transform it into actionable information for the competent authorities.
1.3. Drivers for change
A common repository of long-stay and residence documents could close the information gap for this category of TCNs, allowing border guards to reliably check the authenticity and validity of these documents. The repository would support checks already being performed, but with the advantage that border guards would have an IT tool to support their task, instead of having to rely solely on the documents’ physical features.
The repository would reinforce border security, creating triangular verification between document, person and repository. A forged document (entirely or partially, by altering some of its information) – even if of very good quality – would not be found in the repository. In addition, the identity information of the person associated with the said document would have to match not only the information contained in the passport, but also the information present in the repository.
Figure 2: Triangular verification – person, repository and document
The effectiveness of such triangular verification based on a central repository has already been tested with the VIS (additionally with the use of biometrics to be able to verify the identity of the person independently of the document). The clear majority of Member States agree that the introduction of the VIS has facilitated the fight against visa fraud, as well as facilitating checks at external border-crossing points and within the Member States’ territory.15 Moreover, Frontex’s Annual Risk Analysis 2016 shows that the introduction of VIS checks at the borders in October 2011 led to an increase in detections of false visas in the period immediately thereafter (2012) and, in the longer run, constituted a deterrent to the use of false visas to enter EU territory (with a drop from over 1,800 false visas in 2012 to 776 in 2015).
15 Source: REFIT VIS evaluation, 2016, report https://ec.europa.eu/home-affairs/sites/homeaffairs/files/what-we-do/policies/borders-and-visas/visa-policy/docs/report_to_the_european_parliament_and_council_on_implementation_of_vis_en.pdf
The person can be found in the repository as holder of the document
The document exists in the repository
The identity of the person matches the one in the document presented
13
VIS impact on the fight against visa fraud16
Cases of visa fraud detected at the external borders since the introduction of the VIS
According to the VIS evaluation and based on consultations carried out with the Member States, the VIS had three main impacts regarding the objective of “facilitating checks at external border crossing points and within the territory of the Member States”:
“the fact that it has improved the quality of visa checks (thanks to the use of centralised data making it possible to verify the identity of the visa holder and the authenticity of the visa in seconds, including when issued by another Member State);
the increase in the information accessible to relevant authorities (by allowing access to the visa history and information input by 26 states);
its contribution to detecting and fighting the use of fraudulent documents (made useless by a system carrying out identity checks based on fingerprints)”. (Source: SWD (2016) 328 final).
A central repository for long-stay and residence documents could have similar effects. It could become not only a facilitator for border checks but also an effective tool for tackling irregular migration and fraud at the borders and within the Schengen Area (in 2014, the number of false residence permits detected17 was 2,241 – the third most forged type of document after passports and ID cards).18
In addition, the repository could be used by migration authorities to assess the situation of third-country nationals by exchanging information on the person applying and on previously issued documents (for long-stay visas and residence permits). It could give a general overview of a TCN’s past and present situation, as national records do not reflect previous documents issued or denied in other Member States.
1.4. Scope of the study
The European Commission has launched this study with the aim of investigating the possibility of building a common repository as a way to address the information gap and strengthen the security of the Schengen Area. The goal of this study is to perform an initial assessment of the feasibility of such a repository and the possibility of integrating it into the existing VIS, and to provide the European Commission with data to better scope a more detailed impact assessment, as provided in the following table summarising the scope of the study.
16 Source: VIS evaluation, SWD (2016) 328 final. 17 The actual number is bound to be higher as only a portion of fake documents are detected. 18 Source: Frontex European Union Document Fraud Annual Risk Analysis 2015.
Figure 3: Impact of VIS on visa fraud (source: VIS “REFIT” evaluation and Frontex Annual Risk Analysis)
14
Table 3: Summary of the scope of the study
In scope Out of scope
High-level analysis of the feasibility of creating a repository into which to copy data on long-stay visas, residence permits, residence cards and local border-traffic permits. This assessment includes studying several aspects:
- Assessing the technical and organisational possibilities of creating a repository of these documents
- Defining a data set for the repository - Comparing the options for implementing the
repository.
Detailed impact assessment. In particular, identifying, researching and assessing the alternatives to the repository are not part of the scope and will only briefly be addressed within this study. Further assessments and consultations should take place following this study.
Harmonising the documents or the respective processes (in particular the application/issuing process).
Should the possibility and opportunity to design such a repository result from this initial assessment, a more detailed study and impact assessment will be launched to deepen the analysis, in particular in relation to the impact on fundamental rights.
Lastly, the study addresses the feasibility of creating a repository of documents issued by Member States, and changes neither the nature of the rights related to these documents nor the conditions and responsibilities for issuing them.
The common repository
A repository is understood here as being an entity containing information collected from different sources; in this case, MS databases. The repository does not contain any data in addition to the data already available in Member States’ source systems, and thus simply and efficiently resolves the issue of accessing many data sources. The documents19 whose data could be stored in the central repository are:
1. Long-stay visas: granted to TCNs staying in the Schengen Area for a period of between 90 days and one year for various purposes: studies, work, etc.
2. Residence permits: issued to TCNs residing in a Member State (e.g. to work, study, etc.).
3. Residence cards: granted to TCNs who are family members of EU citizens who do not reside in their Member State of origin.20 They differ from the previous two types of documents, as they confer the primary right of free movement granted to EU citizens and their family members.
4. Local border-traffic (LBT) permits: the LBT regime essentially states that TCNs living in a border region may apply for and travel with a permit that simplifies border crossings. With this permit, the holder may travel up to 30 km (with a possibility to extend this to 50 km) into the neighbouring Schengen country and stay in that area for up to 90 days.
While LBT permits are not long-stay or residence documents, they have been included in the scope of the study as they also allow the holder to cross the external Schengen borders.
The study analyses and compares three main options for implementing a repository:
1. A repository as part of VIS; 2. A repository as a new database; 3. A combination of both options.
These options will be thoroughly described and assessed in Chapter 4.
1.5. Stakeholders of the repository
The main potential stakeholders affected by the implementation of the repository are listed below, starting from the top-left of the figure and moving anticlockwise:
19 See Section 3.4 for further details on the documents. 20 Directive 2004/38/EC.
15
Figure 4: Potential stakeholders affected by the repository
Border guards are the main end users who could directly benefit from the repository in their day-to-day border-control activities. In addition, the repository would benefit authorities in charge of checks within the territory (verifying the identity and validity of a TCN’s travel documents).
Migration authorities will be affected by the repository, whichever option is chosen, as they are the stakeholders logging the data in the system and modifying it in the event of a status change. Asylum authorities could also be affected, as they could use the information for managing asylum cases.
Consulates will be affected by the repository in the same manner as migration authorities, whichever option is chosen, as they are in charge of handling the application and issuance processes of some of the documents in scope (primarily long-stay visas).
eu-LISA will be the agency operating and maintaining the central IT system.
The European Border and Coast Guard Agency would benefit from statistics on the legal migration of TCNs holding these types of documents. This data is currently fragmented in each issuing MS, with a limited set of aggregated statistics collected by Eurostat. A central repository could support their risk assessments and their understanding of the migration flows to the Schengen Area.
Law enforcement authorities at national and European level (Europol) might be granted restricted access to the repository for investigative purposes, similarly to what already happens with the VIS, which can be consulted under specific conditions.
IT operators at national level will naturally have to adapt and test their national systems so as to be able to use the services provided by the repository.
EU citizens, although not directly concerned by this measure, are expected to benefit from the enhanced security. If residence cards of TCN family members of EU citizens are included, EU citizens will then be directly affected, as the repository would be consulted to check their family members when they cross borders.
Third-country nationals are the data subjects whose data would be copied from a national system into the central repository. For bona fide travellers, the repository would have no impact, as it would not change how these documents are issued to them and the border checks would be done in a swift and automated manner. On the contrary, they might benefit from more efficient and effective border checks, which would identify fraudsters more easily.
Law enforcement
authorities
IT operators
at national level
EU citizens
Third-country nationals
EU agencies
eu-LISA
Consulates
Migration
authorities
Border guards /
authorities for checks in the territory
Stakeholders
16
2. Methodology
Approach
This study proposes a high-level analysis of the feasibility of the repository, on operational, technical, legal and cost-effectiveness aspects. After a data collection phase, the study carries out a requirement analysis including a study of the benefits and objectives of the repository, general necessity and proportionality considerations per objective and document, the identification of the main scenarios for using the repository, and the required data sets. The options are then compared and a recommendation on the best-suited option to create a repository is provided.
Figure 5: Approach
1. Data collection phase
A desk research is the first step of the study. It consists of an analysis of available data from the following sources:
Literature review, including the legal bases of the four documents, the policy context, the studies performed in the area and other relevant material for the analysis and outline of technical options.
Consultations with DG HOME and DG JUST Objective: understand the policy and legal context of the study and confirm/infirm
research assumptions. Different meetings have been organised with DG HOME and DG JUST on the main transversal topics the study analyses, focusing on business processes, IT architecture, data protection, security and analysis of documents (long-stay visas, residence permits and local border traffic permits).
Interviews with eu-LISA Objective: understand how VIS currently works, its capacity and fit for the purpose of
the study. As the European Agency providing operational management of central VIS, the interview gave insights as for the technical aspects of the different options, such as the IT architecture, the requirements in terms of infrastructure and the pros and cons of reusing the VIS to include information on the four documents from a technical perspective.
1.DATA COLLECTION
Sources of the analysis
2. REPOSITORY MAIN
CONSIDERATIONSDocuments, use-cases, design
principles and constraints
3. OPTIONS ASSESSMENT
Documents, data structure, use-cases, security aspects
4. RECOMMENDATIONS
Preferred options and conclusions
17
Questionnaire sent to the Member States Objective: understand the study and its challenges from the point of view of the EU
Member States and the Schengen Associated Countries (further referred to as Member States), understand the “as-is” situation and gather their preliminary opinion on the purpose and use of the repository. The questionnaire was divided into five sections: a general set of questions on the current situation at external borders, the main added value for the repository and its main uses and four sets of questions focusing on the documents analysed (“as-is” situation, national repository, situation at the borders, data included…). The study incorporates the input received from 17 MS. Annex 4 provides the template of questions sent to the MS and a summary of the answers received. The study also takes into account other surveys sent to the Member States within the scope of other relevant studies in the area and within the European Migration Network, put at the disposal of the present study by DG HOME.
The information obtained was analysed to understand the as-is situation, the current challenges and to assess the different possible options.
2. Repository: main consideration
This phase looks at the objectives of the repository, the documents it would contain, the data needed to perform the use-cases, the access rights and a preliminary analysis of the required legislative changes. It also contains an overview of some aspects relating to the necessity and proportionality of the objectives, use-cases and data set of the repository.
1. An analysis of the primary and ancillary objectives achievable by the repository, in order to determine the main use-cases. The two primary objectives of the repository are facilitation of border checks and assessment of the situation of third-country nationals. They constitute the main reasons why a repository should be envisaged and why data should be gathered. The two ancillary objectives do not have an impact on the data collection; e.g. they will make use of the data and functionalities of the repository but are not the reasons why it is implemented. One of them is the contribution to the prevention and detection of serious and organised crime, allowing law enforcement authorities to access the repository and the other is the gathering of statistics and reporting activities;
2. A preliminary reflexion on the necessity and proportionality of implementing such a repository, which topic should be further analysed in a detailed risk and privacy assessment. These considerations will focus on the objectives of the repository and its data set;
3. A description of the documents, their use, their purpose and a set on considerations on whether or not it is proportionate and necessary to include them in a common repository;
4. Once the objectives and the documents are defined, the analysis then proceeds to identifying the main use-cases for accessing the repository, looking at which end-users would need to access the systems and for what end;
5. At this stage of the analysis, the study will be able to discern the data set needed for the use-cases and build the overall minimal data set of the repository;
6. The study will also look into legal considerations and the legislative changes derived from the implementation of the repository.
These points will be taken into account for the next chapter, focusing on the technical option for implementing the repository.
3. Options assessment
The three options (repository as part of VIS, repository as a separate database, repository as hybrid solution) are first described at technical level and then analysed, focusing on data protection, security, technical and architectural aspects. A general overview of pros and cons aspects opens the analysis. Their assessment is based on the following criteria:
1. Criterion 1: IT security;
2. Criterion 2: Implementation complexity;
3. Criterion 3: Cost-effectiveness.
18
Criteria 1 and 2 are further detailed into categories in order to better grasp all the aspects of the options. They will be scored on a scale of one to four, one being the lowest grade and four being the best. More explanation on the evaluation criteria is provided under Chapter 4. Options assessment.
4. Recommendations
Once all the options have been assessed, a final recommendation and justification for a preferred solution concludes the study.
19
3. Repository main considerations
This chapter presents the key considerations about the possible design of the repository. This high-level analysis is drawn following a Privacy by Design approach. In fact, the approach minimises the impact on privacy by defining the data that are required for the repository to function and achieve its objectives.
The objectives are the starting point. They drive the analysis and determine what can be done with the repository, what can be stored and for how long. By following this approach only, the necessary data are collected.
Figure 6: Design approach which derives the data to be collected from the objectives of the system
Given that this study is not intended to be a detailed design of the repository solution, there are many aspects that will have to be determined at a later stage. For this reason, this study provides some elements that will need to be taken into consideration during the preparation of an impact assessment, but does not constitute an exhaustive analysis on the necessity and proportionality of the proposed measure and its objectives. From a data protection and privacy standpoint, a thorough analysis will have to be carried out in order to justify the proposed measure.21
21 Regardless of the technical option, a detailed impact assessment and comprehensive necessity test will have to be carried out in order to justify the creation of a legal instrument that will legitimise the proposed measure. In its Necessity Toolkit, the EDPS defines this process as a “combined, fact-based assessment of the effectiveness of the measure for the objective pursued and of whether it is less intrusive compared to other options for achieving the same goal.”
20
3.1. Objectives
The following figure shows the objectives that could be set for the repository, based on the drivers for change identified in Chapter 1: the information gap, risk of fraud for long-stay and residence documents, the risk of irregular migration and the overall risk for internal security. For all the objectives listed below, the MS22 confirmed their respective interest (See Annex 4 for further details).
Figure 7: Repository's objectives
1) Facilitate checks at external border-crossing points and within the territory of the Member States
Why?
The purpose of these checks is to establish the identity of the third-country national and make sure the document presented is genuine and belongs to him/her. As such, it strongly relates to identify abuse of documents at the border: either the document(s) is authentic but does not belong to the bearer (e.g. a stolen real document is used by a look-alike) or a false or counterfeited document is presented (e.g. a false residence permit is used in order to avoid having to present a visa in case of a visa-required traveller).
The latest Frontex Risk Analysis for 201723 reports 8.267 cases of fraudulent documents being used with the intention to cross the external borders. Visas and visa stamps account for the majority of the counterfeit documents, closely followed by passports and residence permits. Residence permits represent 14% of the counterfeit documents and they have been encountered in many Member States (especially in Spain, Italy, France, Germany, Belgium and Greece)24.
Residence permits follow the same format and are secured: the residence permit document contains a chip with the facial image and two fingerprints stored in it. The current means used by border control are either to check in SIS whether the residence permit is reported as stolen, misappropriated or withdrawn, but not whether the document is false; or to check in PRADO/FADO the presented document against the samples of previously detected false documents or by checking its security features against a sample of a genuine one. The latter control is only done in case of doubt and in second line as it is a time-consuming exercise. The check that the residence permit belongs to the bearer is done by reading the facial image from the chip of the document and comparing it with the one of the bearer. In case of failure or doubt, the stored fingerprints can be accessed. However, the information on the chip needs to be checked on its authenticity which can be done by having the exchange of cryptographic certificates between countries. For accessing the fingerprints, the exchange of other cryptographic keys is necessary. Both exchanges are currently being developed at EU level but are not operational yet among all countries. In practice, the chip of the residence permit is
22 17 MS answered the questionnaire submitted
21
almost only checked by the issuing MS, which is an unsatisfactory situation in terms of security.
The unlawful use of residence cards is unknown as the card is rarely encountered at the borders. The harmonised format is not used by all Member States and some residence cards do not include strong security features; as a result counterfeit documents might possibly pass more undetected25. For residence cards, Member States are entitled to make use of the uniform format established by Regulation 1030/2002. To date, a small majority of MS makes use of this possibility. It is important to note that a residence card of a family member of a European Union citizen has to be combined with additional documents to allow the holder to travel as the latter has to "accompany or join" the Union citizen. Similarly, little information is available on abuses of local border traffic (LBT) permits26, which are only in use in eight Member States27.
Forged documents are often part of the services provided by smugglers and used by criminal networks28. They are an entry point for irregular migration and travellers with criminal intentions. This situation, together with the difficulties faced by border guards in authenticating documents that are in some cases rarely encountered, having different formats or insufficient security features create a security risk.
How
As described in section 1.3, the triangular verification (person->document->system) has proven to be a successful approach for the efficient tackling of unlawful use of documents through the correct assessment of their validity and authenticity and of the identity of the holder.
The repository, as a whitelist29 of all the valid documents issued, could support the checks at external borders and within the territory for the documents it stores. It would in fact create a triangular verification between the person, the document and the system, similarly to what already exists today with the VIS. The verification of a secure document allows only to check that the person matches with the document. This is demonstrated in the case of VIS where the use of fraudulent documents is systematically detected by the system. Without repository, the reported fraud is only the one that has been detected, usually estimated as being one out of ten or twenty false documents in circulation. For further details, see the use-cases 1 and 2 described in section 3.3.
The repository could also enable a biometric identification of undocumented TCN (as currently performed with the VIS and proposed with the EES). However, that would require a systematic collection of biometric data with sufficient quality for all documents across all Member States. Based on consultations with Member States, this does not appear to be the case currently. In fact, not all Member States collect and store biometrics and even when they do, a different number of fingerprints is collected with different quality criteria. This means that to enable such a use-case, the way the documents are issued would have to be harmonised to include the requirements of capturing and storing biometric identifiers according to common standards.
23 Available at: http://frontex.europa.eu/assets/Publications/Risk_Analysis/Annual_Risk_Analysis_2017.pdf (consulted 06/2017). 24 Ibid. p.22 25 Any statistic on detection of forgeries is bound to underestimate the actual number as it is not possible to know how many pass undetected the borders 26 Source: MS questionnaire. Only 4 MS of the 17 that answered were able to provide data on residence cards and 5 on LBT. 27 Croatia; Hungary; Latvia; Lithuania; Norway; Poland; Romania; Slovakia. 28 Frontex Annual Risk Analysis 2017 29 Currently only a black list exists within the SIS for withdrawn or stolen documents. MS can also check Interpol Lost and Stolen Travel Documents database (SLTD).
22
The following table details how the repository can help address different cases of document fraud:
Table 4: Potential benefits of the repository for tackling unlawful use of documents
Types of fraud Potential benefits from the repository
1) False document
a) Forged (authentic altered in any of its parts);
b) Counterfeit (entirely produced by the forger)
c) Stolen blanks (unissued document personalised by an unauthorised agent);
Using the repository as a whitelist of all valid documents issued, border guards would have an automated and simple tool to identify these frauds. Information altered in the document would not match what is stored centrally.
Currently only the MS having issued a document can perform this operation automatically, while other Member States need to contact the issuing MS to ascertain the authenticity and validity of a document or rely on a cumbersome and less secure manual check.
2) Genuine document
By using an authentic and valid document belonging to another person
The use of biometric data (facial image and/or fingerprints) would offer a higher level of assurance that the document bearer is the rightful owner of the document presented.
When asked about the impact of the use of fingerprints at the external borders and biometrics in the visa applications in the VIS, a large majority of the responding Member States (84.2%) agreed that the introduction of the VIS facilitated the fight against visa fraud30.
2) Assess the TCN situation and contribute to tackle irregular migration.
Why?
By confining the different applications, documents, rights associated with a certain person in different databases located in different Member States, a lot of information that could be useful for the assessments of the situation of the third-country national's in terms of migration and security is lost. This in fact prompted the European Commission to initiate a broader work to enhance the interoperability and the exchange of information across systems. For instance:
If a person had already been issued a long-stay visa, this information might be relevant when assessing a newly lodged application in a different MS;
If a person tried repeatedly and unsuccessfully to obtain a residence permit or a long-stay visa (especially if the documentation provided was forged), this situation might be a risk factor when assessing a newly lodged request for a short-stay visa. It might be indicating that the person intends to overstay. Naturally, the document’s history alone is not sufficient to draw conclusions but it does carry an informative value, especially on cases for which there is already a doubt.
Only a common European repository could give the general overview on a TCN’s past and present situation as the national records do not reflect previous documents issued or denied in other MS.
30 Data from the Report from the Commission to the European Parliament and the Council on the implementation of Regulation (EC) No 767/2008 of the European Parliament and of the Council establishing the Visa Information System (VIS), the use of fingerprints at external borders and the use of biometrics in the visa application procedure/REFIT Evaluation, October 2016
23
How
The repository could keep a history of the last documents issued to a TCN for the length of the defined data retention period. It could also store ongoing and/or previously denied applications. There would be no need to store the entire application dossier, but rather only the information that an application was submitted, the respective decision and the reason for refusal.
Linking documents and applications’ decisions from different Member States to the same person would allow the system to be person-centric, providing all the relevant information on a TCN to all Member States and not only the MS which issued or refused the documents. The history of the past documents and potentially current and past applications would be accessible for authorities in the process of issuing a new document31 (see use-case 4 for further details).
The study will analyse in the following sections the proportionality and necessity of storing the documents’ history and of storing ongoing and negative decisions on an application. This assessment will also take into consideration the differences among the documents and what data set would be needed.
3) Contribute to the prevention, detection and investigation of terrorist offences or of other serious criminal offences.
Why?
Access to the data set and possibly to the history of granted/refused documents and applications could give investigators a more complete view on an individual for investigative purposes. Biometric data, if included in the repository, could be useful for identifying a suspect.
The necessity of sharing document-related data with law enforcement authorities has been underlined by the VIS LEA Decision adopted in June 200832 whereby, both the Council and MS concluded that access needed to be granted to MS LEA and Europol ‘in order to achieve fully the aim of improving internal security and the fight against terrorism’.
Law enforcement authorities have been granted access to other systems in the Migration and Home Affairs area (VIS and EURODAC) and their access is also included for future systems (EES and ETIAS). Therefore, not granting access at all for investigative purposes to the repository would create an information gap with respect to the other systems compiling data on TCN.
How
Law enforcement authorities in the Member States and at EU level (Europol) could be given access to the data, under specific conditions. This access should be limited to certain conditions and always justified by the existence of an on-going investigation or if the access can contribute to the prevention or detection of terrorist offences and of other serious criminal offences.
31 Legal constraints might limit the possibility of this consultation to the issuance on short-stay visa or to consult only the history of the same type of documents for its issue or renewal (e.g. for the renewal of a residence permit the access would be limited to the history of previous residence permits). 32 See Council Decision 2008/633/JHA of 23 June 2008 concerning access for consultation of the Visa Information System (VIS) by designated authorities of Member States and by Europol for the purposes of the prevention, detection and investigation of terrorist offences and of other serious criminal offences
24
4) Gather statistics to support evidence based Union migration policy making
Why?
Today, statistics on these topics are scarce and rely on heterogeneous data sets and collection methods at MS level. There is a lack of quantitative data as the literature review of this study has shown. As an example, Eurostat provides data on first residence permits issued within a year but does not provide any statistic on long-stay visas, residence cards and local border traffic permits33. Even simple aggregations on numbers of documents issued, or in circulation can only be obtained by collecting them individually from each MS.
For a fact-based policy making on an essential area such as migration and border control, the capacity for analysing data across Member States is key. An EU common repository would add value to the statistics given that it would reflect the real dimensions and magnitudes of topics that transcend national borders.
How
Key statistical data such as the number of documents issued, withdrawn and in circulation could be easily extracted from the repository.
For this objective, privacy and data protection concerns would be met by anonymising data (either by masking-out a personally identifiable biographical data or depersonalising the data set). For example, the repository could offer statistics on numbers of TCNs holding any of the four documents, cases of withdrawal of documents, issuing MS…. The data could be used by different stakeholders, including policy makers.
33 See: http://ec.europa.eu/eurostat/statistics-explained/index.php/Residence_permits_statistics (consulted 05/2017)
25
3.2. Possible alternatives to the repository
It is worth to note that alternatives to a common repository could exist, although from a preliminary assessment they appear to be either less feasible or not to provide the full benefits of a common repository. The main ones are:
a) Harmonise towards a secure document format: The most likely alternative option in order to address the difficulties to authenticate long-stay and residence documents at the border, would be to focus on the harmonisation of their format including a potential overhaul of the security features so that the document authenticity can be verified more effectively at the border. In practice it would mean to extend (and possibly enhance if necessary) the work done for the standardising the format and security featured of the residence permit. This residence permit format could be seen as a model to be complied with for any other document under consideration like the residence card.
This would require a review of the legal instruments linked with the documents that are not harmonised and major costs for changes to the issuance and printing of secure documents as well as the addition of embarked chips containing both biographic and biometric data. The ongoing difficulty in exploiting the fingerprints in the passports also warn us of the hidden complexity of the infrastructure and coordination that could be still necessary in order to have a truly secure document with also biometric information.
Even with enhanced security features, the addition of a common repository would anyway provide higher security. In fact, with the increasing ability of fraudsters, documented by Frontex in its Annual Risk Analysis34, secure documents alone are unlikely to defeat frauds.
Moreover, the harmonisation of the format of the documents has no impact whatsoever on the intended objective of assessing the situation of the third-country nationals based on the applicant’s data and document history.
Harmonising and securing documents that give a right to enter and stay in the Schengen area has to be seen as a first and indispensable step for making sure EU migration policy as implemented in the current legal framework is applied. However, once harmonised and secure documents are used, the issuance process becomes the main target of fraudsters as described by Frontex Annual Risk Analysis:
"Migrant smugglers frequently abuse legal channels to facilitate the entry of irregular migrants to the EU or to legalise their stay. The abuse of legal channels involves a variety of modi operandi including sham marriages, bogus paternity claims, false employment contracts, fake invitation letters, false medical visas, and false claims of being a refuge or a victim of human trafficking. In many cases, migrant smuggling networks operate as legal business structures in the EU, such as travel agencies, to produce fraudulent paperwork which allows irregular migrants to obtain work permits. These methods have proven very successful for the networks involved and their use is expected to further increase in the future.35
To make sure the issuance process is not abused by false declarations and the submission of false documents one of the mitigation strategies is to ensure systematic cooperation between MS administrations. Therefore, stronger documents, might actually increase the need to exchange information among Member States, ultimately increasing the added value that a repository would bring.
b) Distributed database: A second alternative could be the creation of a distributed
database which would allow for all MS to query each other’s relevant databases when assessing a long-stay or residence document and a document holder at an external border crossing point. Although this option would remove the need for a centralised repository it would require a complex architecture and integration.
34 Frontex Annual Risk Analysis 2017, page 22, http://frontex.europa.eu/assets/Publications/Risk_Analysis/Annual_Risk_Analysis_2017.pdf 35 Frontex Annual Risk Analysis 2017, page 17, http://frontex.europa.eu/assets/Publications/Risk_Analysis/Annual_Risk_Analysis_2017.pdf
26
This alternative could be applicable to both objectives of border control and assessment of the TCNs situation as Member States already store the documents in their national databases. However, this alternative would not be less intrusive than the proposed measure as all Member States would similarly have access to the document data contained in other Member States databases.
This solution is likely to be expensive, complex and with major difficulties deriving from the different governance, legal basis and technical solution used across these systems. Moreover, it would not allow for any re-use or synergies with the VIS.
In section 3.8, these alternatives are considered when assessing the data protection framework.
27
3.3. Use-cases
The figure below provides an overview of the main use-cases36 derived from the analysis of the repository’s objectives:
Figure 8: Taxonomy of the use-cases
Their detailed descriptions are provided hereafter.
3.3.1. Verify the authenticity, validity and status of document issued by another MS
Table 5: Use-case 1
End-user Border guards (or police for checks within the territory)
Trigger events
Arrival at the border of a TCN holding a document issued by another MS (1st line border checks);
Checks within the territory of the travel document and long-stay or residence document.
Description
Verification by MS A that the document issued by MS B presented by the TCN is authentic and still valid:
1. Officer logs in the repository through its national system;
2. Queries the system by scanning the MRZ of the passport37 or using the identifier of the document (long stay visa or residence document);
3. If the document is found, then the system returns the data on the status (valid, expired or withdrawn), the validity of the document (e.g. “date of expiry”, “valid until”); If the query was done with the MRZ of the passport then the list of valid documents associated to it is returned.
4. Officer compares the status and validity against the data on the document and takes a decision on granting entry or relaying the TCN to 2nd line check (note: this check can be performed manually or by the system, depending on how the interface is programmed).
Data The following data is necessary to be able to query the system and to avoid ambiguity
36 Differently from the VIS, the repository would not be a case management system. Therefore, it would not need to support the entire application process, including the consultation of other MS. For this reason, functionalities like the ones implemented by the VIS mail are not relevant. 37 For instance, residence card holders can travel without having a passport with them.
Assess the situation of TCN and contribute to tackle irregular migration
Support the investigation of a serious and organised crime
Facilitate border checks
Use of the data for reporting and statistics
2
3
4
1Use-case 1: verify the authenticity, validity and status of a document issued by another MS
Use-case 2: verify that the bearer is the rightful owner of the document
Use-case 3: store and update document information
Use-case 4: consult the history of documents and/or decisions on applications
Use-case 5: consultation for law enforcement purposes
Use-case 6: reporting and statistics
Objectives Use-cases
28
(document number for instance is not unique, therefore it is necessary to use additional data such as the issuing country and the date of birth of the person to ensure the right match).
Document data (number, validity date, issuing country);
Biographical data (name, surname, date of birth, place of birth, nationality);
List of the valid documents associated to the person (if the query is done using the passport, then multiple documents could be valid).
Remarks The repository should then be queried with the passport number only and with the document number (and possibly other fields contained in the document) only.
3.3.2. Verify that the bearer is the rightful owner of the document
Table 6: Use-case 2
End-user Border guards (or police for checks within the territory)
Trigger events
Arrival at the border of a TCN holding a document issued by another MS (1st line border checks);
Checks within the territory of the travel document and long-stay or residence document.
Description
Verification by MS A that the TCN is the rightful owner of the document issued by MS B.
1. Officer logs in the repository through its national system;
2. Queries/scans the MRZ of the passport or identifier of the document;
3. System returns a set of information on the TCN found
4. Officer verifies if the biographical information matches the one in the passport and in the document;
5. (in case of biometric data is available38): compare the fingerprints/facial image of the TCN against the ones stored in the repository or against the ones stored in the document.
Data
See use case 1 (which would take place simultaneously) plus the addition of biometrics (facial image or fingerprints).
Biometrics would allow performing the bearer verification independently of the passport. This verification could be done either against the common repository or against the ones stored in the document itself, when the document allows for the possibility and the Member States have access to the cryptographic certificates that authenticate the chip for reading the facial image or to authenticate and access the fingerprints as these have a more complex access protection than the facial image. The feasibility of using biometrics is further assessed under the Data section (3.5).
Remarks
This check is done in parallel of the checks performed in the first use-case described above.
This use-case offers end-users another data set to check the information presented (document and passport). After verifying the biographical information, the officer compares the photograph with the bearer of the document. However, it does not prevent the cases of unlawful use of the document by a similar looking individual if the passport and the document data set are the same. Only the use of biometric data (facial image or fingerprints) can really ascertain the identity of a person.
38 See Section Data 3.4. The use of fingerprints is unlikely given the current diversity present at MS.
29
3.3.3. Store and update document information
Table 7: Use-case 3
End-user Migration and consular authorities (in the territory and at consular posts)
Trigger events
Updates made in the respective national system, such as:
- Log a new application for a document39;
- Modify the data set of an application already existing;
- Modify the status of an application already logged in the system and confirm decision (document granted/application accepted or refused);
- Log a new issued document;
- Modify the data set of an issued document;
- Modify the status of an issued document: withdrawn, extended;
- Delete the data.
- Request by the concerned TCN for correction or deletion of the data in the system.
Description
1. Migration officer works on its national system;
2. Processes the data:
a. Creation of data (e.g. logging an application40 or a newly issued document);
b. Amendment of data (e.g. status of the document);
c. Deletion of the data.
3. The changes are replicated automatically into the central repository;
Data
Biographical data
Document data
And additional logging data, including the record of the time of the changes.
Remarks
Member States have the ownership of the data they insert in the repository and are responsible for its management. MS can only read the data inserted by another MS, and only the MS that logged data can then make changes to it. Data quality and accuracy is key for reaching the set objectives.
All or at least the majority of these operations should be performed automatically by the system. It would avoid an important burden on the national authorities and therefore increase data quality and accuracy. An automatic data consistency / synchronisation process will ensure that the repository always correctly replicates the relevant data contained in the national systems.
The repository would not contain data that is not already included in a national repository. This also means that the repository should not have a data retention that is longer than the national systems. If that was the case the migration officer would not be able to change the data using the national system only.
39 This and the following three points related to applications are relevant only if the history of decisions will be stored in the repository as well, as opposed to only storing the valid documents. 40 Different options are possible. The repository could be used to log all the applications
30
3.3.4. Consult the history of documents and/or decisions on applications
Table 8: Use-case 4
End-user Migration and consular authorities (in the territory and at consular posts)
Trigger events
A new application for a document has been submitted: the officer logs the application and consults the repository for possibly previously issued document and/or rejected applications (if the history of past decisions were to be part of the data set of the repository) or withdrawn documents for the TCN in other Member States (including short-stay visas);
Description
1. Officer logs in the repository;
2. (if available) System returns a list of all previous41 and valid documents and/or the rejected applications of the same TCN, along with reasons for the relevant changes of their statuses;
3. (if needed) Officer of MS A contacts officer of MS B responsible for a file to request additional information.
Data
History of previous documents and/or decision on applications:
Previous valid documents;
Application refused (within the data retention period) and the respective reason for the refusal.
Remarks
Although the repository does not aim at being a case-management system like the VIS, the information that this use-case can offer could be of use for the national assessment of an application. All the documents and applications could be linked via a common identifier similar to the dossier number as currently used in VIS.
Given the different nature of long-stay and residence documents compared to short-stay visas, it is important to note that:
the grounds for refusing a long-stay or a residence permit’s application are much wider and complex than the reasons for refusing a short-stay visa. Similarly, withdrawing an issued document or refusing an application does not necessarily mean that the TCN no longer meets the conditions to legally stay in the Schengen Area. In order for this use-case not having a negative impact on the TCN, it is important to store the reasons for taking a negative decision;
residence cards are granted to TCNs who are family members of EU citizens. This right derives from the freedom of movement and is not conditioned to other circumstances (employment situation, studies…). As a result, the grounds upon which the residence card is issued are only based on the proof of family ties to a EU citizen. It can thus be concluded that this objective/ use case would not apply to them.
3.3.5. Consultation for law enforcement purposes
Table 9: Use-case 5
End-user National law enforcement authorities
Europol
Trigger event Investigation: need to access the database concerning a particular case of serious and organised crime or terrorism
Description 1. Officer is granted access to the repository;
41 limited by the data retention.
31
2. Officer logs in the repository; 3. Queries/Enters the document number, biographical data or biometric data (if
available); 4. (if there is a hit) System returns the file on the TCN.
Data All the data stored of the person under investigation
Remarks
This use-case is conditioned to an access request sent by the national authority and including the reasons why accessing the data can contribute to the prevention, detection or investigation of terrorist offences and of other serious criminal offences. Due to the current lack of homogeneity in biometric data (fingerprints) collected by Member States, law enforcement access will be used primarily for investigative purposes and not identification purposes. This could be re-assessed should the collection of biometrics be harmonised in the future. VIS, EURODAC, EES and ETIAS, propose law enforcement access rules and governance that could be used as a model for the repository. These databases store information of similar nature and for similar purposes (ultimately they are all systems that support Schengen border management activities) and in all these cases it was necessary to prevent indiscriminate access for law enforcement purposes to the data of millions of innocent people, a comparable situation to the one of the repository.
3.3.6. Reporting and statistics
Table 10: Use-case 6
End-user Competent national and EU authorities
Trigger events
Periodic statistics on the repository’s functioning (number of records, performances, data quality indexes, etc.);
Periodic statistics on the documents stored (number of documents issued, in circulation, withdrawn, etc.);
Ad hoc reports on any specific aspect (e.g. number of long stay visas issued per Member State in the last 6 months);
Description
Modern databases and systems allow to extract reports easily on the functioning of the system and to perform any type of statistical extraction needed. The raw report could be coupled with visualisation tools that could help understanding trends over the time or geographical distributions.
Data Key performance indicator of the system Anonymised statistics
Remarks Reports and statistics would not contain any personal data nor any information that could be traced back to a specific individual.
32
3.4. Overview of the relevant documents
The following table summarises the analysis performed in this section, highlighting differences and similarities between the four documents in scope:
Table 11: Fact sheet representing the summary analysis of the four documents
Long-stay visas
Residence permits
Residence cards42 Local border
traffic permits
Use
TCNs staying in the Schengen Area for a longer period than the one allowed with short-stay visas
TCNs residing in the Schengen Area for a period longer than 90 days
Issued to family members of mobile EU citizens but who are TCNs
Issued for residents of a border area to the Schengen external borders.
Checks at issuance
Checked against SIS at application stage
Not systematically checked against a European database at application stage
Checked against SIS at application stage
Checks at the
external borders
Checked at external borders against the national database of the issuing country
Subject to the checks applying to persons enjoying the right of free movement (i.e. Exempt from the entry visa requirement when the TCN has a nationality that is visa-required)
Not systematically checked and entry or exit stamps are not affixed
Validity Maximum 1 year
Durations can vary from 90 days to permanent according to MS legislation
5 years, then right to permanent residence card, renewable automatically every ten years
From 1 to 5 years and only valid in the relevant border area of the issuing MS
Format
Uniform sticker
Security features defined in the regulation
No required biometrics
Uniform stand-alone document
Minimum security features are defined in the regulation
Biometrics: facial image and two fingerprints
Not uniform
No minimum security features
No required biometrics
MS can adopt the format of the residence permit.
Uniform (minimum data set defined)
Same security features than the residence permits
Biometrics: facial image and two fingerprints
Issued and valid
in Schengen States
Member States of the European Union and Norway, Iceland and Liechtenstein.
Schengen States with a land-border with a non-EU MS43
Volumes (issued
per year) ≈ 1 million44 ≈ 2 -3 million45 ≈ 300 thousands 46
Few hundred thousands47
Annex 5 includes a comparison of the mandatory data for each of these documents.
42 In this study always intended as Residence cards issued to family members of mobile EU citizens but who are TCN 43 Schengen States, SAC and EU MS not fully implementing the Schengen acquis. 44 See : https://ec.europa.eu/home-affairs/sites/homeaffairs/files/what-we-do/networks/european%1F_migration_network/reports/docs/emn-studies/migration-channel/de_20120510_visapolicy_en_version_final_en_pdf 45 Source: Eurostat 46 “Study to Support the Preparation of an Impact Assessment on EU Policy Initiatives on Residence and Identity Documents to Facilitate the Exercise of the Right of Free Movement, DG JUST 2017 47 Extrapolation from the limited data available. Just Poland issues 120 000 per year.
33
3.4.1. Long-stay visas
Long-stay visas are issued to TCNs who wish to stay in the territory of a Schengen country for a period of between 91 days to one year. Regulation (EU) No 265/2010 extended the principle of equivalence between residence permits and long-stay visas issued by the Member States fully implementing the Schengen acquis. Holders of long-stay visas can thus travel to another Member State for 90 days in any 180-day period (length of a short-stay visa), under the same conditions as residence permit holders.
Format
Regulation (EC) No 1683/9548 establishes a uniform format for long-stay visas: a sticker that needs to be affixed to the travel document (passport) of third-country nationals. The figure below shows a model of long-stay visa:
Figure 9: Model of a visa sticker, as per Regulation (EC) No 1683/95
Security features
The sticker includes a minimum of security features, specified in Council Regulation (EC) No 1683/95.
Biometrics:
No legislative provision for the collection of biometrics. As the long-stay visa is a sticker to be attached to the passport, the biometrics of the passport can be used for the bearer verification.
Some MS still collect fingerprints (a variable number depending from the MS) and facial image. However, in some cases no biometrics are collected at all or they are deleted shortly after the issuance of the document (e.g. after 90 days).
3.4.2. Residence permits
Residence permits are issued to third-country nationals residing or staying in an EU Member State for more than 90 days. There are many types of residence permits49 issued by Member States depending on the purpose of the stay. There are an estimated 19 million residence permits in circulation50. This study only takes into consideration residence permits issued by Schengen Member States and thus valid in the Schengen Area.
Interactions between residence permits and long stay visa
Residence permits can directly be granted to TCNs or can also be issued after a long-stay visa. Although in many Member States the application for a residence permit can be submitted at the
48 This regulation will soon be replaced. 49 See: Annex 22 of the Schengen Borders Code for the complete list: https://ec.europa.eu/home-affairs/sites/homeaffairs/files/e-library/documents/policies/borders-and-visas/schengen/docs/handbook-annex_22_en.pdf (consulted 05/2017) 50 Data for 2015, available at: http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=migr_resvalid&lang=en (consulted 05/2017)
34
consular posts, only 3 out of 17 Member States who answered the questionnaire issue the document outside their territory. TCN are in most cases issued a long-stay visa in order to cross the external border of the Schengen Area and when residing in the Member State obtain their residence permit. After a few months the residence permit replaces the long-stay visa. As a result, a TCN could potentially have two logs in the repository for each document, both being valid at the same time.
There may also be situations where a TCN has two residence permits at the same time issued by two Member States. One example is under the ICT Directive (2014/66/EU), where a TCN is issued a residence permit in the MS where he/she applied, but may get a second permit if he/she goes to another MS for "long-term mobility". Both would be valid at the same time.
Format
Residence permits are issued in a uniform format51 as specified in Regulation (EC) No 1030/2002 as amended by Regulation (EC) No 380/2008. The Regulation establishes two models of documents that include cards. The sticker format is no longer issued.
Figure 10 Residence permit (Finnish) as a stand-alone document
Security features
The document includes standard security features specified in the relevant Regulation. Member States can add additional security features, provided that they do not undermine the value of the uniform format. Regulation (EC) No 380/2008 adds biometrics (facial image and two fingerprints) which strengthens significantly the robustness of the document.
Biometrics:
Regulation (EC) No 380/2008 specifies that the following biometrics shall be taken and stored within the document:
Facial image, taken in accordance with ICAO standards
Two flat fingerprints.
Some Member States store additional biometrics within their national databases (e.g. 10 fingerprints). However, some Member States also delete the biometrics after their inclusion within the document.
3.4.3. Residence cards
The nature of residence card of a TCN family member of a Union citizen differs from residence permits and long-stay visas. They materialise a primary and individual right granted to TCNs who are family members of EU citizens in order to accompany and join their EU family member who moves to and or resides in the territory of the Member States (mobile EU citizens)52. As a result, this document is mostly regulated under the freedom of movement acquis and not fully by the migration policies and thus applies to EU Member States and not only to Schengen
51 A new uniform format is under works and should be adopted by September 2017 52 It is important to note here that the study’ scope is limited to residence cards issued to TCN. Indeed, a MS can, on a voluntary basis and upon request of the Union citizen, issue a residence card to a EU citizen living in its territory.
35
States (as opposed to long-stay visas and residence permits). Therefore, TCNs who are family members of EU citizens not living in the Member State of their nationality possess a derived right to free movement regardless of their nationality. This right is regulated by Directive 2004/38/EC (hereinafter “the Directive”). There is however a consequence on border management as family members of Union citizens are subject to the same checks at the external borders of the Schengen area as EU/EEA and CH citizens while the quality of family members may be proven by the residence card.
There are two types of documents; residence cards and permanent residence cards. After five years residing in a Member State, the TCN shall have the right of permanent residence and the card shall be renewable automatically every ten years. It is relevant to note that some Member States issue permanent residence cards for an unlimited period of time (4 out of 28)53. Although the validity is indefinite, in many MS the card itself is only valid for 5 years. The only condition to assess the renewal of a permanent residence card is assessing if there has been continued residence in the MS (no absence of more than 2 years).
Format
Residence cards are not issued in a uniform format and are the least harmonised document in the scope of the study. Nevertheless, a majority of Member States issues residence cards in the same format as residence permits.
Security features
No minimum security features are currently mandatory.
Biometrics
As no legislation regulates the format and issuance of the residence cards, the situation at MS level is fairly heterogeneous:
Currently, around half of the Member States (13 out 28)54 issue residence cards with no fingerprints. Although this number has been increasing over the years, the situation is not sufficiently harmonised as to include fingerprints in the repository and proceed to the identification of TCNs with this type of data;
There is still much diversity within the Member States in terms of use, storage and retention of biometric data:
o Half of the Member States do not store fingerprints, one MS does not store them in the same repository as the alphanumerical data, another stores them only in the card itself and others only stores them for the application process and deletes them once the document is issued for instance;
o The photographs are usually stored in the national repository. In these cases, they would be used as a biometric identifier;
53 “Study to Support the Preparation of an Impact Assessment on EU Policy Initiatives on Residence and Identity Documents to Facilitate the Exercise of the Right of Free Movement, DG JUST 2017 54 Ibid
36
Figure 11: Residence card for a family member of a mobile EU citizen (Luxembourgish version left,
Spanish version right)
3.4.4. Local border traffic permits
TCNs living in a border region of a Schengen State55 and who need to frequently cross the border for justified purposes can apply for and travel based on a local border traffic permit (LBT). The LBT aims at simplifying their frequent border crossings if they can demonstrate a good reason for it. The aim is to avoid creating barriers to trade, social and cultural interchange or regional cooperation with neighbouring countries. They allow TCNs to travel up to 30 kilometres (and sometimes up to 50 km) within the neighbouring MS and stay in that area for an unlimited period of 90 days. The precise duration of the stay is determined in the specific Local Border Traffic agreement. The permits are valid between one and five years. This permit and the conditions to be fulfilled are defined in Regulation (EC) No 1931/2006. The local border traffic regime derogates (art.40 Schengen Borders Code - SBC) from the general rules on border checks for TCN at the external borders of the Member States of the EU, which are set out in the SBC. Today 13 bilateral agreements56 at the initiative of nine Member States or Schengen associated countries are in force as shown in the table below:
Table 12: Local Border Traffic Agreements
Member State Neighbouring country
Croatia Bosnia-Herzegovina
Hungary Ukraine
Latvia Belarus, Russia
Lithuania Belarus, Russia
Norway Russia
Poland Ukraine, Belarus, Russia
Romania Ukraine, Moldova,
Slovakia Ukraine
55 Schengen Member States, SAC and EU MS not fully implementing the Schengen acquis. 56 Data from DG Home (May 2017).
37
Format
As for the format, the Regulation lays down the minimal data that the permits should contains (art. 7.3) and states that the security features should be the ones of the uniform format for residence permits (Regulation No 1030/2002). The following figure shows a model of LBT permit:
Figure 12: Model of a local border traffic permit issued by Norway to Russian citizens residing in the border area57
Security features
LBT must implement the same security features as the residence permits.
Biometrics
As LBT have to implement the same security features as the resident permits, they should also include facial image and two fingerprints. However, from the answers received from Member States, it appears that not all of them do (two Member States answered that they do not collect fingerprints at all).
3.4.5. Inclusion in the repository
This section addresses the question whether or not for each of the documents examined there are enough expected benefits to include them in the repository and what would be the respective challenges.
For all the documents analysed above, the variety of formats and the different security features make it very difficult for border guards to verify their authenticity and validity at the borders. Should further harmonisation of the documents and the inclusion of advanced security features (such as biometrics cryptographically protected against alteration) be achieved that would mitigate the issue of document fraud.
Long stay visa and residence permits
Added value
The volumes (2-3 millions of residence permits issued per year) and the incidence of fraud (visas and residence permits follow passport in document fraud)58 indicate that there would be significant benefits from the increase in security
Allow MS to have an automated way to check also the documents issued by other MS, which given the volumes could facilitate border checks significantly.
57 Source: http://www.consilium.europa.eu/prado/en/NOR-J-01001/image-259789.html (consulted 01/05/2017) 58 Source: Frontex Annual Risk Analysis 2017
38
Challenges
Scope: Schengen States59. The legal basis would in principle allow them to feed and consult the database for both the objectives in scope. Denmark is considered here as an exception as the MS would need to opt-in in order to be allowed to use (both feeding data and accessing) the repository.
Data: harmonised (see Annex 5 for a full comparison of the data set).
Biometrics: while for residence permits the situation is clearer as all include at least facial image and two fingerprints on the permit, the situation is much more diverse for long stay visas for which there is no obligation. For both documents nevertheless some MS delete the biometric data from their national system once the document is issued or shortly after.
Privacy: the measure would have limited impact for the privacy of the data subjects as their data is already stored in national databases and access by other Member States from the repository would be limited to the respective decisions, and not include the supporting documents and the information part of the application process. The purpose would remain for border checks and assessment of a TCN’s situation. On the other hand, the central storage of biometrics (should it happen) and the possibility to give access to law enforcement will require specific attention and safeguards.
Legal: no challenges from a border control point of view. On the other hand the legality of consulting the history of documents / decision during the application process is debatable (see Section 3.7 Legal for further details) as the repository is not supposed to change the conditions for granting long-stay visas and residence permits.
Conclusions A common repository would not encounter major blocking points and their inclusion
would bring added value. Member States also confirmed their interest during the consultation60.
Residence cards
Added value
Limited data is available on the fraud linked to this document.
The volumes associated with this document are low.
The lack of a uniform format (although MS could opt for the one of the residence permits) and the rarity with which it appears at the borders undermine the level of security of the manual check
Residence cards allow the bearer to benefit of the freedom of movement, thus the importance of being able to check them effectively, as it might leave a non-controlled entry point for people that are not bona fide.
Challenges
Scope: Member States of the European Union and Norway, Iceland and Liechtenstein. All these countries would have to feed and consult the system, however, as the objectives 1 and 2 (see Section 3.1) might have as legal basis article 77 and 79 of the TFEU, Ireland and United Kingdom would not be able to consult and feed the system. Denmark would also have to opt-in to be able to use the system. If residence cards were not part of the scope of the repository, no connection to Ireland and United Kingdom would be needed.
Biometrics: Biometrics are not consistently collected and stored by Member States, nor are always stored on the documents themselves.
Privacy: the measure would have limited impact for the privacy of the data subjects as their data is already stored in national databases and access by other Member States from the repository would be for the purpose of border checks. On the other hand, the central storage of biometrics (should it happen) and the possibility to give access to law enforcement will require specific attention and safeguards.
Data: lack of harmonisation. There would be limited rationale to store the history of
59 The possibility to impose an obligation on MS not yet fully applying the Schengen acquis to feed the repository with data on the documents they issue should be further assessed. 60 On a scale from 1 to 4, where 4 was very relevant, MS have answered 4/4 for residence permits and 3.7/4 for long stay visa.
39
past decisions for this document as the cards materialise a right and its issuance is not subject to the same type of assessment (migration and security) as for the different visas or residence document.
Legal: UK and Ireland would probably be unable to consult the database for border checks as they opted out of article 77 of the TFEU (see Section 3.7 Legal for further details). It would need to be further analysed whether Art 21 TFEU would be the correct legal basis.
Conclusions
To include residence cards in the repository would require addressing the challenges listed above. The effort to include this document type would be important, although SIS has demonstrated how it is possible to manage different access rights. The main added value for including them in the repository stems from the lack of a mandatory uniform format and security features. Should that be remedied, then the benefits from the inclusion in the repository would be further eroded.
For the remaining of the analysis the document will be considered as part of the repository, in order to further assess the implication of their inclusion in the repository for the implementation options.
Local Border Traffic Permits
Added value
The limited data available provide no evidence of fraud linked to this document.
Low volume of documents with high volume of border crossings.
The territorial validity is limited to the border area of the issuing MS. LBT holders cannot cross any other external or internal borders and the border guards can therefore not be confronted to a LBT permit issued by another MS. If a LBT holder is found in another MS he/she would already be misusing the document and the repository would be of no use;
Systematically checking the LBT permits vs the repository at the external borders would be contrary to the primary objectives of the document, which is to facilitate the border-crossing of border area residents who have a legitimate reason to regularly enter to or stay in a limited adjacent area of a single Schengen Member State;
LBT permits are mandatorily kept in a national repository. The exchange of information with other MS based on bilateral requests is provided by the Regulation. In that sense, the repository would duplicate the data kept at national level for the same purpose (e.g. MS A enquiring MS B about a local border traffic issued by the latter);
Challenges
Scope: Schengen States with a land-border with a non-EU MS.
Data: the data is harmonised so no particular challenge is envisaged.
Biometrics: while the LBT must implement the security features foreseen for the residence permits (hence collect and store in the document the facial image and two fingerprints) the result of the consultation with MS presented a much more diverse situation as not all MS collect and store the same biometric data (see Annex 4).
Privacy: the measure would have limited impact for the privacy of the data subjects as their data is already stored in national databases and access by other MS from the repository would be for the purpose of border checks. On the other hand, the central storage of biometrics (should it be done) and the possibility to give access to law enforcement will require specific attention and safeguards.
Legal: no challenges for the border control.
Conclusions
The added value of a common repository is low as the documents have limited geographical validity: the LBT does not create a right to circulate in the EU (or Schengen Area) and hence this document does not need to be controlled in another area than the border area of a particular MS. In addition, there is little evidence of abuse and the MS who issued them and within which a particular LBT is valid already do have national databases which can be used for controlling the document
40
authenticity. This view was confirmed by MS61 in their answer to our questionnaire.
For the remainder of the analysis the document will be considered as not part of the repository as there would be insufficient benefits from its inclusion.
61 17 MS answered the questionnaire. The average score, on a scale from 1 to 4 (very important), was 2.
41
3.5. Data
3.5.1. Data set
Within Annex 5 the study lists the minimum data set contained in each document. This data set stems from the legal texts on the uniform format and partial harmonisation of long-stay visas, residence permits and local border traffic permits although this last document will not be considered further in the study. As no legal text harmonises the format, and thus the data set, of residence cards, the study will consider the passport’s MRZ data and the validity period as the only data set available. When compared to the data contained in the VIS, a repository of long-stay and residence documents would have a much smaller data set.
As not all fields are present in all documents, the data set should then contain at least the data that are common to all the documents and that is necessary to enable the use-cases presented earlier in Section 3.3. The following figure shows a preliminary data set for the repository:
Figure 13: Repository's possible data set
These fields are for most part the information that is present on the document and or the passport, and which would be needed to allow to authenticate the document present within the border check and to reduce the possibility of ambiguity when querying the system.
The history of documents and decision data on past or ongoing applications is necessary to achieve the objective 2 (see Section 3.1). The study analyses in the following sections the proportionality and necessity of storing either only the history of valid documents or also the negative decisions on applications previously lodged.
History of documents and of decisions on applications
History of issued documents
An option would be to include the history of only the issued documents (and not the cases where the application is rejected) in the central repository for the purpose of assessing new applications by the same applicant data subject. Consequently, a MS assessing an application from a TCN will be able to see whether the TCN is or was the holder of another document issued by another MS. This information should be made available only to the MS migration authorities.
Biographical data
1. First name2. Last name3. Date of birth4. Nationality5. Sex
Biometric data
6. Facial image*
Document data
7. Travel document (passport) number8. Unique identifier9. Type of document (long-stay visa, residence permit or residence card)
10. Issuing MS11. Validity period12. Status(valid/extended/withdrawn)
13. Reason for the withdrawl
Decisions data
15. Decision on an application (rejected)16. Authority that took the decision17. Date and time of the decision18. Reasons for the negative decision
Data generated by the repository
14. Personal identification number
* Might not be always available currently in national systems, especially for residence cards
42
History of decisions on applications
As described in Section 3.1, the application history may very well provide clear early risk indicators. The issuing authority would be able to confirm whether the applicant has a track record of past long-stay visas and/or residence documents applications in other MS.
For the specific case of past negative decisions, it must be taken into account that the grounds for refusing a long-stay or residence document’s application are much broader and complex than the reasons for refusing a short-stay visa. In order to give a full picture to the migration authorities of other Member States of the situation of a TCN, it will be essential to document the justification of past refusal decisions. Unless the motivation for the refusal is unequivocally explained, this element may prove misleading for the authorities in the other MS.
To justify the collection and storage of the history of decisions on the applications lodged by a person is difficult as there are no specific figures.
Without such figures that provide an assessment of the proportion and nature of the security and migratory threats that stem from this information gap between MS, a statistics and number-based justification is unlikely. However, according to the Frontex’s Annual Risk Analysis, the majority of the illegal stayers detected originally entered the Schengen Area legally62. This supports the idea that a more efficient vetting of the applications might be of help reducing the number of illegal stayers.
The lack of a formal mechanism through which MS can systematically exchange information on the history of past applications may be considered as a weakness in the border management of the Schengen Area as it may lead to the assessment being done on the basis of incomplete information.
Conclusion
In conclusion, the collection and storage of application and/or document history constitute a particular use case that, by providing complementary input in the decision-making process of immigration authorities, would reinforce the central repository as an effective tool to fight irregular migration and frauds at the borders.
Biometric data
The analysis of documents in Section 3.4. and the answers received from the Member States in Annex 4 show that the collection and storage (either centrally or in the document) of biometric data is very heterogeneous between Member States (number of fingerprints collected, whether or not the photograph can be used as a facial image, biometric data not captured for all documents, fingerprints stored in a different database than the biographical data…).
The general lack of biometric identifiers also contrasts with the vision of border management systems that are person-centric as opposed to document centric. It limits the possibility of reconciling the information of people having multiple passports, having changed name or with other identities.
Table 36 in Annex 4, provides an overview, of which biometrics are consistently captured and stored. The results are based on 17 answers received from Member States. Further investigation and consultation with the Member States would be required, should it be decided to import biometrics into the repository, to have more details on what is stored in their national databases, in which format and at what quality.
Fingerprints
There are two main use cases for fingerprints:
Verification (1:1). The verification confirms that the bearer of the document is the same person as recorded in a reference system. This is currently done with the VIS at the border crossings on the basis of one or two fingerprints.
Identification (1:n). The identification searches on the basis of a fingerprint set the matching occurrences in the complete reference system. To make this search yield a sufficiently small response (ideally a single one), more than two fingerprints need to be submitted once the
62 Frontex Annual Risk Analysis 2016, http://frontex.europa.eu/assets/Publications/Risk_Analysis/Annual_Risk_Analysis_2016.pdf
43
number of identities becomes large (a few millions). In the case of VIS, a complete 10-fingerprint set is used and proves effective.
According to the answers collected some Member States do not store the fingerprints in their national database of documents issued and delete them as soon as the document has been issued. In the absence of harmonisation between Member States and in light of the current situation, it is unlikely that the repository will be able to make systematic use of fingerprints for neither verification nor identification.
However, between 2011 and 201763 Member States reported an increase in the collection and storage of fingerprints. This trend together with the progressive harmonisation of documents might open the way for a later inclusion of fingerprints in the system. Further considerations, especially on data protection, should be undertaken as to whether or not it would be feasible to use biometric data only in the cases of documents containing such information.
Facial image
Long-stay visas and residence permits include a facial image and the majority of Member States store them in their national repositories (the situation is still not that homogeneous for residence cards). The facial image, if stored in the common repository, could be used as a biometric identifier for what was described previously as the (biometric) verification (1:1) and this applies to border check processes, both for automatic matching and manual comparison.
Finally, biometric identifiers (facial image or fingerprints) might be included in the documents themselves, similarly to what is currently done for the residence permits. This could allow performing a local verification, diminishing the need to include them in the repository. However, that would also entail that MS can exchange the cryptographic certificates to retrieve and authenticate the data stored.
3.5.2. Access
With this preliminary data set, the study now determines which types of data are needed for which end-users (on the basis of the use case described earlier in Section 3.3) and accessible under which conditions. The following table summarises this assessment and uses the definition of data accessed from figure 13:
Table 13: Data set per use-case and stakeholder
End-user Use
cases Data accessed Conditions
Border guards Verify authenticity of the document and identity of the holder view only
1, 2 Biographical data;
Biometric data; Document data.
Limited data access when performing 1st and 2nd line border checks
Migration authorities Maintenance of the document information in the repository by the issuing MS create, modify, delete
3 Full data set R&W access to the files created by the respective MS
Migration authorities Consult the history of either documents only or documents and applications (according to option taken) view only
4
Biographical data; Document data;
History of the documents and applications;
Data generated by the repository.
Not applicable to residence cards
Law enforcement authorities Consult a file
5 Full data set Restricted access for national law enforcement authorities and conditions
63 As stated in the Chapter 2 Methodology, this study analysed MS answers to two European Migration Network (EMN) questionnaires (one from 2011 and another from 2017), as well as another questionnaire sent in 2017 and tailored to the study.
44
view only limited to the exercise of the mandate for Europol
Relevant EU authorities Reporting and statistics view only
6
Anonymised/masked out biographical data; Document data;
Data generated by the system.
Anonymised data
3.5.3. Data retention
The retention period of the data will depend on the main objectives chosen for the repository:
1. If it were used only as a border check tool, then there would be no justification to keep the data for longer than the lifecycle of the document. The purpose is to be able to ascertain the authenticity and status of the document whilst it is still valid. If a document is no longer valid or has been withdrawn, a “no match” in the repository would indicate the invalidity to the border guards or officers. As a result, from a border control perspective all the data can be deleted from the repository once the document ends its lifecycle (end of validity period/withdrawal).
2. If migration authorities are granted access to the history of documents and applications (according to the case), there would then be a need for a data retention period. This objective is only achievable if the data is retained.
As the primary goal of the initiative was not creating a repository of documents for law enforcement authorities nor for statistics and reporting, these two objectives will not have an incidence on the choice of data retention period.
The repository’s data retention period, if the second objective is retained, could be set for a period that could range from three to five years, a period comparable to the VIS, which is also used to check the history of previous applications and documents and has a data retention of five years, and that is meaningful compared to the long duration of the long-stay documents.
The data retention period would be counted from:
The expiry date of the document;
The new expiry date of the document, if the document has been renewed, extended, modified;
The date of the withdrawal of the document;
The date of a negative decision on an application.
After this period of retention, the data shall be deleted automatically.
The data retention of the repository should not exceed the data retention of any of the MS’ systems. If that were to happen, national authorities would not be able to change or delete data through their own systems but would have to connect directly to the repository which would then contain data that is not included in the national system. This might be particular critical should it be decided to store biometrics (e.g. facial image) as some Member States delete them shortly after issuing the document.
45
3.6. To Be process
In Section 3.3, six main use-cases for which access to the repository will be required have been identified and described. This section further details the use cases in terms of the interactions between the end-users and the repository.
3.6.1. Border check
Use case 1: Verifying the authenticity, validity and status of document issued by another MS and use case 2: Verify that the bearer is the rightful owner of the document are part of the border check process (or of the checks in the territory). Both use cases take place simultaneously, according to the same process flow:
1. The officer via the national system(s) consult the common repository;
2. The document number found on the long-stay or residence document is inserted to the system either manually by typing or through a scan of its MRZ.
Alternatively, the repository could be queried by using the passport MRZ, however the linkage to a passport might not always be possible, for instance, residence cards are not necessarily linked to a passport and a person might travel without one as long he/she carries an ID.
3. An identical entry of the document number is searched in the repository by the system. If a match is found, the document is authenticated. Otherwise, the case is relayed to a second line check.
4. System then returns to the end-user information on the document. In the case where the passport is used to query the system, the repository would return the list of valid documents associated to the passport.
5. The officer compares the information returned against the ones of the documents presented by the TCN. If a match is found, the TCN is granted entry, otherwise the case is relayed to a second line check. The facial image, if available, could further reinforce this step, by allowing to compare the picture on the document and the on stored in the repository.
46
Figure 14: Process flow for the verification of the authenticity, validity and status of long stay documents issued by another MS and verification by MS A that the TCN is the rightful owner of the document issued by MS B
3.6.2. Store and update document information
Use case 3: Store and update document information involves the creation of new data entries in the central repository, amending the information available (especially updating the statuses of the documents) and the ability to delete entries. It is important to note that the change in the central repository is propagated after amendment in the national system. It is thus recommended to implement automatic central updates that are triggered by the national updates in order to avoid duplication of work by the end-user.
The following steps will be necessary:
1. The end-user connects to the national system connected to the common repository;
2. Request is made either to
o Create a new data entry (new application, new document data upload etc…) o Modify existing data in the repository o Update statuses of the documents (e.g. withdrawn, extended, etc…) o Delete an entry or data
3. The national system controls if the end-user has the right to execute the requested
transaction.
MATCHdocument number
CONNECTto repository
1
3
Interface
INPUTdocument number
2
Type in Interface
MRZ Scan
Match found
Match not found
OR
System
RETURN Document
information
4
System
COMPARE Document
information
5
System or manual check
Match found Match not found
Entry granted
PROCEED to 2nd line
check
PROCEED to 2nd line
check
If the MRZ was used to query the system then the return
message would include a list of valid document associated
to the passport
Either the document unique identifier or the passport
could be used to query the system, however residence cards are not necessarily
linked to a travel document
47
4. If the transaction is not allowed, the end-user is alerted that he/she does not have the permission to for the requested transaction.
5. If the requested transaction is allowed, the request is processed by the national system.
6. If the transaction was not successfully processed, the end-user is alerted by the system. Else, the national database is updated.
7. The system returns a message to the end-user to alert him/her of the successful update of the database.
8. Successful update of the national database triggers the request to update the central repository as well.
9. The requested change is also processed in the central repository.
Figure 15: Process flow for handing the data in the repository
CONNECTto repository
1
Interface
REQUESTtransaction
2
Create new entry, update/delete data
PROCESSrequest
5
National System
CHECK User permission
National System
RETURN exception
No permission for the transaction
4
National db
3Transaction not allowed
Transaction allowed
National db
RETURN exception
Update successful
7
TRIGGER change to central repository
Successful/not successful
PROCESSChange
9
Central repository
8
National db
National db Central repository
National db
*db: database
National databaseUpdated
RETURN exception
Update fail
6
National db
Update successfulUpdate not successful
48
3.6.3. Consultation
The processes involved for the last two use-cases (4 and 5) are very similar: 1) Consult the history of documents and applications belonging to a TCN who applies for one of the documents in scope and 2) Consultation of the data in the repository by law enforcement authorities. Unlike the previous process flow, the end-user can have direct access to the data (using the national system is not a prerequisite). The process flow steps are as follows:
1. The end-user connects to the national system connected to the common repository;
2. The request for information made by inputting the document number or using other search criteria such as the surname and name of the document bearer on whom information is required;
3. The system processes the query;
4. If the query is successful, the system executes a control of the set of data which the end user can view depending on the permission/access rules defined for the latter;
5. The document information requested by the end user is returned by the system;
6. If the query fails or no match is found, the system returns an exception for e.g. no data found, search error.
Figure 16: Process flow for the last 2 use-cases
It is important to note that aside the main processes listed above, the following processes should also be considered:
Managing the
o User permissions (both nationally and centrally) o Business rules o Services (e.g. search engine, etc.) o Schema (tables, views, procedures, etc…) o Certificates
Handling system failure of the central repository.
PROCESSquery
CONNECTto repository
1
3
Interface)
INPUTSearch criteria
2
Search by document number, surname…
Match found
Match not foundSystem
CHECKUser permission
4
System
RETURNDocument
information
5
Set of data as per defined access rules
RETURNexception
6
No data found
49
3.7. Legal
Foreseen changes in the legislation
This section offers an overview of the legal changes involved in the implementation of the repository and is based on the following assumptions:
The initiative is in accordance to the treaties64 which are not assumed to be changed in the short term;
The initiative does not modify the entry conditions of TCNs so the Schengen Borders Code, in particular Article 6, would not be amended;
This analysis constitutes a preliminary legal analysis of the possible changes in the EU framework and should not be understood as an exhaustive list of required changes. A more in-depth assessment should be carried out at a later stage.
The implementation of the repository would have an impact in the EU legal framework as it will:
1. Store data on documents that are not yet shared at EU level and only stored at national level;
2. Include new stakeholders due to the plurality of actors involved in the issuance of long-stay and residence documents;
3. Depending on the technical option chosen: a) Modify the VIS legal framework (option 1); b) Create a new legal framework for the repository (options 2 and 3).
Whichever technical solution chosen, and whether or not the repository is part of VIS, eu-LISA will be managing the system as the agency “should perform tasks relating to training on the technical use of SIS, VIS and EURODAC and other large-scale IT systems which might be entrusted to it in the future” (recital 11 of Regulation (EU) 1077/2011). Four legal instruments will need to be modified or created in order to implement the repository, depending on the technical option chosen. This section does not take any assumption into account in terms of the choice of objectives and offers an overall overview of foreseeable modifications:
1. Regulation (EC) 767/2008 concerning the Visa Information System (VIS) and the exchange of data between Member States on short-stay visas (VIS Regulation):
The title of the Regulation, the recitals and the titles of the articles should also state “long-stay visas and residence documents” in addition to “visa” or find a general assertion to include all documents chosen to be part of the scope of the repository (e.g.: “visa and residence documents data”).
If the repository is not used for examining applications, then it should be stated that this objective of VIS only concerns short-stay visas. In any case, a difference should be made for the two categories of documents (short-stays on the one hand and long-stay and residence on the other) as for the latter, VIS will not be used as a case-management system. The issuance procedure will stay at national level and the information derived from the repository, if used, will be an additional information to support the decision making process.
Similarly, the Regulation should state that the exchange of data on the history of documents shall not apply to residence cards if included in the repository.
The Regulation should state that fingerprints data are available only on short-stay visas. It should also clarify that the data for long-stay visas and residence permits are more limited as they do not include the application data, but only, if chosen, the application decision.
The exact reasons for refusing/withdrawing a long-stay visa or a residence permit should be detailed as the grounds for refusing these types of documents are more complex than the ones for refusing a short-stay visa.
The system should also allow for a search at external borders with the travel document number for long-stay and residence documents.
64 In particular concerning Articles 77 and 79 of the Treaty on the Functioning of the European Union (TFEU).
50
2. Council Decision 2008/633/JHA concerning access for consultation of the Visa
Information System (VIS) by designated authorities of Member States and by Europol for the purposes of the prevention, detection and investigation of terrorist offences and of other serious criminal offences:
The Decision should specify which data is possible to be queried by the repository of long-stay and residence documents as its data set will be more limited.
As the modifications will depend on the choice of objective and given the amount of exceptions foreseen for the current VIS legal instruments, it could be advised to use a different chapter for specifications on long-stay visas, residence permits and residence cards.
3. Regulation (EU) 1077/2011 establishing a European Agency for the operational management of large-scale IT systems in the area of freedom, security and justice:
The Regulation should be modified if the repository is a separate entity or if the hybrid solution implies the creation of a repository separated of the VIS. If the repository is part of the VIS, the Regulation should not be modified.
If options 2 or 3 are chosen, the repository should be added in the list of systems managed by the agency and new articles would have to be created within Chapter II (Tasks) to describe the tasks performed by eu-LISA in relation to the repository.
It would have to include references to the repository in order to ensure that any external network provider would not have access to it and that the management of encryption keys remains within the competence of the agency.
It would have to include a reference to the repository as eu-LISA monitors the developments in research of SIS, VIS and EURODAC.
eu-LISA’s Management Board and Advisory Group related articles should also include the repository.
4. A new legal instrument for a repository as separate database or as a hybrid solution if the
repository is not integrated to the VIS.
In addition, it is relevant to note that the Schengen Borders Code might need to be amended to provide for a compulsory check of the documents against the repository during the border check procedure.
As it will be described in Chapter 4. Options assessment, the methodology for ranking the options on their legal impact will focus on the above-mentioned legal texts. As Regulation (EC) 767/2008 and Council Decision 2008/633/JHA both concern the VIS, for simplicity purposes they will be referred together as the VIS legal instruments. Indeed, one should not be modified without the other one. Even if the repository does not include law enforcement access, the exception would need to be specified in the Council decision. Regulation (EU) 1077/2011 will be referred at as eu-LISA’s legal basis. The options assessment will measure the impact on each option on these texts in order to determine which is easier to implement.
Complex legal framework
As shown in Table 29 in Annex 2, the legal framework on the topic is heterogeneous and builds on different types of acquis: legal migration, border management, freedom of movement. This creates some challenges in defining the legal boundaries for the central repository and might create differences in access or use-cases for different countries / documents.
The following tables summarise the “as-is” situation65 with the different scopes for each document and objective. Most of the points of attention concern the applicability of the measure to Denmark, Ireland
65 May 2017.
51
and the United Kingdom66 which opted out of the implementation of some of the articles of the legal basis in scope (border checks, legal migration). As shown, the level of legal complexity will depend on the choice of objectives, itself having a direct impact on the legal basis of the repository.
Table 14: Points of attention per documents
Document Applicability Points of attention
Long-stay visas and residence permits
EU Member States fully applying the Schengen acquis and Schengen Associated Countries67
Usually only valid as a border-crossing document within the Schengen Area
Ireland and the United Kingdom do not participate in the mutual acceptance of long-stay visas and residence permits between Member States and Schengen Associated Countries.
Irish and British long-stay visas and residence permits are not valid border-crossing documents for Schengen Area, nor long-stay visas and residence permits issued by a Schengen State are accepted at the borders in Ireland and the UK68.
Residence permits issued by Member States not yet fully applying the Schengen acquis cannot be used to enter the area without internal border controls (except in some very specific cases69)
Long-stay visas issued by Member States not yet fully applying the Schengen acquis cannot be used to enter the Schengen Area without internal border controls (except in some very specific cases70).
Residence permits and long-stay visas issued by Member States not yet fully applying the Schengen acquis can be used to enter the territory of the Member States not yet fully applying the Schengen acquis.
UK and Ireland would not have access to long-stay and residence documents data contained in the repository.
Residence cards Residence cards are issued by all EU Member States, including Ireland and the UK and are valid documents in all EU Member States
All EU Member States issue residence cards which are valid to cross any Union borders as all EU Member States implement art.21 TFEU on freedom of movement. The UK and Ireland could then feed the repository with data on their residence cards. But they might not be able to consult the repository when performing border checks (as they do not implement art.77 TFEU).
All SAC but Switzerland (which issues residence permits to TCNs family members) issue residence cards as they are part of the EEA. These countries would then need to have access to the repository for this data.
66 Due to the ongoing Brexit negotiations, UK might not be a EU MS by the time the repository will be implemented. Nevertheless, the complexity won’t change significantly as even without UK, the applicability to Ireland has the same limitations and the same consequences on the repository. 67 Notable exception: according to Decision No 565/2014/EU, BG, HR, CY and RO recognise long-stay visas and residence permits issued by MS fully implementing the Schengen acquis and allow entry upon presentation of these documents. 68 Similarly, short-stay visas contained in the VIS are not valid documents to cross the British and Irish borders. 69 In some cases, residence permits issued under Directives 2014/66/EU and (EU) 2016/801 are valid to cross the borders from a non-Schengen into a Schengen State. 70 Only under Directive (EU) 2016/801.
52
Table 15: Points of attention per objectives
Objectives Points of attention
Border checks
This objective may fall under Article 77 (border checks) of the Treaty on the Functioning of the European Union, the latter being implemented by EU Member States fully applying the Schengen acquis and Denmark (with an opt-in possibility). Article 77 TFEU does not as such apply to Schengen Associated Countries but the latter apply the relevant Schengen acquis in accordance with their association agreement. Article 21 (freedom of movement) could be used as the legal basis for residence cards.
The United Kingdom and Ireland do not implement Article 77. Still both countries issue and check residence cards at the borders on the basis of the freedom of movement (art. 21 TFEU) and these residence cards can be used to cross the external border of other Member States.
Assessment of the TCN situation
This objective might fall under Article 79 TFEU (migration) as the data would be used to assess a migratory risk and take part in a decision-making process related to migration.
The UK, Ireland, Denmark and the SAC do not implement this article and might not, depending on the specificities of this objective, participate in a common repository whose objective is migration-based.
Support to an investigation
No particular points of attention
Statistics and reporting
No particular points of attention
Due to the “variable geometry”71, the legal impact of implementing a common repository on long-stay and residence documents will depend on the choice of objectives.
71 See: http://eur-lex.europa.eu/summary/glossary/variable_geometry_europe.html?locale=en (consulted 06/2017)
53
3.8. Compliance with data protection framework
3.8.1. Applicable legal texts
Five pieces of EU law may apply to the set-up of a common European repository.
The Charter of Fundamental Rights
Article 7 of the Charter establishes a general right to respect the “private and family life, home and communications”. Article 8 provides for the protection of personal data, its fair processing for specified purposes on a legitimate basis. Finally, Article 52 provides that any limitation to these rights must:
Respect their essence;
Be proportional;
Be necessary;
Genuinely meet the objectives of general interest or the need to protect the rights of others. Once the final configuration and design of the proposed central repository are determined (objectives pursued, use-cases and data retained) the necessity of the central repository should be analysed in light of the EU context of large-scale IT systems (existing and future). It will be necessary to identify these systems, their purposes and the data they collect, to ensure as limited an overlap as possible.
Regulation on the processing of personal data by the Community institutions and bodies
This Regulation applies to data processing by EU institutions and agencies, including eu-LISA. This instrument is however being revised and a new proposal for replacing it has been issued by the Commission on the 10th of January 2017. The purpose of this change is to align the Regulation with the new General Data Protection Regulation, which will become effective in May 2018.
General Data Protection Regulation (GDPR)
The GDPR would apply to any processing that is not covered by the Regulation on the processing of personal data by the Community institutions and bodies or the Directive on personal data processing for the prevention of criminal offences.
Directive on personal data processing for the prevention, investigation, detection or prosecution of criminal offences
The Directive does not apply to EU agencies and therefore would not apply to the processing of personal data by eu-LISA. It would, however, apply to the processing of the personal data contained in the repository by national law enforcement authorities for the purposes of law enforcement for the prevention, detection and investigation of terrorist offences or of other serious criminal offences.
All these pieces of legislation coherently provide for principles to be respected in the course of data processing.
3.8.2. Data protection principles
As indicated in the preamble of this study, the approach undertaken aims to address privacy and data protection considerations from the outset in order to ensure that the central repository, regardless of the option retained, can be compliant with the required personal data protection principles and the applicable EU data protection legal framework.
In all cases, the repository would process and store high volumes of personal data. Access to the data is expected to be provided for different stakeholders, including national law enforcement authorities. Therefore, it will be of particular importance to ensure adequate levels of data protection through the adoption of appropriate safeguards, in line with the applicable EU data protection legal framework and taking into account privacy by design considerations. The EU legal framework on data protection provides a list of different principles to be respected in the course of data processing. An overview of
54
these principles and how they have been considered in the high-level design of the central repository is described below.
Lawfulness, fairness and transparency72
The lawfulness of the processing of the data contained in the central repository would rest under
article 6(1)(e) GDPR whereby “Processing is permitted if 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 controller.”
Moreover, the creation of a central repository would necessarily have to be backed by a legislative
proposal requiring approval by the European Parliament and the Council.
Purpose limitation73
The purposes are intrinsically linked with the objectives described under section 3.1. as each of these
objectives would constitute a limited purpose for the processing of the personal data contained in the
central repository. If retained, each of the four objectives would have to be specifically contemplated
and accounted for, regardless of their intended importance (primary or ancillary). The use-cases
described under section "3.3. Use-cases" would also have to be included and would mark the
boundaries of the processing operations.
Data minimisation74
The principle of data minimisation is at the core of the analysis contained in sections "3.4.5. Inclusion in the repository” and “3.5. Data” where considerations are made on:
a. Which documents are deemed necessary to be included in the repository to fulfil the pursued objectives;
b. What specific data contained in each of the selected documents would be proportionate to include in the common data set; and
c. What specific data from the common data set is needed for the fulfilment of the intended objectives and whom should this data be made available to.
Through this approach, the study aims to ensure that the collection of personal information is limited to what is directly relevant and necessary to accomplish the specified purposes and objectives described in section "3.1. Objectives". It is through the application of this principle that local border traffic permits have been excluded from the scope of the study and that the proposed preliminary data set in section "3.5.1. Data set " has been determined. Moreover, the configuration of end-user access rights as contained in section "3.5.2. Access" is also aimed at minimising the risks derived from exposing personal data to unauthorised users.
Accuracy75
The MS being responsible and accountable for ensuring the accuracy of the data in their national databases, the accuracy of the personal data contained in the central repository will be automatically guaranteed as long as appropriate measures and safeguards are implemented at MS level. The responsibility and accountability of the MS as data controllers concerning accuracy is limited to:
a. Take reasonable steps to ensure the accuracy of the personal data obtained; b. Keep data up-to-date in their national databases; c. Ensure deletion or rectification of inaccurate data.
This principle is accounted for in existing EU-scale IT systems and data sets and can be ensured
through appropriate IT security safeguards at MS level related to access rights control in order to
72 See Rec.39, 40, 41; Art.6(1) of GDPR stating that personal may be processed only if, and to the extent that, at least one lawful basis applies. 73 See Rec.50; Art.5(1)(b) of GDPR stating that data shall be “collected for specified, explicit and legitimate” purposes. It should not be further processed in a manner that is incompatible with these purposes. 74 See Rec.39; Art.5(1)(c) of GDPR which stipulates that data shall be “adequate, relevant and limited” for the purpose(s) for which it is processed 75 See Rec.39; Art.5(1)(d) of GDPR whereby personal data must be accurate and, where necessary, kept up to date. Every reasonable step must be taken to ensure that personal data that are inaccurate are either erased or rectified without delay.
55
guarantee the data subjects’ right of correction in the case of inaccurate data (e.g. change of name).
Consequently, compliance with this principle should not constitute a blocking factor.
Storage limitation76
As indicated in section "3.5.3. Data retention", the central repository mechanism could foresee the tailoring of data retention periods for the different categories of data stored and the different objectives pursued. A brief recapitulation is provided in the table below.
Table 16: Retention period considerations by objective
Objective Retention period considerations
Border check A maximum of 6 months after document date of expiry or withdrawal
Assessment of TCN’ situation A maximum of 3 - 5 years as of the expiry/withdrawal of the document or the refusal of an application
Law enforcement A maximum of 3 - 5 years as of the expiry/withdrawal of the document or the refusal of an application under specific conditions (for instance, court order)
Statistics GDPR grants the possibility of extending data retention periods for statistical purposes in the public interest as long as appropriate safeguards are implemented
The bracket of 3-5 years will need to be based on objective criteria in order to ensure that the retention is limited to what is strictly necessary77 taking into consideration the average validity of the documents, the national retention periods, and the importance of ensuring that the retention period is broad enough to allow for the coexistence of overlapping documents related to a same individual.
The fact that the central repository could potentially pursue different objectives requiring different retention periods does not constitute a blocking factor as long as appropriate measures and safeguards are put in place.
Integrity and confidentiality78
Similarly to the data accuracy principle, this principle aims to ensure that Member States are responsible for ensuring that the personal data stored in their national systems (and fed in the repository) are kept secure and protected against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures. In addition, this principle aims to ensure that eu-LISA is responsible for ensuring that the personal data stored in the central repository are kept secure and protected against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures.
Compliance with this principle is intrinsically linked to the IT security measures both at MS and central level that will have to be implemented to ensure full lifecycle security.
76 See Rec.39; Art.5(1)(e) of GDPR which stipulates that data shall be kept “in a form that permits the identification” of persons for no longer than necessary for the purposes and lists the exceptions under which it can be kept for longer periods for statistical purposes subject to the implementation of appropriate safeguards. 77 See data retention considerations in EDPS Opinion 06/2016 on the Recommendations on the revised proposal to establish an Entry/Exit System. 78 See Rec.29, 71, 156; Art.5(1)(f), 24(1), 25(1)-(2), 28, 39, 32 of GDPR which enshrines the principle of data security.
56
Accountability 79
This principle calls for the explicit documentation and implementation of measures in order to
guarantee the respect of data protection rules for all processing activities. As in other EU-scale IT
systems, accountability may be ensured through:
Recording of the staff having access and of processing activities;
Logging functionalities;
Auditability;
Responsibility allocation;
Cooperation between authorities.
3.8.3. Repository pursuing objective 1: necessity and proportionality test
The necessity test follows the "Necessity Toolkit" proposed by the European Data Protection Supervisor. It is of course an initial assessment as the envisaged measure is yet to be fully developed. At the end an additional step on proportionality is added as the toolkit is only focused on necessity while ultimately both necessity and proportionality must be assessed. In this section the analysis is performed assuming the objective pursued is only objective 1 "Facilitate checks at external border-crossing points and within the territory of the Member State"
Step 1: Factual description of the measure proposed
The measure would consist in creating a central repository containing the data that are currently stored relating to long-stay visa, and/or the residence permit and/or the residence card of TCNs. These data are described in section 3.5.1 and consist in five data fields that identify the person (first name, last name, data of birth, nationality and sex), six data fields that identify the document (unique identifier, type of document, validity period, document number, issuing MS, status, and, potentially, withdrawal) and one biometric identifier that links the person to the document, being the facial image.
The central repository would be created by copying the data from the MS national system that is currently used to issue long-stay visas, residence permits or residence cards. The data would be accessed by border guards who would scan the submitted document. This would trigger a request to the repository that would confirm that the information extracted from the document and sent to the repository matches its content. The facial image contained in the document would also be matched (either by the system in case of a digital picture or simply visually) with the picture on the document and with the person bearing the document.
Step 2: Identification of fundamental rights and freedoms limited
The proposed measure processes a small amount of data of a large group of persons. Currently there are an estimated 22 million documents in circulation (19 million residence permits, 2 million long-stay visas and an amount of residence cards not exactly known but estimated at 1 million). This number of documents can be assumed to correspond to the same amount of individuals.
The processing operations involve the collection of data from a unique official Member State source and keeping it available for checks by border control authorities.
The measure envisaged would create an interference with Article 7 of the EU Charter of Fundamental Rights (Art 7 – Respect for privacy and family life). As it includes the processing of personal data, it would need to be demonstrated that the conditions set forth in article 52(1) of the Charter for limiting the exercise of rights and freedoms are fulfilled. Any limitation on the exercise of the rights and freedoms laid down by the Charter must be (1) provided for by law, (2) respect their essence (3) subject to the principle of proportionality, (4) limitations may be made to those rights and freedoms
79 See Rec.85; Art.5(2) of GDPR whereby the controller is responsible for, and must be able to demonstrate, compliance with the data protection principles.
57
only if they are necessary and genuinely meet objectives of general interest recognised by the Union or the need to protect the rights and freedoms of others.
Concerning the principle of proportionality three elements must therefore be assessed in combination:
(1) the measure must be appropriate (suitable),
(2) the measure must be necessary (requisite), which includes an assessment to determine whether there is no less intrusive alternative,
(3) the measure must be proportionate.
Article 8 of the Charter is a proactive horizontal right to protection that is not limited to interferences by the MS. It gives individuals the right that their personal data can only be processed if the requirements set out in paragraphs 2 and 3 of Article 8 are met:
(1) the data is processed fairly for specified purposes and on the basis of the consent of the person concerned or some other legitimate basis laid down by law,
(2) transparency is ensured by giving the individuals rights to access and correction,
(3) control by an independent authority is ensured.
Meeting the requirements of Article 8 can be done once the other checks have been made and that legal provisions are developed: the envisaged measure can be tailored to meet each of the items mentioned.
Step 3: Define objectives of the measure
The objective of the proposed measure is to eliminate the use of false documents that support irregular migration and cross-border criminality. Both objectives can be categorised as objectives of general interest. Providing the assurance to EU citizens that legal migration status is only granted to those genuinely meeting the required conditions is essential to keep the trust in legal migration and to ensure the fairness of treatment between the many TCNs who lawfully want to enter and stay in the EU.
The proposed measure presents the benefit that any of the three types of documents submitted (long-stay visa, residence permit, residence card) would be checked against the information recorded at its issuance or ulterior status modification. As such, this measure would ensure that only legitimate documents are accepted and are solely used by the genuine bearer. The process thus ensures that withdrawn documents are no longer accepted and completely avoids that false documents pass undetected.
Detecting false documents remains inherently difficult. Out of the three documents envisaged, the residence card is not harmonised which means that a border guard must be aware of a variety of document formats and security features. Practically this situation quickly becomes unworkable as a border guard cannot fall back to a system that would provide detailed descriptions of genuine and legitimate residence cards each time a different document is submitted.
Long-stay visas and residence permits, on the contrary, are harmonised and have common security features. However, despite the common security measures there is still a significant amount of frauds according to the MS consulted. Moreover, in the case of the resident permits, the electronic verification on the authenticity of the document can only be done using cryptographic certificates whose exchange between Member States is still far from being systematic.
Finally, the information and data printed on the document itself cannot be updated once the document has been issued. As such, there is no way of reflecting the most recent changes or status of the document (withdrawal, invalidation because of theft or misappropriation, extension of its validity, etc.) onto the physical document itself.
Step 4: Choose the option that is effective and least intrusive
The problem of document fraud exists since a long time and has essentially been addressed by making forgery or counterfeit of documents more difficult by adding, over the time, security features to the documents. The general trend is that secure documents become increasingly expensive to produce and
58
because of growing security features the inspection systems used by border guards/police have to be repeatedly upgraded. However, despite these efforts document fraud continuously adapts to the new type of document. Having a trusted database against which being able to verify a document and its content will always provide an additional layer of security and as well facilitate the work of border guards.
The Visa Information System (VIS) authenticates the visa information no longer against the data printed on the visa sticker (and which nevertheless contains optical security features to avoid easy counterfeiting) but against the information stored in the system supporting the visa issuance process. The success of the VIS shows that the central storage and access of the original data combined with a means to ascertain the genuine identity of the person using the visa, is the most efficient way to combat visa fraud.
In section 3.2 Possible alternatives to the repository, two potential alternatives have been examined. The first measure (harmonising documents to a more secure version) appears as a necessary first step to address document fraud but will not achieve the same level of efficiency and effectiveness of using a reference database of issued documents. This is because having more secure and uniform documents does not necessarily tackle visa fraud. The second measure (distributed database) would not be considered as less intrusive given that the same information would be made available to all MS. Moreover, this measure would also pose practical problems given, for instance, the language differences between the different MS systems. Technically it would also be more difficult to implement the extent that its feasibility would not be guaranteed from the outset.
Step 5: Check proportionality
As mentioned above under step 2, proportionality test requires showing that the measure would be suitable in the sense of being likely to achieve its purpose. The answer is affirmative as this is precisely what is currently achieved through the VIS for short-stay visas. In fact, in its recent evaluation80 (2016) the VIS was described as “an indispensable tool for the implementation of an effective and efficient common visa policy and is increasingly contributing to the security of the EU external borders, to fight irregular migration and help in the fight against terrorism and other serious crimes, thereby generating further EU added value” (source: COM(2016) 655 final, page 8-9). Checking the identity of the bearer and the document authenticity and validity against the central database allows for the detection of visa frauds, a majority of which passed undetected previously.
Another question to answer is whether the measure can be made more targeted in order to potentially reduce its interference on the right to privacy. In addition to what is explained under Step 4, it can be observed that the measure analysed is targeted to the holders of documents (long stay visa, residence permits and cards) with a validity for the Schengen area, that are not yet included in a central repository, such as the VIS. Overall, the intrusiveness of the proposed measure is in itself very modest. In fact, the personal data that would be subject to storage in the central repository does not go beyond what a border guard currently sees when examining the long-term visa, residence card or permit that is presented at the border. The only difference is that the border guard will compare the presented information against the information as stored by the issuer of the document. The interference on the right to privacy would not be greater than the current VIS system, for which no complaint on data protection was registered to date (source COM(2016) 655 final, page 12) and adequate safeguards have been put in place.
Conclusion on this section
The preliminary assessment done in this section suggests that it is possible to justify the necessity and proportionality of a measure setting up a central repository storing a minimum of information limited to the last issued long-term visa, residence permit and card. Further quantitative evidences, that could not be collected during the duration of the present study, could further strengthen the assessment.
80 https://ec.europa.eu/home-affairs/sites/homeaffairs/files/what-we-do/policies/borders-and-visas/visa-policy/docs/report_to_the_european_parliament_and_council_on_implementation_of_vis_en.pdf
59
3.8.4. Repository pursuing objective 2: necessity and proportionality test
Similarly to section 3.8.3 above, the preliminary necessity and proportionality analysis that follows relates to objective 2 “Assess the TCN situation and contribute to tackle irregular migration” of the proposed measure.
Step 1: Factual description of the measure proposed
The proposed measure would consist in creating a central repository containing the document history of TCNs as well as ongoing and/or previously denied applications (the difference between the two options will be discussed within Step 4). The documents and applications refer to long-stay visas, residence permits and/or residence cards. This information would only be available to consular and migration authorities while studying and assessing a newly filed application for the issuance of a new document (including a short stay visa). The document history and denied application decisions would only be stored for a predefined data retention period after which documents and denied applications that go beyond the data retention period would be eliminated from the central repository.
The central repository would contain each MS’ national records for all successful and failed applications filed in each MS. A person-centric approach would be implemented in order to be able to trace all issued documents and rejected applications to the same TCN filing for one of the documents in scope, regardless of the type of document and the MS where the previous applications and documents have been filed or issued.
In practical terms, the data would be accessed by the consular or migration authorities of the MS where the TCN has filed an application. When assessing a new application, the consular or migration authorities would be able to query the database, through the applicant’s biographical data described in Figure 13: Repository's possible data set , and access the individual’s document history and denied application decisions. The query would return a list of all previous and valid documents and the rejected applications of the same TCN, along with reasons for the relevant status changes. In the case of denied past applications the query would also return the precise reasons that led to the negative decision. The processing operations essentially entail collecting existing data from an official MS source and keeping it available for checks by other MS migration authorities. In the event that all documents of a same TCN are linked within the repository, e.g. by generating a common identifier, that would also constitute a processing activity.
The personal data stored in the central repository, described in section 3.5.1, consists of:
The type of document previously issued for a same TCN and its current status (valid, withdrawn, expired, renewed, etc.)
The possible existence of rejected previous applications by a same TCN and the reasons supporting the negative decision
It is important to note that the content of the previous application dossier (successful or not) would not be stored in the central repository. The input resulting from this process would only provide an additional information element for the MS migration authorities during their assessment of a newly lodged application. The measure would in no manner constitute an automated decision-making process.
Step 2: Identification of fundamental rights and freedoms limited
A similar analysis to objective 1 applies to objective 2. The measure envisaged would create an interference with Article 7 of the EU Charter of Fundamental Rights (Art 7 – Respect for privacy and family life) and, therefore, the same Article 52(1) conditions would have to be met.
In this regard, the proposed measure seeks to mitigate its impact on the TCN’s right to privacy by (i) minimising the TCN’s personal data that would be disclosed (the application dossiers and contents would not be stored) and (ii) requiring a documented and unequivocal justification of past refusal decisions to avoid the misleading of MS migration authorities.
As with objective 1, the requirements set forth under Article 8 can be met once the provisions of Article 52(1) are complied with and that legal provisions are developed.
60
Step 3: Define objectives of the measure
The measure’s main objectives are: (i) to provide additional input in the assessment of the TCN situation by the migration authorities; and (ii) to address the information exchange gap between MS on the situation of a TCN.
All of these objectives respond to the pressing social need of fighting irregular migration and cross-border criminality, making them objectives of general interest. In this sense, in order to ensure collective security and equal treatment of TCNs filing for legal migration status, it meets the necessity for the migration authorities of Member States in the course of the assessment of a document request to access an applicant’s document and application history. Moreover, this information would never constitute the unique and decisive factor behind a positive or negative decision on the issuance of a document to a TCN.
The proposed measure has the advantage of providing very valuable information for EU migration and security purposes by ensuring that a TCN’s different applications, existing document and associated rights may be consulted despite the fact that this information is located in different Member States. This process would be instrumental in avoiding instances of fraud stemming from the lack of interoperability and systematic information exchanges between Member States.
Out of the documents envisaged, the residence card must be considered of lesser relevance for the pursued objective. In this case, the grounds upon which the residence card is issued are only based on the proof of family ties of the TCN to a EU citizen and is, therefore, not conditioned to other objective circumstances (studies, employment situation…) Consequently, objective 2 “Assess the TCN situation and contribute to tackle irregular migration” would not be applicable to residence cards.
Step 4: Choose the option that is effective and least intrusive
Contrarily to objective 1, the necessity and benefits of objective 2 are more difficult to justify with number-based arguments due to the lack of specific figures and statistics. Although it is safe to conclude that the risk of migration authorities making partially informed decisions exists, the frequency, and exact consequences of this are unknown. For instance, there is no clear visibility as to how many security or migration threats originating from an overstay could have been avoided if one MS issuing a short-stay visa would have known that the same TCN had repeatedly and unsuccessfully requested long-term visas from a number of other MS. This issue applies both to document history and past application decisions.
Consequently, the justification for processing this type of data (both document history and denied application decisions) must necessarily rely on hypothesis and on the certainty that the lack of figures is in large part due to the inexistence of a formal mechanism through which MS can exchange information on the document history and application decisions of TCNs. As already mentioned in section 3.5.1, from the assessment of Frontex’s Annual Risk Analysis the conclusion is that a number of cases of overstaying could be prevented by a more efficient vetting of the applications.
The alternative to a common European repository could be the establishment of a communication protocol by which the migration authorities of a MS either would send an information request to all other Member States or would be allowed to query the national databases of each MS. These alternatives do not necessarily guarantee speed and efficiency in the process. Moreover, the duplication effort of having all Member States responding to a query in a decentralised manner would not outweigh the benefits of a central repository containing data already available at national level.
In terms of intrusiveness, the distinction between the document history and the denied applications decisions becomes more relevant. Although denied applications would have to be accompanied by the reasons motivating the negative decision, this decision may be interpreted as a precedent revealing TCN’s personal information that may not be pertinent in a subsequent application process. The document history, on the other hand, would only reveal if the TCN is or was the holder of another document issued by another MS. In this sense, the processing of application decisions may be more intrusive than the document history.
In terms of effectiveness, however, it is only through a combined approach containing both document history and denied application decisions that migration authorities would have a thorough
61
understanding and overview of a TCN’s past and present situation that will enable them to make a fully informed decision.
Step 5: Check proportionality
As mentioned above under step 2, proportionality test requires showing that the measure would be suitable in the sense of being likely to achieve its purpose. Through the proposed measure, frauds can be detected by being aware of the different applications made to different MS. The data collection needs to be exhaustive enough to ensure a fair and accurate assessment without any information gap.
The same solution was applied in the case of short-term visas where the ad-hoc consultation between visa authorities was complemented with the possibility to consult the history of visa applications. As indicated above, the necessity and, therefore, proportionality of including residence cards under this objective is disputed.
The impact on the privacy of the data subjects stems from making available to other Member States the information collected by MS authorities which received a long-term visa/residence permit or card application. For the data subject the risk is that in particular a former refusal would negatively impact the evaluation of subsequent applications. A similar fear existed when the VIS was proposed, which proved to be unfounded. The argument was that more visa applications would be refused when MS would be able to see that a prior visa application had been refused. Therefore, subsequent applications would have fewer chances to be accepted. Since VIS is operational the acceptance rate of visa applications did not change, it even slightly increased because the consistency of the evaluation process improved.
The centralisation of the data in a common repository as opposed to a de-centralised system is sometimes perceived as being a more intrusive measure. However, the technical solution does not modify its intrusiveness: whatever the technical architecture is retained, the measure is purely about a MS authority accessing data generated by (an)other Member State(s) equivalent authority. The central solution can rely on the successful experience of other projects at both EU (VIS in particular) and national level for the creation of a person-centric view which is essential for an accurate assessment of a TCN situation.
It is important to underscore that
1) Access would be limited to authorised government entities in the process of assessing the situation of a TCN following a new application;
2) The amount of data replicated centrally and processed would be very limited. In fact, not the entire application-dossier would be stored but only the outcome of previous applications, limited by a set data-retention period.
The purpose of a MS authority accessing the application history is solely to raise awareness on the applicant's situation as regards migration. In no case should it modify the baseline rule that each application is assessed on its own merits and that migration decisions are not taken based on the outcome of a previous application.
A more concrete definition of which data elements from the application history would actually be stored could provide greater certainty and reduce the intrusiveness of the measure. The need for this more detailed analysis is only highlighted but is not further conducted in this part of the study.
Conclusion on this section
The analysis above suggests that the collection of previous decisions on applications might provide added value for the migration authorities whilst having limited impact for privacy of the people involved as only a very limited amount of data would be stored and could be accessed by authorised entities only. However, more factual evidence on the importance of the problem faced would be necessary in order to conclude on its proportionality and necessity.
The intrusiveness of the measure could also be reduced by identifying in detail which information from an application would exactly be shared both in case of acceptance as well as in case of refusal.
62
Concerning residence cards, there is no strong justification for having an EU MS accessing the history of decisions (acceptance and refusals) on residence cards issued by another EU Member State. The decision to issue a residence card is only based on the family situation and does therefore not require the history of past applications or decisions of other documents.
63
4. Options Assessment
The aim of this chapter is to describe and evaluate the possible options for the implementation of the central repository that would achieve the objectives identified in the previous chapter. The evaluation is based on:
Main assumptions and constraints to consider before starting the description and evaluation of the options. They stem from the analysis carried out in the previous chapter;
The set of criteria used to compare these different options, their respective descriptions and how they would be assessed;
Key findings providing a recap of the main pros and cons of each options and main takeaways emerging from the consultations with experts from eu-LISA, the European Commission and the survey sent to Member States.
The main findings of this analysis will be summarised in the following chapter, concluding the study and highlighting the recommendation for a repository that would minimise effort and costs while ensuring security of the data.
4.1. Assumptions and constraints
The table below provides a brief and clear-cut description of the main assumptions and major limitations that could affect the implementation of the central repository:
Table 17: Summary of main assumptions and constraints pertaining to the implementation of the repository
Assumptions
The system will have to provide similar performances as the VIS for first line border checks;
The repository will make maximum re-use of the existing infrastructure, including the communication network (TESTA-ng);
The options assessment should take a privacy-by-design approach;
Common information may not be indicated on the three documents in scope using a standard format. This is especially the case with the duration of validity. For instance, long-stay visas have “expiry date” (e.g. ‘21MAR2021’) while residence permits have “validity period” (e.g. ‘valid until 21-03-2021’). It is assumed that this data will be stored consistently in its respective field in the repository;
As pointed out under section "3.3. Use-cases", one of the main uses of the repository will be to consult the history of short-stay, long-stay and residence applications and documents belonging to the same TCN. Linking the repository with the VIS (in which the short-stay visa history is contained) will thus be of particular importance and will necessitate interoperability, thus more complexity, costs etc.
Constraints
The impact on Member States and especially on border guards should be minimised;
All the potential end-users have been identified in the previous chapter and would need to have a tailored access to the repository. Member States showed that other entities were in charge of residence permits and residence cards (regional offices, Ministry of Interior departments…) than for short-stay visas. The plurality of actors involved in these documents ought to be taken into account;
Some TCNs in the scope of the study can cross the external borders without the need to show the document itself to the border guard. Therefore retrieving/querying information from the repository should be viable using other criteria such as the passport number (and possibly other relevant fields contained in the document) and not only by relying on the document number.
4.2. Evaluation criteria
The options presented within this chapter will be assessed according to the three main criteria described hereafter. They have been selected since they allow for a structured and objective assessment of the options.
64
IT Security
The IT security assessment considers the practical effort on the need of adding safeguards81 centrally for addressing various risks related to the different options.
Different risks scenarios and the practical impact to the different actors, such as TCN, Member State national agencies and border guard authorities are first identified. The risk scenarios are similar to the different options, as it will be the same entity performing the management of the repositories.
These risk scenarios have been elaborated in terms of threat agents, storyline and impact in terms of type of effect and impacted party. The following combinations were evaluated as having the greatest need for defining safeguards:
Confidentiality: risks of disclosure of TCN sensitive information to unauthorised entities or processes.
Integrity: risks associated to possible modification or deletion of TCN sensitive information stored, processed and transferred in an unauthorized and undetected way;
Availability: risks of lack or block of the accessibility and use of the repository by authorized entities;
Privacy: risks to access and disclosure of any personal identifiable information of TCN by unwanted entities.
The safeguards implementation effort is defined as low, medium, high or very high accordingly to the challenges that may arise with the increase of complexity. Where complexity to implement a safeguard is assessed to be low (or lower, compared to the other options), the safeguard’s implementation effort is also estimated to be low. The estimation is based on this study’s understanding of the current VIS situation, and its information security experience. The safeguards categories follow the standard ISO 27002.
Ease of implementation and management
This criterion is used to assess the level of effort with regards to the implementation and management of the repository. It addresses the following question: How easy is it to implement this option for the central system and for the national systems? The following key areas have been taken into consideration
in order to better understand the type of complexity faced:
Technical – Impact on aspects such as the data model, services and capacity at central and national sides.
Operational - Encompasses several strategies and techniques used to implement the repository. Impacted aspects are processes, governance, operations and access control.
Legal – From the analysis already performed in section 3.7. Legal, the impact on the legal instruments is assessed on the basis of:
1. Are new legal instruments required?
2. Level of impact on eu-LISA’s legal basis;
3. Level of impact on current VIS instruments.
81 The Safeguards listed in the assessment follow the structure of the ISO 27002:2013 followed by the VIS.
65
Cost-effectiveness
The main question addressed under this criterion is: Is this option cost-effective? Does it avoid unnecessary costs? The following cost elements are evaluated:
Development cost;
Hardware/software, including costs of hardware/software deployment;
Network;
Administration including procurement, project and grants management, monitoring of the systems, contract management, as well as costs of the training.
The approach for evaluating the options is a two-fold scoring strategy and the steps are the following:
1. Evaluate the impact/effort level of the areas under each criterion. The scale used is LOW, MEDIUM, HIGH and VERY HIGH.
2. The evaluation obtained for each criterion is translated into a score ranging from 1 to 4 where a score of 1 implies ‘VERY HIGH’ risk/effort/cost for the areas identified and a score of 4 means ‘VERY LOW’ costs/impacts/efforts determined.
The following chapter provides a table summarising the scoring given to the three options. The figure below illustrates the overall scoring approach for evaluating the criteria:
Figure 17: Scoring logic used for the option assessment
1 IT Security
2 Ease of implementation and management
3 Cost-effectiveness
High
Medium
V eryHigh
IMPLEMENTATION
LEVEL?
EFFORT
LEVEL?
COST?
Are
as
Development
Software/Hardware
Network
Administration
Are
as
Technical complexity
Operational complexity
Legal complexity
Are
as
Sefeguards e.g.
Access control
Incidence mgt
Security Policies…For each safeguard
For each area
For each area
V erycomplex to implement
a n d manage
Overall Score
1 2 3 4V ery easy to implement
a n d manage
Low
Ea sy to implement
a n d m anage
Complex to implement
a n d m anage
V ery high r isk
Overall Score
1 2 3 4V ery low
r iskLow riskHigh risk
V ery high cost
Overall Score
1 2 3 4V ery low
costLow costHigh cost
High
Medium
V eryHigh
High
Medium
V eryHigh
Low
Low
66
4.3. Overview of the options
Initially, the idea of having a repository was discussed in the High-level expert group on information systems and interoperability and the conclusion was that there were a number of similarities (in terms of desired functionality, purpose and uses) with the VIS and hence that the VIS could potentially be developed to address the needs identified for a repository of long-stay and residence documents. Based on this, three options have been identified, according to the different levels of re-use of the VIS:
1. Repository as part of VIS: maximum integration of the repository with the VIS; 2. Repository as a new database: no or minimal integration with the VIS; 3. Hybrid option: A mix of the first and second options, with some documents integrated in
the VIS and others not based on their characteristics. The possibility of not implementing the repository is also considered as “Option 0: do nothing”. This option represents the will to continue with the “as is” situation. It will be used as reference point for assessing the other options, particularly in terms of costs.
Figure 18: Taxonomy of the options
The options listed above could be implemented using different technical solutions. For example, modify the existing data model within VIS to integrate the new documents’ information or create a new data model with a link to the existing one. While the different technical implementations might impact the technical complexity, they will not have a major impact on the assessment of the options. Any of these options would address the main considerations set in Chapter 3 and all the assumptions and constraints identified would apply.
These options all focus on the implementation of the central site. Network and the ICD82 of the VIS would be reused as much as possible in order to minimise the impact on MS, regardless of the option selected.
82 Interface Control Document
Do nothing
Hybrid repository
Options
Repository as part of VIS
Repository as a new database for all documents
1
2
Option 2 for residence card
Option 1 for long-stay visa and residence
permit
Integration in VIS:
Different levels of integration possible:
Same data model or new data model within VIS but same logic
New business layer, data model,
schema, objects, hardware resources and software infrastructure, securitymeasures, search engine, etc…
New ICD
Additional services, operationalmanagement, etc…
1
3
+
Some documents in VIS and the rest in a
new database
0
67
Figure 19: Overview of the components impacted
The options have been assessed having in mind the main use-cases of the repository as analysed in the previous chapter, especially the possibility to authenticate the documents and the identification of the bearer.
4.4. Option 0: ‘Do nothing: status quo’
The ‘Do nothing’ option, ‘business as usual’ or ‘status quo’ implies the implementation of no repository for the long-stay visas, residence permits and residence cards at EU level. The decision to ‘Do nothing’ could be made if the cost of all other options significantly outweighs the benefits or if there is no issue to be solved at EU level or if the issue could be solved via other means (e.g. cooperation between national administrations etc.). MS could still at least rely on the SIS, in order to log and check the documents that have been withdrawn or use FADO83.
Pros Cons
No additional costs
(hardware/software, infrastructure,
maintenance…) incurred to
implement a new repository or adapt
the VIS;
Limitation of the data stored centrally, and thus of any risk linked
to the protection of said data.
The objectives would not be met: the information gap on long-stay and residence documents and on their holders would remain, creating a potential security loophole especially about authentication of the documents.
Over stayers of long stay visas and residence documents will continue to go undetected, as current rules and lack of common standards allow a third country national to exit the EU through another MS that the one that issued the document without any consequence.
Overall, the Schengen border management systems would remain incomplete and unable to provide an integrated solution for border guards, thus creating potentially unwanted differences in how TCNs are
83 FADO is a European image-archiving system helping to combat illegal immigration and organised crime and was established in 1998 by a joint action of the Council of the European Union. It stands for False and authentic documents online. PRADO is the Public register of authentic travel and identity documents online. See http://www.consilium.europa.eu/prado/en/prado-start-page.html
68
checked and treated at the Schengen borders.
Lack of visibility and statistics making it almost impossible to take data-driven policymaking decisions. For e.g. the impossibility to get anonymous statistics on the actual number of checks at borders for other documents (possible today with short-stay visas).
Potential hidden costs related to internal security and higher budgets for the issuance of well-secured and electronic documents embedding personal data and biometrics.
The possibility of creating a triangular relationship: document, person and system provides a higher level of security than just relying on the security features of the document itself.
This option is considered not viable since it does not meet the business objectives. Especially, it does not solve the information gap on this category of third-country nationals which is one of the objectives set by the roadmap84 (action 50) endorsed to enhance information exchange and information management.
4.5. Option 1: Repository as part of VIS
4.5.1. Description
The first option considered is the integration of the new documents within the VIS, which is of particular interest as it is a live system, already used by Member States, that serves similar business processes (border control tool and exchange of information). This would allow to re-use its infrastructure and services to the maximum extent, which means not only re-using the hardware infrastructure and the main services such as the search services, but also a number of ancillary services such as logging, reporting, data quality, statistic extractions, access control etc. On MS side, users remain connected to their current system(s) for managing the long stay visas, residence permits and residence cards. These systems (or part of the data contained in these systems) are replicated to VIS.
84 See: http://data.consilium.europa.eu/doc/document/ST-9368-2016-REV-1/en/pdf (accessed 05/2017)
69
Figure 20: Overview of the components for option 1: Repository as part of VIS
Without prejudice to a detailed impact assessment that will need to take place before any change is decided for the VIS, the current VIS would undergo the following changes and impacts as represented on the above figure:
Component Change
VIS Database
Inclusion of the alphanumerical data about long-stay visas, residence permits and residence cards. Access to the data of the three documents would be governed by access control that would limit what each end-user can see depending on the use-case / competence. The two main approaches to integrate the new data could be: a) Re-using the existing data model, extending it, and other VIS components (procedures,
queries…) in order to integrate the new data; b) Within VIS, creating a new repository and the new components for the data of new
documents using the same logic as used for the existing ones. In case a connection to the information on short stay visa is required then a link between the new database within the VIS and the existing data model should be set up. This could help in maintaining a separation between the current VIS data and the data copied from national systems, in light of the possible differences of data sets and of quality of the data replicated.
BMS85 Inclusion of the facial image (should it be decided) belonging to long-stay visas, residence
permits and residence cards.
Search Engine
The search engine configuration will be updated to index the new documents which is a standard operation.
VIS Logic
The logic of the VIS will have to be updated to be able to manage the new types of documents and new access rules. If the integration approach (a) as mentioned above under VIS Database, is used, then only minor updates are expected as the operations needed are actually a sub-set of the operations already implemented within the VIS. Else, each operation will have to be modified (depending on information on which type of documents is required)
85 Biometric Matching System
SIS
TESTA-ng
Member States (national)
VIS DB
Short stay visaLong stay visa
Residence permits
Residence cards
VIS Application
BMS
Search Engine
Na
tio
na
l In
terfa
ce
s
(NI-
VIS
)
Migration
authorities
Border control
Read/write
Read
New connection required
Read
Law Enforcement
Systems managed by eu-LISA
Administrative
authorities
Read/write
New connection required
EURODA
VIS
(CS-VIS)
ETIAS
EES
Legend: New / modified Access control
70
in order to support the connection with the corresponding database within VIS.
Connections
Connection of the VIS to Ireland and UK might be necessary to allow the checks of residence cards (only and exclusively for residence cards as UK and IE do not issue or recognise resident permits nor long stay visas issued by Schengen Member States)86. These two countries would not have access to the rest of the data contained in the VIS. However, by the time the repository goes live the UK might have completed the process of exiting the EU and thus not be in the scope anymore.
Within the Member States new stakeholders might require connection, for instance residence documents are issued by different authorities from the ones usually in charge of visas.
Connections for MS not yet fully applying the Schengen acquis. Currently only some of these MS may/will only be granted a passive access87 to the VIS. Other will remain without connection to the VIS until they finalise the relevant Schengen evaluation.
4.5.2. Assessment
This part presents the evaluation of option 1 against the criteria outlined under 4.1 Evaluation Criteria.
1) IT Security
As the majority of the security safeguards are already in place in VIS, this option presents the
lowest effort for implementing most of the safeguards. However, the integration and support of
new documents will present implementation efforts regarding access control, system development
and maintenance and security policies. This may include:
o Update of the access control granularity at database and at Member State level;
o Due to the new document types and actors accessing the repository, it is required to
specify the detailed security requirements for identification and authentication, security
management and resource management. Both from a new document process perspective
and from a repository management perspective, reflecting the operators of the manual
procedure and system managers;
o The monitoring of these safeguards, in order to apply preventively or on an as-needed
basis an adequate maintenance.
o Update the security policies and plan of the VIS. As the new documents biometric data is
stored directly in the visa document and not in the central system there is no update
required.
The change of the data model within this option introduces extra security complexity in implementing new safeguards centrally to support the new model. This includes cryptographic (SG03) and communications security (SG04) changes to adapt the new data model, with special attention for the use of biometric information available in the BMS.
86 The feasibility of the connection to UK and IE remains under question due to legal considerations., see Section 3.6 for further details. 87 Note that such a passive access is limited to a read-only access which would only give the possibility to verify a long stay visa/residence permit issued only by another MS fully applying the acquis.
71
The table below describes the differences regarding the specific safeguards required for option 1:
Table 18: Safeguard implementation effort for option 1: Repository as part of VIS
Safeguard88 Implementation effort level
Explanation
SG01 - HR Low New stakeholders recruitment, training and management of all staff
involved in VIS design, implementation and operation
SG02 - Access control
Low
The access control granularity with the new roles and profiles would need to be updated by the Member States for controlling the access of new stakeholders to the new documents, along with the allowed to use (create, edit, view, delete…). The updated options would be required for accessing the full VIS database, BMS, and search engine.
SG03- Crypto Low The cryptographic means used by eu-LISA follow art. 6 of EC decision
2006/1494 for information systems security and adhere to best practises.
SG04 - Communications
Low The communications security means are already implemented in the
current VIS and can be re-used.
SG05 - SADM Medium New documents stakeholders at Member State level would require extra
effort to guarantee security, monitoring and maintenance of the local systems accessing the VIS.
SG06 - Incident management Low Update the existing incident managed procedures and controls.
SG07 - Operations security
Low Update documentation to include the new document procedures
SG08 – Asset Management
Low This option re-uses the current components. The current data
classification requires update to describe and support the new supported documents.
SG09 - Physical Security
Low Physical security is already guaranteed by current procedures at eu-LISA and locally at MS level
SG10 - Supplier Relationships
Low eu-LISA uses contractual level agreements, such as KPIs and SLAs, to enforce the implementation of security policies by software, hardware and business service suppliers.
SG11 - Business Continuity / Disaster Recovery
Low The additional documents along with the new stakeholders need to be included into the current business continuity / disaster recovery plan.
SG12 - Security Policies
Medium Review and update the existing security policies to address the new documents and new possible threats. This includes the review of roles and
responsibilities, new information assets and on new possible risks/threats.
SG13 – Compliance
Low Guarantee compliance with applicable regulations and industry standards for the new systems.
SG14 – Organisation of information security
Low eu-LISA and Member State local policies guarantee the organization of information security.
Safeguards for Option 1 can be very easily implemented Overall Score for:
IT Security
4
88 Safeguards defined in accordance with ISO 27000.
72
2) Ease of implementation
The table below provides an estimation of the complexity in setting-up this option technically, operationally and legally.
Table 19: Ease of implementation for option 1: Repository as part of VIS
Key Area Effort Level Explanation
Central
System
MS
Technical Low Low Central system
Data model: Low impact. The required data set derived from the examination of the new documents in section 3.4 could be supported by the VIS data model. In fact, the VIS database is document-centric and already prepared for accommodating the new types of documents.
All the involved documents share many common fields. Moreover, the VIS already allows to link different documents to the same person. Using the existing data model would not put more complexity to create links between the new documents and the short-stay visas.
Finally, in case of difficulties in the adaptation of the data model, data related to the new documents could be stored within a new database within the VIS, although that would likely require a much more extensive update of the VIS Logic that will then have to manage multiple databases.
Services: Low impact. The repository would not introduce new operations compared to the VIS, at most it would require the creation of new variants of the existing operations to accommodate the new documents. In fact, as described in Chapter 3, the use-cases foreseen for the repository already apply to the VIS.
Existing queries in the VIS search engine can be easily amended to support information on the new documents. Moreover, the search engine already provides the possibility to have a list of valid visa/permits associated to a single passport since the root objects are visa applications, not travel documents.
Capacity: Low impact. According to the consultations with eu-LISA and based on the current usage of the VIS, the system should be able to accommodate the additional volume of documents to be stored. The additional volume could be easily absorbed by future evolutions. In fact, approximately 1 million long-stay visas, 2.6 million residence permits and approximately 300.000 residence cards are issued per year. Representing 20-35% of the current VIS capacity. Moreover, only a third of the capacity for operations per hour is currently used.
Access: Low impact. VIS Access Control uses roles which are associated to different profiles and could be configured to manage the new stakeholders without issues. New roles and profiles would only need to be created and maintained for controlling who can access the data on the new documents and which functions they are allowed to use (create, edit, view, delete…) in order to protect the confidentiality, integrity and privacy of the existing information available in the VIS database.
MS
National systems: Low Impact. By reusing the VIS ICD and its services as much as possible, the integration effort for Member States would be minimised as well. Moreover, Member States could benefit and leverage on the experience and knowledge cumulated since the VIS implementation so far.
Operational Low Low Central authority
Central system operations: Low impact. By developing the repository as part of the VIS, there would be clear synergies not only on the operations’ side, but also about the contract management and the contractors
73
Key Area Effort Level Explanation
Central
System
MS
developing and operating the repository. It would also avoid the duplication of meetings and committees including MS and other stakeholders. On the other hand, an increased usage of the system would imply the need to manage a higher number of incidents and updates. (this applies for all options).
Access: Low impact. Once the creation of the new roles and responsibilities are established in compliance with the applicable legislation, there is no operational change anymore until the next legislative amendments.
MS would not have to work on understanding the system, thus reducing the need of training, knowledge transfers and even of testing as material already exists for the VIS.
MS
Processes: Low impact. The impact would be minimal on the existing processes at the borders. The repository itself would actually simplify it, especially in a configuration fully integrated with the VIS. Also, there will be no impact on the support for decision-making, the application process or second line checks. In fact, while it would be a new tool and procedure, by re-using the VIS, Member States would not need to get to know a new system.
Access: Low impact. New stakeholders (e.g. Ireland and the UK) at national level will require a connection to the VIS. The end-users in these two countries will need to be trained and appropriate security measures should be put in place to ensure that the safety of the data is not compromised. On the other hand, integrating the data on the new documents in the VIS, makes it possible to re-use the infrastructure already deployed within Member States, for instance at the consulates.
Legal Medium The following changes to the three identified legal instruments would have to be performed in order to implement a repository as part of the VIS89:
VIS legal instruments: Medium impact. Substantial changes need to be done in the current VIS instruments in order to add the three documents in the system. Taking into consideration the ongoing works for the VIS recast, these changes could be included or at least facilitated by this initiative.
eu-LISA’s legal basis: No impact. If the repository were fully part of the VIS, eu-LISA’s mandate would not need to be modified.
New legal instrument: No impact. No new legal instrument would need to be created.
Option 1 can be easily implemented and managed Overall Score for:
Ease of implementation
3
89 Based on the preliminary analysis performed under section 3.6. VIS legal instruments refer to Regulation (EC) 767/2008 and Council Decision 2008/633/JHA and eu-LISA’s legal basis refers to Regulation (EU) 1077/2011.
74
3) Cost-effectiveness
The cost effectiveness assessment of option 1 “Repository as part of VIS” is provided in the table below.
Table 20: Cost-effectiveness assessment for option 1: Repository as part of VIS
Element Overall costs
Explanation
Central System
MS
Development Low Low Central System
Functionalities for the operation of the required processes are already implemented in VIS. E.g. VIS database is already document-centric, hence it could be easily extended with new tables to the new types of documents. Moreover, existing data model already supports the changes required. Hence minimal development efforts would be needed, if the existing database was re-used.
Testing efforts would be significantly lower given the re-use of existing VIS infrastructure and services to the maximum extent. There would no need for network and connectivity tests and limited need for functional tests, performance tests, BCP/DRP, security tests etc.).
MS
Queries will have to be modified to be able to support the additional corresponding fields related to the new documents. The modifications of the interface will be also needed, but MS could leverage on the existing VIS experience, e.g. by using already
accustomed development and search matching tools. Testing efforts would be significantly lower than in option 2 and 3
given the re-use of existing VIS infrastructure and services to the maximum extent.
Software and hardware
Low
Low
Central System
More storage and processing power will be needed for data of new document types, however minimal investment in new infrastructure would be required given that only 20-35% of the VIS capacity is currently used.
MS
More processing power would be needed for the redesigned queries, however existing application servers and software could be used. Overall the costs will depend on whether or not existing processing capacity is fully utilised, which is commonly not the case.
Network Low (Marginal)
Low (No cost)
Central System
Possibly higher bandwidth of TESTA-ng network would be needed, but this would have to be assessed. The low additional traffic may not have significant impact on the current bandwidth usage.
There would be also a cost to connect Ireland and the UK for the residence cards, and possibly other new stakeholders, but these costs will be the same for all implementation options and are not a differentiator when comparing options.
75
MS
Most likely existing networks could be reused.
Administration
Medium Low Central System
During the development phase the main cost component would be project management costs.
Administrative costs during operational phase would be minimal, as the same actors would monitor the system.
The existing VIS MWO contract could be used for the evolution of the VIS. This would avoid a new ad-hoc procurement that would otherwise take time and effort to prepare and to monitor afterwards.
MS
There might be a need to connect new stakeholders such as additional local authorities in charge of residence documents. This will require efforts e.g. to train people, but they will be the same for all implementation options. Other than that the routines deployed for the consulates would be reused, hence the main cost component during the development phase will be project management costs.
Very low cost for Option 1 Overall Score for:
Cost Effectiveness 4
76
4.5.3. Key Findings
The table below summarises the main findings that emerged from the analysis, desk research and from consultations with experts within eu-LISA, the European Commission and the survey sent to MS.
Pros Cons
The data model is already fit for housing the new
data. The approach may bring greater risks for the
proper function of the live VIS system but is the best
integration approach adding value for data factoring
and avoiding integrity checks between databases.
Take advantage of the existing/future functionalities. The evolutions of VIS foreseen for
the recast include many ancillary services which will
enhance significantly the system. Storing all the
information centrally in VIS will imply optimised
benefits driven from the following functionalities:
o Use same logic/solution for access control;
o Future interoperability with other systems;
o VIS search engine (Elise) allowing flexible
searching using different criteria other than the
document number;
o Data quality indicators/warnings;
o Central whitelist of valid documents;
o Reporting and statistics engine;
o Unique IDs for each of the MS authorities;
o Data amendment requests (integrating the VIS mail in the core services).
Operational efficiency: reduced complexity to
manage an existing large-scale IT system extended to
other types of data; for Member States no new human
resources and efforts for the participation in the
governance of an existing system (no new Advisory
Group); for the European Institutions, no additional
tasks relating to the evaluation of an existing system;
Limited impact on Member States. Member States are already familiar with the system.
Lower costs as compared to setting-up a new
system.
Modification of a live system could
impact already scheduled evolutions
and create risks potentially inducing
business interruptions. But these risks
could be mitigated depending on how the
additional functionalities are developed (e.g.
modular add-on would be less impactful).
Single point of failure. Even though most of the safeguards implemented can be re-
used, lowering the implementation effort, the
centralisation of the TCN visa and residence
information in a single repository increases a
single point of failure (however mitigated by
the VIS business continuity provisions
already in place).
77
4.6. Option 2: Repository as a new system
4.6.1. Description
This option will involve setting up a new system that will be managed by eu-LISA, in addition with the existing ones (SIS, ETIAS, EURODAC, etc…).
Figure 21: Repository as a new system
Despite being new, it is expected that the system would still re-use the network (TESTA-ng) and as much as possible the artefacts of the VIS, such as specifications and documentation. For this option, it is also recommended to use the same technology as for database, middleware, server types and the development and search matching tools for instance. This would limit the diversity that eu-LISA would need to manage and would allow to leverage on the experience and knowledge cumulated with the VIS. However, implementing a new system will imply a series of different elements as illustrated in the figure below:
Figure 22: New components to be implemented for option 2
SIS VIS EURODAC EES ?
New documents
ETIAS
Proposal stage
New componentsfor option 2
Hardware/software
Database
ServicesProcedures
People Network
Hardware/software
Testing and training platforms
Internal messaging infrastructure
Licences
Encryption devices
Procedures
New ICD
Security measure
Audit by EDPS and securiyexperts
People/Governance
Operational management
Incident management
Maintenance resources
Database
Data model
Access rules
Integrity checks
Services
Search engine
Biometric matching system (BMS)
Logging and authorisations
Disaster recovery
Data replication
Performance tuning
Network
Reuse the VIS Testa-NG
78
Figure 23: Overview of the components for option 2: Repository as a new system
4.6.2. Assessment
1) IT Security
Regarding the infrastructure aspects, most of the security safeguards are already in place, requiring a
low effort for adaptation for new stakeholders. However, adding a new database requires new
connections and thus extra security safeguards. This includes access control definitions, such as the
definition of access control policies and roles for the different Member State end-users querying the
new system. The access control roles per stakeholder are the responsibility of each Member State,
whereas eu-LISA manages each Member State as a single user. The following extra challenges may
arise:
o The creation of an entirely new system and database would require the creation of policies
for access control, authentication and separation of duties;
o The development or acquisition of safeguards whose implementation is to ensure that the
repository’s operational system meets the new access control policies and authentication
requirements;
o The integration of security requirements in line with the new document requirements and
allocation of accountability for their implementation.
The table below describes the differences regarding specific safeguards required for option 2:
SIS
TESTA-ng
Member States (national)
New DBResidence cards
Residence permits
Long stay visa
LogicSearch Engine
Na
tio
na
l In
terfa
ce
s
(NI-
VIS
)
Migration
authorities
Border control
Read/write
Read
Read
Law Enforcement
Systems managed by eu-LISA
Administrative
authorities
Read/write
EURODA
New System
ETIAS
VIS
Legend: New / modified Access control
New connections required
79
Table 21: Safeguard implementation effort for option 2: Repository as a new system
Safeguard Implementation level
Explanation
SG01 - HR Low New stakeholders recruitment, training and management of all staff
involved in VIS design, implementation and operation.
SG02 - Access control
Medium
New roles and profiles created and maintained for controlling the access of the documents and new connections, along with what they are allowed to use (create, edit, view, delete…). Additional updated access control for the communication of the new components is also required, such as the BMS holding the biometric characteristics of TCN.
SG03- Crypto Medium
New systems require the implementation of cryptographic means to support the new documents storage and communication. The new
cryptographic means should follow article 6 of EC decision 2006/1494
concerning the security of information systems.
SG04 - Communications
Medium
For the new systems (option 2 and 3), the creation of new connections is required to allow access for the associated stakeholders. While the TESTA-ng covers the connections with the competent authorities, internal component connections between the search engine, the logic component and the new database are required. These connections need to be secure and authenticated. Furthermore, it can be expected that since documents will be ‘distributed’ over two repositories, there will be more complicated communication involved compared to option 1. In addition, due to the different security model and schema, the communication with the BMS is separated using a firewall which requires extra configurations.
SG05 - SADM Medium The acquisition, development and maintenance activities would be
complex to ensure that the repository meets the new access control policies and authentication requirements.
SG06 - Incident management Low
For the new systems (option 2 and 3) the VIS security team would require extra monitoring, collection and assessment of security events.
SG07 - Operations security
Low
Implement/extend the existing security controls by:
Documenting new procedures of the new system architecture and processes;
Implementing technical malware protection, vulnerability management and software installation restrictions in the new system;
Doing the backup, logging and monitoring of the new system's data exchanges.
SG08 – Asset Management
Medium
The new system introduces new components and requires extra effort on the identification and classification of the new assets storing and managing the new documents. This is required to analyse and identify the level of protection of the new documents, including database security for the VIS database and the BMS storing biometric information.
SG09 - Physical Security
Low Physical security is already guaranteed by current procedures at eu-LISA and locally at MS level.
SG10 - Supplier Relationships
Low Required additional contractual agreements for the extra providers.
SG11 - Business Continuity / Disaster Recovery
Medium
The changes require the update of the current disaster recovery plan to cover the new system, in order to allow competent authorities to be able to access the new documents in case of any service disruption and security incident. Given that this is a composite system, it will be relatively complex to assure BCM.
SG12 - Security Policies
Medium
New security policies establishing the rules and policies addressing the
new documents access control lists. In addition to the extra documents
and services, an extra review on the existing policies is required for compliance alignment verification.
SG13 – Compliance Medium
Guarantee compliance with applicable regulations and industry standards for the new systems.
80
SG14 – Organisation of information security
Low eu-LISA and Member State local policies guarantee the organisation of information security.
Safeguards for Option 2 can be easily implemented Overall Score for:
IT Security
3
2) Ease of implementation
The table below provides an estimation of the difficulty in setting up this option technically, operationally and legally. Table 22 Ease of implementation for option 2: Repository as a new system
Key Area Effort Level Explanation
Central
System
MS
Technical High Very High
Central system
New Data model: High impact. A new data model would have to be designed. Unlike the VIS which stores information on only one type of document (short-stay visas), the new system will need to ensure data integrity on several types of documents. Nevertheless, the VIS conceptual model could be copied and artefacts could be re-used.
New Services: High impact. New services would have to be developed to implement similar operations as in the VIS. Additional and potentially more complex operations will have to be developed to arrange for the orchestration of the different databases, so to reduce the technical complexity for the end-users.
A new search engine will have to be developed for the new system. However, the search queries will have to support both the VIS and the new system and for consistency purpose, they will need to return the same type of results.
It is worth to note that the “European Search Portal”, currently under discussion, a sort of enterprise bus that could allow to easily query the different systems operated by eu-LISA, might simplify the technical complexity behind returning a single answer when a MS performs a query using the travel document number.
Capacity: High impact. The capacity, including redundancies for business continuity, will have to be built from scratch.
MS
National systems: High impact. new central system implies new ICD to be implemented at MS level and thus high impact on MS. New series of testing will be necessary, not only at development, but also for each evolution of the system.
81
Operational Very High High Central authority
Governance: Very high impact. By developing the repository as a new system all the related operations would have to be set-up. No synergies with the VIS would be achieved and it will create significant redundancy by establishing separate committees, meetings, advisory group, etc... Moreover, a new system would entail a complete new procurement and related contract management.
MS
Governance: High impact. MS will also have to participate in separate Committee and Advisory Group related only to the new documents.
Processes: Low impact. The impact would be minimal on the existing processes at the borders. The repository itself would actually simplify them. Specific training activities will have to be done, tailored to the new repository / tool, albeit most of the complexity could be hidden from the final end-users.
Testing: High impact. By creating a new repository in addition to the VIS, new testing would have to take place. Not only at the initial roll-out but for each evolution. There would be little/ no synergies with the existing VIS testing operations.
Access: Low impact. Access to the new system will have to be granted to all the national systems involved in any of the three documents. Apart from end-user acceptance procedures, no major training effort should be envisaged since the services will be similar.
Access: Low impact. New stakeholders (e.g. Ireland and the UK) at national level will require a connection to the VIS. These end-users will need to be trained and appropriate security should be put in place to ensure that the safety of the data is not compromised. On the other hand, integrating the data on the new documents in the VIS, makes it possible to re-use the infrastructure already deployed within MS, for instance at the consulates.
Legal High The following changes to the three identified legal instruments would have to be performed in order to implement a repository as part a separate database:
VIS legal instruments: Medium impact. They would, in principle, not need to be modified significantly (aside to allow the re-use of the National Interface). However, if the objective of granting access to migration authorities to history of documents and/or history of applications is retained, the new repository’s data would need to be linked to the one in VIS in order for this overview to include data on short-stay visas. The legal instruments should allow for these new possibilities.
A new legal instrument; High impact. The creation of a new legal instrument is a very long and cumbersome procedure.
eu-LISA’s legal basis: Medium impact. It would also need to be modified in order to allow for the Agency to manage the new repository.
Option 2 is complex to implement and manage Overall Score for:
Ease of implementation
2
82
3) Cost-effectiveness
The overview of cost effectiveness assessment of option 2 “Repository as a separate database” is given in the table below:
Table 23: Cost-effectiveness assessment for option 2: Repository as a separate database
Element Overall costs
Explanation
Central System
MS
Development High High Central System
Higher contractor development costs would be needed as compared to option 1, because of the need to develop a repository as a separate database, implement search engine, access rules, interfaces. Testing and roll-out efforts would be also higher due to more complex design with a separate repository.
MS
Additional queries would have to be developed and modifications of the interface will be needed to consume the new services and to map the national data model with the one in the repository.
With regards to the development phase, higher testing efforts would be required than in option 1.
Software and hardware
High Medium Central System
Storage hardware and software for a new database would be required, hence higher infrastructure costs than in option 1. New instances of the existing software would be also required to increase processing capacity to support new business rules, search engine, access rules and other functionalities/services to ensure orchestration of all databases. All additional infrastructure would have to be deployed on the backup site, thus the costs would be double higher.
MS
The same technologies as for the VIS could be used, but new hardware and software would be needed.
Network Medium Low (No cost)
Central System
TESTA-ng network could be reused, but a new connection would have to be created for the new repository with the respective development and testing costs.
MS
Most likely existing networks could be used.
Administration
High Medium Central System
Project and contract management costs during the development phase would be much higher than in option 1, as the new system would entail a completely new procurement. There would be a need for separate (from the VIS) meetings, committees, what would also entail higher administrative costs.
Administrative costs during operational phase would also be higher than in option 1, because of new system introduction, i.e. higher monitoring and service desk efforts.
MS
Largely, the change would be embedded in the existing border management processes, but still there might be a need to connect new stakeholders, which will require additional efforts. Another cost component will be project management costs, which will be higher than in option 1 due to higher complexity of the solution.
High cost for Option 2 Overall Score for:
Cost Effectiveness 2
83
4.6.3. Key findings
The table below summarises the main findings that emerged from the analysis and from consultations with experts within eu-LISA, MS and European Commission.
Pros Cons
No risks of interruption of the functioning of the VIS;
Easier to have a fast response as it is simpler to comply with stringent SLA with smaller databases containing data serving the same purpose;
Improved performance and parallelism in executing transactions can be achieved;
Handling failures is easier. It will still be required to link the new entity with the VIS to enable retrieval of data on short-stay visas.
Green field development. The development would not have to deal with a legacy system and could therefore be easier to design and deploy, although this might result in a higher heterogeneity and complexity of technical solutions for eu-LISA to manage and operate.
Increased processing overhead. It may require too much time before a request involving a distributed transaction is answered (this is especially the case if checks need to be done on the history of different types of documents/applications for the same person);
Data integrity becomes complex because too much additional resources is used. Database integrity refers to the validity and consistency of stored data. Integrity is usually expressed in terms of constraints, which are consistency rules that the database is not permitted to violate;
Complex database design since either a fragmentation of the database is required or the VIS database replicated and then readapted;
Security. The replicated data have to be controlled in multiple systems but also the network itself has to be made secure;
Deadlocks difficult to handle especially if multiple transactions could require parallel modification of information on different document types but they do not do it in the same order.
84
4.7. Option 3: Hybrid option
4.7.1. Description
The ‘hybrid’ option is a combination of option 1 and option 2. Some of the new document types could be integrated along with the short-stay visas in the VIS (option 1) while the other types of documents could be housed in a separate database (option 2).
Figure 24: Overview of the components for option 3: Hybrid option
In light of the characteristics of the documents and of the different geographical scopes described in section "3.7. Legal, a separate repository could be setup for residence cards while long-stay visa and residence permits could still be stored within the VIS existing database.
The separate repository for residence cards would increase the overall flexibility of the option. Since it will not necessarily need to use the same technology as the VIS, this freedom of choice will allow the components to be more loosely connected. There would be also more freedom in the management of the ad-hoc repository for residence cards.
SIS
TESTA-ng
Member States (national)
New DBResidence cards
LogicSearch Engine
Na
tio
na
l In
terfa
ce
s
(NI-
VIS
)
Migration
authorities
Border control
Read/write
Read
Read
Law Enforcement
Systems managed by eu-LISA
Administrative
authorities
Read/write
EURODA
New System
ETIAS
EES
Legend: New / modified Access control
New connections required
VIS DB
Short stay visaLong stay visa
Residence permits
VIS Application
BMS
Search Engine
VIS
(CS-VIS)
85
The separate repository of residence cards could be implemented either as a completely new system or alternatively as a separate database within the VIS. This latter would be a sub-option of option 1, for which the assessment presented above would apply.
However, Member States not fully applying the Schengen acquis may require a full access to the VIS in order to include the residence permits/long-stay visa they issue. Passive access will only give them the possibility to verify a long-stay visa/residence permit issued by another Member States fully applying the Schengen acquis (but not the documents issued by another Member States not fully applying the acquis).
4.7.2. Assessment
1) IT Security
The hybrid option requires higher effort on the safeguards implementation effort, as extra challenges
may arise with the difficulty on maintaining the data accuracy and thus increasing the possible impact
of data integrity and availability. This would require a high effort on several safeguards that may
increase with challenges related to the data classification and the level of safeguards required. This
includes safeguards related to access control, communications security, operational and monitoring as
follows:
o Access Rights to the new database by new actors: access control and authentication
policies should be adapted and defined covering the repository for the integration of new
documents to the current repository and the new database;
o Creation of new a database for different types of documents and re-use of current
safeguards regarding maintenance and service hardening;
o Allocation of responsibility for translation of the policy into Access Control Lists (ACL)
and roles (in a Role Based Access Control - RBAC) model or alternatively in Attribute
Based Access Control (ABAC) for both databases in the repository. This should include
the creation of definitions for parties that access the system and the definition of which
parties can access what information, with the justification thereof. Appropriate
segregation of duty should be addressed via the ACL group or RBAC role management to
the different document types and databases.
The table below describes the differences regarding specific safeguards required for option 2:
Table 24: Safeguard implementation effort for option 3: Hybrid option
Safeguard Implementation level
Explanation
SG01 - HR Low New stakeholders recruitment, training and management of all staff
involved in VIS design, implementation and operation.
SG02 - Access control
Medium Compound access control would have to be elaborated, to address the
hybrid architecture.
SG03- Crypto Medium
New systems require the implementation of cryptographic means to support the new documents’ storage and communication. The new
cryptographic means should follow article 6 of EC decision 2006/1494
concerning the security of information systems.
86
SG04 - Communications
Medium
For the new systems (for both options 2 and 3), the creation of new connections is required to allow associated stakeholders access to the data. While the TESTA-ng covers the connections with the competent authorities, internal component connections between the search engine, the logic component and the new database are required. These connections need to be secure and authenticated. Furthermore, it can be expected that since documents will be ‘distributed’ over two repositories, there will be a more complicated communication involved compared to option 1. In addition, due to the different security model and schema, the communication with the BMS is separated using a firewall which requires extra configurations.
SG05 - SADM High The acquisition, development and maintenance activities would be
complex because there will be a data model split over two systems, also requiring a split over the communications/queries.
SG06 - Incident management Medium
For the new systems (for both options 2 and 3) the VIS security team would require extra monitoring, collection and assessment of security
events.
SG07 - Operations security
Medium
Implement/extend the existing security controls by:
Documenting new procedures of the new system architecture and processes;
Implementing technical malware protection, vulnerability management and imply software installation restrictions in the new system;
Backup, logging and monitoring the new system data exchanges.
SG08 – Asset Management
High
The new system introduces new components and requires extra effort on the identification and classification of the new assets storing and managing the new documents. It is required to analyse and identify the level of protection the new documents require, and the latter needs to be done while taking into account the accesses provided on the existing VIS database part.
SG09 - Physical Security
Low Physical security is already guaranteed by current procedures at eu-LISA
and locally at MS level.
SG10 - Supplier Relationships
Low Required additional contractual agreements for the extra providers.
SG11 - Business Continuity / Disaster Recovery
High The changes require the update of the current disaster recovery plan to cover the new system, in order to allow competent authorities to be able to access the new documents in case of any service disruption and security incident. Given that this is a composite system, it will be relatively hard to assure BCM.
SG12 - Security Policies
High With the new system come the security policies establishing the rules and
policies addressing the new documents access control lists. In addition to
the extra documents and services, an extra review on the existing policies
is required for compliance alignment verification. This affects both the
different repositories and the BMS as the latter follows a different security model and schemas.
SG13 – Compliance
High Guarantee compliance with applicable regulations and industry standards for the new systems.
SG14 – Organisation of information security
Low eu-LISA and Member State local policies guarantee the organisation of information security.
Safeguards for Option 3 are complex to implemented Overall Score for:
IT Security
2
87
2) Ease of implementation
The table below provides an estimation of the difficulty in setting up this option technically, operationally and legally. Table 25: Ease of implementation for option 3: Hybrid option
Key Area Effort Level Explanation
Central
System
MS
Technical Very High High Central System
Very high impact: The technical impact of this option can be considered as the sum of the previous options. In fact, not only would it still require a VIS evolution to accommodate for resident permits and long-stay visas, but it would also entail setting up a complete new system, which might be developed with different technologies and designs compared to the VIS, thus increasing the knowledge and effort for eu-LISA to develop and operate such scenario.
The search across multiple systems would be more complex to perform and would require the development of a logical layer on top of the two systems. This function could potentially be performed by the “European Search Portal” that is currently being studied.
The performance of the search at the borders would be bound not only to the response time of the VIS but also of the new repository. Specific SLA and fall back procedures would have to be established in case of unavailability of either one of the two systems.
MS
National systems: Medium Impact. Even if being successful in re-using the VIS ICD, issues might still arise and additional testing will be necessary, not only at development but also for each evolution of the system.
Testing with national system: High impact. The testing would have to be performed not only in case of updates of the VIS but also in case of updates of the new repository, effectively doubling the testing effort.
Operational Very High High Central authority
Operations: Very high impact. The development of a new repository would imply the creation of a service structure around it, to manage its incidents, its evolutions, its testing and the day to day operations. Additionally, the dependencies between the VIS and the new repository (such as at time of query to provide a unique answer) would add complexity and possible issues to be managed.
Contract management: Very high Impact. According to this option not only there would have to be an evolution of the VIS, but also a new procurement would have to take place for the development. There would be a significant overhead and more administrative resources would have to be deployed.
MS
Processes: Low impact. The impact would be minimal on the existing processes at the borders. The repository itself would actually simplify them. Specific training activities will have to be done, tailored to the new repository / tool, although most of the complexity could be hidden from the end-users.
Testing: High impact. By creating a new repository in addition to the VIS, new testing would have to take place. Not only at the initial roll-out but for each evolution. There would be little/ no synergies with the VIS testing operations.
Access: High impact. Access to the new system will have to be given to all
88
the authorities involved in issuing all of the three documents. The new end-users will need to be trained and appropriate security measures should be put in place to ensure that the safety of the data is not compromised.
Legal High The following changes to the three identified legal instruments would have to be performed in order to implement a repository as a hybrid solution:
VIS legal instruments: Medium impact. Changes would need to be done to the VIS to incorporate the new documents and the links between the two entities. Taking into consideration the ongoing works for the VIS recast, these changes could be included or at least facilitated by this initiative:
A new legal instrument; High impact. The creation of a new legal instruments is a very long and cumbersome procedure.
eu-LISA’s legal basis: Medium impact. It would also need to be modified in order to allow for the Agency to manage the new repository.
Option 3 is very complex to implement and manage Overall Score for:
Ease of implementation
1
89
3) Cost-effectiveness
The table below provides an overview of cost effectiveness assessment of option 3 “Hybrid option”:
Table 26: Cost-effectiveness assessment for option 3: Hybrid option
Element Overall costs Explanation
Central System
MS
Development Very High High Central System
All the required functionalities would have to be developed for a new database. Existing data model would need to be adapted, search engine extended for residence cards. Two separate contract development teams would be needed, i.e. one for extension of the VIS and another one for the development of new database.
Testing efforts would be also higher compared to option 1 due to much more complex design.
MS
Additional queries would have to be developed and modifications of the interfaces will be needed. Higher testing efforts would be required than in option 1, because of the need to test the evolution of the VIS and new system in addition.
Software and hardware
High Medium Central System
Storage hardware and software for a new database would be required, including duplication at the backup site. New instances of the existing software would be required to increase processing capacity to support new system with business rules, search engine, access rules and other functionalities/ services.
Infrastructure costs would be slightly lower than in option 2, as only residence cards would be stored in a separate repository.
MS
Existing hardware/ software could be used, depending on its current capacity.
Network Medium Low
(No cost)
Central System
TESTA-ng would have to be re-used in order to support additional database.
MS
It would depend on a country-to-country basis, but most likely existing networks could be reused, so only customisation costs would have to be covered.
Administration
Very high Medium Central System
Project and contract management costs during the development phase would be much higher than in option 1 and 2, as the new system would entail two new procurements. There would be a need for separate (from the VIS) meetings, committees, what would also entail higher administrative costs.
Administrative costs during operational phase would be also higher than in option 1, because of higher monitoring and service desk efforts for a new system.
90
MS
The solution might require more training efforts than in options 1 and 2 at least for the technical staff who would have to deal with a new system and VIS evolution. Project management costs would be also higher.
High cost for Option 3 Overall Score for:
Cost Effectiveness 2
4.7.3. Key Findings
The table below summarises the main findings emerged from the analysis and from consultations with experts from eu-LISA and the European Commission and from the survey sent to the MS.
Pros Cons
More flexibility. By separating the residence cards into a new repository there would be more flexibility in the choice of technology for implementing the different components;
No need to extend the access of the VIS to new countries. Only the smaller new system would be connected to Ireland and the UK;
Fewer changes to the VIS would be required. Given the similarities between short-stay visas, long-stay visas and residence permits, more limited changes would be required compared to the scenario where residence cards would also be stored in the VIS (connections, access, type of documents, availability of data).
Cost inefficient;
Requires more effort to develop and maintain;
Not aligned with the current strategy and vision of a central system of information;
Extra challenges may arise with the difficulty of maintaining the data accuracy in two different systems and thus increasing the possible impact of data integrity and availability.
91
5. Conclusions
5.1. On the analysis of options
The preferred option to emerge from this study is Option 1: a repository as part of the VIS. It scores higher in all the criteria, especially at technical and operational levels. The impact that the repository would have on the existing VIS is low when considering the data model, services and overall capacity.
The following table summarises the scoring given to the three options in Chapter 4:
Table 27: Assessment table
Criterion/option Repository as part of VIS Repository as a separate
database Hybrid solution
IT Security 4 3 2
Ease of implementation 3 2 1
Cost-effectiveness 4 2 2
Member States would be able to reuse an existing and known system, if such a system does not alter the ‘as is’ processes. The repository would achieve all the business objectives set out in Chapter 3 and would be more in line with the current vision for border-management systems set out in the European Commission’s Communication of April 2017 on stronger and smarter information systems for borders and security:90 making full use of existing systems and managing data in a more effective and efficient way.
In addition, the repository could take advantage of the existing and future functionalities of the VIS. The changes to VIS provided for in the recast include many ancillary services, which will significantly enhance the system. Storing all the information centrally in VIS will yield optimised benefits derived from the new functionalities:
Data-quality indicators/warnings;
A central white list of valid documents;
A reporting and statistics engine;
Unique IDs for each of the MS authorities;
Data-amendment requests (integrating the VIS mail into the core services).
Lastly, it is also the most cost-effective option.
5.2. On the analysis of objectives and scope
Throughout the analysis undertaken within this study, some of the main findings were as follows:
If the second objective of the repository (i.e. assessing the personal history of third-country nationals) is retained, impacts would be felt on a number of points:
o It would impact on the repository’s legal basis, as this derives from Article 79 TFEU, not Article 77 (border checks);
o It would not apply to residence cards;
o It would justify the retention of the data for longer than its validity period.
90 See: http://www.eulisa.europa.eu/Newsroom/News/Documents/SB-EES/communication_on_stronger_and_smart_borders_20160406_en.pdf (accessed 05/2017).
92
Including Local Border Traffic permits in the repository would generate insufficient benefits to justify the effort. Moreover, including them would not address the underlying problems. Therefore, this should be out of the scope of the common repository;
Irrespective of the types of documents retained in the scope of the repository, they could all be placed into the same system. Different access rights may make it possible to legally treat them as separate entities (e.g. the United Kingdom and Ireland would not have access to the data on long-stay visas and residence permits, but could have an access right to residence cards only);
Member States not yet fully applying the acquis may require full access to the VIS in order to include the residence permits/long-stay visas that they issue. Passive access will only give them the possibility to verify a long-stay visa/residence permit issued by another MS that fully applies the acquis (but not LSVs/RPs issued by another MS not yet fully applying it);
Updates in the national system will trigger updates in the central repository. Therefore, initially, the new data set would be limited to information that already exists in national systems. As opposed to the current VIS, the data set will not include data collected during the application process.
5.3. Points of attention
Levels of integration in the VIS
Several levels of integration could be envisaged in order to use VIS for hosting information on the additional documents. The two most prevalent methods could be:
1. Adapting the existing database: data model (the one for short-stay visas) and other VIS components (procedures, queries, etc.) in order to integrate the new data;
2. Creating an additional database within VIS: data model and the new components for the data on new documents using the same logic as is used for existing ones
It is recommended that the details (outlining the precise data components and how they could specifically be remodelled) and impacts of these different integration levels be analysed in a more in-depth study.
Data-protection considerations
From a data-protection perspective, some considerations must be made on the proportionality of the options for implementing an EU-scale repository. It should be noted, however, that with the design, adoption and implementation of appropriate safeguards and IT security mechanisms, all of the options can be built to comply with the data-protection principles and requirements described in Section 3.8 (compliance with data protection legal framework). The main considerations, which should not constitute blocking factors and can be addressed through appropriate safeguards, are:
• Given that there are overlapping purposes between VIS and the intended repository (border control, migration authorities’ access), the proportionality of creating a new EU-scale central repository may be contested. The EDPS has recently raised this point, highlighting the fact that the multiplicity of large-scale EU information systems combined with continuously evolving institutional, policy and legal contexts has led to increased complexity in the applicable legal frameworks and data-governance models.91 On the basis of this reasoning, Option 1 appears to provide a more consistent and coherent approach.
91 See EDPS Opinion 7/2017 on the new legal basis of the Schengen Information System.
93
• Risk of data loss due to single point of failure must be specifically addressed: the physical concentration of data, despite logical segregation mechanisms, generally represents a higher risk from the data subject’s perspective because a hypothetical error in the system (system outage or failure, data loss or leak) affects more people and more data. This can be achieved with measures that are well known but the attention is drawn on the fact that they cannot be neglected.
Biometric data
The inclusion of biometric data for long-stay and residence documents has two main points of attention:
1. Availability. The survey sent to Member States showed the heterogeneity with which biometric data is stored at national level. Some Member States capture it but do not keep it after having issued the document, making it impossible to incorporate the data into the VIS and to use it for identification purposes.
2. Data quality. The survey also showed the different collection methods and uses of biometric data between Member States. Its quality is not certain and it is difficult to assess whether all photographs collected could be used as a biometric identifier for facial image recognition. This heterogeneity may also have a negative impact on the data quality of the VIS’s Biometric Matching System (BMS), as not all biometrics on long-stay and residence documents would be usable. The level of impact should be further studied.
5.4. Options for rolling out the repository
Various options can be considered for rolling out the repository, independently of the objectives, documents and technical option chosen:
1. Fresh start – gradually populating the repository
Pre-existing documents would not be loaded into the repository. The repository would start off as empty, with Member States beginning to insert data when a new application is processed or a new document is issued from the date on which the repository goes live. This would mean that application/document history, if retained as an objective, would not be available in the first few years of the repository’s existence. More importantly, as a border-control system, the repository would not be able to cover all the documents during this initial period. This option was chosen for the roll-out of the VIS as it is a case-management system.
2. Import all data available (bulk copy)
All Member States would connect their national systems to the repository and copy the data from all documents in circulation. This would mean that the repository would be fully operational at the borders and for migration authorities as soon as the repository went live. This option might be more difficult to handle at central level in terms of data quality.
The option could be modulated by taking only the documents (and applications, if this option is retained) issued from a certain date onwards (for example: in the last year). Since the central repository is fed by Member States’ systems, this ‘initial load’ requires the data to be prepared, tools for the upload made available and the estimated time taken into account for this upload. As an example in the case of the go-live of SIS II, the data existing in SIS I needed to be mapped to both a new data model and the existing data included in the SIS II database. This is a complicated, but only a one-off operation.
94
The following table summarises the main pros and cons of both options:
Table 28: Pros and cons of the two roll-out options
Option 1: gradually inserting data Option 2: importing all data
Pros
Better overview of the data quality and more margin for manoeuvre to correct this type of issue
Easier from a technical perspective
Defines a data-quality standard for incoming documents
Longer transition period
The system would be fully operational as of the go-live date, as all data would be included at once
Application/document history would also be available from the go-live date
Cons
Application/document history unavailable in the first few years of the system’s existence, as documents issued before the roll-out would not be included.
Automated border checks with the repository might not be possible to perform on all documents during the first few years of the repository’s existence.
Only documents issued as of the go-live date could be verified at the borders
TCNs processed differently depending on when their documents were issued
The repository would only be fully implemented at least five years after going live (or at least ten years for renewals of residence permits and cards)
Potential data-quality and accuracy issues – though these could be mitigated by loading data through an interface that could transform and adapt the data on a case-by-case basis
Time and cost of solving data-quality and accuracy issues
Member States may need to inform TCNs about a longer retention period for some of their personal data (e.g. facial images)
95
Annexes
96
Annex 1. – Glossary
The glossary is composed of the main acronyms used in the study:
ABC Automated Border Control
BCP Border-Crossing Point
EES Entry Exit System
ETIAS European Travel Information and Authorisation System
EU European Union
eu-LISA European Agency European Agency for the operational management of large-scale IT systems in the area of freedom, security and justice
IBM Integrated Border Management
JHA European Union’s Justice and Home Affairs
LBT Local Border Traffic (permit)
LSV Long-stay Visa
MS Member State
NI National Interface
RC Residence Card
RP Residence Permit
SAC Schengen Associated Countries (Iceland, Liechtenstein, Norway and Switzerland)
SBC Schengen Borders Code
SIS Schengen Information System
TCN Third-country national
TESTA-ng Trans-European Services for Telematics between Administrations - New Generation
VIS Visa Information System
97
Annex 2. – Legislative overview
The following table summarises the main legal texts relevant to the study:
Table 29: Draft table summarising the main legislation of interest, the domain and the field of application
Area EU legislation Content Applies to
Freedom of movement
Art. 21 TFUE Right to move and reside freely within the territory of Member States of the European Union.
European Union Member States (hereinafter EU MS)
Border checks Art. 77 TFUE Absence of controls when crossing internal borders;
Border checks at external borders;
Common policy on visas and other short-stay residence permits;
Conditions under which TCN shall have the freedom to travel within the Union for a short period;
Integrated border management system;
Provisions concerning passports, identity cards, residence permits or any other such document.
EU MS, but Ireland and the United Kingdom, and Schengen Associated Countries (SAC). Some specificities are to be taken into account for MS not yet fully applying the Schengen acquis (Bulgaria, Croatia, Cyprus and Romania)
Migration Art. 79 TFUE Common immigration policy and management of migratory flows
Fair treatment of TCN residing in the EU;
Conditions of entry and residence and standards on the issue of long-stay visas and residence permits;
Illegal migration, unauthorised residence and trafficking in human beings.
EU MS but Denmark Ireland and the United Kingdom
Long-stay visas Regulation (EU) 265/2010
Amending the Convention Implementing the Schengen Agreement and Regulation (EC) n° 562/2006 as regards movement of persons with a long-stay visa and extending the principle of equivalence between residence permits and short-stay visas
EU MS fully implementing the Schengen acquis and SAC
Border management Regulation (EU) 2016/399 Schengen Borders Code, establishing a Union Code on the rules governing the movement of persons across borders
EU MS fully implementing the Schengen acquis, SAC and partly EU MS not fully implementing the Schengen acquis
Residence permits Regulation (EC) 1030/2002 Laying down a uniform format for residence permits for third-country nationals
EU MS fully implementing the Schengen acquis, SAC and the United Kingdom
Regular migration Directive (EU) 2016/801 Conditions of entry and residence of TCN for the purposes of research, studies, training, voluntary service, pupil exchange schemes or educational projects and au pairing
EU MS but the UK, Ireland and Denmark
98
Directive 2014/66/EU Conditions of entry and residence of TCN in the framework of an intra-corporate transfer
Directive 2014/36/EU Conditions of entry and residence of TCN for the purpose of employment as seasonal workers
Directive 2011/98/EU The Single Permit Directive sets out a common, simplified procedure for TCN applying for a residence and work permit as well as a common set of rights to be granted to regular immigrants
Directive 2009/50/EC Conditions of entry and residence of TCN for the purposes of highly qualified employment: ‘EU blue card’
Directive 2005/71/EC Specific procedure for admitting TCN for the purposes of scientific research
EU MS, but the UK and Denmark
Directive 2004/114/EC Conditions of admission of TCN for the purposes of studies, pupil exchange, unremunerated training or voluntary service
EU MS but the UK, Ireland and Denmark Directive 2003/86/EC Provisions on the right to family reunification
Directive 2003/109/EC Concerning the status of TCN who are long-term residents
Residence cards Directive 2004/38/EC
On the right of citizens of the Union and their family members to move and reside freely within the territory of the Member States Amending Regulation (EEC) n° 1612/68 and repealing Directives 64/221/EEC, 68/360/EEC, 72/194/EEC, 73/148/EEC, 75/34/EEC, 75/35/EEC, 90/364/EEC, 90/365/EEC and 93/96/EEC
EU MS
Local Border Traffic permits
Regulation (EC) No 1931/2006 Laying down rules on local border traffic at the external land borders of the Member States and amending the provisions of the Schengen Convention
Applies EU MS (but Ireland and the UK), SAC and issued by EU MS with a land borders with a third country (not SAC)
VIS Council Decision 512/2004 Establishing the Visa Information System EU MS fully implementing the Schengen acquis, SAC and Denmark
VIS Regulation (EC) 767/2008 Specifying the Visa Information System EU MS fully implementing the Schengen acquis, SAC and Denmark
Visa policy Regulation (EC) 810/2009 Establishing a Community Code on visas EU MS fully implementing the Schengen acquis and SAC
Data protection Regulation (EU) 2016/679 Protecting natural persons with regard to the processing of personal data and on the free movement of such data
EU MS. It applies directly to MS and all natural/legal persons concerned
Data protection Regulation (EU) 2016/679 General Data Protection Regulation, repealing Directive 95/46/EC EU MS
99
Data protection Directive (EU) 2016/680
Protection of natural persons with regard 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, and on the free movement of such data
EU MS
Data protection Directive (EU) 2016/680 Repealing Council Framework Decision 2008/977/JHA EU MS
100
Annex 3. - VIS
The Visa information system92 (VIS) is a system for the exchange of short-stay visa data among Schengen Member States and, since December 2012, its operational management is under the responsibility of eu-LISA93. The VIS is a perfect example of a cooperative venture at EU level between the Commission and the Member States.
The main purpose of the VIS is to:
facilitate checks and the issuance of visas;
tackle abuses;
protect the travellers from identity theft via the biometric technology;
support asylum applications;
prevent, detect and investigate terrorist offences and other serious criminal offence
The illustration below provides an overview of the end-users at MS level and interactions with the VIS.
Figure 25: Overview of interactions between MS and the VIS
92 http://ec.europa.eu/home-affairs/what-we-do/policies/borders-and-visas/visa-information-system_en 93 http://www.eulisa.europa.eu/Pages/default.aspx
101
Security Assessment
This section describes our security assessment of VIS repository options depicted in Chapter 4. First the existing safeguards used at the VIS are described, because these safeguards form the baseline for options 1 and 2. This description is structured according to the ISO 27000 categories. This analysis is based on information exchanges between personnel from DG HOME and the Study Team, and on various VIS related documents94.
Safeguards
The VIS’ safeguards are implemented and operated according to the ISO 27002:2013 standard. Therefore, the overview of safeguards in place in this section is also elaborated following the structure of the ISO 27002:2013 clauses.
The current VIS safeguards structure follows the ISO 27000 standard. Access control and communication security are arguably the most relevant safeguards. The current system access control safeguards definitions provide one user per Member State, and define this user’s rights. Member states provide granular access control definitions to the different agencies and actors. The authentication and communication security uses VPN/IPsec connections and the TESTA-ng network.
Safeguards identification
Safeguards description VIS Safeguards
SG.01 Human
Resources
Human Resources safeguards address the human factor:
Prior to employment;
During employment; and
At time of termination and change of employment
This includes the recruitment, training and management of all staff involved in VIS design, implementation and operation. Hence, this includes recruitment, management and training of staff within VIS organizations, competent authorities, and Border Guards authorities. Also agreements with subcontractors are in place. This addresses:
Job descriptions and screening
Continuous Training and awareness Processes to management used information
Access privileges
Legal Confidentiality statements (NDA) Security Awareness training
SG.02 Access
Control
Physical and Logical Access Control should be implemented, and address:
Business requirements of access control; User access management and user
responsibilities;
System and application access control
Commission Decision (CD) of 29 October 2009 defines the access rights for license and certificate data when residing in the registers.
The VIS system distinguishes users based on different roles, as the follows:
Member States The VIS Responsible Agency (i.e. EU-Lisa)
Law enforcement and investigation bodies (e.g. Europol)
The VIS Access Control system uses Access Control Lists to define the roles associated to the Member State profile configured to manage information in the VIS. Each Member State represents a single user in the current VIS. The access granularity of each MS competent authority is managed locally by each MS.
SG.03 Cryptography Cryptographic controls address the confidentiality and integrity of the VIS information assets, in accordance with the classification of that asset. Cryptographic controls should be in place for each component, particularly addressing entity and message authentication, as well as the protection of information in transfer/in storage.
The VIS controls include cryptographic controls and key management mechanisms. Cryptographic means such as IPSEC and VPN security are employed to protect the confidentiality and/or integrity of the TCN information assets (PII), in accordance with the assessed classification of the information asset. The cryptographic means used follow article 6 of EC decision 2006/1494 concerning the security of information systems.
SG.04
Communications
Communications security addresses network security management and the security of
VIS networks include the following security controls, network security design and operational practices:
94 ‘VIS System Architecture V1.90’, ‘VIS NFRs v1.40’ and ‘VIS Security Target V1.00’.
102
Security information transfers. Encrypted communication at the different layers of the networking stack (i.e. application, transport, and network level).
Secure and authenticated connection support between the MS national system and the VIS central system, such as IPSec and T.
Secure perimeter of the network using firewalls limit the exposure of applications and infrastructure to only those services that are required to be provided externally (e.g. access to the BMS storing biometric data is separated by a firewall)
Allow secure and controlled access through IPsec or VPN connection among sensitive components (e.g., Interpol and Europol)
SG.05 System
acquisition,
development and
maintenance
System acquisition, development and maintenance safeguards address security requirements of information systems, as well as security in development and support processes, and for test data.
Security controls are included in standard development lifecycle are:
disabling of unnecessary services
changing insecure default configurations ensuring the latest system patches / security
updates are in place
installation of malware protection software, host IPS, and other security software
securing the bios/boot loaders
secure software development review full documentation and restriction of changes
protect applications and transactions
SG.06 Information
Security Incident
Management
Information Security Incident Management addresses the management of information security incidents and improvements. A formalized incident management process should be established to identify, respond to, recover from, and follow up security incidents. Intrusion detection or prevention systems should be implemented in key network points and at key information systems.
VIS security team is responsible for the following controls:
Monitor and report security weaknesses and events
Assess and respond to security events Collect evidence and learn from the security event
to reduce impact and likelihood of a future event
SG.07 Operations
Security
Operations security addresses: Operational procedures and responsibilities;
Backup, as well as Logging and monitoring;
Control of operational software; Technical vulnerability management including
protection from malware;
Information systems audit considerations.
Security controls for operations security include: Document procedures of VIS architecture and
processes
Implement technical malware protection, vulnerability management and imply software installation restrictions in VIS
Backup, log and monitor VIS data exchanges
SG.08 Asset
Management
Asset management ensures the identification and classification of the VIS information assets. The VIS information assets should be identified, classified and tracked, so that they can be used and disposed of in accordance with their level of sensitivity / classification. This allows identifying the level of protection that each data processed, stored and transferred in VIS should be mapped.
Controls enforce that VIS data should not be exposed externally without a defined and approved requirement, and should be used in accordance with their classification and sensitivity data should be securely destroyed when no longer required. This include: Hardware tamper resistance and hardware
protection safeguards (sensors and alarms, memory content protection, bus protection)
Application (web and mobile) security safeguards to protect the integrity and the process of information.
Database security connections. Data protection safeguards
Access control rules and policies
SG.09 Physical and
Environmental
Security
Physical security ensures the physical measures to protect the building, facilities and physical infrastructure, whereas environmental security ensures protection against environmental and natural hazards. For physical security, the definition and implementation of procedures to grant, limit and revoke access to organizational and assets premises, buildings and areas within the VIS system, this include Member State infrastructures. VIS premises, buildings and areas should be secured and
eu-LISA and the different MS implement physical security facilities and procedures. This includes: VIS resources located within controlled access
facilities,
Physical authentication controls to secure areas, Network segregation,
Secure and resilient equipment.
103
monitored against unauthorized access and physical attacks. For environmental security, measures should be established to protect against environmental hazards (e.g. fire, water, smoke, humidity, power outages, natural disasters such as floods, earthquakes). Consideration should be given to installing specialized equipment and devices to monitor and control the environment.
SG.10 Supplier
Relationships
Supplier relationships ensure a strategic plan related to the risks of the supplied components and software provided by external parties. These risks should be identified and managed throughout all stages of the relationship with external suppliers (including organizations in the supply chain), in order to mitigate fraudulent and tampered equipment and interactions with unwanted suppliers, vendors and partners.
eu-LISA uses hardware and software provides and outsources the development. The supplier relationship is managed via contractual level agreements, such as KPIs and SLAs. These contracts require the implementation and enforcement of security policies by suppliers.
SG.11 Information
Security Aspects of
Business Continuity
Management
Business continuity ensures the resilience and continuous operation of VIS services upon any disruptive incidents. A formalized plan, such as a Disaster Recovery Plan (DRP) should be in place to enable the VIS systems, assets and IT to respond to incidents and disruptions in order to continue operation of the VIS system and required IT services, while maintaining the availability of information at an acceptable level. This plan should be periodically tested, and updated as required.
VIS includes the following controls to guarantee continuous business operations in case of a security event.
Implement a Disaster Recovery Plan (DRP), Test and update the DRP timely and after major
security events.
SG.12 Information
Security Policies
The Information Security Polices addresses security regulation among the different VIS assets and components. Security policies englobes a set of rules that regulate the VIS system assets, components and organizations.
VIS security policies include the following rules and policies:
Program Policies: defines the scope of VIS organization, assigns the responsibilities and resources for implementation, and establishes the strategy.
Issue Policies: addresses issues such as contingency planning, the use of methodology for risk management, and the implementation of new regulations and laws. (requires frequent maintenance and revisions)
System Policies: addresses individual VIS systems, such as access control list and user's training. These polices may differ per system and components within the VIS system architecture.
VIS changes lead to reviews to these policies and rules.
SG.13 Organisation
of Information
Security
Organization of Information Security ensures the definition and management of information security on the full scope organizations. VIS should have a structure management framework that directs, monitors and controls the implementation of information security as a whole within the full architecture and organization of VIS. This includes a development of an Information Security strategy within VIS system, entities and assets that adopts, incorporates, reviews and implements the regulations and security controls.
The security controls implemented in VIS organization are as follows: Internal controls: division of responsibilities and
segregation of duties, and project management security.
Use of mobile device and teleworking controls, such as the use of VPN setting when accessing from external networks.
SG.14 Compliance Comply with Information Security regulations that precise access control and authorization, as well as logging following most compliance industry standards key requirements.
VIS complies with EU regulations and the related information security standards and best practices guidelines, such as ISO 27000, BSI and ENISA security guidelines. The security safeguards are based on the EC decision 2006/1494 on the security of information systems.
SG.15 Organization
of information
security
To establish an internal and remote management of information security. This includes the definition of a management framework for governance and operation of information security within the
Eu-LISA and MS follow organization framework by establishing segregation of duties, roles and responsibilities and appropriate project management measures. It also defines policies to ensure security
104
organization. during remote work by their employees.
105
Annex 4. – Summary of Member States' answers to the surveys
This annex summarises Member States’ answer to a survey sent in May 2017 (17 MS answered) and a European Migration Network survey sent in April 2017 (21 MS answered). Member States have been asked qualitative and quantitative questions, some of them on the ranking of different solutions (from 1 to 4, 4 being the best score).
1. Summary of MS answers All MS answered that the repository would be useful/very useful, in particular for border control purposes. Table 30 Answers from MS about the possible objectives for the repository
Objectives of the repository Importance for MS
1 Facilitate border checks 3.75/4
1.a Authentication of the document 3.8/4
1.b i) Determining that the TCN is the rightful owner of the document 3.8/4
1.b ii) Identification of the document’s holder using biometric data 3.7/4
2 Assess migration risk 3.1/4
2.a Access to the history of valid and previously issued/withdrawn documents 3.3/4
2.b Access to the history of denied applications 3.3/4
3 Support investigating a serious and organised crime 3.4/4
A Member State included an additional objective in the questionnaire: support to the decision-making process for asylum authorities. These authorities could use the biometric data to check if a TCN applying for asylum is known as a holder of a document issued by another country. This practice is of common use with the information contained in the VIS (art.22 of the VIS Regulation), so reusing the system would allow for this objective to be met with less implementation complexity. Additionally, about the utility to include the different documents in the repository, the MS replied the following:
Table 31: Preliminary table summarising the MS questionnaire on the added value of the documents
Documents Average score Long-stay visas 3.7/4 Residence permits 3.9/4 Residence cards 3.8/4 Local Border Traffic Permit 2/4
Table 32 Usefulness of the repository
Would a European central repository of long-stay visas, residence permits, residence cards and local border traffic permits be a useful tool for your day-to-day activities? If yes, how?
MS1 Yes
106
MS2 Yes. It would be a useful tool for the processing an application for a residence permit (to get the information on validity of a document issued by another Member State) and also for the procedure of termination of residence permit (checking the history of granted/withdrawn documents from other Member States and checking the history of previous applications and refusals of applications for residence permits from other Member States should get the information about the alien, if he moves abroad or remains out of the territory of the MS). In MS2, residence permits and residence cards are one and the same. Local border traffic permits do not belong to the part of the residence permits and they cannot be equated with a residence permit. Holders of local border traffic permits can move and reside only in the border region along the border in a Member State and a neighbouring third country, but they cannot, in any case, travel outside the geographically defined area (this is a violation of local border traffic regime and prescribes penalties). Common repository of these licenses does not make sense and is not usable. The matter was also highlighted in the conclusions for HLEG IT needs.
MS3 n/a MS4 Yes. For border control and territory checks of TCN holding such a document, it would be very
helpful for the officers to be able to verify the authenticity of such a document provided during such a control/check or to verify the pretension that a TCN who does not carry such a document is nevertheless the lawful holder of such a document. Additional Purpose: Asylum Process: Biometric check whether person applying for asylum are known as holders of a document issued by another country (analogue the checks some countries already do towards the VIS)
MS5 A central repository could come in handy mainly for the border police, during border checks. Such information would also be useful to consular posts, but also for immigration authorities when verifying the status of TCN with a long stay residence on the territory of the MS or Schengen Area and also for their family members, which need to extend their right to stay on MS5’s territory and have to present the document issued by the respective Member State.
MS6 n/a MS7 Yes, new EU tool is necessary to address the existing information gap on these categories of third-
country nationals. Some documents such as long-stay visas, residence permits and cards and local border traffic permits are issued by Member States and the information on their validity, status, etc. is collected and remains at national level. As a result Member States cannot ascertain the authenticity and validity of a document issued by another Member State.
MS8 Yes, the relevant authorities could check visa or residence document issued by another Member State in case of need without any delay.
MS9 Yes
MS10 Somehow useful
MS11 Yes. MS11 supports the creation of such a central repository. A central repository would close an important gap in the information needed to judge whether a person has the right to enter and stay in each EU Member State. This would facilitate and make border control more efficient. A central repository for residence permits would limit the confusion whether a residence permit of another Member State is authentic and still valid, and would give more information regarding the kind of residence permit (and thus the benefits it generated in the other Member State). The actual system of consultations via national contact points is in an administrative point of view burdensome.
MS12 Yes, for the purpose of identification of persons, or verification of authenticity of those, who are in possession of a long-stay visa, residence permit/card, or for the purpose of verification of veracity of third country nationals applying for visas/residence permits. Establishing such a repository would be also a useful tool for MS12 Border Guard’s day-to-day activities since they are responsible for carrying out the control of foreigners’ legality of stay in the territory and issuing return decisions to those staying therein illegally. Such a repository would allow to check the authenticity and validity of such documents as well as confirm the identity of the bearer of the document.
MS13 Yes, the implementation of a central repository of long-stay visas, residence permits, residence cards and local border traffic permits will be a very useful tool in relation to the daily activities. The access to data for the issued documents of this type will enable quick and effective verification of the identity of the document holders, including through the use of the enrolled biometric data, as well as for identification of the issued by the Member States documents. The repository will allow detection of cases of unlawfully issued documents – documents issued in due order to persons who provided false personal data when filing an application for their issuance
MS14 Ms14 is of the opinion that such EU-level repository would be highly relevant for migration authorities and border guards, as it would contain information on long-stay visas, residence permits, residence cards and, possibly, local border traffic (LBT) permits issued by all MS. In such a way, it would improve the effectiveness of controls of migration flows, as well as it could serve as a useful tool in making informed decisions in the area of migration (admission and return), as it would
107
provide information on the current immigration status of the person in the EU, and as well on his/her immigration history in the EU, if relevant. In addition, MS12 also considers that the respective repository would also be useful for law enforcement authorities for the purpose of detection and prevention of serious and organised crime.
MS15 A central repository of long stay visas, residence permits and residence card would be welcomed by the MS15. Firstly, a central repository for regular residence permits would be useful to check whether a person that stays in the territory with an expired or withdraw permit from another MS. Furthermore a repository can be useful to determine which MS is responsible for the asylum application in accordance with the Dublin regulation.
MS16 Such initiative would be very useful as it provides a detailed history of a Third-Country National’s stay in the European territory. The information would be useful in case a non-EU person submits an application for a visa or residence permit. The intentions of the applicant would be verified following an analysis of the person’s history within the EU. The measure would also give the opportunity to national authorities to check the validity of residence permits issued by another Member States, issued before or after a person submits an application to the national authority.
MS17 MS17 Agency for Integration: Yes – for identification of persons, authentication of documents, and checks of present and former applications and residence permits in EU countries. MS17 national police: Yes. When performing border control it would be useful for checking, if a person is allowed entry. MS17 Immigration Service: The Immigration Service finds that such a central register would be of great value. It would be useful in various types of case processing, including visa cases, asylum cases, family reunification cases and permanent residence cases. We would e.g. be able to:
Verify the authenticity of a residence permit. - For example, verify a former residence permit a third-country national might have had
before applying for a visa. And in connection with the future EES we would be able to check whether or not the applicant was in compliance with the entry and exit dates of the residence permit.
Verify if an applicant has a residence permit in another Member State even if the applicant does not inform us of this. Whether or not an applicant has a residence permit in another country is e.g. of importance in regards to the requirements the applicant must comply with in the applied permit.
Verify the identity of a residence permit holder with biometrics. - For example, verify the identity of an applicant for family reunification who may already
have a residence permit (e.g. family reunification or asylum) in another Member State.
Cancel a residence card in a central EU system. If a residence permit has been withdrawn and the foreigner still has the card, we would be able to cancel the card in a central system informing other national and European authorities that the residence card is invalid.
Table 33 Access requirements
Which authorities in your Member State would need to access the repository?
MS1 n/a
MS2 Diplomatic and consular representations abroad, Ministry of Foreign Affairs, Ministry of the Interior, Administrative units, Police
MS3 n/a
MS4 Border Control Authorities, Police Forces, Migration Offices, Asylum Authorities
MS5 Ministry of Home Affairs: General Inspectorate for Immigration, Border Police, National Police Ministry of Foreign Affairs: Diplomatic and Consular Missions
MS6 n/a
MS7 Migration services, consulates, border guard service, national law enforcement agencies
MS8 The relevant law enforcement authorities would need to access the repository
MS9 Ministry of Foreign affairs (for foreign representations issuing visas) and various law enforcement agencies, including Police and Border Guard Board, Internal Security Service, Information Board
MS10 Ministry of Interior
MS11 Immigration authorities, designated law enforcement authorities (included border control authorities), Ministry of Foreign Affairs
MS12 The list of authorities should be similar/same to the list of authorities with access to VIS (visa issuing/permit issuing authorities/border check authorities/territorial check authorities/asylum-
108
examination authorities/LEA).
MS13 Ministry of Interior, Ministry of foreign affairs and the State Agency for National Security. Within the Ministry of Interior, the following directorates should have access: Chief Directorate, Border Police, Migration Directorate, Identity Documents Directorate, etc. Indirect access should have State Agency for Refugees with the Council of Ministers, Ministry of labour and social policy, National Social Security Institute, etc.
MS14 Border authorities, immigration authorities, visa authorities and law enforcement authorities
MS15 Border check authorities, Immigration authorities, Visa authorities
MS16 Law enforcement institutions and national security authorities and the government agency responsible of issuing residence permits and visas
MS17 The Immigration Service, the Agency for Integration, the National Police, the Security and Intelligence Service, the Ministry of Justice, the State Administration and other relevant authorities
Table 34 Current process
What is the current procedure at the border-crossing point or in the territory when there is a doubt on the validity/authenticity of a long-stay visa, residence permit or residence card issued by another Member State?
MS1 When there is a reasonable doubt in the described way at the border crossing point, the officer in charge has to get in touch with the issuing authority by phone, mail or telefax; either directly or via a joint office. The person has to stay until the clarification at the border crossing point and is not allowed to pass
MS2 Border police authorities have a possibility to send a query to the responsible Member State via the existing Police and Customs Cooperation Centres. Such communication need additional time before the final decision is taken
MS3 n/a
MS4 The actual residence permit status is checked directly with the issuing authority, either via Sirene or the liaison office.
MS5 Both at the border and within the territory, in case of doubt regarding the validity/authenticity of a long-stay visa, residence permit or residence card issued by another Member State, the document is submitted in the second line to thorough checks on the document and against the relevant available databases (national, SIS and INTERPOL, iFADO etc.). Whenever necessary, the interview of TCN is conducted
MS6 n/a
MS7 Document physical security features are checked. In case of real doubts, document issued MS can be consulted.
MS8 On bilateral basis there is a possibility to request information from the country of issuance however the procedure is time consuming
MS9 Request through the National Contact Centre (NCC) to the NCC of the relevant MS
MS10 n/a
MS11 The border control authority examines at the external border and the federal police in the territory whether an identity document is authentic or not, they have the expertise. Immigration authorities can make decisions regarding the right of stay of these persons after having consulted the competent services of the police.
MS12 Direct contact with the authorities of the state that issued the document (through chain questions, through contact points at common borders, etc.)
MS13 In case of a border check on a first control line, there is a doubt on the authenticity of the visa or the residence permit, the document is sent for control on a second line – expert level where specially trained officers (experts) examine the document for the availability of security features and requisites, thus establishing whether it is genuine, has forgeries and deletions, and an expert conclusion is prepared. If necessary, the SIRENE Bureau in International Operational Cooperation Directorate within the Ministry of Interior is required to contact the relevant EU Member State that issued the document to provide additional information regarding the person to whom the document is issued, the term of validity of the document, to provide a photo, etc.
MS14 In such cases, additional checks in information systems, as well as Second line checks are carried out, where corresponding technical means are employed. In addition, document experts are involved and inquiries to other authorities are sent.
MS15 In case of a doubt on the authenticity of a document, further investigation is carried out by experts
109
from the Border check authorities, among which the expertise centre for Identity and Documents. In case of doubt on the validity, possibly in combination with purpose, duration and means, contact is done with the Immigration authorities.
MS16 Immigration authorities have direct access to the IT based system that is used for the issuance of residence permits. Moreover, they also have direct access to the visa case management and visas may also be checked directly from the BCP
MS17 National Police: If there is a doubt on a document issued by another Member State the person in question will undergo a thorough check and will eventually have to wait until the validity/authenticity of the document has been confirmed by the issuing Member State.
Table 35 Frequency of frauds
How frequently have abuses with this type of document been detected (e.g. use of falsified or forged documents, stay beyond the limits of the validity period…)? Do you have any figures?
Long-stay visas Residence permits Residence cards LBT permits
MS1 n/a n/a n/a MS1 has no external Schengen land borders, i.e. there is no local border traffic
MS2 In 2017 we notice an increase of abuse. Ca. 50 holders of MS2 long-stay visas left the territory and went to other Schengen countries
Two cases of abuse of MS2 residence permits were detected in the territory in 2017. The total number of residence permit abuses detected in territory in 2017 is 24.
n/a No abuses identified
MS3 n/a n/a n/a n/a
MS4 Very few Few n/a No
MS5 In 2016, 11 forged/counterfeited visas have been detected during border checks
In 2016, 20 forged/counterfeited residence permits have been detected during border checks
No No. MS5 has 2 LBT agreements in force. Starting with 2010, no abuses of the local border traffic regime were registered
MS6 n/a n/a n/a n/a
MS7 No Few: in 2015, 3 false residence permit where detected on the borders and in 2016, 3 false residence permit where detected on the borders (2 from MS7 and one from a another country)
No No: the LBT agreement with a non-EU country is not in force yet
MS8 Very few Very few Very few No
MS9 Important. Misuse of visas is the main modus operandi of illegal migration in MS9
n/a n/a n/a
MS10 n/a n/a n/a n/a
MS11 n/a n/a n/a n/a
MS12 Fair amount: in 2016, 1 678 persons had been detected with falsified long-stay visas
Few: in 2016, 53 persons had been detected with falsified residence permits and
No data. Similar to residence permits
No. We have not observed any significant abuse of LBT regime
110
and 3 407 persons, which enter the territory legally and then they overstayed. From January to April 2017, 587 persons had been detected with falsified long-stay visas and 1 294 which enter the territory legally using long-stay and then they overstayed.
168 persons which enter the territory legally and then they overstayed. From January to April 2017, 25 persons had been detected with falsified residence permits and 66 persons which enter the territory legally using, and then they overstayed.
MS13 Some: in 2016, a total of 39 totally falsified and forged visas were identified at BCP. Since 2017 until the end of May, there is only one case of a totally falsified visa at BCP. All types of visas are included in the provided number of visas. There are no cases of abuse with MS13 visas
In 2016, a total of 48 totally falsified, forged or relinquished residence permits were identified at BCP. Since 2017 until the end of May their number at BCP is 12. These numbers refer to documents of the other European countries. There are no cases of abuse with MS13 residence permits
n/a n/a
MS14 Overall, the rate of abuses is low (only 30 long-stay visas out of 4139 were annulled/revoked in year 2016). As the rate is this low, no particular reason for abuses can be identified and emphasised as frequent
Yes. Abuses of residence permits as regards the stay beyond the limits of the validity period have been encountered. However, there is no statistical data available on them
Abuses of residence cards, as regards the stay beyond the limits of the validity period, have been encountered. However, there is no statistical data available on them
No
MS15 n/a n/a n/a n/a
MS16 Such documents are abused in the same manner as in other EU jurisdictions. Applicants pose as students or as tourists and remain in the territory or else travel to other countries within the Schengen Area
No figures are recorded on the number of cases. There were only very rare occasions, brought to the attention of the administration involving the use of a forged residence permit allegedly issued by the MS16
MS16 has never encountered abuses related to residence cards issued to EU nationals. The expiry of the card does not mean that the holder is not allowed to remain in MS16. The residence cards of EU nationals and their family members may be renewed after their expiry date
n/a
MS17 n/a n/a n/a Never
111
Table 36 Collection and storage of biometrics
Do you store biometric data of the applicants in the national database? If yes, which ones (e.g. photograph, fingerprints)? How many fingerprints?
Long-stay visas Residence permits Residence cards LBT permits
MS1 n/a n/a n/a n/a
MS2 Photograph Facial image and FP, deleted 30 days after a decision is made on the permit
No n/a
MS3 n/a Photograph and 10 FP Photograph and 10 FP Photograph and 10 FP
MS4 Photograph for all applicants and fingerprints in some cases (10 FP)
Facial image and 2 FP n/a n/a
MS5 Not yet, until full application of the Schengen acquis/VIS decision
Photograph and signature
Photograph Photograph, signature and fingerprints
MS6 n/a Photograph and 2 FP, deleted if the permit is collected. If not collected, data kept for 6 months
No n/a
MS7 Photograph and 10 FP Photograph and 2 FP Photograph and 2 FP n/a
MS8 No No No No
MS9 Photograph and 10 FP Photograph and 2 FP Photograph and 2 FP n/a
MS10 n/a Photograph and 2 FP n/a Photograph and 2 FP
MS11 Photograph and FP Photograph n/a n/a
MS12 n/a Photograph, signature, and 2 FP, but only for the purpose of issuing the document as thereafter the data is deleted
Photograph, signature, and 2 FP, but only for the purpose of issuing the document as there after the data is deleted
Photograph
MS13 Photograph and FP Photograph and 10 FP Photograph and signature
n/a
MS14 Photograph Photograph and 2 FP Photograph and 2 FP Photograph
MS15 Photograph and 10 FP Photograph and 10 FP n/a n/a
MS16 Photograph Photograph and 2 FP Photograph n/a
MS17 No Photograph, signature and 2 FP stored only for issuing the document: deleted 90 days after the issuance or final rejection. New legislation is expected as of July 1, 2017 which – if implemented – will allow storage of both photograph and FP
Photograph, signature and 2 FP stored only for issuing the document: deleted 90 days after the issuance or final rejection. New legislation is expected as of July 1, 2017 which – if implemented – will allow storage of both photograph and FP
n/a
2. EMN survey From the EMN 2017 survey, all MS (21/21) stated they store data on long-stay visa applications and only 3/21 use a different system for withdrawn and renewed documents. For residence permits, the data is
112
similar, but only 2/21 use a different system. All MS use the same system for applications and issued residence cards.
113
Annex 5. – Data set comparison
The following table compares the different data set contained in the four types of documents which format has been harmonised at EU level: short-stay visas, long-stay visas, residence permits and local border traffic permits. It shows whether this data is contained on the document itself (either sticker, card or other type of stand-alone document), in its machine-readable zone (MRZ) or in the passport:
Table 37: Comparison of the data contained in the documents
Short-stay visa Long-stay visa Residence permit
Local border traffic permit
Biographical information First name √ + MRZ P** √ √ Last name √ + MRZ P** √ √ Surname at birth P P P Date of birth √ MRZ P √* √ Place of birth P P √*
Nationality √ MRZ P √* √ Place of residence P P √* √ Sex √ MRZ P √*
Address √
not mandatory
Biometric data Photograph √ P √ √ Fingerprints √ P √ √ Signature √
Document information Issuing MS √ √ √ √ Type of document √ √ √ √ Type of visa/permit √ √
Document number √ MRZ √ √ √ Validity period √
“from…to” + date of issue + date of start and end of validity
in MRZ
√ “from…until” +
date of issue
√ “valid until” + date
of issue
√ date of issue +
period of validity
Territorial validity √ + MRZ √ Not relevant √ border area
Number of entries √ + MRZ √ Not relevant Not relevant
Duration of stay √ + MRZ √ Not relevant Not relevant
Place of issue √ √ √
Passport number √ √ √* √ Remarks √
(“comments”) √ √
(√): data available in the documents (sticker, card, stand-alone document). (√ MRZ): information available in the MRZ of the visa. (√ + MRZ): information available in the visa and in the MRZ. (p) data available in the passport. (*) in case of a stand-alone document, not a sticker. If a sticker, then data included in the passport. (**) included in the sticker itself by a newly adopted Council Regulation amending Regulation (EC) No 1683/95 lawing down a uniform format for visas95.
95 See: http://data.consilium.europa.eu/doc/document/PE-20-2017-INIT/en/pdf (consulted 07/2017)
114
Related Documents
