Critères de service de confiance SOC 2 : le guide complet

Les Critères de service de confiance (TSC) constituent l’ossature de chaque rapport SOC 2. Développés et maintenus par l’AICPA (American Institute of Certified Public Accountants), ces critères définissent les normes exactes selon lesquelles votre auditeur évalue vos contrôles. Ce ne sont pas des directives optionnelles ou des suggestions de bonnes pratiques — c’est le cadre de mesure formel qui détermine si votre rapport SOC 2 revient propre ou chargé d’exceptions.

Pour les entreprises SaaS poursuivant la conformité SOC 2, comprendre les TSC n’est pas qu’un exercice académique. Les critères que vous sélectionnez façonnent directement le périmètre de votre audit, les contrôles que vous devez mettre en place, les preuves que vous devez collecter et, en fin de compte, le coût et le calendrier de l’ensemble de l’engagement. Choisissez trop peu de critères et votre rapport pourrait ne pas satisfaire les acheteurs institutionnels. Choisissez-en trop et vous vous engagez sur des contrôles que votre organisation n’est peut-être pas prête à maintenir.

Ce guide détaille les cinq critères, explique quand chacun s’applique et fournit un cadre pratique pour sélectionner la bonne combinaison pour votre entreprise SaaS.

Que sont les Critères de service de confiance ?

Le cadre TSC — anciennement connu sous le nom de Trust Service Principles (TSP) avant que l’AICPA ne les renomme en 2017 — comprend cinq catégories qui couvrent les attributs fondamentaux d’un système d’information bien géré :

1. Sécurité (Common Criteria)
2. Disponibilité
3. Intégrité du traitement
4. Confidentialité
5. Vie privée

Chaque critère contient des points de focalisation spécifiques qui correspondent à des contrôles individuels au sein de votre organisation. Votre auditeur teste ces contrôles pendant le processus d’audit SOC 2 pour déterminer s’ils sont correctement conçus (Type I) ou s’ils fonctionnent efficacement dans le temps (Type II).

Distinction clé : Vous n’êtes pas obligé d’inclure les cinq critères dans votre rapport SOC 2. La Sécurité est obligatoire. Les quatre critères restants sont sélectionnés en fonction de votre modèle économique, des exigences de vos clients et de la nature des données que vous traitez.

Sécurité (Common Criteria — CC)

La Sécurité est le seul critère obligatoire dans chaque examen SOC 2. L’AICPA le désigne comme les « Common Criteria » car ses contrôles sous-tendent toutes les autres catégories de service de confiance. Même si vous ne poursuivez que la Sécurité, vous obtenez tout de même un rapport SOC 2 complet.

Ce qu’il couvre

Le critère Sécurité vérifie si votre système est protégé contre les accès non autorisés — tant physiques que logiques. Il couvre neuf catégories de contrôle (CC1 à CC9) qui, ensemble, créent un cadre de sécurité complet :

• CC1 : Environnement de contrôle — Gouvernance, structure organisationnelle, responsabilité et engagement envers l’intégrité et les valeurs éthiques
• CC2 : Communication et information — Comment les politiques de sécurité et les responsabilités sont communiquées en interne et en externe
• CC3 : Évaluation des risques — Identification et analyse des risques susceptibles d’empêcher l’atteinte des objectifs (voir notre guide d’évaluation des risques SOC 2)
• CC4 : Activités de surveillance — Évaluation continue des contrôles pour s’assurer qu’ils continuent de fonctionner comme prévu
• CC5 : Activités de contrôle — Les politiques et procédures spécifiques qui atténuent les risques identifiés
• CC6 : Contrôles d’accès logiques et physiques — Authentification, autorisation, sécurité réseau et protections des installations physiques
• CC7 : Opérations système — Surveillance des anomalies, détection des incidents et procédures de réponse
• CC8 : Gestion des changements — Comment les changements apportés à l’infrastructure, aux logiciels et aux configurations sont autorisés, testés et déployés
• CC9 : Atténuation des risques — Processus de gestion des risques liés aux relations commerciales et aux dépendances envers les fournisseurs

Pour un parcours détaillé de chaque catégorie de contrôle, consultez notre analyse approfondie des Common Criteria SOC 2.

Exemples SaaS en pratique

En pratique : Une entreprise SaaS B2B mettant en œuvre les contrôles de Sécurité démontrerait typiquement :

• Authentification multi-facteurs (MFA) imposée pour tous les employés accédant aux systèmes de production et aux données clients
• Chiffrement en transit (TLS 1.2+) pour tous les points d’accès API et le trafic de l’application orienté client
• Segmentation réseau séparant les environnements de production, de test et d’entreprise
• Gestion des vulnérabilités avec des analyses régulières et un SLA défini pour la correction des vulnérabilités critiques
• Gestion des changements exigeant des pull requests avec revue par les pairs, des tests CI/CD automatisés et des fenêtres de déploiement approuvées
• Journalisation centralisée avec des alertes pour les tentatives d’authentification suspectes, les élévations de privilèges et les changements de configuration

Pourquoi c’est important pour les équipes SaaS

Chaque acheteur institutionnel s’attend à ce que la Sécurité soit incluse. C’est le minimum. Si votre rapport SOC 2 ne couvre que la Sécurité, c’est acceptable pour de nombreuses équipes achats. Mais les contrôles ici ne sont pas anodins — CC6 (contrôles d’accès) et CC7 (opérations système) peuvent à eux seuls générer des dizaines de demandes de preuves lors d’un audit Type II.

Disponibilité

Le critère Disponibilité vérifie si votre système fonctionne et est accessible conformément aux engagements ou aux accords. Il ne s’agit pas d’atteindre 100 % de disponibilité — il s’agit de disposer des contrôles nécessaires pour respecter les niveaux de service que vous avez promis à vos clients.

Ce qu’il couvre

Les contrôles de disponibilité se concentrent sur :

• Surveillance des performances — Suivi des métriques système par rapport à des seuils définis
• Reprise après sinistre (DR) — Procédures documentées pour restaurer le service après un incident majeur
• Planification de la continuité d’activité (PCA) — Assurer la continuité des fonctions critiques pendant les perturbations
• Planification des capacités — Gestion proactive de l’infrastructure pour prévenir l’épuisement des ressources
• Procédures de sauvegarde — Sauvegardes régulières et testées avec des objectifs de point de reprise (RPO) et des objectifs de temps de reprise (RTO) définis
• Réponse aux incidents — Procédures de détection, de réponse et de reprise suite à des événements affectant la disponibilité (voir notre guide de réponse aux incidents SOC 2)

Quand inclure la Disponibilité

Incluez la Disponibilité si :

• Vous fournissez des SLA (accords de niveau de service) à vos clients, qu’ils soient contractuels ou publiés sur votre page de statut
• Vos clients dépendent de votre service pour leurs propres opérations (ex. : vous traitez leurs transactions, hébergez leurs données ou alimentez leurs workflows)
• Une indisponibilité de votre service cause directement une perte financière ou une perturbation opérationnelle pour les clients
• Vous opérez dans un secteur réglementé où les exigences de disponibilité sont explicites

Exemple SaaS : Un SaaS de gestion de projets avec un SLA de disponibilité de 99,9 % a besoin de contrôles de disponibilité pour démontrer qu’il dispose de la surveillance, de la redondance et des mécanismes de reprise pour soutenir cette promesse. Un auditeur testera que les plans de DR ont été exécutés, que les sauvegardes sont testées et que les capacités sont surveillées — pas seulement qu’un document de politique existe.

Contrôles en détail

• Redondance et basculement — Déploiements multi-AZ ou multi-régions, réplication de bases de données, équilibrage de charge avec vérifications de santé
• Surveillance et alertes — Surveillance de l’infrastructure (CPU, mémoire, disque, réseau), vérifications de santé au niveau applicatif, procédures d’escalade lorsque les seuils sont dépassés
• Tests de DR — Exercices documentés sur table ou tests de basculement en conditions réelles effectués au moins annuellement, avec des résultats enregistrés et des lacunes corrigées
• Vérification des sauvegardes — Tests de restauration effectués selon un calendrier défini pour valider que les données de sauvegarde sont complètes et récupérables

Intégrité du traitement

L’Intégrité du traitement vérifie si le traitement du système est complet, valide, exact, ponctuel et autorisé. Ce critère concerne l’exactitude des données — s’assurer que votre système fait ce qu’il prétend faire avec les données qui le traversent.

Ce qu’il couvre

• Complétude — Toutes les transactions devant être traitées le sont, sans aucune manquante ou dupliquée
• Validité — Les entrées de données sont conformes aux critères d’acceptation définis
• Exactitude — Le traitement produit la sortie correcte compte tenu des entrées
• Ponctualité — Le traitement s’effectue dans les délais prévus
• Autorisation — Seules les transactions approuvées sont traitées

Quand inclure l’Intégrité du traitement

Incluez l’Intégrité du traitement si :

• Votre produit SaaS gère des transactions financières, des calculs de facturation ou du traitement de paiements
• Vous effectuez des transformations, agrégations ou calculs de données sur lesquels les clients s’appuient pour des décisions commerciales
• Vous opérez des pipelines de données où l’exactitude est critique (processus ETL, analytique, reporting)
• Vos clients subiraient un préjudice financier ou opérationnel si votre système produisait des résultats incorrects

Exemple SaaS : Un SaaS de traitement de la paie doit démontrer l’Intégrité du traitement car des erreurs de calcul affectent directement la rémunération des employés. Un auditeur testera la validation des entrées (les données salariales sont-elles vérifiées ?), l’exactitude du traitement (le moteur de calcul des impôts produit-il des résultats corrects pour différents scénarios ?) et les contrôles de rapprochement (les totaux de sortie sont-ils comparés aux totaux d’entrée ?).

Contrôles en détail

• Validation des entrées — Vérifications automatisées du format, de la plage et de la complétude des données avant le début du traitement
• Surveillance du traitement — Alertes automatisées lorsque les tâches de traitement échouent, produisent des résultats inattendus ou dépassent les seuils de temps
• Rapprochement — Comparaison systématique des données d’entrée et de sortie pour détecter les écarts
• Gestion des erreurs — Procédures définies pour identifier, journaliser et résoudre les erreurs de traitement, y compris la notification des clients le cas échéant
• Journalisation des transactions — Pistes d’audit immuables enregistrant ce qui a été traité, quand, par qui et avec quel résultat

Confidentialité

Le critère Confidentialité protège les informations désignées comme confidentielles. C’est plus large que les seules données personnelles — il couvre toute information que votre organisation ou vos clients ont identifiée comme nécessitant un accès restreint.

Ce qu’il couvre

• Classification des données — Catégorisation formelle de l’information selon la sensibilité
• Restrictions d’accès — Limitation de l’accès aux informations confidentielles en fonction du rôle et du besoin d’en connaître
• Chiffrement — Protection des données confidentielles au repos et en transit
• Destruction sécurisée — Garantir que les données confidentielles sont détruites lorsqu’elles ne sont plus nécessaires
• Contrôles de divulgation — Gestion de la manière et du moment où les informations confidentielles sont partagées en externe

Quand inclure la Confidentialité

Incluez la Confidentialité si :

• Vous traitez des secrets commerciaux, de la propriété intellectuelle ou des informations commerciales confidentielles appartenant à vos clients
• Les clients partagent des données financières, des plans stratégiques ou d’autres informations commerciales sensibles via votre plateforme
• Vos contrats ou NDA exigent explicitement que vous protégiez la confidentialité des données clients
• Vous stockez des données dont la divulgation causerait un préjudice concurrentiel à vos clients

Exemple SaaS : Un SaaS de gestion de documents juridiques stocke des contrats clients, des documents de fusions-acquisitions et des dossiers de litige. Le critère Confidentialité démontre que ces données sont classifiées, chiffrées au repos (AES-256), accessibles uniquement aux utilisateurs autorisés et purgées de manière sécurisée lorsque le client résilie son compte.

Confidentialité vs. Vie privée

Les équipes SaaS confondent souvent ces deux critères. La distinction est importante :

• La Confidentialité protège les informations désignées comme confidentielles par l’organisation ou le client — secrets commerciaux, projections financières, plans d’affaires, code source, etc.
• La Vie privée régit spécifiquement les informations personnelles — noms, adresses e-mail, numéros de sécurité sociale, dossiers médicaux, données comportementales, etc.

Une entreprise SaaS qui stocke à la fois des documents commerciaux et des données personnelles pourrait avoir besoin des deux. Une entreprise SaaS qui ne traite que des données commerciales (ex. : un dépôt de code) pourrait avoir besoin de la Confidentialité mais pas de la Vie privée.

Contrôles en détail

• Politique de classification des données — Cadre formel définissant les niveaux de sensibilité (ex. : Public, Interne, Confidentiel, Restreint) et les exigences de traitement pour chacun
• Chiffrement au repos — AES-256 ou équivalent pour les données confidentielles stockées, avec des procédures de gestion des clés
• Contrôles d’accès — Accès basé sur les rôles avec des revues d’accès trimestrielles pour vérifier que seul le personnel actuellement autorisé peut atteindre les données confidentielles
• Destruction sécurisée — Effacement cryptographique ou destruction certifiée lorsque les données ne sont plus nécessaires, avec des preuves documentées d’achèvement
• Contrôles des fournisseurs — S’assurer que les sous-traitants qui traitent vos données confidentielles maintiennent des protections équivalentes

Vie privée

Le critère Vie privée régit la manière dont les informations personnelles sont collectées, utilisées, conservées, divulguées et éliminées. C’est le critère le plus complexe sur le plan opérationnel et il recoupe de manière significative des réglementations comme le RGPD, le CCPA et d’autres lois sur la protection des données.

Ce qu’il couvre

Le critère Vie privée est organisé autour des Generally Accepted Privacy Principles (GAPP) de l’AICPA :

• Information — Fournir des avis de confidentialité clairs sur la collecte et l’utilisation des données
• Choix et consentement — Offrir aux individus des choix sur la manière dont leurs données sont utilisées
• Collecte — Limiter la collecte de données à ce qui est nécessaire pour les finalités déclarées
• Utilisation, conservation et élimination — Utiliser les données personnelles uniquement pour les finalités déclarées, les conserver aussi longtemps que nécessaire et les éliminer de manière sécurisée
• Accès — Permettre aux individus d’accéder à leurs données personnelles et de les corriger
• Divulgation à des tiers — Limiter et contrôler la divulgation des données personnelles
• Sécurité pour la vie privée — Protéger les informations personnelles contre les accès non autorisés
• Qualité — Maintenir des informations personnelles exactes, complètes et pertinentes
• Surveillance et application — Surveiller la conformité aux politiques de confidentialité et traiter les plaintes

Quand inclure la Vie privée

Incluez la Vie privée si :

• Votre produit SaaS collecte ou traite des informations personnelles d’utilisateurs finaux (en particulier des consommateurs)
• Vous traitez des catégories de données personnelles sensibles (santé, finances, données d’enfants, biométriques)
• Vous opérez dans des juridictions avec des réglementations de confidentialité strictes (UE/EEE, Californie, Brésil)
• Vos clients attendent de vous que vous démontriez des contrôles de vie privée dans le cadre de votre posture de conformité
• Vous traitez des données personnelles pour le compte de clients (rôle de sous-traitant au sens du RGPD)

Exemple SaaS : Une plateforme d’engagement client qui collecte des données comportementales, des adresses e-mail et des informations démographiques des utilisateurs finaux de ses clients a besoin de contrôles de Vie privée. L’auditeur testera que les avis de confidentialité sont publiés et exacts, que les mécanismes de consentement fonctionnent correctement, que les demandes d’exercice des droits des personnes concernées peuvent être satisfaites dans les délais réglementaires et que les politiques de conservation des données sont appliquées — pas seulement documentées.

Relation avec le RGPD et d’autres réglementations

Le critère Vie privée du SOC 2 ne remplace pas la conformité au RGPD, mais il existe un chevauchement significatif. Les entreprises SaaS qui mettent en place des contrôles de Vie privée pour le SOC 2 se trouveront bien positionnées pour la conformité au RGPD, et inversement. Les principaux domaines de chevauchement incluent la minimisation des données, la gestion du consentement, les droits des personnes concernées et la notification des violations. Consultez notre guide complet de conformité au RGPD pour plus de détails.

Contrôles en détail

• Avis de confidentialité — Description publiée et exacte des pratiques de collecte de données, accessible avant ou au moment de la collecte
• Mécanismes de consentement — Contrôles granulaires d’opt-in/opt-out, avec des enregistrements de quand et comment le consentement a été obtenu
• Minimisation des données — Processus garantissant que seules les données personnelles nécessaires sont collectées, avec des revues régulières pour identifier et éliminer les collectes inutiles
• Politiques de conservation — Périodes de conservation définies par catégorie de données, avec une application automatisée (suppression ou anonymisation) à l’expiration des périodes
• Droits des personnes concernées — Processus opérationnels pour traiter les demandes d’accès, de rectification, de suppression et de portabilité dans les délais requis
• Divulgation à des tiers — Contrats et contrôles techniques régissant le partage des données personnelles avec les sous-traitants et les partenaires

Comment choisir vos critères : un cadre de décision

Sélectionner la bonne combinaison de TSC est une décision stratégique, pas un exercice de cases à cocher. Voici un cadre pratique pour les entreprises SaaS :

Étape 1 : Commencez par la Sécurité (Obligatoire)

Chaque rapport SOC 2 inclut la Sécurité. Pas de décision nécessaire ici. Concentrez votre énergie de planification sur les contrôles Common Criteria et assurez-vous d’avoir les contrôles fondamentaux en place.

Étape 2 : Évaluez la Disponibilité

Posez-vous la question : Avons-nous des SLA ? Nos clients dépendent-ils de notre disponibilité pour leurs opérations quotidiennes ? Une interruption causerait-elle un préjudice financier direct à nos clients ?

Si la réponse est oui à l’une de ces questions — et c’est le cas pour presque tous les produits SaaS B2B — ajoutez la Disponibilité. L’effort supplémentaire est modéré car de nombreux contrôles de Disponibilité chevauchent les contrôles de Sécurité (surveillance, réponse aux incidents, sauvegarde).

Étape 3 : Évaluez la Confidentialité

Posez-vous la question : Stockons-nous des informations commerciales sensibles appartenant à nos clients ? Sommes-nous soumis à des NDA exigeant une protection démontrable des données ? La divulgation non autorisée de données clients causerait-elle un préjudice concurrentiel ?

Si votre SaaS traite quoi que ce soit au-delà de données génériques et non sensibles, la Confidentialité est un ajout pertinent. Elle signale aux clients que vous prenez la protection des données au sérieux au-delà du minimum.

Étape 4 : Évaluez l’Intégrité du traitement

Posez-vous la question : Notre produit principal implique-t-il des calculs, du traitement financier ou des transformations de données ? Un traitement incorrect causerait-il un préjudice financier ou opérationnel à nos clients ?

Si votre SaaS est principalement un outil de stockage ou de collaboration, l’Intégrité du traitement peut être inutile. Si vous effectuez des calculs, des agrégations ou du traitement financier, c’est essentiel.

Étape 5 : Évaluez la Vie privée

Posez-vous la question : Collectons-nous ou traitons-nous des informations personnelles des utilisateurs finaux de nos clients ? Sommes-nous soumis au RGPD, au CCPA ou à des réglementations similaires ? Les données personnelles sont-elles au cœur de la fonctionnalité de notre produit ?

La Vie privée ajoute le plus de complexité opérationnelle. Incluez-la si le traitement de données personnelles est au cœur de votre produit. Si vous traitez principalement des données commerciales avec un minimum d’informations personnelles, vous pourriez reporter la Vie privée à un futur cycle d’audit.

Combinaisons courantes de TSC par type de SaaS

Type de SaaS	Critères recommandés	Justification
Gestion de projets / collaboration B2B	Sécurité + Disponibilité	Service centré sur les SLA ; traitement financier ou données personnelles minimaux
Analytique / plateforme BI B2B	Sécurité + Disponibilité + Confidentialité	Traite des données commerciales sensibles ; les clients attendent des contrôles de confidentialité
Traitement de paiement / fintech	Sécurité + Disponibilité + Intégrité du traitement + Confidentialité	Les calculs financiers exigent l’intégrité du traitement ; traite des données financières sensibles
Plateforme RH / recrutement	Sécurité + Disponibilité + Confidentialité + Vie privée	Traitement intensif de données personnelles ; soumis à la réglementation des données d’emploi
SaaS grand public avec couche B2B	Sécurité + Disponibilité + Vie privée	Les données personnelles des consommateurs finaux sont au cœur du produit
SaaS santé	Les cinq critères	Les exigences réglementaires touchent chaque critère ; les données patients nécessitent une couverture maximale

Ce que cela signifie : La plupart des entreprises SaaS B2B se retrouvent sur la combinaison Sécurité + Disponibilité + Confidentialité comme point de départ. Cela couvre les contrôles que les acheteurs institutionnels évaluent le plus couramment et maintient le périmètre d’audit gérable pour un premier engagement.

Comment GRCTrail vous aide

Naviguer parmi les Critères de service de confiance est considérablement plus facile avec les bons outils :

• Moteur de cartographie des critères — GRCTrail cartographie vos contrôles existants pour chaque catégorie TSC, vous montrant exactement où vous avez une couverture et où existent des lacunes
• Cadres de contrôle pré-construits — Démarrez avec des modèles de contrôle alignés sur le SOC 2 pour les cinq critères, personnalisés pour les environnements SaaS
• Tableau de bord d’analyse des écarts — Représentation visuelle de votre niveau de préparation pour chaque critère sélectionné, avec des recommandations de remédiation priorisées
• Automatisation de la collecte de preuves — Collecte continue de preuves mappée à des points de focalisation TSC spécifiques, pour être toujours prêt pour l’audit
• Portail de collaboration avec l’auditeur — Partagez votre documentation des contrôles, vos preuves et la description de votre système directement avec votre auditeur via une interface structurée
• Cartographie inter-cadres — Visualisez comment vos contrôles SOC 2 correspondent au RGPD, à l’ISO 27001 et à d’autres cadres que vous pourriez devoir aborder

Guides connexes

• Common Criteria SOC 2 : comprendre CC1 à CC9
• SOC 2 Type I vs Type II : différences, coûts et lequel choisir
• Le processus d’audit SOC 2 : calendrier, étapes et à quoi s’attendre
• Collecte de preuves SOC 2 : ce que les auditeurs veulent voir

Commencez avec GRCTrail →