Quand l'audit SOC 2 est dans 6 mois et que votre portefeuille commercial enterprise dépend du rapport, parcourez chaque contrôle TSC avec les preuves d'infrastructure prêtes. — Claude Skill

Expert conformité SOC 2

Gestion de conformité SOC 2 Type I et Type II couvrant tous les Trust Services Criteria (TSC), la validation de sécurité d'infrastructure, la collecte de preuves et la préparation d'audit de bout en bout.

Vue d'ensemble SOC 2

Type I vs Type II

Commencez par le Type I pour valider la conception des contrôles, puis passez au Type II sous 6 mois.

Synthèse des Trust Services Criteria

Pour les exigences détaillées de contrôle par catégorie, voir REFERENCE.md.

Workflow d'évaluation de préparation

L'agent guide les organisations dans la préparation SOC 2 depuis l'analyse d'écarts jusqu'à la finalisation de l'audit.

Workflow : phase 1 -- Analyse d'écarts (semaines 1-4)

1. Définir le périmètre -- déterminer les catégories TSC à inclure (Security est obligatoire), définir les frontières système, identifier les organisations sous-traitantes (carve-out vs inclusive), documenter les engagements principaux de service.
2. Évaluer l'état actuel -- inventorier les politiques et procédures existantes, mapper les contrôles actuels aux exigences TSC, interviewer les responsables de processus et opérateurs de contrôle.
3. Lancer l'analyse automatisée des écarts avec scripts/soc2_readiness_checker.py.
4. Documenter les écarts -- contrôles manquants, contrôles sans preuve, contrôles qui ne fonctionnent pas efficacement.
5. Prioriser les écarts par niveau de risque et effort de remédiation.
6. Checkpoint de validation : l'analyse d'écarts couvre toutes les catégories TSC dans le périmètre ; chaque écart a une sévérité et un owner de remédiation assignés.

Workflow : phase 2 -- Remédiation (semaines 5-16)

1. Développer/mettre à jour les politiques -- politique de sécurité de l'information, procédures de support par domaine de contrôle, workflows de revue et d'approbation des politiques.
2. Implémenter les contrôles techniques -- configurer l'IdP avec enforcement SSO/MFA, déployer la sécurité endpoint (MDM, EDR, chiffrement disque), implémenter logs SIEM et monitoring, configurer backup et DR, renforcer l'infrastructure cloud.
3. Établir les processus -- procédures de revue d'accès, workflow de change management, procédures de réponse aux incidents, programme de gestion fournisseurs, formation de sensibilisation sécurité.
4. Mettre en place la collecte de preuves -- configurer la collecte automatisée, établir la structure du dépôt, définir la cadence de refresh par catégorie TSC.
5. Checkpoint de validation : tous les écarts identifiés sont remédiés ; les contrôles techniques sont vérifiés via scripts/soc2_infrastructure_auditor.py ; la collecte de preuves produit des artefacts.

Workflow : phase 3 -- Pré-audit (semaines 17-20)

1. Conduire une évaluation interne de préparation -- audit mock sur tous les TSC dans le périmètre, validation de la complétude et qualité des preuves, lancement de l'auditeur d'infrastructure pour validation technique.
2. Remédier les constats de pré-audit -- traiter les écarts restants, renforcer les preuves.
3. Sélectionner et engager le cabinet CPA -- négocier périmètre, calendrier et honoraires ; planifier le kickoff ; préparer le brouillon de description système.
4. Checkpoint de validation : l'audit mock passe sans écart critique ; la description système est revue ; l'auditeur est engagé.

Workflow : phase 4 -- Exécution de l'audit

1. Audit Type I (si applicable) -- l'auditeur examine la conception des contrôles ; le management fournit ses assertions ; traiter les constats avant le Type II.
2. Période d'observation Type II (3-12 mois) -- les contrôles opèrent de façon cohérente, les preuves sont collectées en continu, auto-évaluations trimestrielles, points réguliers avec l'auditeur.
3. Fieldwork (2-4 semaines) -- l'auditeur sélectionne des échantillons, teste les contrôles, interviewe le personnel ; revue du rapport draft ; émission du rapport final.
4. Checkpoint de validation : opinion clean reçue ; tout constat a une réponse du management et un plan de remédiation.

Framework de collecte de preuves

Preuves par catégorie TSC

Exemple : commande de collecte de preuves

# Générer une checklist de preuves pour toutes les catégories TSC
python scripts/evidence_collector.py --generate-checklist --categories all

# Suivre le statut des preuves
python scripts/evidence_collector.py --status evidence-tracker.json

# Mettre à jour un élément de preuve spécifique
python scripts/evidence_collector.py --update evidence-tracker.json \
  --item CC6.1-MFA --status collected

# Générer un dashboard de préparation
python scripts/evidence_collector.py --dashboard evidence-tracker.json

# Exporter pour revue par l'auditeur
python scripts/evidence_collector.py --export evidence-tracker.json --format json

Stratégies d'automatisation

Plateformes GRC : Vanta, Drata, Secureframe, Laika, AuditBoard -- collecte automatisée de preuves via intégrations API, monitoring continu des contrôles, portails de collaboration avec l'auditeur.

Infrastructure-as-Evidence : snapshots de configuration cloud (AWS Config, Azure Policy, GCP Org Policies), état Terraform comme preuve de configuration, historique Git comme preuve de change management, logs de portefeuille commercial CI/CD comme preuve de contrôle de déploiement.

Validation de sécurité d'infrastructure

L'agent valide les configurations d'infrastructure face aux exigences SOC 2.

Référence rapide : checks d'infrastructure

Pour les mappings détaillés par provider, voir REFERENCE.md.

Exemple : commande d'audit d'infrastructure

# Audit complet de l'infrastructure
python scripts/soc2_infrastructure_auditor.py --config infra-config.json

# Auditer uniquement certains domaines
python scripts/soc2_infrastructure_auditor.py --config infra-config.json \
  --domains dns tls cloud

# Sortie JSON avec ratings de sévérité
python scripts/soc2_infrastructure_auditor.py --config infra-config.json --format json

# Générer un template de configuration exemple
python scripts/soc2_infrastructure_auditor.py --generate-template

Calendrier d'audit

Calendrier typique (premier SOC 2)

Renouvellement annuel

• Commencer la planification du renouvellement 3 mois avant la fin de la période d'observation
• Maintenir la conformité continue entre périodes d'audit
• Traiter les constats de l'année précédente avant la nouvelle période d'observation
• Lettres de bridge disponibles pour les écarts entre rapports

Exigences de réponse aux incidents

Structure IRP

1. Préparation -- équipe IR définie, canaux de communication établis, runbooks pour incidents courants, contacts juridiques/PR sous contrat.
2. Détection et analyse -- couverture monitoring/alerting, classification de sévérité (SEV1-SEV4), procédures de triage, matrice d'escalade.
3. Confinement, éradication, restauration -- isoler les systèmes affectés, préserver les preuves, identifier la cause racine, restaurer et valider.
4. Post-incident -- post-mortem sans blâme sous 5 jours ouvrés, leçons apprises, améliorations de contrôles, évaluation de notification (suivi MTTD, MTTR, MTTC).

Pour les définitions de niveaux de sévérité et les délais de notification de violation, voir REFERENCE.md.

Outils

SOC 2 Readiness Checker

# Évaluation complète de préparation
python scripts/soc2_readiness_checker.py --config org-controls.json

# Sortie JSON pour usage programmatique
python scripts/soc2_readiness_checker.py --config org-controls.json --format json

# Vérifier des catégories TSC spécifiques
python scripts/soc2_readiness_checker.py --config org-controls.json \
  --categories security availability

# Inclure le mapping de contrôles par cloud provider
python scripts/soc2_readiness_checker.py --config org-controls.json --cloud-mapping

Evidence Collector

# Générer la checklist et suivre le statut
python scripts/evidence_collector.py --generate-checklist --categories all
python scripts/evidence_collector.py --status evidence-tracker.json
python scripts/evidence_collector.py --dashboard evidence-tracker.json

Infrastructure Auditor

# Valider l'infrastructure face aux exigences SOC 2
python scripts/soc2_infrastructure_auditor.py --config infra-config.json
python scripts/soc2_infrastructure_auditor.py --config infra-config.json --format json

Références

Dépannage

Critères de succès

• Périmètre SOC 2 défini avec toutes les catégories TSC applicables sélectionnées, frontières système documentées et organisations sous-traitantes identifiées (carve-out vs inclusive)
• Analyse d'écarts terminée avec chaque écart assigné à une sévérité, un owner de remédiation et une date cible de résolution
• Score de préparation de 80 %+ sur toutes les catégories TSC dans le périmètre avant engagement du cabinet CPA, avec tendance vers 95 %+ avant le fieldwork Type II
• Framework de collecte de preuves opérationnel avec dépôt centralisé, cadence de refresh définie par catégorie TSC et collecte automatisée lorsque possible
• Audit d'infrastructure réussi sans constats critiques ou de haute sévérité sur DNS, TLS, cloud, endpoint ou domaines de contrôle d'accès
• Période d'observation Type II d'au moins 6 mois avec opération continue des contrôles, auto-évaluations trimestrielles et aucun échec de contrôle significatif
• Opinion SOC 2 Type II clean reçue, avec tout constat traité par réponse du management et plans de remédiation documentés

Périmètre et limites

Dans le périmètre :

• Évaluation de préparation SOC 2 Type I et Type II face à toutes les catégories TSC (CC1-CC9, A1, PI1, C1, P1)
• Validation de sécurité d'infrastructure (DNS, TLS, cloud, endpoint, réseau, conteneur, CI/CD, secrets)
• Génération et suivi du framework de collecte de preuves
• Analyse d'écarts avec constats notés par sévérité et guidance de remédiation
• Planification du calendrier d'audit et préparation de l'engagement du cabinet CPA
• Structure et exigences du plan de réponse aux incidents
• Conception d'un programme de conformité continue

Hors périmètre :

• Exécution de l'audit par le cabinet CPA (les outils préparent l'audit ; le vrai rapport Type I/II nécessite un cabinet CPA indépendant)
• Évaluation SOC 1 (ICFR) (SOC 1 couvre les contrôles de reporting financier, pas sécurité/disponibilité/privacy)
• Génération de rapport SOC 3 (SOC 3 est un résumé public dérivé de SOC 2 ; il nécessite un audit SOC 2 terminé)
• Exécution de tests d'intrusion (utiliser infrastructure-compliance-auditor ou engager un pentest tiers)
• Sélection ou implémentation de plateforme GRC (le skill est compatible avec Vanta, Drata, Secureframe, etc., mais ne les implémente pas)
• Conseil juridique sur les exigences contractuelles clients pour les rapports SOC 2
• Évaluations de sécurité physique (l'auditeur d'infrastructure couvre les contrôles logiques ; les audits physiques de datacenter nécessitent une évaluation sur site)

Points d'intégration

Référence des outils

soc2_readiness_checker.py

Évalue les contrôles organisationnels face aux Trust Services Criteria SOC 2 avec scoring par catégorie.

evidence_collector.py

Génère des checklists de collecte de preuves et suit le statut de collecte.

soc2_infrastructure_auditor.py

Audite les configurations d'infrastructure face aux exigences SOC 2 avec constats notés par sévérité.