Préface

Dans le secteur des start-up et scale-up B2B SaaS, en particulier aux États-Unis, les rapports SOC 2 sont considérés comme un « indispensable » pour vendre avec succès à des clients plus importants. Après avoir aidé des dizaines d'entreprises SaaS à obtenir les rapports d'attestation SOC 2 Type II, nous pouvons affirmer avec confiance qu'il existe beaucoup de confusion et d'incompréhensions concernant SOC 2, ses exigences, le processus d'audit ainsi que le pourquoi et le comment. Cet article vise à aider les entreprises SaaS et les cabinets de conseil à comprendre les concepts de base du SOC 2 et à répondre aux questions les plus importantes, telles que comment procéder, combien de temps cela prend, combien cela coûte et quels efforts sont nécessaires.

TL;DR: SOC 2 est une méthodologie d'audit qui définit certains contrôles (Trust Service Criteria) pour lesquels votre entreprise sera auditée. Le processus d'audit permettra de valider si les contrôles sont établi et exploité efficacement, l'auditeur délivrera une lettre d'attestation le précisant. La lettre d'attestation précise que dans le cabinet CPA avis vous avez établi et/ou utilisé efficacement les contrôles. Le rapport SOC 2 de type I (1) se concentrera sur l'établissement du contrôle à une date donnée (audit à un moment précis) et le type II (2) validera l'établissement du contrôle et le fonctionnement efficace pour une période de temps spécifique (appelée période d'observation) du passé (Par exemple, entre le 1er janvier 2026 et le 31 mars 2026).

Les rapports SOC 2 sont des mesures retardées par défaut car la méthodologie d'audit nécessite la validation de preuves objectives (par exemple, un ticket de bug traitant du processus de fermeture d'une vulnérabilité d'application signalée). Votre travail en tant que propriétaire d'entreprise consiste à tout gérer en toute sécurité, à collecter en permanence des preuves, puis à valider la période d'observation (minimum 3 mois, maximum 15 mois) par un cabinet de CPA indépendant, à obtenir le rapport et, si demandé, à le partager avec vos clients actuels et futurs prospects (uniquement après la signature de la NDA) montrant que tout était en ordre pour la période d'observation.

D'accord, vous le saviez probablement déjà (ou auriez pu le savoir) en recherchant SOC 2 en ligne, en consultant Wikipédia ou en interrogeant votre copilote/invite Gen AI préféré. Pour passer aux choses sérieuses, je dois fouiller dans l’histoire de l’audit pour fournir un contexte. Il y a un mur de texte ci-dessous, et vous pouvez passer aux questions importantes et section réponses ici.

Historique – Audit des systèmes informatiques, SAS 70, SSEA 16, IASE 3402 et 3000

SAS70

Tout a commencé avec des audits financiers. Je veux dire l'audit, où vous imaginez que la société de comptable entre, vérifie les registres financiers et les grands livres, et donne un rapport indiquant que tous les freins et contrepoids sont OK. L'entreprise auditée doit disposer de contrôles internes empêchant la fraude, le détournement de fonds, la tricherie, etc. Ces audits aux États-Unis (et dans d'autres pays) ont été menés par des comptables publics certifiés (CPA). Pour créer un format de reporting standardisé sur les contrôles internes ayant un impact sur l'information financière, l'American Institute of CPAs (AICPA) a publié la « Déclaration sur les normes d'audit n° 70 (SAS 70) » comme méthodologie recommandée pour l'audit des contrôles en 1992. Dans le cadre des audits financiers, les cabinets d'audit ont également vérifié certains contrôles informatiques (comme qui a accès au logiciel de comptabilité, etc.)

Le résultat des audits SAS 70 a été une lettre du cabinet CPA indiquant que les contrôles internes sur rapports financiers ont été efficacement exploités. Au cours des années 1990 et au début des années 2000, l’externalisation et la délocalisation ont explosé, et les entreprises ont confié leurs opérations de paie, de comptabilité et d’informatique à des sociétés externes. Ces « entreprises externes » appelées organisations de services ont commencé à utiliser les rapports SAS 70 dans le cadre de leurs efforts de marketing/vente, ce qui est devenu problématique dans la mesure où la portée du rapport concernait explicitement les contrôles financiers, et non les contrôles généraux en matière d'informatique, de sécurité des données ou de confidentialité.

Au cours de cette période, l'audit des contrôles internes sur l'information financière est devenu un défi pour les cabinets CPA, car chaque entreprise conçoit ses contrôles (par exemple, la société A a mis en œuvre le principe des quatre yeux pour les paiements importants [comme le directeur financier et le PDG tenus d'envoyer le paiement], dans la société B, tous les paiements étaient effectués uniquement par le PDG), aucun « ensemble standard » de contrôles n'existait.

Chaque entreprise était responsable de la conception de son propre ensemble de contrôles, car il semblait correspondre au fonctionnement et aux objectifs de l'organisation (c'était la version comptable du « Wild Wide West »).

SSAE 16 – SOC 1 et SOC 2

Sur la base des commentaires du cabinet CPA et de la demande du marché pour des attestations spécifiques à l'informatique, l'AICPA a publié en 2010 la Déclaration sur les normes pour les missions d'attestation n° 16 (SSAE 16), qui a remplacé SAS 70 et était alignée sur la méthodologie d'audit ISAAB (International Auditing and Assurance Standards Board créé en 1978) 3402 (préparez-vous et ne perdez pas la trace des abréviations).

La SSAE 16 a apporté plusieurs changements importants :

• Des rapports d'audit SOC 1 ont été introduits et fonctionnent effectivement comme des audits SAS 70, par exemple en se concentrant sur les contrôles liés à l'information financière. L'organisation de services peut concevoir son cadre de contrôle.

• Les audits SOC 2 se concentrent sur les contrôles liés à l'ensemble de principes/critères de service de confiance prédéfinis – un nom sophistiqué pour un ensemble de contrôles que l'AICPA a défini pour répondre aux exigences plus larges en matière d'informatique et de protection des données, répartis en cinq catégories : sécurité, disponibilité, intégrité des processus, confidentialité et confidentialité. Le TSC permet aux cabinets de CPA d’évaluer « de manière égale » tout le monde pour ces contrôles. Les rapports SOC 2 sont destinés à une diffusion limitée en raison des informations sensibles qu'ils peuvent contenir. Les rapports ne sont pas destinés à être rendus publics.

• Les rapports SOC 3, qui sont en fait un format récapitulatif et à usage général du rapport SOC 2, qui peut être partagé avec n'importe qui.

Le changement le plus important concerne la séparation entre le reporting sur les contrôles ayant un impact sur l'information financière (SOC 1) et les contrôles informatiques généraux (ish) (SOC 2).

Le timing était parfait ; Au début des années 2010, le cloud computing, y compris les solutions SaaS, a commencé à prendre le relais et les données sensibles se sont rapidement accumulées chez les fournisseurs de services cloud. Bien entendu, cela a conduit à d’importantes violations de données. Cela a donné lieu à des évaluations par des tiers, que les rapports SOC 2 ont parfaitement abordées. Comme les cabinets CPA effectuaient déjà des audits « en interne » sur les livres (comptabilité), ils accédaient facilement aux clients et effectuaient les audits SOC 2.

SSAE 18 – Le présent

L'AICPA a mis à jour la norme en 2017, alignant les exigences sur le cadre de contrôle interne du COSO (Committee of Sponsoring Organizations of the Treadway Commission) – il s'agit d'une liste générale de bonnes pratiques permettant aux entreprises de gérer les risques (financiers et opérationnels), de prévenir la fraude et d'opérer avec prudence.

Note latérale : La création du cadre COSO a été motivée par le Enron, WorldCom, et d'autres scandales.

Les critères du service de confiance ont été mis à jour pour la dernière fois en 2020 (principalement liés aux contrôles de confidentialité), et je suis sûr que l'AICPA mettra continuellement à jour le TSC et sa méthodologie.

Bien que SOC 2 fournisse un ensemble complet de contrôles, il ne s’agit pas d’une norme formelle. Une norme formelle est un ensemble strictement formalisé de règles, de lignes directrices ou de spécifications, et les normes actuelles en matière d'information et de cybersécurité sont membres de la famille ISO/IEC 27000, PCI-DSS ou NIST 800-53. Nous pouvons considérer SOC 2 (de ses Trust Service Criteria) comme une norme informelle, et avoir un rapport SOC 2 était essentiellement devenu une exigence pour les éditeurs de logiciels visant à répondre aux clients des secteurs de la finance, de la santé ou du Fortune 500 aux États-Unis au milieu des années 2010. Désormais, en Europe et dans la région APAC, elle est devenue équivalente à la certification ISO/IEC 27001:2022.

D'accord, j'essaie de ne pas rivaliser avec les "Histoire hardcore" Podcast de Dan Carlin (connu pour ses longues sessions de plus de 3 heures), mais il y a plus. Maintenant que nous comprenons l'histoire, nous pouvons examiner le pourquoi et le comment.

Les questions importantes

La cybersécurité (de l’information) est un marathon, pas un sprint. Il ne suffit pas d’atteindre un certain niveau de maturité en matière de sécurité ; il doit être maintenu et (espérons-le) amélioré. À quoi cela ressemble-t-il du point de vue du SOC 2 ?

TL;DR#2: Les informations ci-dessous sont basées sur une expérience de réflexion imaginant une entreprise SaaS de 25 personnes entièrement distante développant une plate-forme CRM exploitée sur AWS et vous optez pour SOC 2 Type II avec une période d'observation de 3 mois.

1) DIY manuellement (word/docs, excel/sheet, outil de gestion de projet) en passant du temps à comprendre et à mettre en œuvre les exigences,

2) DIY avec l'outil GRC – payez des frais pour un outil, passez du temps à comprendre et à mettre en œuvre les exigences avec les conseils de l'outil GRC.

3) La voie du consultant – faites appel à un consultant qui a fait cela des dizaines de fois, en prenant autant de votre épaule que possible, qu'il s'agisse d'une mise en œuvre manuelle ou d'un outil GRC. Tranquillité d'esprit, rapidité, efficacité.

Cela dépend de l'endroit où vous vous trouvez, du degré de mise en œuvre nécessaire, du fait que vous ayez ou non une dette technologique et si vous suivez déjà les meilleures pratiques.

Manuel de bricolage : si quelqu'un ne connaît pas les exigences ou n'a aucune expérience en matière de sécurité/conformité, je ne pourrais pas imaginer une durée de moins de 3 à 4 mois (pas d'heures de travail réelles) pour la mise en œuvre et une période d'observation de 3 mois par la suite. C'est une estimation très optimiste !

Outil DIY GRC – Si quelqu'un ne connaît pas les exigences ou n'a aucune expérience, je pense qu'il est possible d'avoir 2 à 3 mois de mise en œuvre et une période d'observation de 3 mois par la suite.

La Voie du Consultant - 4 semaines de mise en œuvre + 3 mois de période d'observation.

Comment y arriver ? (avec détails)

Vous avez plusieurs options pour le faire. Je décrirai les scénarios et les chemins les plus courants pour les entreprises SaaS qui, dans ce scénario, utilisent les principaux CSP (AWS, Azure, GCP) et opèrent à distance (pas d'infrastructure sur site).

Le manuel de bricolage – à mains nues

Vous faites vos devoirs et savez que le SSEA 18 et le TSC sont publiés sur le site de l'AICPA. Après une courte inscription, vous téléchargez le PDF. Vous passez d'innombrables heures à comprendre quelles sont les exigences réelles et celles qui vous concernent (commencez par des critères communs, c'est-à-dire uniquement les exigences de sécurité) et à comprendre comment les mettre en œuvre. Peut-être que vous envoyez le PDF à un LLM et gagnez des dizaines d'heures.

Vous créez vos propres politiques et effectuez votre propre évaluation des risques, concevez le cadre de contrôle et mettez en œuvre les contrôles (si vous n'êtes pas familier avec les informations générales, les pratiques et les outils de sécurité du cloud et des points finaux, ainsi que le « discours sur la conformité », ce sera une courbe d'apprentissage abrupte, avec plusieurs sommets à franchir).

Vous êtes intelligent et vous savez que vous devez collecter des preuves pour la période d'observation et mettre en place un cadre de sécurité et de conformité durable. Vous passez beaucoup de temps à expliquer ce qui doit être fait et pourquoi pour impliquer tout le monde en interne.

Parce que vous êtes malin et que vous souhaitez montrer des résultats à vos clients, vous fixez la période d'observation à trois mois la plus courte possible. Une fois que vous vous sentez prêt, vous vous engagez auprès des cabinets CPA et gérez le processus d'audit, en fournissant des échantillons, des explications et des preuves objectives pour répondre aux exigences. Ils envoient des fiches où vous fournissez des réponses et des fichiers. Après le processus d'audit de 4 à 8 semaines, vous attendez 2 à 6 semaines pour obtenir le rapport SOC 2 Type II, qui atteste que pendant la période d'observation (les trois mois), vous avez effectivement opéré les contrôles.

Faites éclater le champagne, faites la fête et passez des jours heureux ! Parce que vous êtes intelligent, vous n’oubliez pas de continuer à exercer les contrôles et à collecter continuellement des preuves, car après un an, votre rapport couvrant la période initiale de trois mois expire en quelque sorte et votre client vous demandera quel est le temps écoulé entre la fin du rapport initial et maintenant. Mais vous avez fait vos devoirs, vous savez donc que 12 mois plus tard, vous refaireez votre audit SOC 2, et qu'une fois celui-ci effectué tous les 12 mois, vous suivrez le cycle.

Le DIY – Outillage GRC

Vous avez entendu des histoires de cauchemar de la part de vos pairs sur le processus manuel de bricolage SOC 2, et vous êtes intelligent, rusé et pouvez utiliser les moteurs de recherche. Vous trouvez un outil GRC, vous réservez une démo et vous entendez les bons mots : rationalisation, automatisation, des centaines, des milliers de clients satisfaits, un portail d'audit, un effort minimal. Vous l'aimez! Vous êtes à bord ! Vous connectez vos systèmes cloud, commencez à vérifier les tableaux de bord dans l'outil et créez des listes d'actions, tandis que le système vous guidera si vous créez votre produit, si vous servez votre client, améliorez l'équipe ou si vous gérez simplement votre entreprise en tant que démarrage ou mise à l'échelle, l'effort prendra beaucoup de temps. Principalement dépensé pour essayer de donner un sens aux exigences et à la manière de les mettre en œuvre.

Vous vous rendrez compte que tout n'est pas automatisé ou collecté automatiquement et que vous devez passer du temps à rédiger des rapports, à capturer des tickets, des tableaux de bord et d'autres preuves pour les télécharger dans l'outil GRC. Les outils sont excellents ; nous les aimons car ils fournissent des explications et des échantillons. Pourtant, si vous faites du bricolage, cela prendra du temps. Espérons que vous ne serez pas distrait ou retardé car vous avez payé pour quelque chose qui n'est pas entièrement utilisé et que le retour sur investissement que vous aviez imaginé initialement ne se réalise pas.

Vous bénéficiez d'un audit de période d'observation d'au moins trois mois, et comme vous êtes malin, vous mettez en place votre cadre opérationnel. L'outil vous dira si quelque chose doit être fait (si vous l'avez configuré correctement) ou si les preuves ont expiré. La meilleure façon est de mettre en place votre système de gestion de projet pour suivre les activités.

La voie d'un consultant

Vous construisez votre produit. Vous recevez des questions, des fiches d’évaluation et des demandes de vos clients et prospects. Vous êtes occupé et vous voulez faire avancer les choses. Vous engagez un consultant, par exemple nous (l'équipe Clarify Consult Partner) ou tout autre professionnel décent.

Lors de l’appel de cadrage, le consultant posera les questions suivantes (ou des questions très similaires) :

• Votre argumentaire éclair, par exemple, quel service/solution vous fournissez, quel type de données est impliqué (et le secteur réglementé, quel est votre secteur vertical, etc.). Cela aide immédiatement à comprendre la complexité et le paysage des menaces.

• Votre pile technologique, AWS/GCP/Azure, restons fidèles à AWS. Le consultant vous demandera quels services vous utilisez : ECS ou Fargate, Lambda ou EC2, AWS RDS ou MongoDB vs MySQL fonctionnant sur un EC2. CloudWatch, CloudTrail ou Security Hub sont-ils activés ? Cela aidera le consultant à comprendre le modèle de responsabilité partagée (EC2 nécessite des correctifs et une gestion des vulnérabilités au niveau du système d'exploitation, contrairement à Lambda), votre maturité probable en matière de sécurité et une éventuelle dette technique.

• Votre modèle opérationnel, par exemple, employés ou sous-traitants, à distance ou au bureau, appareils appartenant à l'entreprise ou ordinateurs portables privés. Ces questions visent à comprendre la complexité de la mise en œuvre à venir ; par exemple, SOC 2 impose le cryptage des ordinateurs portables et l'utilisation de l'AV, ce qui peut constituer un défi si tout le monde utilise des ordinateurs portables privés.

• Une date limite stricte, des clients/prospects bannis sur la table exigeant le rapport SOC 2 promis ?

Une fois que le consultant aura compris la situation, il expliquera les différentes options de mise en œuvre qui sont similaires à la méthode DIY, par exemple, processus manuels ou utilisation d'un outil GRC. La différence ici est que le consultant se chargera de la majorité des tâches, mais vous devrez apporter votre contribution et passer des appels. L’effort global de votre part dépend des facteurs expliqués ci-dessus (votre paysage de menaces, la complexité et la dette technique).

Dans notre scénario, disons que vous êtes une entreprise SaaS de 25 personnes développant une solution CRM exploitée sur AWS avec une pile technologique standard et une configuration entièrement à distance dans laquelle vous expédiez un Mac à tous les membres du personnel. Dans ce cas, votre implication durera entre 15 et 25 heures, où le plus gros effort sera l'évaluation des risques (environ 3 heures), les révisions des politiques (2 à 4 heures), les opérations de processus internes telles que la personnalisation de la liste de contrôle d'entrée et de sortie du personnel, la mise en œuvre du processus de vérification des antécédents et certains renforcements AWS que vous n'avez peut-être pas (journal de flux VPC, journalisation immuable avec période de conservation appropriée, alertes, renforcement des groupes de sécurité, etc.), et rencontrez-nous lors des réunions d'avancement hebdomadaires.  

Si vous faites appel à un consultant, votre effort de mise en œuvre avec un minimum de variables est indépendant de l'utilisation de méthodes manuelles (feuilles, documents, outils de gestion de projet comme ClickUp, Asana, Notion, Jira, Linear, etc.) ou d'un outil GRC.

L’avantage d’utiliser un outil GRC

L’utilisation d’un outil GRC apporte deux différences significatives et fondamentales à long terme :

Expérience utilisateur (interne et externe): Avoir tout au même endroit, avec une visualisation appropriée comme des tableaux de bord, des listes et des contrôles, fait une différence en interne. L'utilisation des fonctionnalités du centre de confiance fournies par les outils GRC fait également une différence en externe pour vos clients et prospects. Cela a juste l'air professionnel.

Effort d'entretien — À long terme (12 mois+), la collecte de toutes les preuves et les tâches de suivi, les rapports et les statuts sont plus gérables avec un outil GRC. Même si les téléchargements manuels sont toujours nécessaires, la collecte automatisée de preuves via des API réduit les efforts manuels, d'où le nombre total d'heures et de ressources nécessaires.

Le processus manuel ne nécessite pas de frais supplémentaires pour l'outil GRC et, à long terme, l'outil GRC permet des économies et une meilleure expérience utilisateur et client.

Cependant, l’utilisation d’un outil GRC permet de collecter des preuves en continu tout au long de la période d’observation. Les cabinets CPA doivent respecter la méthodologie d'audit prescrite, ce qui signifie qu'ils testent les contrôles en fonction d'une fréquence d'échantillonnage prescrite ; par exemple, si vous exécutez des analyses de vulnérabilité mensuelles sur votre surface externe (application Web et adresses IP publiques), cela signifie que sur une période de 12 mois, vous devez avoir collecté 12 preuves de l'exécution des analyses, c'est-à-dire des rapports d'analyse. Le cabinet CPA doit valider plus de 50 % des échantillons, par exemple au moins six rapports d'analyse, et si vous ne pouvez pas les fournir, vous échouez à l'audit, et cela sera affiché dans la section de test ressemblant à ceci : "Exception notée : X % des six échantillons n'ont pas été présentés, ce qui indique que le contrôle n'est pas utilisé.» Une phrase que vous ne souhaitez pas montrer à votre prochain potentiellement gros client.

Par conséquent, la mise en place d’une opération de contrôle appropriée et d’un processus de collecte de preuves de conformité est vraiment la clé ici, car une erreur peut ruiner des années d’efforts.

Combien de temps cela prend-il ?

La réponse honnête est : cela dépend. Mais « ça dépend » n’est pas une réponse particulièrement utile, alors décomposons-la correctement. Les variables clés qui déterminent le calendrier sont : votre niveau de sécurité actuel (combien reste à mettre en œuvre), le montant de la dette technique dans votre infrastructure, la bande passante et la réactivité de votre équipe, et si vous avez des délais clients stricts qui repoussent le calendrier.

En utilisant le même scénario SaaS à distance de 25 personnes, voici une répartition réaliste :

DIY – à mains nues: Attendez-vous à 3 à 4 mois de mise en œuvre avant même d’être prêt à commencer la période d’observation. Cela suppose que vous êtes discipliné, raisonnablement instruit en matière de sécurité et que vous n'êtes pas distrait par votre travail réel consistant à créer un produit et à servir les clients. Ajoutez la période d'observation minimale de 3 mois en plus, et vous obtenez 6 à 7 mois entre le début et le rapport – au mieux.

DIY — Outil GRC : Le guidage de l'outil raccourcit la courbe d'apprentissage. En réalité, 2 à 3 mois de mise en œuvre suivis d'une période d'observation de 3 mois vous donnent un total d'environ 5 à 6 mois. La mise en garde : cela suppose que vous configurez et utilisez réellement l'outil GRC de manière cohérente, ce qui est plus difficile qu'il n'y paraît lorsque les délais des produits rivalisent pour attirer l'attention.

La voie d'un consultant : Environ 4 semaines pour la mise en œuvre (avec vos 15 à 25 heures de contribution), suivies de la période d'observation standard de 3 mois. Cela signifie que vous avez un rapport entre les mains environ 4 mois après le coup d'envoi. Ajoutez le processus d'audit de 4 à 8 semaines et 2 à 6 semaines pour que le cabinet CPA publie le rapport final, et vous êtes confortablement dans les 5 à 6 mois entre la première conversation et la lettre d'attestation signée. Notre service comprend tout, depuis l'outil GRC jusqu'au renforcement du cloud (oui, nous sommes des ingénieurs après tout et pouvons configurer et renforcer AWS/Azure/GCP selon les exigences de sécurité et de conformité), la sécurité des terminaux, les tests d'intrusion et les relations avec les auditeurs. Vous vous concentrez sur votre activité, nous nous occupons de la sécurité et de la conformité.

Une remarque importante sur la durée de la période d'observation : si 3 mois est le minimum, il existe une raison stratégique de l'étendre à 6 voire 12 mois à partir du deuxième cycle. Une période d'observation plus longue couvre une plus grande fenêtre de temps, ce qui réduit l'« écart » remarqué par les clients lorsque votre rapport précédent vieillit. Plus d’informations à ce sujet dans la section maintenance ci-dessous.

Combien ça coûte?

SOC 2 comporte trois catégories de coûts : la mise en œuvre, l'outillage et l'audit lui-même. Les proportions changent considérablement selon la voie que vous choisissez.

Coût de mise en œuvre :

- Le bricolage signifie que votre coût est mesuré en temps plutôt qu’en argent – ​​mais le temps, c’est de l’argent, surtout dans une entreprise en période de croissance. Donc, si vous avez le temps de comprendre les exigences, de procéder à l'évaluation des risques, de rédiger une révision et d'affiner les politiques, de configurer vos activations de sécurité et opérationnelles et de les exploiter, d'embaucher un testeur d'intrusion, d'exécuter des analyses de vulnérabilité, de trouver et de négocier avec le cabinet CPA, de gérer le processus d'audit, alors c'est votre voie. Au minimum, nous parlons ici de 80 à 100 heures de travail (même si vous utilisez une Gen AI et des ensembles de modèles disponibles), quel est votre taux horaire en tant que PDG/CTO/COO, etc ? Au moins 100$/heure (j'espère), calcul facile à partir d'ici.

- Un engagement de consultant pour une norme SOC 2 Type II relevant du TSC de sécurité (Critères communs uniquement) se situe généralement entre les cinq chiffres bas à moyens. La complexité, la portée et la dette technique feront grimper ce chiffre.

Outillage GRC : La plupart des plates-formes GRC destinées aux startups et aux scale-up coûtent entre quelques centaines et quelques milliers de dollars par mois, en fonction du niveau de fonctionnalités et de la taille de l'entreprise. Sur un cycle de 12 mois, il s'agit d'un délai important mais gérable – et comme indiqué précédemment, les gains d'efficacité à long terme justifient généralement les dépenses une fois que vous avez dépassé votre premier cycle d'audit.

L’audit (cabinet CPA) : C’est un coût douloureux mais qui doit avoir un coût. L’attestation doit être délivrée par un cabinet de CPA indépendant et agréé. Pour un audit de type II couvrant les critères communs (sécurité uniquement), attendez-vous à payer entre 10 000 et 25 000 dollars pour une entreprise réputée, bien que les entreprises spécialisées axées sur le SaaS se situent parfois en dessous de cette fourchette. L'ajout de catégories de services de confiance supplémentaires (disponibilité, confidentialité, etc.) augmente proportionnellement la portée et le coût. Vous ne voulez pas que votre rapport SOC 2 soit émis par une usine de certificats (des cabinets d'audit très bon marché, signant plus ou moins n'importe quoi moyennant des frais).

Le coût total tout compris d'un premier SOC 2 Type II (mise en œuvre, outillage et audit) se situe généralement entre 20 000 $ et 60 000 $ pour une entreprise dans notre scénario de référence, en fonction de la voie choisie et du cabinet de CPA engagé. Les cycles annuels ultérieurs sont moins coûteux, car le travail de mise en œuvre est en grande partie déjà effectué et la portée de l'audit devient plus prévisible.

Et n'oubliez pas que vous devez exécuter toutes les activités pertinentes (évaluation des risques, examen des politiques, test d'intrusion, etc. ainsi que l'audit) au moins une fois par an pour toujours disposer d'un rapport SOC 2 valide couvrant votre période d'observation standard de 12 mois.

Quel effort continu est requis ?

C’est la question que la plupart des gens oublient de poser avant de commencer, et celle qui cause le plus de douleur par la suite.

SOC 2 n'est pas un projet avec une ligne d'arrivée. C'est un engagement opérationnel. Obtenir le premier rapport est le début, pas la fin. Voici à quoi ressemble réellement « garder les lumières allumées » sur une base continue.

Collecte continue de preuves : Chaque contrôle qui sera testé lors du prochain audit doit être activement utilisé et démontré tout au long de la période d'observation. Les analyses de vulnérabilité doivent être exécutées dans les délais. Les examens d’accès doivent être complétés. Les politiques doivent être révisées chaque année. Des évaluations des fournisseurs doivent être effectuées. Rien de tout cela ne se produit tout seul : cela nécessite une appropriation assignée et un mécanisme de suivi fiable, qu'il s'agisse d'un outil GRC, d'un comité de gestion de projet ou d'une feuille de calcul bien entretenue. Faites-nous confiance là-dessus (toutes les variantes ont été réalisées et plusieurs fois, vous souhaitez utiliser un outil GRC).

Changements de personnel : Chaque fois qu'une personne rejoint ou quitte l'entreprise, le processus d'intégration et de désintégration doit être suivi correctement et documenté. L'approvisionnement en accès, la vérification des antécédents, les accusés de réception de formation de sensibilisation à la sécurité et la résiliation de l'accès sont tous des événements vérifiables. Un seul départ mal géré – le compte d’un ancien employé laissé actif pendant trois semaines – est le genre d’exception qui apparaît en bonne place dans les résultats des tests d’audit. C'est le moyen le plus simple de dérailler....

Modifications de l'infrastructure et des produits : Lorsque votre pile technologique évolue (adoption d'un nouveau service AWS, ajout d'une nouvelle intégration tierce, création d'un nouvel environnement de produit), le cadre de contrôle doit refléter ces changements. Les contrôles de gestion des changements et de gestion de la configuration existent précisément parce que les auditeurs vérifieront si vos contrôles documentés correspondent à votre environnement d'exploitation réel.

Le cycle d’audit annuel : Environ 12 mois après la fin de votre période d’observation, vous devrez recommencer le processus d’audit. La bonne nouvelle est que les audits ultérieurs sont nettement moins contraignants que le premier. Les politiques, le cadre de contrôle et les processus opérationnels sont déjà en place. L’audit consiste alors principalement à présenter la preuve que vous avez continué à faire ce que vous avez déclaré faire. Le défi est simplement qu’il faut avoir continué à le faire.

En pratique, l'effort mensuel continu pour un programme SOC 2 bien structuré dans une entreprise SaaS de 25 personnes est modeste : généralement quelques heures par mois au sein de l'équipe, pouvant atteindre quelques jours dans les semaines immédiatement avant et pendant l'audit. Le mot-clé est « bien structuré ». Les entreprises qui traitent le SOC 2 comme un exercice de coche de cases et laissent échapper la collecte de preuves se retrouvent à se bousculer avant chaque audit, ce qui est à la fois stressant et coûteux.

Réflexions finales

SOC 2 n’est pas magique. Cela ne garantit pas la sécurité de votre entreprise : la sécurité est ce qui sécurise votre entreprise. SOC 2 est le moyen standardisé et vérifié de manière indépendante de démontrer cette sécurité à vos clients et prospects. Cette distinction est importante, car les entreprises qui utilisent SOC 2 uniquement comme outil de vente, sans véritable engagement envers les contrôles sous-jacents, ont tendance à se retrouver avec des rapports remplis d'exceptions et des processus opérationnels qui s'effondrent entre les audits.

Bien réalisé, un programme SOC 2 est véritablement précieux. Cela impose de clarifier votre posture de sécurité, fait apparaître les dettes techniques avant qu'elles ne deviennent une violation et crée une responsabilité interne qui profite à l'ensemble de l'organisation. Le rapport d’attestation est le résultat – l’amélioration de la maturité de la sécurité est le véritable retour sur investissement.

Pour résumer les points clés de cet article :

• SOC 2 est une méthodologie d'audit, pas une certification. Vous recevez un rapport d'attestation d'un cabinet de CPA agréé, et non un certificat d'un organisme de normalisation.

• Le type I valide l'existence du contrôle à un moment donné. Le type II valide que les contrôles ont été effectués efficacement sur une période d'observation définie. Les clients demanderont presque toujours le type II.

• La voie que vous choisissez (bricolage, outil GRC ou consultant) affecte principalement la vitesse, les efforts internes et le risque d'échec, et non la question de savoir si le résultat est réalisable.

• Le temps total nécessaire pour obtenir le premier rapport varie d'environ 5 mois (avec un consultant) à plus de 7 mois (entièrement DIY). L'audit lui-même prend 6 à 14 semaines supplémentaires en plus de la période d'observation.

• SOC 2 est un engagement annuel. La charge opérationnelle permanente est gérable si le cadre est correctement mis en place dès le départ – et pénible dans le cas contraire.

Si vous êtes une entreprise SaaS évaluant vos options ou travaillant sur votre premier (ou prochain) SOC 2, nous sommes heureux d'avoir un conversation de cadrage initiale sans frais. Nous avons aidé des dizaines d'entreprises dans ce processus (et les avons aidées à vendre à Amazon, Siemens, Disney, Bank of America, Google, Zeiss, etc.) et un appel de 30 minutes suffit généralement pour vous donner une idée claire de votre situation, de ce qui est impliqué et d'un calendrier réaliste pour votre situation spécifique.

‍

À propos de l'auteur :

Clarify Consult Partner travaille dans le domaine de la sécurité depuis plus de 23 ans, dont une décennie et demie passée dans le monde des affaires, travaillant dans de petites entreprises comme Vodafone, AXA, Royal Bank of Scotland, Bank of Tokyo. Depuis 2019, il a aidé plus de 150 entreprises SaaS à répondre aux besoins en matière de sécurité, de confidentialité et de réclamation, et travaille continuellement à fournir des services de conseil axés sur la qualité. Clarify Consult Partner est certifié ISO/IEC 27001, membre de la Cloud Security Alliance, ISACA, ISC2 et dispose d'une incroyable équipe de Clarify Consult Partner pour aider les clients à vendre aux entreprises.

‍