Concept de conservation et de suppression pour la documentation IT : appliquer des durées de conservation conformes aux exigences de conformité

Un concept de rétention et de suppression pour la documentation IT semble à première vue être de la « paperasserie ». Lors d’audits, d’incidents de sécurité ou de changements de personnel, il apparaît toutefois rapidement : sans durées de conservation définies, sans règles de suppression traçables et sans responsabilités claires, la documentation devient un risque. Une conservation trop longue augmente la surface d’attaque, le volume de données et les efforts d’eDiscovery ; une suppression trop précoce compromet la capacité de démonstration, la continuité opérationnelle et les obligations légales.

Ce texte décrit comment la direction IT, la conformité, la protection des données et la sécurité peuvent établir un concept de rétention et de suppression pour la documentation IT de manière praticable au quotidien : avec une logique de décision claire, de la gouvernance, une perspective d’audit, des éléments de modèles, des composants de mise en œuvre technique et des mécanismes de contrôle. L’accent porte sur les types de documentation réellement présents en entreprise : documents système et d’architecture, manuels d’exploitation, preuves de changements et d’approbation, concepts d’autorisations, journaux, runbooks, preuves fournisseurs ainsi que contenus de tickets et de bases de connaissances.

Pourquoi la documentation IT nécessite des règles de rétention spécifiques

La documentation IT n’est pas un ensemble de données homogène. Elle contient souvent des contenus mixtes : informations techniques (configurations, IPs, topologies), éléments sensibles pour la sécurité (matériel de clés, accès d’urgence), données à caractère personnel (noms dans les tickets, interlocuteurs, échanges d’e-mails) et parfois aussi des références contractuelles ou financières (réceptions, preuves de prestation). C’est précisément ce mélange qui rend la rétention difficile : il n’existe pas une seule durée de conservation applicable à tout.

Conflits typiques constatés en pratique sans concept :

• Audit vs. minimisation : la révision et l’ISMS (système de management de la sécurité de l’information) exigent des preuves ; la protection des données impose la minimisation des données et une conservation limitée au finalité.
• Base de connaissances vs. sécurité : l’exploitation souhaite des runbooks complets ; la sécurité refuse mots de passe permanents, jetons d’urgence ou plans d’attaque exploitables en clair.
• Historique des changements vs. charge de maintenance : la traçabilité exige un historique ; les équipes perdent du temps si les anciens documents ne sont pas correctement identifiés ou automatiquement retirés.

Un concept de rétention et de suppression ne résout pas ces conflits par « plus de règles », mais par des catégories décisionnelles et des cycles de vie automatisables — avec des exceptions définies (p. ex. Legal Hold) et des contrôles vérifiables.

Contexte réglementaire et normatif : ce qui motive réellement

Plusieurs types d’exigences s’appliquent à la documentation IT. Important : en général, elles imposent des obligations de traçabilité et des objectifs de protection, mais rarement un nombre concret « X années » pour l’ensemble des documents. Elles doivent donc être transposées dans un référentiel interne.

Protection des données (RGPD) : limitation du stockage et obligations de suppression

Le RGPD exige notamment une limitation de la conservation (données conservées aussi longtemps que nécessaire) et intégrité/confidentialité. Cela concerne la documentation IT dès lors qu’elle contient des données personnelles (p. ex. tickets d’incident, journaux contenant des identifiants utilisateur, listes de contacts). Conséquence pratique : vous avez besoin d’une classification des données, d’une finalité définie et de règles de suppression ou d’anonymisation applicables techniquement.

Obligations d’audit et de preuve: traçabilité, immutabilité, retrouvabilité

Indépendamment du secteur, les auditeurs internes/externe attendent des preuves pour les processus IT essentiels : validations, documentation des changements, concepts d’habilitation, tests de secours, preuves fournisseurs, suivi des risques et des mesures. « Révisable » signifie essentiellement : les documents sont retrouvables, complets, datés et protégés contre toute manipulation non détectée (p. ex. via gestion de versions, signatures/hashes ou stockage WORM — « write once, read many »).

ISMS/Information Security: besoins de protection et suppression contrôlée

Un SGSI (p. ex. selon la logique ISO 27001) exige des processus documentés, des rôles, un traitement des risques et des preuves, mais surtout : un traitement conforme au besoin de protection des informations. Pour la documentation, cela signifie : classifier, contrôler les accès, journaliser (audit-log) et assurer une élimination sûre (suppression, éventuellement suppression cryptographique). La suppression ne doit pas se résumer à « disparaître », elle doit être démontrable et répétable.

Définir le périmètre: quels artefacts relèvent de la documentation IT ?

Avant de discuter des délais, il faut définir l’étendue. Dans les projets, c’est l’un des pièges les plus fréquents : les équipes pensent aux pages Wiki, les auditeurs à tout ce qui atteste d’une décision ou d’une opération d’exploitation.

Un périmètre opérationnel pour un concept de rétention et de suppression comprend typiquement :

• Documents système et d’architecture : architecture cible/actuelle, descriptions d’interfaces (API), flux de données, plans réseau.
• Documentation d’exploitation : runbooks, manuels de secours, procédures de sauvegarde/RESTauration, règles de monitoring et d’alerte.
• Preuves de changement et de mise en production : demandes, évaluations des risques, validations, acceptations, décisions de rollback.
• Documents de sécurité et d’habilitation : concepts de rôles et droits, recertifications, standards de durcissement, dérogations autorisées.
• Système de ticketing et base de connaissances : incidents, problèmes, demandes de service, erreurs connues, analyses de cause racine.
• Preuves fournisseur et d’exploitation : SLAs, fenêtres de maintenance, preuves de sécurité, protocoles de communication.

Tout n’est pas traité de la même manière : les tickets contiennent souvent des données personnelles et doivent être limités dans le temps différemment des décisions d’architecture ou des concepts de secours.

Logique décisionnelle: de la catégorie de document à la durée de conservation

Plutôt que de négocier document par document, une matrice de rétention fonctionne mieux : catégorie de document → besoin de protection → finalité/preuve → durée de conservation → mode de suppression/archivage → rôle responsable → règle de Legal Hold.

Quatre questions qui déterminent chaque catégorie

1. Quelle obligation ou quelle finalité exige la conservation ? (p. ex. preuve des modifications, sécurité d’exploitation, questions contractuelles/ de responsabilité)
2. Quel est le niveau de protection requis ? (Confidentialité/Intégrité/Disponibilité ; particulièrement critique pour les accès administrateur, le matériel de clés, les informations sur les vulnérabilités)
3. À quelle vitesse le contenu devient-il obsolète ? (Les Runbooks peuvent devenir incorrects et dangereux après une migration de plateforme)
4. Comment détecte-t-on le « End of Life » ? (Système hors service, contrat terminé, ticket clos + X mois, changement supplanté)

Profils typiques de rétention pour la documentation IT (à titre de modèle)

Les profils suivants sont délibérément formulés comme une aide à la décision. Les délais concrets doivent être adaptés à votre règlement interne, votre secteur et vos contrats. L’essentiel est la logique sous-jacente : la pertinence pour la preuve et le risque déterminent la conservation, pas la commodité.

• Décisions d’architecture et fondements système : conservation au minimum pendant le cycle de vie du système, plus une période de transition définie, car elles étayent les migrations, l’analyse d’incidents et les questions de responsabilité. Archivage avec historique des versions, marquage clair « valable jusqu’à » et « remplacé par ».
• Runbooks opérationnels et processus d’urgence : conservation tant qu’ils sont valides ; les versions anciennes uniquement si elles sont nécessaires comme preuve (p. ex. pour l’audit d’exercices d’urgence). Sinon suppression contrôlée, car des instructions obsolètes peuvent causer des dommages réels en situation critique.
• Preuves de changements et d’approbations : conservation conforme aux systèmes de contrôle interne et aux cycles d’audit ; plusieurs années sont souvent requises pour que les auditeurs puissent évaluer l’efficacité des contrôles. L’inaltérabilité / l’intégrité est particulièrement importante ici.
• Tickets (incident/service) : différencier : incidents purement techniques sans lien avec des personnes vs. tickets contenant des données à caractère personnel. Pour ces derniers, définir des règles claires de suppression / anonymisation après atteinte de la finalité et l’expiration des besoins de garantie / de preuve. Traiter séparément les pièces jointes (logs, captures d’écran).
• Exceptions de sécurité et autorisations temporaires : courte durée de conservation pour les contenus opérationnels, mais preuve d’autorisation conservée plus longtemps. Des éléments tels que les mots de passe d’urgence ne doivent pas figurer dans la documentation permanente, mais dans des systèmes contrôlés prévus à cet effet (p. ex. coffre-fort de mots de passe) avec une politique de rétention dédiée.

Gouvernance : rôles, responsabilités et approbations

Sans gouvernance, un concept de suppression reste théorique. Il est essentiel que la rétention ne soit pas décidée par « l’IT » seule, mais gérée comme un contrôle partagé entre l’IT, la conformité/révision, la protection des données et la sécurité de l’information.

Modèle de rôles (adapté au RACI)

• Responsable de la catégorie de documents (métier/IT) : définit l’objectif, les exigences minimales de contenu et les critères de « End of Life ».
• Responsable de la sécurité de l’information : définit la classification, le modèle d’accès, les mesures de protection et les méthodes de suppression sécurisées.
• Protection des données (si données à caractère personnel) : vérifie la limitation de la finalité, la limitation de conservation, l’anonymisation / la pseudonymisation.
• Conformité / Révision : définit les exigences de preuve, la durée minimale de conservation, les pistes d’audit et la logique d’échantillonnage.
• Exploitation IT / équipes plateformes : mettent en œuvre les politiques techniques (stockage d’archives, étiquettes de conservation, sauvegardes, journalisation).
• Legal (en cas de Legal Hold) : pilote les exceptions, les périodes de blocage et l’autorisation de reprise des suppressions.

Gestion des changements pour les règles de rétention

Les politiques de rétention sont pertinentes pour le contrôle. Les modifications doivent être traitées comme des changements de configuration : demande documentée, justification, évaluation des risques, approbation et historique des versions. Cela réduit les constats d’audit tels que « la rétention a été modifiée de manière ad hoc ».

Mise en œuvre technique : des étiquettes à la suppression sécurisée

Un concept de rétention et de suppression échoue rarement par manque d’outils, mais plutôt par absence de métadonnées et de frontières systématiques cohérentes. La mise en œuvre doit donc être pragmatique : peu de mécanismes robustes qui fonctionnent dans tous les stockages pertinents.

Métadonnées comme facteur clé : pas d’automatisation sans classification

Au minimum, sont nécessaires :

• Catégorie de document (p. ex. « preuve de changement », « runbook », « architecture »)
• Propriétaire (rôle/équipe, pas seulement une personne)
• Classe de protection (p. ex. interne, confidentiel, strictement confidentiel)
• Statut de validité (brouillon, valide, remplacé, hors service)
• Étiquette de rétention (ID de politique) et date de départ (p. ex. « ticket fermé le … »)

Si votre documentation vit dans plusieurs systèmes (Wiki, DMS, système de gestion des tickets, Git, partages de fichiers), ces métadonnées doivent soit pouvoir être représentées de manière inter-systèmes, soit vous devez définir consciemment quels systèmes sont « System of Record » pour chaque catégorie.

Archive vs. Sauvegarde vs. dépôt actif : idées reçues fréquentes

Dans les audits, « nous avons des sauvegardes » ne remplace pas l’archivage. Une sauvegarde sert à la restauration, pas à la conservation ciblée à long terme. À l’inverse, un archive n’est pas un plan de reprise après sinistre. Ligne directrice pratique :

• Dépôt actif : documentation opérationnelle et à jour ; accès rapide, modifications autorisées.
• Archive : pour les preuves ; plutôt immuable, versionnée, avec journal d’audit ; recherche ciblée et export possible.
• Sauvegarde : copie à un instant donné ; contient aussi les données supprimées jusqu’à l’expiration de la rétention des sauvegardes.

Pour les concepts de suppression, il est particulièrement important de définir le traitement des sauvegardes : la suppression dans le dépôt actif ne signifie pas la suppression immédiate des sauvegardes. Cela doit être décrit de manière transparente dans le concept (« suppression effective en production immédiatement, éviction complète des sauvegardes après X jours/mois »).

Suppression sécurisée et « suppression cryptographique »

Dans les systèmes cloud et de stockage, la réécriture physique n’est souvent ni pertinente ni possible. On utilise donc fréquemment la suppression cryptographique : les données sont stockées chiffrées de telle sorte que la suppression de la clé rend les données pratiquement illisibles. Cela n’est fiable que si la gestion des clés, le contrôle d’accès et la traçabilité sont en ordre (p. ex. rôles séparés, cycle de vie des clés documenté, journalisation).

Exemple : logique de politique comme modèle copiable (sans liaison à un outil)

Si vous documentez la rétention sous forme de « politique sous forme de texte », vous évitez les silos d’outils. Le modèle suivant peut servir de point de départ pour un document de politique interne.

POLICY-ID: DOC-RET-CHG-001
Kategorie: preuves de changements et d'approbations
Zweck: traçabilité des modifications, vérifiabilité des contrôles internes
Schutzklasse: Confidentiel
Aufbewahrung: 6 ans à compter de la clôture du changement (Statut : fermé)
Ablage: stockage d'archive (non modifiable), lien de référence depuis le système de tickets/wiki
Löschmodus: automatisé après expiration, sauf en cas de blocage légal
Legal Hold: verrouillage par le service juridique/compliance, début/fin documentés
Nachweis: journal d'audit de l'archivage et de la suppression, rapport mensuel
Owner: Gestion des services informatiques
Freigabe Retention-Regel: Conformité + Sécurité de l'information

Exemple : règles de suppression et d’anonymisation pour les tickets (modèle copiable)

Les systèmes de ticketing sont pertinents pour les audits, mais contiennent également des données personnelles. Souvent, une combinaison est judicieuse : conserver les faits techniques, minimiser les contenus à caractère personnel.

POLICY-ID: DOC-RET-TCK-002
Kategorie: Incident- und Service-Tickets
Unterkategorie A: Tickets ohne personenbezogene Daten
  Aufbewahrung: 3 Jahre ab Schließung
  Löschmodus: automatisiert
Unterkategorie B: Tickets mit personenbezogenen Daten (z. B. Nutzeranfragen)
  Aufbewahrung: 12 Monate ab Schließung
  Maßnahme: Anonymisierung von Namen/E-Mail, Entfernen personenbezogener Anhänge
  Technische Kerndaten bleiben: Kategorie, System, Zeitstempel, Maßnahmen, RCA-Referenz
Unterkategorie C: sicherheitsrelevante Incidents (IR/Forensik)
  Aufbewahrung: nach IR- und Rechtsvorgaben; standardmäßig länger, strenge Zugriffskontrolle
Legal Hold: möglich in allen Unterkategorien
Owner: Service Desk / Incident Management
Freigabe: Datenschutz + Informationssicherheit + Compliance

Perspective d’audit : quelles preuves les auditeurs attendent

Lors des audits, il s’agit rarement de savoir si vos délais sont « bien choisis », mais de vérifier s’ils sont justifiés, mis en œuvre et contrôlés. Attentes typiques :

• Matrice de conservation documentée : catégories, durées, responsables, exceptions.
• Preuve de l’application technique : configuration système, étiquettes, workflows, permissions.
• Journaux d’audit : qui a créé/modifié/supprimé quoi ; dans les domaines sensibles, immuables.
• Contrôles par échantillonnage : des documents/tickets individuels sont vérifiés rétrospectivement (existence, intégrité, statut de suppression après expiration du délai).
• Processus de blocage légal : déclencheur clair, autorisations, fin du blocage, communication documentée.

Un point de contrôle interne utile est un examen de conservation trimestriel : non pas une réunion de comité, mais une procédure fondée sur des rapports (catégories principales, exceptions, arriérés de suppression, étiquettes manquantes, systèmes sans application).

Conséquences sur les coûts et l’exploitation : où la conservation affecte réellement coûts et risques

La conservation est souvent associée uniquement au stockage. Le levier le plus important réside cependant dans l’exploitation, la sécurité et les efforts d’audit.

Coûts directs

• Stockage et fenêtres de sauvegarde : davantage de données rallongent les temps de sauvegarde, augmentent les risques RTO/RPO (temps de reprise et perte de données maximale).
• Coûts de licences/SaaS : de nombreux systèmes tarifent en fonction du volume ou des utilisateurs ; les pièces jointes historiques et les doublons augmentent les coûts.
• eDiscovery/recherches : plus le volume de données est important, plus chaque recherche en cas de litige ou d’audit coûte cher.

Risques indirects

• Surface d’attaque : d’anciens schémas réseau, identifiants d’accès, analyses de vulnérabilités ou instructions de « Quick Fix » sont précieux pour un attaquant.
• Erreur d’exploitation : des runbooks obsolètes et des pages Confluence « mortes » entraînent des interventions erronées en situation de stress.
• Constats d’audit : l’absence de concepts de suppression et des responsabilités floues sont des remarques récurrentes.

Plan d’implémentation pragmatique en 6 étapes

La mise en œuvre réussit mieux de manière itérative. L’objectif n’est pas « parfait », mais contrôlable et évolutif.

1. Définir l’inventaire et les systèmes : Où se trouve la documentation IT (Wiki, DMS, Ticketing, Fileshare, Git, CMDB) ? Quelles catégories sont critiques ?
2. Définir la classification et les catégories : 8–15 Kategorien suffisent souvent pour commencer. Zu viele Kategorien verhindern Automatisierung.
3. Décider de la matrice de rétention : Fristen, Trigger, responsable, Legal Hold, Archiv-/Löschmodus.
4. Prioriser l’application technique : Commencez là où le volume et le risque sont élevés (Ticketing-Anhänge, anciens Runbooks, Sicherheitsausnahmen).
5. Établir contrôles et rapports : monatliche/vierteljährliche Reports, Kontrollen par échantillonnage, KPIs (Label-ABDEckung, Löschrückstand, Legal-Hold-Fälle).
6. Formation et transfert d’exploitation : consignes concises pour auteurs et Betreiber (« welches Label wann? »), plus klare Eskalation.

Checkliste: Retention- und Löschkonzept für IT-Dokumentation (auditfähig)

• Portée définie: types de Dokumente, Systeme, « System of Record » par catégorie
• Modèle de catégories et classes de protection décidés
• Matrice de rétention: Frist, Trigger, Archiv/Löschung, responsable, Freigaben, Legal Hold
• Standard de métadonnées: Pflichtfelder und Validierung
• Technische Durchsetzung in den Kernsystemen umgesetzt (Labels/Policies/Workflows)
• Backup-Retention und Löschwirkung transparent documentiert
• Audit-Logs und Integritätsmechanismen (Versionierung, Hash/Signatur oder WORM) geregelt
• Processus für Ausnahmen und Legal Hold etabliert
• Kontrollplan: Reports, Stichproben, Review-Takt, Verantwortlichkeiten
• Onboarding-/Autorenguides für neue Dokumente und Ticket-Anhänge

Häufige Fehlerbilder und wie Sie sie vermeiden

« Alles aufbewahren, dann sind wir sicher »

Das Gegenteil ist oft der Fall: Sie erhöhen Angriffsfläche und Audit-Aufwand. Sicherheit entsteht durch klare Nachweisketten und kontrollierte Reduktion, nicht durch unbegrenztes Sammeln.

« Löschung ist Sache des Tools »

Tools können nur umsetzen, was Sie als Kategorien, Metadaten und Trigger definieren. Ohne saubere Startpunkte (« ab wann läuft die Frist? ») bleibt Löschung zufällig.

« Backups lösen Retention »

Backups sind zeitpunktbezogen und schwer selektiv zu löschen. Ein gutes Konzept beschreibt deshalb explizit, wie Löschung und Backup-Retention zusammenwirken.

« Keine Zuständigkeit, weil es ‚nur Dokumentation‘ ist »

Gerade IT-Dokumentation enthält Betriebs- und Sicherheitswissen. Ohne Owner gibt es keine belastbare Entscheidung, wann etwas weg darf oder bleiben muss.

Fazit: Retention ist ein Steuerungsinstrument, kein Archivprojekt

Ein Retention- und Löschkonzept für IT-Dokumentation ist dann erfolgreich, wenn es drei Dinge gleichzeitig erreicht: Es hält Nachweise für Audit und Betrieb verfügbar, reduziert unnötige Datenbestände und senkt Sicherheitsrisiken durch kontrollierte Löschung. Der Schlüssel liegt in wenigen, klaren Kategorien, belastbaren Triggern, einer governancefähigen Retention-Matrix und technischer Durchsetzung inklusive Reporting.

Wenn Sie das Thema angehen, starten Sie nicht mit « Jahre festlegen », sondern mit Scope, Kategorien und Verantwortlichkeiten. Fristen ergeben sich dann aus Zweck, Nachweisbedarf und Schutzbedarf – und lassen sich im Betrieb tatsächlich einhalten.

Für dieses Thema sind auch Aufbewahrungsfristen It-Dokumentation und Löschkonzept Dokumentation wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.