+150 XP

SOC 2, ISO 27001 et l'audit theater exigé par les acheteurs

Une startup de 40 personnes sans ingénieur sécurité peut obtenir un rapport SOC 2 sans réserve en trois mois. Une équipe achats d'une entreprise du Fortune 500 rejettera un vendor à la sécurité irréprochable mais sans aucun rapport. C'est le paradoxe au cœur de la vente SaaS enterprise : le certificat compte davantage que la réalité qu'il est censé certifier, du moins à l'entrée.

Pourquoi les acheteurs ne signent pas sans

Les équipes achats et sécurité en entreprise font face à un problème d'échelle. Une grande entreprise peut utiliser 300 à 3 000 vendors SaaS (estimation, très variable selon la taille). Personne n'a le temps d'auditer les pratiques de sécurité de chacun depuis zéro.

Elles externalisent donc la confiance à un rapport. SOC 2 (System and Organization Controls 2) est un rapport d'attestation produit selon les normes de l'AICPA (American Institute of Certified Public Accountants). Il dit au client : un auditeur indépendant a vérifié les contrôles de ce vendor par rapport à un framework défini et les a trouvés opérationnels tels qu'annoncés.

ISO 27001 est l'équivalent international, une certification (et pas seulement un rapport) par rapport à une norme maintenue par l'International Organization for Standardization. Elle est plus fréquemment exigée comme prérequis de base par les acheteurs enterprise européens et asiatiques, tandis que SOC 2 domine la vente enterprise aux États-Unis.

Sans l'un des deux, beaucoup de départements achats ne transmettent même pas le vendor à la revue juridique. C'est une case à cocher qui débloque le reste du processus de vente, ce qui explique précisément pourquoi les vendors courent après le rapport avant de courir après une vraie maturité.

Ce que SOC 2 teste réellement

SOC 2 s'articule autour de cinq Trust Services Criteria : sécurité, disponibilité, intégrité du traitement, confidentialité et vie privée. Presque tous les vendors incluent la sécurité (obligatoire) et retiennent un sous-ensemble des autres selon ce qu'ils vendent.

Il existe deux types de rapports :

  • Type I : teste si les contrôles sont correctement conçus, à un instant donné. Plus rapide et moins cher, signal plus faible.
  • Type II : teste si les contrôles ont effectivement fonctionné sur une période, généralement 3 à 12 mois. C'est ce que demandent les acheteurs avertis.

Un auditeur (un cabinet CPA agréé) échantillonne des preuves : les revues d'accès ont-elles eu lieu chaque trimestre comme documenté ? Les employés partis ont-ils été déprovisionnés dans le SLA annoncé ? Existe-t-il un processus de réponse aux incidents documenté, et a-t-il été suivi lors d'un incident réel ?

Point essentiel : SOC 2 ne certifie pas qu'un produit est sécurisé. Il certifie que l'entreprise a suivi ses propres contrôles déclarés. Si votre politique dit « nous revoyons les accès tous les 90 jours » et que vous l'avez fait, vous passez, même si 90 jours est une fréquence trop faible au regard du risque réel.

ISO 27001 : la même idée, une forme différente

ISO 27001 impose de construire un ISMS (Information Security Management System) : un framework documenté et fondé sur le risque, couvrant l'inventaire des actifs, l'évaluation des risques et un ensemble obligatoire de contrôles issus de l'Annexe A (un catalogue d'environ 93 contrôles dans la révision 2022, couvrant des domaines comme le contrôle d'accès, la cryptographie et les relations fournisseurs).

Différences clés avec SOC 2 :

  • ISO 27001 est une certification avec un badge et un numéro de certificat public, valable généralement 3 ans avec des audits de surveillance annuels.
  • Les rapports SOC 2 sont des documents privés, en général partagés sous NDA avec les prospects, non publiés.
  • ISO est plus prescriptif sur le système de management lui-même ; SOC 2 laisse l'entreprise définir son propre jeu de contrôles à l'intérieur des trust criteria.

Beaucoup de vendors SaaS matures détiennent les deux, parce que les acheteurs enterprise américains demandent SOC 2 et que les acheteurs européens ou multinationaux exigent souvent ISO 27001. Maintenir les deux est un vrai centre de coûts : honoraires d'audit, effectifs conformité internes et outillage (comme Vanta, Drata ou Secureframe) qui automatise la collecte de preuves, ce qui représente couramment des dizaines de milliers de dollars par an, même pour des vendors de taille moyenne (estimation, très variable selon la taille de l'entreprise et l'auditeur).

Le jeu du périmètre de confiance

C'est ici qu'intervient l'« audit theater ». Un rapport SOC 2 délimite un system boundary : le produit, l'environnement ou l'unité opérationnelle spécifique que l'auditeur examine. Les vendors ont une forte incitation à rétrécir ce périmètre.

Exemple concret : une entreprise vend trois produits. Seul le produit phare, hébergé dans un unique compte AWS bien géré, est inclus dans le scope SOC 2. Les deux produits plus récents, hébergés dans un environnement legacy plus brouillon récupéré via M&A, en sont exclus. Le vendor continue de communiquer « nous sommes SOC 2 compliant » à l'échelle de l'entreprise, alors que le rapport ne couvre qu'un tiers de ce qu'un client peut réellement acheter.

C'est légal. C'est indiqué dans les petits caractères du rapport (la « system description »), que presque aucun acheteur ne lit intégralement. Les équipes commerciales mettent en avant le logo AICPA ; les réserves de périmètre vivent en page 4 d'un PDF de 60 pages.

Autres schémas d'optimisation courants :

  • Jeux de calendrier : obtenir un rapport Type I juste avant un gros cycle de renouvellement, puis prendre un an pour produire le Type II, plus exigeant.
  • Minimalisme des contrôles : choisir le moins de Trust Services Criteria possible (juste « sécurité ») pour réduire le périmètre et le coût de l'audit.
  • Auditor shopping : des cabinets CPA plus petits, plus rapides et moins chers coexistent avec les Big Four et les cabinets intermédiaires, et la qualité du contrôle varie. Il n'existe pas de système public unique de notation de la rigueur des auditeurs.
  • Carve-outs des subservice organizations : si le vendor tourne sur AWS ou GCP, les contrôles propres à ces fournisseurs cloud sont exclus du rapport du vendor et couverts séparément (AWS et Google publient chacun leurs propres rapports SOC 2 et ISO). Un vendor faible peut s'appuyer sur « notre fournisseur cloud est certifié » alors que ses propres pratiques applicatives sont minces.

Rien de tout cela ne signifie que les rapports sont sans valeur. Cela signifie qu'ils sont un plancher, pas un plafond, et qu'un acheteur averti lit la system description et les exceptions relevées par l'auditeur, pas seulement la page de garde.

Pour une introduction à la structure du framework sous-jacent, l'AICPA publie une présentation ici : AICPA SOC 2 guide.

Vérification des acquis

1. Pourquoi les équipes achats en entreprise exigent-elles souvent un rapport SOC 2 ou une certification ISO 27001 avant même de transmettre un vendor à la revue juridique ?

2. Une startup obtient un rapport SOC 2 Type I. Qu'est-ce que cela démontre réellement à un acheteur ?

3. Une startup SaaS centrée sur les États-Unis hésite entre viser SOC 2 ou ISO 27001 en premier. Quel critère devrait le plus influencer ce choix ?

CHOIX MULTIPLES

4. Sélectionnez TOUTES les réponses correctes concernant les Trust Services Criteria dans un rapport SOC 2.

Sélectionnez toutes les réponses correctes.

CHOIX MULTIPLES

5. Sélectionnez TOUTES les réponses correctes qui expliquent le paradoxe de l'« audit theater » décrit dans la leçon.

Sélectionnez toutes les réponses correctes.

Ce que vérifient les bonnes équipes achats

Les acheteurs matures en sécurité ne s'arrêtent pas à « avez-vous un SOC 2 ». Ils demandent :

  1. Le rapport complet, pas seulement une lettre de synthèse, et ils lisent la section des exceptions de l'auditeur (les écarts relevés sont fréquents et pas automatiquement disqualifiants, mais ceux qui restent inexpliqués sont un signal d'alerte).
  2. Le system boundary, pour confirmer qu'il couvre bien le produit acheté.
  3. Les listes de sous-traitants et le fait de savoir si les vendors critiques (hébergement cloud, traitement des paiements, outillage support client) sont dans le scope ou carved out.
  4. Des preuves de penetration testing (tests de sécurité par un tiers sur l'application en production), que SOC 2 n'exige pas toujours mais que les acheteurs sérieux attendent chaque année.
  5. Pour les deals liés à l'UE, l'alignement avec les exigences du RGPD (Règlement général sur la protection des données) sur les accords de traitement des données, qui se situent à côté, et non à l'intérieur, de SOC 2 ou ISO 27001.

C'est aussi là qu'interviennent les plateformes de vendor risk management et les questionnaires comme SIG (Standardized Information Gathering) ou CAIQ (Consensus Assessments Initiative Questionnaire, de la Cloud Security Alliance), qui ajoutent un niveau de contrôle par-dessus la certification de base.

🎬 [VIDEO: "SOC 2 Explained" - https://www.youtube.com/results?search_query=soc+2+explained+audit - cherchez une présentation à jour de la structure d'un rapport SOC 2 et des Trust Services Criteria ; choisissez-en une provenant d'un éditeur d'automatisation de la conformité ou d'un auditeur reconnu, les premiers résultats évoluant avec le temps]

L'économie derrière le théâtre

Pourquoi ce système persiste-t-il malgré ses failles ? Parce qu'il coûte moins cher que l'alternative pour tout le monde.

Les acheteurs obtiennent une trace écrite défendable (« nous avons exigé SOC 2, conformément à la politique ») sans mener des audits de sécurité sur mesure auprès de centaines de vendors. Les vendors obtiennent un coût de conformité répétable et budgétable au lieu de questionnaires de sécurité personnalisés imprévisibles venant de chaque prospect. Les auditeurs obtiennent une mission récurrente et standardisée.

Le système est optimisé pour le transfert de responsabilité et la vélocité commerciale, pas pour la sécurité maximale. Ce n'est pas un scandale, c'est un équilibre rationnel, mais les professionnels du secteur doivent le comprendre pour ce qu'il est : une solution de marché à un problème d'asymétrie d'information, avec des trous connus que les acheteurs expérimentés intègrent dans leur évaluation.

Points clés

  • SOC 2 (AICPA, centré sur les États-Unis, rapport privé) et ISO 27001 (ISO, international, certification publique) sont les deux principaux signaux de confiance enterprise dans le SaaS ; beaucoup de vendors ont besoin des deux pour vendre sur les marchés américain et européen.
  • SOC 2 Type II (contrôles testés dans la durée) est un signal bien plus fort que le Type I (conception seule, à un instant donné) ; demandez toujours lequel on vous présente.
  • Aucune des deux certifications ne prouve qu'un produit est sécurisé. Les deux prouvent que le vendor a suivi ses propres contrôles documentés à l'intérieur d'un system boundary défini, et ce périmètre peut être rétréci pour exclure les parties les plus faibles de l'activité.
  • Les acheteurs avertis lisent le rapport complet (system description, exceptions, périmètre des sous-traitants), pas seulement la page de garde ou le badge de conformité du deck commercial.
  • Ces frameworks s'ajoutent à d'autres obligations comme les clauses RGPD de traitement des données, sans s'y substituer ; un rapport SOC 2 ne remplace pas la conformité au droit de la vie privée.