kamrulkonok/evalllm2026-french-defense huggingface dataset:
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 5

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
3/47 
TABLE DES MATIÈRES 
 
Présentation _________________________________________________________________ 6 
 
Champ et modalités d'application ________________________________________________ 6 
 
Niveaux de préconisation _______________________________________________________ 7 
 
Gestion des dérogations aux règles de la directive ___________________________________ 7 
 
Documents applicables _________________________________________________________ 8 
 
Autres documents et sites de référence __________________________________________ 10 
 
Autorité d’emploi ____________________________________________________________ 10 
 
Autorité d’homologation ______________________________________________________ 11 
 
Désignation de l’autorité d’homologation ____________________________________ 11 
 
Transfert de responsabilités ______________________________________________ 11 
 
Centre expert de l’autorité d’homologation _______________________________________ 12 
 
Responsable SSI du SI _________________________________________________________ 12 
 
Commission d’homologation ___________________________________________________ 13 
 
Objectifs ____________________________________________________________________ 14 
 
Processus de maîtrise des risques _______________________________________________ 14 
 
Méthode d’analyse de risques __________________________________________________ 15 
 
Dossier d’homologation _______________________________________________________ 16 
 
Le périmètre d’homologation _____________________________________________ 16 
 
La stratégie d’homologation ______________________________________________ 17 
 
Les procédures d’exploitation de sécurité ___________________________________ 17 
 
La liste de risques résiduels ______________________________________________ 18 
 
Le plan d’amélioration continue de la sécurité ________________________________ 18 
 
Trois types de démarche _______________________________________________________ 18 
 
Démarche sommaire ___________________________________________________ 18 
 
Démarche simplifiée ____________________________________________________ 19 
 
Démarche standard ____________________________________________________ 19 
 
Détermination du choix de la démarche __________________________________________ 20 
 
Principe de l’héritage _________________________________________________________ 21 
 
Objectifs ____________________________________________________________________ 21 
 
La forme de la décision d’homologation __________________________________________ 22 
 
La durée de validité de la décision d’homologation _________________________________ 23
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 9

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
7/47 
responsables de conduite de projet (RCP), les différents acteurs des projets en mode agile et les 
opérateurs.  
La directive ne s’applique pas aux SI ne relevant pas du ministère des Armées (SI interministériel, 
OTAN, UE, etc.). Dans ce cas, il convient de se référer aux documents idoines. 
L’homologation de sécurité d'un SI est globale : elle inclut dans son périmètre tout ce qui peut 
impacter la sécurité numérique du système et des données. 
Le [GUIDE 7] précise les modalités définies dans cette directive et propose des modèles de livrables. 
Il est accessible via SynopTIC4. Son usage et sa large diffusion sont donc fortement recommandés. Les 
modèles proposés peuvent être déclinés, sans les alourdir, par les AH pour répondre à leurs besoins 
et à leurs spécificités tout en facilitant la démarche d’homologation.  
Cette directive est applicable à partir de sa publication. Cette version annule et remplace la précédente 
édition (version n°2 du 19 novembre 2019). 
 Niveaux de préconisation 
Les règles définies dans ce document ont différents niveaux de préconisation et sont conformes au 
[RGI] et à la [RFC 2119]5 : 
 
OBLIGATOIRE 
Ce niveau de préconisation signifie que la règle édictée indique une exigence 
absolue de la directive. 
RECOMMANDÉ  Ce niveau de préconisation signifie qu’il peut exister des raisons valables, 
dans des circonstances particulières, pour ignorer la règle édictée, mais les 
conséquences doivent être comprises et pesées soigneusement avant de 
choisir une voie différente. 
CONSEILLÉ 
Ce niveau de préconisation signifie que la règle édictée est une bonne 
pratique de SSI. Il n’est pas nécessaire d’instruire une dérogation lorsqu’elle 
n’est pas respectée. 
DÉCONSEILLÉ 
Ce niveau de préconisation signifie que la règle édictée indique une 
prohibition qu’il est toutefois possible, dans des circonstances particulières, 
de ne pas suivre, mais les conséquences doivent être comprises et le cas 
soigneusement pesé. 
INTERDIT 
Ce niveau de préconisation signifie que la règle édictée indique une 
prohibition absolue de la directive. 
 Gestion des dérogations aux règles de la directive 
Les dérogations à des règles de niveau OBLIGATOIRE ou INTERDIT sont du ressort de l’AQSSI. Le 
FSSI et la DGNUM en sont tenus informés. 
Les dérogations à des règles de niveau RECOMMANDÉ ou DÉCONSEILLÉ sont du ressort de l’AH. 
L’AQSSI en est tenue informée. 
Les dérogations octroyées sont à lister et à insérer dans le dossier d’homologation. 
 
 
                                               
4 https://synoptic.intradef.gouv.fr/securite-numerique/guide-ndeg7-portant-sur-lintegration-de-la-securite-
numerique-dans-le-cycle-de 
5 https ://www.ietf.org/rfc/rfc2119.txt – keys words for use in RFCs to indicate requirement levels.
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 10

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
8/47 
 
CADRE DOCUMENTAIRE 
 Documents applicables 
[Audit] 
Directive n°28/DEF/DGSIC du 23/10/2013 portant sur l’exécution des audits 
https://synoptic.intradef.gouv.fr/securite-des-systemes-dinformation/directive-
ndeg28defdgsic-du-17-octobre-2013-portant-sur (Intradef) 
[CLOUD 
État] 
Circulaire n°6282/SG du 5/07/2021 relative à la doctrine d’utilisation de l’informatique 
en nuage par l’État (« cloud au centre ») 
https://synoptic.intradef.gouv.fr/securite-numerique/cloud-au-centre-nouvelle-
doctrine-de-letat (Intradef) 
[CLOUD 
SaaS] 
Directive provisoire relative à l’accès à des services cloud en mode SaaS hébergés 
à l’extérieur du ministère, note n°485/ARM/DGNUM/DG/NP du 25/11/2019 
https://portail-dirisi.intradef.gouv.fr/images/Achats/20191125_NP_DGNUM-DG_458-
DP-services-Cloud-mode-SaaS-V4.pdf (Intradef) 
[DEFEND] 
Note n°D-16-008326/DEF/EMA/SCOPS/CYBER/DR du 6/09/2016 relative à la 
défendabilité des SI 
https://synoptic.intradef.gouv.fr/securite-des-systemes-dinformation/defendabilite-
des-si-du-minarm (Intradef) 
[DIR 39] 
Directive n°39/DEF/DGSIC/DR de 1/07/2016 relative à la sécurité des systèmes 
industriels (en cours de réactualisation) 
https://synoptic.intradef.gouv.fr/securite-des-systemes-dinformation/directive-
ndeg39defdgsicdr-du-01-juillet-2016-relative-la (Intradef) 
[DPID] 
Note n°215/DEF/DPID/NP du 29/07/2016, relative à la cartographie hiérarchisée des 
systèmes d’information du ministère 
https://synoptic.intradef.gouv.fr/securite-numerique/cartographie-hierarchisee-des-
si-dpid (Intradef) 
[GUIDE 7] 
Guide n°7 portant sur l’intégration de la sécurité numérique dans le cycle de vie d’un 
système d’information, note n°443/ARM/DGNUM/DG/NP du 19/11/2020 
https://synoptic.intradef.gouv.fr/securite-numerique/guide-ndeg7-portant-sur-
lintegration-de-la-securite-numerique-dans-le-cycle-de (Intradef) 
[GUIDE 
HYG] 
Guide d’hygiène informatique - ANSSI 
https://www.ssi.gouv.fr/uploads/2017/01/guide_hygiene_informatique_anssi.pdf 
(Internet) 
[GUIDE S2I] 
Maîtriser la SSI pour les systèmes industriels - ANSSI 
https://www.ssi.gouv.fr/uploads/IMG/pdf/Guide_securite_industrielle_Version_finale-
2.pdf (Internet) 
[GUIDE SSI] 
Ensemble des guides [GUIDE HYG] et [GUIDE S2I] 
[IGI 1300] 
Instruction générale interministérielle n°1300 sur la protection du secret de la défense 
nationale du 9/08/2021
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 11

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
9/47 
https://synoptic.intradef.gouv.fr/securite-numerique/igi-1300-protection-sur-le-secret-
de-la-defense-nationale (Intradef) 
[II 901] 
Instruction interministérielle n°901/SGDSN/ANSSI relative à la protection des 
systèmes d’information sensibles 
https://synoptic.intradef.gouv.fr/securite-des-systemes-dinformation/publication-de-
lii-901-sur-la-protection-du-sensible-et-du-dr (Intradef) 
[IM DAJ-
RGPD] 
Instruction ARM/SGA/DAJ/D2P du 31/01/2020 relative à la mise en œuvre du 
règlement européen sur la protection des données personnelles au ministère de la 
défense 
http://portail-sga.intradef.gouv.fr/sites/info-metier/affaires-juridiques/droit-prive-droit-
public/donnees-personnelles-cada-cnil/Documents/20200218_NP_SGA-
DAJ_Instruction%20RGPD%20du%2031%20janvier%202020.pdf (Intradef) 
[LID] 
Instruction ministérielle n°101000/ARM/CAB du 1/12/2018 relative à la politique de 
lutte informatique et défensive du ministère des Armées 
http://portail-
cicde.intradef.gouv.fr/images/documentation/DIA/20180905_DR_CICDE_DIA-
3.20A_OPS-CYBER-2018.pdf (Intradef) 
[MCS] 
Directive n°47 portant sur le maintien en condition de sécurité, note 
n°200/ARM/DGNUM/DG/DR du 4/06/2020 
https://synoptic.intradef.gouv.fr/securite-numerique/publication-de-la-directive-
ndeg47-portant-sur-le-maintien-en-condition-de (Intradef) 
[PSSIM] 
Instruction ministérielle n°7326/ARM/CAB du 25/06/2018 relative à la politique de 
sécurité des systèmes d’information du ministère des Armées 
https://synoptic.intradef.gouv.fr/sites/synoptic/files/im7326_edition_2_du_25_juin_20
18.pdf (Intradef) 
[PSSIM-T] 
Instruction ministérielle n°7362-2/ARM/CAB du 21/07/2021, édition 2, portant sur le 
volet technique de la politique de sécurité du système d’information du ministère des 
Armées 
https://synoptic.intradef.gouv.fr/securite-numerique/pssi-m-volet-technique-2nd-
edition (Intradef) 
[RGS] 
Référentiel Général de Sécurité, version 2.0 du 13/06/2014 
http://www.ssi.gouv.fr/rgs (Internet) 
[RGI] 
Référentiel Général d’Interopérabilité, version 2 du 20/04/2016 
https://synoptic.intradef.gouv.fr/architecture-technique-generale/referentiel-general-
dinteroperabilite-rgi-v2-approuve-par-arrete-du (Intradef) 
[SIIV] 
Arrêté du 22/03/2021 fixant les règles de sécurité et les modalités de déclaration des 
systèmes d’information d’importance vitale et des incidents de sécurité relatives au 
sous-secteur d’importance vitale « Activités militaires de l’État 
https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000043310173 (Internet) 
https://synoptic.intradef.gouv.fr/securite-numerique/les-systemes-dinformation-
dimportance-vitale-s2iv-activites-militaires-de-letat (Intradef)
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 12

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
10/47 
[Traces] 
Directive n°29/DEF/DGSIC du 12/11/2013 relative aux traces et leur gestion au sein 
du ministère de la Défense 
https://synoptic.intradef.gouv.fr/securite-des-systemes-dinformation/directive-
ndeg29defdgsic-du-12-novembre-2013-relatives-aux (Intradef) 
 Autres documents et sites de référence 
[EBIOS 
2010] 
Expression des Besoins et Identification des Objectifs de Sécurité - ANSSI 
http://www.ssi.gouv.fr/site_article173.html (Internet) 
[EBIOS RM] 
Expression des Besoins et Identification des Objectifs de Sécurité - Risk Manager - 
ANSSI 
https://www.ssi.gouv.fr/guide/la-methode-ebios-risk-manager-le-guide/ (Internet) 
[FICHE 2 
DCP] 
Fiche n°2 de la direction des affaires juridiques portant sur l’AIPD et les actes 
réglementaires portant création du traitement des données 
http://portail-sga.intradef.gouv.fr/sites/info-metier/affaires-juridiques/droit-prive-droit-
public/donnees-personnelles-cada-
cnil/Documents/20190808_Fiche%20n%202%20-
%20AIPD%20et%20Actes%20r%C3%A9glementaires%20vvalid%C3%A9eDAJ.pdf
#search=fiche%20n%202%20%2D%20AIPD (Intradef) 
[MAITRISK] 
Directive 
n°45/ARM/DGNUM/SDSNUM/DR 
relative 
à 
l’emploi 
de 
l’outil 
« MAITRISK » au ministère des Armées 
https://synoptic.intradef.gouv.fr/securite-numerique/directive-
ndeg45armdgnumsdsnumdr-relative-lemploi-de-loutil-maitrisk-au (Intradef) 
[Site ANSSI] 
Site de l’ANSSI   www.ssi.gouv.fr (Internet) 
[Site 
DGNUM] 
Site SynopTIC   synoptic.intradef.gouv.fr (Intradef) 
 
ORGANISATION 
 Autorité d’emploi 
L’AE veille : 
● à la prise en compte de ses besoins de sécurité dans la conception et l’exploitation de 
ses SI et dans le traitement de ses données ; 
● à la cohérence des mesures mises en place dans ses SI avec ses besoins métiers ou 
opérationnels et avec les risques en matière de sécurité numérique.  
Elle s’assure que : 
● tous les SI, qui relèvent de sa responsabilité, sont homologués ou font l’objet d’une 
démarche d’homologation ou de ré-homologation ; 
● les conditions de leur homologation et les restrictions d’emploi décidées par l’AH, si elles 
sont définies, sont respectées ;
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 14

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
12/47 
FSSI peut y participer. Les risques résiduels sont présentés au cours de la réunion. La réunion donne 
lieu à un procès-verbal qui mentionne notamment les remarques et restrictions de la partie prenante.  
Une décision formelle notifie les nouvelles responsabilités. Tant que la notification n’est pas publiée, la 
responsabilité de l’AH sortante est pleine et entière.  
Si les risques résiduels, les conditions de MCS et le niveau de sécurité du SI ne sont pas acceptables 
pour l’AH prenante, celle-ci mettra en œuvre une nouvelle démarche d’homologation. 
RO 4 :  il est OBLIGATOIRE de renouveler la décision d’homologation en cas de transfert de 
responsabilité d’AH. La mise en œuvre de ce renouvellement est laissée à l’appréciation de 
l’AH prenante.  
Le transfert de responsabilités est effectif à la publication de la décision d’homologation par la nouvelle 
AH.  
 Centre expert de l’autorité d’homologation 
L’AH s’appuie sur un centre d’experts en SSI, dit centre expert de l’AH (CEAH), qui suit les démarches 
d’homologation, vérifie le dossier d’homologation et prépare ses décisions. Il apporte son appui et son 
expertise auprès des responsables SSI (RSSI) des SI qui relèvent de son périmètre de responsabilités. 
RO 5 :  il est OBLIGATOIRE pour une AH de disposer d’au moins un spécialiste en sécurité du 
numérique formé à la démarche d’homologation. 
L’annexe 3 propose une liste de connaissances et de compétences qu’il convient de détenir pour mener 
des démarches d’homologation. 
 Responsable SSI du SI 
Le RSSI projet (RSSI-P) conduit la démarche d’homologation sous la responsabilité de l’AE et au profit 
du responsable de projet (RCP) ou de programme jusqu’à la première décision d’homologation, et tant 
que le SI est en phase de conception ou de réalisation.  
Le RSSI aval (RSSI-A) conduit les démarches d’homologation lorsque le SI n’est plus en phase de 
réalisation pour renouveler la décision d’homologation, et ceci sous la responsabilité de l’AE6.  
Les fonctions de RSSI-P et de RSSI-A peuvent ne pas être distinctes et être portées par un seul RSSI7. 
En absence de RSSI, un SI ne peut être homologué ou ré-homologué, et en cas de SI déjà 
homologué, la décision d’homologation peut être remise en cause. Il est de la responsabilité de 
l’AE de s’assurer de la continuité de la fonction de RSSI, tout au long du cycle de vie du SI. 
Le transfert de la fonction de RSSI, notamment de la fonction de RSSI-P à celle de RSSI-A en cas 
d’attributaires différents, requiert au minimum : 
● un transfert du dossier d’homologation du SI réactualisé, contenant notamment le plan 
d’amélioration continue de sécurité (PACS, cf. §4.4.5) ; 
                                               
6 Si le SI n’est pas homologué alors qu’il est déjà en phase d’utilisation, il instruit une démarche d’homologation 
pour régularisation. 
7 Dans la présente directive, le terme de RSSI désigne les deux fonctions, RSSI-P et RSSI-A, qui se distinguent 
selon la phase du cycle de vie du SI.
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 15

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
13/47 
● une désignation formelle du RSSI prenant et la date effective de sa prise de fonction. 
Le transfert de responsabilité nécessite un procès-verbal qui définit les pièces transmises, les 
remarques et les restrictions du RSSI prenant. Il est transmis à l’AE et à l’AH. 
 Commission d’homologation 
La commission d’homologation est une instance mise en place pour assister l’AH au moment de décider 
de l’homologation du SI. Les éventuelles négociations entre l’AH et l’AE ou avec les autres parties 
prenantes doivent être achevées avant la commission d’homologation. La commission peut se 
rassembler de manière dématérialisée et émettre un avis sans nécessairement réunir physiquement 
ses membres. 
RO 6 :  il est OBLIGATOIRE que l’AH constitue une commission d’homologation, adaptée au système 
à homologuer et en fixe les règles générales de fonctionnement.  
La commission se rassemble sur demande du RSSI pour proposer à l’AH une décision au travers d’un 
procès-verbal.  
La composition de cette commission dépend de l’enjeu et de la nature de l’homologation. Dans les cas 
les plus simples (démarche sommaire (cf. §4.5.1), simplifiée (cf. §4.5.2), homologation de déploiement 
(cf. §6.6) par exemple), la composition de la commission reste à la diligence de l’AH. Elle peut se limiter 
au CEAH et au RSSI en charge de la démarche d’homologation. Un certificat de conformité aux 
exigences SSI peut faire office de procès-verbal.  
Le FSSI et l’AQSSI sont des membres de droit des commissions d’homologation. Ils sont informés de 
leur tenue et, à leur demande, ils peuvent accéder à l’ensemble du dossier d’homologation. 
RO 7 :  il est OBLIGATOIRE que, dans le cadre d’une démarche d’homologation standard, la 
commission d’homologation soit au minimum composée des acteurs suivants : 
● 
l’AH ou son représentant ; 
● 
le responsable SSI (RSSI) en charge de la démarche d’homologation ; 
● 
le responsable de projet (RCP ou équivalent)/programme ou son représentant ; 
● 
l’AE ou son représentant. 
 
Dans le cas d’un renouvellement d’une homologation (cf. §5.6), la constitution de la commission 
d’homologation est à la diligence de l’AH. La commission doit au moins comprendre : 
● 
le CEAH ; 
● 
le RSSI en charge de la démarche de renouvellement de l’homologation ; 
● 
le RSSI (ou RSSI-A) du SI (s’il est différent du RSSI en charge de la démarche 
d’homologation) ; 
● 
le responsable du MCS (s’il est différent du RSSI). 
Dans le cadre d’une régularisation d’une homologation d’un SI déjà en phase d’utilisation, la commission 
comprend au moins : 
● 
l’AH ou son représentant ; 
● 
le RSSI en charge de la démarche d’homologation ; 
● 
le RSSI-A du SI (s’il est différent du RSSI en charge de la démarche d’homologation) ; 
● 
le représentant de l’opérateur ;
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 16

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
14/47 
● 
l’AE ou son représentant. 
 
DÉMARCHE D’HOMOLOGATION 
 Objectifs  
La démarche d’homologation a pour objectif : 
● 
d’une part : 
o d’identifier, d’évaluer et de hiérarchiser les risques résiduels portant sur le SI dans un 
périmètre bien défini selon les principes de gestion de risques ; 
o de réduire la vraisemblance des risques, en particulier la surface d’attaque, ou le cas 
échéant leurs impacts, par l’application de mesures de sécurité ; 
o de mettre en place la capacité à réagir en cas d’incident ou de crise ; 
o de s’assurer de l’effectivité des règles relatives au [MCS] et aux [Traces] ; 
● d’autre part : 
o de justifier le bon déroulement de la démarche ; 
o de fournir à l’AH les justifications nécessaires pour prononcer sa décision. 
La démarche d’homologation doit amener à une décision d’homologation (cf. §5). 
 Processus de maîtrise des risques 
L’AH décide des modalités de la démarche et peut la faire évoluer en conduite. 
Toutefois, la démarche d’homologation doit être adaptée : 
● en termes de méthode, aux enjeux portés par le SI en matière de niveau de risque et 
de ressources tout au long de son cycle de vie ; 
● en termes de mesures de sécurité, pour éviter d’entraver le développement du SI par 
la « sur-sécurité » ; 
● en termes de documentation, pour ne pas multiplier les livrables fastidieux, inadaptés 
ou encore inefficaces. 
Il s’agit donc de prioriser les démarches d’homologation en fonction du niveau de criticité des SI et de 
leur exposition aux menaces afin d’éviter d’instruire des processus d’homologation complexes, longs et 
coûteux qui finalement seraient inadaptés aux enjeux de sécurité des SI.  
Toute démarche d’homologation repose sur un processus de maîtrise de risques qui se déroule en 
plusieurs étapes : 
● définition du périmètre d’homologation (cf. §4.4.1) ; 
● description de la démarche dans une stratégie d’homologation (cf. §4.4.2) ; 
● définition des objectifs de sécurité ; 
● identification, évaluation et hiérarchisation des risques portés sur le SI au moyen d’une 
analyse de risques ou de conformité à un référentiel préalablement défini (cf. RO 8 :) ; 
● traitement des risques hiérarchisés ; 
● réalisation et contrôle des mesures de sécurité destinées à atteindre les objectifs de 
sécurité ; 
● identification, évaluation et hiérarchisation des risques résiduels ; 
● constitution et vérification du dossier d’homologation (cf. §4.4) ; 
● décision de l’AH (cf. §5) sur avis de la commission d’homologation (cf. §3.5).
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 17

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
15/47 
 
Lors de la démarche d’homologation, le RSSI doit tenir compte au minimum : 
● des attendus métiers (AE) 
● du fondement juridique et réglementaire s’appliquant à la protection des données et des 
SI ; 
● des prérequis nécessaires à l’homologation (par exemple, la qualification de produits de 
sécurité) ; 
● de l’interconnexion avec d’autres systèmes ; 
● des moyens d’hébergement des informations ; 
● des solutions de chiffrement (logicielles et matérielles) ; 
● de la gestion des documentations, notamment de la cartographie afin de garantir la 
connaissance du système au cours de son cycle de vie ; 
● de la gestion et de la protection des supports amovibles ; 
● des accès à distance par des utilisateurs en mobilité ; 
● des conditions de MCS conformément au [MCS] ou à ses déclinaisons au sein des 
EMDS ; 
● des modalités de supervision de sécurité ; 
● des opérations de maintenance, d’exploitation ou de télégestion du système, notamment 
lorsqu’elles sont effectuées par des prestataires externes ; 
● des éléments mis en œuvre pour assurer le plan de continuité/reprise d’activité 
(PCA/PRA) ; 
● de la formation des utilisateurs et des administrateurs, y compris sur la sécurité ; 
● des contraintes et des impératifs, notamment calendaires ; 
● des modalités de retrait de service. 
Si le besoin de mise en supervision de sécurité par un SOC est avéré, le processus de supervision doit 
être pris en compte dans la démarche d’homologation et suffisamment tôt dans la réalisation du SI afin 
de prendre en compte les prérequis et d’intégrer cette mise sous supervision dans le plan de charge du 
SOC. 
RO 8 :  il est OBLIGATOIRE de renseigner les informations relatives à la démarche d’homologation 
dans l’outil de suivi du patrimoine applicatif du ministère des Armées8 et de les réactualiser au 
fur et à mesure de la démarche d’homologation (sous réserve du niveau de classification de 
ces informations). 
 Méthode d’analyse de risques 
La méthode d’analyse de risques à utiliser est EBIOS RM. D’autres méthodes peuvent être utilisées en 
complément sur autorisation de l’AH (cf. [PSSIM-T] ENV13). Dans ce cas, il est nécessaire de le 
préciser et de le justifier dans la stratégie d’homologation. Toutefois, de manière transitoire, en attendant 
que tous les responsables SSI et fournisseurs de SI s’approprient cette méthode, l’ancienne méthode 
EBIOS 2010 peut être utilisée. 
Le renouvellement de l’homologation d’un système dont l’analyse de risques a été réalisée, selon la 
méthode EBIOS 2010, peut utiliser la même méthode d’analyse de risques. 
                                               
8 SICLADE est l’outil de suivi du patrimoine applicatif du ministère des Armées.
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 19

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
17/47 
● les dispositifs d’échanges, d’interconnexion et d’interfaces avec d’autres SI ; 
● les références relatives au SI ayant un impact sur la sécurité numérique et la démarche 
d’homologation (CCTP, contrat MCO, contrat d’hébergement, etc.). 
En raison de son usage récurrent dans différents livrables et de ses possibles évolutions, le périmètre 
d’homologation peut faire l’objet d’un document de référence. Il est alors joint à la stratégie 
d’homologation ou à tout document le nécessitant. 
 
La stratégie d’homologation 
RO 12 : il est OBLIGATOIRE pour le RSSI d’établir une stratégie d’homologation puis de la faire 
approuver par l’AH.  
La stratégie d’homologation précise a minima les informations suivantes : 
● le périmètre d’homologation (ou référence du document définissant ce périmètre) ; 
● les acteurs de la démarche d’homologation ; 
● le référentiel réglementaire ; 
● le type de démarche d’homologation (cf. §4.5) ; 
● les analyses de risques à réaliser et les méthodes à employer ; 
● le parcours (séquence, cas d’usage traités) de l’homologation à instruire ; 
● les éléments de la stratégie de MCS du SI ; 
● les modalités de mise sous supervision de sécurité9 ;  
● les livrables à produire avec les responsabilités, les échéances et les approbateurs ; 
● les modalités de la commission d’homologation (composition, nature de la réunion) ; 
● les contraintes et les impératifs, notamment calendaires. 
 
Les procédures d’exploitation de sécurité 
RO 13 : il est OBLIGATOIRE pour le RSSI de rédiger des PES et de les faire approuver par l’AH, après 
accord de l’AE. 
Les PES définissent a minima : 
● les différentes responsabilités des acteurs en matière de SSI et d’exploitation ; 
● les mesures organisationnelles de sécurité spécifiques au SI, dont nécessairement : 
o la gestion des accès et des droits ; 
o l’organisation du MCS ; 
o la supervision de sécurité (stratégie de détection, politique de journalisation, etc.) ; 
o les modalités de sauvegarde et de restauration ; 
● les mesures dérogatoires à des exigences de sécurité ; 
● les mesures conservatoires, notamment à des fins pédagogiques ; 
● les limitations d’utilisation du SI ; 
● les modalités de retrait de service du SI en matière de sécurité numérique. 
                                               
9 Par un SOC, une surveillance périodique des journaux, etc.
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 20

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
18/47 
Les PES doivent : 
● être adaptées au public visé (RSSI, administrateurs, utilisateurs)10 ; 
● ne contenir que les informations strictement nécessaires aux destinataires. 
 
La liste de risques résiduels 
L’ensemble des risques portant sur le SI et subsistant toujours après l’implémentation des mesures de 
sécurité doit être présenté à l’AH avec les niveaux de gravité et de vraisemblance.  
Le SI est soumis à un ensemble d’exigences de sécurité de niveaux d’importance variés en raison de 
la nature de ses données, des activités qu’il porte ou des éléments qui le constituent. Ces exigences 
sont extraites d’un référentiel préalablement défini. Lorsque des exigences ne sont pas applicables pour 
des raisons justifiées, des mesures sont définies pour réduire les risques que cette non-conformité peut 
générer. La liste des risques résiduels prend aussi en compte les risques subsistant après la 
mise en place de ces mesures dérogatoires. 
RO 14 : il est OBLIGATOIRE pour l’AH de délivrer une décision d’homologation à partir d’une liste de 
risques résiduels après avoir autorisé les mesures dérogatoires relevant de son périmètre. 
 
Le plan d’amélioration continue de la sécurité 
Le plan d’amélioration continue de la sécurité (PACS) définit et suit dans le temps les mesures de 
sécurité à appliquer à un SI pour réduire les risques, traiter les non-conformités et les vulnérabilités du 
SI.  
Le PACS identifie le responsable de chaque mesure et les difficultés de mise en œuvre, évalue le coût 
nécessaire pour la réaliser, son échéance et son état de réalisation. Chaque mesure est associée à au 
moins un risque. 
Le PACS est initié et mis à jour par le RSSI dès la phase de développement du SI et tout au long du 
cycle de vie. 
 Trois types de démarche 
La présente directive définit trois types de démarche d’homologation : sommaire, simplifiée et standard. 
Les types de démarches d’homologation se différencient par : 
● la nature et la profondeur de l’analyse de risques (cf. ANNEXE 2) ; 
● la composition du dossier d’homologation (cf. ANNEXE 1) ; 
● la composition de la commission d’homologation. 
RO 15 : il est OBLIGATOIRE, pour homologuer un SI, d’appliquer l’une des trois démarches 
d’homologation identifiées : sommaire, simplifiée ou standard. 
 
Démarche sommaire 
La démarche sommaire repose sur une analyse de risques réalisée à partir d’un certificat d’usage et 
de conformité (CUC) fondé sur le [GUIDE SSI], éventuellement complété par la [PSSIM], les politiques 
de sécurité du SI qui l’héberge, voire de la [DIR 39] lorsqu’elle s’applique.  
Le [GUIDE 7] propose un modèle de CUC que les AH peuvent adapter. 
                                               
10 Des PES peuvent en annexe fournir des fiches réflexes par public visé.
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 22

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
20/47 
La cible de sécurité et le PDS permettent de vérifier le recouvrement de l’ensemble des objectifs de 
sécurité. La cible de sécurité peut être incluse dans le PDS pour former un seul livrable. 
Le SI fait l’objet d’un audit d’homologation [Audit]. Cet audit donne lieu à un rapport qui définit les 
vulnérabilités identifiées et les risques associés, puis à un plan d’actions. 
RO 21 : il est OBLIGATOIRE, dans toute démarche standard, de réaliser un audit d’homologation. Les 
résultats et les actions qui en découlent sont étudiés lors de la commission d’homologation. 
 Détermination du choix de la démarche  
Les SI sont répartis en quatre catégories en fonction de la sensibilité et de l’exposition à la menace 
[PSSIM-T] : 
● SI d’importance vitale (SIIV) ; 
● SI essentiel (SIE) ; 
● SI important (SII) ; 
● SI standard (SIS). 
Les SI industriels font aussi l’objet d’une classification (classes 1 à 3) dont le niveau détermine les 
mesures de sécurité à appliquer sur un périmètre bien défini ([DIR 39]). La catégorisation d’un système 
industriel peut se déduire de son niveau de classe.  
L’AH valide la catégorisation du SI sur proposition de l’autorité emploi au regard de l’importance du SI 
pour le fonctionnement de l’entité ou la réalisation de la mission, et de l’exposition aux menaces. L’AE 
est assistée par sa chaîne fonctionnelle SSI. 
Le choix du type de démarche d’homologation doit être en accord avec la catégorisation du SI. 
Typiquement, les correspondances suivantes peuvent être appliquées. 
 
Système d’information 
Système industriel 
(ou sous-système) 
Démarche standard 
S2IV 
SIE 
classe 3 
Démarche simplifiée 
SII 
classe 2 
Démarche sommaire 
SIS 
classe 1 
La complexité du SI et donc de maîtrise du SI peut aussi être un critère supplémentaire dans le choix 
de la démarche. 
La démarche sommaire peut correspondre à un SI d’architecture simple, dont l’exposition aux risques 
et la criticité sont faibles et dont les règles de sécurité à appliquer n’excèdent pas celles prévues par 
les [GUIDE SSI].  
La démarche simplifiée peut correspondre à un SI d’architecture maîtrisée et dont l’exposition aux 
risques ou la criticité est faible. Elle répond notamment au cas des SI s’appuyant sur un socle au travers 
des usages, ou pouvant faire l’objet d’exigences de sécurité non couvertes par le socle ou par les 
[GUIDE SSI] mais encadrées par des réglementations relatives aux informations et fonctions à protéger 
(personnelles, médicales, financières, systèmes industriels, etc.).  
La démarche standard s’applique aux autres SI, notamment à des SI dont l’exposition aux risques 
n’est pas maîtrisée au travers du socle ou dont les exigences de sécurité ne sont pas couvertes par 
des réglementations. Elle s’applique principalement à des SI du socle, des SI constituant leur propre
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 23

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
21/47 
socle (par exemple, les systèmes embarqués, les systèmes d’armes, etc.), des SI présentant un fort 
niveau de criticité (un ou plusieurs critères de risques (DICT11) au niveau maximum).  
Pour les systèmes non industriels, l’AH pourra s’appuyer sur le questionnaire d’évaluation initiale (QEI) 
proposé par le [GUIDE 7] pour orienter ses choix. Pour les systèmes industriels, une méthode et des 
outils sont proposés dans [DIR 39]. Toutefois, l’AH reste seule décisionnaire du choix de la 
démarche, hormis pour les SI auxquels la réglementation et la présente directive peuvent 
imposer une démarche standard (RGS, SIIV). 
 Principe de l’héritage12 
Dans le cadre des homologations, le principe d’héritage consiste à utiliser les résultats d’une analyse 
de risques déjà conduite sur un modèle. Celui-ci peut désigner un composant (physique, logiciel), un 
service, voire une architecture type. 
Un modèle est constitué : 
● d’une description permettant de l’identifier clairement ; 
● d’un niveau de sécurité défini comme l’ensemble des résultats de l’analyse de risques 
sous forme de critères de sécurité (DICT, etc.) et des risques résiduels ; 
● de prérequis sous forme de recueil d’exigences vérifiables. 
Tout modèle doit être validé par le CEAH.  
L’objet hérite d’un modèle quand il utilise les éléments constituant ce modèle pour identifier, évaluer et 
hiérarchiser les risques portant sur le SI.  
Les risques13 associés à l’objet qui hérite doivent alors être évalués à partir : 
● du niveau de sécurité du modèle hérité ; 
● de l’état de conformité du SI au prérequis. 
Les modèles hérités ainsi que l’évaluation des risques associés aux objets qui héritent sont insérés 
dans le dossier d’homologation. 
 
DÉCISION D’HOMOLOGATION 
 Objectifs 
La décision d’homologation est l’acte officiel par lequel l’AH atteste que : 
● les risques résiduels sont bien identifiés, évalués et acceptés ; 
● les ressources affectées à la démarche sont en adéquation avec les enjeux portés par 
le SI ; 
● le dossier d’homologation est satisfaisant et a fait l’objet d’une validation par le CEAH 
(cf. §4.4) ; 
● les mesures annoncées dans le dossier d’homologation sont effectives ou le seront au 
terme de la réalisation du PACS dont la complétude devra être vérifiée par le RSSI ; 
                                               
11 Disponibilité, Intégrité, Confidentialité, Traçabilité au minimum. 
12 Le principe d’héritage est implicitement utilisé pour les composants ou services certifiés ou labellisés. Le modèle 
est alors défini par le certificat et le rapport de certification. 
13 Dans le cadre de la méthode EBIOS RM, le composant ou le service du SI qui hérite est alors considéré 
comme une partie prenante du SI dont le niveau de confiance ou de menace est évalué à partir des besoins 
atteints par le modèle, des résultats de l’analyse de risques et de l’état de conformité du SI aux prérequis.
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 25

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
23/47 
Une décision d’homologation conditionnelle ou restrictive doit préciser les critères ou les 
actions nécessaires pour procéder à une homologation ferme. Les actions à réaliser complètent le 
PACS du SI. Il sera inséré dans le dossier d’homologation et mis à jour tout le long du cycle de vie du 
SI. 
RO 24 : il est OBLIGATOIRE d’insérer dans la décision d’homologation le niveau de protection 
maximal des données pouvant être traitées par le SI et leurs éventuelles mentions de 
manipulation ou de diffusion. 
Un refus d’homologation engage directement la responsabilité de l’AE et éventuellement celle 
des opérateurs. L’AH les informe des risques encourus et de leurs responsabilités. 
 La durée de validité de la décision d’homologation 
RO 25 : il est OBLIGATOIRE d’assortir la décision d’homologation d’une durée de validité et de fixer 
les conditions de validité.  
La durée de validité d’une décision d’homologation est laissée à l’appréciation de l’AH. Toutefois, elle 
ne doit pas dépasser : 
● 2 ans pour les systèmes traitant des informations au moins de niveau de classification 
TRÈS SECRET ; 
● 3 ans pour les systèmes traitant des informations de niveau de classification SECRET ; 
● 5 ans pour des systèmes traitant des informations sensibles, y compris celles portant la 
mention DIFFUSION RESTREINTE ; 
● 7 ans pour les autres systèmes. 
Dans le cas de systèmes industriels traitant des informations non classifiées, la durée de validité de 
l’homologation doit être inférieure ou égale à : 
● 3 ans pour les SI de classe 3 ; 
● 5 ans pour les SI de classe 2 ; 
● 7 ans pour les SI de classe 1.  
Au-delà de sa date de validité et jusqu’au renouvellement de la décision d’homologation, l’utilisation du 
SI doit être suspendue. 
 Suspension d’une homologation 
RO 26 : il est OBLIGATOIRE de remettre en cause une décision d’homologation quand : 
● 
les conditions de sa validité ne sont plus respectées ; 
● 
les conditions de configuration ou d'exploitation du SI ont été modifiées de manière 
significative ; 
● 
le SI ne correspond plus au périmètre d’homologation (ajout de fonctionnalités, 
d’applications, d’interconnexions non prévues) ; 
● 
des vulnérabilités ont été détectées et peuvent remettre en cause le niveau de sécurité 
du SI de manière inacceptable pour l’AH ; 
● 
les menaces sur le SI ont significativement évolué ; 
● 
des problèmes d’application des mesures de sécurité ont été identifiés, notamment lors 
d’un contrôle ou d’un audit de sécurité ; 
● 
le MCS du SI n’est pas applicable ou suffisamment appliqué, ou a été défaillant ;
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 26

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
24/47 
● 
le système a fait l'objet d'un incident de sécurité significatif mettant en doute le niveau de 
sécurité attendu. 
Le RSSI ou l’AE peut proposer à l’AH, via son centre expert, une suspension d’une décision 
d’homologation. Sur l’avis de son centre expert, l’AH peut réunir la commission d’homologation pour 
statuer sur la décision d’homologation.  
Après suspension d’une décision, une démarche d’homologation peut être reprise ou poursuivie, 
totalement ou de manière partielle, après avis de la commission d’homologation. 
 Abrogation d’une homologation  
Une homologation est abrogée dès que le SI est retiré du service. Cette abrogation n’appelle pas de 
formalisme particulier mais doit être notifiée dans l’outil de suivi du patrimoine applicatif du ministère 
des Armées. L’AH est chargée de veiller à cette notification. 
Le RSSI informe l’AH de l’abrogation de l’homologation. 
 Renouvellement des homologations  
La démarche d’homologation pour renouveler une décision d’homologation est réalisée par : 
● le RSSI-A si le SI est uniquement en phase d’utilisation ; 
● le RSSI-P lorsque le SI est encore en phase de réalisation. 
Selon l’importance des évolutions et de la criticité du SI, et sur proposition de son centre expert, l’AH 
peut renouveler la décision d’homologation sur simple présentation du dossier d’homologation 
réactualisé ou à partir de l’avis d’une nouvelle commission d’homologation.  
Si le SI n’a pas connu de changements significatifs ou d’incidents majeurs ayant remis en cause 
ses besoins de sécurité, il n’est pas nécessaire de conduire à nouveau une démarche 
d’homologation complète. 
 
RO 27 : il est OBLIGATOIRE qu’un renouvellement d’homologation comporte a minima : 
● 
une revue des informations figurant dans le dossier d’homologation ; 
● 
une revue des informations d’enrôlement dans l’outil de suivi du patrimoine applicatif du 
ministère des Armées ; 
● 
une vérification des hypothèses de l’analyse de risques ; 
● 
une vérification de la pertinence des exigences de sécurité appliquées sur le SI ; 
● 
une revue du PACS ; 
● 
un bilan des contrôles et audits réalisés sur le SI ; 
● 
un bilan de l’activité liée au MCS pour évaluer sa performance et identifier les 
événements marquants.  
 
Le renouvellement d’homologation peut donner lieu à un contrôle, à un audit de conformité ou 
d’homologation. 
La décision de renouvellement d’homologation est identique à celle d’une homologation et se présente 
de la même manière (cf. §5.2). Elle précise la référence de la précédente homologation. 
 
CAS D’USAGE 
 Système d’information d’importance vitale
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 27

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
25/47 
 
Démarche d’homologation d’un SIIV 
RO 28 : il est OBLIGATOIRE de mener une démarche d’homologation de type standard pour 
homologuer un SI déclaré d’importance vitale. Toute dérogation à cette règle nécessite 
l’autorisation formelle du FSSI. 
L’AH du SI est l’opérateur d’importance vitale (OIV), sauf cas particulier précisé dans la règlementation 
interministérielle ou ministérielle (cf. par exemple §6.11). S’il n’est pas l’AH du SI, il est membre de droit 
de la commission d’homologation. L’opérateur est identifié dans la stratégie d’homologation. 
Le périmètre d’homologation définit les activités remises en cause en cas de dysfonctionnement ou 
d’atteinte à la sécurité numérique du SI ainsi que les fonctionnalités qui les portent. 
Les exigences de sécurité à appliquer, c’est-à-dire le socle de sécurité, contiennent nécessairement les 
règles définies par [SIIV]. Toute non-conformité à ces règles est dûment justifiée dans le dossier 
d’homologation.  
La démarche d’homologation comprend nécessairement un audit d’homologation dont les résultats et 
les actions qui en découlent sont étudiées lors de la commission d’homologation. 
Des indicateurs de sécurité prévus par [SIIV] sont élaborés au cours de la démarche d’homologation et 
présentés à l’AH. Ils doivent permettre d’évaluer le niveau de sécurité du SI dont : 
● le MCS du SI ; 
● l’avancement de la démarche d’homologation ou de son renouvellement ; 
● l’avancement du PACS mis en place.  
Au-delà des documents correspondant à une démarche standard (cf. ANNEXE 1), le dossier 
d’homologation contient en outre : 
● le formulaire de déclaration en SIIV ainsi que les pièces le justifiant, dont l’analyse 
d’impacts ; 
● la liste des indicateurs de sécurité et les modalités pour les déterminer. 
 
Décision d’homologation d’un SIIV 
En plus des éléments classiques à prendre en compte (cf. §5.1) pour statuer sur l’homologation du SI, 
l’AH doit aussi prendre en considération : 
● la gestion des incidents ; 
● la gestion de crise en cas d’attaques informatiques majeures ; 
● les indicateurs de sécurité ; 
● les rapports de sécurité prévus par [SIIV]. 
La durée de validité de l’homologation d’un SIIV non classifié est au maximum de 5 ans. En cas de SIIV 
classifié, elle dépend de son niveau de classification (cf. §5.3). 
La décision et le dossier d’homologation sont à la disposition de l’agence nationale de la sécurité des 
systèmes d’information (ANSSI). 
Il est rappelé que la décision d’homologation et le dossier d’homologation sont « des documents 
confidentiels susceptibles de contenir des informations dont la révélation est réprimée par les 
dispositions de l’article 226-13 du code pénal. Il est, le cas échéant, couvert par le secret de la défense 
nationale. » [SIIV]  
La mention qu’un SI est SIIV est considérée a minima comme une information de niveau DIFFUSION 
RESTREINTE SPÉCIAL FRANCE.
20220607_np_dpid_dir27-homologation-si-du-minarm-ed3.pdf — page 29

Directive DPID n°27/ARM/DPID - Homologation des SI du ministère des Armées (DIR-HSI) – 3ème édition – 2022 
27/47 
La règle RO33 ne s’applique pas pour une homologation d’un dispositif d’interconnexion ou d’un 
segment d’interface (cf. §6.11.1). 
 Traitement de données à caractère personnel 
Le responsable de traitement (RT) a pour mission de déterminer les finalités et les moyens du 
traitement. Il assume la responsabilité juridique et supporte les sanctions en cas de non-respect des 
dispositions du RGPD.  
L’homologation d’un SI traitant des données à caractère personnel relevant du périmètre du RT assure 
à ce dernier que les risques sur la sécurité des données à caractère personnel et leur protection au sein 
de ce SI ont été examinés et traités sur le plan technique, conformément aux exigences réglementaires.  
Elle doit donc nécessairement prendre en compte les risques suivants portant sur les personnes 
concernées : 
● accès illégitimes à leurs données (confidentialité) ; 
● modification non désirée de leurs données (intégrité) ; 
● disparition de leurs données (disponibilité). 
RO 34 : il est OBLIGATOIRE de préciser dans la décision d’homologation que le SI traite des données 
à caractère personnel lorsque ce traitement donne lieu à un acte réglementaire16. 
Les traitements de données à caractère personnel qui font l’objet d’un acte réglementaire sont rappelés 
dans la [FICHE 2 DCP] publiée par la direction des affaires juridiques (DAJ). Ne sont pas soumis à la 
publication d’un acte réglementaire les traitements mis en œuvre aux fins de : 
● gestion des comptes et accès informatiques, de la téléphonie fixe et mobile, des SI ; 
● gestion des procédures d’achat (fichiers fournisseurs) et des fichiers clients ; 
● gestion des opérations de communication (gratuites) ; 
● gestion du courrier et des dossiers ; 
● gestion des biens. 
La décision d’homologation d’un SI traitant des données à caractère personnel doit être transmise au(x) 
responsable(s) de traitement concerné(s). 
Lors d’un traitement de données à caractère personnel relevant de son périmètre, le RT peut être amené 
à réaliser une analyse d’impact relative à la protection des données à caractère personnel (AIPD) sur 
les personnes concernées [IM DAJ-RGPD]. L’AIPD n’est pas un prérequis à toute décision 
d’homologation. 
S’il est estimé nécessaire ou s’il est obligatoire de réaliser une AIPD, le RSSI contribue à l’élaboration 
de son volet technique au profit du RT. L’AH peut être amenée à se prononcer sur l’efficacité et la 
pertinence des mesures techniques mises en œuvre. 
 Urgence opérationnelle 
Lorsque l’urgence opérationnelle le requiert et pour permettre une mise en exploitation provisoire, l’AH 
peut délivrer une autorisation provisoire d’emploi (APE) sans attendre l’homologation du SI, en 
tenant compte de l’avancement de la procédure d’homologation et des risques résiduels de sécurité 
[IGI 1300]. 
                                               
16 Acte réglementaire portant création du traitement (arrêté publié aux journaux officiels).