Un bon modèle de rapport d’audit cybersécurité pour une PME doit permettre à la direction de comprendre la situation en quelques minutes, puis aux équipes de savoir précisément quoi corriger. Il repose sur trois niveaux de lecture : une synthèse exécutive, des constats reliés à des critères et à des preuves, puis un plan d’action avec priorité, responsable, échéance et preuve de clôture. Le score de maturité n’est qu’un indicateur : il ne doit jamais masquer les écarts critiques ni être présenté comme une certification. Le rapport devient utile lorsqu’il transforme une évaluation ponctuelle en décisions suivies dans le temps.
Un rapport d’audit cybersécurité formalise les objectifs, le périmètre, les critères, les éléments examinés, les constats et les conclusions d’une évaluation.
Un audit repose sur des critères préalablement définis et sur des éléments vérifiables. Ces critères peuvent provenir d’un référentiel, d’une politique interne, d’une obligation contractuelle, d’une réglementation ou d’une norme. Une preuve peut être un document, une configuration, un enregistrement, une observation ou une déclaration recoupée.
Le rapport doit donc répondre à cinq questions simples :
La version 2026 d’ISO 19011 fournit un cadre général pour organiser les programmes d’audit, conduire les audits de systèmes de management et assurer une méthode cohérente. Elle ne prescrit cependant pas un modèle unique de rapport cybersécurité.
Ces trois livrables ne doivent pas être confondus.
| Livrable | Question principale | Résultat attendu |
| Rapport d’audit | Les critères définis sont-ils respectés ? | Conformités, écarts, preuves et recommandations |
| Rapport de maturité | À quel niveau les pratiques sont-elles structurées et pilotées ? | Score, forces, faiblesses et trajectoire de progression |
| Rapport d’audit technique | Quelles vulnérabilités ou faiblesses techniques ont été observées ? | Résultats de tests, vulnérabilités et corrections techniques |
| Plan d’action | Qui doit faire quoi, pour quand et avec quelle preuve ? | Actions, responsables, échéances, statuts et contrôles de clôture |
Un même rapport peut combiner audit et maturité, mais il doit expliquer clairement la différence entre les deux.
Une note de maturité ne constitue pas automatiquement une conclusion de conformité. L’ENISA rappelle d’ailleurs, dans son modèle de maturité destiné aux PME publié en juillet 2026, qu’un niveau avancé ne remplace pas les obligations applicables et ne doit pas être considéré comme une preuve de conformité.
De la même manière, une évaluation documentaire ne remplace pas un test d’intrusion, un audit de configuration ou un audit de code. Le référentiel PASSI de l’ANSSI distingue notamment les audits organisationnels et physiques, les audits d’architecture, de configuration, de code source et les tests d’intrusion.
Un rapport d’audit cyber est généralement lu par plusieurs profils :
La structure doit donc proposer plusieurs niveaux de lecture, sans produire plusieurs audits différents.
La synthèse exécutive répond à la direction. Les fiches de constats servent aux responsables opérationnels. L’index des preuves et la méthode assurent la traçabilité nécessaire à une revue ultérieure.
Le tableau suivant constitue une trame directement réutilisable.
| Section | Contenu attendu | Question à laquelle elle répond |
| 1. Page de garde | Organisation, intitulé, version, date, auteur, classification | De quel document s’agit-il ? |
| 2. Identification | Commanditaire, auditeurs, période, référentiel, modèle d’audit | Qui a réalisé quoi et quand ? |
| 3. Synthèse exécutive | Conclusion générale, indicateurs, forces, écarts critiques, décisions | Que doit retenir la direction ? |
| 4. Objectifs et périmètre | Entités, sites, processus, applications, exclusions | Qu’a-t-on réellement audité ? |
| 5. Critères et méthode | Référentiel, collecte, échantillonnage, notation, limites | Comment les conclusions ont-elles été obtenues ? |
| 6. Résultats consolidés | Couverture, scores, répartition des statuts, tendances | Quelle est la situation globale ? |
| 7. Constats détaillés | Critère, observation, preuve, écart, risque, recommandation | Pourquoi faut-il agir ? |
| 8. Plan d’action | Priorité, action, responsable, échéance, statut, preuve attendue | Comment traiter les écarts ? |
| 9. Conclusion | Niveau général, réserves, prochaine revue | Quelle suite donner à l’audit ? |
| 10. Annexes | Index des preuves, personnes interrogées, mesures non évaluées | Comment vérifier et reproduire l’analyse ? |
Le rapport d’audit démo fourni par CompliKey reprend déjà une grande partie de cette structure : identification, synthèse exécutive, couverture, score moyen, graphiques, méthode de notation, mesures auditées, remédiations, index des preuves et points forts.
La première page doit au minimum préciser :
Le rapport CompliKey ajoute également une mention utile : le document est une évaluation interne fondée sur des preuves et ne constitue pas une certification. Cette précision limite le risque d’interprétation abusive du livrable.
La synthèse exécutive ne doit pas être un résumé de toutes les pages suivantes.
Elle doit permettre à un dirigeant de comprendre, en deux minutes :
Un modèle efficace peut tenir sur une ou deux pages.
Conclusion générale
L’organisation dispose de plusieurs mesures techniques déjà opérationnelles, notamment sur les sauvegardes, l’antimalware et la gestion des accès. Leur formalisation, leur suivi et la conservation des preuves restent cependant insuffisants. La priorité doit porter sur l’analyse des risques, les comptes à privilèges et la gestion des incidents.
Indicateurs
Ces chiffres proviennent du rapport de démonstration et ne constituent pas un benchmark de maturité des PME. Ils illustrent uniquement la manière dont les résultats peuvent être présentés.
Décisions proposées
Le périmètre doit être suffisamment précis pour éviter qu’un lecteur conclue que toute l’entreprise a été auditée alors que seuls quelques processus ont été examinés.
Il peut contenir :
La méthode doit ensuite préciser :
Le NIST distingue notamment trois familles de méthodes d’évaluation : les tests, l’examen d’éléments et les entretiens. Ces méthodes ne produisent pas le même niveau d’assurance et doivent donc être identifiées dans le rapport.
Un audit exclusivement fondé sur des entretiens doit être présenté comme tel. L’absence de document ou de trace ne signifie pas systématiquement que la mesure n’existe pas, mais qu’elle n’a pas pu être démontrée avec le niveau d’assurance attendu.
Le tableau détaillé ne doit pas se limiter à une note et à une phrase.
Chaque ligne doit permettre de remonter :
Dans le rapport CompliKey, le tableau des mesures relie déjà l’intitulé, les règles du référentiel, le score, le commentaire, les preuves et les remédiations. La règle « Non fourni » permet également d’éviter de compléter artificiellement une colonne en l’absence d’information.
Le plan d’action doit être exploitable indépendamment du rapport.
Une équipe projet doit pouvoir le reprendre dans son outil de suivi sans avoir à relire toutes les fiches de constats.
Les annexes servent quant à elles à préserver la traçabilité sans alourdir la synthèse :
Avant de choisir les graphiques ou le modèle Word, il faut déterminer l’usage du rapport.
S’agit-il de :
Un rapport destiné à une décision budgétaire doit montrer les priorités, les dépendances et les ressources nécessaires.
Un rapport de préparation à un audit externe doit davantage insister sur les critères, les preuves et les écarts de conformité.
La méthode de notation doit être définie avant l’évaluation.
À défaut, l’auditeur risque de modifier son niveau d’exigence au fur et à mesure des entretiens.
Pour chaque niveau, il faut préciser :
Le rapport démo CompliKey utilise une échelle de 0 à 4 :
| Score | Niveau |
| 0 | Inexistant |
| 1 | Initié |
| 2 | Défini |
| 3 | Maîtrisé |
| 4 | Optimisé |
L’évaluation s’appuie sur quatre axes : les preuves, l’effectivité, le pilotage et la pérennité. Le rapport prévoit également qu’une note au moins égale à 2 nécessite qu’une preuve soit référencée. Cette échelle correspond à la méthode CompliKey ; elle ne doit pas être présentée comme une échelle officielle de l’ANSSI ou de l’ISO.
Un constat doit pouvoir être défendu plusieurs semaines après l’audit.
La preuve doit donc être :
Un intitulé tel que « capture Microsoft 365 » est souvent insuffisant. Il faut préciser ce que la capture permet de démontrer et, si nécessaire, ses limites.
Exemple :
Capture de la console Microsoft 365 datée du 28 mars 2026 montrant l’activation du MFA pour les comptes utilisateurs du périmètre examiné. La capture ne permet pas de confirmer la couverture des comptes administrateurs ni des applications hors Microsoft 365.
Cette rédaction évite de faire dire à la preuve plus que ce qu’elle démontre réellement.
Une erreur fréquente consiste à partir directement de la solution :
Mettre en place une politique de sécurité.
Cette recommandation ne permet pas de comprendre :
Il faut d’abord rédiger le constat, puis seulement la recommandation.
La gravité d’un constat ne doit pas dépendre uniquement du nombre de critères non satisfaits.
Une priorisation utile prend au minimum en compte :
Le score de maturité peut éclairer la décision, mais ne remplace pas l’analyse du risque.
Une mesure notée 2 sur 4 peut cacher une faiblesse critique sur un actif exposé. Inversement, une note faible sur une procédure secondaire ne doit pas nécessairement devenir la première priorité du trimestre.
Une recommandation indique la direction à suivre.
Une action indique ce qui sera réellement fait.
| Recommandation | Action pilotable |
| Renforcer le MFA | Identifier les applications sensibles sans MFA et activer le MFA pour les comptes concernés |
| Formaliser les sauvegardes | Documenter le périmètre sauvegardé, la rétention, les responsabilités et la fréquence des tests |
| Améliorer la gestion des incidents | Créer une procédure, un registre et une matrice d’escalade |
| Revoir les droits | Extraire les comptes à privilèges, faire valider les accès et supprimer les droits injustifiés |
Le NIST recommande que les résultats d’évaluation soient reliés à des mesures de correction et à un plan permettant de suivre les tâches, les ressources, les jalons et les dates de réalisation.
Avant publication, l’organisation auditée doit pouvoir vérifier :
Cette relecture ne doit pas conduire à supprimer un constat uniquement parce qu’il est inconfortable.
En cas de désaccord, le rapport peut documenter :
Un constat complet peut être construit avec les champs suivants :
| Champ | Contenu |
| Critère | Exigence, règle, politique ou objectif évalué |
| Observation | Situation factuelle constatée |
| Preuve | Élément vérifiable examiné |
| Écart | Différence entre la situation et le critère |
| Risque | Conséquence possible pour l’organisation |
| Qualification | Majeur, mineur, écart, observation ou point fort |
| Recommandation | Résultat de sécurité recherché |
Le terme « non-conformité » doit être réservé aux situations dans lesquelles un critère défini n’est pas satisfait. Sans critère explicite, il est généralement plus rigoureux de parler d’observation, de faiblesse ou d’opportunité d’amélioration.
L’exemple suivant est adapté du constat d’authentification présenté dans le rapport CompliKey.
Les accès distants, les applications sensibles et les comptes à privilèges doivent être protégés par une authentification multifacteur selon les règles définies par l’organisation.
L’entreprise utilise des comptes nominatifs. Le MFA est activé pour la messagerie Microsoft 365 et pour l’accès VPN. Il n’a toutefois pas été démontré que l’ensemble des comptes administrateurs et des applications sensibles étaient couverts.
La couverture MFA est partielle et aucune règle formalisée ne définit les catégories de comptes et de services devant obligatoirement utiliser un second facteur.
Un compte sensible non couvert pourrait être compromis à la suite d’un vol ou d’une réutilisation de mot de passe. L’absence de règle commune peut également entraîner des niveaux de protection différents entre applications.
Non-conformité mineure sur la couverture du MFA, accompagnée d’un écart de formalisation.
La qualification définitive dépend du référentiel, du périmètre et de la méthode de gravité retenue.
Étendre le MFA aux comptes administrateurs, aux accès distants et aux applications sensibles. Formaliser les règles de couverture, les exceptions et la fréquence de revue.
| Champ | Exemple |
| Action | Recenser les comptes et applications sensibles non couverts, puis activer le MFA |
| Responsable | Responsable informatique |
| Contribution | Prestataire informatique et responsables applicatifs |
| Échéance illustrative | J+60 |
| Priorité | Haute |
| Preuve de clôture | Export de configuration, liste des comptes couverts et validation de la règle |
| Contrôle | Revue de couverture après déploiement |
Ces trois indicateurs répondent à des questions différentes.
| Indicateur | Question |
| Maturité | La pratique est-elle définie, appliquée, suivie et durable ? |
| Conformité | Le critère applicable est-il satisfait ? |
| Risque | Quelle conséquence la faiblesse peut-elle entraîner ? |
Un score moyen de 2,8 sur 4 ne signifie donc pas :
Le rapport doit toujours permettre de consulter la distribution des scores et les écarts critiques, pas uniquement la moyenne.
Pour être exploitable, la notation doit indiquer :
Il est également utile de présenter :
La moyenne ne doit jamais remplacer la lecture des constats.
Un plan de remédiation réellement pilotable contient au minimum :
| Champ | Finalité |
| Identifiant | Retrouver l’action sans ambiguïté |
| Constat d’origine | Conserver le lien avec l’audit |
| Action | Décrire le travail à réaliser |
| Priorité | Ordonner l’exécution |
| Responsable | Désigner le propriétaire |
| Contributeurs | Identifier les équipes sollicitées |
| Échéance | Fixer la cible |
| Statut | Suivre l’avancement |
| Effort estimé | Anticiper la charge |
| Dépendances | Identifier les prérequis |
| Preuve de clôture | Définir comment valider l’action |
| Risque résiduel | Documenter ce qui subsiste |
Une action sans responsable est une recommandation.
Une action sans échéance est une intention.
Une action sans preuve de clôture ne permet pas de démontrer que l’écart a été traité.
| Priorité | Action | Responsable | Échéance | Preuve attendue |
| P1 | Réaliser une première analyse de risques | Direction et référent sécurité | À planifier | Méthode, registre des risques et validation |
| P1 | Généraliser le MFA aux comptes sensibles | Responsable informatique | J+60 | Export de configuration et revue de couverture |
| P1 | Séparer les comptes standards et administrateurs | Responsable informatique | J+60 | Liste des comptes et contrôle d’accès |
| P2 | Formaliser la gestion des incidents | Référent sécurité | J+90 | Procédure, contacts et registre |
| P2 | Tester une restauration de sauvegarde | Responsable infrastructure | J+90 | Compte rendu du test et anomalies traitées |
| P3 | Structurer le programme de sensibilisation | RH et référent sécurité | J+120 | Calendrier, supports et suivi des participants |
Les délais sont ici illustratifs. Ils ne constituent ni une obligation réglementaire ni une durée standard applicable à toutes les PME.
Le livrable minimal ne devrait pas se limiter à un PDF.
Un ensemble cohérent comprend généralement :
Il contient la synthèse, la méthode, les résultats et les conclusions.
Il doit pouvoir être filtré, mis à jour et attribué. Un format tableur ou un accès à une plateforme est souvent plus adapté qu’un tableau figé dans un PDF.
Il conserve la correspondance entre les mesures et les éléments examinés, sans nécessairement intégrer les documents sensibles au rapport.
Il présente les décisions attendues, les priorités et les arbitrages à réaliser. Il ne doit pas reproduire les cinquante pages du rapport.
Il indique les actions acceptées, reportées ou refusées, ainsi que les risques formellement acceptés.
Il précise la prochaine revue, la méthode de validation des actions et les personnes responsables du pilotage.
Une liste de vulnérabilités, de ports ou de configurations ne permet pas toujours à la direction de comprendre les conséquences opérationnelles.
Les détails techniques doivent rester accessibles, mais être reliés aux actifs, aux risques et aux décisions.
Un score non documenté donne une impression de précision sans être reproductible.
Deux auditeurs doivent pouvoir comprendre pourquoi une mesure a obtenu 1 plutôt que 2.
« Non démontré » et « inexistant » ne signifient pas la même chose.
Cette distinction doit être conservée dans les constats et dans la notation.
« Mettre en conformité », « renforcer la sécurité » ou « formaliser les processus » ne sont pas des actions.
La recommandation doit indiquer le résultat attendu et le plan d’action doit préciser le travail à réaliser.
Les points forts permettent de préserver les pratiques déjà efficaces et d’éviter que la direction considère l’audit comme une simple liste de reproches.
Le rapport doit signaler les exclusions, les indisponibilités, les preuves manquantes, les restrictions d’échantillonnage et l’absence éventuelle de tests techniques.
Un rapport remis puis archivé apporte peu de valeur.
La clôture de l’audit doit ouvrir un cycle de remédiation, de contrôle et de réévaluation.
L’effort dépend du périmètre, du nombre de mesures, de la disponibilité des interlocuteurs et de la qualité des preuves.
Pour un audit flash comparable au rapport démo CompliKey — une entité, un périmètre limité, une douzaine de mesures et des preuves déjà disponibles — l’ordre de grandeur suivant peut servir à préparer la charge :
| Activité | Charge indicative |
| Cadrage et préparation | 0,25 à 0,5 jour |
| Entretiens et collecte | 0,5 à 1 jour |
| Analyse des preuves | 0,5 à 1 jour |
| Rédaction des constats et du plan | 0,75 à 1 jour |
| Relecture et restitution | 0,5 jour |
| Total indicatif | 2,5 à 4 jours |
Cette estimation est une décomposition de travail, pas un benchmark ANSSI ou ISO. Elle suppose un périmètre restreint, peu de déplacements, des interlocuteurs disponibles et l’absence de tests techniques complexes.
Un audit multisite, multinorme, technique ou réglementaire nécessite un chiffrage spécifique.
CompliKey permet de centraliser les référentiels, les mesures évaluées, les commentaires d’audit, les scores, les preuves référencées, les remédiations et les actions associées.
Le rapport de démonstration fourni illustre notamment :
Cette centralisation limite les écarts de structure entre plusieurs missions et facilite la mise à jour du rapport lorsqu’un constat, une preuve ou un score évolue.
CompliKey ne réalise pas automatiquement l’analyse technique. La plateforme ne remplace ni un scanner de vulnérabilités, ni un SIEM, ni un EDR, ni un test d’intrusion. Elle ne remplace pas non plus une méthode complète d’analyse de risques comme EBIOS Risk Manager ou le jugement d’un auditeur.
Son rôle est de structurer l’évaluation et son suivi :
référentiel → mesure → question → preuve → score → constat → recommandation → action → contrôle de clôture.
Le rapport actuel présente correctement les observations et les recommandations dans son plan de remédiation. En revanche, les colonnes suivantes ne figurent pas encore dans le tableau exporté :
Pour que le CTA de l’article soit parfaitement cohérent avec la promesse d’un rapport relié à un plan d’action, il serait pertinent d’ajouter ces informations au rapport généré, ou de joindre un export distinct du plan d’action.
Un rapport d’audit cybersécurité utile ne se mesure pas au nombre de pages produites.
Il doit :
Pour une PME, le meilleur rapport est celui que la direction comprend, que l’équipe informatique peut exécuter et qu’un consultant peut défendre plusieurs mois après sa remise.
CompliKey apporte ici un cadre homogène pour centraliser les évaluations, produire les restitutions et suivre les remédiations dans le temps, sans se substituer au travail d’analyse de l’auditeur.
Un rapport d’audit cybersécurité doit contenir l’identification de l’organisation, les objectifs, le périmètre, les critères, la méthode, les limites, une synthèse exécutive, les constats détaillés, les preuves examinées, les recommandations et un plan d’action. Il doit également préciser les mesures non évaluées et la méthode de notation. Les annexes peuvent regrouper l’index des preuves, les personnes interrogées et le détail des résultats.
Un constat doit décrire un critère, une situation observée, les preuves examinées, l’écart constaté, le risque associé et la recommandation. La rédaction doit rester factuelle et éviter les formulations vagues. Une non-conformité ne devrait être déclarée que lorsqu’un critère défini n’est pas satisfait. La recommandation doit ensuite être traduite en action avec un responsable, une échéance et une preuve attendue.
Le calcul dépend du modèle choisi. L’échelle et les conditions de chaque niveau doivent être définies avant l’audit. Le rapport doit préciser les règles de pondération, d’arrondi et de traitement des mesures non applicables ou non évaluées. Le score peut mesurer le niveau de formalisation, d’application, de pilotage et de pérennité. Il ne constitue toutefois ni une certification ni une preuve suffisante de conformité.
Le rapport d’audit décrit le périmètre, la méthode, les preuves, les constats et les conclusions de l’évaluation. Le plan d’action organise le traitement des écarts. Il précise les actions, les responsables, les échéances, les statuts, les ressources et les preuves de clôture. Le rapport explique pourquoi il faut agir ; le plan d’action indique comment, par qui et dans quel délai l’organisation compte agir.
Non. Le rapport permet d’identifier et de documenter des écarts, mais il ne suffit pas à démontrer la conformité globale. Une démarche ISO 27001 implique notamment un système de management, une analyse des risques, des objectifs, des responsabilités et un cycle d’amélioration. Pour NIS2, les exigences applicables dépendent également du cadre national, de l’entité et de son secteur. Le rapport constitue un point de départ et un outil de pilotage.
Pas nécessairement. Les preuves peuvent contenir des informations sensibles, des données personnelles ou des configurations de sécurité. Le rapport peut référencer un index précisant l’intitulé, la date, la mesure concernée, la localisation et l’observation associée. L’accès aux documents sources doit être limité aux personnes autorisées. Cette approche conserve la traçabilité sans diffuser inutilement des informations sensibles dans chaque copie du rapport.
Découvrez comment centraliser les mesures évaluées, les scores, les preuves et les remédiations dans une restitution cohérente.
Voir un exemple de rapport d’audit généré depuis CompliKey
