SOC 2 pour les SaaS français : le guide pour vendre aux entreprises américaines

Un jour, ça arrive. Vous êtes en closing avec un prospect américain — le genre de deal qui change votre trimestre — et le mail tombe : “Before we can proceed, we’ll need your SOC 2 Type II report.”

Si vous ne savez pas ce que c’est, vous venez de perdre entre 3 et 6 mois. Si vous savez ce que c’est mais que vous ne l’avez pas, vous venez de perdre ce deal. On voit ça régulièrement chez nos clients : un deal bloqué à la dernière étape, faute de rapport SOC 2.

Cet article couvre tout ce qu’un CTO d’éditeur SaaS français doit savoir sur SOC 2 : ce que c’est, pourquoi les américains l’exigent, le processus pour l’obtenir, les outils qui accélèrent le travail, et où le pentest rentre dans l’équation.

SOC 2, c’est quoi concrètement

SOC 2 (Service Organization Control 2) est un standard d’audit développé par l’AICPA — l’ordre des experts-comptables américain. C’est un référentiel qui prouve qu’un prestataire de services (vous, l’éditeur SaaS) gère correctement la sécurité des données de ses clients.

Ce n’est pas une certification au sens ISO du terme. C’est un rapport d’audit émis par un cabinet CPA (Certified Public Accountant) qui atteste que vos contrôles de sécurité sont en place et fonctionnent.

Type I vs Type II

Il y a deux niveaux, et la distinction est importante :

Type I — Le cabinet vérifie que vos contrôles de sécurité existent à un instant T. C’est une photo. Ça prend 1 à 2 mois, ça coûte entre 10 000 et 25 000 €. C’est suffisant pour débloquer des deals en cours et montrer que vous êtes en route.

Type II — Le cabinet vérifie que vos contrôles fonctionnent effectivement sur une période de 3 à 12 mois. C’est un film. Ça prend 3 à 6 mois au total si vous êtes bien organisés, ça coûte entre 20 000 et 40 000 €. C’est ce que les entreprises américaines exigent réellement.

La différence en une phrase : Type I dit “vous avez un extincteur”, Type II dit “votre extincteur fonctionne et quelqu’un l’a testé tous les mois pendant un an.”

Un Type I passe pour signer un deal — ça rassure le procurement et montre que vous prenez le sujet au sérieux. Mais à moyen terme, il faudra passer au Type II. La majorité des clients enterprise américains finissent par l’exiger, et votre auditeur vous poussera naturellement dans cette direction au renouvellement.

Les 5 critères de confiance (Trust Service Criteria)

SOC 2 s’articule autour de 5 critères. Seul le premier est obligatoire — les quatre autres sont optionnels et ajoutés selon les attentes de vos clients :

1. Sécurité (obligatoire) — Protection contre les accès non autorisés. C’est le socle. Il couvre 9 domaines : gouvernance, gestion des risques, contrôle des changements, monitoring, contrôle d’accès, gestion des incidents, etc.

2. Disponibilité — Vos systèmes sont opérationnels quand vos clients en ont besoin. Pertinent si vous vendez du SLA 99.9%.

3. Intégrité du traitement — Les données sont traitées correctement, sans erreur, sans altération. Pertinent pour les SaaS qui gèrent de la data financière ou médicale.

4. Confidentialité — Les données confidentielles restent confidentielles. Si vos clients vous confient des secrets industriels ou des données stratégiques.

5. Vie privée — La collecte et le traitement des données personnelles respectent vos engagements. Si vous traitez des données personnelles (spoiler : c’est quasi systématique).

En pratique, la majorité des SaaS commencent avec le critère Sécurité seul, puis ajoutent Disponibilité et Confidentialité au deuxième audit. Si votre prospect vous envoie un security questionnaire avec des questions sur la disponibilité ou la confidentialité, c’est un signal qu’il faudra les couvrir.

Pourquoi les américains l’exigent

On ne va pas tourner autour : le marché US fonctionne différemment du marché européen en matière de compliance sécurité.

En Europe, quand un client veut s’assurer que son prestataire SaaS gère correctement la sécurité, il demande une certification ISO 27001. C’est le standard de référence en Europe pour les systèmes de management de la sécurité de l’information. Certains signent aussi un DPA pour la partie données personnelles (RGPD), mais c’est un sujet privacy, pas sécurité.

Aux US, l’équivalent de l’ISO 27001 c’est SOC 2. C’est le standard que le marché américain a adopté pour évaluer la sécurité des prestataires SaaS. Si vous vendez aux US, c’est le test que votre prospect va vous faire passer avant de signer.

Quand ça tombe dans le cycle de vente

Ça ne tombe jamais au premier call. Le scénario classique :

1. Discovery / demo — Pas de question compliance. On parle produit, use case, pricing.
2. Évaluation technique — L’équipe IT regarde votre produit. Parfois un security questionnaire de 50 à 200 questions arrive à ce stade.
3. Négociation / procurement — C’est là que le mail arrive. Legal et procurement demandent le SOC 2, parfois avec un questionnaire SIG ou CAIQ en bonus.
4. Closing — Sans SOC 2, le deal est bloqué. Le procurement ne signera pas.

Un rapport SOC 2 Type II simplifie considérablement les security questionnaires. Au lieu de répondre à 200 questions en justifiant chaque point, vous envoyez le rapport et le prospect coche la case. Certains clients envoient quand même un formulaire complémentaire, mais c’est beaucoup plus rapide quand vous pouvez renvoyer au rapport pour la majorité des réponses.

Le seuil de déclenchement

Ce qui déclenche le sujet, ce n’est pas votre taille — c’est la taille de votre client. Si vous vendez à un Fortune 500, même en étant une startup de 10 personnes, le procurement va demander le SOC 2. On a vu des éditeurs pré-seed se retrouver bloqués sur un deal transformant parce qu’ils n’avaient rien à montrer.

Notre observation :

• Clients mid-market US — Un Type I suffit souvent pour débloquer le deal. Le procurement veut voir que vous prenez la sécurité au sérieux.
• Clients enterprise / Fortune 500 — Type II exigé. Pas de négociation possible. Le procurement ne signera pas sans.
• Levée de fonds aux US — La majorité des VCs américains préfèrent investir dans des startups conformes SOC 2. Si vous visez un tour US, anticipez.

Le processus pour l’obtenir

On décompose en 5 phases. Bonne nouvelle : avec les bons outils et un minimum d’organisation, un Type II peut se boucler en 3 à 6 mois. Les délais de 12-18 mois qu’on lit partout datent d’une époque où tout se faisait manuellement — les outils de compliance ont changé la donne.

Phase 1 : cadrage du périmètre (2 semaines)

Définir ce qui entre dans le scope de l’audit. C’est la décision la plus structurante du projet.

La règle : périmètre minimal. Incluez uniquement votre environnement de production, les outils qui supportent directement votre service (monitoring, CI/CD, gestion des accès), et les process associés (incident response, onboarding employés).

N’incluez pas votre CRM, votre outil de comptabilité, ou le Slack de l’équipe marketing. Chaque système dans le scope = plus d’evidence à collecter = plus de temps = plus cher.

Erreur fréquente chez les SaaS français : inclure trop de choses par excès de prudence. Demandez à votre auditeur : “quel est le périmètre minimal que mes clients accepteront ?”

Phase 2 : gap analysis (1-2 mois)

Optionnel mais fortement recommandé. Un consultant ou votre outil de compliance (Vanta, Drata, etc.) passe en revue votre état actuel et identifie les écarts avec les exigences SOC 2.

Les gaps les plus courants qu’on voit chez les SaaS français :

• Pas de politique d’accès formalisée. Vous utilisez GitHub Teams et Okta, c’est bien. Mais il n’y a pas de document écrit qui dit qui a accès à quoi, pourquoi, et comment on le revoit. L’auditeur veut un document.
• Pas de revue trimestrielle des accès. Vous ajoutez des gens, vous n’en retirez jamais. L’auditeur veut une preuve de revue signée chaque trimestre.
• Pas de plan de réponse aux incidents. “On avisera si ça arrive” ne passe pas un audit. Il faut un document de 2-3 pages et un exercice de simulation documenté.
• Pas de formation sécurité employés. Un email “faites attention au phishing” ne compte pas. L’auditeur veut une formation annuelle documentée avec signature de chaque employé.
• Pas de pentest récent. On y revient plus bas, mais si votre dernier test d’intrusion date de plus de 12 mois, c’est un gap.

Phase 3 : remédiation et mise en place des contrôles (2-4 mois)

C’est la phase la plus lourde en effort. Il faut :

• Rédiger les politiques manquantes (accès, changements, incidents, rétention des données, formation)
• Implémenter les contrôles techniques (MFA partout, chiffrement, logging, alerting, scans de vulnérabilités)
• Mettre en place la collecte d’evidence automatisée (c’est là que Vanta et consorts deviennent utiles)
• Former les équipes
• Réaliser un pentest de baseline pour identifier les vulnérabilités avant le début de la période d’observation

Phase 4 : période d’observation Type II (3 mois minimum)

Vos contrôles doivent fonctionner en production pendant au minimum 3 mois (la plupart des auditeurs acceptent une fenêtre de 3 mois pour un premier audit). L’auditeur va vérifier que ce n’est pas du théâtre. Il veut des logs, des preuves de revues d’accès datées, des tickets de gestion de changements, des rapports de scans de vulnérabilités réguliers.

C’est pendant cette période qu’il faut réaliser au moins un pentest complet (idéalement deux : un au début pour la baseline, un vers la fin pour valider les remédiations).

L’erreur fatale : collecter les preuves manuellement la veille de l’audit. Les auditeurs repèrent immédiatement les screenshots d’accès tous datés du même jour. Automatisez la collecte dès le jour 1.

Phase 5 : audit par le cabinet CPA (1-2 mois)

Le cabinet passe en revue vos contrôles, teste les preuves, interroge vos équipes. Il émet ensuite un rapport avec une opinion :

• Opinion non qualifiée = vous êtes conforme. C’est ce que vous voulez.
• Opinion qualifiée = des contrôles sont défaillants. C’est problématique — un prospect enterprise verra les exceptions et posera des questions.

Choisissez bien votre auditeur. Tous les CPA peuvent techniquement faire un SOC 2, mais l’expérience varie énormément. Demandez : “combien d’audits SOC 2 Type II pour des SaaS avez-vous réalisés ces 2 dernières années ?” Vous voulez un cabinet qui en fait plus de 20 par an.

Les outils de compliance : Vanta, Drata, Secureframe

On accompagne régulièrement des clients qui utilisent ces outils. Ce sont des plateformes qui automatisent la partie la plus pénible de SOC 2 : la collecte d’evidence.

Elles se connectent à vos systèmes (AWS, GitHub, Okta, Jira, Slack, etc.) et collectent automatiquement les preuves que l’auditeur attend : logs d’accès, configuration MFA, tickets de changements, etc.

Vanta

Le choix par défaut de la majorité des SaaS qu’on audite. Simple à déployer, onboarding rapide, bon catalogue d’intégrations. C’est le choix qui fait sens si vous êtes en Series A/B, que c’est votre premier SOC 2, et que vous voulez aller vite. Comptez 1 000 à 3 000 € par mois.

Drata

Plus technique, meilleure automatisation native, particulièrement bon sur les environnements cloud complexes (multi-cloud, Kubernetes). Si vous avez une équipe infra solide et que vous visez plusieurs frameworks (SOC 2 + ISO 27001), c’est un bon choix. Comptez 2 000 à 5 000 € par mois.

Secureframe

Le plus accompagné des trois. Leur équipe fait une grande partie du setup. Bon choix si vous n’avez pas de ressource dédiée compliance et que vous voulez un support white-glove. Pricing sur demande — c’est le plus cher des trois, mais l’accompagnement est inclus.

Ce que ces outils ne font pas

Un point qu’on rappelle à chaque client : Vanta ne fait pas votre sécurité. Ces outils collectent de l’evidence. Ils ne corrigent pas vos vulnérabilités, ils ne configurent pas votre MFA, ils ne rédigent pas votre plan de réponse aux incidents.

Si vos contrôles de sécurité sont mauvais, l’outil va documenter fidèlement que vos contrôles sont mauvais — et votre auditeur aussi.

Où le pentest rentre dans SOC 2

C’est la question qu’on nous pose le plus. Réponse courte : dans la pratique, le pentest est incontournable pour SOC 2 — Type I comme Type II. On n’a pas vu d’auditeur faire passer un client sans rapport de pentest.

Ce que l’auditeur attend

Le pentest couvre plusieurs Common Criteria du volet Sécurité :

• CC 4.1 (Monitoring) — Vous testez régulièrement l’efficacité de vos contrôles de sécurité
• CC 6.1 (Contrôle d’accès) — Vos contrôles d’accès résistent à une tentative d’intrusion réelle
• CC 7.1 (Opérations système) — Vos systèmes en production sont sécurisés
• CC 7.2 (Gestion des changements) — Les changements n’introduisent pas de vulnérabilités

Un auditeur qui voit un rapport de pentest récent dans vos preuves va cocher ces cases rapidement. Un auditeur qui n’en voit pas va poser des questions, demander des compensations, et potentiellement noter des exceptions.

Pentest Type I vs Type II

Pour un Type I, l’auditeur attend un rapport de pentest récent. Ça peut être un pentest réalisé dans les derniers mois, mais il faut qu’il couvre le périmètre SOC 2.

Pour un Type II, prévoyez au minimum un pentest complet pendant la période d’observation. L’idéal :

• Un pentest au début de la période d’observation (baseline, identification des vulnérabilités)
• Remédiation des findings critiques et high sous 30 et 60 jours respectivement
• Un retest en fin de période pour prouver que les corrections tiennent

Le rapport de pentest doit couvrir le périmètre SOC 2 : votre application web, vos APIs, votre infrastructure exposée. Un pentest réseau interne seul ne suffit pas si votre scope SOC 2 est votre plateforme SaaS.

Ce qu’on fait concrètement

On accompagne une dizaine d’éditeurs SaaS par an en préparation SOC 2. Le scénario type :

1. Le client a défini son périmètre SOC 2 avec son outil de compliance (souvent Vanta)
2. On réalise un pentest applicatif sur le périmètre défini — application web, APIs, éventuellement mobile
3. On livre un rapport avec chaque vulnérabilité documentée : description, preuve d’exploitation, criticité CVSS, et correctif applicable
4. Le client remédie. On fait un retest gratuit sous 30 jours pour valider les corrections
5. Le rapport de pentest + le rapport de retest vont directement dans les preuves SOC 2

Le rapport est formaté pour être directement exploitable par l’auditeur. On mappe chaque finding aux Common Criteria SOC 2 concernés — l’auditeur peut les exploiter directement.

Vous préparez un SOC 2 ? Décrivez votre périmètre en 2 minutes — on revient vers vous le jour même avec une proposition de cadrage.

Erreurs courantes des SaaS français

On les voit revenir. Les voici dans l’ordre de fréquence.

Ne pas paralléliser les phases

Le réflexe : traiter chaque phase séquentiellement, comme un projet waterfall. La réalité : avec un bon outil de compliance et une équipe motivée, vous pouvez lancer la remédiation en parallèle du gap analysis, commencer la période d’observation dès que les contrôles critiques sont en place, et boucler un Type II en 3 à 6 mois.

Si vous avez un deal enterprise qui arrive dans 2 mois, visez un Type I. Ça prend 4 à 8 semaines et ça débloque le deal pendant que vous préparez le Type II en parallèle.

Acheter Vanta et considérer le travail comme fait

Vanta (ou Drata, ou Secureframe) est un collecteur d’evidence, pas un bouclier magique. Si votre MFA n’est pas activée, l’outil va afficher un warning rouge — il ne va pas l’activer pour vous. On voit des clients qui ont payé l’abonnement pendant 6 mois sans jamais implémenter les contrôles que l’outil leur demandait.

Périmètre trop large

Vous n’avez pas besoin d’inclure votre Notion, votre Figma, et votre outil de paie dans le scope SOC 2. Le périmètre doit couvrir les systèmes qui traitent, stockent ou transmettent les données de vos clients. Pas plus.

Ignorer la question data residency

Celle-là est spécifique aux éditeurs français qui vendent aux US. Votre prospect américain va vous demander où sont stockées ses données. Si vous utilisez AWS eu-west-3 (Paris), c’est un bon début. Mais l’auditeur veut un schéma de flux de données documenté : où les données sont collectées, traitées, stockées, sauvegardées, archivées.

Les éditeurs français qui hébergent en Europe ont un avantage marketing (“EU data residency”), mais attention au US CLOUD Act : les fournisseurs cloud américains peuvent être contraints de fournir des données même stockées en Europe. Documentez votre position dans le scope narrative SOC 2.

Pas de plan de réponse aux incidents

C’est le gap le plus sous-estimé. Rédigez un document de 2-3 pages qui couvre : qui est alerté, comment, quel est le processus de triage, d’escalade, de communication client, de post-mortem. Puis faites un exercice de simulation documenté au moins une fois pendant la période d’observation.

Combien ça coûte au total

Budget réaliste pour un SaaS français de 20 à 100 employés :

Type I :

• Outil de compliance (Vanta/Drata) : 12 000 - 24 000 €/an
• Audit CPA : 8 000 - 20 000 €
• Pentest : 5 000 - 15 000 €
• Temps interne : 1-2 mois équivalent temps plein (ETP)
• Total : 25 000 - 60 000 €

Type II :

• Outil de compliance (Vanta/Drata) : 12 000 - 24 000 €/an
• Audit CPA : 15 000 - 30 000 €
• Pentest (x2 : baseline + retest) : 10 000 - 25 000 €
• Temps interne : 2-4 mois ETP
• Total : 40 000 - 80 000 €

C’est un investissement. Mais mettez ça en face d’un seul deal enterprise US à 50K€+ ARR, et le ROI est positif dès le premier contrat signé.

Timeline recommandée

Pour un éditeur SaaS français qui part de zéro :

Mois 1-2 — Cadrage du périmètre. Choix de l’outil de compliance. Gap analysis. Lancement du premier pentest (baseline).

Mois 3-5 — Remédiation des gaps. Rédaction des politiques. Mise en place des contrôles. Retest pentest. Optionnel : lancer un Type I en parallèle pour débloquer les deals en cours.

Mois 4-6 — Période d’observation Type II (peut démarrer dès que les contrôles critiques sont en place — pas besoin d’attendre que tout soit parfait). Collecte d’evidence en continu. Deuxième pentest vers la fin de la période.

Mois 6-7 — Audit CPA. Émission du rapport Type II.

Ensuite — Renouvellement annuel. Le second audit est plus simple et moins cher — la majorité du travail est derrière vous, vous entretenez, vous ne construisez plus.

En résumé

SOC 2 n’est plus un “nice to have” si vous vendez aux US. La grande majorité des entreprises américaines l’exigent de leurs prestataires SaaS. Le processus prend 3 à 6 mois pour un Type II bien mené et coûte entre 40 000 et 80 000 €, mais un seul deal enterprise rembourse l’investissement.

Les outils comme Vanta ou Drata accélèrent le travail en automatisant la collecte d’evidence. Le pentest est attendu par les auditeurs pour Type I comme pour Type II — et il est de toute façon indispensable pour savoir si vos contrôles de sécurité fonctionnent réellement.

Si vous préparez votre SOC 2 et que vous avez besoin d’un pentest aligné sur votre périmètre d’audit, décrivez votre projet en 2 minutes. Nos rapports sont mappés aux Common Criteria SOC 2 et directement exploitables par votre auditeur. Retest gratuit inclus sous 30 jours. Réponse le jour même.