SOC 2 ou ISO 27001 : lequel choisir pour un SaaS français, et comment préparer un premier SOC 2

Un prospect américain, ou la direction des achats d'un grand compte, réclame un « rapport SOC 2 type 2 » à un éditeur qui prépare, ou détient déjà, une certification ISO/IEC 27001. Sur un questionnaire de sécurité, les deux demandes occupent la même ligne. Elles désignent pourtant deux objets différents, émis par deux professions différentes, selon deux calendriers qui ne se rattrapent pas.

Cet article indique, pour un éditeur SaaS français qui vend aussi hors de France, quel référentiel répond à quelle demande, quand chacun peut exister et ce qui en fait le coût, puis décrit comment préparer un premier SOC 2 à partir d'un socle ISO/IEC 27001 et d'une plateforme cloud. Il ne donne aucun prix. Cette lecture est établie sur les Trust Services Criteria 2017 de l'AICPA (points of focus révisés en 2022), les critères de description SOC 2 de 2018 (révisés en 2022) et ISO/IEC 27001:2022 amendée en 2024 ; les pages officielles citées ont été vérifiées le 28 septembre 2026.

SOC 2 et ISO 27001 : un rapport d'attestation face à une certification

SOC 2, un rapport d'examen émis par un cabinet de CPA

SOC 2 appartient à la gamme SOC (System and Organization Controls) de l'AICPA, l'institut américain des experts-comptables : des services que des CPA peuvent rendre sur les contrôles d'une organisation de services. Le guide SOC 2 de l'AICPA, mis à jour le 15 octobre 2022, aide les CPA à appliquer les normes d'attestation à ces examens. Le résultat est un rapport, pas un certificat : la description du système établie par la direction de l'éditeur, et l'opinion du cabinet sur cette description et sur les contrôles. On lit souvent dans les questionnaires que SOC 2 serait une certification : c'est impropre, aucun certificat SOC 2 n'existe.

Le référentiel s'appelle Trust Services Criteria (TSC). Il couvre cinq catégories : sécurité, disponibilité, intégrité du traitement, confidentialité et vie privée. La sécurité repose sur 33 critères communs (CC1.1 à CC9.2) ; la disponibilité (A1), l'intégrité du traitement (PI1), la confidentialité (C1) et la vie privée (P1 à P8) ajoutent leurs critères propres. CC1 à CC5 reprennent les dix-sept principes de contrôle interne du COSO ; CC6 à CC9 couvrent les accès, l'exploitation, les changements et l'atténuation des risques, fournisseurs compris.

Type 1, type 2 et SOC 3

Un examen de type 2 porte sur la description du système et sur la conception et l'efficacité des contrôles tout au long d'une période ; le type 1 porte sur la description et la conception, sans opinion sur l'efficacité. Le Journal of Accountancy, publication de l'AICPA, situe le type 1 « à une date spécifiée » et le type 2 « tout au long d'une période spécifiée » (à propos du SOC 1, dont SOC 2 reprend la distinction). Un type 1 peut donc être émis dès que les contrôles sont en place ; un type 2, seulement après la clôture de la période observée.

Le rapport SOC 2 est en général d'usage restreint : il se remet à des destinataires identifiés. Le SOC 3 couvre les mêmes catégories avec moins de détail et se diffuse librement : AWS publie le sien sans accord de confidentialité et met son SOC 2 à la disposition de ses clients dans AWS Artifact.

ISO/IEC 27001, la certification d'un système de management

ISO/IEC 27001:2022, publiée en octobre 2022 et amendée en février 2024, fixe les exigences d'un SMSI. L'ISO ne certifie pas et ne délivre aucun certificat : des organismes de certification s'en chargent, et l'ISO renvoie vers l'organisme d'accréditation national ou vers la base IAF CertSearch pour vérifier leur accréditation. En France, le Cofrac accrédite les organismes qui certifient selon ISO/IEC 27001 au regard d'ISO/IEC 17021-1 et d'ISO/IEC 27006. La transition vers l'édition 2022 s'est achevée le 31 octobre 2025, date fixée par l'IAF (document MD 26).

Le cycle de certification dure normalement trois ans : audit initial en deux étapes, puis au moins un audit par année civile, surveillance ou renouvellement. Le certificat porte un périmètre ; la déclaration d'applicabilité justifie, mesure par mesure de l'annexe A, ce qui est retenu ou écarté.

Tableau comparatif

Le certificat se vérifie ; le rapport se lit, contrôle par contrôle.

Qui demande quoi, et comment lire l'exigence

La question utile est ce que l'acheteur exige par écrit. SOC 2, format de l'AICPA, parle d'abord aux équipes de risques fournisseurs habituées aux normes américaines ; ISO/IEC 27001 est plus familière des acheteurs européens, publics comme privés. Ce n'est qu'une tendance : seule la clause du contrat, de l'appel d'offres ou du questionnaire décide.

Le dernier cas ne demande ni l'un ni l'autre dans l'immédiat, mais un dossier de preuves.

Ce que l'acheteur lit dans chaque document

Dans un rapport SOC 2 type 2, un acheteur averti lit l'opinion et ses éventuelles réserves, la période, les catégories, les limites du système (le service acheté est-il dedans ?), les exceptions relevées, les sous-traitants et la méthode retenue pour eux, et les contrôles complémentaires laissés aux clients. Sur un certificat ISO/IEC 27001, il vérifie le périmètre, les dates, l'organisme et son accréditation, et peut demander la déclaration d'applicabilité.

Entre deux rapports, la couverture se discute : Microsoft indique émettre des lettres de couverture (bridge letters) la première semaine de chaque trimestre pour les trois mois précédents.

Ce qui se réutilise entre ISO 27001 et SOC 2

Les deux référentiels partagent une mécanique : risques identifiés, mesures choisies, preuves de fonctionnement. Un SMSI certifié couvre déjà une grande part des critères de gouvernance : l'appréciation des risques répond à CC3.2 (identifier et analyser les risques pesant sur les objectifs), les politiques et procédures à CC5.3, l'audit interne et la revue de direction aux évaluations continues ou ponctuelles de CC4.1.

La correspondance AICPA, un point de départ daté

L'AICPA publie une correspondance entre les TSC 2017 et ISO 27001. Sa présentation mentionne les mises à jour de mars 2020 des TSC, ni la révision de 2022 ni l'édition 2022 d'ISO/IEC 27001 : ses renvois à l'annexe A sont donc à contrôler contre la numérotation en vigueur. Une correspondance n'est pas une équivalence : une mesure ISO peut ne couvrir qu'une partie d'un critère. Les tables des outils de gouvernance, risque et conformité (GRC) se relisent de la même façon.

Du critère à la preuve technique

Critères TSC résumés, ce que le SMSI fournit déjà, et la preuve qu'une plateforme cloud doit produire sur toute la période :

Sur AWS, une partie de ces preuves s'extrait par commande. Exemple fictif pour CC7.2 : vérifier que le journal couvre toutes les régions avec validation d'intégrité, puis que les fichiers d'un trimestre n'ont été ni modifiés ni supprimés.

# Journal multirégion et validation d'intégrité activée ?
aws cloudtrail describe-trails \
  --query 'trailList[].{nom:Name,multiRegion:IsMultiRegionTrail,validation:LogFileValidationEnabled}'

# Intégrité des fichiers livrés sur le trimestre (ARN fictif)
aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:eu-west-3:111111111111:trail/journal-organisation \
  --start-time 2026-04-01T00:00:00Z --end-time 2026-06-30T23:59:59Z

La validation repose sur des fichiers de condensats livrés chaque heure, hachés en SHA-256 et signés en SHA-256 avec RSA ; sans --verbose, la commande ne signale que les échecs. Sa sortie datée est une pièce lisible par un auditeur. Pour A1.3, les restaurations planifiées d'AWS Backup (restore testing) jouent le même rôle : AWS indique que leurs résultats peuvent servir à démontrer le respect d'exigences de gouvernance.

Ce qui ne se réutilise pas

• La description du système. Le périmètre du SMSI et la déclaration d'applicabilité en fournissent la matière, pas la forme attendue par les critères de description de l'AICPA.
• La continuité des preuves. Un type 2 teste le fonctionnement des contrôles sur toute la période. Une revue d'accès trimestrielle oubliée risque d'apparaître en exception.
• Les engagements. Un rapport SOC 2 décrit les principaux engagements de service et les exigences du système. La disponibilité se juge donc sur ce que vos contrats promettent.

L'outil GRC ne remplace pas les contrôles

Une plateforme GRC centralise les preuves sans toutes les produire. Le cadre SOC 2 préconstruit d'AWS Audit Manager en donne la mesure : AWS précise que ses contrôles ne vérifient pas la conformité, ne garantissent pas la réussite d'un audit et laissent la collecte manuelle aux contrôles de procédure. Ce service ne s'active d'ailleurs plus dans de nouveaux comptes depuis le 30 avril 2026 ; AWS oriente notamment vers les packs de conformité d'AWS Config. Aucun abonnement n'exécute les revues d'accès, l'appréciation des risques ou la revue des fournisseurs.

Préparer un premier SOC 2 quand on a déjà ISO 27001

Avec un SMSI certifié et une plateforme cloud outillée, préparer un premier SOC 2 revient à combler des écarts identifiables. Nous pouvons préparer ce travail en réutilisant les contrôles ISO 27001 et en mettant en place les preuves techniques de la plateforme. Le rapport est émis par un cabinet de CPA : nous ne le délivrons pas et nous ne réalisons pas l'examen.

1. Décrire le système. Les critères de description SOC 2 de l'AICPA (2018, révisés en 2022) servent à préparer et à évaluer la description : services couverts, composants, engagements de service, sous-traitants, contrôles attendus des clients. Le périmètre ISO et la déclaration d'applicabilité en donnent la matière. Tout contrôle décrit sera testé.
2. Choisir les catégories. La sécurité, portée par les critères communs, sert de socle. La disponibilité se justifie quand les contrats promettent une disponibilité : capacité (A1.1), sauvegardes et infrastructure de reprise (A1.2), tests du plan de reprise (A1.3). La confidentialité, quand les clients confient des informations désignées confidentielles : identification et conservation (C1.1), destruction (C1.2). L'intégrité du traitement et la vie privée s'ajoutent sur demande explicite ; la vie privée compte dix-huit critères et ne se confond pas avec la conformité au RGPD (règlement général sur la protection des données).
3. Lister les écarts. Pour chaque critère retenu : la mesure ISO qui y répond, la preuve, sa fréquence, son responsable. Les points of focus des TSC servent de liste de relecture.
4. Rendre les preuves continues. Chaque contrôle récurrent décrit doit laisser une trace datée à chaque occurrence de la période. Automatiser ce qui peut l'être (journaux, configuration, restaurations planifiées, historique GitOps) et ne déclarer que des fréquences tenables : une revue promise chaque mois et tenue chaque trimestre produit des exceptions qu'une revue trimestrielle annoncée comme telle aurait évitées.
5. Traiter le fournisseur cloud comme sous-traitant. Le rapport présente chaque sous-traitant selon la méthode inclusive ou selon la méthode d'exclusion (carve-out), qui laisse les contrôles du sous-traitant hors de l'examen. Avec l'exclusion, l'éditeur montre qu'il surveille ce sous-traitant (CC9.2) : sur AWS, rapports SOC et certificats ISO se téléchargent gratuitement dans AWS Artifact ; le rapport SOC 2 d'AWS est soumis à un accord de confidentialité, à respecter quand on le remet à son auditeur. Vers l'aval, publier les contrôles attendus des clients : SSO, gestion des rôles, retrait des accès.
6. Choisir le cabinet et le cadre d'émission. Quatre vérifications avant de signer :
   • la licence du cabinet, dans CPAverify, qui reprend les données officielles des boards of accountancy des États ;
   • son inscription au programme de revue par les pairs de l'AICPA, dont le fichier public donne l'état d'inscription ; l'AICPA examine d'ailleurs des allégations visant un fournisseur de conformité proposant des services SOC, et annonce agir envers ses membres qui n'auraient pas suivi les normes, n'auraient pas été inscrits à cette revue ou n'auraient pas eu de licence ;
   • son indépendance vis-à-vis de l'outil GRC : en avril 2026, l'AICPA a publié des Ethics Staff Insights sur les accords entre cabinets et fournisseurs d'outils SOC 2, qui peuvent menacer significativement le respect de son code de conduite ;
   • le cadre d'émission : NOREA, association néerlandaise d'auditeurs informatiques, décrit des rapports SOC 2 émis selon la norme internationale ISAE 3000, qui relèvent du droit néerlandais et non des normes américaines ; faire confirmer que l'acheteur accepte ce format.

   La préparation (readiness) est une mission distincte de l'examen : celui qui prépare n'examine pas.

7. Décider du type 1. Si l'acheteur accepte un type 1 pour signer, ce premier rapport débloque la vente avant l'ouverture de la période du type 2. S'il exige un type 2, chaque semaine de retard à l'ouverture de la période repousse d'autant le rapport ; mais une période ouverte avant que les contrôles fonctionnent enregistre leurs défaillances.

Le socle de cette préparation reste le SMSI. Les étapes d'un projet de certification et le rôle de l'organisme sont décrits sur la page Accompagnement ISO 27001 : construire les preuves.

Délais, coûts et arbre de décision

Ce qui fixe la date du premier rapport ou du certificat

Pour un type 2, la date d'émission au plus tôt vaut : début de période, plus durée convenue, plus délai de rédaction du cabinet. Aucune source AICPA consultée ne fixe de durée minimale ; la durée se convient avec le cabinet et doit convenir à l'acheteur.

Les grands fournisseurs publient leurs pratiques, qui renseignent sans faire norme : AWS émet ses rapports SOC 2 et SOC 3 deux fois par an, sur des périodes de douze mois closes au 31 mars et au 30 septembre, environ neuf à dix semaines après la fin de période ; Microsoft décrit une fenêtre glissante de douze mois et un nouveau rapport tous les six mois.

Exemple fictif : une période ouverte le 1er janvier, de P mois, avec D semaines de rédaction, donne un rapport au plus tôt le 1er janvier plus P mois plus D semaines. La préparation ne raccourcit pas P ; elle réduit le risque d'exceptions.

Côté ISO, la date dépend du moment où le SMSI fonctionne réellement, puis de l'audit initial en deux étapes mené par l'organisme de certification.

Ce qui fait le coût

• Honoraires du cabinet de CPA : catégories retenues, étendue du système (services, environnements, sous-traitants inclus ou exclus), type, durée de la période, nombre de contrôles à tester.
• Audit de certification ISO : l'organisme détermine le temps d'audit selon une méthode encadrée ; pour les SMSI, l'annexe C d'ISO/IEC 27006-1:2024 part du nombre de personnes dans le périmètre. S'y ajoutent surveillances et renouvellement.
• Coûts internes : temps des équipes pour exécuter et documenter les contrôles, outil GRC, mise à niveau, préparation.

Pour un éditeur déjà certifié, le surcoût se concentre sur les honoraires du cabinet et sur les écarts décrits plus haut. Pour des devis comparables, envoyer à chaque cabinet ou organisme le même dossier : services vendus et périmètre visé ; effectif et sites ; fournisseurs cloud et sous-traitants ; catégories, type et période souhaités ; certificat ISO/IEC 27001 et déclaration d'applicabilité ; exigence de l'acheteur citée mot pour mot.

Arbre de décision

Sources officielles et limites de lecture

Limites de cette lecture :

• Textes payants ou sous inscription. Le guide SOC 2 de l'AICPA (payant) n'a pas été consulté, ni les critères de description en entier. Les types 1 et 2 sont présentés d'après les pages de l'AICPA et le Journal of Accountancy ; le texte et le décompte des critères viennent d'une table de correspondance publiée par le NIST, à jour des révisions de 2022.
• Normes ISO. Le texte d'ISO/IEC 17021-1 et d'ISO/IEC 27006-1 n'a pas été consulté ; le cycle de certification et la détermination du temps d'audit sont repris de documents de l'European co-operation for Accreditation.
• Durées et prix. Aucun n'est avancé ; les pratiques d'AWS et de Microsoft ne valent que pour leurs rapports.
• Méthodes inclusive et d'exclusion. Leur définition détaillée figure dans le guide SOC 2, non consulté ; elle est reprise ici d'après les publications de l'AICPA accessibles.

Nous préparons un premier SOC 2 en réutilisant les contrôles ISO 27001 et en mettant en place les preuves techniques, mais nous ne délivrons ni certificat ni rapport SOC 2 et ne garantissons l'issue d'aucun audit ni examen.

Sources

1. System and Organization Controls: SOC Suite of Services, AICPA & CIMA, https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services, consulté le 28/09/2026.
2. SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy, AICPA & CIMA, https://www.aicpa-cima.com/cpe-learning/publication/soc-2-reporting-on-an-examination-of-controls-at-a-service-organization-relevant-to-security-availability-processing-integrity-confidentiality-or-privacy, consulté le 28/09/2026.
3. 2017 Trust Services Criteria (With Revised Points of Focus, 2022), AICPA & CIMA, https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022, consulté le 28/09/2026.
4. NIST Privacy Framework, correspondance avec les Trust Services Criteria 2017 de l'AICPA (mises à jour de 2022 incluses), dépôt officiel usnistgov/PrivacyFrmwkResources, https://raw.githubusercontent.com/usnistgov/PrivacyFrmwkResources/master/resources/AICPA%20TSC%20Crosswalk/NIST-Privacy-Framework-Version1-Crosswalk-AICPA-Trust-Services-Criteria-Mapping.xlsx, consulté le 28/09/2026.
5. 2018 SOC 2 Description Criteria (With Revised Implementation Guidance, 2022), AICPA & CIMA, https://www.aicpa-cima.com/resources/download/get-description-criteria-for-your-organizations-soc-2-r-report, consulté le 28/09/2026.
6. Mapping: 2017 Trust Services Criteria to ISO 27001, AICPA & CIMA, https://www.aicpa-cima.com/resources/download/mapping-2017-trust-services-criteria-to-iso-27001, consulté le 28/09/2026.
7. SOC 3, SOC for Service Organizations: Trust Services Criteria for General Use Report, AICPA & CIMA, https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-3, consulté le 28/09/2026.
8. Explaining the 3 faces of SOC, Journal of Accountancy (AICPA), https://www.journalofaccountancy.com/newsletters/2016/jun/3-face-of-soc/, consulté le 28/09/2026.
9. FAQs on SOC 2 and SOC 3 engagements issued by AICPA staff, Journal of Accountancy (AICPA), https://www.journalofaccountancy.com/news/2020/dec/aicpa-issues-faqs-on-soc-2-soc-3-engagements/, consulté le 28/09/2026.
10. Ethics Staff Insights: Business arrangements with SOC tool providers, AICPA & CIMA, https://www.aicpa-cima.com/resources/article/esi-soc, consulté le 28/09/2026.
11. For the public (Peer Review Public File), AICPA & CIMA, https://www.aicpa-cima.com/resources/article/for-the-public, consulté le 28/09/2026.
12. CPAverify, NASBA, https://cpaverify.org/, consulté le 28/09/2026.
13. Update en Engelse vertaling Handreiking SOC 2 en 3 Rapporten, NOREA, https://www.norea.nl/nieuws/update-en-engelse-vertaling-handreiking-soc-2-en-3-rapporten, consulté le 28/09/2026.
14. ISO/IEC 27001:2022, Information security management systems, Requirements, ISO, https://www.iso.org/standard/27001, consulté le 28/09/2026.
15. ISO/IEC 27001:2022/Amd 1:2024, ISO, https://www.iso.org/standard/88435.html, consulté le 28/09/2026.
16. Certification, ISO, https://www.iso.org/certification.html, consulté le 28/09/2026.
17. ISO/IEC 27006-1:2024, Requirements for bodies providing audit and certification of information security management systems, Part 1: General, ISO, https://www.iso.org/standard/82908.html, consulté le 28/09/2026.
18. Auditing Practices Note: Statement of Applicability, ISO/IEC JTC 1/SC 27/WG 1, https://committee.iso.org/files/live/sites/jtc1sc27/files/resources/ISO-IECJTC1-SC27-WG1_N3298_Auditing%20Practices%20Note%20-%20SoA.pdf, consulté le 28/09/2026.
19. IAF MD 26:2023, Transition requirements for ISO/IEC 27001:2022, IAF, https://iaf.nu/iaf_system/uploads/documents/IAF_MD26_Issue_2_15012023.pdf, consulté le 28/09/2026.
20. Certification of management systems (transition numérique et cybersécurité), Cofrac, https://www.cofrac.fr/en/our-fields-of-application/digital-transition-and-cybersecurity/certification-of-management-systems, consulté le 28/09/2026.
21. Question 37.12, ISO 17021-1:2015, clause 9.1.3, European co-operation for Accreditation, https://european-accreditation.org/sp_accordion_faqs/question-37-12-iso-17021-12015-clause-9-1-3/, consulté le 28/09/2026.
22. Question 48.6, Audit time determination to ISO/IEC 27006-1:2024, determination of initial number of persons (C.3.4), European co-operation for Accreditation, https://european-accreditation.org/sp_accordion_faqs/question-48-6-audit-time-determination-to-iso-iec-27006-12024-determination-of-initial-number-of-persons-c-3-4/, consulté le 28/09/2026.
23. SOC FAQs, AWS, https://aws.amazon.com/compliance/soc-faqs/, consulté le 28/09/2026.
24. What is AWS Artifact?, AWS, https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html, consulté le 28/09/2026.
25. System and Organization Controls (SOC) 2 Type 2, Microsoft Learn, https://learn.microsoft.com/en-us/azure/compliance/offerings/offering-soc-2, consulté le 28/09/2026.
26. SSAE-18 SOC 2, AWS Audit Manager, https://docs.aws.amazon.com/audit-manager/latest/userguide/SOC2.html, consulté le 28/09/2026.
27. AWS Audit Manager availability change, AWS, https://docs.aws.amazon.com/audit-manager/latest/userguide/audit-manager-availability-change.html, consulté le 28/09/2026.
28. Validating CloudTrail log file integrity, AWS, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-intro.html, consulté le 28/09/2026.
29. Validating CloudTrail log file integrity with the AWS CLI, AWS, https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-log-file-validation-cli.html, consulté le 28/09/2026.
30. Trail (type de données de l'API CloudTrail), AWS, https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_Trail.html, consulté le 28/09/2026.
31. Restore testing, AWS Backup, https://docs.aws.amazon.com/aws-backup/latest/devguide/restore-testing.html, consulté le 28/09/2026.