SOC 2 en 90 jours : comment un SaaS de santé a réussi son premier audit

Projet représentatif. Détails du client anonymisés et éléments spécifiques modifiés sous NDA.

L’e-mail qui a tout déclenché ne venait pas d’une équipe sécurité. Il avait été transféré par un fondateur, trois lignes, avec pour objet “on risque de perdre le contrat”. Un éditeur SaaS de santé d’environ 40 personnes avait un contrat entreprise en cours chez les juristes, et le groupe risque fournisseurs de l’acheteur avait répondu avec une seule condition : fournir un rapport SOC 2 avant la mise en production. L’entreprise n’en avait pas. Il lui restait 90 jours avant la fermeture de la fenêtre de renouvellement.

C’est ainsi que débute réellement la plupart des projets de préparation SOC 2. Non pas parce qu’une équipe sécurité décide de gagner en maturité, mais parce qu’un client retient un contrat tant que vous n’avez pas prouvé que vous prenez la sécurité au sérieux. Quatre-vingt-dix jours, c’est vraiment serré, mais c’est jouable pour un Type II avec une fenêtre d’observation courte si vous avancez vite et cessez de traiter l’audit comme une corvée de paperasse. Le piège, c’est le périmètre. Les équipes brûlent régulièrement le premier mois à débattre de ce qu’il faut inclure au lieu de collecter des preuves.

Voici ce que nous avons fait, ce que l’évaluation des écarts a révélé et la poignée de changements qui leur ont permis de réussir.

Points clés à retenir

• La préparation SOC 2 consiste à prouver que les contrôles fonctionnent dans la durée, pas à rédiger des politiques la semaine précédant l’arrivée de l’auditeur. Lancez le compteur des preuves dès le premier jour.
• Pour un Type II sur une fenêtre courte, la voie la plus rapide est un périmètre resserré : le système de production qui touche aux données clients, et rien d’autre.
• Les écarts qui font échouer les premiers audits sont banals. Aucune revue d’accès, aucune preuve de départ, une journalisation qui tourne mais que personne ne lit. Pas d’attaques exotiques.
• Reliez la collecte de preuves à l’identité, à la configuration cloud et à la gestion des tickets pour que les contrôles génèrent leur propre preuve au lieu de dépendre de captures d’écran.
• Une évaluation de préparation avant l’audit transforme le “on espère que ça passe” en une liste connue d’écarts avec responsables et échéances.

Ce que SOC 2 exige réellement d’une entreprise

SOC 2 est un rapport d’attestation produit par un cabinet CPA agréé au regard des Trust Services Criteria de l’AICPA. Chaque SOC 2 couvre la Security, appelée common criteria, et vous ajoutez en option l’Availability, la Confidentiality, la Processing Integrity ou la Privacy. Un rapport Type I indique que vos contrôles étaient correctement conçus à une date précise. Un Type II indique qu’ils ont réellement fonctionné sur une période, en général de trois à douze mois. Les acheteurs entreprise veulent presque toujours du Type II, car un instantané limité à la conception ne prouve rien sur votre comportement au quotidien.

Pour un SaaS de santé, la Confidentiality est généralement dans le périmètre, et une seconde réalité vient s’y ajouter : si vous manipulez des données de santé protégées, HIPAA s’applique toujours. SOC 2 ne remplace pas HIPAA. Sur ce projet, les deux se recoupaient suffisamment pour que nous cartographiions chaque contrôle une seule fois et satisfaisions les deux exigences partout où elles coïncidaient, ce qui a évité à l’équipe de faire deux fois le même travail.

Voici ce que les gens ratent. SOC 2 ne vous remet pas une liste de contrôles à mettre en place. Il n’existe pas de checklist maîtresse de l’AICPA. Vous définissez vos propres contrôles au regard des critères, et l’auditeur teste si ces contrôles existent et fonctionnent. C’est précisément cette liberté qui fait caler les équipes livrées à elles-mêmes.

Le plan sur 90 jours que nous avons mené

Nous avons découpé la fenêtre en trois phases et lancé le compteur des preuves immédiatement, plutôt que d’attendre que le corpus de politiques soit parfait.

Jours 1 à 20 : périmètre, évaluation des écarts et compteur des preuves

Nous avons d’abord verrouillé le périmètre, et ce fut une bataille. L’instinct du client était de tout inclure : le site marketing, un outil d’analytique interne, trois comptes AWS distincts. Nous l’avons réduit au seul compte de production qui héberge l’application et traite les données clients. La dérive du périmètre est l’erreur la plus coûteuse d’un premier audit. Chaque système que vous y intégrez multiplie les preuves à produire et les contrôles à maintenir en fonctionnement sur toute la période d’observation.

Ensuite, l’évaluation de préparation. Nous avons passé en revue chaque contrôle des common criteria et l’avons marqué présent, partiel ou manquant. Le résultat était un simple registre d’écarts avec un responsable et une échéance par ligne, pas un rapport de 60 pages que personne n’ouvre après le lancement.

Jours 20 à 55 : remédiation

C’est là que se fait le vrai travail. Nous avons mis en place les contrôles manquants, relié la collecte de preuves aux outils que l’équipe utilisait déjà, et lancé la fenêtre d’observation pour que l’auditeur dispose d’un véritable historique d’exploitation à échantillonner plutôt que d’une semaine d’activité bricolée à la hâte.

Jours 55 à 90 : exploiter, collecter et l’audit

Les contrôles tournaient pendant que les preuves s’accumulaient d’elles-mêmes. Nous avons fait une répétition interne au regard de la liste de demandes attendue de l’auditeur, corrigé les deux points encore fragiles, et remis un dossier de preuves propre au cabinet CPA.

Ce que nous avons trouvé dans l’évaluation des écarts

Aucun des écarts sérieux n’était spectaculaire. C’est le schéma sur presque tous les projets de première préparation SOC 2 que nous menons. Ce qui fait échouer les audits, c’est l’hygiène opérationnelle, pas les zero-days.

Aucune revue des accès utilisateurs. Personne ne s’était jamais assis pour se demander qui pouvait atteindre la production et si cet accès était encore nécessaire. Deux anciens prestataires avaient encore des utilisateurs IAM actifs, l’un d’eux presque un an après la fin du contrat. CC6.1 et CC6.2 s’en préoccupent tous les deux, et l’accès est l’une des premières choses qu’un auditeur échantillonne.

Le départ des collaborateurs était informel. Quand quelqu’un partait, l’ordinateur portable revenait mais l’accès était révoqué “quand quelqu’un y pensait”. Pas de ticket, pas d’horodatage, pas de preuve. Un auditeur n’accepte pas le “on le fait toujours”. Il choisit un partant dans le registre RH et vous demande de montrer l’enregistrement de déprovisionnement avec une date dessus.

La journalisation était activée mais non surveillée. CloudTrail était activé, ce que les équipes adorent mettre en avant. Les logs atterrissaient dans un bucket S3 qu’aucun humain et aucune alerte n’a jamais touché. Une détection que l’on ne regarde jamais n’est pas un contrôle. C’est du stockage avec une facture mensuelle.

Aucune gestion formelle des changements. Les ingénieurs fusionnaient et déployaient via des pull requests revues par les pairs dans GitHub, ce qui était en fait une pratique solide. Mais rien par écrit ne reliait cette pratique à un contrôle, si bien que, du fauteuil de l’auditeur, elle n’existait pas.

La gestion des fournisseurs était un tableur touché pour la dernière fois en 2023. Un SaaS de santé s’appuie sur des sous-traitants, et les critères attendent que vous les recensiez et surveilliez leur posture de sécurité.

Voyez combien d’entre eux relèvent de problèmes de documentation et de preuve plutôt que du “on ne fait pas ça du tout”. Une grande part de la préparation SOC 2 consiste à rendre lisibles, pour quelqu’un qui n’était pas dans la pièce, des pratiques bonnes mais invisibles.

Comment nous avons comblé les écarts sans ralentir l’ingénierie

La règle que nous avons fixée avec le client était sans détour : automatiser la preuve pour qu’un contrôle produise son propre justificatif, et ne se rabattre sur un processus manuel que là où l’automatisation n’en vaut pas la peine.

Pour l’identité et les accès, nous avons fait passer tout le monde derrière le SSO, imposé le MFA et instauré une revue des accès trimestrielle récurrente, dont le résultat est stocké sous forme d’artefact daté plutôt que dans un fil Slack qui défile jusqu’à l’oubli. Pour le déprovisionnement, nous avons rattaché le départ des collaborateurs à un modèle de ticket, de sorte que chaque départ génère désormais un enregistrement horodaté de la suppression des accès. Ce seul changement a transformé un contrôle improuvable en un contrôle auditable.

Pour la journalisation et la supervision, nous ne sommes pas allés acheter une grande plateforme. Nous avons acheminé les logs CloudTrail et applicatifs vers une destination avec alertes sur les événements qui comptent : usage du compte root, modifications des politiques IAM et échecs de connexion à la console au-delà d’un seuil. Ensuite, nous avons documenté qui examine les alertes et à quelle fréquence. Voici comment cela se lisait dans leur matrice de contrôles :

Control ID : CC7.2
Statement  : Security events are logged and monitored; anomalies alert the on-call.
Evidence   : CloudTrail -> log sink; alert rules (root use, IAM change, failed logins);
             on-call rotation; sample alert + triage ticket from the observation window.
Frequency  : Continuous; reviewed weekly.
Owner      : Head of Engineering

Pour la gestion des changements, nous n’avons rien changé à la façon de travailler des ingénieurs. Nous avons rédigé la politique pour qu’elle corresponde à la réalité déjà en place : pull request, revue obligatoire, contrôles CI, branche main protégée. Puis nous avons utilisé l’historique GitHub existant comme preuve. Aligner le document sur la pratique est bien plus rapide, et bien plus honnête, que de greffer un nouveau processus la semaine où l’auditeur débarque.

Les politiques sont venues en dernier. Nous avons rédigé les politiques de sécurité, de contrôle des accès, de réponse aux incidents, de gestion des changements et de gestion des fournisseurs pour décrire des contrôles qui fonctionnaient déjà. Les politiques rédigées avant la pratique décrivent un fantasme, et les auditeurs sont très doués pour repérer l’écart entre une belle politique et ce que les logs disent qu’il s’est réellement passé.

Le résultat

Ils ont réussi. Le cabinet CPA a émis un rapport SOC 2 Type II sans exceptions sur le périmètre des common criteria, ce qui est un solide résultat pour un premier audit. Présenté comme un résultat représentatif pour une entreprise de cette taille : l’évaluation de préparation a fait remonter une douzaine d’écarts significatifs, la plupart ont été comblés pendant la phase de remédiation, et le contrat entreprise qui avait tout déclenché a atteint sa mise en production.

Le gain le plus durable a été plus discret. La collecte de preuves est devenue un processus d’arrière-plan. Les revues d’accès, les enregistrements de départ et le tri des alertes génèrent désormais leurs propres artefacts, si bien que la prochaine période d’audit relève surtout de la maintenance plutôt que d’un nouveau sprint de 90 jours. C’est là la vraie frontière entre courir après un rapport et faire tourner un programme de sécurité.

Comment CyberXplore vous aide

Nous menons la préparation SOC 2 comme nous avons mené celle-ci. Cadrer le périmètre serré, évaluer honnêtement, combler les écarts que les auditeurs testent réellement, et intégrer la preuve pour que vos contrôles se justifient d’eux-mêmes. Nous cartographions les contrôles au regard des Trust Services Criteria, effectuons la répétition pré-audit au regard de la liste de demandes, et travaillons aux côtés de votre cabinet CPA pour que rien ne vous surprenne sur le chemin du rapport. Si un acheteur attend un rapport ou si vous avez une échéance que vous n’avez pas choisie, demandez un devis et nous vous dirons honnêtement si votre fenêtre est réaliste et ce qu’il faut pour la tenir.

FAQ

Peut-on vraiment obtenir SOC 2 en 90 jours ?

Vous pouvez atteindre la préparation SOC 2 et boucler un Type II avec une fenêtre d’observation courte en environ 90 jours si le périmètre est resserré et que vous commencez à collecter des preuves tout de suite. La contrainte est la période d’observation, car un Type II exige que les contrôles fonctionnent dans la durée, et vous ne pouvez pas comprimer cela à zéro. Certains cabinets CPA n’observent pas en dessous de trois mois, aussi un repli courant consiste à faire d’abord un Type I pour satisfaire un acheteur pressé, suivi d’une période Type II.

Quelle est la différence entre SOC 2 Type I et Type II ?

Le Type I atteste que vos contrôles sont conçus de manière appropriée à une seule date. Le Type II atteste que ces contrôles ont effectivement fonctionné de façon efficace sur une période, typiquement de trois à douze mois. Les acheteurs entreprise exigent en général le Type II, car il prouve le comportement dans la durée, pas seulement l’intention un jour donné.

SOC 2 couvre-t-il HIPAA pour un SaaS de santé ?

Non. SOC 2 et HIPAA sont distincts. SOC 2 est une attestation au regard des Trust Services Criteria de l’AICPA, tandis que HIPAA est une réglementation américaine couvrant les données de santé protégées. Ils se recoupent sur de nombreux contrôles de sécurité, vous pouvez donc cartographier le travail pour satisfaire les deux, mais un rapport SOC 2 ne vous rend pas conforme à HIPAA à lui seul.

Quels Trust Services Criteria devrions-nous inclure ?

Chaque SOC 2 doit inclure la Security, les common criteria. Vous ajoutez l’Availability, la Confidentiality, la Processing Integrity ou la Privacy selon ce que vous promettez aux clients. La plupart des entreprises SaaS commencent par la Security plus l’Availability et la Confidentiality, et n’ajoutent la Privacy que lorsqu’elles prennent des engagements précis en matière de confidentialité.

Qu’est-ce qui fait échouer les entreprises à leur premier audit ?

Presque jamais des défaillances de sécurité exotiques. Ce sont des preuves manquantes : aucune revue d’accès, aucun enregistrement de départ daté, une journalisation que personne ne surveille, et des politiques qui décrivent un processus que l’équipe ne suit pas réellement. Une évaluation de préparation avant l’arrivée de l’auditeur est le moyen le moins coûteux de trouver ces écarts pendant que vous avez encore le temps de les corriger.

Quelle part de tout cela peut être automatisée ?

Une grande part. Les preuves d’identité et d’accès, les vérifications de configuration cloud, l’historique des changements et la supervision des logs peuvent tous générer leurs propres artefacts de façon planifiée. Automatiser la collecte de preuves, c’est ce qui transforme SOC 2 d’un exercice d’incendie récurrent en une tâche de maintenance, et c’est le seul changement qui rapporte le plus sur les futures périodes d’audit.