Cadrer un premier rapport SOC 2 sans trop s'engager

Un rapport SOC 2 couvre un système : le service acheté par les clients et tout ce qui le sous-tend. Si vous tracez cette frontière trop largement, vous passerez des mois à documenter des contrôles que personne n'a demandés. Si elle est trop étroite, le rapport ne répondra pas à la question du client. Les erreurs les plus coûteuses lors d'un premier SOC 2 se commettent pendant la semaine de cadrage.

Décision 1 : quel système

Partez de ce que les clients achètent et dont ils dépendent. Pour la plupart des éditeurs de logiciels, il s'agit de la plateforme de production : l'application, son infrastructure et ses bases de données, les personnes qui la développent et l'exploitent, ainsi que les processus qu'elles suivent. Sont généralement hors périmètre : le système d'information interne de l'entreprise qui ne touche jamais aux données clients, les autres gammes de produits et les outils commerciaux.

Définissez la frontière par écrit dès le début, car elle deviendra la description du système dans le rapport. Chaque contrôle doit fonctionner sur l'ensemble de ce qui se trouve à l'intérieur, chaque jour de la période d'observation.

Décision 2 : quels critères

La sécurité, c'est-à-dire les critères communs CC1 à CC9, est obligatoire. Ajoutez les autres uniquement si vos clients en ont besoin :

• Disponibilité si les clients dépendent d'engagements de disponibilité.
• Confidentialité si vous détenez des données clients désignées comme confidentielles (c'est le cas de la plupart des services B2B).
• Intégrité des traitements si les clients comptent sur vous pour traiter correctement leurs données : paiements, paie, facturation.
• Confidentialité des données personnelles si vous traitez des informations personnelles pour vos propres finalités et que les clients le demandent. La plupart de ses critères n'ont pas d'équivalent dans les référentiels de sécurité, comme le montre notre analyse de SOC 2 et ISO 27001.

Décision 3 : organisations sous-traitantes

Votre fournisseur cloud, votre prestataire de paiement ou votre fournisseur de bases de données managées exécute des contrôles sur lesquels vous vous appuyez. Vous choisissez entre :

• Exclusion (carve-out) (le cas le plus courant) : leurs contrôles sont exclus ; vous décrivez ce pour quoi vous vous appuyez sur eux et vous montrez que vous examinez leurs propres rapports SOC 2.
• Inclusion : leurs contrôles sont testés dans votre rapport. Cela suppose leur coopération et reste rare pour les grands fournisseurs.

Décision 4 : contrôles complémentaires de l'entité utilisatrice

Listez les contrôles que vos clients doivent mettre en œuvre pour que les vôtres fonctionnent : gestion de leurs propres comptes utilisateurs, protection de leurs clés d'API, configuration de leur SSO. Restez réalistes et peu nombreux, car les clients les lisent et leurs équipes de sécurité remettront en cause une liste déraisonnable.

Décision 5 : Type I ou Type II, et la période

Un Type I est plus rapide ; un Type II est ce que la plupart des clients attendent. Pour un premier Type II, une période de trois à six mois est courante. Ne la démarrez que lorsque les contrôles fonctionnent depuis quelques semaines, afin que le début de la période ne soit pas rempli d'exceptions.

Une liste de contrôle du cadrage

Avant le lancement avec votre cabinet CPA, préparez les réponses à ces questions :

• Quel produit ou service fait l'objet du rapport, et pour quoi les clients s'appuient-ils dessus ?
• Quels environnements sont dans le périmètre (production uniquement, ou aussi préproduction) ?
• Quels comptes cloud, quelles régions et quelles bases de données ?
• Quelles équipes et quels rôles exploitent le système ?
• De quelles organisations sous-traitantes le système dépend-il, et disposez-vous de leurs rapports ?
• Quelles catégories des Trust Services Criteria, et pourquoi ?
• Quels contrôles complémentaires de l'entité utilisatrice les clients devront-ils mettre en œuvre ?
• Type I d'abord, ou directement Type II ? Quelle période ?
• Quels référentiels ou audits existants permettent de réutiliser des preuves ?

Les réponses écrites deviennent le premier brouillon de votre description du système et vous évitent des semaines d'allers-retours. Si vous détenez déjà l'ISO 27001, le rapport d'écarts ISO 27001 → SOC 2 répond à la dernière question.

Les erreurs de périmètre les plus coûteuses

• Inclure le SI d'entreprise « par précaution » : cela double le nombre de systèmes à documenter.
• Ajouter la Confidentialité des données personnelles ou l'Intégrité des traitements parce que cela semble valorisant : chacun ajoute des contrôles et des preuves pour toute la période.
• Une description du système qui ne correspond pas à la réalité : les auditeurs testent ce que vous avez écrit.
• Démarrer la période avant que les contrôles ne fonctionnent : les exceptions du premier mois restent dans le rapport.

Notre guide SOC 2 couvre l'ensemble du processus ; la page du référentiel SOC 2 répertorie chaque critère avec ses correspondances ; et si vous détenez déjà un autre référentiel, l'analyse d'écarts montre le chemin qui reste à parcourir.

Questions

Quel est le périmètre minimal d'un rapport SOC 2 ?

La catégorie Sécurité (les critères communs, CC1 à CC9) pour un système défini. La Disponibilité, la Confidentialité, l'Intégrité des traitements et la Confidentialité des données personnelles sont facultatives.

Qu'est-ce qu'un carve-out dans SOC 2 ?

L'exclusion des contrôles d'une organisation sous-traitante (par exemple les contrôles du centre de données de votre fournisseur cloud) du rapport, tout en décrivant ce pour quoi vous vous appuyez sur elle et la manière dont vous en assurez le suivi.