🏛️ Storage Systems — Chapitres 44 & 45 : Gouvernance des données et conformité

Partie 14 — Gouvernance, conformité et souveraineté. Cette page regroupe deux chapitres denses : la gouvernance des données, puis la conformité réglementaire et sectorielle. On y traite classification, lifecycle, ownership, catalog, policies, lineage, qualité, rétention, legal hold, souveraineté, partage, RGPD, ISO 27001, SecNumCloud, HDS, PCI-DSS, finance et assurance, NIS2 / DORA, transferts internationaux, audit logging, due diligence fournisseur, records management et checklists d’exploitation.

Classification Lifecycle Data catalog RGPD ISO 27001 SecNumCloud / HDS / PCI-DSS

44.1

Classification

Public, interne, confidentiel, sensible : niveaux de données, étiquetage, règles de traitement, accès et stockage adapté.

ClassificationLabelsSensitivity

44.2

Data lifecycle

Création, usage, archivage, purge : cycle de vie, transitions de tiers, rétention, legal hold et suppression contrôlée.

LifecycleRetentionPurge

44.3

Data ownership

Responsables métiers, data owner, data steward, custodian IT, RACI, validation d’accès et arbitrage de rétention.

OwnershipRACISteward

44.4

Data catalog

Inventaire des données, sources, schémas, tags, qualité, lineage, propriétaires, criticité et emplacements.

CatalogInventoryLineage

44.5

Policies

Rétention, chiffrement, accès, sauvegarde, archive, souveraineté, partage tiers et destruction sécurisée.

PoliciesEncryptionAccess

44.6

Lineage et traçabilité

Tracer l’origine, les transformations, les copies, les exports, les modèles dérivés et les usages aval.

LineageTraceabilityAudit

44.7

Qualité des données

Complétude, fraîcheur, cohérence, unicité, validité, quality rules, exception handling et remediation.

QualityFreshnessConsistency

44.8

Rétention et destruction

Schedules de conservation, expiration, purge, destruction logique/physique, preuves et chaînes d’approbation.

RetentionDestructionEvidence

44.9

Legal hold et eDiscovery

Gel des suppressions, conservation probatoire, litige, audit, chain of custody et recherche d’éléments.

Legal holdeDiscoveryLitigation

44.10

Souveraineté

Localisation, résidence des données, extraterritorialité, cloud de confiance, chiffrement et contrôle des clés.

SovereigntyResidencyKeys

44.11

Partage et tiers

Data sharing interne/externe, contrats, minimisation, anonymisation, data processing agreement et contrôle d’usage.

SharingDPAAnonymization

44.12

Checklist gouvernance

GO/NO-GO : classification, owner, catalog, lineage, rétention, legal hold, purge, souveraineté et audit.

ChecklistGovernanceGO/NO-GO

45.1

RGPD

Données personnelles, bases légales, minimisation, droit à l’effacement, portabilité, sous-traitants et tenue des registres.

GDPRPrivacyErasure

45.2

ISO 27001

Sécurité de l’information : ISMS, politiques, gestion des risques, contrôles, preuves, audits et amélioration continue.

ISO 27001ISMSRisk

45.3

SecNumCloud

Cloud de confiance français : exigences ANSSI, contrôle opérationnel, localisation, sécurité et chaîne de sous-traitance.

SecNumCloudANSSITrusted cloud

45.4

HDS

Données de santé en France : hébergement, sécurité, traçabilité, disponibilité, sous-traitance et audit.

HDSHealthcareFrance

45.5

PCI-DSS

Données de paiement : segmentation, encryption, logging, key management, retention minimale et tests réguliers.

PCI-DSSPaymentSegmentation

45.6

Finance et assurance

Conservation, audit, traçabilité, intégrité, contrôles internes, archivage réglementaire et supervision.

FinanceInsuranceAudit

45.7

NIS2 / DORA

Résilience, gestion des risques, incidents, supply chain, continuité, preuves de contrôle et supervision.

NIS2DORAResilience

45.8

Transferts internationaux

Clauses contractuelles, adéquation, Schrems II, transfert hors UE, chiffrement et assessment pays tiers.

TransfersEUSCC

45.9

Journalisation et audit

Traçabilité des accès, modifications, export, suppression, administration, horodatage et rétention probante.

Audit logsTraceabilityEvidence

45.10

Due diligence fournisseur

Évaluer certifications, DPA, localisation, sous-traitants, audit rights, exit plan et sécurité des clés.

Vendor riskDue diligenceExit

45.11

Records management

Documents officiels, archivage, conservation longue durée, WORM, records schedules et destruction autorisée.

RecordsArchiveWORM

45.12

Checklist conformité

GO/NO-GO : RGPD, ISMS, cloud de confiance, HDS/PCI, audit logs, transfert UE, preuves et runbooks.

ChecklistComplianceGO/NO-GO

44.1 Classification

Définition opérationnelle

Public, interne, confidentiel, sensible : niveaux de données, étiquetage, règles de traitement, accès et stockage adapté.

Point clé : le stockage ne peut plus être décidé uniquement par la performance ou le coût. Gouvernance, conformité, localisation, preuves, rôles et durée de conservation déterminent aussi l’architecture.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.2 Data lifecycle

Définition opérationnelle

Création, usage, archivage, purge : cycle de vie, transitions de tiers, rétention, legal hold et suppression contrôlée.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.3 Data ownership

Définition opérationnelle

Responsables métiers, data owner, data steward, custodian IT, RACI, validation d’accès et arbitrage de rétention.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.4 Data catalog

Définition opérationnelle

Inventaire des données, sources, schémas, tags, qualité, lineage, propriétaires, criticité et emplacements.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.5 Policies

Définition opérationnelle

Rétention, chiffrement, accès, sauvegarde, archive, souveraineté, partage tiers et destruction sécurisée.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.6 Lineage et traçabilité

Définition opérationnelle

Tracer l’origine, les transformations, les copies, les exports, les modèles dérivés et les usages aval.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.7 Qualité des données

Définition opérationnelle

Complétude, fraîcheur, cohérence, unicité, validité, quality rules, exception handling et remediation.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.8 Rétention et destruction

Définition opérationnelle

Schedules de conservation, expiration, purge, destruction logique/physique, preuves et chaînes d’approbation.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.9 Legal hold et eDiscovery

Définition opérationnelle

Gel des suppressions, conservation probatoire, litige, audit, chain of custody et recherche d’éléments.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.10 Souveraineté

Définition opérationnelle

Localisation, résidence des données, extraterritorialité, cloud de confiance, chiffrement et contrôle des clés.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.11 Partage et tiers

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

44.12 Checklist gouvernance

Définition opérationnelle

GO/NO-GO : classification, owner, catalog, lineage, rétention, legal hold, purge, souveraineté et audit.

Cycle de contrôle

Create→Classify→Store→Use / Share→Archive→Purge

Gouvernance utile = classification + owner + policies + preuves + revues régulières.

Composants à piloter

Composant	Rôle / explication
Business role	Direction métier, data owner, data steward, security officer, legal, compliance, privacy officer.
Data artifact	Table, bucket, share, backup, snapshot, archive, export, dataset, catalog entry, policy document.
Core controls	Classification, least privilege, encryption, retention, legal hold, purge, audit trail, catalog.
Decision points	Where stored, who accesses, how long retained, where replicated, what is archived, how destroyed.
Evidence	Policies, registers, approvals, lineage, access logs, retention proof, deletion proof, provider attestations.
Failure modes	Unknown owner, shadow copies, no catalog, excessive retention, uncontrolled sharing, no deletion proof.

Cas d’usage

Mettre en place une classification unifiée des données
Construire un data catalog et un ownership clair
Définir des politiques de rétention et de purge
Traiter un besoin de legal hold ou d’eDiscovery
Préparer un audit de gouvernance ou un comité data
Organiser souveraineté et localisation des données

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Rend les décisions de stockage explicites et traçables
Réduit les risques de copies sauvages et de rétention illimitée
Facilite conformité, sécurité et arbitrage métier
Améliore compréhension des flux et du lineage
Prépare les audits et les plans de transformation

Risques / limites

Catalog sans owner réel ni processus d’update
Classification théorique non appliquée aux buckets/partages
Purge impossible car dépendances inconnues
Souveraineté mal comprise réduite au simple hébergement
Shadow IT et exports non tracés

Matrice de décision

Question	Décision à prendre
Quelle donnée ?	Public, interne, confidentielle, sensible, personnelle, santé, financière, source code, logs, modèles ou archives.
Qui décide ?	Le data owner valide classification, accès, rétention, partage, purge et priorités de remédiation.
Quel stockage ?	Bloc/fichier/objet/archive selon performance, coût, durée, sécurité, souveraineté et volume.
Quelle protection ?	Encryption, access control, logging, DLP, versioning, immutable backup, legal hold et proof of deletion.
Quelle preuve ?	Catalog entry, policy mapping, lineage, access review, retention schedule, purge log et audit report.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Governance control examples
# inventory and classification mapping
aws s3api list-buckets
aws s3api get-bucket-tagging --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage
gcloud storage buckets describe gs://my-bucket

# access and evidence
rclone ls remote:bucket
find /archives -type f | wc -l
du -sh /archives /exports /legal-hold
# validate policy, retention and deletion evidence in governance registers

NO-GO : NO-GO : données critiques sans owner, sans classification, sans durée de conservation, sans preuve de purge ni visibilité catalog/lineage.

45.1 RGPD

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.2 ISO 27001

Définition opérationnelle

Sécurité de l’information : ISMS, politiques, gestion des risques, contrôles, preuves, audits et amélioration continue.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.3 SecNumCloud

Définition opérationnelle

Cloud de confiance français : exigences ANSSI, contrôle opérationnel, localisation, sécurité et chaîne de sous-traitance.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.4 HDS

Définition opérationnelle

Données de santé en France : hébergement, sécurité, traçabilité, disponibilité, sous-traitance et audit.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.5 PCI-DSS

Définition opérationnelle

Données de paiement : segmentation, encryption, logging, key management, retention minimale et tests réguliers.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.6 Finance et assurance

Définition opérationnelle

Conservation, audit, traçabilité, intégrité, contrôles internes, archivage réglementaire et supervision.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.7 NIS2 / DORA

Définition opérationnelle

Résilience, gestion des risques, incidents, supply chain, continuité, preuves de contrôle et supervision.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.8 Transferts internationaux

Définition opérationnelle

Clauses contractuelles, adéquation, Schrems II, transfert hors UE, chiffrement et assessment pays tiers.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.9 Journalisation et audit

Définition opérationnelle

Traçabilité des accès, modifications, export, suppression, administration, horodatage et rétention probante.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.10 Due diligence fournisseur

Définition opérationnelle

Évaluer certifications, DPA, localisation, sous-traitants, audit rights, exit plan et sécurité des clés.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.11 Records management

Définition opérationnelle

Documents officiels, archivage, conservation longue durée, WORM, records schedules et destruction autorisée.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.

45.12 Checklist conformité

Définition opérationnelle

GO/NO-GO : RGPD, ISMS, cloud de confiance, HDS/PCI, audit logs, transfert UE, preuves et runbooks.

Cycle de contrôle

Requirement→Control→Evidence→Audit→Remediation→Review

Conformité crédible = exigences comprises + contrôles déployés + preuves disponibles + revues et remédiations.

Composants à piloter

Composant	Rôle / explication
Legal framework	GDPR, ISO 27001, SecNumCloud, HDS, PCI-DSS, sector rules, internal policy, contracts.
Scope objects	Buckets, NAS, SAN, backups, archives, cloud accounts, keys, logs, admin actions, exports and replicas.
Required controls	Encryption, access review, audit logs, retention, data minimization, incident response, vendor oversight.
Operational evidence	Registers, RoPA, ISMS docs, certifications, audit logs, test reports, restoration drills, risk assessments.
Third-party controls	DPA, SCC, subcontractor chain, audit rights, provider certifications, exit plan, key control.
Failure modes	Missing evidence, unclear processor roles, excessive retention, risky transfers, weak logging, no restore tests.

Cas d’usage

Préparer un audit RGPD ou ISO 27001
Choisir un fournisseur compatible SecNumCloud ou HDS
Structurer une politique PCI-DSS pour stockage paiement
Documenter transferts hors UE et mesures complémentaires
Renforcer audit trail et retention probante
Évaluer un provider cloud et ses sous-traitants

Conseil : rattacher chaque jeu de données critique à un owner, un niveau de classification, une durée de conservation, une localisation et un plan de destruction ou d’archivage.

Apports

Aligne stockage et obligations réglementaires
Réduit le risque juridique et réputationnel
Améliore qualité des preuves d’audit
Clarifie le rôle des fournisseurs et sous-traitants
Permet arbitrage entre sécurité, coût et conformité

Risques / limites

Se limiter à une certification marketing sans lire le scope
Ignorer la chaîne de sous-traitance et les transferts
Retenir trop longtemps des données personnelles
Pas de logs suffisants pour prouver conformité
Pas de test restore, failover ou incident process

Matrice de décision

Question	Décision à prendre
Quel référentiel ?	RGPD pour données personnelles, ISO 27001 pour ISMS, SecNumCloud/HDS/PCI selon secteur et type de données.
Quel périmètre ?	Prod, backups, snapshots, archives, DR site, SaaS tiers, supports amovibles et exports.
Quelle preuve ?	RoPA, DPA, SCC, policy, audit logs, access reviews, key rotation, restore test, certifications et exceptions.
Quel fournisseur ?	Évaluer certification, localisation, subcontractors, contractual clauses, audit rights et exit plan.
Quel risque résiduel ?	Transfert international, extraterritorialité, logs insuffisants, retention excessive, weak key control, orphan backups.

Runbook de vérification

Identifier la donnée, son owner, son usage, sa criticité et sa réglementation applicable.
Vérifier l’emplacement de stockage, la réplication, l’archive, les backups, les accès et les clés.
Contrôler l’existence d’une policy, d’un catalogue, d’un registre et d’une durée de conservation.
Collecter les preuves : logs, tags, revues d’accès, restoration tests, contrats, certifications, décisions d’exception.
Tester au moins un scénario : purge, legal hold, restauration, revue d’accès, transfert externe, extraction d’audit.
Documenter le risque résiduel, le plan de remédiation, la date de revue et le responsable d’action.

# Compliance verification examples
aws s3api get-bucket-public-access-block --bucket my-bucket
aws s3api get-bucket-versioning --bucket my-bucket
aws s3api get-bucket-encryption --bucket my-bucket
az storage account show --name mystorage --query encryption
gcloud storage buckets describe gs://my-bucket
grep -R "retention" /etc /opt/policies 2>/dev/null | head
find /audit-logs -type f | tail
# cross-check: provider certification scope, DPA, SCC, retention schedules, restore and access review evidence

NO-GO : NO-GO : données réglementées sur une plateforme sans preuves d’encryption, logs, contrats, localisation, rétention, ni processus de restauration et d’audit.