Préparer un audit SOC2 sur AWS sans ralentir votre équipe

Le scénario classique : un commercial signe un mid-market US, le contrat exige un rapport SOC2 dans les 6 mois, et l’équipe technique apprend la nouvelle un lundi matin. Trois mois plus tard, la roadmap produit est gelée, l’équipe est épuisée, et le rapport n’est toujours pas prêt.

Cet article décrit la séquence que nous appliquons en mission Distribuée pour passer un audit SOC2 sur AWS sans geler la roadmap — c’est-à-dire en travaillant en parallèle de l’équipe produit, pas à sa place.

Le périmètre, en deux phrases

SOC2 (Service Organization Control 2) est un framework américain géré par l’AICPA. Il évalue cinq Trust Service Criteria :

• Security (CC) : obligatoire, c’est le socle
• Availability (A) : recommandé pour la majorité des SaaS
• Confidentiality (C) : si données client B2B
• Processing Integrity (PI) : si transactions financières
• Privacy (P) : rarement scopé en France (RGPD couvre déjà)

Type 1 = état à un instant T (rapport en ~1 mois). Type 2 = preuve sur 6 à 12 mois (rapport plus long, plus crédible commercialement).

90 % des PME que nous accompagnons commencent par un Type 1 sur Security + Availability, puis enchaînent sur un Type 2 l’année suivante.

La timeline qui marche

Quatre phases qui se chevauchent. Pas de Big Bang, pas de freeze. Chaque phase produit un livrable concret pour l’auditeur.

Phase 1 — Cartographie (J0 à J15)

L’objectif : produire un gap analysis précis. Pour chaque contrôle SOC2, l’état actuel + l’écart à combler.

Outils utilisés :

• AWS Audit Manager : framework SOC2 pré-cablé qui scanne automatiquement votre compte
• AWS Security Hub avec la security standard “AWS Foundational Security Best Practices”
• Une checklist manuelle pour ce qui n’est pas dans AWS (process, RH, contrats fournisseurs)

# Activer Audit Manager avec le framework SOC2
aws auditmanager register-account
aws auditmanager create-assessment \
  --name "SOC2-Type1-2026" \
  --framework-id $(aws auditmanager list-assessment-frameworks \
    --framework-type Standard \
    --query 'frameworkMetadataList[?contains(name, `SOC 2`)] | [0].id' \
    --output text) \
  --assessment-reports-destination destination=s3://distribuee-com-audit-reports \
  --scope file://scope.json \
  --roles roleArn=arn:aws:iam::ACCOUNT_ID:role/AuditManagerRole,roleType=PROCESS_OWNER

Livrable : un tableau Gap Analysis avec 60 à 100 lignes, chacune classée en place / quick win / chantier / pas applicable.

Phase 2 — Quick wins (J10 à J45)

Tout ce qui se règle en moins d’une semaine, on le fait pendant cette phase. C’est l’étape où l’on rattrape le retard d’hygiène sécurité accumulé.

Les quick wins typiques sur AWS :

• MFA obligatoire sur le root user et tous les users IAM (souvent partiel)
• Suppression des access keys IAM long-lived (et migration vers IAM Identity Center)
• CloudTrail organisationnel activé avec log file validation
• Default encryption sur tous les buckets S3 et volumes EBS
• TLS 1.2+ partout (audit des Load Balancers et CloudFront distributions)
• Retention CloudWatch Logs configurée explicitement

Phase 3 — Automatisation des contrôles (J30 à J75)

C’est le cœur technique du chantier. On installe la stack qui va prouver en continu que les contrôles sont en place.

Concrètement, sur AWS :

# Activer Security Hub avec la standard SOC2
resource "aws_securityhub_account" "main" {
  enable_default_standards = true
}

resource "aws_securityhub_standards_subscription" "aws_foundational" {
  standards_arn = "arn:aws:securityhub:::standards/aws-foundational-security-best-practices/v/1.0.0"
  depends_on    = [aws_securityhub_account.main]
}

# Activer GuardDuty avec malware protection
resource "aws_guardduty_detector" "main" {
  enable                       = true
  finding_publishing_frequency = "FIFTEEN_MINUTES"

  datasources {
    s3_logs { enable = true }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes { enable = true }
      }
    }
  }
}

# Config rules typiques pour SOC2
resource "aws_config_config_rule" "encrypted_volumes" {
  name = "encrypted-volumes"
  source {
    owner             = "AWS"
    source_identifier = "ENCRYPTED_VOLUMES"
  }
}

resource "aws_config_config_rule" "root_account_mfa" {
  name = "root-account-mfa-enabled"
  source {
    owner             = "AWS"
    source_identifier = "ROOT_ACCOUNT_MFA_ENABLED"
  }
}

resource "aws_config_config_rule" "iam_password_policy" {
  name = "iam-password-policy"
  source {
    owner             = "AWS"
    source_identifier = "IAM_PASSWORD_POLICY"
  }
  input_parameters = jsonencode({
    RequireUppercaseCharacters = "true"
    RequireLowercaseCharacters = "true"
    RequireSymbols             = "true"
    RequireNumbers             = "true"
    MinimumPasswordLength      = "14"
    PasswordReusePrevention    = "24"
    MaxPasswordAge             = "90"
  })
}

Pour chacun de ces contrôles, la preuve est automatique : Config enregistre les changements de configuration en continu, Security Hub aggrège les findings, et l’auditeur n’a qu’à exporter les rapports.

Phase 4 — Pré-audit interne (J60 à J90)

Deux semaines avant la mission de l’auditeur externe, on lance un pré-audit interne simulant la vraie mission. Mêmes questions, mêmes preuves demandées, même format.

C’est le filet qui évite 80 % des surprises. Tout ce qui ne tient pas en interne ne tiendra pas devant l’auditeur.

Les pièges classiques

Quelques pièges que nous voyons systématiquement :

Piège 1 — Le périmètre flou. “Notre app SaaS” ne suffit pas. L’auditeur veut connaître précisément les comptes AWS scoped, les services AWS utilisés, le data flow, les sous-traitants impactés. Documentez tout ça avant la phase 1.

Piège 2 — La sous-estimation du HR. SOC2 ne concerne pas que la tech. Onboarding/offboarding, background checks, formations sécurité, code de conduite : c’est dans le scope. Si votre RH n’est pas alignée, vous perdrez des semaines.

Piège 3 — Les sous-traitants critiques. Tout fournisseur qui touche à vos données client doit avoir son propre rapport SOC2 (ou équivalent ISO 27001). Liste exhaustive : votre IdP, votre PaaS, votre solution de monitoring, votre provider d’emails transactionnels, etc.

Piège 4 — Le journal d’incidents vide. SOC2 attend que vous documentiez les incidents et leur résolution. Un journal vide est suspect. Documentez même les petits incidents (faux positifs GuardDuty, alertes capacity).

La checklist pré-audit interne

Avant de lancer l’auditeur, vérifiez ces points :

Si tout est vert, vous êtes prêts.

Conclusion

SOC2 est moins une question de technique que d’organisation. Les contrôles AWS sont aujourd’hui largement automatisables (Audit Manager, Security Hub, Config) — ce qui prend du temps, c’est la mise en place de la discipline de preuve continue.

La bonne nouvelle : une fois la stack en place, le second audit (Type 2 année suivante) coûte 30 % de l’effort du premier. Et les bénéfices business — closing de deals, simplification des due diligences acquéreurs — dépassent largement le coût.

Si un audit SOC2 approche dans les 6 prochains mois, nous accompagnons typiquement les équipes sur les phases 1 à 3, en laissant la phase 4 et la mission auditeur à votre équipe interne.