Comment préparer votre org Salesforce à un audit

Réponse courte : un auditeur ne veut pas une visite guidée de votre org. Il veut trois dossiers de preuves : qui avait accès et qui l'a approuvé, ce qui a changé en production et qui l'a validé, et combien de temps vous conservez les données avant de les supprimer. Si ces trois exports sont une routine, l'audit est une réunion. Sinon, c'est deux semaines de panique.

Que demande vraiment un auditeur à une équipe Salesforce ?

La plupart des conseils sur l'audit Salesforce décrivent un contrôle interne de santé : champs morts, rapports inutilisés, nettoyage du stockage. Utile, mais ce n'est pas ce que teste un auditeur externe. Sous SOX, SOC 2 ou ISO 27001, il échantillonne et vous demande de prouver un contrôle :

• Preuve d'accès. Une liste d'utilisateurs avec profils, permission sets et rôles, plus qui a approuvé chaque attribution et quand elle a été revue.
• Preuve de changement. Pour un échantillon de changements en production : la demande, l'approbation, le résultat des tests et l'enregistrement du déploiement.
• Preuve de conservation et de suppression. Quelles données personnelles vous détenez, combien de temps, et la preuve que les demandes d'effacement ont été exécutées.

Presque tous les constats que nous voyons viennent de ces trois points, pas d'une page layout en désordre.

Qu'est-ce qui est dans le périmètre, et qui le décide ?

Vous le décidez d'abord, puis vous le défendez. Le périmètre suit le risque, pas l'organigramme :

• Information financière (SOX) : devis, commandes, facturation, objets de revenu et toute automatisation capable de modifier ces valeurs, utilisateurs d'intégration compris.
• Données personnelles (RGPD et équivalents) : Contact, Lead, Case, Person Account, transcriptions de chat et chaque copie sandbox.
• Accès privilégiés : Modify All Data, View All Data, Manage Users, Author Apex, et quiconque peut déployer.

Écrivez cela dans une note de périmètre d'une page avant la réunion de lancement. Un auditeur obligé de définir le périmètre à votre place le définira largement.

Comment produire une preuve d'accès sans captures d'écran ?

Les captures vieillissent mal et ne disent rien des 51 autres semaines de l'année. Exportez plutôt, selon un calendrier :

1. Interrogez les objets de permission. PermissionSetAssignment, ObjectPermissions et FieldPermissions donnent l'image réelle, y compris ce qui passe par les permission set groups.
2. Exportez le Login History. Salesforce en conserve six mois en ligne, téléchargeables en CSV. Les comptes dormants aux droits actifs sont le constat classique.
3. Lancez Security Health Check et Optimizer et gardez la sortie. Un auto-diagnostic daté est accepté comme preuve qu'une surveillance existe.
4. Faites la revue chaque trimestre, avec un approbateur nommé. Une revue d'accès que personne n'a signée n'est pas un contrôle. Notez le relecteur, la date et les exceptions.

Les utilisateurs d'intégration méritent leur propre ligne. Ils portent souvent les droits les plus larges et l'attention la plus faible, et les auditeurs ont appris à regarder là en premier.

Comment produire une preuve de changement ?

C'est là que les change sets font mal. Ils ne séparent pas celui qui construit de celui qui déploie et ne laissent aucune approbation liée. Un pipeline répond par des liens : le work item et sa raison métier, le commit montrant exactement quelles métadonnées ont bougé, la pull request avec un relecteur différent de l'auteur, le résultat des tests et l'enregistrement du déploiement.

Deux propriétés décident du résultat. La preuve doit être immuable et complète, c'est-à-dire qu'aucune route vers la production ne la contourne. Un processus qui couvre la plupart des changements échoue quand même, car l'échantillon peut tomber sur l'exception.

L'historique natif aide sans tout porter. Le Setup Audit Trail garde 180 jours et s'interroge via l'objet SetupAuditTrail avant purge. Le Field History Tracking conserve environ 18 mois dans l'interface et 24 via l'API, sauf si vous souscrivez Field Audit Trail avec Salesforce Shield et définissez une politique de rétention. Les cycles d'audit sont annuels : gardez votre propre copie dans Git et votre plateforme DevOps.

Comment prouver la conservation et la suppression ?

La conservation est la question la plus mal traitée, parce que personne ne la porte. Trois artefacts la règlent :

• Une cartographie : quels objets et champs contiennent des données personnelles, et la base légale de chacun.
• Un calendrier de conservation par objet, avec le mécanisme de suppression nommé (job planifié, archive, suppression définitive).
• Un journal de suppression montrant que les demandes d'effacement ont été exécutées, y compris en sandbox et dans les sauvegardes.

La ligne sandbox est celle qui surprend. Une sandbox complète rafraîchie depuis la production est une copie des mêmes données personnelles dans un environnement moins contrôlé. Semez un sous-ensemble et masquez les champs personnels pendant le refresh, pour que le contrôle produise sa propre preuve.

Comment se préparer en deux semaines plutôt qu'en deux mois ?

1. Jours 1-2 : rédigez la note de périmètre et nommez un responsable par dossier de preuves.
2. Jours 3-5 : exportez les données d'accès, lancez Health Check, listez chaque utilisateur d'intégration et chaque profil privilégié.
3. Jours 6-8 : prenez 10 changements récents au hasard et déroulez-les de bout en bout. Ce que vous ne pouvez pas tracer est votre vrai constat.
4. Jours 9-10 : rédigez le calendrier de conservation et vérifiez le traitement des données en sandbox.
5. Automatisez ensuite ce que vous venez de faire à la main, pour que l'an prochain soit un export et non un projet.

Cette dernière étape fait tout. Les équipes qui passent proprement n'ont pas l'org la plus rangée : elles ont des contrôles qui tournent seuls et laissent une trace. Tekunda construit Salesforce ainsi, comme SI, ISV et PDO certifié, et nous avons fait passer des packages managés par la security review AppExchange en santé, logistique et industrie, là où quelqu'un d'autre fixe le niveau de preuve.

FAQ

Combien de temps Salesforce garde-t-il l'historique des changements de setup ?

Le Setup Audit Trail conserve 180 jours puis purge. Exportez-le régulièrement ou gardez l'équivalent dans votre plateforme DevOps.

Faut-il Salesforce Shield pour passer un audit ?

Pas forcément. Shield allonge la rétention de l'historique de champs et ajoute l'Event Monitoring, mais les contrôles et leurs preuves comptent plus que la licence.

À quelle fréquence faire les revues d'accès ?

Chaque trimestre pour les accès privilégiés et les utilisateurs d'intégration, au moins une fois par an pour les autres, avec un approbateur nommé à chaque fois.

Une sandbox complète avec des données de production pose-t-elle problème ?

Cela peut. Traitez-la comme un traitement : semez un sous-ensemble au lieu de cloner, masquez les champs personnels pendant le refresh et restreignez l'accès comme en production.