Rapport explicatif

Al. 2 : L’exploitation du système dans le centre de calcul du fournisseur du système doit être certifiée conformément à la norme ISO 27001. Un canton qui n’exploite pas lui-même un système peut se faire certifier pour les processus cantonaux selon la norme ISO 27001, mais il n’est pas obligé de le faire.

Al. 3 : La ChF et les organes mandatés pour les contrôles visés à l’al. 1 doivent avoir accès aux documents nécessaires détenus par le canton et ses prestataires de services. Cela comprend tous les documents requis pour les contrôles prévus à l’al. 1 et tous les rapports disponibles (y compris les rapports de certification), les pièces justificatives et les certificats (certificat ISO 27001 au sens de l’al. 2 et toutes les certifications cantonales, s’il y en a).

Al. 4 : Les résultats des audits qui sont pertinents pour l’autorisation sont publiés. L’organe qui a commandé un audit est responsable de la publication. Il publie les pièces et les certificats qui ont été établis dans le cadre des contrôles conformément aux al. 1 et 2. Le terme « pièces justificatives » recouvre également les rapports d’audit. Les résultats des audits qui sont publiés doivent être compréhensibles. S’il y est fait référence à d’autres documents, ceux-ci doivent en règle générale être eux aussi publiés. S’il n’est pas possible de publier des documents supplémentaires, les résultats des audits doivent être rendus compréhensibles au moyen d’une description sommaire des aspects pertinents de la documentation non publiée. Si l’entité auditée fournit une réponse à un rapport d’audit, celle-ci doit elle aussi être publiée. Un document peut ne pas être publié si cela est justifié. Les exceptions s’appuient généralement sur les législations sur la transparence et sur la protection des données. Il s’agira à cet égard de mettre à chaque fois en balance l’intérêt public à une publication et l’intérêt à la confidentialité. À l’appui de ce dernier, il est notamment possible de faire valoir des directives internes, la protection des intérêts de l’entreprise ou encore la protection des données de tiers.

Art. 11 Publication du code source et de la documentation relative au système et à son exploitation

Les exigences précédemment applicables à la publication du code source et de la documentation relative au système et à son exploitation sont précisées. L’al. 1 contient désormais une liste des éléments qui doivent être publiés. Ci-après un commentaire de certains des termes utilisés:

Al. 1, let. a : Les «paramètres pertinents» comprennent toutes les informations et données nécessaires pour mettre le système en service chez soi.

Al. 1, let. b : La documentation relative au logiciel comprend notamment le protocole cryptographique, la spécification et l’architecture, les instructions, les concepts de test, les rapports consacrés aux failles et aux mesures correctives et les résultats du processus d’examen.

Al. 1. let. c : Comprend les documents qui facilitent la mise en service du système en vue de le tester (par exemple des instructions, une FAQ, etc.).

Al. 1, let. d : Comprend les documents qui documentent la conformité aux exigences de l’OVotE. Cela inclut également ceux qui documentent les mesures essentielles de réduction des risques mentionnées dans l’appréciation des risques. Le principe qui prévaut est le suivant: plus la documentation concerne l’exploitation, l’entretien ou la sécurité d’un composant dit fiable ou la manipulation d’un support de données contenant des données critiques, plus il est important de publier. Les dispositions de la législation sur la transparence qui concernent les exceptions s’appliquent au surplus.

Al.1, let. e : Si l’exploitant du système a connaissance d’une erreur dans le code source publié ou dans la documentation, il doit l’indiquer. Il décrit l’erreur et les mesures éventuellement prévues pour y remédier. Cela contribue à la compréhension, à la transparence et à la coopération avec le public.

Al. 2, let. c : Les exceptions justifiées se fondent sur les législations sur la transparence et sur la protection des données. En outre, si des motifs particuliers le justifient, il est possible de ne pas publier les documents peu ou pas pertinents pour la sécurité du système et son exploitation. Il s’agit par exemple de descriptions de processus opérationnels sans rapport direct avec le système ou de simples précisions pas ou peu déterminantes pour la sécurité ou dont il est possible de supposer qu’elles seront mises en œuvre correctement. Il s’agira à cet égard de mettre à chaque fois en balance l’intérêt public à une publication et l’intérêt à la confidentialité. À l’appui de ce dernier, il est notamment possible de faire valoir des directives internes, la protection des intérêts de l’entreprise ou encore la protection des données de tiers.