Quand vous préparez votre premier audit SOC 2, mappez chaque Trust Service Criteria dans une matrice de contrôles que vous pouvez remettre à l'auditeur. — Claude Skill

Conformité SOC 2

Préparation à la conformité SOC 2 Type I et Type II pour entreprises SaaS. Couvre le mapping des Trust Service Criteria, la génération de matrices de contrôles, la collecte de preuves, l'analyse d'écarts et l'évaluation de préparation à l'audit.

Table des matières

• Vue d'ensemble
• Trust Service Criteria
• Génération de matrice de contrôles
• Workflow d'analyse d'écarts
• Collecte de preuves
• Checklist de préparation à l'audit
• Gestion fournisseurs
• Conformité continue
• Anti-patterns
• Outils
• Références
• Références croisées

---

Vue d'ensemble

Qu'est-ce que SOC 2 ?

SOC 2 (System and Organization Controls 2) est un framework d'audit développé par l'AICPA qui évalue la façon dont une organisation de services gère les données client. Il s'applique à toute entreprise technologique qui stocke, traite ou transmet des informations client, principalement les fournisseurs SaaS, d'infrastructure cloud et de services managés.

Type I vs Type II

Qui a besoin de SOC 2 ?

• Entreprises SaaS qui vendent à des clients enterprise
• Fournisseurs d'infrastructure cloud qui hébergent des workloads client
• Data processors qui gèrent des PII, PHI ou données financières
• Fournisseurs de services managés avec accès aux systèmes clients
• Tout vendor dont les clients exigent une assurance tierce

Parcours typique

Évaluation des écarts → Remédiation → Audit Type I → Période d'observation → Audit Type II → Renouvellement annuel
    (4-8 sem.)          (8-16 sem.)   (4-6 sem.)       (6-12 mois)             (4-6 sem.)       (continu)

---

Trust Service Criteria

SOC 2 est organisé autour de cinq catégories de Trust Service Criteria (TSC). Security est requise pour chaque rapport SOC 2 ; les quatre autres sont optionnelles et sélectionnées selon le besoin métier.

Security (critères communs CC1-CC9) — requis

La base de tout rapport SOC 2. Mappée aux principes COSO 2013.

Availability (A1) — optionnel

À sélectionner quand : vos clients dépendent de votre uptime ; vous avez des SLA ; le downtime cause un impact business direct.

Confidentiality (C1) — optionnel

À sélectionner quand : vous manipulez des secrets commerciaux, données propriétaires ou informations contractuellement confidentielles.

Processing Integrity (PI1) — optionnel

À sélectionner quand : l'exactitude des données est critique (traitement financier, dossiers santé, plateformes analytics).

Privacy (P1-P8) — optionnel

À sélectionner quand : vous traitez des PII et vos clients attendent une assurance privacy (complète la conformité GDPR).

---

Génération de matrice de contrôles

Une matrice de contrôles mappe chaque critère TSC à des contrôles spécifiques, owners, preuves et procédures de test.

Structure de la matrice

Convention de nommage des contrôles

{CATEGORY}-{NUMBER}
SEC-001 à SEC-NNN  → Security
AVL-001 à AVL-NNN  → Availability
CON-001 à CON-NNN  → Confidentiality
PRI-001 à PRI-NNN  → Processing Integrity
PRV-001 à PRV-NNN  → Privacy

Workflow

1. Sélectionner les catégories TSC applicables selon les besoins métier
2. Lancer control_matrix_builder.py pour générer la matrice de base
3. Adapter les contrôles à votre environnement réel
4. Assigner les owners et exigences de preuves
5. Valider la couverture : chaque critère TSC sélectionné doit avoir au moins un contrôle

---

Workflow d'analyse d'écarts

Phase 1 : évaluation de l'état actuel

1. Documenter les contrôles existants — inventorier toutes les politiques, procédures et contrôles techniques de sécurité
2. Mapper aux TSC — aligner les contrôles existants avec les Trust Service Criteria
3. Collecter des échantillons de preuves — rassembler la preuve que les contrôles existent et opèrent
4. Interviewer les owners de contrôles — vérifier la compréhension et l'exécution

Phase 2 : identification des écarts

Lancer gap_analyzer.py sur vos contrôles actuels pour identifier :

• Contrôles manquants — critères TSC sans contrôle correspondant
• Partiellement implémentés — contrôle existant mais sans preuve ou cohérence
• Écarts de design — contrôle conçu mais ne couvrant pas suffisamment le critère
• Écarts opérationnels (Type II seulement) — contrôle bien conçu mais pas efficace en opération

Phase 3 : planification de remédiation

Pour chaque écart, définir :

Phase 4 : planification du calendrier

---

Collecte de preuves

Types de preuves par catégorie de contrôle

Opportunités d'automatisation

Monitoring continu

Passer de la collecte ponctuelle de preuves à la conformité continue :

1. Collecte automatisée de preuves — scripts qui tirent les preuves selon un planning
2. Dashboards de contrôles — visibilité temps réel sur le statut des contrôles
3. Monitoring basé sur alertes — notifier quand un contrôle dérive hors conformité
4. Dépôt de preuves — stockage centralisé, horodaté des preuves

---

Checklist de préparation à l'audit

Préparation pré-audit (4-6 semaines avant)

• Tous les contrôles documentés avec descriptions, owners et fréquences
• Preuves collectées sur toute la période d'observation (Type II)
• Matrice de contrôles revue et écarts remédiés
• Politiques signées et distribuées dans les 12 derniers mois
• Revues d'accès complétées à la fréquence requise
• Scans de vulnérabilités à jour (aucune critique/haute non patchée > SLA)
• Plan de réponse aux incidents testé dans les 12 derniers mois
• Évaluations de risque fournisseurs à jour pour toutes les organisations sous-traitantes
• DR/BCP testé et documenté dans les 12 derniers mois
• Formation sécurité employés complétée pour tout le personnel

Scoring de préparation

Constats d'audit courants

---

Gestion fournisseurs

Évaluation des risques tiers

Chaque fournisseur qui accède, stocke ou traite des données client doit être évalué :

1. Inventaire fournisseurs — maintenir un registre de tous les prestataires de services
2. Classification du risque — catégoriser les fournisseurs par niveau d'accès aux données
3. Due diligence — collecter rapports SOC 2, questionnaires sécurité, certifications
4. Protections contractuelles — assurer DPA, exigences sécurité, clauses de notification de violation
5. Monitoring continu — réévaluation annuelle, veille d'actualité continue

Tiers de risque fournisseur

Organisations sous-traitantes

Quand votre rapport SOC 2 dépend de contrôles chez une organisation sous-traitante (ex. AWS, GCP, Azure) :

• Méthode inclusive — votre rapport couvre les contrôles de l'organisation sous-traitante (requiert sa coopération)
• Méthode carve-out — votre rapport exclut leurs contrôles mais référence leur rapport SOC 2
• La plupart des entreprises utilisent le carve-out et incluent les complementary user entity controls (CUECs)

---

Conformité continue

Du ponctuel au continu

Étapes d'implémentation

1. Automatiser la collecte de preuves — cron jobs, intégrations API, snapshots IaC
2. Construire des dashboards de contrôle — agréger le statut des contrôles en une seule vue
3. Configurer les alertes de dérive — notifier quand les contrôles sortent de conformité
4. Établir une cadence de revue — points hebdomadaires avec owners de contrôles, steering mensuel
5. Maintenir le dépôt de preuves — centralisé, horodaté, accessible à l'auditeur

Cycle annuel de réévaluation

---

Anti-patterns

---

Outils

Control Matrix Builder

Génère une matrice de contrôles SOC 2 à partir des catégories TSC sélectionnées.

# Générer la matrice Security complète en markdown
python scripts/control_matrix_builder.py --categories security --format md

# Générer une matrice pour plusieurs catégories en JSON
python scripts/control_matrix_builder.py --categories security,availability,confidentiality --format json

# Toutes les catégories, sortie CSV
python scripts/control_matrix_builder.py --categories security,availability,confidentiality,processing-integrity,privacy --format csv

Evidence Tracker

Suit le statut de collecte de preuves par contrôle.

# Vérifier le statut des preuves depuis une matrice de contrôles
python scripts/evidence_tracker.py --matrix controls.json --status

# Sortie JSON pour intégration
python scripts/evidence_tracker.py --matrix controls.json --status --json

Gap Analyzer

Analyse les contrôles actuels face aux exigences SOC 2 et identifie les écarts.

# Analyse d'écarts Type I
python scripts/gap_analyzer.py --controls current_controls.json --type type1

# Analyse d'écarts Type II (inclut l'efficacité opérationnelle)
python scripts/gap_analyzer.py --controls current_controls.json --type type2 --json

---

Références

• Trust Service Criteria Reference — Les 5 catégories TSC avec sous-critères, objectifs de contrôle et exemples de preuves
• Evidence Collection Guide — Types de preuves par contrôle, outils d'automatisation, exigences de documentation
• Type I vs Type II Comparison — Comparaison détaillée, calendrier, analyse de coût et chemin d'upgrade

---

Références croisées

• gdpr-dsgvo-expert — Les critères Privacy SOC 2 chevauchent fortement les exigences GDPR ; utiliser ensemble lors du traitement de données personnelles UE
• information-security-manager-iso27001 — Les contrôles ISO 27001 Annex A se mappent étroitement aux critères Security SOC 2 ; les organisations poursuivant les deux peuvent partager des preuves
• isms-audit-expert — La méthodologie d'audit et les patterns de gestion des constats se transfèrent directement à la préparation d'audit SOC 2