Une entreprise de logiciels qui détient l'ISO 27001 et lit l'ISO 9001 pour la première fois en reconnaît l'essentiel. Contexte, leadership, planification, support, évaluation des performances et amélioration, les paragraphes 4 à 7, 9 et 10, sont la structure harmonisée : le même squelette avec « qualité » là où l'autre norme dit « sécurité de l'information ». Puis elle atteint le paragraphe 8, Réalisation des activités opérationnelles, et y trouve la production, la traçabilité, la préservation des éléments de sortie et la propriété des clients, écrits pour des organismes qui fabriquent et expédient des choses. La tentation est d'en déclarer l'essentiel non applicable. C'est la mauvaise lecture : le paragraphe 8 s'applique en entier au logiciel, il a simplement besoin d'être traduit, et la traduction est ce que fait cet article, sous-paragraphe par sous-paragraphe, dans notre lecture du texte ; le libellé de l'ISO n'est pas reproduit. Dans notre propre registre de paragraphes, le paragraphe 8 est là où sont les lacunes honnêtes, et la traduction ci-dessous est ce que ces enregistrements devraient contenir.

8.1 Planification et maîtrise opérationnelles

Le paragraphe demande à l'organisme de planifier et de maîtriser les processus qui fournissent ses produits et services : des critères pour les processus et pour l'acceptation, les ressources, et assez d'information documentée pour avoir confiance dans le fait que les processus se sont déroulés comme prévu. Pour un logiciel, c'est la définition du chemin d'une fonctionnalité de la demande à la production, et les critères d'acceptation à chaque étape. C'est aussi le seul endroit où le paragraphe 8 mentionne les processus externalisés, ce qui pour une entreprise de logiciels signifie la plateforme cloud sur laquelle elle tourne.

8.2 Exigences relatives aux produits et services

8.2.1 est la communication avec les clients : comment un client apprend ce que fait le produit, comment il commande, comment il réclame, et comment sa propriété (des données, dans le cas d'une entreprise de logiciels) est traitée. 8.2.2 est la détermination des exigences : ce que le produit doit faire, y compris les exigences légales et réglementaires qui s'y appliquent. 8.2.3 est la revue de ces exigences avant que l'organisme ne s'engage à fournir, avec les résultats conservés, et c'est le sous-paragraphe où les entreprises de logiciels échouent le plus souvent : un contrat signé avec un engagement spécifique au client que personne en ingénierie n'a revu est une non-conformité au regard de 8.2.3, quoi que les ingénieurs réalisent ensuite. 8.2.4 est les modifications des exigences, ce qui dans un produit par abonnement est chaque note de version.

Pour une entreprise de logiciels, « exigences légales et réglementaires » a désormais un contenu précis : à partir du 11 décembre 2027, les exigences essentielles de l'annexe I du Cyber Resilience Act sont des exigences relatives au produit au sens de 8.2.2, et une revue des exigences qui ne les considère pas est incomplète.

8.3 Conception et développement

C'est le cycle de développement logiciel, et le sous-paragraphe qui se transpose le plus directement. 8.3.2, la planification, est la définition du processus : les étapes, les revues, la vérification et la validation, les responsabilités, ce à quoi le client participe, et l'information documentée à conserver. 8.3.3, les éléments d'entrée, sont les exigences dont part un travail, y compris les exigences légales et réglementaires et ce qui a été appris des produits précédents. 8.3.4, la maîtrise, est la distinction que fait la norme et que les équipes d'ingénierie brouillent d'habitude : les revues (la conception répond-elle au plan), la vérification (l'élément de sortie répond-il aux exigences d'entrée, c'est-à-dire la revue de code et la suite de tests) et la validation (le produit répond-il à l'usage prévu, c'est-à-dire l'acceptation par l'utilisateur ou en son nom). 8.3.5, les éléments de sortie, est ce qui quitte le développement : l'artefact, sa documentation, les critères d'acceptation contre lesquels il a été vérifié. 8.3.6, les modifications, est la maîtrise des modifications de la conception, avec la revue, l'autorisation et toute action pour prévenir un impact négatif, conservées.

Une entreprise qui tient son travail dans un système de tickets, revoit le code, exécute des tests et a une définition du « terminé » a l'essentiel des enregistrements que demande 8.3. Ce qui lui manque en général est l'enregistrement qui les relie par modification : quel élément d'entrée, quelle revue, quelle vérification, quelle validation, qui a autorisé.

8.4 Processus, produits et services fournis par des prestataires externes

8.4.1 demande que les prestataires externes soient évalués, sélectionnés, surveillés et réévalués, avec des enregistrements ; 8.4.2 que le type et l'étendue de la maîtrise correspondent à l'effet de la prestation sur le produit ; 8.4.3 que le prestataire soit informé de ce qui est exigé de lui. Pour un logiciel, les prestataires externes sont de trois sortes : la plateforme cloud et les outils SaaS sur lesquels tourne le produit, qui sont des processus externalisés au titre de 8.4.1 ; les composants open source et commerciaux dans le produit, qui sont des produits fournis par des prestataires externes ; et les sous-traitants qui écrivent du code. La deuxième sorte est là où 8.4 et le Cyber Resilience Act se rejoignent : la diligence que l'article 13(5) demande sur les composants est la maîtrise 8.4.2 d'une dépendance logicielle, et le même enregistrement sert aux deux.

8.5 Production et prestation de service

Le sous-paragraphe qui demande le plus de traduction. 8.5.1, les conditions maîtrisées, est le déploiement : le processus documenté, la surveillance aux étapes qui comptent, l'infrastructure et l'environnement, des personnes compétentes, et la validation des processus dont l'élément de sortie ne peut pas être vérifié après coup, ce qui dans une entreprise de logiciels est le pipeline de déploiement lui-même. 8.5.2, l'identification et la traçabilité, sont les versions et les identifiants de build : quel build est en production, quel client utilise quelle version, et la capacité de remonter l'historique d'un élément de sortie lorsque la traçabilité est exigée. 8.5.3, la propriété des clients ou des prestataires externes, est le sous-paragraphe qu'une entreprise SaaS doit lire le plus attentivement : les données, les identifiants et les contenus des clients sont de la propriété du client au sens de la norme, à identifier, vérifier, protéger et sauvegarder, et une perte ou un dommage est signalé au client avec l'enregistrement conservé. 8.5.4, la préservation, est les sauvegardes et l'intégrité de l'artefact livré. 8.5.5, les activités après livraison, est le support, la maintenance et les mises à jour aussi longtemps que l'organisme s'y est engagé, ce qui sous le Cyber Resilience Act devient la période d'assistance avec des mises à jour de sécurité sur toute sa durée. 8.5.6, la maîtrise des modifications, est la maîtrise des changements en production, avec la revue, la personne qui autorise et toute action, conservées.

8.6 Libération des produits et services

La libération n'a lieu que lorsque les dispositions planifiées ont été menées à bien, sauf approbation contraire d'une autorité compétente et, le cas échéant, du client ; l'enregistrement montre la preuve de la conformité aux critères d'acceptation et qui a autorisé la libération. Pour un logiciel, c'est le portail de libération : les critères contre lesquels le build a été vérifié, la preuve, et la personne nommée qui l'a laissé partir. Une entreprise qui déploie en continu a quand même une libération au sens de la norme à chaque déploiement, et le portail est l'ensemble des contrôles du pipeline plus l'approbation qui laisse passer une modification ; l'enregistrement est le journal du pipeline, à condition qu'il nomme les critères et l'approbateur.

8.7 Maîtrise des éléments de sortie non conformes

Un élément de sortie non conforme est identifié et maîtrisé pour ne pas être livré ou utilisé par inadvertance : corrigé, isolé, le client informé, ou une dérogation obtenue ; et l'enregistrement dit quelle était la non-conformité, ce qui a été fait, toute dérogation et qui a décidé. Pour un logiciel, les éléments de sortie non conformes sont les bugs qui ont atteint un client, les incidents, la version qu'il a fallu retirer. Le gestionnaire de bugs tient déjà l'essentiel de l'enregistrement ; ce que 8.7.2 ajoute est la décision, en particulier la dérogation, c'est-à-dire la décision de livrer ou de laisser en place un défaut connu, prise par quelqu'un qui en a l'autorité. Un défaut connu livré sans cette décision est la non-conformité qu'un auditeur relève, pas le défaut lui-même.

Ce que cela donne au total

Lu ainsi, le paragraphe 8 pour une entreprise de logiciels est six enregistrements que l'entreprise produit déjà pour l'essentiel dans ses outils de tickets, de revue de code, d'intégration continue et de gestion des incidents, plus les décisions que ces outils n'enregistrent pas : la revue des exigences avant un engagement, l'autorisation d'une modification de conception, l'approbation de la libération, et la dérogation sur un défaut connu. Le rôle du système de management est de tenir ces décisions à côté des artefacts, pour qu'un auditeur, ou l'auditeur d'un client, puisse suivre une modification de la demande à la libération avec chaque contrôle et chaque nom en place. Quels sous-paragraphes du paragraphe 8 StandardOS tient en enregistrements, et lesquels non, est publié paragraphe par paragraphe ; les autres paragraphes, l'information documentée et la revue de direction entre autres, sont ceux qu'une entreprise ISO 27001 fait déjà tourner.

Sources

  • ISO 9001:2015, paragraphes 8.1 à 8.7, cités par numéro ; le texte est celui de l'ISO et n'est pas reproduit.
  • Règlement (UE) 2024/2847 (CRA), article 13(5) et (8), annexe I, pour les endroits où les mêmes enregistrements sont exigés d'un produit logiciel.

Ceci n'est pas un conseil en certification. Jusqu'où un sous-paragraphe s'applique à un produit donné se décide dans le périmètre de l'organisme et s'y justifie ; la traduction ci-dessus est la nôtre.