Pourquoi le dossier de preuves est urgent
La directive NIS2 est entrée en vigueur en janvier 2023, et le délai de transposition par les États membres était fixé au 17 octobre 2024. Les entités notifiées après cette date ont généralement bénéficié d'un délai de 18 mois pour se mettre en conformité. Les premières actions d'exécution sont engagées dans plusieurs États membres, et les autorités compétentes formulent désormais des demandes formelles de documentation.
Un audit NIS2 ne vérifie pas seulement que des mesures techniques sont en place : il exige des preuves datées, traçables et opposables. Un système correctement configuré mais non documenté ne passe pas un audit — un rapport d'incident sans horodatage fiable non plus. La constitution du dossier de preuves est donc une tâche distincte de la mise en conformité technique elle-même, et elle implique votre hébergeur autant que vos propres équipes.
Ce que couvre cet article
- Périmètre de l'hébergeur — ce qu'il est responsable de prouver et ce qu'il ne peut pas certifier à votre place
- Logs d'accès et de sécurité — quels journaux demander, sous quelle forme et pour quelle durée de rétention
- Patch management — rapports de vulnérabilités et de correctifs applicables à l'infrastructure sous-jacente
- SLA sécurité — les clauses contractuelles qui ont une valeur probante lors d'un audit
- Plan de continuité d'activité (PCA) — ce que l'hébergeur documente et ce que vous devez produire vous-même
- Rapport d'incident — le calendrier de notification NIS2 article 23 et la chaîne de preuves à reconstituer
- Ce que l'hébergeur ne peut pas certifier — la frontière claire entre infrastructure et politique de sécurité du client
La frontière entre ce que l'hébergeur prouve et ce qui vous incombe
L'objection la plus fréquente en audit : « notre hébergeur est certifié ISO 27001, cela couvre-t-il notre conformité NIS2 ? » La réponse est non, et la distinction est importante. L'hébergeur prouve la sécurité de son infrastructure — datacenter, hyperviseur, réseau, procédures internes de son personnel. Vous prouvez la sécurité de ce que vous déployez dessus : vos applications, vos données, vos accès, vos procédures.
L'article 21 de la directive NIS2 impose des mesures à l'entité soumise à la directive, pas à son fournisseur d'hébergement. L'hébergeur est un élément de votre chaîne d'approvisionnement (Art. 21.d) : vous devez documenter comment vous avez évalué ses pratiques de sécurité, quelles clauses contractuelles vous garantissent, et quels mécanismes de notification d'incident il vous offre. Ce que l'hébergeur ne peut jamais produire à votre place : votre cartographie des actifs, votre politique de sécurité formalisée, la formation de vos équipes, votre propre procédure de gestion d'incident, et la preuve que vos données applicatives sont chiffrées selon vos choix.
Répartition des responsabilités documentaires
Faites défiler le tableau
| Domaine | Ce que l'hébergeur documente | Ce que vous documentez |
|---|---|---|
| Infrastructure physique | Certification datacenter (ISO 27001, SOC 2), contrôle d'accès physique, alimentation redondante | Choix du datacenter et justification de la localisation géographique des données |
| Réseau et hyperviseur | Journaux de flux réseau, isolation des VMs, mise à jour de l'hyperviseur | Configuration du pare-feu applicatif, règles réseau côté OS invité |
| Patch management | Bulletins de correctifs appliqués sur l'infrastructure, CVE traitées | Mise à jour de l'OS, des dépendances applicatives, du runtime |
| Logs d'accès | Accès au panneau de gestion, actions d'administration sur l'infrastructure | Logs applicatifs, logs d'authentification SSH, accès à la base de données |
| Incidents de sécurité | Notification dans les délais NIS2 article 23, rapport d'incident sur l'infrastructure | Votre propre rapport d'incident, impact sur vos données et services |
| Continuité d'activité | SLA de disponibilité, plan de reprise infrastructure, sauvegardes des snapshots VM | RPO/RTO définis, test de restauration applicative, plan de crise documenté |
| Politique de sécurité | Politique de sécurité interne de l'hébergeur (fournie sur demande contractuelle) | Votre politique de sécurité SI, cartographie des actifs, formation des équipes |
Logs d'accès et de sécurité : ce qu'il faut demander
Les journaux sont le premier élément que demande un auditeur NIS2, car ils permettent de reconstituer le déroulement d'un incident (Art. 21.b) et de prouver que des contrôles d'accès sont effectivement appliqués. Sur un VPS, la chaîne de journaux implique deux couches : celle de l'hébergeur (accès au panneau de gestion, opérations sur l'infrastructure) et la vôtre (système d'exploitation invité, applications).
Du côté de l'hébergeur, les journaux à demander explicitement sont : les événements de connexion au panneau de gestion (avec adresse IP source et horodatage), les opérations de redimensionnement, de snapshot ou de réinstallation de VMs, et les alertes de sécurité réseau détectées au niveau de l'infrastructure. Ces journaux doivent être exportables dans un format structuré (JSON, CSV) et couvrir a minima les 90 derniers jours. Pour les journaux d'authentification et d'administration, une rétention de 12 mois est recommandée par la plupart des CSIRT nationaux.
Du côté de votre VPS, la configuration minimale à documenter comprend : la centralisation des logs auth.log (ou secure sur les distributions Red Hat) vers un stockage que le compte applicatif ne peut pas modifier, la rétention des logs Nginx/Apache avec rotation configurée pour conserver au moins 90 jours, et l'export vers une solution externe (syslog distant, Loki, Elasticsearch) pour préserver l'intégrité en cas de compromission du serveur.
Documents à demander à votre hébergeur concernant les logs
- Journal d'accès au panneau de gestion — export des connexions avec IP source, date/heure, action effectuée, sur 12 mois minimum
- Journal des opérations d'infrastructure — création/suppression/redimensionnement de VMs, snapshots, modifications de configuration réseau
- Politique de rétention documentée — durée officielle de conservation des journaux de l'hébergeur, format et procédure d'export
- Alertes de sécurité réseau — rapports d'anomalies détectées au niveau de l'infrastructure (scans, tentatives d'intrusion périmètre)
- Procédure d'accès aux logs en situation d'incident — canal, délai de réponse et format de livraison en cas de demande urgente d'un auditeur ou d'une autorité
Patch management : preuves côté hébergeur et côté client
L'article 21 NIS2 impose des mesures pour assurer la sécurité dans l'acquisition, le développement et la maintenance des systèmes. Pour un VPS, cela couvre deux périmètres distincts que l'auditeur examinera séparément.
Côté hébergeur, les éléments à demander sont : la politique de gestion des vulnérabilités appliquée à l'hyperviseur et à l'infrastructure réseau, les bulletins de sécurité publiés ou transmis aux clients pour les CVE critiques affectant l'infrastructure sous-jacente, et les délais de déploiement des correctifs critiques garantis contractuellement. Sur ServOrbit, la politique de patch management de l'infrastructure est documentée et communiquée lors des incidents affectant l'hyperviseur ; vous pouvez en demander une copie formalisée pour votre dossier d'audit.
Côté client, vous devez documenter : la fréquence des mises à jour de l'OS (hebdomadaire ou mensuelle selon votre politique), la gestion des dépendances applicatives (outil de scanning, registre des CVE traitées), et les tests réalisés avant déploiement d'un correctif en production. Un simple journal de mise à jour daté et signé — même dans un tableur — constitue une preuve valable si elle est maintenue de façon cohérente.
Constituer votre dossier de preuves NIS2 : étapes pratiques
Demander le dossier de conformité infrastructure à votre hébergeur
Formulez une demande écrite à votre hébergeur en précisant le cadre NIS2 et les éléments requis : certificat ISO 27001 ou SOC 2 en cours de validité, localisation des datacenters, politique de gestion des vulnérabilités, procédure de notification d'incident. Sur ServOrbit, ce dossier peut être demandé via le support en mentionnant votre démarche d'audit NIS2 — précisez que vous avez besoin d'un document formalisé et daté.
Auditer et exporter les journaux d'accès à votre VPS
Connectez-vous à votre panneau de gestion ServOrbit et exportez l'historique des connexions et des opérations. Sur le VPS lui-même, vérifiez la configuration de
logrotatepourauth.loget vos logs applicatifs : la directiverotatedoit permettre une rétention de 90 jours minimum. Configurez un export vers un stockage externe avecrsyslogou un agent Loki si ce n'est pas déjà en place — c'est la seule façon de prouver l'intégrité des logs en cas de compromission du serveur.Vérifier et documenter les clauses contractuelles à valeur probante
Relisez votre contrat d'hébergement en cherchant explicitement : le SLA de disponibilité avec pénalités mesurables, les obligations de notification en cas d'incident de sécurité affectant l'infrastructure (délai et canal), les responsabilités en matière de sauvegarde (qui fait quoi), la portabilité des données et les conditions d'accès aux logs lors d'une investigation. Si une clause est absente, demandez un avenant ou un document complémentaire — un SLA de disponibilité seul ne suffit pas pour NIS2.
Produire votre propre politique de sécurité documentée
L'hébergeur ne peut pas produire ce document à votre place. Il doit couvrir a minima : la cartographie des actifs critiques hébergés, les règles de gestion des accès (MFA obligatoire, clés SSH, politique de rotation des secrets), la politique de sauvegarde (fréquence, localisation, test de restauration), et les personnes habilitées à accéder à l'infrastructure. Un document d'une à deux pages, daté et approuvé par la direction, constitue une preuve valable.
Mettre en place et tester le plan de continuité d'activité
Le PCA NIS2 couvre deux niveaux : celui de l'hébergeur (disponibilité de l'infrastructure, procédure de basculement) et le vôtre (procédure de restauration applicative, contacts d'escalade, décision de bascule). Sur ServOrbit, documentez les snapshots automatisés disponibles, leur fréquence et leur rétention. Ajoutez-y votre propre procédure de restauration, testée et datée — un test de restauration non documenté n'existe pas aux yeux d'un auditeur.
Préparer la procédure de notification d'incident NIS2
L'article 23 de la directive impose : une alerte précoce à l'autorité nationale compétente dans les 24 heures suivant la détection d'un incident significatif, une notification formelle dans les 72 heures incluant l'évaluation initiale de l'impact et une indication de la cause probable, et un rapport final dans le mois suivant. Définissez par écrit : qui est responsable de la notification, quel est le seuil de significativité retenu, et quel canal est utilisé (plateforme de l'autorité nationale, email sécurisé). Votre hébergeur est responsable de vous notifier des incidents affectant son infrastructure dans les mêmes délais.
Configurer les sauvegardes avec preuve de test de restauration
Sur ServOrbit, les snapshots automatisés couvrent la couche VM. Pour la couche applicative, configurez une sauvegarde distincte exportée vers un stockage objet externe (S3 compatible). Documentez chaque test de restauration : date, version restaurée, durée, résultat. Un tableau dans un fichier versionné (git) constitue une trace valable. La fréquence minimale recommandée pour un test de restauration complet est trimestrielle.
Vérifier la chaîne d'approvisionnement (Art. 21.d)
Recensez tous les prestataires ayant accès à votre infrastructure : hébergeur, infogérance, développeurs externes, intégrateurs, fournisseurs de bibliothèques critiques. Pour chacun, documentez : le niveau d'accès accordé, les clauses de sécurité dans le contrat, et la procédure si ce prestataire subit lui-même un incident. Votre hébergeur doit figurer dans cet inventaire avec ses certifications et ses engagements contractuels.
Archiver et versionner l'ensemble du dossier
Un dossier de conformité NIS2 doit être dateable et opposable. Stockez tous les documents dans un espace d'accès contrôlé, versionné (un dépôt git privé convient), avec un historique des modifications. Chaque document doit porter une date, une version et l'identité de son approbateur. Planifiez une revue annuelle minimum, documentée elle aussi.
SLA sécurité : les clauses qui ont une valeur probante
Un SLA de disponibilité (disponibilité contractuelle) n'est pas un SLA de sécurité. Pour un audit NIS2, les clauses contractuelles à valeur probante sont différentes et plus précises. Voici ce qui distingue un contrat d'hébergement acceptable d'un contrat insuffisant au regard de la directive.
Les clauses essentielles pour NIS2 portent sur : le délai de notification des incidents de sécurité affectant l'infrastructure (doit être inférieur ou égal à 24 heures pour être compatible avec l'article 23), le type d'information transmise lors d'un incident (au minimum : nature de l'incident, systèmes affectés, mesures prises), la durée de conservation des journaux et la procédure d'accès en cas d'investigation, les conditions d'audit ou d'inspection par le client ou son mandataire, et les engagements en matière de continuité d'activité avec des métriques mesurables (RTO, RPO).
Sur ServOrbit, les conditions générales de service documentent les engagements de disponibilité et les obligations de notification. Pour les entités NIS2, nous recommandons de compléter cela par un échange écrit précisant les délais de notification d'incident et la procédure d'accès aux journaux — cet échange lui-même constitue une pièce du dossier de preuves.
Durcissement : ne vous contentez pas d'une certification ISO 27001 de votre hébergeur comme preuve unique. ISO 27001 couvre les processus internes de l'hébergeur, pas votre environnement spécifique. Demandez explicitement le périmètre de la certification (est-ce que votre datacenter est inclus ?) et son millésime. Complétez avec les bulletins de sécurité récents et les rapports d'incidents des 12 derniers mois si disponibles. Pour votre propre périmètre, un test d'intrusion annuel réalisé par un tiers et son rapport constituent la preuve la plus solide de la maturité de votre posture de sécurité — bien plus qu'une checklist auto-déclarative.
Rapport d'incident NIS2 : la chaîne de preuves à reconstituer
L'article 23 de la directive NIS2 est l'une des obligations les plus concrètes et les plus contraignantes : il impose une séquence de notification précise, et l'absence de preuves datées à chaque étape est elle-même une violation. Comprendre cette séquence avant qu'un incident ne survienne est indispensable.
La chronologie imposée est la suivante : dans les 24 heures suivant la détection d'un incident significatif, l'entité doit transmettre une alerte précoce à l'autorité nationale compétente (ANSSI en France, BSI en Allemagne, selon votre État membre). Cette alerte doit indiquer que l'incident est soupçonné d'être d'origine malveillante ou d'avoir un impact transfrontalier. Dans les 72 heures suivant la détection, une notification formelle doit être transmise avec : une évaluation initiale de la sévérité, les systèmes affectés, et l'indication de la cause probable. Dans le mois suivant la résolution de l'incident, un rapport final doit documenter l'ensemble du déroulement, les mesures correctives prises et les enseignements tirés.
Pour pouvoir produire ces documents, votre infrastructure doit fournir des preuves à chaque étape : l'horodatage précis de la détection (log avec timestamp serveur), la liste des systèmes affectés (inventaire à jour), la nature des données exposées (cartographie des actifs), et les actions prises (journal des opérations). Votre hébergeur doit vous fournir sa propre timeline si l'incident touche son infrastructure — cette obligation doit figurer dans votre contrat.
Conclusion et maillage
Constituer un dossier de preuves NIS2 n'est pas une démarche bureaucratique : c'est la traduction documentaire de pratiques de sécurité qui, si elles sont réellement en place, ne demandent qu'à être formalisées. La distinction fondamentale à retenir est celle entre ce que votre hébergeur prouve (son infrastructure, ses processus, ses certifications) et ce que vous devez produire vous-même (votre politique, vos actifs, vos procédures, vos tests).
Sur un VPS ServOrbit, les briques techniques sont disponibles : snapshots automatisés, journaux d'accès exportables, notification d'incident dans les délais contractuels, et infrastructure certifiée. Ce que vous devez ajouter, c'est la couche documentaire qui rend ces éléments opposables à un auditeur : demandes formalisées, clauses contractuelles vérifiées, procédures écrites et testées.
Pour aller plus loin : les obligations générales des hébergeurs et de leurs clients dans le cadre NIS2 sont détaillées dans [nis2-hebergement-obligations-clients-2026](/blog/nis2-hebergement-obligations-clients-2026). L'impact du Cyber Resilience Act sur les composants logiciels de votre infrastructure est abordé dans [cra-cyber-resilience-act-hebergement-2027](/blog/cra-cyber-resilience-act-hebergement-2027). Les obligations de localisation et de transfert de données dans le cadre de la CNDP sont couvertes dans [conformite-cndp-hebergement-hors-maroc](/blog/conformite-cndp-hebergement-hors-maroc).
