Vu la loi du - Privacy Commission

1/14
Le Comité sectoriel du Registre national
Délibération RN n° 83/2016 du 19 octobre 2016
Objet : demande formulée par le Service public fédéral ICT (Fedict) afin que soit revue la délibération
RN n° 06/2016 en matière d'identification et d'authentification transfrontalières (RN-MA-2016-158)
Le Comité sectoriel du Registre national (ci-après "le Comité") ;
Vu la loi du 8 août 1983 organisant un Registre national des personnes physiques (ci-après la "LRN") ;
Vu la loi du 8 décembre 1992 relative à la protection de la vie privée à l'égard des traitements de
données à caractère personnel (ci-après la "LVP"), en particulier l'article 31bis;
Vu l'arrêté royal du 17 décembre 2003 fixant les modalités relatives à la composition et au
fonctionnement de certains comités sectoriels institués au sein de la Commission de la protection de
la vie privée;
Vu la délibération RN n° 06/2016 du 10/02/2016 ;
Vu la demande de révision du Service public fédéral ICT (Fedict) reçue le <datum> 27/04/2016 ;
Vu la demande d'avis technique et juridique adressée au Service public fédéral Intérieur en date du
27/06/2016
Vu l'avis technique et juridique reçu le 26/07/2016 [date] ;
Vu le rapport de la Présidente ;
Délibération RN 83/2016 - 2/14
Vu les décisions du Comité des 27/07/2016 et 14/09/2016 de suspendre le traitement de ce dossier
en attendant l’avis de la Commission de la protection de la vie privée concernant l'avant-projet de loi
relative à l'identification électronique (lié au Règlement (UE) n° 910/2014) ;
Émet, après délibération, la décision suivante, le 19 octobre 2016 :
I. OBJET DE LA DEMANDE
1.
La demande vise à ce que Fedict, ci-après "le demandeur", soit autorisé à :
•
accéder aux informations mentionnées à l’article 3, premier alinéa, 1° à 5° de la LRN ;
•
utiliser le numéro de Registre national ;
en vue de l'authentification transfrontalière.
2.
Par la délibération RN n° 06/2016, le Comité a refusé au demandeur l'accès aux informations
demandées du Registre national. L'utilisation du numéro de Registre national a par contre été
autorisée, moyennant le respect d'un certain nombre de conditions préalables.
3.
Par courrier du 21/04/2016, le demandeur a demandé au Comité de revoir la délibération
susmentionnée. Il attire à cet effet l'attention sur les éléments suivants :
•
il n'est pas exclu que d'autres moyens d'identification électronique que la carte d'identité
électronique (eID) et la carte d'étranger électronique ne contenant pas nécessairement une
puce sur laquelle sont enregistrées des données à caractère personnel soient notifiés ;
•
lorsque l'eID ou la carte d'étranger électronique sont utilisées de manière non connectée, il
est impossible de lire la puce ;
•
le Federal Authentication Service (FAS) n'est techniquement pas équipé pour lire la puce de
cartes ;
•
au besoin, un STORK ID distinct sera constitué par pays mais c'est le pays receveur qui
déterminera si le STORK ID différera également par application au sein de ce pays.
4.
Dans un souci de clarté, le Comité analysera à nouveau la demande initiale, en tenant compte
des arguments avancés par le demandeur dans son courrier du 21/04/2016.
Délibération RN 83/2016 - 3/14
II. EXAMEN DE LA DEMANDE
5.
Le Comité a déjà accordé au demandeur plusieurs autorisations afin d'accéder à un certain
nombre d'informations du Registre national et/ou d'utiliser le numéro de ce Registre.
6.
Lors de son examen, le Comité peut dès lors se limiter à vérifier si, en la matière :
•
la finalité pour laquelle l’utilisation est à présent demandée est déterminée, explicite et légitime
au sens de l'article 4, § 1, 2° de la LVP ;
•
l'accès aux données et l'utilisation du numéro de Registre national sont proportionnels à la
lumière de la finalité (article 4, § 1, 3° de la LVP).
A. FINALITÉ
7.
Le 23 juillet 2014, le Règlement (UE) n° 910/2014 du Parlement européen et du Conseil sur
l’identification électronique et les services de confiance pour les transactions électroniques au sein du
marché intérieur et abrogeant la directive 1999/93/CE, ci-après le Règlement, a été promulgué.
Ce dernier est entré en vigueur le 17/09/2014 1.
8.
L'article 6 de ce Règlement dispose que :
"1. Lorsqu’une identification électronique à l’aide d’un moyen d’identification électronique
et d’une authentification est exigée en vertu du droit national ou de pratiques
administratives nationales pour accéder à un service en ligne fourni par un organisme du
secteur public dans un État membre, le moyen d’identification électronique délivré dans
un autre État membre est reconnu dans le premier État membre aux fins de
l’authentification transfrontalière pour ce service en ligne, à condition que les conditions
suivantes soient remplies :
a)
la délivrance de ce moyen d’identification électronique relève d’un schéma
d’identification électronique qui figure sur la liste publiée par la Commission en vertu de
l’article 9 ;
b)
le niveau de garantie de ce moyen d’identification électronique correspond à
un niveau de garantie égal ou supérieur à celui requis par l’organisme du secteur public
concerné pour accéder à ce service en ligne dans le premier État membre, à condition
1
Voir l'article 52.1 du Règlement.
Délibération RN 83/2016 - 4/14
que le niveau de garantie de ce moyen d’identification électronique corresponde au
niveau de garantie substantiel ou élevé ;
c)
l’organisme du secteur public concerné utilise le niveau de garantie substantiel
ou élevé pour ce qui concerne l’accès à ce service en ligne.
Cette reconnaissance intervient au plus tard douze mois après la publication par la
Commission de la liste visée au point a) du premier alinéa. (...)".
9.
Cet article doit impérativement être appliqué au plus tard le 18/09/2018 2. Avant cette date,
on peut déjà procéder, sur une base volontaire, à une reconnaissance mutuelle. Ce Règlement vise
l'identification et l'authentification tant dans le secteur public que dans le secteur privé et donc
commercial 3.
10.
L'article 12 du Règlement, d'application depuis le 17/09/2014 4, prévoit à cet effet une
coopération et une interopérabilité et précise en quoi cela consiste. L'article 3 de la Décision
d'exécution (UE) 2015/296 de la Commission du 24 février 2015 établissant les modalités de
coopération entre les États membres en matière d'identification électronique conformément à l'article
12, paragraphe 7, du règlement (UE) n° 910/2014 du Parlement européen et du Conseil sur
l'identification électronique et les services de confiance pour les transactions électroniques au sein du
marché intérieur, ci-après la Décision d'exécution, stipule qu'aux fins de la coopération entre les États
membres prévue à l'article 12, paragraphes 5 et 6, du Règlement, chaque État membre désigne un
guichet unique.
11.
Le demandeur a été désigné en tant que guichet. Étant donné que les missions qui ont été
confiées au demandeur par son arrêté de création 5 n'ont pas été explicitement limitées au contexte
belge, on peut conclure que ce rôle en tant que guichet, tel que visé à l'article 3 de la Décision
d'exécution, s'inscrit dans le cadre de ses missions réglementaires.
12.
Afin de mettre en pratique l'identification et l'authentification transfrontalières, on travaillera
sur la base de la philosophie expérimentée dans le cadre du projet Stork, ce qui n'exclut pas que :
•
2
cette approche soit adaptée dans le futur en fonction de l'évolution technologique ;
L'article 52.2.c) du Règlement.
Voir le considérant 2 du Règlement : "Le présent règlement vise à susciter une confiance accrue dans les transactions
électroniques au sein du marché intérieur en fournissant un socle commun pour des interactions électroniques sécurisées entre
les citoyens, les entreprises et les autorités publiques et en accroissant ainsi l’efficacité des services en ligne publics et privés,
ainsi que de l’activité économique et du commerce électronique dans l’Union".
3
4
Voir l'article 52.2. a) du Règlement.
5
Arrêté royal du 11 mai 2001 portant création du Service public fédéral Technologie de l'Information et de la Communication.
Délibération RN 83/2016 - 5/14
•
sur la base du Règlement, d'autres possibilités d'authentification transfrontalière soient
élaborées.
13.
Dans l'état actuel des choses, une architecture distribuée sera élaborée, devant permettre une
prestation de services intégrée au-delà des frontières des États membres en recourant aux
spécifications et aux infrastructures utilisées actuellement dans chaque État membre. Cela signifie que
les systèmes existants d'identification et d'authentification électroniques des États membres sont reliés
entre eux dans un ensemble.
14.
Selon la demande, la situation se présente actuellement selon le schéma suivant :
15.
D'après la demande, les principaux composants du scénario illustré ci-dessus, sont les
suivants :
•
SP (Service Provider) : le Service Provider est localisé dans l'État membre S et fournit des
services demandés par un utilisateur ;
Délibération RN 83/2016 - 6/14
•
PEPS (Pan-European Proxy Service) : au départ, un État membre S utilise un PEPS-S dans
l'État membre où le Service Provider est établi en vue de l'identification et de l'authentification
de l'utilisateur. Un deuxième PEPS (PEPS-C) est présent dans l'État membre C (l'État membre
où le citoyen est enregistré) ;
•
V-IDP (Virtual Identity Provider) : le PEPS de l'État membre S a accès au Middleware (MW)
d'un autre État membre via un V-IDP (directement relié au PEPS-S) ;
•
SP-WARE : le V-IDP utilise un SP-WARE pour accéder au Middleware d'un État membre ;
•
MW (Middleware) : ce logiciel est propre à chaque État membre et est utilisé pour accéder à
la carte d'identité électronique de l'utilisateur ;
•
IDP (Identity Provider) : l'État membre C utilise l'Identity Provider (propre à l'État membre)
pour réaliser l'authentification.
16.
Le Comité constate qu'il s'agit en fait de la même architecture et de la même méthode que
celles mises en œuvre dans le cadre du projet Stork. Dans l'attente d'accords communs pour tous les
participants, le demandeur conclura avec les autres PEPS concernés des conventions établissant des
accords relatifs à la sécurité de l'information et à la protection de la vie privée.
17.
Une identification et une authentification transfrontalières permettront de réclamer en
Belgique les données requises à cet effet de Belges et de citoyens ne faisant pas partie de l'Union
européenne disposant d'une carte d'étranger électronique belge et souhaitant accéder à un service
électronique proposé par un État membre de l'Union européenne.
18.
Le PEPS belge est localisé au sein du demandeur. Il assurera l'authentification à l'aide d'un
accès à l'Identity Provider. En Belgique, CSAM-FAS (Common Secure Access Management-Federal
Authentication Service) assure le rôle d'Identity Provider. Lorsqu'un citoyen belge ou un citoyen ne
faisant pas partie de l'Union européenne et disposant d'une carte d'étranger belge se connecte à une
application d'un autre État membre de l'Union européenne, ce dernier prendra contact avec le PEPS
belge. Celui-ci vérifie l'identité (identification et authentification) via CSAM-FAS. Dans ce cadre, on
utilise le numéro de Registre national comme pour toute vérification d'une identification via CSAMFAS. Le numéro de Registre national est traduit en un STORK ID unique. En principe, le numéro de
Registre national n'est pas envoyé mais bien le STORK ID.
19.
Lors de l'identification et de l'authentification, il est possible que l'application étrangère
souhaite également la communication de plusieurs autres données d'identification minimales.
20.
Concrètement, un ensemble maximum de données sera convenu par pays. Dans cet accord,
le pays concerné devra prouver la proportionnalité des données demandées. On établira ensuite, par
authentification, quelles données de cet ensemble sont obligatoires et lesquelles sont optionnelles.
Délibération RN 83/2016 - 7/14
Lorsqu'un citoyen n'est pas d'accord avec la communication des données obligatoires, cela implique
qu'il renonce à l'utilisation de l'application. S'il n'est pas d'accord avec la communication des données
optionnelles, il peut utiliser l'application. Les données optionnelles ne sont pas transmises dans ce cas.
Le demandeur extraira de facto, à la demande et avec l'accord du citoyen, certaines données du
Registre national via son FSB (Federal Service Bus) et les transmettra ensuite au PEPS d'un autre pays.
21.
Pour un résident de l'Union européenne qui souhaite accéder à un service électronique belge,
les données requises seront réclamées dans l'État membre correspondant et seront ensuite transmises
à l'application en question en Belgique.
22.
Le Comité constate que la finalité est déterminée et explicite. Elle est également légitime étant
donné que les traitements qui en découlent se fondent sur l'article 5, premier alinéa, a) de la LVP
d'une part et sur l'article 5, premier alinéa, c) de la LVP d'autre part.
B. PROPORTIONNALITÉ
B.1 Quant aux données
23.
Le demandeur souhaite accéder aux informations mentionnées à l'article 3, premier alinéa, 1°
à 5° de la LRN , à savoir :
24.
•
les nom et prénoms ;
•
le lieu et la date de naissance ;
•
le sexe ;
•
la nationalité ;
•
la résidence principale.
L'annexe du Règlement d'exécution (UE) 2015/1501 de la Commission du 8 septembre 2015
sur le cadre d'interopérabilité visé à l'article 12, paragraphe 8, du règlement (UE) n° 910/2014 du
Parlement européen et du Conseil sur l'identification électronique et les services de confiance pour les
transactions électroniques au sein du marché intérieur (ci-après le Règlement d'exécution (UE)
2015/1501) définit l'ensemble minimal de données à caractère personnel représentant de manière
univoque une personne physique6.
25.
Il y est stipulé que cet ensemble contient les attributs obligatoires suivants : nom(s) de famille
actuel(s), prénom(s) actuel(s) et date de naissance. Il est en outre précisé qu'il peut contenir un ou
6
Article 12, quatrième alinéa, d) du Règlement.
Délibération RN 83/2016 - 8/14
plusieurs attributs supplémentaires (optionnels), à savoir prénom(s) et nom(s) de famille à la
naissance, lieu de naissance, adresse actuelle et sexe.
26.
Les données d'identification qui doivent obligatoirement être envoyées sont reprises sur la
puce de l'eID et de la carte d'étranger électronique. En théorie, ces données pourraient être lues et
ensuite transmises. Ce n'est toutefois pas une option étant donné le fait que :
•
selon toute probabilité, d'autres moyens d'identification électronique que l'eID et la carte
d'étranger électronique seront notifiés, ne disposant pas nécessairement d'une puce et, s'ils
en disposent, la puce ne contiendra pas nécessairement les données à caractère personnel
requises ;
•
l'eID et la carte d'étranger électronique seront également utilisées d'une manière non
connectée, rendant la lecture de la puce impossible ;
•
27.
le FAS n'est pas équipé pour lire une puce.
La manière la plus pratique de transmettre ces données est donc de recourir à la source
authentique pertinente, à savoir le Registre national. Le demandeur extraira seulement les données
obligatoires du Registre national. Il ne les extrait pas pour son propre usage mais pour une
communication à des instances publiques et/ou privées étrangères. On pourrait affirmer qu'une
communication d'informations du Registre national est organisée au profit d'instances qui, sur la base
de l'actuelle LRN, n'entrent pas en ligne de compte pour obtenir une telle communication. Dans l'état
actuel de la législation, ce Registre n'est pas ouvert à "l'étranger" et encore moins au "secteur
commercial". À la lumière de cet élément, la Commission estime qu'il convient de réglementer la
communication des données du Registre national à des acteurs étrangers afin d'éviter toute discussion.
28.
En attendant une telle réglementation légale, le demandeur est toutefois obligé, lors d'une
utilisation transfrontalière d'un moyen d'identification électronique, de fournir aux instances étrangères
concernées l'ensemble minimal de données à caractère personnel imposé par le Règlement d'exécution
(UE) 2015/1501.
29.
En vertu de l'article 6, § 3 de la loi du 19 juillet 1991 7, le titulaire d'une eID peut, au moyen
de cette carte, consulter les informations le concernant qui sont enregistrées dans le Registre national.
En outre, l'article 2, premier alinéa de l'arrêté royal du 16 juillet 1992 relatif à la communication des
informations contenues dans les registres de la population et dans le registre des étrangers prévoit
que toute personne peut obtenir un extrait du registre de la population ou du registre des étrangers
relatif aux données la concernant. L'application "mon dossier" du Registre national permet au titulaire
Loi du 19 juillet 1991 relative aux registres de la population, aux cartes d'identité, aux cartes d'étranger et aux documents de
séjour et modifiant la loi du 8 août 1983 organisant un Registre national des personnes physiques.
7
Délibération RN 83/2016 - 9/14
d'une eID d'obtenir cet extrait sous forme électronique. Cet extrait contient notamment les données
qui font partie de l'ensemble obligatoire et de l'ensemble optionnel.
30.
Théoriquement, un citoyen domicilié en Belgique dispose des moyens nécessaires pour fournir
de manière valable les données qui doivent obligatoirement être communiquées ou qui peuvent l’être
à titre optionnel lors de l'identification électronique transfrontalière. L'organisation pratique de cette
communication n'est pas évidente et en outre, l'obligation de fournir ces données incombe au
demandeur.
31.
En permettant au demandeur d'extraire les données requises du Registre national après que
la personne concernée ait au préalable donné son consentement informé, il devient possible, dans le
cadre d'une identification transfrontalière, d'utiliser le règlement relatif à l'extrait électronique et de
communiquer les données qui doivent ou qui peuvent l’être. Le Comité souligne que cette approche
ne peut constituer qu'une solution temporaire. Comme déjà précisé au point 27, en la matière, une
intervention légale à court terme est nécessaire.
32.
Les données auxquelles un accès est demandé sont les mêmes que celles auxquelles un accès
a été accordé par la délibération RN n° 55/2010 en vue du projet pilote Stork. Compte tenu du contenu
des données de l'ensemble obligatoire et optionnel, tel que défini par le Règlement d'exécution (UE)
2015/1501, le Comité constate que la donnée "nationalité" n'est pas mentionnée. À défaut d'une autre
justification, l'accès à cette donnée doit être qualifié de non pertinent (article 4, § 1, 3° de la LVP).
B.2. Quant à l'utilisation du num éro de R egistre national
B.2.1. Utilisation par le demandeur en vue du processus d'identification et d'authentification
33.
Pour les fournisseurs d'un service électronique, il est essentiel de pouvoir identifier et
authentifier non seulement les utilisateurs du pays de l'Union européenne où ils sont établis mais
également les utilisateurs d'autres pays de l'Union européenne. Les fournisseurs doivent être certains
de l'identité de la personne qui souhaite utiliser leur service électronique.
34.
En Belgique, l'identification et l'authentification se font à l'aide de l'eID ou de la carte
d'étranger électronique (le token fédéral sera progressivement supprimé). À cet effet, on utilise dans
ce processus le numéro de Registre national de la personne concernée de manière à pouvoir exclure
les erreurs dues notamment à des fautes d'orthographe et à une homonymie.
35.
À la lumière de la finalité indiquée, l’utilisation du numéro de Registre national souhaitée par
le demandeur est conforme à l’article 4, § 1, 3° de la LVP.
Délibération RN 83/2016 - 10/14
B.2.2. Création du STORK ID
36.
L'annexe du Règlement d'exécution (UE) 2015/1501 dispose aussi que l'ensemble minimal de
données contient également un identifiant unique, créé par l'État membre expéditeur conformément
aux spécifications techniques aux fins de l'identification transfrontalière et qui soit aussi persistant que
possible dans le temps.
37.
Il ressort de la demande que le demandeur, en tant que PEPS, constituera, sur la base du
numéro de Registre national, un code unique, appelé STORK ID, qui peut servir d'identifiant unique.
38.
Dans la mesure où il s'agit d'une application du secteur privé/commercial, cela reviendrait à
ce que par exemple des entreprises étrangères disposent d'un numéro de Registre national codé
(le demandeur conserve un tableau de concordance) alors que cela est actuellement exclu pour les
entreprises belges. Concernant cet identifiant unique, le rapport du eIDAS Technical Sub-group du
22/06/2015 précise :
“The third part a combination of readable characters. This uniquely identifies the identity
asserted in the country of origin but does not necessarily reveal any discernible
correspondence with the subject's actual identifier (for example, username, fiscal number
etc)”.
39.
Sur la base de ces éléments, le Comité estime que si un identifiant unique doit déjà être
communiqué vis-à-vis d'applications du secteur privé/commercial, on ne peut pas utiliser le numéro
de Registre national dans ce cadre.
40.
Lorsqu'il s'agit d'une application publique, le Comité renvoie à ce qu'il a fait remarquer à cet
égard dans la délibération RN n° 55/2010 :
"18. Dans le contexte européen, certaines matières font l'objet de règlements qui
disposent que les autorités et organes des États membres s'assistent réciproquement
comme s'il s'agissait de l'application de leur propre législation. Dans la mesure où, dans
de telles matières, une autorité belge est, en vertu de sa réglementation nationale, soit
obligée d'utiliser le numéro d'identification, soit autorisée à l'utiliser, la communication du
numéro d'identification du Registre national à une autorité ou à un organe d'un autre État
membre européen ne pose en principe pas de problème, pour autant que cet État
garantisse un niveau de protection similaire à celui de la Belgique.
Délibération RN 83/2016 - 11/14
19. Cela signifie que le demandeur fournit le numéro d'identification du Registre national
sous forme non codée à des autorités et organes d'un État membre européen lorsque
cela s'inscrit dans le cadre de l'exécution d'un règlement européen – comme indiqué ciavant au point 18."
41.
Toutefois, il n'existera pas toujours un tel règlement. Dans ce cas, l'alternative proposée par
le demandeur, à savoir la constitution d'un STORK ID, peut être utilisée, étant entendu qu'un STORK
ID différent sera constitué en fonction du pays et de l'application (sans quoi, à terme, des connexions
en réseau pourraient être créées au niveau européen sur la base du STORK ID).
B.3. Quant à la durée de l'autorisation et à la fréquence de l'accès
42.
Un accès permanent est demandé. Le Comité estime qu'un accès permanent en la matière est
approprié vu que, comme cela est précisé à juste titre dans la demande, la nature des activités pour
lesquelles cet accès est demandé requiert la possibilité de procéder à une consultation à tout moment
(article 4, § 1, 3° de la LVP).
43.
Une autorisation d'une durée indéterminée est demandée, vu que le système d'identification
et d'authentification transfrontalières mis en place en exécution du Règlement n'a pas été limité dans
le temps.
44.
À la lumière de cet élément, le Comité juge qu'une autorisation d'une durée indéterminée est
appropriée (article 1, § 1, 3° de la LVP).
B.4. Quant au délai de conservation
45.
En ce qui concerne les données extraites du Registre national, le demandeur précise qu'il
fonctionne uniquement en tant que volet de transmission et qu'il ne conserve pas ces données.
Le Comité en prend acte.
46.
En ce qui concerne le numéro de Registre national, le demandeur affirme qu'il le conserve
dans les loggings, et ce pendant au moins 10 ans. Ce numéro permet au demandeur :
•
de contrôler les consultations des données dans le Registre national ;
•
en cas de discussion ou de problèmes, de retrouver l'identification et l'authentification
réalisées.
Délibération RN 83/2016 - 12/14
47.
Un système de journalisation permet de contrôler a posteriori les opérations effectuées
notamment en matière d'irrégularités ou d'abus. Étant donné que de tels irrégularités ou abus peuvent
constituer un fait punissable, le Comité a déjà jugé, à plusieurs reprises, qu'un délai de conservation
de 10 ans était acceptable à la lumière de l'article 4, § 1, 5° de la LVP.
B.5. Usage interne et/ ou com m unication à des tiers
48.
Selon ses propres dires, le demandeur n'utilise pas les données extraites. Il les transmet au
citoyen qui les a réclamées, éventuellement après avoir procédé à une opération. C'est ce dernier qui
décide au final s'il transmet ou non ses propres données.
49.
Le Comité en prend acte mais précise que le demandeur utilise bel et bien le numéro de
Registre national de la personne concernée en interne en vue de la traçabilité de l'opération.
B.6. Connex ions en réseau
50.
La demande ne fait pas mention de connexions en réseau. Le Comité en prend acte.
51.
Par souci d'exhaustivité, le Comité attire l'attention sur le fait que :
•
si des connexions en réseau devaient être réalisées ultérieurement, le demandeur devra l'en
informer au préalable, sauf autorisation d'un autre comité sectoriel ;
•
le numéro de Registre national ne peut être utilisé dans des relations avec des tiers que pour
autant que cela s'inscrive dans le cadre des finalités pour lesquelles ces derniers ont également
été autorisés à utiliser ce numéro.
C. SÉCURITÉ DE L'INFORMATION
C.1. Conseiller en sécurité de l'inform ation
52.
Le Comité constate que le demandeur dispose d'un conseiller en sécurité de l'information.
C.2. P olitique de sécurité de l'inform ation
53.
Il ressort des documents communiqués que le demandeur dispose d'une politique de sécurité
de l'information et d'un plan d'exécution de celle-ci.
54.
Le Comité en a pris acte.
Délibération RN 83/2016 - 13/14
C.3. P ersonnes qui accèdent aux inform ations/ utilisent le num éro de R egistre national et
liste de ces personnes
55.
Le Comité déduit de la demande que :
•
les membres du personnel du demandeur proprement dits n'ont pas accès aux informations.
Il s'agit d'une consultation automatisée lors du processus d'identification et d'authentification
de la personne concernée. Les membres du personnel du demandeur sont toutefois chargés
de la surveillance du processus ;
•
le numéro de Registre national est enregistré et conservé dans les loggings en vue du contrôle
et de la traçabilité. Cela implique que les membres du personnel du demandeur qui sont
chargés du contrôle et répondent aux questions relatives à la traçabilité utiliseront ce numéro.
56.
Comme le prescrit l'article 12 de la LRN, le demandeur doit dresser une liste des personnes
qui utilisent le numéro de Registre national. Cette liste sera continuellement actualisée et tenue à la
disposition du Comité.
57.
Les personnes figurant sur cette liste doivent en outre signer une déclaration par laquelle elles
s'engagent à préserver la sécurité et le caractère confidentiel des informations.
PAR CES MOTIFS,
le Comité
1° retire la délibération RN n° 06/2016 à partir de ce jour ;
2° autorise pour une durée indéterminée le Service public fédéral ICT, pour la réalisation de la finalité
mentionnée au point A et aux conditions exposées dans la présente délibération à :
•
accéder en permanence aux informations du Registre national mentionnées à l'article 3,
premier alinéa, 1° à 3° et 5° de la LRN ;
•
utiliser le numéro de Registre national ;
3° refuse ce qui est demandé en sus ;
Délibération RN 83/2016 - 14/14
4° stipule que lors de toute modification ultérieure de l’organisation de la sécurité de l’information
pouvant avoir un impact sur les réponses données au questionnaire sécurité fourni au Comité
(désignation du conseiller en sécurité de l'information et réponses aux questions relatives à
l’organisation de la sécurité), l'instance habilitée adressera au Comité un nouveau questionnaire relatif
à l'état de la sécurité de l'information complété conformément à la vérité. Le Comité en accusera
réception et se réserve le droit de réagir ultérieurement, s'il y a lieu ;
5° stipule que lorsqu'il enverra à l'instance habilitée un questionnaire relatif à l'état de la sécurité de
l'information, celle-ci devra compléter ce questionnaire conformément à la vérité et le renvoyer au
Comité. Le Comité en accusera réception et se réserve le droit de réagir ultérieurement, s’il y a lieu.
L'Administrateur f.f.,
La Présidente,
(sé) An Machtens
(sé) Mireille Salmon