Les Trust Services Criteria SOC 2 : Guide complet

Points clés

Point	Résumé
Cinq critères	Security (obligatoire), Availability, Processing Integrity, Confidentiality et Privacy (tous optionnels)
Commencez ciblé	Beaucoup de premiers audits incluent uniquement Security + Availability
Security est obligatoire	Aussi appelé "Common Criteria" - couvre 9 catégories de contrôles (CC1-CC9)
Chevauchement significatif	De nombreux contrôles satisfont plusieurs critères, ce qui réduit l'effort additionnel
Étendez progressivement	Des critères additionnels peuvent être ajoutés les années suivantes selon les besoins clients

En bref : SOC 2 comprend 5 Trust Services Criteria. Security est obligatoire pour tous les audits. Pour un premier SOC 2, beaucoup d'organisations commencent avec Security + Availability (si elles ont des SLAs), puis considèrent des critères additionnels selon les exigences clients.

Vue d'ensemble des Trust Services Criteria

Critère	Obligatoire ?	Domaine
Security	Oui	Protection contre les accès non autorisés
Availability	Non	Uptime et accessibilité du système
Processing Integrity	Non	Traitement précis et complet
Confidentiality	Non	Protection des informations confidentielles
Privacy	Non	Gestion des informations personnelles

Security (Common Criteria) : Obligatoire

Le critère Security est obligatoire pour tout audit SOC 2. Aussi connu sous le nom de Common Criteria, il établit le socle de protection des systèmes et données contre les accès non autorisés.

Catégories de contrôles

CC1 : Environnement de contrôle

L'environnement de contrôle définit le ton de l'engagement de votre organisation envers la sécurité.

Contrôles clés :

• Supervision de la sécurité par la direction et le conseil
• Structure organisationnelle et lignes hiérarchiques
• Engagement envers la compétence et la responsabilité
• Policies et standards de sécurité

Exemples de preuves :

• Organigramme
• Documents de policy de sécurité
• Comptes-rendus de réunions de direction discutant de la sécurité
• Fiches de poste avec responsabilités sécurité

CC2 : Communication et information

Comment votre organisation communique les informations de sécurité en interne et en externe.

Contrôles clés :

• Communications internes de sécurité
• Programmes de sensibilisation à la sécurité
• Communication externe des engagements sécurité
• Canaux de signalement des problèmes de sécurité

Exemples de preuves :

• Registres de formation à la sensibilisation sécurité
• Annonces internes de sécurité
• Documentation sécurité destinée aux clients
• Procédures de signalement d'incidents

CC3 : Évaluation des risques

Comment votre organisation identifie et gère les risques de sécurité.

Contrôles clés :

• Processus d'évaluation des risques
• Identification et analyse des risques
• Décisions de traitement des risques
• Surveillance continue des risques

Exemples de preuves :

• Documentation d'évaluation des risques
• Registre des risques
• Plans de traitement des risques
• Comptes-rendus de réunions de revue des risques

CC4 : Activités de monitoring

Comment votre organisation surveille l'efficacité des contrôles de sécurité.

Contrôles clés :

• Processus de monitoring continu
• Évaluations séparées
• Communication des déficiences
• Suivi des remédiations

Exemples de preuves :

• Dashboards de monitoring
• Rapports d'audit interne
• Registres de suivi des remédiations
• Documentation des revues de management

CC5 : Activités de contrôle

Les policies et procédures qui aident à atteindre les objectifs de sécurité.

Contrôles clés :

• Contrôles d'accès logiques
• Contrôles d'accès physiques
• Gestion des changements
• Opérations système

Exemples de preuves :

• Configurations de contrôle d'accès
• Registres de gestion des changements
• Documentation de hardening système
• Procédures opérationnelles

CC6 : Contrôles d'accès logiques et physiques

Contrôles détaillés pour restreindre l'accès aux systèmes et aux locaux.

Contrôles clés :

• Provisioning et déprovisioning des accès utilisateurs
• Mécanismes d'authentification (MFA)
• Contrôles de sécurité réseau
• Mesures de sécurité physique

Exemples de preuves :

• Revues d'accès utilisateurs
• Screenshots de configuration MFA
• Règles de firewall
• Logs d'accès physique

CC7 : Opérations système

Contrôles pour détecter et répondre aux événements de sécurité.

Contrôles clés :

• Gestion des vulnérabilités
• Monitoring et alerting sécurité
• Détection et réponse aux incidents
• Protection contre les malwares

Exemples de preuves :

• Rapports de scan de vulnérabilités
• Configurations d'alertes de sécurité
• Registres de réponse aux incidents
• Preuves de déploiement antimalware

CC8 : Gestion des changements

Contrôles pour gérer les changements aux systèmes et applications.

Contrôles clés :

• Processus d'autorisation des changements
• Tests avant déploiement
• Séparation des tâches
• Procédures de changements d'urgence

Exemples de preuves :

• Tickets de demande de changement
• Registres de code review
• Approbations de déploiement
• Documentation de tests

CC9 : Mitigation des risques

Contrôles pour identifier et atténuer les risques liés aux vendors et partenaires business.

Contrôles clés :

• Évaluation des risques vendors
• Exigences de sécurité contractuelles
• Monitoring continu des vendors
• Considérations de continuité d'activité

Exemples de preuves :

• Questionnaires d'évaluation vendors
• Clauses de sécurité contractuelles
• Registres de revue des vendors
• Plans de continuité d'activité

Availability : Optionnel

Le critère Availability vérifie si vos systèmes répondent aux exigences opérationnelles et d'accessibilité spécifiées dans les accords de service.

Quand inclure Availability

À inclure si :

• Vous proposez des SLAs avec des engagements d'uptime
• Vos clients dépendent de votre service pour des opérations critiques
• Vous fournissez des services d'infrastructure ou de plateforme
• Une indisponibilité impacterait significativement les clients

À ignorer si :

• Vous n'avez pas de SLAs formels
• Votre service n'est pas critique pour les opérations clients
• Vous optimisez pour un premier audit plus rapide

Domaines de contrôle clés

A1 : Disponibilité système

Contrôles :

• Planification et monitoring de capacité
• Procédures de backup et recovery
• Planification de disaster recovery
• Contrôles environnementaux

Exemples de preuves :

• Dashboards de monitoring de capacité
• Logs de backup et résultats de tests
• Documentation du plan DR
• Registres de tests DR

Exigences spécifiques à Availability

Exigence	Description
Monitoring d'uptime	Surveillance continue de la disponibilité système
Gestion des incidents	Processus de gestion des incidents de disponibilité
Gestion de capacité	Assurer des ressources adéquates
Procédures de recovery	Processus de recovery documentés et testés

Processing Integrity : Optionnel

Le critère Processing Integrity garantit que le traitement système est complet, valide, précis, ponctuel et autorisé.

Quand inclure Processing Integrity

À inclure si :

• Vous traitez des transactions financières
• La précision des données est critique pour votre service
• Vous effectuez des calculs ou transformations de données
• Des erreurs pourraient causer un impact significatif aux clients

À ignorer si :

• Vous stockez/récupérez principalement des données sans transformation
• La précision du traitement n'est pas une préoccupation majeure des clients
• Vous optimisez pour un premier audit plus rapide

Domaines de contrôle clés

PI1 : Intégrité du traitement

Contrôles :

• Validation des entrées et vérifications de complétude
• Monitoring de la précision du traitement
• Gestion et correction des erreurs
• Validation des sorties

Exemples de preuves :

• Règles de validation des données
• Rapports de réconciliation de traitement
• Logs d'erreurs et registres de résolution
• Documentation d'assurance qualité

Confidentiality : Optionnel

Le critère Confidentiality couvre la protection des informations désignées comme confidentielles.

Quand inclure Confidentiality

À inclure si :

• Vous gérez des secrets commerciaux clients
• Vous traitez des informations business propriétaires
• Des contrats spécifient des exigences de confidentialité
• Vous gérez des données pré-release ou business sensibles

À ignorer si :

• Vous ne gérez pas de données spécifiquement désignées comme confidentielles
• Le critère Privacy couvre vos besoins en données personnelles
• Vous optimisez pour un premier audit plus rapide

Domaines de contrôle clés

C1 : Informations confidentielles

Contrôles :

• Policies de classification des données
• Identification des données confidentielles
• Restrictions d'accès aux données confidentielles
• Procédures de destruction sécurisée

Exemples de preuves :

• Policy de classification des données
• Inventaire des données confidentielles
• Configurations de contrôle d'accès
• Certificats/logs de destruction

Privacy : Optionnel

Le critère Privacy couvre la collecte, l'utilisation, la rétention, la divulgation et la suppression des informations personnelles conformément à vos engagements de confidentialité.

Quand inclure Privacy

À inclure si :

• Vous collectez et traitez des informations personnelles
• Vous avez des produits destinés aux consommateurs
• Vous opérez dans la santé, les RH ou l'éducation
• Des réglementations privacy (RGPD, CCPA) s'appliquent à vous

À ignorer si :

• Vous ne gérez que des données business, pas de données personnelles
• Vous êtes un service purement B2B sans données utilisateur final
• Vous optimisez pour un premier audit plus rapide

Domaines de contrôle clés

P1-P8 : Principes Privacy

Contrôles :

• Mécanismes de notification et consentement
• Limitations de collecte des données
• Policies d'utilisation, rétention et destruction
• Procédures d'accès et de correction
• Contrôles de divulgation et partage
• Assurance qualité des données
• Monitoring et enforcement

Exemples de preuves :

• Privacy policy
• Mécanismes de consentement
• Calendriers de rétention des données
• Procédures de demande d'accès
• Accords de traitement des données

Choisir vos critères

Considérations pour un premier SOC 2

Votre situation	Critères à considérer
Ressources limitées, besoins simples	Security uniquement
SaaS avec engagements d'uptime	Security + Availability
Gestion d'informations personnelles	Security + Privacy
Traitement de données financières	Security + Processing Integrity
Clients enterprise avec exigences complètes	Security + Availability + Confidentiality

Une approche d'expansion réfléchie

Il est généralement sage d'éviter de sur-dimensionner un premier audit. Beaucoup d'organisations suivent une progression comme :

Année 1 : Security (+ Availability si engagements d'uptime)
Année 2 : Considérer l'ajout de Confidentiality ou Privacy selon les retours clients
Année 3 : Évaluer le scope complet selon les exigences du marché

Checklist de sélection des critères

Posez-vous ces questions pour déterminer votre scope :

• Avons-nous des SLAs avec engagements d'uptime ? → Availability
• La précision du traitement des données est-elle critique ? → Processing Integrity
• Gérons-nous des données spécifiquement désignées comme confidentielles ? → Confidentiality
• Collectons-nous ou traitons-nous des informations personnelles ? → Privacy

Mapping des contrôles entre critères

Beaucoup de contrôles satisfont plusieurs critères. Voici comment ils se chevauchent :

Domaine de contrôle	Security	Availability	Processing Integrity	Confidentiality	Privacy
Contrôle d'accès	✓	✓	✓	✓	✓
Chiffrement	✓			✓	✓
Monitoring	✓	✓	✓
Backup/Recovery	✓	✓
Gestion des changements	✓	✓	✓

Considérations pratiques

Commencez ciblé, étendez progressivement

Ajouter des critères après votre premier audit est généralement simple. Retirer des critères peut nécessiter des explications aux clients. Commencer avec un scope ciblé tend à bien fonctionner pour la plupart des organisations.

Laissez les besoins clients guider vos décisions

Si vous recevez régulièrement des questions sur la disponibilité de la part de prospects, c'est un signal pour considérer son inclusion. La demande du marché peut être un guide utile pour les décisions de scope.

Pensez à l'alignement des frameworks

Si ISO 27001 est dans votre roadmap, le critère Security de SOC 2 s'y aligne étroitement. Le critère Privacy s'aligne avec les exigences RGPD. Consultez notre comparaison SOC 2 vs ISO 27001 pour plus de détails.

Documentez votre raisonnement

Garder des traces de pourquoi vous avez inclus ou exclu certains critères peut être utile. Les auditeurs et clients posent parfois des questions sur les décisions de scope.

---

Des questions pour déterminer le bon scope SOC 2 pour votre organisation ? Parlons-en

---

Sources

• AICPA Trust Services Criteria - Framework TSC officiel et définitions des critères
• AICPA SOC 2 Description Criteria - Guide du framework de reporting SOC
• TSC 2017 avec révisions 2022 (PDF) - Document complet des critères
• COSO Internal Control Framework - Fondation des Common Criteria (CC1-CC9)