Collecte de preuves SOC 2 : ce que les auditeurs recherchent réellement

La collecte de preuves est le moment où la conformité SOC 2 devient concrète. Vos politiques décrivent ce que vous vous engagez à faire. Vos contrôles sont les mécanismes qui appliquent ces engagements. Les preuves sont la démonstration que ces contrôles ont réellement fonctionné — de manière cohérente, sur l’ensemble de votre période d’observation.

Pour un rapport SOC 2 Type I, les preuves démontrent que les contrôles sont correctement conçus à un moment donné. Pour un rapport Type II, l’exigence est plus élevée : les preuves doivent démontrer que les contrôles ont fonctionné efficacement sur une période soutenue — généralement de 6 à 12 mois. Chaque mois de cette fenêtre compte. Une seule lacune dans les preuves peut entraîner un avis avec réserve ou une exception dans votre rapport que les clients institutionnels scruteront.

Les entreprises SaaS qui traitent la collecte de preuves comme une course de dernière minute avant la saison d’audit se retrouvent avec des enregistrements incomplets, des équipes paniquées et des rapports retardés. Les entreprises qui intègrent la collecte de preuves dans leurs opérations quotidiennes constatent que l’audit lui-même devient un exercice simple. Ce guide couvre exactement quelles preuves les auditeurs demandent, organisées par domaine de contrôle, et comment construire un système de collecte qui rend le SOC 2 durable.

Types de preuves SOC 2

Avant de plonger dans les domaines de contrôle spécifiques, comprenez les catégories de preuves avec lesquelles les auditeurs travaillent. Différents contrôles nécessitent différents types de démonstration.

Captures d’écran. Captures ponctuelles des configurations système, paramètres de sécurité et vues de tableaux de bord. Les captures d’écran sont utiles pour démontrer qu’un paramètre est activé (application du MFA, configuration du chiffrement, règles de pare-feu), mais elles ne prouvent l’état qu’au moment de la capture. Pour les audits Type II, vous pouvez avoir besoin de captures d’écran à plusieurs moments de la période d’observation.

En pratique : Incluez toujours la barre d’URL du navigateur, un horodatage et suffisamment de contexte pour identifier le système. Une capture d’écran d’une page de configuration MFA est utile. Une capture recadrée d’un interrupteur sans identification du système ne l’est pas.

Logs. Enregistrements générés par le système des événements : logs d’accès, logs de changements, pistes d’audit, logs d’authentification. Les logs sont la forme de preuve la plus solide car ils sont générés automatiquement et difficiles à falsifier. Les auditeurs préfèrent les logs aux enregistrements manuels car ils représentent ce qui s’est réellement passé, pas ce dont quelqu’un se souvient.

En pratique : Assurez-vous que la rétention des logs couvre la totalité de votre période d’observation plus une marge. Si votre période d’observation va de janvier à décembre et que vos logs sont supprimés après 90 jours, vous perdrez les preuves des neuf premiers mois.

Tickets. Enregistrements de suivi des incidents dans des systèmes comme Jira, Linear ou ServiceNow. Les tickets fournissent des preuves de gestion des changements (modifications de code passant par des workflows d’approbation), de traitement des incidents (délais de réponse et résolution) et de gestion des accès (demandes de provisionnement et de déprovisionnement).

En pratique : Les tickets ne sont utiles que s’ils contiennent les bonnes métadonnées : horodatages, responsables, enregistrements d’approbation, transitions de statut et artefacts liés. Un ticket qui dit « Déployer mise à jour » sans enregistrement de revue ou d’approbation ne démontre pas la gestion des changements.

Rapports. Résultats formels des outils et processus de sécurité : résultats d’analyses de vulnérabilités, rapports de tests d’intrusion, résumés de revues d’accès, documents d’évaluation des risques. Les rapports démontrent généralement des activités de contrôle périodiques.

En pratique : Les rapports doivent être datés, attribués à la personne ou l’outil qui les a générés et montrer des conclusions claires et des actions de remédiation. Un rapport d’analyse de vulnérabilités listant 47 constatations critiques sans preuve de travail de remédiation est pire que pas de rapport du tout — il prouve que vous avez identifié des risques et n’avez rien fait.

Documents. Politiques signées, enregistrements de formation, procès-verbaux de réunions, assertions de la direction. Les documents démontrent des activités de gouvernance qui ne produisent pas nécessairement de preuves générées par le système.

En pratique : Les documents ont besoin de dates, de signatures ou d’approbations et d’informations de version. Les procès-verbaux de réunion doivent inclure les participants, les sujets discutés et les décisions prises — pas seulement « réunion de revue sécurité » sans contenu.

Configurations. Modèles d’Infrastructure-as-Code, configurations de pipeline CI/CD, règles de pare-feu, ACL réseau. Pour les entreprises SaaS gérant l’infrastructure par le code, ces configurations sont des preuves puissantes car elles sont versionnées et auditables.

En pratique : Orientez les auditeurs vers votre dépôt IaC avec des hash de commit spécifiques. Une configuration Terraform imposant le chiffrement sur tous les buckets S3, enregistrée dans Git avec un historique de revue, est une preuve plus propre qu’une capture d’écran de la console AWS.

Attestations. Accusés de réception signés, assertions de la direction et déclarations formelles. Celles-ci sont utilisées lorsque des preuves automatisées ne sont pas disponibles — par exemple, les accusés de réception de politiques par les employés ou l’assertion de la direction sur la complétude de la description du système.

En pratique : Les attestations doivent être signées et datées. Les signatures numériques (DocuSign, systèmes d’accusé de réception internes) sont acceptables et préférées aux signatures physiques car elles incluent des horodatages inviolables.

Preuves par domaine de contrôle

Les auditeurs SOC 2 organisent leurs demandes de preuves autour des catégories Common Criteria. Voici ce qu’ils attendent pour chaque domaine majeur, avec des exemples spécifiques pertinents pour les entreprises SaaS.

Contrôles d’accès (CC6)

Le contrôle d’accès est le domaine le plus intensif en preuves d’un audit SOC 2. Les auditeurs testent le cycle de vie complet de l’accès utilisateur — provisionnement, gestion continue et déprovisionnement — et ils échantillonneront largement.

Listes d’accès utilisateurs avec rôles. Fournissez les listes d’accès actuelles pour tous les systèmes dans le périmètre, montrant le rôle de chaque utilisateur, ses permissions et la date d’attribution de l’accès. Les auditeurs les croiseront avec votre annuaire d’employés et vos dossiers RH.

Exemple SaaS : Exportez les listes d’utilisateurs depuis AWS IAM, Okta, GitHub et votre base de données de production montrant les noms d’utilisateur, les rôles attribués, les appartenances aux groupes et les dates de dernière connexion.

Preuves d’application du MFA. Prouvez que l’authentification multi-facteurs est imposée — pas seulement disponible — pour tous les systèmes requis. Captures d’écran de configuration montrant que le MFA est obligatoire, plus des logs d’authentification montrant les vérifications MFA lors des événements de connexion.

Revues d’accès trimestrielles avec remédiation. C’est là que beaucoup d’entreprises SaaS trébuchent. Les auditeurs veulent voir quatre revues d’accès complétées pendant une période d’observation de 12 mois, chacune montrant le réviseur, les systèmes examinés, les écarts trouvés et la remédiation effectuée.

Tickets d’intégration et de départ. Fournissez des tickets montrant que le provisionnement des accès suit votre procédure documentée et que les employés ayant quitté l’entreprise sont déprovisionnés dans le délai spécifié par votre politique.

Logs d’accès privilégié. Fournissez des logs d’audit pour les comptes privilégiés — accès root, comptes administrateur de base de données, rôles administrateur d’infrastructure. Les auditeurs veulent voir qui a utilisé un accès privilégié, quand et dans quel but.

Gestion des changements (CC8)

Les preuves de gestion des changements démontrent que vos processus de développement et de déploiement suivent vos procédures documentées. Pour les entreprises SaaS livrant du code fréquemment, ce domaine devrait produire des preuves automatisées abondantes.

Historique des pull requests avec revues de code. Les auditeurs échantillonneront des pull requests de toute la période d’observation et vérifieront que les revues de code ont eu lieu avant la fusion. Ils vérifieront les approbations des réviseurs, les commentaires de revue et que le réviseur est quelqu’un d’autre que l’auteur.

Logs de déploiement. Fournissez des enregistrements des déploiements en production montrant ce qui a été déployé, quand, par qui et via quel mécanisme. Les auditeurs veulent voir que les déploiements ont suivi votre pipeline CI/CD, pas un accès SSH manuel aux serveurs de production.

Workflows d’approbation des changements. Pour les changements nécessitant une approbation explicite au-delà de la revue de code — changements d’infrastructure, migrations de bases de données, modifications de configuration — fournissez les enregistrements d’approbation.

Procédures de rollback testées. Preuve que vous avez testé votre capacité à annuler un déploiement échoué.

Documentation des changements d’urgence. Si des changements d’urgence ont eu lieu pendant la période d’observation (correctifs déployés sans revue standard), fournissez les tickets de changement d’urgence montrant la justification, le changement lui-même et la revue et approbation rétrospectives dans le délai de votre politique.

Opérations système (CC7)

Les preuves des opérations système couvrent la surveillance, la gestion des incidents, la gestion des vulnérabilités et la santé opérationnelle.

Tableaux de bord de surveillance et configurations d’alertes. Montrez que la surveillance est configurée pour les systèmes critiques et que les alertes sont acheminées vers les bonnes personnes.

Tickets d’incident avec délais de réponse. Pour chaque incident pendant la période d’observation, fournissez le ticket montrant le temps de détection, le démarrage de la réponse, les actions de confinement, la résolution et la finalisation du post-mortem. Les horodatages comptent — les auditeurs mesureront votre réponse par rapport aux SLA définis dans votre politique de réponse aux incidents.

Résultats d’analyses de vulnérabilités et tickets de remédiation. Fournissez les résultats d’analyse de vos outils d’analyse de vulnérabilités à intervalles réguliers sur la période d’observation, plus les tickets montrant que les vulnérabilités identifiées ont été remédiées dans le SLA de votre politique.

Rapports de tests d’intrusion. Au moins un test d’intrusion pendant la période d’observation, réalisé par un tiers qualifié.

Enregistrements de gestion des correctifs. Preuve que les systèmes d’exploitation, les frameworks et les dépendances sont maintenus à jour.

Évaluation des risques (CC3)

Les preuves d’évaluation des risques démontrent que votre organisation identifie, évalue et traite systématiquement les risques. Ce domaine est lié à votre politique d’évaluation des risques et alimente plusieurs autres domaines de contrôle.

Document formel d’évaluation des risques. Une évaluation des risques complétée et datée dans la période d’observation, suivant votre méthodologie documentée.

Registre des risques avec plans de traitement. Un document vivant montrant les risques identifiés, leur statut actuel, les propriétaires assignés et les actions de traitement.

Procès-verbaux de réunions de revue des risques. Preuve que les risques sont discutés au niveau de la gouvernance.

Évaluations des risques fournisseurs. Évaluations des risques pour vos fournisseurs critiques et à haut risque, démontrant que le risque tiers est intégré dans votre programme global de gestion des risques. Pour plus de détails, consultez notre guide de gestion des fournisseurs.

Communication (CC2)

Les preuves de communication démontrent que les attentes de sécurité sont établies et communiquées à toutes les parties concernées.

Enregistrements de formation à la sensibilisation à la sécurité. Fournissez des enregistrements montrant que tous les employés ont complété la formation à la sensibilisation à la sécurité dans le délai de votre politique.

Signatures d’accusé de réception des politiques. Enregistrements des employés accusant réception et compréhension des politiques clés.

Rapports de sécurité au conseil ou à la direction. Preuve que la posture de sécurité est communiquée à la direction.

Engagements de sécurité externes. Votre page de sécurité publique, vos SLA avec des dispositions de sécurité et toute certification de sécurité externe que vous communiquez aux clients.

Construire un système de collecte de preuves

Collecter les preuves manuellement n’est pas durable. Les entreprises SaaS qui s’appuient sur des tableurs et des sprints trimestriels de collecte de preuves épuisent leurs équipes de conformité et produisent des enregistrements incomplets. Voici comment construire un système qui fonctionne.

Automatisez autant que possible. Chaque outil de votre pile a une API. L’API de GitHub fournit les données de pull request et de revue de code. AWS CloudTrail fournit les logs d’accès et de changement. Okta fournit les événements d’authentification et de provisionnement. Jira fournit l’historique des tickets. Construisez des intégrations — ou utilisez une plateforme de conformité — qui récupère les preuves automatiquement selon un calendrier.

Établissez une cadence de collecte. Toutes les preuves n’ont pas besoin d’une collecte quotidienne. Définissez la fréquence appropriée pour chaque type de preuve :

• Quotidien : Logs d’accès, logs de déploiement, événements de surveillance
• Hebdomadaire : Résultats d’analyses de vulnérabilités, mises à jour de statut des tickets
• Mensuel : Enregistrements de formation complétée, mises à jour d’accusés de réception de politiques
• Trimestriel : Revues d’accès, revues des fournisseurs, mises à jour du registre des risques
• Annuel : Rapports de tests d’intrusion, évaluations complètes des risques, revues des politiques

Centralisez le stockage des preuves. Toutes les preuves doivent être dans un seul système avec une organisation cohérente. Utilisez une structure de dossiers ou un système d’étiquetage organisé par catégorie Common Criteria et contrôle. Envisagez de connecter votre programme de preuves à vos workflows de surveillance continue afin que les lacunes soient détectées en temps réel.

Assignez des propriétaires de preuves. Chaque domaine de contrôle a besoin d’un propriétaire identifié responsable de s’assurer que les preuves sont collectées selon le calendrier.

Nommez de manière cohérente. Adoptez une convention de nommage qui inclut le type de preuve, le domaine de contrôle, la période et le système. Exemple : revue-acces_aws-iam_2026-T1.pdf.

Erreurs courantes liées aux preuves

Ces erreurs causent des retards d’audit, des constatations et, dans certains cas, des avis avec réserve. Évitez-les.

Lacunes dans la période d’observation. Si votre période d’observation va de janvier à décembre et que vous avez des preuves de revue d’accès pour T1, T2 et T4 mais pas T3, c’est une lacune. Les auditeurs ne peuvent pas supposer que le contrôle a fonctionné pendant les périodes sans preuves.

Captures d’écran sans horodatage ni contexte. Une capture d’écran d’un écran de configuration ne signifie rien sans le nom du système, l’URL, la date de capture et la personne qui l’a réalisée.

Preuves qui contredisent vos politiques. Votre politique dit que les revues d’accès ont lieu trimestriellement avec remédiation dans les 14 jours ouvrables. Vos preuves montrent une revue trimestrielle où un compte signalé n’a pas été supprimé pendant 45 jours. C’est une défaillance de contrôle — vous avez fourni des preuves contre vous-même.

Collecter les preuves au moment de l’audit au lieu de continuellement. Si vous essayez de rassembler un an de preuves dans les deux semaines avant votre audit, vous découvrirez que les logs ont été supprimés, les captures d’écran n’ont pas été prises et personne ne se souvient des détails d’un incident d’il y a huit mois.

Ne pas préserver les preuves des comptes d’employés ayant quitté l’entreprise. Lorsqu’un employé part, ses comptes sont déprovisionnés — correctement. Mais si cet employé était propriétaire de preuves ou effectuait des revues d’accès, ses enregistrements pourraient être perdus. Assurez-vous que les preuves générées par les individus sont stockées dans des systèmes partagés, pas dans des comptes personnels.

Surcollecte sans organisation. Déverser des centaines de fichiers dans un drive partagé sans convention de nommage, sans cartographie des contrôles ni attribution de date crée du travail pour les auditeurs et votre équipe. Plus de preuves n’est pas mieux que des preuves mieux organisées.

Travailler avec votre auditeur sur les preuves

La relation avec l’auditeur impacte directement la fluidité de la collecte de preuves. Investissez du temps en amont pour aligner les attentes. Pour un aperçu détaillé du cycle de vie complet de l’audit, consultez notre guide du processus d’audit.

Demandez la liste des demandes de preuves tôt. La plupart des cabinets d’audit fournissent une liste PBC (Prepared by Client) — un inventaire détaillé de chaque preuve dont ils auront besoin, organisé par domaine de contrôle. Obtenez cette liste le plus tôt possible, idéalement avant le début de votre période d’observation.

Convenez du format des preuves et des conventions de nommage. Demandez à votre auditeur comment il préfère recevoir les preuves. Certains cabinets utilisent des portails avec des structures de téléchargement spécifiques. D’autres acceptent des partages de dossiers organisés. Convenez des formats de fichiers — certains auditeurs préfèrent les PDF pour les documents et les CSV pour les exports de données.

Utilisez un portail partagé ou une structure de dossiers sécurisée. Évitez d’envoyer des fichiers de preuves par e-mail. Utilisez un mécanisme dédié de partage de preuves — le portail de votre auditeur, un drive sécurisé partagé ou la fonctionnalité d’accès auditeur de votre plateforme de conformité.

Répondez rapidement aux questions de suivi. Les auditeurs auront des questions de suivi. Répondez dans les 24 à 48 heures. Les réponses tardives prolongent le calendrier de l’audit et signalent un manque d’organisation.

Comment GRCTrail vous aide

GRCTrail transforme la collecte de preuves d’une course manuelle en un processus automatisé et continu qui maintient votre équipe SaaS prête pour l’audit tout au long de l’année.

• Collecte automatisée de preuves depuis vos outils existants — GitHub, AWS, Okta, Jira, et plus — récupérant les preuves de contrôle selon un calendrier sans intervention manuelle
• Preuves liées à des contrôles et critères spécifiques pour que chaque artefact collecté corresponde directement à la catégorie Common Criteria et au contrôle qu’il soutient, éliminant la question « quelle preuve va où »
• Dossiers de preuves prêts pour l’audit qui organisent vos preuves dans le format attendu par les auditeurs, avec un nommage cohérent, des métadonnées et une cartographie des contrôles pouvant être partagés directement avec votre cabinet d’audit
• Détection des lacunes de périodes de preuves manquantes vous alertant lorsque des preuves attendues n’ont pas été collectées — avant que votre auditeur ne découvre la lacune des mois plus tard pendant les travaux de terrain
• Collecte continue avec automatisation planifiée remplaçant les sprints trimestriels de collecte de preuves par un processus de collecte régulier et automatisé qui fonctionne tout au long de votre période d’observation

Commencez avec GRCTrail →

Guides connexes

• Qu’est-ce que le SOC 2 ? Guide pratique pour les entreprises SaaS
• Politiques et procédures SOC 2 : ce que vous devez documenter
• Gestion des fournisseurs SOC 2 : exigences en matière de risques tiers
• Guide de surveillance continue SOC 2