Traiter la conformité comme un problème d’ingénierie

1Introduction

Dans beaucoup d’organisations, la conformité est une urgence annuelle. Quelques semaines avant l’audit, les ingénieurs cessent de livrer pour réunir des captures d’écran, exporter des listes d’accès et mettre à jour des politiques que personne n’a lues depuis le dernier audit. Puis les contrôles dérivent à nouveau jusqu’à l’année suivante. Traiter la conformité comme un problème d’ingénierie la transforme en un processus continu, qui produit ses propres preuves et rend l’organisation réellement plus sûre, et pas seulement certifiée.

2Sachez à quoi vous vous engagez

• ISO/IEC 27001:2022 est une norme certifiable pour un système de management de la sécurité de l’information. Son annexe A énumère 93 contrôles répartis en quatre thèmes : organisationnels, humains, physiques et technologiques.
• SOC 2 est un rapport d’attestation fondé sur les Trust Services Criteria de l’AICPA. La sécurité est toujours incluse ; la disponibilité, l’intégrité du traitement, la confidentialité et la vie privée sont facultatives. Un rapport Type II couvre le fonctionnement des contrôles sur une période, généralement de trois à douze mois.
• PCI DSS v4.0 s’applique à quiconque stocke, traite ou transmet des données de cartes de paiement. Ses exigences à date différée sont devenues obligatoires le 31 mars 2025.
• NIS2 étend les obligations de cybersécurité de l’UE à bien plus de secteurs, engage personnellement la direction et fixe des délais de signalement des incidents : une alerte précoce sous 24 heures, une notification sous 72 heures et un rapport final sous un mois.
• DORA s’applique aux entités financières de l’UE depuis le 17 janvier 2025 et couvre la gestion des risques TIC, le signalement des incidents, les tests de résilience et la supervision des tiers TIC.
• Les règles régionales comptent autant que les règles internationales. Dans le Golfe, les Essential Cybersecurity Controls de la NCA et la loi sur la protection des données personnelles en Arabie saoudite, ainsi que le décret-loi fédéral n° 45 de 2021 sur la protection des données personnelles aux Émirats, s’appliquent souvent. Au Liban, la loi n° 81 de 2018 couvre les transactions électroniques et les données personnelles.

3Un seul ensemble de contrôles, plusieurs référentiels

Les référentiels se recoupent largement. Les mettre en œuvre séparément crée des doublons et des preuves contradictoires. Définissez plutôt un seul ensemble de contrôles internes dans vos propres mots, attribuez à chacun un responsable et reliez-le aux clauses qu’il satisfait.

4Les contrôles sous forme de code

De nombreux contrôles techniques peuvent s’exprimer en code et s’appliquer automatiquement. Les changements d’infrastructure as code sont vérifiés dans le pipeline, la configuration cloud est évaluée en continu avec des services comme AWS Config ou Azure Policy, et les politiques d’admission Kubernetes bloquent les charges non conformes avant leur exécution. Chaque contrôle réussi constitue une preuve, sans que personne ne prenne de capture d’écran.

package compliance.storage

deny contains msg if {
  some r in input.resource_changes
  r.type == "aws_s3_bucket_public_access_block"
  r.change.after.block_public_acls == false
  msg := sprintf("%s must block public ACLs (ISO A.8.12, SOC 2 CC6.1)", [r.address])
}

5Surveillance continue et preuves

• Collectez les preuves selon un calendrier : revues d’accès, instantanés de configuration, résultats de tests de sauvegarde et rapports d’analyse de vulnérabilités arrivent automatiquement dans un dépôt central, avec leur horodatage.
• Donnez à chaque responsable une vue en direct de ses contrôles et alertez-le lorsqu’un contrôle commence à échouer, plutôt que de le découvrir pendant l’audit.
• Traitez les échecs de contrôle comme des incidents de production, avec un ticket, un responsable et une échéance.
• Faites de la préparation à l’audit un état permanent. Si un auditeur arrivait demain, les preuves des douze derniers mois devraient déjà exister.

6Ce que vous ne pouvez pas automatiser

L’évaluation des risques, la revue de direction, le contrôle des fournisseurs et la sensibilisation à la sécurité exigent toujours des personnes et du jugement. Gardez des politiques assez courtes pour être lues et écrites selon votre façon réelle de travailler. Les auditeurs vérifient de plus en plus si la pratique correspond au document, et une belle politique décrivant un processus que personne ne suit est un écart annoncé.

7Pièges courants

• Viser le certificat plutôt que le risque. Réussir un audit et être difficile à compromettre sont liés, mais ce n’est pas la même chose.
• Choisir un périmètre trop large au départ. Commencez par les systèmes qui contiennent les données visées par le référentiel, puis élargissez.
• Acheter une plateforme GRC avant de définir les contrôles et les responsables. L’outil organise un programme ; il ne peut pas le créer.
• Les preuves par capture d’écran. C’est lent, facile à falsifier et cela ne prouve qu’une chose vraie à un instant donné.

8Conclusion

Lorsque les contrôles fonctionnent en continu et produisent leurs propres preuves, l’audit devient une revue de données que vous avez déjà. Le temps gagné retourne au travail de sécurité qui réduit réellement le risque.