Un audit PASSI est une prestation d’audit de sécurité réalisée dans les conditions du dispositif de qualification des prestataires d’audit de la sécurité des systèmes d’information. Il aide à obtenir des constats fiables sur un périmètre défini. Il ne délivre pas automatiquement une certification du système audité et ne garantit pas qu’aucune attaque ne pourra réussir.
Pour commander utilement cette prestation, il faut choisir les activités nécessaires, vérifier la portée du prestataire et préciser les décisions attendues du rapport. Une demande limitée à « faire un audit ANSSI » laisse trop de questions ouvertes : système concerné, accès fournis, environnement, profondeur, exclusions et preuves de correction. Ces choix déterminent autant la valeur du résultat que le nom du cabinet.
Comprendre la qualification PASSI actuelle
La version 2.2 du référentiel PASSI, datée du 1er août 2024, distingue les niveaux substantiel et élevé. L’annonce ANSSI du 29 novembre 2024 explique cette évolution et les dispositions de transition des évaluations antérieures. Pour une consultation en 2026, vérifiez la décision en vigueur plutôt que de reprendre une ancienne mention commerciale « PASSI LPM » sans examiner son sens actuel.
La portée associe des activités et un niveau de qualification. Le référentiel prévoit aussi des exigences supplémentaires pour les besoins de la sécurité nationale. Un prestataire qualifié sur une activité ne l’est pas nécessairement sur toutes. De plus, acheter une prestation quelconque à un cabinet qualifié ne démontre pas que cette mission particulière sera exécutée comme prestation qualifiée.
Demandez donc que le devis et la convention désignent les activités couvertes et l’engagement de réaliser la mission dans les conditions pertinentes. Le catalogue officiel de l’ANSSI permet de retrouver les références, décisions et dates de validité. Vérifiez l’entité juridique qui signe et celle qui réalise les travaux, notamment en présence d’un groupe ou d’un intermédiaire commercial.
Cette vérification ne se limite pas à la sélection initiale. Si l’équipe, la sous-traitance ou la date d’intervention change, demandez les conséquences sur les conditions de réalisation. Conservez la décision examinée et la correspondance avec le contrat. Une capture du logo sur une présentation est une preuve insuffisante pour décrire ce qui a effectivement été commandé.
Choisir parmi les cinq activités d’audit
L’index officiel des référentiels distingue l’architecture, la configuration, le code source, les tests d’intrusion et l’audit organisationnel et physique. Ces activités répondent à des questions différentes. Elles peuvent se compléter sans devoir être systématiquement toutes commandées pour chaque projet.
L’audit d’architecture examine les choix de conception, les flux, les zones de confiance et les dépendances. Il est utile avant une migration ou une ouverture du système à de nouveaux partenaires. Pour en tirer parti, fournissez les schémas actuels et faites participer des personnes capables d’expliquer les exceptions réelles, comme une interface d’administration accessible par un chemin ancien.
L’audit de configuration examine les réglages effectivement appliqués. Il peut révéler un écart entre une architecture bien conçue et un déploiement vulnérable : droits trop larges, fonctions inutiles actives ou journalisation insuffisante. Précisez les équipements et échantillons retenus. Un résultat sur quelques serveurs ne doit pas être présenté comme une vérification exhaustive de tous les environnements.
L’audit de code source permet d’étudier les mécanismes de l’application, notamment les autorisations et la manipulation des données. Définissez les composants accessibles, la version et les dépendances examinées. La quantité de code ne suffit pas à déterminer la profondeur : une fonction courte qui attribue les droits peut présenter davantage d’enjeux qu’un module volumineux d’affichage.
Le test d’intrusion cherche des chemins d’attaque dans un cadre autorisé. Ses résultats dépendent des accès fournis, du temps disponible et des scénarios. Un test sans compte utilisateur n’éclaire pas nécessairement les risques de séparation entre clients connectés. À l’inverse, fournir trop d’informations peut ne pas correspondre à l’objectif d’évaluer la détection d’une attaque externe. Le choix doit être explicite.
L’audit organisationnel et physique examine les pratiques et protections qui entourent le système : gestion des accès, fonctionnement des équipes, locaux ou procédures. Il peut vérifier comment une PSSI informatique se traduit dans les opérations. Une politique bien écrite n’établit pas que les départs sont traités correctement ou que les accès aux locaux sensibles sont maîtrisés.
Déterminer quand une prestation qualifiée est requise
La qualification est un dispositif d’évaluation des prestataires ; elle n’impose pas universellement un audit externe à toutes les entreprises. L’obligation peut découler d’un texte, d’une prescription applicable à un système, d’un programme particulier ou d’un engagement contractuel. Identifiez ce fondement avant de choisir la portée et le niveau.
Pour les OIV, l’article L. 1332-6-3 du code de la défense prévoit des contrôles demandés par le Premier ministre, effectués par l’autorité nationale, des services de l’État désignés ou des prestataires qualifiés. Les règles relatives aux systèmes d’importance vitale et les prescriptions sectorielles doivent aussi être examinées. Il serait réducteur d’en déduire que tout test réalisé dans un OIV est obligatoirement un audit externe identique.
Pour une homologation de sécurité, déterminez les contrôles requis par le régime et les risques du système. Le RGS ne doit pas être résumé par une formule selon laquelle chaque administration devrait commander chaque année un audit PASSI complet. Le fondement, le périmètre et les modalités de contrôle demandent une lecture précise.
De même, le processus d’évaluation d’une offre SecNumCloud ne signifie pas que chaque client doit faire auditer annuellement toute son application selon PASSI. Le fournisseur, son offre et le système déployé par le client sont des périmètres distincts. Les obligations contractuelles ou internes du client peuvent néanmoins justifier une mission adaptée.
Le secteur financier possède ses propres exigences. Les tests TLPT de DORA obéissent à des conditions concernant les entités visées, les testeurs et la supervision. Une qualification PASSI ne démontre pas, à elle seule, que toutes ces conditions sont satisfaites. Le guide DORA en France aide à distinguer le programme réglementaire d’un test d’intrusion ordinaire.
Si un appel d’offres invoque le dispositif Cyberscore, faites préciser le texte, le champ et la prestation attendue. La simple présence de ce mot dans une consultation ne permet pas de conclure que votre mission couvrira toutes les exigences invoquées. Cette clarification évite qu’une promesse commerciale de « conformité » remplace un livrable précisément défini.
Concernant NIS2, au 28 septembre 2026, le projet de loi français n’a pas achevé son parcours parlementaire ; l’Assemblée annonce sa discussion le 7 octobre, sous réserve de l’évolution de l’agenda. Ne présentez pas des modalités futures de contrôle comme une obligation française déjà adoptée. La veille sur la transposition doit accompagner la préparation sans effacer les règles actuellement applicables.
Rédiger un cahier des charges qui permette de comparer les devis
Commencez par l’objectif de décision. Voulez-vous autoriser une mise en production, examiner un changement d’architecture, comprendre une exposition ou vérifier une correction ? À partir de cette question, décrivez le système, les enjeux métier, les activités d’audit attendues et les résultats nécessaires. Une liste de noms de machines sans contexte ne permet pas de prioriser convenablement les travaux.
Précisez les environnements et leurs différences. Une préproduction peut faciliter les essais mais ne reproduire ni les données, ni les permissions, ni les connexions de la production. Demandez que ces écarts soient explicités dans le rapport. Si un composant ne peut pas être testé, indiquez la méthode alternative proposée et la limite qui subsistera.
Définissez également les documents et accès disponibles, les interlocuteurs, les périodes possibles et les dépendances externes. Le prestataire doit pouvoir évaluer ce qu’il peut réellement examiner. Un devis très court fondé sur une hypothèse d’accès complet sera trompeur si l’équipe découvre ensuite qu’une partie du système est inaccessible ou administrée par un tiers non mobilisé.
La rédaction d’une PSSI fournit un cadre de responsabilités ; le cahier des charges traduit ce cadre pour la mission. Demandez une explication des exclusions et de l’échantillonnage. Une restriction peut être raisonnable, mais elle doit apparaître avant la commande et dans les conclusions afin de ne pas élargir artificiellement la portée du résultat.
Encadrer les essais et protéger les informations
Les tests doivent reposer sur une autorisation écrite définissant les cibles, les actions permises, les limites et les personnes habilitées à intervenir. Assurez-vous que le commanditaire peut autoriser les opérations sur les systèmes concernés. La possession d’un abonnement cloud ne vaut pas nécessairement permission de tester tous les composants de l’hébergeur ou les services d’autres clients.
Convenir d’une procédure d’arrêt évite des décisions improvisées. Précisez qui peut interrompre les essais, comment joindre l’exploitation et dans quelles circonstances reprendre. Pour un service sensible, discutez des risques d’indisponibilité, des sauvegardes et de la possibilité de restaurer. Ces dispositions doivent être adaptées aux actions autorisées, pas reprises mécaniquement d’un modèle.
Les preuves d’audit peuvent contenir des identifiants, des extraits de données ou des détails facilitant une attaque. Limitez leur collecte à ce qui est nécessaire pour démontrer le constat. Définissez le transfert sécurisé, les destinataires, les accès au rapport et la conservation. Les obligations de sécurité de l’article 32 restent pertinentes lorsque des données personnelles sont traitées pendant la mission.
Si un auditeur découvre une situation urgente, l’organisation doit savoir comment être alertée sans attendre le rapport final. Cette alerte technique ne préjuge pas de la qualification juridique d’une violation de données. Les responsables compétents doivent pouvoir analyser les faits et activer les procédures appropriées, sans perdre le contexte des essais ou altérer les éléments utiles.
Évaluer le prix sans reprendre un tarif prétendument universel
Le coût dépend du périmètre, des activités, de la complexité, de l’accès aux informations, de la qualification attendue et des livrables. Une fourchette journalière non sourcée ne permet pas de savoir si une offre couvre vos besoins. Comparez d’abord des hypothèses identiques et demandez l’effort prévu pour le cadrage, les travaux, le rapport et la restitution.
Examinez aussi les conditions qui déclenchent un supplément : environnement indisponible, ajout de composants, déplacement, nouvelle version à examiner ou contre-vérification. Une offre peut sembler moins chère parce qu’elle exclut les essais après correction ou les échanges avec les équipes de développement. Ces exclusions doivent être évaluées au regard de la décision que vous cherchez à prendre.
Prévoyez les ressources internes : préparation des accès, disponibilité des équipes, analyse des constats et corrections. Aucun ratio universel ne permet d’affirmer que la remédiation coûtera nécessairement autant que l’audit. Certaines corrections sont rapides ; d’autres nécessitent une transformation d’architecture. Le rapport doit aider à les distinguer plutôt qu’à les traiter comme une enveloppe indifférenciée.
Lire le rapport et transformer les constats en actions
Un constat exploitable décrit le composant, la situation observée, les conditions de reproduction, les conséquences et une piste de correction. Il doit permettre à une équipe de comprendre ce qui a été démontré et ce qui reste hypothétique. Le niveau de gravité technique gagne à être rapproché de l’exposition réelle et des effets métier.
Conservez la distinction entre constat, décision et preuve. Le catalogue de contrôles associant objectif, activité et preuve aide à structurer ce suivi. Par exemple, l’objectif est de limiter les privilèges ; l’activité consiste à revoir les droits ; la preuve montre les comptes examinés, les retraits et la vérification. Le rapport d’audit initial ne prouve pas que ces retraits ont ensuite eu lieu.
Attribuez chaque action à une personne capable de la réaliser, avec une échéance et une vérification. Si la correction dépend d’un éditeur, conservez le suivi de cette dépendance et évaluez les protections intermédiaires. Une faiblesse acceptée doit faire l’objet d’une décision explicite par l’autorité compétente, avec ses motifs et ses limites ; le mot « accepté » dans un tableau ne suffit pas.
L’audit RGPD et l’audit de sécurité peuvent partager certaines preuves, mais leurs conclusions ne sont pas interchangeables. Une application correctement protégée peut conserver trop longtemps des données ou poursuivre une finalité illicite. Inversement, des documents juridiques complets ne démontrent pas que les mécanismes d’autorisation sont efficaces.
Pour éviter de réutiliser un rapport hors de son périmètre, la matrice de validité des preuves d’audit relie date, période, changement technique et responsable de renouvellement.
La fiche de clôture d’un écart distingue l’action déclarée du résultat contrôlé et documente la contre-vérification avant acceptation.
Exemple : vérifier l’isolation entre les clients d’un logiciel
Supposons qu’un éditeur souhaite vérifier qu’un utilisateur ne peut pas consulter les dossiers d’un autre client. Un simple scan externe de la page de connexion ne répond pas à cette question. La mission peut nécessiter des comptes appartenant à plusieurs organisations, des rôles différents et des parcours représentatifs d’export, de recherche et d’accès par API.
Le cadrage définit les données de test, les actions autorisées et la manière de démontrer un accès indu sans extraire inutilement des dossiers réels. Le rapport doit préciser les versions testées et les chemins couverts. Si un défaut est découvert dans une fonction commune, la correction doit être examinée au-delà du seul écran où il a été observé.
Une contre-vérification ciblée confirme ensuite le comportement corrigé et recherche un éventuel contournement proche. Elle ne transforme pas le résultat en garantie perpétuelle. Un nouveau mode de partage ou une modification des rôles peut justifier d’autres travaux. Cette logique de suivi peut s’intégrer à un système de management ISO 27001, sans confondre la mission PASSI et la certification de ce système de management.
Questions fréquentes
Un cabinet qualifié réalise-t-il toujours une prestation qualifiée ?
Non. Il faut vérifier la portée, le niveau et les conditions de la mission commandée. Faites inscrire l’engagement approprié dans la convention. Une marque ou une qualification sur une autre activité ne suffit pas.
À quelle fréquence faut-il recommencer l’audit ?
La fréquence dépend des obligations applicables, des risques, des changements et des engagements contractuels. Il n’existe pas une périodicité unique valable pour toute prestation PASSI. Une évolution majeure ou un incident peut justifier un examen avant la date prévue.
L’absence de faille critique permet-elle de déclarer le système conforme ?
Elle indique seulement qu’aucune faille de cette catégorie n’a été retenue dans les conditions et limites de la mission. Relisez les exclusions, les accès et les constats non techniques. La décision d’exploitation doit intégrer ces limites et les autres exigences applicables au système.