Plongée profonde SOC 2

1. Aperçu

Qu'est-ce que le SOC 2

SOC 2 (System and Organization Controls 2) est un mission d'attestation effectué par un cabinet de CPA agréé selon les normes d'attestation de l'AICPA (SSAE 21, en particulier la section AT-C 105 et la section AT-C 205). Le cabinet CPA indique si les contrôles de la société de services répondent aux Critères des services de confiance (TSC) pertinent pour une ou plusieurs des cinq catégories : sécurité, disponibilité, confidentialité, intégrité du traitement et confidentialité.

À qui s’applique-t-il

Toute organisation de services gérant les données des clients, en particulier les SaaS B2B, les services cloud, les processeurs de données et les fournisseurs de services externalisés qui ont un impact sur la sécurité, la disponibilité, la confidentialité, l'intégrité du traitement ou la confidentialité des informations des clients.

Résultat

Un indépendant rapport du commissaire aux comptes:

• SOC 2 Type I — avis sur la conception et la mise en œuvre des contrôles à un moment donné.
• SOC2 Type II — avis sur la conception, la mise en œuvre, et efficacité opérationnelle de contrôles sur une période d'observation définie (généralement 3 à 12 mois).

Le rapport n’est pas une certification — c’est une attestation CPA. Clarify Consult Partner n'est pas un cabinet CPA et ne publie pas de rapports SOC 2 ; nous préparons les clients à l’audit et représentons le programme à travers la mission. Pour une explication conviviale pour l'acheteur, lisez notre article de blog Qu'est-ce que SOC 2 (vraiment) et comment y arriver. Pour les travaux de préparation et de remédiation, consultez notre Service de conseil en conformité SOC 2.

Objectifs de haut niveau et domaines de risque

• Démontrer que les données clients sont protégées contre tout accès non autorisé
• Montrer que les niveaux de service engagés en matière de disponibilité sont respectés
• Preuve que les engagements en matière de confidentialité et de confidentialité envers les clients sont mis en œuvre
• Fournir une opinion tierce indépendante sur laquelle les acheteurs d'entreprise peuvent s'appuyer pour faire preuve de diligence raisonnable auprès des fournisseurs.

‍2. Portée et applicabilité

Éléments typiques du champ d'application

• Infrastructure de production hébergeant les données clients
• Plateformes SaaS et API orientées client
• Systèmes de gestion des identités et des accès
• Outils de sécurité : SIEM, EDR, scanners de vulnérabilités, gestion des secrets
• Processus opérationnels : gestion du changement, réponse aux incidents, gestion des risques, gestion des fournisseurs
• Employés et sous-traitants ayant un accès logique ou physique aux systèmes de production
• Fournisseurs et organisations de sous-services prenant en charge le traitement des données de production ou des clients

Éléments courants hors de portée

• Systèmes internes d'entreprise non connectés à la prestation de services
• Sites Web de marketing (sauf s'ils sont liés à l'authentification ou aux données du client)
• Systèmes RH (sauf traitement des données clients)
• Appareils personnels hors du contrôle de l'entreprise (BYOD sans couverture MDM)

Organisations de sous-services – Méthode d'exclusion ou méthode inclusive

Si votre service s'appuie sur une organisation de sous-services (par exemple, AWS, GCP, Azure, Snowflake ou un processeur de paiement), vous devez le divulguer dans la description de votre système et choisir la manière dont ses contrôles sont gérés :

• Méthode d'exclusion : les contrôles de l'organisation de sous-services sont exclus de la portée de votre rapport. Vous répertoriez les contrôles que l'organisation de sous-services est censée effectuer (le Contrôles complémentaires de l'organisation des sous-services, ou CSOC) afin que les utilisateurs du rapport comprennent la dépendance. C'est le choix le plus courant.
• Méthode inclusive: les contrôles de l'organisation de sous-services sont testés dans le cadre de votre audit. Nécessite leur coopération et est rarement utilisé dans la pratique.

Contrôles complémentaires des entités utilisateur (CUEC)

La description du système doit également divulguer les contrôles que l'entité utilisatrice (votre client) est censée mettre en œuvre pour atteindre les TSC. Les exemples incluent l'application de politiques de mot de passe fortes sur les comptes qu'ils gèrent, la configuration correcte du SSO et l'examen des journaux d'audit que vous fournissez. Ceux-ci sont répertoriés dans le rapport afin que les clients connaissent leurs responsabilités.

Hypothèses et dépendances

• L'infrastructure cloud est configurée selon une référence (CIS Benchmarks ou meilleures pratiques du fournisseur)
• Le fournisseur d'identité prend en charge l'application de SSO et MFA au niveau organisationnel
• Les pratiques d'ingénierie incluent le suivi des modifications et la révision du code (historique git, enregistrements d'approbation des relations publiques)
• L'inventaire des fournisseurs est à jour et classé en fonction des risques

‍

3. Principes fondamentaux (critères des services de confiance)

Les critères des services de confiance ont été publiés par l'AICPA en 2017 et actualisés avec des mises à jour des points d'intérêt en 2022. Ils sont organisés en cinq catégories. La sécurité est requise dans chaque engagement SOC 2 ; les quatre autres sont ajoutés lorsqu'ils sont pertinents pour les engagements de service.

CatégorieFocusSécurité (Critères communs, CC1 à CC9) Protéger les systèmes contre tout accès, utilisation, divulgation, modification ou destruction non autorisés Disponibilité (A1) S'assurer que le système est opérationnel et accessible conformément aux engagements de l'entité Confidentialité (C1) Protéger les informations désignées comme confidentielles contre toute divulgation non autorisée Intégrité du traitement (PI1) Garantir que le traitement du système est complet, valide, précis, opportun et autorisé Confidentialité (P1 à P8) Gérer les informations personnelles conformément à l'avis de confidentialité de l'entité et Principes de confidentialité de l'AICPA

Chaque critère est appuyé par points de concentration — les caractéristiques de contrôle spécifiques que les auditeurs recherchent lorsqu'ils évaluent si le critère est rempli. Les points d’intérêt sont des orientations et non des listes de contrôle obligatoires, mais les auditeurs s’attendent à ce que la plupart d’entre eux soient abordés sous une forme ou une autre.

‍

4. Panne du contrôle

Le résumé structuré ci-dessous couvre les catégories des Critères communs (CC) et les quatre critères supplémentaires.

CC1 — Environnement de contrôle

But: Établir une gouvernance, une structure et une responsabilité de haut niveau.
Attentes minimales : Rôles et responsabilités définis ; code de conduite; vérifications des antécédents ; contrôle organisationnel.
Preuve: Organigrammes, dossiers RH, code de conduite signé, procès-verbaux du conseil d'administration couvrant la supervision de la sécurité.
Lacunes courantes : Aucun rôle documenté ; pas de contrôles RH périodiques ; aucune preuve de surveillance de la direction.
Exemple: Examen annuel de la direction des responsabilités organisationnelles, documenté dans le procès-verbal de l'examen de direction.
Cartographie : ISO 27001 articles 5 et 7.

CC2 — Communication et information

But: Veiller à ce que les informations de sécurité pertinentes soient communiquées en interne et en externe.
Attentes minimales : Politiques communiquées au personnel ; processus de notification des incidents de sécurité ; engagements envers les clients publiés.
Preuve: Accusés de réception, achèvement de la formation, journaux de communication.
Lacunes courantes : Politiques obsolètes, pas de flux de travail d'accusé de réception.
Cartographie : ISO 27001 Annexe A 6.3, 5.1.

CC3 — Évaluation des risques

But: Identifier et gérer les risques pour les objectifs.
Attentes minimales : Méthodologie des risques documentée ; registre des risques ; les décisions de traitement ; examen périodique.
Preuve: Registre des risques, plan de traitement, approbations d'acceptation des risques.
Lacunes courantes : Registre des risques traité comme un exercice ponctuel ; aucun lien avec les actions thérapeutiques.
Cartographie : ISO 27001, articles 6.1, 8.2, 8.3. Voir notre Service d'évaluation des risques.

CC4 — Activités de surveillance

But: Détectez et répondez aux problèmes qui affectent les contrôles.
Attentes minimales : Surveillance continue ; auto-évaluation du contrôle périodique ; programme d'audit interne.
Preuve: Tableaux de bord de suivi, rapports d'audit interne, suivi des déficiences.
Lacunes courantes : Pas de cycle d'audit interne ; alertes non réglées.
Cartographie : ISO 27001 articles 9.1, 9.2.

CC5 — Activités de contrôle

But: Mettre en œuvre des politiques, des procédures et des contrôles technologiques qui atténuent les risques identifiés.
Attentes minimales : Les politiques se traduisent par des contrôles mis en œuvre ; la technologie soutient les objectifs de contrôle ; séparation des tâches, le cas échéant.
Preuve: Documents de politique, lignes de base de configuration, preuves de ségrégation, rapports système.
Lacunes courantes : Des politiques existent mais les contrôles ne sont pas appliqués ; les solutions de contournement manuelles prolifèrent.

CC6 — Accès logique et physique

But: Restreindre l’accès aux systèmes et aux données.
Attentes minimales : Cycle de vie de l'identité (provisionnement, modification, déprovisionnement) ; MAE ; moindre privilège; examens périodiques des accès.
Preuve: Tickets de provisionnement d’accès, attestations de révision d’accès trimestrielles, dossiers d’inscription MFA.
Lacunes courantes : Déprovisionnement lent ; accès privilégié obsolète; application incohérente de l’AMF.
Cartographie : ISO 27001 Annexe A 5.15-5.18, 8.2-8.5.

CC7 — Opérations système

But: Détectez, répondez et récupérez des événements de sécurité.
Attentes minimales : Journalisation et surveillance ; procédures de réponse aux incidents ; tests de récupération.
Preuve: Exportations SIEM, enregistrements d'incidents, revues post-incident, résultats de tests DR.

CC8 — Gestion du changement

But: Contrôlez les modifications apportées à l’infrastructure, aux données, aux logiciels et aux procédures.
Attentes minimales : Processus de changement documenté ; révision du code ; essai; Ségrégation entre développement et production.
Preuve: Approbations des demandes d'extraction, enregistrements de modifications, journaux de déploiement.

CC9 — Atténuation des risques

But: Identifier, sélectionner et développer des activités d'atténuation des risques, y compris la gestion des risques liés aux fournisseurs.
Attentes minimales : Inventaire du fournisseur ; diligence raisonnable par niveau de risque ; surveillance continue des fournisseurs ; planification de la continuité des activités.
Preuve: Évaluations des risques des fournisseurs, exigences de sécurité contractuelles, résultats des tests BCP.

Catégories TSC supplémentaires

Disponibilité (A1) — SLA de disponibilité, planification de la capacité, protection de l'environnement, tests de reprise après sinistre. Preuve : mesures de disponibilité, rapports de test DR, tableaux de bord de capacité. ISO 27001 Annexe A.5.30, A.8.13–A.8.14.

Confidentialité (C1) — Classification des données, cryptage, accès restreint, élimination sécurisée. ISO 27001 Annexe A.5.12, A.8.10–A.8.12.

Intégrité du traitement (PI1) — Validation des entrées, contrôles de traitement, vérification des sorties. Moins courant dans la cartographie ISO 27001.

Confidentialité (P1 à P8) — Avis, consentement, limites de collecte, utilisation et conservation, droits d'accès, divulgation, sécurité, surveillance et application. Correspond étroitement aux principes ISO 27701 et RGPD.

‍

5. Exigences minimales (non négociables)

Documents obligatoires

• Description du système (l'artefact narratif central - voir la section 8)
• Politique de sécurité des informations et politiques associées (accès, incident, reprise après incident, gestion des modifications, fournisseur, chiffrement, conservation des données)
• Évaluation des risques et plan de traitement
• Inventaire des actifs
• Diagrammes de flux de données couvrant chaque système concerné
• Documentation de gestion des fournisseurs, y compris toutes les organisations de sous-services découpées
• Plan de réponse aux incidents et journal des incidents
• Plan de reprise après sinistre et de continuité des activités, ainsi que les résultats des tests annuels
• Contrôles complémentaires d'entité utilisateur (CUEC) – attentes documentées de vos clients
• Contrôles complémentaires des organisations de sous-services (CSOC) – attentes documentées des organisations de sous-services découpées

Processus obligatoires

• Vérification des antécédents (ou vérification équivalente)
• Intégration/désintégration avec fourniture et révocation d'accès en temps opportun
• Examens d'accès trimestriels avec attestation documentée
• Gestion du changement avec révision et approbation du code
• Gestion des correctifs avec des SLA basés sur les risques
• Analyse des vulnérabilités (au moins mensuellement ; hebdomadairement de préférence)
• Formation de sensibilisation à la sécurité, minimum annuel, plus formation spécifique au rôle

Contrôles techniques (référence)

• MFA sur tous les accès administratifs et distants
• Chiffrement en transit (TLS 1.2 ou 1.3) et au repos (clés gérées par KMS)
• Journalisation, surveillance et alerte centralisées sur les événements critiques
• Protection des points de terminaison sur les appareils gérés par l'entreprise
• Sauvegardes et procédures de récupération testées

Récurrence

• Évaluation annuelle des risques
• Examens d'accès trimestriels
• Examens annuels des politiques
• Table de réponse annuelle aux incidents ou test en direct
• Test DR annuel
• Analyse continue des vulnérabilités et correctifs
• Type II uniquement : les preuves doivent être conservées pendant toute la période d’observation – généralement 3 à 12 mois – pour chaque contrôle récurrent

‍

6. Conseils de mise en œuvre technique

Sécurité des infrastructures

• Renforcez les ressources cloud en utilisant Références CEI (AWS Foundations, Azure, GCP, Kubernetes)
• Appliquer des groupes de sécurité et des règles réseau de moindre privilège
• Utilisez l'infrastructure en tant que code avec des garde-fous de stratégie en tant que code (Terraform + OPA, AWS Config, Azure Policy)

Contrôle d'accès

• Appliquer SSO et MFA au niveau du fournisseur d'identité
• Accès basé sur les rôles avec recertification périodique
• Déprovisionnement automatisé lors du départ (SCIM ou scripté)
• Accès privilégié révisé mensuellement ; accès standard trimestriel

Journalisation et surveillance

• Agrégation centralisée des journaux dans les journaux du cloud, des applications et des identités
• Alertes adaptées aux événements critiques (élévation de privilèges, accès anormal, falsification d'outils de sécurité)
• Conservation en ligne d'au moins 90 jours ; Une rétention totale de 12 mois est typique

Gestion des vulnérabilités

• Analyses automatisées hebdomadaires de l'infrastructure et des applications cloud
• Correction basée sur le SLA : critique dans les 30 jours, élevée dans les 60 jours, moyenne dans les 90 jours
• Externe tests d'intrusion au moins une fois par an

Sauvegarde et reprise après sinistre

• Sauvegardes immuables avec copies hors ligne ou entre régions
• Objectifs de temps de récupération et de point de récupération définis par système
• Test de basculement annuel DR avec résultats documentés

Cryptage

• TLS 1.2+ pour les données en transit (1.3 préféré) ; HSTS appliqué
• Clés gérées par KMS pour le chiffrement au repos avec rotation des clés documentée
• Clés gérées par le client proposées là où cela est requis contractuellement

Suggestions d'outillage (neutre)

• SIEM : tout SIEM cloud natif ou tiers avec des détections pertinentes pour le TSC
• Automatisation de la conformité : Drata, Vanta, Secureframe, ControlMap – utiles pour la collecte de preuves, ne remplacent jamais la conception des contrôles
• EDR / gestion des vulnérabilités : selon les préférences de l'organisation

‍

7. Exigences en matière de politiques et de procédures

Les documents typiques comprennent :

• Politique de sécurité des informations
• Politique de contrôle d'accès
• Politique de gestion des actifs
• Politique de journalisation et de surveillance
• Plan de réponse aux incidents
• Plan de reprise après sinistre et de continuité des activités
• Politique de gestion du changement
• Politique de gestion des risques liés aux fournisseurs
• Politique de cryptage
• Politique de conservation et de suppression des données
• Politique de confidentialité (si critères P inclus)
• Description du système avec CUEC et CSOC

Chaque document doit définir :

• But
• Portée
• Rôles et responsabilités
• Processus et procédures
• Contrôles et attentes
• Fréquence d'examen (généralement minimum annuel)

Pour les organisations qui poursuivent également la norme ISO 27001, la plupart de ces documents peuvent être réutilisés avec des ajouts mineurs de portée. Voir notre Service de conseil ISO 27001 pour l’approche dualiste.

‍

8. Éléments probants et vérification

La description du système (DC1 à DC9)

La description du système est l’artefact narratif central d’un engagement SOC 2. Les auditeurs testent les contrôles qui y sont décrits ; rapportez que les utilisateurs (vos clients) le lisent pour comprendre votre service. Les critères de description de l'AICPA (sections DC) définissent ce qu'ils doivent couvrir :

• DC1 — Types de services fournis
• DC2 — Principaux engagements de service et exigences du système
• DC3 — Composants du système : infrastructure, logiciels, personnes, procédures, données
• DC4 — Incidents de système survenus au cours de la période d'observation et résultant de contrôles ne fonctionnant pas efficacement
• DC5 — Critères applicables aux services de confiance et contrôles associés conçus pour fournir une assurance raisonnable
• DC6 — Contrôles complémentaires des entités utilisatrices (CUEC) — contrôles supposés dans la conception que les entités utilisatrices doivent mettre en œuvre
• DC7 — Contrôles complémentaires de l'organisation de sous-services (CSOC) — si vous utilisez la méthode d'exclusion, les contrôles attendus de l'organisation de sous-services
• DC8 — Critères spécifiques non pertinents pour la société de services, avec justification
• DC9 — Changements significatifs au cours de la période d'observation (type II uniquement)

Ce que demandent les auditeurs

• Description du système
• Diagrammes d'architecture
• Remerciements en matière de politique
• Accéder aux tickets de provisionnement et consulter les enregistrements
• Tickets de gestion du changement
• Dossiers d'incident et examens post-incident
• Exportations d'outils de sécurité (analyses de vulnérabilités, alertes EDR, détections SIEM)
• Preuves d'intégration et de désintégration des RH
• Évaluations des risques des fournisseurs et engagements contractuels en matière de sécurité

Formats

• Captures d'écran (horodatées, montrant la date du test et le système mis en évidence)
• Billets (exports Jira, Linear, ServiceNow)
• Journaux (exportations CSV depuis SIEM ou journalisation cloud native)
• Notes de réunion (revue de direction, revues d'incidents, revues de risques)

Échantillonnage

Les échantillons de type II comprennent généralement 25 à 40 éléments par zone de contrôle, plus grands pour les examens d'accès et la gestion des modifications. Le cabinet CPA sélectionne des échantillons de manière aléatoire tout au long de la période d’observation.

Éléments de correction courants

• Workflows d'approbation manquants pour les modifications
• Mauvais horodatage des preuves (aucune preuve que le contrôle a été exécuté à la bonne date)
• Propriété du contrôle peu claire
• Fourniture d'accès incohérente
• CUEC ou CSOC obsolètes qui ne correspondent pas à la réalité actuelle

Un examen préalable à l'audit indépendant — généralement formulé sous la forme d'une évaluation de l'état de préparation SOC 2 ou dans le cadre d'un programme d'audit interne – détecte ces problèmes avant le cabinet CPA.

‍

9. Considérations sur le calendrier de mise en œuvre

Durée typique

• Tapez I: 4 à 12 semaines entre le lancement et le rapport, en fonction de la maturité des contrôles existants
• Type II: l'audit lui-même se déroule quelques semaines après la période d'observation, mais la période d'observation ajoute 3 à 12 mois. Un premier rapport type II couvre une période d’observation de 3 mois ; les rapports ultérieurs couvrent généralement 12 mois

Pont de type I à type II

De nombreuses organisations délivrent un type I pour démontrer leur préparation aux clients, puis passent au type II une fois qu'elles disposent de plus de 3 mois de preuves opérationnelles. La transition ne relance pas l’engagement : les contrôles décrits dans le rapport de type I deviennent les contrôles testés au cours de la période d’observation de type II.

Lettre de pont

Entre les rapports de type II, les clients peuvent demander une lettre relais de la direction (et parfois contresignée par le cabinet CPA) confirmant qu'aucun changement important de contrôle n'a été apporté depuis le dernier rapport. Les lettres de transition de gestion peuvent être préparées en interne ; Les lettres de transition signées par le CPA nécessitent la participation du cabinet CPA.

Jalons

• Cadrage et sélection TSC
• Évaluation des écarts
• Assainissement
• Rédaction de la description du système
• Configuration de la collecte de preuves
• Examen de l'état de préparation à l'audit
• Travaux de terrain en audit (cabinet CPA)
• Rapport publié

Dépendances

• Achèvement de la politique
• Embauche ou accès à des rôles de sécurité (souvent soutenus par un Engagement vCISO)
• Maturité de référence du cloud
• Rapports d'organisation de sous-services disponibles (les rapports AWS, GCP, Azure SOC 2 sont publics)

‍

10. Exigences continues du BAU en matière de sécurité

• Examens d'accès trimestriels avec attestation documentée
• Analyse continue des vulnérabilités et correction basée sur les risques
• Cadence mensuelle des correctifs
• Formation annuelle de sensibilisation à la sécurité et formation spécifique aux rôles pour les ingénieurs et les administrateurs
• Actualisation annuelle de l’évaluation des risques
• Test annuel de DR et de réponse aux incidents
• Examens des risques des fournisseurs selon une cadence de risque
• Mises à jour de l'inventaire des actifs à mesure que les systèmes sont ajoutés ou retirés
• Journalisation, alerte et réponse sur appel aux événements de sécurité
• Collecte de preuves pour les périodes d'observation de type II (continues et non par rafales)

‍

11. Niveaux de maturité

Conformité minimale

• Politiques en place et reconnues par le personnel
• Contrôles mis en œuvre mais en grande partie manuels
• Outils de base pour la journalisation, l'AMF et l'analyse des vulnérabilités
• Examens manuels et collecte de preuves

Intermédiaire

• Provisionnement et déprovisionnement automatisés des utilisateurs
• Surveillance mature avec alertes optimisées
• Procédures documentées avec les propriétaires nommés
• Outil d'automatisation de la conformité intégré pour la collecte de preuves

Avancé

• Automatisation complète de l'IAM, du CI/CD et de la surveillance
• Conformité continue aux contrôles et preuves vérifiées quotidiennement
• Analyse prédictive des risques et intégration des renseignements sur les menaces
• Preuves intégrées de SOC 2, ISO 27001, ISO 27701 et de gouvernance de l'IA

‍

12. FAQ

Le SOC 2 est-il obligatoire ?

Non. SOC 2 n’est pas une exigence réglementaire : il s’agit d’une norme d’assurance axée sur le client. Les clients d'entreprise B2B et les équipes d'approvisionnement en ont régulièrement besoin avant de signer.

Quelle est la durée de validité d'un rapport SOC 2 ?

Un rapport SOC 2 couvre un moment précis (Type I) ou une période d'observation définie (Type II). Les clients traitent généralement le rapport comme « à jour » pendant 12 mois après la date du, souvent complété par une lettre de transition pour l'écart jusqu'au prochain rapport.

Avons-nous besoin des cinq critères des services de confiance ?

Seule la sécurité (critères communs) est requise. La disponibilité, la confidentialité, l'intégrité du traitement et la confidentialité sont ajoutées lorsque les engagements de service les rendent pertinents. La plupart des engagements SaaS B2B incluent la sécurité ainsi que la disponibilité et la confidentialité.

SOC 2 est-il identique à ISO 27001 ?

Non, mais il existe un chevauchement important des contrôles : généralement 65 à 75 % des contrôles sous-jacents sont répartis dans les deux. De nombreuses organisations élaborent un programme de sécurité unique et rendent compte des deux normes. Voir le Page de services ISO 27001 pour l’approche dualiste.

Pouvons-nous utiliser un outil d’automatisation de la conformité ?

Oui : Drata, Vanta, Secureframe, ControlMap et des outils similaires accélèrent considérablement la collecte de preuves. Ils ne remplacent pas la conception des contrôles, la correction des lacunes ou la préparation d’un audit.

Combien de temps faut-il pour obtenir un SOC 2 Type I par rapport au Type II ?

Un engagement de type I dure de 4 à 12 semaines pour un SaaS B2B typique, en fonction de la maturité actuelle. Un type II nécessite en plus une période d'observation supplémentaire de 3 à 12 mois – vous ne pouvez pas compresser la période d'observation, car c'est tout l'intérêt d'un type II.

Combien coûte un rapport SOC 2 ?

Coûts divisés en deux parties. Les honoraires d'audit du cabinet CPA s'élèvent généralement entre 20 000 et 60 000 dollars pour un type II, en fonction de la portée et de la complexité du rapport. Les coûts de conseil et de remédiation varient en fonction de l'écart entre l'état actuel et l'état de préparation à l'audit. C'est là que la portée de la mission de Clarify Consult Partner est définie après l'évaluation initiale des écarts.

Avons-nous besoin d’un cabinet de CPA ou notre consultant peut-il rédiger le rapport ?

Le rapport SOC 2 ne peut être émis que par un cabinet CPA agréé. Les consultants préparent la description du système, comblent les lacunes en matière de contrôle et représentent le programme à travers l'engagement. Nous nous coordonnons avec le cabinet CPA mais ne publions pas le rapport.

Quelle est la différence entre SOC 1, SOC 2 et SOC 3 ?

SOC 1 couvre les contrôles pertinents à l’information financière (CIIF). SOC 2 couvre les contrôles pertinents aux critères des services de confiance (sécurité, disponibilité, confidentialité, intégrité du traitement, confidentialité). SOC3 est un rapport à usage général destiné au public et basé sur le même examen SOC 2 : plus court, sans descriptions de contrôle détaillées, adapté au marketing ou aux centres de confiance.

Qu'est-ce qu'une lettre relais ?

Une lettre de transition (ou lettre d'écart) couvre la période entre la fin d'une période d'observation SOC 2 Type II et le début de la suivante, confirmant qu'aucun changement important de contrôle n'a eu lieu. La direction peut les émettre directement ; Les versions signées par le CPA nécessitent l'implication du cabinet d'audit.

Que sont les CUEC et les CSOC ?

Les CUEC (Complementary User Entity Controls) sont des contrôles que vos clients doivent mettre en œuvre pour atteindre les TSC – par exemple, configurer correctement le SSO. Les CSOC (Complementary Subservice Organization Controls) sont des contrôles attendus des organisations de sous-services découpés, par exemple la sécurité physique d'AWS. Les deux doivent être divulgués dans la description de votre système.

Quand devrions-nous passer du type I au type II ?

Dès que vous disposez de plus de 3 mois de preuves opérationnelles pour les contrôles décrits dans votre rapport de type I. La plupart des émetteurs SaaS B2B effectuent le type I au cours des mois 1 à 3, puis démarrent une période d'observation de type II qui se termine 6 à 12 mois plus tard.

‍

13. Résumé

SOC 2 fournit une assurance indépendante qu'une organisation de services protège les données des clients et applique des contrôles efficaces alignés sur les critères de services de confiance de l'AICPA. L'obtention de l'attestation SOC 2 nécessite une gouvernance bien définie, des processus documentés, des garanties techniques, une discipline opérationnelle cohérente et une description du système crédible que les auditeurs peuvent tester et sur laquelle les clients peuvent s'appuyer.

Avec une portée appropriée, des mesures correctives systématiques et une collecte continue de preuves tout au long de la période d'observation, les organisations peuvent obtenir et maintenir des rapports de type I et de type II avec des délais et des coûts prévisibles.

Pour définir un engagement, réservez un appel depuis le Page du service de conseil SOC 2, ou parlez-nous de la combinaison de SOC 2 avec ISO 27001, ISO 27701, ou ISO 42001 pour les services de gestion de l'IA. Pour un cas pratique de superposition de la gouvernance de l'IA sur un SMSI existant, consultez notre article de blog approfondi. Comment intégrer ISO 42001 à ISO 27001 sans reconstruire votre SMSI.

‍