Checklist de conformité SOC 2 pour les entreprises SaaS

La conformité SOC 2 est un effort en plusieurs phases — et les entreprises SaaS qui la traitent comme un projet structuré, plutôt qu’une course de dernière minute avant la saison d’audit, sont celles qui réussissent proprement et restent conformes année après année.

Cette checklist couvre le cycle de vie complet : des premières décisions de cadrage jusqu’à la finalisation de l’audit et le maintien de la conformité continue. Chaque section renvoie à un guide détaillé où vous pourrez approfondir des sujets spécifiques. Que vous visiez votre premier rapport SOC 2 ou que vous affiniez la préparation de votre prochain cycle d’audit, utilisez cette checklist comme feuille de route opérationnelle.

Si vous êtes totalement nouveau dans le SOC 2, commencez par notre guide Qu’est-ce que le SOC 2 ? pour les concepts fondamentaux avant de parcourir cette checklist.

Phase 1 : Cadrage et planification

Les décisions que vous prenez lors du cadrage définissent le coût, le calendrier et la complexité de tout ce qui suit. Réussir cette phase rend le reste du processus considérablement plus gérable.

Définir les Critères de service de confiance à inclure

Chaque rapport SOC 2 doit inclure le critère Sécurité (également appelé Common Criteria). Les quatre critères restants — Disponibilité, Intégrité du traitement, Confidentialité et Vie privée — sont optionnels et doivent être sélectionnés en fonction des exigences de vos clients et de la nature de votre service.

En pratique : La plupart des entreprises SaaS B2B commencent par la Sécurité et la Disponibilité. Si votre produit traite des données sensibles avec des contrôles d’accès stricts, ajoutez la Confidentialité. Si vous traitez des données personnelles à grande échelle et souhaitez démontrer l’alignement avec le RGPD, incluez la Vie privée.

N’incluez pas de critères « au cas où ». Chaque critère supplémentaire ajoute des contrôles, des exigences de preuves et du périmètre d’audit. Incluez ce que vos clients demandent et ce qui est véritablement pertinent pour votre service.

Consultez notre analyse détaillée : Les Critères de service de confiance SOC 2 expliqués

Choisir entre Type I et Type II

Le Type I évalue la conception de vos contrôles à un moment donné. Le Type II évalue la conception et l’efficacité opérationnelle sur une période (généralement 6 à 12 mois). Les clients des grandes entreprises préfèrent fortement le Type II car il démontre un fonctionnement soutenu des contrôles, et non un simple instantané.

Exemple SaaS : Une startup de série A concluant son premier contrat avec une grande entreprise pourrait viser un Type I pour débloquer la vente, puis passer au Type II dans les 12 mois suivants. Une entreprise de série B avec une base clients établie devrait aller directement au Type II.

Consultez notre comparaison : SOC 2 Type I vs. Type II : lequel choisir ?

Définir le budget et le calendrier

Les coûts du SOC 2 varient considérablement en fonction de la taille de votre entreprise, du périmètre de l’audit et de l’utilisation d’une plateforme de conformité ou de consultants. Les seuls honoraires de l’auditeur se situent généralement entre 20 000 et 80 000 $ pour un engagement Type II. Ajoutez les outils, les coûts de remédiation et le temps interne de l’ingénierie, et les coûts totaux de la première année pour une entreprise SaaS en phase de croissance se situent souvent entre 50 000 et 150 000 $.

Estimation du calendrier : Un rapport Type I peut être réalisé en 2 à 4 mois si vos contrôles fondamentaux sont en place. Un rapport Type II nécessite une période d’observation de 6 à 12 mois après la mise en place des contrôles, ce qui signifie que vous devriez commencer 9 à 15 mois avant d’avoir besoin du rapport.

Consultez notre analyse détaillée : Coûts et calendrier SOC 2 pour les entreprises SaaS

Sélectionner un auditeur

Seul un cabinet d’expertise comptable agréé (CPA) peut émettre un rapport SOC 2. Choisissez un cabinet ayant une expérience démontrable dans le SaaS — des auditeurs qui comprennent l’infrastructure cloud, les pipelines CI/CD et l’infrastructure en tant que code poseront des questions pertinentes et ne feront pas perdre de temps à votre équipe avec des contrôles conçus pour des environnements sur site.

Ce qu’il faut évaluer :

• Expérience dans l’audit d’entreprises SaaS de votre taille et de votre stade de développement
• Familiarité avec votre pile technologique (AWS/GCP/Azure, Kubernetes, etc.)
• Style de communication et réactivité pendant l’engagement
• Transparence des prix — attention aux frais cachés liés aux retests de remédiation
• Références d’autres entreprises SaaS qu’ils ont auditées

Définir les limites du système

Les limites du système définissent ce qui est dans le périmètre de votre audit SOC 2. Cela inclut l’infrastructure, les logiciels, les personnes, les procédures et les données liées au service que vous évaluez.

En pratique : Pour une application SaaS typique, les limites du système incluent votre environnement de production, le pipeline CI/CD qui y déploie, les systèmes de surveillance et d’alerte, les personnes qui y accèdent et les politiques qui régissent leur comportement. Les environnements de développement et de test sont généralement exclus, sauf s’ils contiennent des données clients.

Soyez précis. Des limites trop larges signifient plus de contrôles, plus de preuves et plus de coûts. Des limites trop étroites signifient que votre rapport ne couvrira pas ce qui intéresse réellement les clients.

Phase 2 : Évaluation des risques et analyse des écarts

Avant de mettre en place des contrôles, vous devez comprendre votre état actuel : quels risques existent, quels contrôles sont déjà en place et où sont les lacunes.

Réaliser une évaluation formelle des risques

Une évaluation des risques SOC 2 identifie les menaces pesant sur votre système, évalue leur probabilité et leur impact, et documente la manière dont vous les atténuez. Ce n’est pas un exercice théorique — c’est le socle sur lequel vos contrôles sont construits, et votre auditeur l’examinera.

Ce qu’il faut évaluer :

• Menaces externes : tentatives d’accès non autorisé, attaques DDoS, compromissions de la chaîne d’approvisionnement, ingénierie sociale
• Menaces internes : erreurs des employés, menaces internes, erreurs de configuration, contrôles d’accès inadéquats
• Menaces environnementales : pannes du fournisseur cloud, catastrophes naturelles affectant la disponibilité, défaillances de services tiers
• Menaces de conformité : changements réglementaires, exigences contractuelles des clients, obligations de résidence des données

Exemple SaaS : Votre évaluation des risques identifie que les ingénieurs ont un accès permanent aux bases de données de production contenant des données clients. Le risque : les identifiants compromis d’un ingénieur pourraient exposer des données clients. L’atténuation : mettre en place un accès juste-à-temps avec des workflows d’approbation et une journalisation des sessions.

Consultez notre processus étape par étape : Guide d’évaluation des risques SOC 2

Identifier les écarts par rapport aux Common Criteria SOC 2

Cartographiez vos contrôles existants par rapport aux Common Criteria SOC 2 (les points de contrôle de la série CC). Cette analyse des écarts vous indique exactement ce que vous devez construire, formaliser ou documenter avant l’audit.

Écarts courants découverts par les entreprises SaaS :

• Les politiques existent de manière informelle mais ne sont pas documentées
• Les revues d’accès se font de manière ponctuelle mais ne sont pas planifiées et journalisées
• Les procédures de réponse aux incidents existent dans la tête de quelqu’un mais pas dans un runbook
• Les évaluations des risques fournisseurs sont effectuées lors de l’intégration mais jamais revisitées
• La gestion des changements existe dans les workflows de pull requests mais n’est pas formellement documentée comme un contrôle

Prioriser la remédiation en fonction du niveau de risque

Toutes les lacunes n’ont pas le même poids. Priorisez en fonction du niveau de risque (selon votre évaluation des risques) et de la criticité pour l’audit (si la lacune entraînerait un avis avec réserve).

En pratique : L’absence d’une politique de sécurité de l’information est une lacune critique — elle sous-tend plusieurs domaines de contrôle et votre auditeur la signalera immédiatement. L’absence d’une revue annuelle de votre politique d’utilisation acceptable est importante mais de priorité moindre. Construisez un plan de remédiation avec des responsables, des échéances et un suivi de l’état d’avancement.

Phase 3 : Politiques et contrôles

C’est ici que la conformité passe de la planification à la mise en œuvre. Vos politiques définissent ce que vous vous engagez à faire. Vos contrôles sont les mécanismes qui appliquent ces engagements.

Rédiger les politiques requises

Le SOC 2 exige des politiques documentées dans de multiples domaines. Votre auditeur examinera ces politiques, testera si votre équipe les suit et évaluera si elles sont correctement revues et mises à jour.

Politiques essentielles dont vous aurez besoin :

• Politique de sécurité de l’information
• Politique de contrôle des accès
• Politique de gestion des changements
• Politique de réponse aux incidents
• Politique d’évaluation des risques
• Politique de gestion des fournisseurs
• Politique de classification et de traitement des données
• Politique de continuité d’activité et de reprise après sinistre
• Politique d’utilisation acceptable
• Politique de sécurité des ressources humaines (couvrant l’intégration, le départ, les vérifications d’antécédents)

Ce qui fait une bonne politique : Elle doit être suffisamment spécifique pour être actionnable, suffisamment réaliste pour être suivie et révisée au moins annuellement. Les politiques qui disent « nous utilisons les meilleures pratiques de l’industrie » sont inutiles — précisez ce que vous faites réellement.

Consultez notre guide détaillé : Guide des politiques et procédures SOC 2

Mettre en place des contrôles de sécurité alignés sur les Common Criteria

Les contrôles sont les mécanismes opérationnels qui appliquent vos politiques. Pour le SOC 2, ces contrôles doivent être rattachés aux Common Criteria et à tout Critère de service de confiance supplémentaire que vous avez inclus.

Domaines de contrôle clés pour les entreprises SaaS :

• Contrôles d’accès logiques : SSO avec MFA pour tous les systèmes de production, accès basé sur les rôles, revues d’accès trimestrielles, déprovisionnement automatique à la fin de contrat
• Sécurité réseau : Règles de pare-feu, segmentation réseau, détection/prévention des intrusions, protection DDoS, VPN ou accès zero-trust pour les outils internes
• Gestion des changements : Revues de pull requests, tests automatisés dans le CI/CD, workflows d’approbation des déploiements, procédures de rollback
• Protection des données : Chiffrement au repos (AES-256) et en transit (TLS 1.2+), gestion des clés, classification des données, suppression sécurisée
• Surveillance et alertes : Journalisation centralisée, SIEM ou agrégation de logs, alertes sur les événements de sécurité, rétention des logs pour la période d’audit

Mettre en place un programme de gestion des fournisseurs

Votre périmètre SOC 2 ne s’arrête pas aux frontières de votre entreprise. Les services tiers qui traitent, stockent ou transmettent des données relevant de votre rapport doivent être évalués et surveillés.

Ce qu’il faut documenter pour chaque fournisseur :

• Quelles données ils accèdent ou traitent
• Le statut de leur rapport SOC 2 (ou certifications de sécurité équivalentes)
• Les conditions contractuelles de protection des données
• Les résultats de votre évaluation des risques du fournisseur
• La cadence de revue et la date de la dernière revue

Exemple SaaS : Votre application utilise Stripe pour les paiements, AWS pour l’infrastructure, Datadog pour la surveillance et Slack pour les communications internes. Stripe, AWS et Datadog sont dans le périmètre car ils traitent ou ont accès aux données clients. Slack est probablement hors périmètre, sauf s’il est utilisé pour transmettre des données clients.

Consultez notre guide complet : Guide de gestion des fournisseurs SOC 2

Établir des procédures de réponse aux incidents

Votre capacité de réponse aux incidents est l’un des domaines les plus scrutés lors d’un audit SOC 2. Les auditeurs veulent voir un plan documenté, des rôles définis, des voies d’escalade claires et des preuves que vous avez testé le plan.

Votre plan de réponse aux incidents doit couvrir :

• Classification des incidents et niveaux de gravité
• Mécanismes de détection et d’alerte
• Rôles de l’équipe de réponse et coordonnées
• Procédures de confinement, d’éradication et de reprise
• Protocoles de communication (internes, orientés client, réglementaires)
• Processus de revue post-incident
• Exigences de préservation des preuves

En pratique : Lorsqu’une alerte de sécurité se déclenche à 2 heures du matin, votre ingénieur d’astreinte doit savoir exactement où se trouve le runbook, à qui escalader, quelles décisions il est autorisé à prendre et comment documenter ses actions. Si votre plan de réponse aux incidents ne fonctionne que pendant les heures de bureau, il ne fonctionne pas.

Consultez notre guide détaillé : Guide de réponse aux incidents SOC 2

Phase 4 : Collecte de preuves et surveillance

Des contrôles sans preuves sont des contrôles que votre auditeur ne peut pas vérifier. Cette phase consiste à prouver — de manière systématique et continue — que vos contrôles fonctionnent comme prévu.

Mettre en place des processus de collecte de preuves

Les auditeurs SOC 2 ont besoin de preuves que vos contrôles ont fonctionné efficacement tout au long de la période d’audit (pour le Type II). Cela signifie que vous devez collecter et conserver les preuves en continu, et non les rassembler rétroactivement.

Types de preuves que votre auditeur demandera :

• Preuves de configuration : Captures d’écran ou exports montrant les configurations système (MFA activé, paramètres de chiffrement, règles de pare-feu, listes de contrôle d’accès)
• Preuves de processus : Enregistrements des revues d’accès, approbations de changements, réponses aux incidents, évaluations des fournisseurs
• Preuves automatisées : Logs du SIEM, pistes d’audit du fournisseur cloud, enregistrements du pipeline CI/CD, logs de déploiement
• Preuves humaines : Enregistrements de formation complétée, accusés de réception des politiques, confirmations de vérification d’antécédents

Exemple SaaS : Votre auditeur demande des preuves que tous les changements en production passent par une revue de code. Au lieu de vous précipiter pour extraire les données de PR GitHub, votre plateforme de conformité capture automatiquement les métadonnées des pull requests — réviseur, horodatage d’approbation, horodatage de fusion — et les stocke comme preuves prêtes pour l’audit.

Consultez notre guide détaillé : Guide de collecte de preuves SOC 2

Mettre en place une surveillance continue

La surveillance continue signifie que vos contrôles sont validés de façon permanente — pas seulement pendant la préparation de l’audit. Cela permet de détecter les défaillances des contrôles tôt et vous donne le temps de remédier avant l’arrivée de l’auditeur.

Ce qu’il faut surveiller en continu :

• Efficacité des contrôles d’accès (les employés ayant quitté l’entreprise sont-ils réellement déprovisionnés ?)
• Dérive de configuration (quelqu’un a-t-il désactivé le MFA sur un compte de service ?)
• Gestion des vulnérabilités (les correctifs critiques sont-ils appliqués dans le délai de votre SLA ?)
• Métriques de disponibilité (respectez-vous vos engagements de temps de fonctionnement ?)
• Respect de la gestion des changements (tous les changements en production passent-ils par le processus défini ?)

Consultez notre guide de mise en œuvre : Guide de surveillance continue SOC 2

Effectuer une évaluation interne de préparation

Avant d’engager votre auditeur, réalisez une évaluation interne de préparation. Passez en revue chaque contrôle, vérifiez que les preuves existent et identifiez les lacunes restantes.

En pratique : Assignez un responsable pour chaque contrôle SOC 2. Demandez à chaque responsable de vérifier que son contrôle fonctionne, que les preuves sont collectées et que la documentation est à jour. Toute lacune découverte maintenant est une lacune que vous pouvez corriger avant que le chronomètre de l’audit ne commence.

Phase 5 : L’audit

L’audit lui-même est un engagement structuré avec votre cabinet CPA. La préparation détermine s’il se déroule sans accroc ou sous tension.

Se préparer au processus d’audit

Votre auditeur commencera par une phase de planification — comprendre votre système, examiner votre description du système et identifier les contrôles qu’il testera. Venez préparé avec un référentiel de preuves propre et organisé et des points de contact désignés pour chaque domaine de contrôle.

Checklist de préparation :

• Document de description du système (décrivant votre service, votre infrastructure et votre environnement de contrôle)
• Liste complète des contrôles mappés aux critères SOC 2
• Référentiel de preuves organisé par contrôle
• Contacts désignés pour chaque domaine de contrôle
• Disponibilité calendaire pour les sessions de l’auditeur

Consultez notre parcours détaillé : Processus d’audit SOC 2 : à quoi s’attendre

Accompagner les sessions et tests de l’auditeur

Pendant l’audit, l’auditeur testera vos contrôles par une combinaison d’enquête (demander à votre équipe comment les choses fonctionnent), d’observation (observer les processus en action), d’inspection (examiner les preuves et la documentation) et de ré-exécution (ré-exécuter un contrôle pour vérifier qu’il fonctionne).

Exemple SaaS : L’auditeur teste votre contrôle d’accès en sélectionnant un échantillon d’employés ayant quitté l’entreprise et en vérifiant que leur accès a été révoqué dans le délai spécifié par votre politique. Il vérifiera Active Directory, AWS IAM, GitHub et tout autre système où ces employés avaient un accès.

Traiter les constatations éventuelles

Si l’auditeur identifie des déficiences de contrôle, vous aurez l’occasion d’en discuter. Les problèmes mineurs peuvent être notés comme des observations dans le rapport sans affecter l’avis. Les déficiences significatives ou les faiblesses matérielles peuvent entraîner un avis avec réserve — ce qui annule l’intérêt du rapport.

En pratique : Si l’auditeur constate que 2 revues d’accès sur 25 échantillonnées ont été réalisées en retard, c’est probablement une observation. S’il constate que 15 sur 25 n’ont jamais été réalisées, c’est une déficience significative. La différence entre ces résultats réside dans la rigueur de votre programme de conformité continu.

Recevoir votre rapport SOC 2

Le livrable final est un rapport SOC 2 contenant l’avis de l’auditeur, votre description du système, une description de vos contrôles, les résultats des tests de l’auditeur et toute exception notée. Ce rapport est ce que vous partagez avec les clients et prospects sous NDA.

Phase 6 : Conformité continue

Un rapport SOC 2 a une durée de vie. Les clients des grandes entreprises attendent des rapports récents, et vos contrôles doivent fonctionner en permanence — pas uniquement pendant la fenêtre d’audit.

Maintenir la surveillance continue

Les contrôles que vous avez mis en place pour l’audit doivent continuer à fonctionner. Les tableaux de bord de surveillance, la collecte automatisée de preuves et les revues régulières doivent faire partie de vos opérations normales, et non des activités réservées à la saison d’audit.

Re-certification annuelle

Les rapports Type II sont généralement émis annuellement. Votre période d’audit doit couvrir les 12 mois depuis votre dernier rapport, sans interruption. Commencez à planifier chaque cycle d’audit 2 à 3 mois avant la fin de la période d’observation pour assurer des transitions fluides.

Conseil de calendrier : Si votre premier rapport Type II couvre janvier à juin, votre prochain rapport devrait couvrir juillet à juin de l’année suivante. Les interruptions entre les périodes d’observation soulèvent des questions de la part des clients qui examinent votre rapport.

Gérer les changements

Les entreprises SaaS changent constamment — nouveaux fournisseurs, nouvelle infrastructure, nouveaux membres d’équipe, nouvelles fonctionnalités. Chaque changement peut affecter votre environnement de contrôle SOC 2.

Changements nécessitant une réévaluation :

• Ajout d’un nouveau fournisseur tiers traitant des données dans le périmètre
• Migration vers un nouveau fournisseur cloud ou une nouvelle région
• Changements significatifs dans l’architecture de votre application
• Changements organisationnels (acquisitions, restructurations, départs de personnel clé)
• Nouvelles exigences réglementaires de la part des clients ou des marchés
• Expansion dans des secteurs avec des besoins de conformité spécifiques (santé, finance)

Mettez en place un processus léger d’évaluation des changements : lorsqu’un changement important survient, évaluez son impact sur vos contrôles SOC 2 et mettez à jour votre documentation en conséquence. Votre auditeur vous interrogera sur les changements significatifs lors du prochain audit, et disposer d’évaluations documentées démontre votre maturité.

Erreurs courantes des équipes SaaS

Commencer trop tard. L’erreur numéro un est de commencer la préparation SOC 2 3 mois avant d’avoir besoin du rapport. Un rapport Type II nécessite une période d’observation de 6 à 12 mois. Ajoutez 2 à 4 mois de préparation avant le début de cette période. Si un client a besoin de votre rapport SOC 2 l’année prochaine, commencez maintenant.

Traiter la conformité comme le problème de l’équipe sécurité. Le SOC 2 touche l’ingénierie (gestion des changements, contrôles d’accès, revue de code), les RH (intégration, départ, vérifications d’antécédents) et les opérations (gestion des fournisseurs, continuité d’activité). Chaque équipe qui opère un contrôle est responsable de ce contrôle.

Collecter les preuves manuellement. Passer 40 heures à faire des captures d’écran et exporter des logs avant chaque audit est le signe que votre collecte de preuves n’est pas automatisée. Investissez dans des outils qui capturent les preuves en continu — l’investissement est rentabilisé dès le premier cycle d’audit.

Rédiger des politiques que personne ne suit. Les auditeurs testent si votre équipe suit réellement les politiques documentées. Une politique de sécurité de l’information de 30 pages qu’aucun ingénieur n’a lue est pire qu’une politique de 3 pages qui reflète ce que votre équipe fait réellement. Rédigez des politiques qui décrivent les pratiques réelles, puis faites-les respecter.

Ignorer la conformité des fournisseurs. Si un fournisseur critique ne dispose pas de son propre rapport SOC 2, votre auditeur voudra voir comment vous avez évalué et géré ce risque. « Nous leur faisons confiance parce que c’est une grande entreprise » n’est pas une évaluation des risques.

Comment GRCTrail vous aide

GRCTrail est conçu pour les équipes SaaS gérant la conformité SOC 2 — de la première préparation aux audits annuels continus.

• Évaluation de préparation SOC 2 qui cartographie votre état actuel par rapport à chaque point de contrôle des Common Criteria et génère un plan de remédiation priorisé
• Bibliothèque de modèles de politiques avec des politiques spécifiques au SOC 2 rédigées pour les entreprises SaaS, prêtes à être personnalisées et diffusées à votre équipe
• Collecte automatisée de preuves s’intégrant avec AWS, GCP, Azure, GitHub, GitLab, Okta, Google Workspace et d’autres outils de votre pile
• Tableaux de bord de surveillance continue qui suivent l’efficacité des contrôles en temps réel et vous alertent lorsque les contrôles dérivent hors conformité
• Cadre d’évaluation des risques avec des workflows structurés pour identifier, évaluer et atténuer les risques par rapport aux critères SOC 2
• Module de gestion des fournisseurs pour suivre la posture de sécurité des tiers, le statut des rapports SOC 2 et les calendriers de revue
• Suivi de la réponse aux incidents avec des workflows intégrés pour la classification, la réponse et la documentation de la revue post-incident
• Dossiers de preuves prêts pour l’audit qui organisent vos preuves par contrôle et critère, exportables dans les formats attendus par votre auditeur

Découvrez comment GRCTrail simplifie la conformité SOC 2 →

Commencez avec GRCTrail →

Guides connexes

• Qu’est-ce que le SOC 2 ? Guide pratique pour les entreprises SaaS
• Les Critères de service de confiance SOC 2 expliqués
• SOC 2 Type I vs. Type II : lequel choisir ?
• Les Common Criteria SOC 2 expliqués
• Processus d’audit SOC 2 : à quoi s’attendre
• Guide des politiques et procédures SOC 2
• Guide de gestion des fournisseurs SOC 2
• Guide de collecte de preuves SOC 2
• Guide d’évaluation des risques SOC 2
• Guide de réponse aux incidents SOC 2
• Guide de surveillance continue SOC 2
• Coûts et calendrier SOC 2 pour les entreprises SaaS
• Checklist de conformité RGPD pour les entreprises SaaS
• Accords de traitement des données (DPA) dans le cadre du RGPD