Gestion des risques et conformité¶

Le directeur technique est responsable des risques techniques et de la conformité — deux dimensions indissociables d'une gouvernance IT mature.

La responsabilité du DSI face aux risques¶

La gestion des risques n'est pas l'affaire exclusive de la direction des risques ou de la conformité. Le DSI est en première ligne parce que les risques les plus critiques pour la plupart des organisations sont aujourd'hui des risques technologiques : cyberattaques, fuite de données, indisponibilite des systèmes, non-conformité reglementaire.

Un incident cyber, une violation de données, ou une indisponibilite prolongee peut détruire la confiance des clients, générer des sanctions financieres, et engager la responsabilité personnelle du DSI. Ce n'est plus une question de best practices — c'est une question de survie de l'organisation et de protection personnelle.

La gestion des risques IT repose sur quatre piliers :

• Identifier les risques (ce qui peut mal tourner)
• Évaluer les risques (probabilite et impact)
• Traiter les risques (actions de réduction, transfert, acceptation)
• Surveiller les risques en continu (évolution du contexte, efficacité des traitements)

ISO 27001 : le SMSI organisationnel¶

ISO 27001 est le standard international pour les Systèmes de Management de la Sécurité de l'Information (SMSI). Contrairement a une idée reçue, ISO 27001 n'est pas un référentiel technique — c'est un référentiel organisationnel. Il définit comment une organisation doit gérer la sécurité de l'information de manière systematique et ameliorable.

Les éléments fondateurs du SMSI¶

Périmètre : le SMSI s'applique a un périmètre défini (toute l'organisation, un département, un service spécifique). Le périmètre doit être explicite dans la politique de sécurité.

Politique de sécurité : document de haut niveau qui exprime l'engagement de la direction et les orientations globales en matiere de sécurité. Elle est signee par la direction générale, pas par le DSI.

Analyse de risques : processus systematique d'identification et d'évaluation des risques sur les actifs du périmètre. Elle alimente la définition des contrôles a mettre en place.

Declaration d'applicabilite (SOA - Statement of Applicability) : document qui liste les 93 contrôles de l'Annexe A d'ISO 27001 (version 2022) et justifie pour chacun s'il est applicable, appliqué, et dans quel état d'avancement. La SOA est le document central de la certification ISO 27001.

Amélioration continue : le cycle PDCA (Plan-Do-Check-Act) est au cœur du SMSI. La certification n'est pas un objectif final — c'est un état maintenu par des audits annuels de surveillance et un renouvellement tous les 3 ans.

L'analyse de risques ISO 27001¶

L'analyse de risques ISO 27001 suit une méthodologie en 6 étapes :

1. Inventaire des actifs : identifier ce qui doit être protégé (données clients, systèmes critiques, code source, secrets d'affaires)
2. Identification des menaces : pour chaque actif, quelles menaces peuvent se materialiser (cyberattaque, erreur humaine, catastrophe naturelle, défaillance matérielle)
3. Identification des vulnérabilités : quelles faiblesses permettraient a une menace de se réaliser
4. Évaluation du risque brut : probabilite x impact avant mesures de sécurité
5. Choix et application des contrôles : mesures de sécurité pour réduire le risque
6. Évaluation du risque residuel : risque restant après application des contrôles

Les contrôles ISO 27001 : les 4 themes de la version 2022¶

Maintenir la certification : les pieges¶

• L'audit interne negligé : l'audit interne annuel n'est pas une formalite — c'est le principal outil de vérification que le SMSI fonctionne. Des organisations font l'audit interne 2 semaines avant l'audit externe en mode "rattrapage". C'est le signe d'un SMSI de papier.
• Les non-conformites sans suivi : chaque non-conformité identifiée (en audit interne ou externe) doit faire l'objet d'un plan d'action avec responsable et echeance. Les non-conformites ouvertes depuis plus d'un an sont un signal rouge pour les auditeurs.
• La revue de direction annuelle : ISO 27001 exige une revue formelle de direction qui examine l'état du SMSI, les indicateurs de sécurité, les incidents, les changements de contexte. Elle doit être documentee et ses décisions suivies.

RGPD : les responsabilités du DSI¶

Le Reglement Général sur la Protection des Données (RGPD) est en vigueur depuis mai 2018 dans l'Union Europeenne. Il s'applique à toute organisation traitant des données personnelles de personnes situees dans l'UE, quel que soit le lieu d'établissement de l'organisation.

Registre des traitements¶

Toute organisation de plus de 250 employes (et les plus petites si le traitement est régulier ou porte sur des données sensibles) doit tenir un registre des traitements. Ce registre documente pour chaque traitement :

• La finalite (pourquoi ces données sont-elles collectees ?)
• Les catégories de données traitees
• Les catégories de personnes concernees
• Les destinataires des données
• Les durées de conservation
• Les mesures de sécurité implementees
• Les transferts hors UE et leurs garanties

Le DSI est souvent responsable de la production et de la maintenance du registre, en coordination avec le DPO et les métiers.

DPIA : Analyse d'Impact relative à la Protection des Données¶

La DPIA (Data Protection Impact Assessment) est obligatoire pour tout traitement susceptible d'engendrer un risque élevé pour les droits et libertes des personnes. Les critères déclencheurs incluent : traitement à grande échelle de données sensibles, surveillance systematique, décisions automatisees ayant des effets significatifs.

Une DPIA comprend :

1. Description du traitement et de ses finalites
2. Évaluation de la nécessité et de la proportionnalite
3. Identification et évaluation des risques pour les personnes
4. Mesures de traitement des risques
5. Consultation du DPO et, si residuel élevé, de la CNIL

Privacy by Design¶

Le RGPD impose le principe de Privacy by Design : la protection des données doit être intégrée dans la conception des systèmes, pas ajoutee à posteriori.

En pratique pour le DSI :

• Minimisation : ne collecter que les données strictement nécessaires à la finalite
• Pseudonymisation : remplacer les identifiants directs par des identifiants techniques
• Chiffrement : protéger les données au repos et en transit
• Consentement : implémenter des mécanismes de recueil et de gestion du consentement (cookie consent, gestion des préférences)
• Droit à l'oubli : implémenter la capacité de supprimer ou d'anonymiser les données à la demande
• Portabilité : implémenter la capacité d'exporter les données dans un format standard

Le DPO : rôles et interfaces avec le DSI¶

Le Délégué à la Protection des Données (DPO) est obligatoire pour les organismes publics, les organisations dont l'activité principale est le traitement à grande échelle de données sensibles, et les organisations dont l'activité principale est la surveillance systematique à grande échelle.

L'interface DSI / DPO : le DPO n'est pas sous l'autorité du DSI. Il rapporte directement au plus haut niveau de la direction et doit pouvoir exercer son rôle en independance. L'interface DSI / DPO est de collaboration : le DPO apporte l'expertise juridique, le DSI apporte l'expertise technique. Les décisions de mise en conformité necessitent les deux.

Sanctions RGPD : l'échelle des risques¶

Les sanctions les plus fréquentes concernent : la sécurité insuffisante des données (violation de données non preventees), le non-respect du droit d'accès, le défaut de base legale pour le traitement, et les transferts illicites hors UE.

Analyse de risques manageriale¶

Au-delà des cadres normatifs (ISO 27001, RGPD), le DSI doit conduire une analyse de risques manageriale plus large, couvrant tous les risques IT susceptibles d'affecter l'organisation.

Identification des risques¶

Les risques IT se categorisent en plusieurs familles :

Risques de sécurité : cyberattaque, ransomware, fuite de données, compromission des accès.

Risques de disponibilité : panne d'infrastructure, défaillance d'un fournisseur cloud, incident sur un système critique.

Risques de projet : dépassement de budget, retard de livraison, non-atteinte des benefices attendus.

Risques de conformité : non-respect du RGPD, d'ISO 27001, de reglementations sectorielles (SOX, PCI-DSS, NIS2).

Risques de dépendance : single point of failure sur un fournisseur, obsolescence d'une technologie, perte de compétences clés.

Risques humains : départ de personnes clés, fraude interne, erreur humaine sur des opérations critiques.

Évaluation des risques : la matrice probabilite x impact¶

L'évaluation des risques combine deux dimensions :

• Probabilite (ou fréquence) : quelle est la vraisemblance que ce risque se materialise ? (sur une échelle 1-4 : rare, possible, probable, quasicertain)
• Impact : quelles seraient les conséquences si le risque se materalise ? (sur une échelle 1-4 : negligeable, modere, significatif, critique)

Score de risque = Probabilite x Impact (de 1 a 16)

Stratégies de traitement des risques¶

Pour chaque risque évalué, le DSI dispose de quatre stratégies :

Accepter : le risque est dans le seuil d'appete pour le risque de l'organisation. On le surveille mais on ne prend pas d'action supplémentaire. Documenter la décision et le responsable qui accepte.

Réduire : mettre en place des mesures qui reduisent la probabilite d'occurrence ou l'impact si le risque se materialise. C'est la stratégie la plus fréquente. Ex : implémenter MFA pour réduire le risque de compromission des accès.

Transferer : reporter le risque sur un tiers. Typiquement via l'assurance (cyber-assurance) ou via des clauses contractuelles avec les fournisseurs (SLA, garanties contractuelles, pénalités).

Éviter : cesser l'activité qui généré le risque. Ex : ne pas traiter une catégorie de données sensibles si la valeur ajoutee ne justifie pas le risque. C'est souvent une décision métier autant que IT.

Plans de traitement : de la décision à l'action¶

Chaque risque traite (réduit ou transfere) doit faire l'objet d'un plan de traitement documenté :

• Action(s) prévue(s)
• Responsable de l'action
• Echeance
• Critère de succès / risque residuel attendu
• Budget requis

Le registre de risques est le document qui consolide tous les risques, leur évaluation, leur stratégie de traitement, et l'état d'avancement des plans.

PCA / PRA : continuite et reprise d'activité¶

Le Plan de Continuite d'Activité (PCA) et le Plan de Reprise d'Activité (PRA) sont deux réponses différentes à la même question : comment l'organisation continue-t-elle a fonctionner après un sinistre majeur ?

BIA : Business Impact Analysis¶

La BIA est l'analyse qui précédé la rédaction du PCA/PRA. Elle identifié :

• Les processus métier critiques (ceux dont l'arrêt a un impact inacceptable sur l'organisation)
• Les systèmes IT qui les supportent
• Le MTPD (Maximum Tolerable Period of Disruption) : combien de temps l'organisation peut-elle survivre sans ce processus ?
• Le RTO (Recovery Time Objective) : en combien de temps doit-on restaurer le service ? Doit être inférieur au MTPD.
• Le RPO (Recovery Point Objective) : jusqu'à quelle date peut-on perdre des données ? (ex: RPO de 4h signifie que la perte maximale acceptable est 4h de données)

PCA vs PRA : deux stratégies complementaires¶

PCA (Plan de Continuite) : vise à maintenir l'activité pendant un sinistre, souvent en mode dégradé. L'objectif est zero interruption ou interruption minimale. Ex : basculement automatique sur un site secondaire en cas de panne du datacenter primaire.

PRA (Plan de Reprise) : vise à reprendre l'activité après un sinistre, après une periode d'interruption. L'objectif est de restaurer le service dans le RTO. Ex : restauration des sauvegardes sur une infrastructure alternative après une attaque ransomware.

Les deux plans peuvent coexister, avec des stratégies différentes selon la criticite des systèmes.

Architectures de continuite IT¶

Tests réguliers : l'imperatif¶

Un PCA non teste est un faux sentiment de sécurité. Les tests sont obligatoires (ISO 22301, plusieurs reglementations sectorielles) et indispensables pour trois raisons :

1. Valider le plan : vérifier que les procédures fonctionnent comme prévu
2. Identifier les lacunes : découvrir ce qui n'a pas été prévu avant que ca soit urgent
3. Former les équipes : les personnes doivent connaître leur rôle dans le plan — impossible sans exercice réel

Types de tests, du moins au plus complet :

• Test documentaire (table-top) : revue du plan en salle avec les parties prenantes. Pas de manipulation de systèmes. Identifie les lacunes de procédure.
• Test fonctionnel partiel : test d'une partie du plan (ex : test de la restauration des sauvegardes) sans bascule complète.
• Test de bascule complète : bascule réelle sur le site de secours pendant une fenêtre maintenance. Le test le plus informatif mais aussi le plus risque.

Audit IT¶

Les types d'audits¶

Préparer un audit¶

La préparation d'un audit ISO 27001, SOC2, ou regulatoire suit les mêmes principes :

3 mois avant :

• Réaliser un audit interne complet selon le périmètre de la certification
• Identifier et traiter les non-conformites critiques
• Vérifier que les preuves (logs, rapports, comptes-rendus) sont disponibles et complets pour la periode auditee

1 mois avant :

• Compiler les preuves documentaires par domaine
• Briefer les équipes sur le déroulement de l'audit et les questions types
• Vérifier que les points ouverts de l'audit précédent sont clos ou ont un plan d'action actif

Pendant l'audit :

• Être transparent : les auditeurs detectent les dissimulations et les penalisent
• Répondre précisément aux questions, ni plus ni moins
• Si une non-conformité est identifiée, proposer immédiatement un plan d'action

Après l'audit :

• Traiter les non-conformites dans les délais convenus
• Documenter les plans d'action dans le registre de suivi
• Planifier le prochain audit interne

Non-conformites : niveaux de gravite¶

Cadre reglementaire : tableau de synthèse¶

Cyber-assurance et responsabilité du DSI¶

La cyber-assurance¶

La cyber-assurance est une forme de transfert de risque qui couvre les conséquences financieres d'un incident cyber. Les garanties typiques incluent :

• Frais de gestion de crise : investigation forensique, communication de crise, notification des victimes
• Pertes d'exploitation : chiffre d'affaires perdu pendant l'indisponibilite
• Frais de restauration : reconstruction des systèmes et des données
• Responsabilité civile : indemnisation des tiers victimes (clients, partenaires)
• Rancon : prise en charge partielle ou totale du rancon en cas d'attaque ransomware (sous conditions)

Les exigences des assureurs sont de plus en plus strictes et alignees avec les bonnes pratiques de sécurité : MFA obligatoire, sauvegardes testées et isolées, patch management actif, EDR déployé. Un assureur peut refuser de couvrir ou appliquer des franchises élevées si ces mesures ne sont pas en place.

Responsabilité personnelle du DSI¶

La responsabilité personnelle du DSI peut être engagee dans plusieurs cas :

Responsabilité penale : en cas de violation grave et caracterisee des obligations de sécurité (RGPD, NIS2), si le DSI avait connaissance des risques et n'a pas pris les mesures nécessaires.

Responsabilité civile : si le DSI a commis une faute detachable de ses fonctions (décision manifestement contraire à l'intérêt de l'entreprise, fraude personnelle).

Protection : le DSI doit documenter ses décisions, s'assurer d'avoir alerte la direction sur les risques identifiés, et avoir obtenu les budgets nécessaires pour y répondre. Un DSI qui a formellement alerte sur un risque et s'est vu refuser le budget pour le traiter est dans une position très différente d'un DSI qui n'a rien signale.

Clauses contractuelles : protéger l'organisation¶

Les contrats avec les fournisseurs IT doivent inclure des clauses spécifiques pour tranferer ou partager les risques :

Clauses de sécurité : obligations du fournisseur en matiere de sécurité (certifications, tests d'intrusion annuels, notification d'incident sous 72h).

Clauses de disponibilité (SLA) : niveaux de service garantis avec pénalités financieres en cas de non-respect.

Clauses de portabilité et de réversibilité : garantie de pouvoir récupérer ses données et de changer de fournisseur sans friction excessive.

Clauses de sous-traitance : obligation du fournisseur d'informer et d'obtenir accord avant de sous-traiter a un tiers, avec transmission des obligations de sécurité.

Droit d'audit : capacité de l'organisation a auditer le fournisseur ou de mandater un tiers pour le faire.

Piloter les risques et la conformité : tableau de bord DSI¶

La gestion des risques et la conformité ne sont pas des activités ponctuelles — elles sont des processus continus qui s'améliorent avec la maturité de l'organisation. Un registre de risques tenu à jour, un SMSI vivant, et des plans de continuite testés régulièrement sont les fondations d'une organisation IT resiliente et responsable.