Politiques et procédures SOC 2 : ce que vous devez documenter

Les politiques sont le socle de chaque audit SOC 2. Elles documentent ce que votre organisation s’engage à faire, et les auditeurs testent si vous le faites réellement. Il n’y a pas de raccourci ici — sans politiques bien rédigées et applicables, votre rapport SOC 2 échouera ou sera tellement assorti de réserves qu’il perdra sa valeur auprès des clients.

Les entreprises SaaS sous-estiment souvent l’effort lié aux politiques. Elles supposent que le SOC 2 est principalement un exercice technique — configurer le MFA, chiffrer les données, mettre en place une surveillance. Ces contrôles comptent, mais ils existent pour mettre en œuvre vos politiques. La première étape d’un auditeur est de lire vos politiques. La deuxième est de vérifier si vos opérations correspondent à ce que les politiques disent. S’il y a un écart entre les deux, vous avez une constatation.

Ce guide couvre chaque politique et procédure dont une entreprise SaaS a besoin pour le SOC 2, ce qui rend chacune prête pour l’audit et les erreurs qui causent le plus de problèmes pendant la saison d’audit.

Politiques vs. Procédures vs. Normes

Avant de plonger dans la liste, comprenez la hiérarchie. Ces trois types de documents servent des objectifs différents, et votre auditeur s’attend à voir les distinctions clairement.

Les politiques définissent ce que votre organisation fera et pourquoi. Elles établissent des engagements, attribuent la responsabilité et fixent des attentes. Une politique est approuvée par la direction et s’applique largement à l’ensemble de l’organisation. Exemple : « Tout accès utilisateur suivra le principe du moindre privilège. »

Les normes définissent les références spécifiques que votre organisation doit atteindre. Elles traduisent les engagements des politiques en seuils mesurables. Exemple : « Les mots de passe doivent comporter au moins 14 caractères et être changés tous les 90 jours. »

Les procédures définissent comment quelque chose est fait, étape par étape. Ce sont des instructions opérationnelles que les employés suivent pour mettre en œuvre les politiques et respecter les normes. Exemple : « Pour créer un nouveau compte utilisateur, soumettez une demande dans Jira en utilisant le modèle de demande d’accès, obtenez l’approbation du manager et configurez le compte dans Okta avec le rôle spécifié dans le ticket. »

Un programme de conformité bien structuré superpose les trois : les politiques fixent la direction, les normes fixent le niveau d’exigence et les procédures indiquent exactement ce qu’il faut faire. Quand les auditeurs voient cette structure, cela signale la maturité.

Politiques essentielles requises

Chaque rapport SOC 2 — quel que soit les Critères de service de confiance que vous incluez — nécessite un ensemble de politiques fondamentales. Voici les dix politiques que les entreprises SaaS doivent avoir documentées et appliquées.

1. Politique de sécurité de l’information

C’est votre document de sécurité principal. Il établit le périmètre de votre programme de sécurité, définit les rôles et responsabilités et articule l’engagement de votre organisation à protéger les actifs informationnels.

Ce qu’elle couvre : Objectifs du programme de sécurité, périmètre (quels systèmes, données et personnel sont inclus), parrainage exécutif, rôles (RSSI, équipe de sécurité, responsables de l’ingénierie) et la relation entre cette politique et toutes les politiques subordonnées.

En pratique : Votre politique de sécurité de l’information est le document parent. Chaque autre politique de sécurité devrait la référencer. Les auditeurs l’utilisent pour comprendre les limites de votre périmètre SOC 2, alors soyez précis sur ce qui est inclus et ce qui ne l’est pas.

Exemple SaaS : Votre politique stipule que tous les systèmes de production hébergés sur AWS, tous les postes de travail des employés et toutes les intégrations tierces traitant des données clients relèvent du périmètre du programme de sécurité. Les outils internes qui ne touchent pas aux données clients sont explicitement hors périmètre.

2. Politique de contrôle des accès

Le contrôle des accès est l’un des domaines les plus testés dans tout audit SOC 2. Cette politique définit comment votre organisation gère l’accès utilisateur tout au long de son cycle de vie.

Ce qu’elle couvre : Provisionnement et déprovisionnement des utilisateurs, contrôle d’accès basé sur les rôles (RBAC), moindre privilège, exigences d’authentification multi-facteurs (MFA), gestion des accès privilégiés, gouvernance des comptes de service et revues d’accès périodiques.

En pratique : Les auditeurs extrairont vos listes d’accès utilisateurs et les compareront avec cette politique. Ils vérifieront que les employés ayant quitté l’entreprise ont été déprovisionnés dans le délai spécifié par votre politique. Ils vérifieront que le MFA est appliqué là où vous dites qu’il l’est. Chaque affirmation dans cette politique devient testable.

Exemple SaaS : Votre politique exige le MFA pour tout accès aux systèmes de production, des revues d’accès trimestrielles avec remédiation documentée et un déprovisionnement dans les 24 heures suivant le départ d’un employé.

3. Politique de gestion des changements

La gestion des changements régit la manière dont les modifications de vos systèmes — code, infrastructure, configurations — sont proposées, examinées, approuvées et déployées. Pour les entreprises SaaS livrant du code quotidiennement, cette politique doit refléter votre workflow de développement réel.

Ce qu’elle couvre : Exigences de revue de code, processus de déploiement, exigences de test, workflows d’approbation, procédures de changement d’urgence, procédures de rollback et documentation des changements.

En pratique : Les auditeurs échantillonneront des pull requests et des déploiements de votre période d’observation. Ils vérifieront que les revues de code ont eu lieu avant la fusion, que les déploiements ont suivi votre processus documenté et que les changements d’urgence ont été rétroactivement documentés et approuvés.

Exemple SaaS : Votre politique exige que tous les changements en production passent par une pull request avec au moins une revue par un pair, réussissent les tests du pipeline CI/CD et soient déployés via votre système de déploiement automatisé. Les correctifs d’urgence peuvent contourner la revue standard mais nécessitent une revue post-déploiement dans les 48 heures et une justification documentée.

4. Politique de réponse aux incidents

Votre politique de réponse aux incidents définit comment votre organisation détecte, répond à et se remet des incidents de sécurité. C’est l’une des politiques les plus scrutées car elle affecte directement la protection des données clients. Pour une analyse approfondie de la construction d’une capacité de réponse aux incidents efficace, consultez notre guide de réponse aux incidents.

Ce qu’elle couvre : Classification des incidents et niveaux de gravité, mécanismes de détection, procédures d’escalade, étapes de confinement et d’éradication, procédures de reprise, protocoles de communication (internes et externes), processus de revue post-incident et préservation des preuves.

En pratique : Les auditeurs demanderont les logs d’incidents de la période d’observation. Si vous avez eu des incidents, ils traceront votre réponse par rapport à cette politique. Si vous n’avez eu aucun incident, ils testeront vos capacités de détection pour confirmer que vous en détecteriez effectivement un.

Exemple SaaS : Votre politique définit quatre niveaux de gravité (P1-P4), exige une war room pour un incident P1 dans les 15 minutes suivant la détection, impose une notification client dans les 72 heures pour les violations de données et exige un post-mortem écrit pour tous les incidents P1 et P2 dans les cinq jours ouvrables.

5. Politique d’évaluation des risques

L’évaluation des risques est fondamentale pour le SOC 2 — les Common Criteria exigent explicitement un processus formel et reproductible d’identification et d’évaluation des risques. Pour un parcours complet du processus d’évaluation des risques, consultez notre guide d’évaluation des risques.

Ce qu’elle couvre : Méthodologie d’évaluation des risques (qualitative, quantitative ou hybride), fréquence d’évaluation (au moins annuellement), approche d’identification des risques, critères de notation de la probabilité et de l’impact, seuils d’acceptation du risque, options de traitement du risque (atténuer, transférer, accepter, éviter) et rôles responsables de la gestion des risques.

En pratique : Les auditeurs veulent voir une méthodologie documentée, une évaluation des risques complétée pendant la période d’observation et des preuves que les risques identifiés ont été suivis et traités. Une évaluation des risques qui reste sur une étagère intouchée pendant 11 mois est une constatation.

6. Politique de gestion des fournisseurs

Votre rapport SOC 2 n’est aussi solide que votre écosystème de fournisseurs. Cette politique régit la manière dont vous évaluez, intégrez, surveillez et désengagez les tiers. Pour le cadre complet de gestion des fournisseurs, consultez notre guide de gestion des fournisseurs.

Ce qu’elle couvre : Classification des fournisseurs par niveau de risque, exigences de diligence raisonnable (revue de rapport SOC 2, questionnaires de sécurité), exigences contractuelles de sécurité, cadence de surveillance continue, gestion des sous-traitants et procédures de désengagement des fournisseurs.

En pratique : Les auditeurs examineront votre inventaire de fournisseurs, vérifieront que les fournisseurs critiques ont été évalués et confirmeront que vous avez examiné leurs rapports SOC 2 pendant la période d’observation.

7. Politique de classification des données

La classification des données définit comment votre organisation catégorise l’information en fonction de sa sensibilité et les exigences de traitement pour chaque catégorie. Cette politique guide les décisions de chiffrement, d’accès, de conservation et d’élimination dans l’ensemble de votre pile.

Ce qu’elle couvre : Niveaux de classification (ex. : Public, Interne, Confidentiel, Restreint), critères d’attribution des classifications, exigences de traitement par niveau (stockage, transmission, accès, élimination), attentes d’étiquetage des données et qui a l’autorité de classifier les données.

Exemple SaaS : Les données clients dans votre base de données de production sont classifiées comme Confidentielles, nécessitant le chiffrement au repos et en transit, un accès restreint aux services et au personnel autorisés, et une suppression sécurisée à la résiliation du contrat. La documentation interne est classifiée comme Interne, nécessitant une authentification mais pas de chiffrement au repos.

8. Politique d’utilisation acceptable

La politique d’utilisation acceptable définit les responsabilités des employés lors de l’utilisation des systèmes, réseaux et données de l’entreprise. Elle fixe les attentes comportementales et établit la base des mesures disciplinaires en cas de violation.

Ce qu’elle couvre : Usages autorisés et interdits des systèmes de l’entreprise, politiques relatives aux appareils personnels, utilisation d’internet et des e-mails, directives sur les réseaux sociaux, responsabilités de traitement des données, règles d’installation de logiciels et conséquences en cas de violation.

En pratique : Chaque employé devrait signer cette politique lors de son intégration. Les auditeurs vérifieront les enregistrements d’accusé de réception. Cette politique sert également de base aux procédures disciplinaires liées aux violations de sécurité.

9. Politique de continuité d’activité et de reprise après sinistre

Si vous incluez le critère Disponibilité dans votre périmètre SOC 2 — et la plupart des entreprises SaaS le font — vous avez besoin d’une politique PCA/PRS documentée. Même sans la Disponibilité, les Common Criteria du critère Sécurité abordent la reprise des systèmes.

Ce qu’elle couvre : Objectif de temps de reprise (RTO) et objectif de point de reprise (RPO) pour les systèmes critiques, procédures de sauvegarde et vérification, mécanismes de basculement, fréquence et méthodologie des tests de reprise après sinistre, plans de communication pendant les pannes et rôles et responsabilités pendant un événement de sinistre.

Exemple SaaS : Votre politique fixe un RTO de 4 heures et un RPO de 1 heure pour votre application de production. Les sauvegardes s’exécutent toutes les heures vers une région AWS distincte. Le basculement DR est testé trimestriellement avec des résultats documentés, et le dernier test réussi a restauré le service complet en 2,5 heures.

10. Politique de sécurité des ressources humaines

Les personnes constituent une couche de contrôle critique. Cette politique couvre les aspects sécuritaires du cycle de vie des employés, de l’embauche à l’après-départ.

Ce qu’elle couvre : Exigences de vérification des antécédents, formation à la sécurité lors de l’intégration (et annuellement ensuite), accords de confidentialité et de non-divulgation, responsabilités de sécurité basées sur les rôles, procédures de départ (révocation d’accès, restitution des actifs, entretiens de sortie) et processus disciplinaire pour les violations de sécurité.

En pratique : Les auditeurs échantillonneront les dossiers des employés pour vérifier que les vérifications d’antécédents ont été effectuées, que des enregistrements de formation existent et que les employés partis ont été correctement déprovisionnés. Si votre politique dit que les vérifications d’antécédents sont terminées avant la date de début, ils vérifieront les dates.

Ce qui rend une politique prête pour l’audit

Rédiger une politique ne suffit pas — elle doit répondre à des normes de qualité spécifiques que les auditeurs évaluent. Voici ce qui distingue une politique qui passe d’une qui génère des constatations.

Contrôle de version et dates d’approbation. Chaque politique doit indiquer quand elle a été créée, révisée pour la dernière fois, approuvée et par qui. Les auditeurs examinent la date d’approbation par rapport à la période d’observation. Une politique approuvée il y a trois ans sans preuve de revue est un problème.

Propriété claire. Chaque politique a besoin d’un propriétaire désigné responsable de son contenu, de son application et de sa revue. « L’équipe sécurité » n’est pas assez spécifique. Nommez le rôle : « Le RSSI est responsable de la Politique de sécurité de l’information. »

Exigences spécifiques et mesurables. « L’accès devrait être revu régulièrement » échoue. « Les revues d’accès sont réalisées trimestriellement, avec remédiation complétée dans les 14 jours ouvrables » passe. Chaque engagement dans une politique devient une assertion testable.

Cadence de revue régulière. Les politiques doivent être revues au moins annuellement. Documentez la date de revue, qui l’a réalisée et quels changements ont été apportés (ou indiquez explicitement « aucun changement nécessaire »). Les auditeurs vérifieront que cela a eu lieu pendant la période d’observation.

Accusé de réception des employés. Les employés doivent formellement accuser réception des politiques clés — au minimum la Politique de sécurité de l’information et la Politique d’utilisation acceptable. Suivez les accusés de réception avec dates et conservez les enregistrements.

Alignement avec la pratique réelle. C’est le critère le plus important et celui qui cause le plus de constatations d’audit. Si votre politique dit quelque chose, vous devez le faire. Les auditeurs testeront la politique par rapport à la réalité opérationnelle. Une politique aspirationnelle qui ne correspond pas à vos opérations est pire que pas de politique du tout, car elle démontre une défaillance de contrôle.

Erreurs courantes liées aux politiques

Après avoir travaillé avec des centaines d’entreprises SaaS, voici les erreurs de politique que nous rencontrons le plus fréquemment.

Copier-coller de modèles sans personnalisation. Les modèles génériques utilisent un langage comme « l’organisation maintiendra des contrôles d’accès physiques aux salles de serveurs ». Si vous êtes une entreprise SaaS cloud-native fonctionnant sur AWS, vous n’avez pas de salles de serveurs. Les auditeurs signaleront immédiatement les politiques qui ne reflètent pas votre environnement réel. Les modèles sont un point de départ, pas un produit fini.

Rédiger des politiques aspirationnelles. Votre politique dit que les revues d’accès ont lieu mensuellement. Vos preuves montrent qu’elles ont lieu trimestriellement — parfois. Cela crée une défaillance de contrôle pire que d’avoir une politique trimestrielle, car vous avez démontré que vous ne respectez pas vos propres engagements. Rédigez des politiques qui correspondent à ce que vous faites réellement, puis améliorez de manière itérative.

Métadonnées de revue et d’approbation manquantes. Une politique sans date d’approbation, numéro de version ou approbateur nommé est incomplète. Certaines organisations rédigent un excellent contenu de politique mais oublient le cadre administratif qui l’entoure. Les auditeurs vérifient d’abord les métadonnées.

Politiques trop complexes que personne ne lit. Une politique de sécurité de l’information de 40 pages couvrant chaque scénario imaginable est techniquement exhaustive et pratiquement inutile. Si vos ingénieurs ne peuvent pas trouver rapidement les exigences pertinentes pour leur travail, la politique ne remplit pas son rôle. Gardez les politiques ciblées et lisibles. Transférez les instructions détaillées dans les procédures.

Ne pas mettre à jour après des changements organisationnels. Vous avez migré d’AWS vers GCP, promu un nouveau RSSI ou restructuré votre équipe d’ingénierie. Si vos politiques font encore référence à l’ancien environnement, l’ancien RSSI ou l’ancienne structure d’équipe, les auditeurs remarqueront l’incohérence.

Procédures : les détails opérationnels

Les procédures sont l’endroit où les politiques deviennent opérationnelles. Alors qu’une politique stipule « l’accès utilisateur sera revu trimestriellement », la procédure définit exactement comment cette revue est menée, qui la fait, quels outils sont utilisés et comment la remédiation est suivie.

Procédures clés pour les entreprises SaaS

Procédure de revue d’accès utilisateur. Instructions étape par étape pour mener les revues d’accès trimestrielles : qui extrait les listes d’accès, quels systèmes sont examinés, comment les écarts sont documentés, comment la remédiation est assignée et suivie, et comment la revue complétée est stockée comme preuve.

Procédure de déploiement des changements. Le workflow détaillé pour amener le code d’une branche de développeur à la production : conventions de nommage des branches, exigences du modèle de PR, assignation des réviseurs, étapes du pipeline CI/CD, étapes de vérification en staging, processus de déploiement en production et exigences de tests de validation.

Procédure de gestion des vulnérabilités. Comment les vulnérabilités sont identifiées (outils d’analyse, fréquence), triées (classification de la gravité), assignées à des propriétaires, remédiées dans le SLA (critique : 7 jours, élevé : 30 jours, moyen : 90 jours) et vérifiées comme résolues. Incluez le processus pour les exceptions et les risques acceptés.

Procédure de sauvegarde et restauration. Étapes détaillées pour configurer les sauvegardes, vérifier l’intégrité des sauvegardes (cadence de vérification automatisée et manuelle), effectuer une restauration et documenter les résultats. Incluez le calendrier des tests de restauration.

Procédure de réponse aux incidents. Le playbook étape par étape pour chaque niveau de gravité d’incident : qui est notifié et comment, quels canaux de communication sont utilisés, comment la war room est configurée, étapes de confinement par type d’incident, exigences de préservation des preuves, modèles de communication client et modèle et calendrier de post-mortem.

Chaque procédure devrait explicitement référencer la politique parente qu’elle met en œuvre. Cette traçabilité est quelque chose que les auditeurs recherchent — elle démontre que vos détails opérationnels sont régis par des engagements approuvés.

Preuves de conformité aux politiques

Les auditeurs ne vous croient pas sur parole. Ils testent si vos opérations correspondent à vos politiques en examinant les preuves sur l’ensemble de la période d’observation. Pour un guide complet sur la collecte de preuves, consultez notre guide de collecte de preuves.

Preuves de contrôle d’accès : Rapports de revue d’accès trimestriels montrant qui a examiné quoi, les écarts trouvés et la remédiation effectuée. Configurations d’application du MFA. Tickets de déprovisionnement avec horodatages montrant la conformité avec votre SLA.

Preuves de gestion des changements : Historique des pull requests montrant les revues de code avant fusion. Logs de déploiement correspondant à votre processus documenté. Tickets de changement d’urgence avec approbations rétrospectives.

Preuves de réponse aux incidents : Tickets d’incident avec horodatages montrant la détection, la réponse et la résolution. Rapports de post-mortem pour les incidents significatifs. Enregistrements de communication montrant les notifications client lorsque requises.

Preuves de formation : Enregistrements de suivi de formation avec dates. Logs d’accusé de réception des politiques. Dossiers d’intégration des nouveaux employés montrant que la formation à la sécurité a été complétée dans le délai requis.

Preuves d’évaluation des risques : Documents d’évaluation des risques complétés et datés dans la période d’observation. Registre des risques montrant les plans de traitement et les mises à jour de statut. Procès-verbaux de réunions de revue des risques.

L’écart le plus courant entre politique et pratique est le timing. Votre politique dit que les revues d’accès ont lieu trimestriellement. Vous avez complété trois revues pendant une période d’observation de 12 mois au lieu de quatre. C’est une constatation — non pas parce que vos revues étaient inadéquates, mais parce que vous n’avez pas respecté votre propre fréquence déclarée. C’est pourquoi rédiger des politiques réalistes est si important.

Comment GRCTrail vous aide

GRCTrail offre aux équipes SaaS une approche structurée pour construire et maintenir le cadre de politiques que le SOC 2 exige.

• Modèles de politiques alignés sur les Common Criteria SOC 2 couvrant chaque domaine de politique requis, rédigés spécifiquement pour les entreprises SaaS afin que vous n’ayez pas à supprimer les références aux centres de données physiques
• Gestion des politiques avec contrôle de version avec des workflows d’approbation intégrés, le suivi des revues et un historique des modifications que les auditeurs peuvent vérifier indépendamment
• Suivi des accusés de réception des employés enregistrant quand chaque membre de l’équipe a examiné et accepté les politiques, avec des rappels automatisés pour les nouvelles recrues et les mises à jour de politiques
• Rappels de revue des politiques qui se déclenchent avant votre échéance de revue annuelle, garantissant que vous ne manquez jamais un cycle de revue pendant votre période d’observation
• Collecte de preuves liées connectant les politiques aux contrôles qui les mettent en œuvre et aux preuves qui prouvent la conformité — pour toujours savoir s’il y a un écart entre ce que vous vous êtes engagé à faire et ce que vous faites réellement

Commencez avec GRCTrail →

Guides connexes

• Qu’est-ce que le SOC 2 ? Guide pratique pour les entreprises SaaS
• Collecte de preuves SOC 2 : ce que les auditeurs recherchent réellement
• Guide d’évaluation des risques SOC 2
• Les Common Criteria SOC 2 expliqués