"Comment réussir SOC 2" est la question que posent la plupart des startups confrontées à cette démarche pour la première fois, et la réponse honnête commence par corriger la prémisse. SOC 2 n'est pas un examen avec une note de passage et ne produit pas de certificat. Un cabinet d'experts-comptables indépendant audite vos contrôles par rapport aux critères Trust Services de l'AICPA et émet un avis, un rapport écrit indiquant si les contrôles étaient bien conçus et, pour le type de rapport que la plupart des acheteurs demandent réellement, s'ils ont fonctionné efficacement sur une période d'observation. "Réussir" signifie que l'avis de l'auditeur est sans réserve : aucune exception assez grave pour le qualifier. Tout ce qui suit décrit le processus permettant à une startup d'obtenir cet avis sans réserve, et il repose principalement sur le périmètre et la discipline, et non sur une liste de modifications de code.
Type I versus Type II, et pourquoi le Type II est celui qui compte
Un rapport de Type I vérifie si vos contrôles sont bien conçus à une date donnée. Il répond à la question : "si ces contrôles fonctionnaient comme décrit, répondraient-ils aux critères ?", mais il ne dit rien sur leur efficacité réelle en pratique. Un rapport de Type II vérifie les mêmes contrôles pour leur efficacité opérationnelle sur une période d'observation, généralement trois mois pour un premier rapport et six à douze mois pour un renouvellement. Il répond à la question qui intéresse réellement les équipes de sécurité des acheteurs : les contrôles d'accès, la gestion des changements et la surveillance ont-ils tenu sur une période réelle, et pas seulement sur le papier.
La plupart des startups finissent par avoir besoin du Type II, car c'est ce que les services d'achats des entreprises et les questionnaires de sécurité des fournisseurs demandent de plus en plus explicitement. Le Type I conserve un rôle : il est plus rapide à produire (pas de période d'attente) et certaines startups l'utilisent comme premier livrable pour montrer leur avancée à un client entreprise précoce, tout en faisant courir la période d'observation du Type II en parallèle. Aucun des deux rapports n'est une certification et aucun n'a de note numérique ; le livrable est un rapport contenant votre description (celle de la direction) du système et des contrôles, votre assertion, les tests et résultats de l'auditeur pour un Type II, ainsi que l'avis de l'auditeur.
Définir le périmètre avant de construire le moindre contrôle : seule la Sécurité est obligatoire
SOC 2 est organisé autour de cinq catégories de services de confiance : Sécurité, Disponibilité, Confidentialité, Intégrité des traitements et Vie privée. La Sécurité, les Critères Communs (les critères numérotés CC, de CC1 à CC9), est la seule catégorie obligatoire ; chaque rapport SOC 2 l'inclut. Les quatre autres sont optionnelles, et une startup qui inclut par défaut les cinq catégories construit et documente généralement des contrôles que personne n'a demandés.
Définissez le périmètre en fonction de ce que les revues de sécurité de vos acheteurs demandent réellement, et non à partir d'un modèle. Une entreprise SaaS B2B inclut généralement la Sécurité, ainsi que la Disponibilité (vous vous engagez sur un temps de disponibilité) et la Confidentialité (vous traitez des données commerciales de clients sous une obligation similaire à un accord de confidentialité). L'Intégrité des traitements compte surtout si la fonction principale de votre système consiste à traiter des transactions où l'exhaustivité et l'exactitude de ce traitement constituent la promesse du produit, comme dans les paiements ou la facturation, et non simplement "nous avons une base de données". La Vie privée est la catégorie AICPA pour les engagements de traitement des informations personnelles dans votre propre politique de confidentialité, distincte du RGPD ou d'autres lois statutaires sur la protection des données ; la plupart des startups répondent aux attentes des acheteurs en matière de traitement des données personnelles sans ajouter cette catégorie. Interrogez vos premiers prospects entreprises sur les exigences de leur équipe de sécurité des fournisseurs avant de vous engager sur un périmètre ; il est bien moins coûteux d'ajouter une catégorie plus tard que de documenter une catégorie dont personne n'a besoin.
Le calendrier réaliste
La préparation vient en premier : une analyse des écarts par rapport aux critères que vous avez définis, la rédaction des politiques requises par ces critères (contrôle d'accès, gestion des changements, réponse aux incidents, etc.), et la résolution des lacunes de contrôle dans vos systèmes réels (application de la MFA, activation de la journalisation d'audit, formalisation d'une étape d'approbation des changements). Pour une petite startup utilisant une plateforme d'automatisation de la conformité pour suivre les preuves et les contrôles, la préparation prend généralement quatre à huit semaines ; plus longtemps si un contrôle doit être construit plutôt que simplement documenté, comme la mise en place d'une journalisation centralisée qui n'existait pas auparavant.
Pour un rapport de Type II, la période d'observation vient ensuite, et sa durée ne peut pas être raccourcie par le fournisseur : les contrôles doivent fonctionner pendant une période convenue avant que l'auditeur puisse les tester. Ainsi, une période de trois mois correspond à trois mois calendaires, et non à un ensemble de preuves assemblées a posteriori. Il n'existe pas de minimum statutaire universel ; la période est convenue avec votre cabinet d'experts-comptables et déterminée par les attentes des utilisateurs prévus du rapport. Les premiers rapports couvrent généralement trois à six mois, les renouvellements souvent six à douze mois. Pendant cette période, les contrôles dans le périmètre doivent fonctionner de manière cohérente : un écart peut devenir une exception échantillonnée en fonction des tests de l'auditeur, de sa nature, de sa fréquence et de son importance, mais pas automatiquement.
Le travail de terrain de l'audit suit la période d'observation : l'auditeur examine les preuves, échantillonne les transactions et les changements, interroge les responsables des contrôles et rédige les constats, généralement en deux à quatre semaines, puis émet le rapport final. Dans l'ensemble, le premier rapport de Type II d'une startup prend réalistement cinq à neuf mois du lancement à la réception du rapport, comme référence typique, et non comme exigence de l'AICPA. Méfiez-vous des promesses de "SOC 2 en un mois" : cela signifie généralement des travaux de préparation, un rapport de Type I, ou une période de reporting exceptionnellement courte acceptée par un auditeur spécifique, et non un Type II conventionnel de plusieurs mois.
Ce qui peut compromettre une période d'observation
La période d'observation est souvent source de mauvaises surprises pour les startups confrontées à SOC 2 pour la première fois, car elle est suffisamment longue pour que des travaux d'ingénierie normaux puissent discrètement annuler un contrôle que la phase de préparation venait de mettre en place. Une pull request d'une ligne qui élargit une politique IAM à un caractère générique par commodité, un nettoyage qui supprime la ligne de journal d'audit pour une action privilégiée, une correction urgente qui ignore l'étape habituelle d'approbation des changements sous la pression des délais : aucune de ces actions ne ressemble à un travail de conformité au moment où elles se produisent, et chacune est exactement le type de chose qui peut devenir une exception échantillonnée si elle est validée pendant la période d'observation et que les tests de l'auditeur la détectent. Les détails au niveau des contrôles sur les critères qui apparaissent réellement dans un diff, principalement la famille CC6 (accès logique) ainsi que CC7.2 (surveillance) et CC8.1 (gestion des changements), sont abordés dans l'analyse approfondie du cadre SOC 2 et le guide complémentaire sur ce que SOC 2 vérifie dans votre dépôt.
C'est à ce niveau qu'une vérification de conformité au niveau des pull requests intervient pendant la période d'observation : elle lit chaque changement par rapport aux critères que vous avez définis et identifie celui qu'il concerne, par exemple CC6.1 pour une politique IAM élargie, sous forme de commentaire de révision au moment où le changement est proposé. Si elle est détectée à ce stade, l'équipe peut l'évaluer et la corriger avant qu'elle ne soit déployée, généralement à un coût bien moindre qu'a posteriori. Si elle est manquée, il s'agit d'un changement que l'auditeur pourrait échantillonner comme une exception que vous devriez expliquer, ce qui peut compliquer l'avis sur lequel vous avez travaillé pendant des mois.
Ce que cela ne remplace pas
Une vérification au niveau des pull requests est une couche d'un processus bien plus large, et il est important d'être précis sur le reste, car aucune de ces étapes ne relève de la responsabilité de heygrc. Choisir votre auditeur, définir vos catégories de confiance, rédiger vos politiques, réaliser l'analyse des écarts de préparation, collecter les preuves sur l'ensemble de votre stack (fournisseur d'identité, configuration cloud, intégration et désintégration des employés par les RH, gestion des fournisseurs) pour toute la période d'observation, et émettre l'avis : tout cela fait partie du programme de conformité, généralement géré via une plateforme conçue à cet effet (le guide sur les outils d'automatisation de la conformité couvre cette couche) ainsi que votre auditeur. heygrc est conçu pour lire les pull requests par rapport aux critères que vous avez sélectionnés et identifier le contrôle qu'un changement concerne. Il ne réalise pas votre audit, ne remplace pas votre auditeur et ne vous permet pas à lui seul d'obtenir un avis sans réserve ; il est conçu pour aider l'équipe à détecter tôt, pendant le programme, les changements de pull requests pertinents pour les contrôles, avant qu'ils ne deviennent le type d'exception qui rend plus difficile l'obtention de l'avis.