SOC 2 dans le cloud : réussir son rapport

SOC 2 est devenu le sésame commercial des éditeurs SaaS qui vendent à des grands comptes, en particulier nord-américains : sans rapport, l'achat se bloque au stade de la revue sécurité. Contrairement à une certification, SOC 2 n'atteste pas un état figé mais le fonctionnement réel de vos contrôles sur une période, jugé par un auditeur indépendant. Dans le cloud, tout l'enjeu se déplace : il ne s'agit pas seulement de configurer Azure ou AWS correctement, mais de produire la preuve que vos contrôles ont tenu, jour après jour, sur toute la fenêtre d'observation. Cette page détaille Type I contre Type II, les cinq Trust Services Criteria, la différence avec ISO 27001, et la façon de réunir les preuves sur le cloud pour réussir l'audit.

• AICPA · Trust Services
• Type I vs Type II
• 5 critères (TSC)
• Auditeur CPA indépendant
• Rapport d'attestation

Qu'est-ce que SOC 2 et qui le demande ?

SOC 2 (System and Organization Controls 2) est un cadre d'audit défini par l'AICPA, l'American Institute of Certified Public Accountants, l'organisation professionnelle des experts-comptables aux États-Unis. Il évalue la façon dont une organisation de services protège les données de ses clients, à travers un ensemble de contrôles rattachés à des critères de confiance, les Trust Services Criteria.

Le point essentiel à comprendre, et qui distingue SOC 2 de la plupart des référentiels européens, est sa nature : SOC 2 n'est pas une certification, c'est une mission d'attestation. Un auditeur indépendant, obligatoirement un cabinet CPA (Certified Public Accountant), examine vos contrôles et publie un rapport qui décrit le système, énonce les contrôles, détaille les tests menés et rend une opinion. Ce rapport est confidentiel : vous le partagez avec vos clients et prospects sous accord de confidentialité, il n'est pas public comme peut l'être un certificat ISO.

Qui le demande, concrètement ? Le mécanisme est presque toujours commercial :

• Les éditeurs SaaS B2B qui traitent les données de leurs clients. Dès qu'un prospect grand compte lance sa revue fournisseur, la question « avez-vous un rapport SOC 2 Type II ? » tombe.
• Les clients nord-américains, pour qui SOC 2 est le standard de fait. Une scale-up française qui vise le marché américain se heurte à cette exigence très tôt dans le cycle de vente.
• Les sous-traitants de données intégrés à la chaîne d'un grand compte, qui doivent prouver leur maîtrise du risque avant d'être référencés.

SOC 1, SOC 2, SOC 3 : ne pas se tromper de rapport

Trois rapports SOC coexistent, et les confondre fait perdre du temps et de l'argent. Ils répondent à des besoins différents.

Pour un éditeur SaaS, la cible est presque toujours SOC 2. Le SOC 3, dérivé du SOC 2, sert de vitrine publique sans exposer le détail des contrôles et des tests. Les rapports s'appuient sur des normes d'attestation : SSAE 18 aux États-Unis et ISAE 3000 à l'international, deux référentiels qui encadrent la façon dont l'auditeur mène sa mission.

Type I contre Type II : instant T ou période

C'est la distinction la plus importante à saisir, et celle qui structure toute la préparation.

• SOC 2 Type I

  Une photographie. L'auditeur juge, à une date donnée, si vos contrôles sont bien conçus et correctement mis en place. Il valide la conception, pas la durée. Plus rapide à obtenir, souvent utilisé comme première étape.

• SOC 2 Type II

  Un film. L'auditeur vérifie que vos contrôles ont réellement fonctionné sur une période, généralement de 3 à 12 mois. Il échantillonne des preuves tout au long de la fenêtre. C'est le rapport qui a de la valeur commerciale.

• La trajectoire habituelle

  Beaucoup d'organisations obtiennent d'abord un Type I pour rassurer vite, puis enchaînent sur une première période Type II. Ensuite, le Type II se renouvelle chaque année sur une fenêtre glissante.

La conséquence opérationnelle est décisive : un Type II ne se prépare pas la veille. Si votre revue d'accès doit être trimestrielle, l'auditeur voudra la preuve qu'elle a bien eu lieu à chaque trimestre de la période. Un contrôle activé la semaine avant la clôture ne produit aucune preuve sur les mois écoulés. La préparation consiste donc à mettre en place les contrôles, puis à les laisser tourner et générer des preuves avant de déclencher l'audit.

Les 5 Trust Services Criteria

SOC 2 s'articule autour de cinq critères de confiance. Un seul est obligatoire, les quatre autres s'ajoutent selon ce que vous vous engagez à protéger et selon les attentes de vos clients. Choisir trop de critères alourdit inutilement l'audit, en choisir trop peu affaiblit la valeur du rapport.

• Sécurité (obligatoire)

  Le socle commun, appelé Common Criteria. Protection des systèmes contre les accès non autorisés : gestion des accès, pare-feu, détection d'intrusion, gestion des changements. Présent dans tous les rapports SOC 2.

• Disponibilité

  Le système est accessible et opérationnel comme convenu. Supervision, capacité, sauvegardes et plan de reprise. Pertinent dès qu'un SLA de disponibilité est promis aux clients.

• Intégrité du traitement

  Le traitement des données est complet, valide, exact et autorisé. Contrôles de validation, rapprochements, gestion des erreurs. Clé pour les plateformes de traitement transactionnel ou financier.

• Confidentialité

  Les informations désignées comme confidentielles (données contractuelles, propriété intellectuelle) sont protégées. Chiffrement, restriction d'accès, purge en fin de vie.

• Vie privée

  Les données personnelles sont collectées, utilisées, conservées et supprimées conformément aux engagements pris. À ne pas confondre avec le RGPD : le critère « privacy » de SOC 2 est distinct, même s'il s'y articule.

En pratique, la grande majorité des éditeurs SaaS démarrent avec Sécurité + Disponibilité + Confidentialité, un trio qui couvre les attentes courantes sans surcharger le périmètre. L'intégrité du traitement et la vie privée s'ajoutent selon la nature du service et des données. La sécurité, le Common Criteria, reste la colonne vertébrale : les autres critères viennent s'y greffer.

SOC 2 face à ISO 27001 : deux logiques complémentaires

C'est la question la plus fréquente des dirigeants qui arbitrent leur feuille de route conformité. SOC 2 et ISO 27001 ne sont pas concurrents, ils répondent à des marchés et à des logiques différents. Notre page dédiée à la certification ISO 27001 dans le cloud traite le référentiel européen en profondeur ; ici, l'angle est le contraste.

La bonne nouvelle : le recouvrement est important. Un socle de sécurité solide, gestion des identités, chiffrement, journalisation, gestion des changements, sert les deux référentiels. Une organisation déjà engagée dans une démarche ISO 27001 a déjà construit une grande partie des contrôles attendus par SOC 2, et inversement. La différence tient surtout au format de la preuve et au marché visé : SOC 2 pour convaincre un acheteur américain, ISO 27001 pour un appel d'offres européen ou un grand compte international. Pour situer ces référentiels dans le panorama complet (RGPD, HDS, DORA, NIS2), voyez notre guide conformité cloud.

Responsabilité partagée et rapports SOC des fournisseurs

Le modèle de responsabilité partagée est la clé de lecture de tout projet SOC 2 dans le cloud. Il répartit les contrôles entre le fournisseur (Azure, AWS) et vous, et c'est là que se logent la plupart des malentendus.

Azure et AWS produisent chacun leurs propres rapports SOC 1, SOC 2 et SOC 3, mis à disposition de leurs clients :

• Microsoft Azure publie ses rapports SOC dans le Service Trust Portal, l'espace de confiance où vous récupérez les attestations de la plateforme.
• AWS met ses rapports SOC à disposition via AWS Artifact, le portail de téléchargement des documents de conformité.

Ces rapports vous servent de deux façons. D'abord, ils prouvent la part fournisseur du modèle de responsabilité partagée : vous n'avez pas à réauditer les datacenters d'AWS ou d'Azure, leur rapport SOC en atteste. Ensuite, ils contiennent des Complementary User Entity Controls (CUEC) : la liste des contrôles que le fournisseur suppose que vous mettez en œuvre de votre côté pour que l'ensemble tienne. Ces CUEC sont une mine d'or, ils vous disent noir sur blanc ce que l'auditeur attendra de vous.

La frontière se déplace selon le service consommé. Le tableau complet couche par couche (IaaS, PaaS, SaaS) et le principe générique « qui sécurise quoi » sont détaillés sur notre pilier sécurisation d'infrastructure cloud. Retenez la constante : vos données, vos identités et vos configurations restent toujours de votre côté, quel que soit le modèle. C'est précisément cette part qui constitue le cœur de votre rapport SOC 2.

Réunir les preuves sur le cloud : le cœur du sujet

Réussir un Type II ne se joue pas sur la sophistication de votre architecture, mais sur votre capacité à produire des preuves régulières, datées et vérifiables. Un contrôle qui fonctionne mais ne laisse aucune trace est, pour l'auditeur, un contrôle qui n'existe pas. Voici les quatre familles de preuves que vous devez outiller sur Azure ou AWS.

• Logsjournalisation centralisée, inaltérable, à rétention suffisante
• Accèsrevues d'accès périodiques, documentées et horodatées
• Changegestion des changements tracée (PR, tickets, approbations)
• Alertessupervision continue et suivi des incidents jusqu'à clôture

Journalisation et surveillance

L'auditeur veut voir que vous savez ce qui se passe dans votre environnement, et que vous le savez depuis longtemps.

• Sur Azure : centralisation via Azure Monitor et Log Analytics, journaux d'activité du plan de contrôle (Activity Log), détection avec Microsoft Defender for Cloud. Les journaux doivent être conservés sur toute la période auditée, au minimum.
• Sur AWS : AWS CloudTrail pour tracer chaque appel d'API, CloudWatch pour les métriques et alarmes, Amazon GuardDuty pour la détection de menaces. La rétention se paramètre pour couvrir la fenêtre d'observation.

Le piège classique : une rétention de journaux trop courte. Si votre période Type II couvre six mois mais que vos logs ne remontent qu'à quatre-vingt-dix jours, vous ne pouvez pas prouver les deux premiers mois. La rétention se cale sur la période, pas sur le défaut technique.

Revues d'accès périodiques

C'est l'un des contrôles les plus testés, car les accès sont le premier vecteur d'incident. L'auditeur cherche la preuve que vous révisez régulièrement qui a accès à quoi, et que vous retirez les droits devenus inutiles.

• Azure : revues d'accès via Microsoft Entra ID (access reviews), gestion des droits d'administration à la demande avec Privileged Identity Management (PIM), MFA généralisée.
• AWS : revue des permissions via IAM Identity Center, rapports d'accès IAM, rôles temporaires plutôt que clés longue durée.

Chaque revue doit produire un artefact daté : qui a revu, quand, quelles décisions (maintien, retrait), avec la trace du retrait effectif. Une revue « faite mais non documentée » ne compte pas.

Gestion des changements

L'auditeur veut la garantie qu'aucune modification ne part en production sans contrôle. Dans un contexte cloud moderne, la preuve se trouve naturellement dans vos outils de développement.

• Traçabilité par le code : chaque changement d'infrastructure passe par une pull request revue et approuvée, versionnée en Infrastructure as Code (Terraform, Bicep). L'historique Git est une preuve d'approbation en soi.
• Tickets et rapprochement : les changements sont reliés à un système de tickets (par exemple Jira ou GitHub Issues), ce qui permet de rapprocher la demande, l'approbation et le déploiement.
• Garde-fous automatiques : les contrôles de sécurité et de conformité intégrés au pipeline CI/CD constituent une preuve continue. Cette industrialisation relève de notre page DevSecOps cloud, où le pipeline devient un instrument de preuve à part entière.

Supervision et gestion des incidents

Enfin, l'auditeur vérifie que vous détectez, tracez et clôturez les incidents. Il ne s'agit pas de prouver qu'aucun incident n'est survenu, personne ne le croirait, mais que chaque alerte a été traitée selon un processus défini, jusqu'à sa résolution documentée. Les tickets d'incident, les runbooks et les post-mortem sont ici la matière première.

Outillage : IaC, centralisation des logs, gestion des secrets

Trois choix d'outillage font la différence entre un audit laborieux et un audit fluide. Ils ne sont pas propres à SOC 2, mais ils transforment la production de preuves en sous-produit automatique de votre exploitation.

• Infrastructure as Code

  Décrire l'environnement en Terraform ou Bicep rend chaque configuration auto-documentée, versionnée et reproductible. L'historique Git prouve qui a changé quoi et quand, sans effort supplémentaire le jour de l'audit.

• Centralisation des logs

  Regrouper les journaux dans un espace dédié, protégé et inaltérable (Log Analytics, CloudWatch, ou un SIEM) fournit une source de preuve unique, requêtable, couvrant toute la période d'observation.

• Gestion des secrets

  Aucun secret en clair dans le code : ils vivent dans un coffre (Azure Key Vault, AWS Secrets Manager), avec rotation et traçabilité d'usage. Un contrôle attendu par le Common Criteria, facile à prouver s'il est outillé.

Le fil conducteur : plus vos contrôles sont codés et automatisés, plus la preuve se génère toute seule. Une revue d'accès manuelle consignée dans un tableur est fragile ; une revue outillée qui produit un rapport horodaté est robuste. La bonne nouvelle pour votre trésorerie, c'est que les capacités natives d'Azure et d'AWS couvrent l'essentiel du besoin, sans licence tierce systématique. Le durcissement technique de ce socle (IAM, chiffrement, réseau, sauvegardes) est détaillé sur notre pilier sécurisation d'infrastructure cloud.

La période d'observation et le rôle de l'auditeur

Deux notions closent la compréhension du dispositif : la fenêtre d'observation et l'indépendance de l'auditeur.

La période d'observation est la fenêtre pendant laquelle, pour un Type II, l'auditeur collecte et teste les preuves. Elle dure typiquement de 3 à 12 mois. Une première période de 3 à 6 mois est fréquente pour un premier rapport, puis on s'aligne sur une fenêtre annuelle glissante pour les renouvellements. Entre la fin de la période auditée et la date à laquelle un prospect vous demande le rapport, il peut s'écouler du temps : c'est le rôle de la lettre de transition (bridge letter), un document par lequel vous attestez qu'aucun changement significatif de contrôle n'est intervenu depuis la clôture. Cette lettre n'est pas produite par l'auditeur, elle émane de votre direction.

Le rôle de l'auditeur est strictement encadré. Seul un cabinet CPA indépendant peut émettre un rapport SOC 2. Cette indépendance est la source même de la valeur du rapport : un tiers qui n'a pas conçu vos contrôles atteste qu'ils fonctionnent. Conséquence directe : celui qui vous aide à préparer ne peut pas être celui qui audite. La préparation (cadrage, mise en place des contrôles, outillage des preuves) et l'attestation (les tests, l'opinion) relèvent de deux acteurs distincts. C'est une règle déontologique, pas une formalité.

Démarche et durée réaliste

Une préparation SOC 2 dans le cloud suit une trajectoire lisible. Les étapes ci-dessous concernent la préparation du périmètre cloud et l'outillage des preuves, en amont de l'audit mené par le cabinet CPA.

1. Cadrage du périmètre et des critères Définir le système audité (quelles applications, quels comptes cloud, quelles données) et choisir les Trust Services Criteria pertinents. La sécurité est acquise ; disponibilité, confidentialité et les autres s'ajoutent selon vos engagements clients.
2. Analyse d'écart (gap analysis) Comparer vos contrôles actuels aux critères visés, en s'appuyant notamment sur les CUEC des rapports SOC d'Azure et d'AWS. On obtient la liste priorisée de ce qui manque.
3. Mise en place des contrôles Combler les écarts : revues d'accès, journalisation, gestion des changements, chiffrement, supervision. On versionne les configurations en Infrastructure as Code pour la traçabilité.
4. Type I (optionnel mais fréquent) Faire attester la conception des contrôles à une date donnée, pour rassurer les prospects rapidement pendant que la période Type II court.
5. Période d'observation Laisser les contrôles fonctionner et générer des preuves sur la fenêtre choisie (3 à 12 mois). C'est le temps incompressible du Type II.
6. Audit Type II par le cabinet CPA L'auditeur indépendant échantillonne les preuves sur la période, teste l'efficacité et émet le rapport. Puis renouvellement annuel sur une fenêtre glissante.

Il faut distinguer deux durées, souvent confondues. La préparation du périmètre cloud représente un accompagnement de l'ordre de 3 à 10 jours de travail spécialisé. Mais la durée calendaire totale est bien plus longue : entre la décision et le premier rapport Type II, comptez plusieurs mois, l'essentiel étant la période d'observation, que rien ne permet de raccourcir. On ne « rattrape » pas des mois de preuves manquantes.

• 3 à 10 jpréparation du périmètre cloud (selon maturité)
• 7 à 18 k€budget indicatif, sur devis selon le périmètre
• 3 à 12 moispériode d'observation typique d'un Type II
• CPAseul un cabinet indépendant émet le rapport

Erreurs fréquentes qui font échouer un SOC 2

Les mêmes pièges reviennent, et chacun coûte des semaines ou une remédiation en urgence.

• Lancer l'audit trop tôt. Déclencher un Type II sans avoir laissé les contrôles générer des preuves sur la période. L'auditeur constate l'absence de traces, et la période repart.
• Choisir trop de critères. Inclure les cinq Trust Services Criteria « pour faire complet » alourdit le périmètre sans valeur commerciale réelle. On calibre sur ce que les clients demandent vraiment.
• Confondre le SOC du fournisseur et le sien. Croire que le rapport SOC d'AWS ou d'Azure couvre son propre système. Il ne couvre que la plateforme, jamais vos configurations.
• Négliger les CUEC. Ignorer les Complementary User Entity Controls listés dans le rapport du fournisseur, alors qu'ils décrivent exactement ce que l'auditeur attend de vous.
• Rétention de logs insuffisante. Une conservation plus courte que la période auditée rend certaines preuves impossibles à produire.
• Contrôles manuels non documentés. Une revue d'accès « faite de tête », un changement déployé sans trace : sans artefact daté, le contrôle est réputé inexistant.
• Confondre le critère « privacy » et le RGPD. Le critère vie privée de SOC 2 est distinct du RGPD. Ils s'articulent mais ne se substituent pas. Le panorama réglementaire complet est traité sur notre page conformité cloud.
• Mélanger préparation et audit. Demander au même acteur de préparer et d'attester. C'est déontologiquement impossible et cela invalide l'indépendance.

Pour les organisations qui traitent des données de santé américaines, SOC 2 se combine souvent avec d'autres exigences : voyez notre approche dédiée à l'architecture cloud conforme HIPAA. Et avant toute démarche, un audit de conformité cloud mesure votre écart réel face aux critères visés.

Pourquoi Architecte Cloud pour préparer votre SOC 2

Préparer un SOC 2 dans le cloud demande de descendre au niveau de la configuration Azure ou AWS tout en gardant la logique de preuve en tête. C'est exactement notre rôle d'intermédiaire indépendant : cadrer, orienter, sélectionner et coordonner, sans réaliser nous-mêmes la prestation ni l'audit.

• Indépendance. Nous ne vendons aucun cloud ni aucune licence. Notre conseil Azure contre AWS est neutre, orienté par votre besoin de preuve et votre budget.
• Réseau qualifié. Nous mobilisons des prestataires disposant des certifications requises (Azure Solutions Architect Expert, AWS DevOps Engineer Professional, CISSP, Azure Security Engineer), en démarche ISO 27001.
• Séparation des rôles. Nous préparons ; le cabinet CPA atteste. Cette frontière protège la valeur de votre rapport.
• Autonomie et réversibilité. Tout ce qui est construit vous appartient : IaC dans vos dépôts, comptes à votre nom, documentation remise. Aucun enfermement.

Pour aller plus loin, voyez nos services, notre cybersécurité cloud, l'audit FinOps pour maîtriser le coût de l'outillage, le guide du cloud et l'approche dédiée au secteur SaaS.

Vous visez un rapport SOC 2 sur un périmètre Azure ou AWS ? Faites le point en quelques minutes avec notre diagnostic en ligne, ou décrivez votre contexte via le contact : nous cadrons le périmètre, clarifions les Trust Services Criteria pertinents et vous orientons vers des prestataires qualifiés. Réponse sous 48 h ouvrées.

FAQ : SOC 2 dans le cloud

SOC 2 est-il une certification ?

Non. SOC 2 est un rapport d'attestation émis par un cabinet CPA indépendant, pas une certification délivrée par un organisme accrédité. Vous obtenez un rapport détaillé, confidentiel et partagé sous accord de confidentialité, valable pour la période auditée. Parler de « certification SOC 2 » est un raccourci courant, mais un client averti attend un rapport, pas un logo.

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

Le Type I juge la conception de vos contrôles à une date donnée : sont-ils bien pensés et en place ? Le Type II juge leur efficacité de fonctionnement sur une période, généralement de 3 à 12 mois : ont-ils réellement tourné, preuves à l'appui ? Le Type II a bien plus de valeur commerciale, car il démontre la constance dans le temps. Beaucoup d'organisations obtiennent d'abord un Type I, puis enchaînent sur une première période Type II.

Quels sont les 5 Trust Services Criteria de SOC 2 ?

La sécurité (obligatoire, appelée Common Criteria), la disponibilité, l'intégrité du traitement, la confidentialité et la vie privée. Seule la sécurité est systématiquement incluse ; les quatre autres s'ajoutent selon vos engagements clients et la nature de vos données. La plupart des éditeurs SaaS démarrent avec sécurité, disponibilité et confidentialité.

SOC 2 ou ISO 27001 : lequel choisir ?

Cela dépend du marché. SOC 2 est le standard de fait pour les clients nord-américains et l'écosystème SaaS ; ISO 27001 est attendu par les grands comptes et les appels d'offres européens et internationaux. Les deux partagent un large socle de contrôles, si bien qu'une organisation déjà avancée sur l'un a fait une grande partie du chemin vers l'autre. Beaucoup finissent par viser les deux.

Le rapport SOC 2 d'Azure ou d'AWS me couvre-t-il ?

Non. Le rapport SOC des fournisseurs couvre leur infrastructure (datacenters, hyperviseur, services managés), pas vos comptes, vos accès, votre code ni vos configurations. Il prouve la part fournisseur du modèle de responsabilité partagée et liste les contrôles qu'il attend de vous (CUEC), mais votre rapport SOC 2 porte sur votre propre système, distinct de celui du fournisseur.

Où trouver les rapports SOC d'Azure et d'AWS ?

Microsoft Azure met ses rapports SOC 1, SOC 2 et SOC 3 à disposition dans le Service Trust Portal. AWS les publie via AWS Artifact, son portail de documents de conformité. Ces rapports vous servent à attester la part fournisseur et à consulter les Complementary User Entity Controls, c'est-à-dire ce que le fournisseur suppose que vous mettez en œuvre de votre côté.

Combien de temps dure la période d'observation d'un Type II ?

Elle dure typiquement de 3 à 12 mois. Une première période de 3 à 6 mois est fréquente pour un premier rapport, puis on s'aligne sur une fenêtre annuelle glissante pour les renouvellements. Cette durée est incompressible : on ne peut pas produire rétroactivement des preuves de contrôles qui ne tournaient pas encore. C'est pourquoi un Type II se prépare des mois à l'avance.

Qui peut réaliser un audit SOC 2 ?

Seul un cabinet CPA indépendant, un expert-comptable habilité aux États-Unis, peut émettre un rapport SOC 2. Cette indépendance fonde la valeur du rapport. Conséquence : l'acteur qui vous aide à préparer les contrôles ne peut pas être celui qui les audite. La préparation et l'attestation relèvent de deux intervenants distincts, pour préserver l'objectivité de l'auditeur.

Quelles preuves faut-il réunir sur le cloud pour SOC 2 ?

Quatre familles : la journalisation centralisée et conservée sur toute la période (CloudTrail, Azure Monitor), les revues d'accès périodiques documentées (Entra ID, IAM Identity Center), la gestion des changements tracée (pull requests, tickets, Infrastructure as Code) et le suivi des incidents jusqu'à clôture. Chaque preuve doit être datée, vérifiable et régulière : un contrôle sans trace est réputé inexistant.

Combien coûte la préparation d'un SOC 2 dans le cloud ?

Pour la préparation du périmètre cloud et l'outillage des preuves, le budget indicatif se situe généralement entre 7 000 et 18 000 €, pour 3 à 10 jours d'accompagnement, sur devis selon le périmètre et la maturité de départ. Ce montant ne comprend pas les honoraires du cabinet CPA qui mène l'attestation, facturés séparément par l'auditeur que vous retenez.

Qu'est-ce qu'une lettre de transition (bridge letter) ?

C'est un document par lequel votre direction atteste qu'aucun changement significatif de contrôle n'est intervenu entre la fin de la période auditée et une date ultérieure, souvent celle où un prospect vous demande le rapport. Elle comble l'écart temporel entre la clôture de l'audit et la demande. Elle émane de vous, pas de l'auditeur, et ne remplace jamais un nouveau rapport.

Le critère « vie privée » de SOC 2 équivaut-il au RGPD ?

Non. Le critère vie privée (privacy) de SOC 2 évalue si vous traitez les données personnelles conformément à vos propres engagements et aux critères de l'AICPA. Le RGPD est une obligation légale européenne distincte, avec ses propres exigences (articles 28 et 32, registres, bases légales). Les deux s'articulent et se renforcent, mais l'un ne dispense jamais de l'autre.