Cartographier les données et les acteurs

Listez les données que le WMS traite : articles, emplacements, mouvements, commandes, utilisateurs et journaux. Déterminez lesquelles sont personnelles, confidentielles ou sensibles pour l’activité. Pour chaque catégorie, notez la finalité, les personnes autorisées, la durée utile et les systèmes qui la reçoivent.

Recensez les acteurs : responsable du traitement, fournisseur, hébergeur, intégrateur et sous-traitants ultérieurs. Demandez à votre équipe compétente de déterminer les rôles applicables; ils dépendent des traitements et contrats, pas uniquement du nom du produit.

La CNIL rappelle qu’un sous-traitant qui traite des données pour le compte d’un organisme doit être encadré contractuellement au titre du RGPD. Faites examiner le contrat et les annexes par le responsable données ou le conseil de votre organisation. Une réponse commerciale de sécurité ne remplace pas cette analyse.

Revoir les identités et permissions

Définissez les rôles à partir des tâches et séparez les opérations sensibles lorsque c’est nécessaire. Demandez comment créer, suspendre et revoir les comptes, comment gérer les accès prestataires et quelles traces sont disponibles. Un compte partagé peut empêcher de savoir qui a confirmé ou modifié une opération.

Faites démontrer l’attribution d’un rôle, le refus d’une action non autorisée et la révocation d’un accès. Vérifiez si les journaux indiquent l’acteur, le moment, l’objet et l’action, et qui peut les consulter. Demandez la durée de conservation et l’export selon vos besoins.

N’accordez pas automatiquement des permissions élevées pour simplifier les essais. Créez des comptes fictifs, limitez les environnements et supprimez les accès temporaires selon une procédure. Les exigences de sécurité doivent être validées par les équipes responsables dans votre contexte.

Interroger l’hébergement et les sous-traitants

Demandez dans quelles régions les données sont stockées et traitées, quelles entités interviennent et comment les changements de sous-traitant sont communiqués. Renseignez-vous sur les mesures techniques et organisationnelles, les incidents et l’assistance aux demandes des personnes concernées, si ces sujets s’appliquent.

Demandez les documents adaptés à votre revue : description d’architecture, rapports ou attestations, conditions de transfert et procédure d’incident. Vérifiez l’émetteur, la période, le périmètre et les exclusions d’une preuve. Un badge ou une certification affichée sur une page ne couvre pas automatiquement chaque service.

L’équipe sécurité doit examiner la configuration réelle, les intégrations et les accès. L’emplacement du serveur ne répond pas à toutes les questions de protection. Ne saisissez pas de données opérationnelles dans une démonstration publique sans validation.

Prévoir la réponse à un incident

Clarifiez qui reçoit l’alerte, sous quel délai contractuel, par quel canal et quelles informations seront fournies. Demandez comment un incident lié à une interface ou un compte compromis est isolé. Attribuez un interlocuteur interne et préparez une méthode de communication aux équipes du site.

Faites un exercice sur un scénario fictif : accès d’un ancien utilisateur, export transmis à la mauvaise personne ou indisponibilité d’un terminal. Vérifiez les responsabilités et la documentation à conserver. L’objectif est de repérer les dépendances, non de tester un système en production.

La CNIL publie des ressources sur les relations responsable-sous-traitant et les obligations de l’article 28. Elles constituent des repères officiels; elles ne déterminent pas à elles seules votre conformité ou le niveau de sécurité d’un fournisseur.

Sources et limites

Ces repères éclairent une méthode de préparation; ils ne valident ni votre configuration ni un fournisseur. Vérifiez les documents contractuels, les versions techniques et les règles applicables à votre activité avec les personnes responsables.