On veut certifier quoi, exactement ?
ISO/IEC 27001 porte sur la manière dont une organisation gère la sécurité de l’information. Le périmètre compte : certifier un service ou une entité ne couvre pas automatiquement toute la boîte. Et ce n’est pas ISO qui vient te certifier, mais un organisme de certification indépendant.
Avant de bloquer une date, il faut savoir pourquoi on le fait, ce qu’on met dedans et qui peut décider. Un client qui demande le certificat lance le sujet. Il ne fournit pas les gens, le temps et les preuves qui manquent derrière.
Prépare ce que tu peux montrer
Je commencerais par un périmètre clair, les systèmes et informations importants, des responsables identifiés, les principaux risques et ce qu’on fait pour les traiter. Ensuite, du concret : une revue des accès, un départ bien géré, une restauration testée, un fournisseur évalué, un incident suivi jusqu’au bout.
Prends une règle écrite et demande à quelqu’un de te montrer la dernière fois qu’elle a servi. Le document annonce une revue mensuelle mais personne n’en retrouve une ? Le travail, c’est de remettre la pratique en place. Pas de renommer le fichier « final-v7-validé », hahaha.
Garde du temps pour les écarts
Prévois l’audit interne, la revue de direction et le temps de corriger avant l’évaluation de certification. Pour les exigences complètes, dont le plan de traitement des risques et la déclaration d’applicabilité, travaille avec la norme applicable et quelqu’un qui connaît le sujet. Cette note aide à démarrer ; elle ne remplace pas ce travail.
Le but n’est pas de jouer la sécurité pendant la visite de l’auditeur. C’est que ça tienne aussi pendant un mois chargé, une arrivée dans l’équipe ou un vrai incident. Le certificat apporte une assurance sur cette organisation. Il ne rend pas la boîte impossible à pirater.