SOC 2: expliqué pour les équipes qui doivent obtenir le rapport.

Une attestation, pas un règlement

SOC 2 n'est pas une loi et pas une certification — c'est une attestation. Un cabinet d'experts-comptables indépendant examine vos contrôles, compare ses constats aux Critères de services fiduciaires de l'AICPA, et émet une opinion écrite. L'opinion constitue le rapport : un document que vos clients et prospects lisent pour décider s'ils peuvent vous confier leurs données.

La différence architecturale essentielle par rapport à ISO 27001 ou à un règlement comme DORA est qu'il n'existe ni organisme d'accréditation, ni portée statutaire, ni mécanisme d'application. Il n'y a pas de sanctions pour l'absence de rapport SOC 2 et aucun régulateur ne peut en imposer un. Vous poursuivez SOC 2 parce que le marché l'exige — en particulier parce que les équipes procurement des grands comptes demandent systématiquement un rapport Type II avant de signer avec un fournisseur cloud ou SaaS. Cette pression commerciale est réelle et croissante, mais elle est commerciale, pas juridique.

Pour une entreprise française, la question pertinente n'est pas « SOC 2 est-il obligatoire en France ? » mais « nos clients ou prospects l'exigent-ils ? » Les éditeurs SaaS français qui vendent aux États-Unis, aux multinationales ou aux grands groupes avec des exigences d'audit internationales poursuivent SOC 2 pour répondre à ces attentes de due diligence. Le choix de poursuivre SOC 2 et des CSF à inclure dans le périmètre vous appartient, en fonction de ce que vos acheteurs doivent voir.

Les cinq Critères de services fiduciaires

Les CSF sont la règle de mesure que l'auditeur utilise. Sécurité (les Critères communs, CC) est la seule catégorie obligatoire — chaque rapport SOC 2 la couvre. Les quatre autres sont des options, incluses selon la pertinence pour les services que vous fournissez et ce qui compte pour vos clients.

La plupart des éditeurs SaaS définissent la Sécurité comme socle et ajoutent la Disponibilité lorsque les engagements de disponibilité comptent pour les acheteurs, la Confidentialité lorsque le traitement des données d'entreprise est un argument commercial, la Protection de la vie privée lorsque le traitement de données personnelles est central au service (avec le RGPD comme cadre juridique en France), et l'Intégrité du traitement pour les services transactionnels ou financiers.

CC1 à CC9 : ce que l'auditeur échantillonne

Les Critères communs sont les exigences de contrôle détaillées derrière la catégorie Sécurité. Ils sont organisés en neuf groupes, CC1 à CC9, chacun couvrant un domaine de contrôle distinct. CC6, Contrôles d'accès logiques et physiques, est le plus intensif opérationnellement pour la plupart des organisations : il couvre l'approvisionnement des accès, l'authentification, l'accès basé sur les rôles et la revue périodique des accès. CC7 couvre les opérations et la surveillance des systèmes. CC9 couvre la gestion des risques et le risque prestataire, incluant CC9.2, qui exige explicitement la surveillance des prestataires tiers et des contrôles qu'ils opèrent pour votre compte.

Comprendre la structure de la série CC est important car les auditeurs échantillonnent les preuves au niveau du contrôle. Savoir quel critère CC un contrôle satisfait, c'est construire une cartographie de preuves prête pour l'audit plutôt qu'un empilement de documents. Une revue des accès qui existe dans un tableur mais ne peut être rattachée à CC6.1 et à un responsable de contrôle nommé est plus difficile à défendre qu'une revue documentée, assignée et récurrente.

La série CC se rapproche étroitement de l'Annexe A d'ISO 27001 : CC6 s'aligne sur A.5.15–A.5.18 (gestion des accès) ; CC7 sur A.8.x (opérations) ; CC9.2 sur A.5.19–A.5.23 (sécurité des fournisseurs). Les organisations qui exécutent les deux référentiels réutilisent ces preuves plutôt que de maintenir des jeux de contrôles séparés.

Type I et Type II : ce que la différence signifie en pratique

SOC 2 Type I examine si vos contrôles sont adéquatement conçus à un instant donné. Un auditeur se déplace, examine votre documentation de contrôles, et forme un avis sur l'adéquation de la conception. Type II examine si ces contrôles ont fonctionné efficacement sur une période définie — la période d'observation, typiquement six à douze mois, avec un minimum de six mois.

Les acheteurs enterprise exigent presque universellement un rapport Type II car il démontre un fonctionnement soutenu, et non seulement l'existence d'une politique. Un Type I dit que vos contrôles semblent corrects sur le papier à une date donnée. Un Type II dit qu'ils ont effectivement tourné pendant six ou douze mois sans lacunes matérielles. C'est l'artefact qui conclut les deals en procurement enterprise.

Certaines organisations utilisent un Type I comme jalon — un moyen de mettre un rapport entre les mains des clients plus rapidement pendant que la période d'observation Type II s'accumule. C'est une tactique légitime, mais les équipes sécurité des grands comptes savent ce que signifie Type I, et un Type II remplace rapidement cette attente comme standard.

Pourquoi la fenêtre d'audit est la partie difficile

La période d'observation est la partie la plus difficile de SOC 2 pour la plupart des organisations — non parce que les contrôles sont inconnus, mais parce que les preuves doivent être continues. Si les revues des accès doivent avoir lieu chaque trimestre et qu'un trimestre a été manqué, l'auditeur le constate. Si un processus de gestion des changements était documenté en janvier mais que la piste de preuves montre qu'il n'a pas été suivi en mars, c'est une déviation. Le rapport le mentionnera.

L'implication pratique est que la conformité SOC 2 n'est pas un projet que vous terminez et archivez — c'est un rythme opérationnel que vous maintenez, et l'audit est le contrôle annuel que ce rythme a tenu. C'est structurellement différent d'ISO 27001, où un organisme de certification audite un instantané et réaudite à intervalles de surveillance. La période d'observation SOC 2 est continue : chaque mois de la fenêtre compte, et chaque lacune dans les contrôles récurrents est visible.

C'est pourquoi les outils conçus pour SOC 2 se concentrent sur la collecte de preuves et la gestion des tâches récurrentes pendant la période d'observation, et non seulement sur la documentation des contrôles au départ. L'objectif est d'entrer dans l'audit avec douze mois de preuves déjà organisées, plutôt que de les reconstruire sous la pression des délais.

Ce qu'est un rapport SOC 2 et qui le lit

Un rapport SOC 2 est un document privé. Contrairement à un certificat ISO 27001, vérifiable publiquement, un rapport SOC 2 est distribué sous NDA aux clients enterprise et prospects qui le demandent lors de la due diligence fournisseur. Il n'est pas déposé auprès d'un régulateur. Il n'est pas publié sur votre site web. Il est remis, sous confidentialité, aux équipes procurement et sécurité de vos acheteurs enterprise.

Ce que ces équipes examinent : d'abord, l'opinion de l'auditeur — si elle est sans réserve (clean) ou avec réserve (contient des exceptions). Une opinion sans réserve signifie que l'auditeur a constaté que les contrôles satisfaisaient aux critères sans exceptions matérielles. Ensuite, la description du système — quels services et systèmes étaient dans le périmètre. Un périmètre étroit (« le module de facturation uniquement ») peut ne pas satisfaire un acheteur dont les données transitent par des systèmes non couverts. Enfin, le tableau des exceptions — tout contrôle qui a échoué ou dévié pendant la période d'audit, et la réponse de la direction.

Un rapport Type II avec une opinion sans réserve, un périmètre approprié et aucune exception matérielle est l'artefact qui conclut les deals enterprise où un questionnaire sécurité fournisseur seul ne suffirait pas. Le rapport est généralement renouvelé annuellement, ce qui explique pourquoi le rythme de la période d'observation est continu plutôt qu'unique.

SOC 2 et ISO 27001 : les contrôles se rapprochent, la décision non

SOC 2 et ISO 27001 couvrent un territoire de contrôles qui se recoupe — c'est pourquoi les organisations qui exécutent les deux peuvent réutiliser des preuves significatives. La différence structurelle est le livrable : ISO 27001 produit un certificat (trois ans, reconnu mondialement, vérifiable publiquement, émis par un organisme de certification accrédité) ; SOC 2 produit un rapport (distribué en privé, renouvelé annuellement, émis par un cabinet CPA agréé, standard sur le marché enterprise américain).

Pour les organisations qui vendent sur les marchés enterprise américain et européen, les deux sont courants et le recoupement des contrôles est un avantage pratique : cartographier une fois, satisfaire les deux. Pour celles qui choisissent par où commencer, la question est où se trouvent vos acheteurs. ISO 27001 est l'attente sur le marché enterprise européen et international. SOC 2 est le standard du marché américain et constitue fréquemment une case obligatoire dans le procurement des Fortune 500. Consultez la comparaison SOC 2 vs ISO 27001 pour une analyse contrôle par contrôle.

SOC 2 comme programme en continu, pas un sprint annuel

Acuna structure SOC 2 sur ses quatre volets pour que le travail se fasse en continu plutôt qu'en urgence avant l'arrivée du cabinet CPA.

Dans Comply, vous sélectionnez les Critères de services fiduciaires dans le périmètre, définissez la description du système, et rapprochez chaque critère CC de contrôles avec des responsables. La cartographie inter-référentiels s'exécute automatiquement : un jeu de contrôles d'accès CC6 construit pour SOC 2 se rapproche d'ISO 27001 A.5.15–A.5.18 sans le reconstruire.

Dans Implement, chaque contrôle porte une référence de critère CC, un responsable, un statut de mise en œuvre et une exigence de preuve. La piste d'audit est intégrée à l'enregistrement du contrôle, et non reconstruite à partir de fils de messagerie.

Dans Operate, les tâches récurrentes maintiennent la période d'observation propre : revues trimestrielles des accès, attestations mensuelles de contrôles, cycles d'évaluation fournisseurs au titre de CC9.2, et journaux de gestion des changements. Une tâche en retard apparaît comme en dépassement avant que l'auditeur ne la constate comme une lacune.

Dans Assure, le dossier d'audit se construit à partir des preuves accumulées pendant la période d'observation. Les demandes d'auditeur pour des contrôles ou éléments de preuve spécifiques sont traitées comme une vue de preuves plutôt qu'un exercice de recherche et d'assemblage. Consultez comment Acuna soutient la préparation à l'audit SOC 2.