Contrôles Common Criteria (CC) SOC 2 expliqués

Les Common Criteria (CC) sont l’ossature de chaque rapport SOC 2. Ils correspondent au Critère de service de confiance Sécurité — le seul critère obligatoire dans chaque examen SOC 2 — et définissent les objectifs de contrôle spécifiques que votre auditeur évalue. Comprendre les neuf catégories CC est essentiel pour concevoir un cadre de contrôle qui réussit l’audit et protège réellement vos systèmes.

Les catégories CC sont dérivées du cadre de contrôle interne COSO (Committee of Sponsoring Organizations of the Treadway Commission), adapté par l’AICPA spécifiquement pour la sécurité de l’information. Elles couvrent tout, de la culture organisationnelle et la gouvernance aux contrôles d’accès techniques et à la gestion des risques fournisseurs. Pour les entreprises SaaS, cela signifie que le SOC 2 ne se limite pas aux pare-feu et au chiffrement — c’est la manière dont l’ensemble de votre organisation fonctionne.

Ce guide détaille chaque catégorie CC avec ce que les auditeurs testent, quelles preuves ils attendent et comment les entreprises SaaS doivent mettre en place les contrôles pour satisfaire chacune. Si vous en êtes encore à vous orienter avec le SOC 2, commencez par notre guide Qu’est-ce que le SOC 2 ? avant de plonger dans les détails des critères.

CC1 : Environnement de contrôle

Critères couverts : CC1.1 à CC1.5

L’environnement de contrôle établit les fondations de tout le reste de votre programme SOC 2. Il s’agit de l’engagement organisationnel — votre entreprise prend-elle la sécurité au sérieux à tous les niveaux, du conseil d’administration aux contributeurs individuels ?

Ce que les auditeurs recherchent :

• Un code de conduite ou une politique d’éthique signée par tous les employés
• Une structure organisationnelle définie avec des rôles et responsabilités de sécurité clairs
• Une supervision au niveau du conseil ou de la direction du programme de sécurité (procès-verbaux de réunions, cadence de reporting)
• La responsabilisation de la direction pour les objectifs de sécurité
• Des politiques RH qui renforcent la sécurité (vérifications d’antécédents, formation à la sécurité lors de l’intégration, procédures de départ)

Mise en œuvre SaaS :

• Organigramme avec responsabilités de sécurité. Cartographiez qui est responsable de quoi : RSSI ou responsable sécurité, managers d’ingénierie responsables du développement sécurisé, le propriétaire de la conformité et toute personne ayant un accès privilégié au système.
• Code de conduite. Chaque employé signe une politique d’utilisation acceptable et d’éthique lors de l’intégration. Revue et renouvellement de l’accusé de réception annuellement.
• Reporting au conseil ou à la direction. Documentez des briefings de sécurité réguliers à votre conseil ou à votre équipe de direction.
• Intégration RH-sécurité. Vérifications d’antécédents pour les nouvelles recrues, formation obligatoire à la sécurité lors de l’intégration et processus de départ documenté incluant la révocation d’accès dans les 24 heures suivant le départ.

En pratique : CC1 est l’endroit où les auditeurs évaluent si la sécurité fait partie de l’ADN de votre entreprise ou est une réflexion après coup. Pour des conseils complets en matière de politiques, consultez notre guide des politiques et procédures.

CC2 : Communication et information

Critères couverts : CC2.1 à CC2.3

CC2 traite de la manière dont votre organisation communique les informations de sécurité en interne et en externe. Les auditeurs veulent voir que les responsabilités, les attentes et les engagements de sécurité sont clairement communiqués.

Ce que les auditeurs recherchent :

• Enregistrements de formation à la sensibilisation à la sécurité avec suivi de complétion
• Canaux de communication internes pour l’information de sécurité
• Engagements de sécurité externes documentés et communiqués (pages de confiance, SLA, livres blancs de sécurité)
• Procédures de communication avec les parties externes sur les questions de sécurité

Mise en œuvre SaaS :

• Programme de formation à la sensibilisation à la sécurité. Formation annuelle pour tous les employés, avec une formation spécifique au rôle pour les ingénieurs (codage sécurisé) et les administrateurs (gestion des accès privilégiés).
• Processus de communication interne. Un canal défini pour les annonces de sécurité.
• Page de sécurité externe. Une page de pratiques de sécurité accessible au public (page de confiance).
• Procédures de communication avec les fournisseurs et clients. Processus documentés pour répondre aux questionnaires de sécurité des clients.

Pour les détails sur la construction d’artefacts de preuves pour ces communications, consultez notre guide de collecte de preuves.

CC3 : Évaluation des risques

Critères couverts : CC3.1 à CC3.4

CC3 exige que votre organisation dispose d’un processus formel et documenté pour identifier, analyser et gérer les risques. Ce n’est pas un exercice ponctuel — c’est un programme continu qui alimente toutes les autres catégories de contrôle.

Ce que les auditeurs recherchent :

• Un document formel d’évaluation des risques produit au moins annuellement
• Un registre des risques cataloguant les risques identifiés avec des notations de gravité, des évaluations de probabilité et des plans de traitement
• Des considérations sur le risque de fraude (oui, même pour les entreprises SaaS)
• Un processus d’identification et d’évaluation des changements significatifs pouvant introduire de nouveaux risques

Mise en œuvre SaaS :

• Évaluation annuelle des risques. Menez une évaluation structurée des risques au moins une fois par an.
• Registre des risques. Maintenez un document vivant qui suit chaque risque identifié, sa notation actuelle, les contrôles qui l’atténuent, le propriétaire du risque et le statut des activités de remédiation.
• Évaluation du risque de fraude. Les auditeurs recherchent spécifiquement les considérations de risque de fraude — accès non autorisé aux données, manipulation financière, contournement des contrôles par la direction.
• Évaluation de l’impact des changements. Lorsque vous effectuez des changements significatifs, vous avez besoin d’un processus documenté pour évaluer l’impact sur la sécurité.

Pour un parcours complet de la construction d’une évaluation des risques prête pour le SOC 2, consultez notre guide d’évaluation des risques.

CC4 : Activités de surveillance

Critères couverts : CC4.1 à CC4.2

CC4 exige que votre organisation surveille activement l’efficacité de ses contrôles et traite les déficiences identifiées. C’est la catégorie « faites confiance mais vérifiez ».

Ce que les auditeurs recherchent :

• Des procédures de surveillance continue évaluant l’efficacité des contrôles dans le temps
• Des processus d’évaluation internes (auto-évaluations, audits internes, tests de contrôle)
• Un processus de gestion des déficiences
• Des preuves que les résultats de surveillance sont rapportés à la direction

Mise en œuvre SaaS :

• Tableaux de bord de surveillance automatisés. Configurez des tableaux de bord suivant les métriques de sécurité clés.
• Revues régulières de l’efficacité des contrôles. Au moins trimestriellement, vérifiez si vos contrôles fonctionnent comme prévu.
• Processus de gestion des déficiences. Lorsqu’un contrôle échoue ou qu’une lacune est identifiée, vous avez besoin d’un processus documenté pour journaliser la déficience, assigner un propriétaire, définir un plan de remédiation et suivre la résolution.

Pour une analyse approfondie de la construction d’un programme de surveillance, consultez notre guide de surveillance continue.

CC5 : Activités de contrôle

Critères couverts : CC5.1 à CC5.3

CC5 fait le lien entre l’identification des risques (CC3) et la mise en place des contrôles. Il exige que vous sélectionniez et déployiez des contrôles qui traitent réellement les risques que vous avez identifiés.

Ce que les auditeurs recherchent :

• Des contrôles cartographiés vers des risques spécifiques (une matrice de contrôle ou un document similaire)
• Des contrôles technologiques déployés et configurés de manière appropriée
• Des politiques et procédures établies et communiquées pour chaque domaine de contrôle

Mise en œuvre SaaS :

• Matrice de contrôle. Créez un document de cartographie reliant chaque risque identifié aux contrôles spécifiques qui l’atténuent. C’est l’un des artefacts d’audit les plus importants.
• Déploiement de contrôles technologiques. Mettez en place les contrôles techniques que votre évaluation des risques a identifiés comme nécessaires.
• Application des politiques. Chaque contrôle devrait être soutenu par une politique et une procédure. Consultez notre guide des politiques et procédures.

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

Critères couverts : CC6.1 à CC6.8

CC6 est la catégorie la plus dense en contrôles des Common Criteria et produit le plus grand volume de preuves lors d’un audit. Elle couvre chaque aspect de la gestion des accès.

Ce que les auditeurs recherchent :

• Configuration du fournisseur d’identité avec gestion centralisée des utilisateurs
• Application du MFA sur tous les systèmes critiques
• Mise en place du contrôle d’accès basé sur les rôles (RBAC) suivant le moindre privilège
• Contrôles de sécurité réseau (pare-feu, WAF, segmentation réseau)
• Protection des endpoints sur tous les appareils de l’entreprise
• Chiffrement des données au repos et en transit
• Procédures de provisionnement et déprovisionnement des utilisateurs
• Revues d’accès périodiques avec preuves documentées

Mise en œuvre SaaS :

• Single sign-on (SSO) avec MFA. Centralisez l’authentification via un fournisseur d’identité (Okta, Azure AD, Google Workspace) avec MFA obligatoire pour tous les utilisateurs.
• Accès basé sur les rôles avec moindre privilège. Définissez des rôles pour chaque système et attribuez les permissions minimales nécessaires.
• Revues d’accès trimestrielles. Chaque trimestre, les propriétaires de systèmes examinent qui a accès, vérifient que les niveaux d’accès sont appropriés et révoquent les accès qui ne sont plus nécessaires.
• Sécurité réseau. Mettez en place un WAF sur les services publics, segmentez votre réseau, restreignez l’accès SSH/RDP et maintenez des règles de pare-feu refusant par défaut le trafic entrant.
• Protection des endpoints. Déployez MDM et EDR sur tous les appareils de l’entreprise.
• Chiffrement partout. TLS 1.2+ pour toutes les données en transit. AES-256 ou équivalent pour les données au repos.
• Provisionnement et déprovisionnement. Procédures documentées pour accorder l’accès lors de l’intégration et révoquer tout accès lors du départ.

En pratique : CC6 est l’endroit où la majorité des constatations d’audit SOC 2 surviennent. Les problèmes les plus courants : MFA non appliqué sur tous les systèmes, revues d’accès non complétées dans les délais, employés partis conservant des accès et rôles IAM trop permissifs.

CC7 : Opérations système

Critères couverts : CC7.1 à CC7.5

CC7 couvre la manière dont votre organisation détecte, évalue et répond aux événements et incidents de sécurité. C’est le battement opérationnel de votre programme de sécurité.

Ce que les auditeurs recherchent :

• Outils de surveillance et détection des événements de sécurité (SIEM, agrégation de logs, alertes)
• Procédures de triage et d’escalade des alertes
• Plan de réponse aux incidents avec rôles définis, classifications de gravité et procédures de réponse
• Preuves de détection, réponse et résolution des incidents
• Documentation de revue post-incident

Mise en œuvre SaaS :

• SIEM ou agrégation de logs. Centralisez les logs pertinents pour la sécurité avec des règles d’alerte pour les schémas suspects.
• Processus de triage des alertes. Définissez comment les alertes sont classifiées, qui les reçoit, les temps de réponse attendus et les voies d’escalade.
• Playbook de réponse aux incidents. Documentez vos procédures de réponse pour chaque catégorie d’incident. Consultez notre guide de réponse aux incidents.
• Revues post-incident. Après chaque incident significatif, menez un post-mortem sans reproche.

CC8 : Gestion des changements

Critères couverts : CC8.1

CC8 a un seul critère mais c’est l’un des domaines les plus testés dans un audit SOC 2 d’entreprise SaaS.

Ce que les auditeurs recherchent :

• Une politique de gestion des changements documentée
• Des exigences de revue de code (revue par les pairs avant fusion)
• Un pipeline CI/CD avec tests automatisés
• Des procédures de déploiement avec workflows d’approbation
• Des environnements de staging ou pré-production
• Des procédures de changement d’urgence avec revue rétrospective
• Des capacités de rollback documentées

Mise en œuvre SaaS :

• Revue de code basée sur les PR. Tous les changements de code nécessitent une pull request examinée et approuvée par au moins un pair avant fusion. Appliquez cela via des règles de protection de branche dans GitHub, GitLab ou Bitbucket.
• Contrôles du pipeline CI/CD. Les tests automatisés doivent réussir avant le déploiement.
• Environnements de staging. Les changements sont déployés dans un environnement de staging avant la production.
• Workflow d’approbation des déploiements. Définissez qui peut approuver et qui peut exécuter. La séparation des fonctions est un contrôle clé.
• Processus de changement d’urgence. Documentez une procédure permettant un déploiement accéléré avec revue rétrospective obligatoire dans les 24 à 48 heures.
• Procédures de rollback. Documentez comment annuler un déploiement échoué.

En pratique : Les auditeurs adorent examiner la gestion des changements car les preuves sont riches et facilement vérifiables. La constatation la plus courante : des développeurs ayant la capacité de pousser directement vers la branche principale, contournant la revue de code.

CC9 : Atténuation des risques

Critères couverts : CC9.1 à CC9.2

CC9 se concentre sur les activités d’atténuation des risques, avec un accent particulier sur la gestion des risques liés aux fournisseurs et aux partenaires commerciaux.

Ce que les auditeurs recherchent :

• Un programme de gestion des fournisseurs avec des processus documentés
• Un inventaire des fournisseurs avec classifications des risques
• Des preuves de diligence raisonnable pour les fournisseurs critiques (rapports SOC 2, questionnaires de sécurité, certifications)
• Des contrats avec exigences de sécurité et clauses de protection des données
• Des procédures de réévaluation périodique des fournisseurs

Mise en œuvre SaaS :

• Inventaire des fournisseurs. Maintenez une liste complète de tous les fournisseurs qui accèdent, traitent ou stockent vos données ou celles de vos clients. Classez chacun par niveau de risque.
• Évaluations des risques fournisseurs. Pour les fournisseurs à haut risque, menez des évaluations formelles des risques. Examinez leurs rapports SOC 2, certifications de sécurité et réponses à vos questionnaires.
• Exigences contractuelles de sécurité. Assurez-vous que les contrats incluent des obligations de protection des données, des exigences de notification de violation, des droits d’audit et des clauses de résiliation.
• Réévaluation annuelle. Revoyez les classifications de risques et la posture de sécurité des fournisseurs annuellement.

Pour un cadre complet de gestion des fournisseurs, consultez notre guide de gestion des fournisseurs.

Cartographie des contrôles sur les Common Criteria

Créer une matrice de contrôle — un document qui cartographie chaque point CC sur les contrôles spécifiques qui le satisfont — est l’un des exercices les plus précieux de votre programme SOC 2.

Comment construire une matrice de contrôle :

1. Listez chaque critère CC (CC1.1 à CC9.2) dans un tableur ou une plateforme GRC.
2. Pour chaque critère, identifiez les contrôles de votre environnement qui le satisfont. Un contrôle peut (et devrait) correspondre à plusieurs critères.
3. Pour chaque contrôle, documentez les preuves qui démontrent que le contrôle fonctionne.
4. Identifiez les lacunes — critères sans contrôles cartographiés. Ce sont vos priorités de remédiation.

Un contrôle, plusieurs critères. Votre revue d’accès trimestrielle satisfait CC6.3 (restriction d’accès), CC4.1 (activités de surveillance) et CC1.4 (responsabilisation). Votre processus de réponse aux incidents satisfait CC7.3, CC7.4 et CC2.2.

Exemple de cartographie pour une entreprise SaaS typique :

Contrôle	Critères CC satisfaits	Preuves
SSO avec application du MFA	CC6.1, CC6.2, CC6.6	Capture de configuration IdP, politique MFA, logs de connexion
Revues d’accès trimestrielles	CC6.1, CC6.3, CC4.1, CC1.4	Enregistrements de revue d’accès, tickets de remédiation
Revue de code basée sur les PR	CC8.1, CC5.2	Configuration de protection de branche, exemples de PR avec approbations
Évaluation annuelle des risques	CC3.1, CC3.2, CC3.3	Document d’évaluation des risques, registre des risques
Formation à la sensibilisation à la sécurité	CC1.1, CC2.1	Enregistrements de complétion de formation, contenu de formation
Plan de réponse aux incidents	CC7.3, CC7.4, CC7.5	Playbook de RI, tickets d’incidents, post-mortems
Évaluations des risques fournisseurs	CC9.1, CC9.2	Inventaire fournisseurs, enregistrements d’évaluation, rapports SOC

Critères supplémentaires au-delà des Common Criteria

Les Common Criteria couvrent le TSC Sécurité, mais si votre rapport SOC 2 inclut des Critères de service de confiance supplémentaires, vous devrez traiter des points de contrôle supplémentaires. Consultez notre guide des Critères de service de confiance pour des conseils détaillés de sélection.

Disponibilité (A1.1-A1.3). Couvre les objectifs de reprise, les procédures de sauvegarde et les tests de reprise après sinistre. Vous aurez besoin de RTO et RPO documentés, de sauvegardes automatisées avec des procédures de restauration testées et d’un plan de DR validé par des tests au moins annuels.

Intégrité du traitement (PI1.1-PI1.5). Couvre la complétude, l’exactitude, la ponctualité et l’autorisation du traitement. Pertinent pour les produits SaaS qui effectuent des calculs financiers, des transformations de données ou du traitement de transactions.

Confidentialité (C1.1-C1.2). Couvre l’identification et la protection des informations confidentielles. Vous aurez besoin d’un schéma de classification des données, de contrôles spécifiques à chaque niveau de classification et de preuves que les données confidentielles reçoivent une protection renforcée.

Vie privée (P1-P8). Couvre le cycle de vie complet des informations personnelles — information, choix, collecte, utilisation, divulgation, accès, qualité et surveillance. C’est le critère supplémentaire le plus étendu et il recoupe significativement les exigences du RGPD.

En pratique : La plupart des entreprises SaaS poursuivant leur premier rapport SOC 2 devraient commencer avec la Sécurité (Common Criteria) uniquement. Chaque critère supplémentaire ajoute 15 à 25 % de contrôles, preuves et périmètre d’audit en plus. Ajoutez des critères en année 2+ en fonction des exigences réelles des clients.

Comment GRCTrail vous aide

GRCTrail fournit un cadre structuré pour mettre en place et gérer les contrôles à travers toutes les catégories Common Criteria.

• Cadre de contrôle pré-construit cartographié sur tous les Common Criteria pour commencer avec un ensemble complet de contrôles CC1-CC9 conçu pour les entreprises SaaS
• Guidance de mise en œuvre des contrôles pour chaque catégorie CC avec des instructions étape par étape, des exemples spécifiques au SaaS et des outils recommandés pour chaque contrôle
• Exigences de preuves liées aux contrôles pour que votre équipe sache exactement quels artefacts collecter, où les trouver et à quelle fréquence les actualiser
• Analyse des écarts montrant quels points CC ont des contrôles et lesquels n’en ont pas — vous donnant une vue en temps réel de votre préparation et une feuille de route de remédiation priorisée
• Intégration de tests automatisés des contrôles validant en continu si vos contrôles fonctionnent comme prévu

Commencez avec GRCTrail →

Guides connexes

• Qu’est-ce que le SOC 2 ? Guide pratique pour les entreprises SaaS
• Les Critères de service de confiance SOC 2 expliqués
• Checklist de conformité SOC 2 pour les entreprises SaaS
• Guide des politiques et procédures SOC 2