RGPD, SOC2 et la checklist SaaS B2B qui débloque l'approvisionnement
Ce que les acheteurs B2B veulent réellement dire lorsqu'ils demandent « êtes-vous conforme au RGPD? » — une checklist qui fait le lien entre les termes juridiques et les livrables d'ingénierie qui concluent la vente.
Lorsqu'un acheteur demande « êtes-vous conforme au RGPD? », il ne pose pas une question à réponse oui ou non. Il demande si votre entreprise peut produire les dix documents, les quatre registres et le journal d'audit dont leur responsable des achats a besoin pour les joindre au contrat. La checklist ci-dessous est celle que nous remettons à un prospect B2B lorsqu'il souhaite vérifier la conformité.
Les dix documents
Il ne s'agit pas d'avis juridiques, mais ils font correspondre la checklist typique de l'approvisionnement B2B de l'UE au travail d'ingénierie et de politique qui soutient chaque élément :
- Un accord de traitement des données (DPA) signé. Modèle prêt à l'exécution sur demande. Reflète l'Art. 28 du RGPD.
- Un registre des activités de traitement. Liste interne ROPA indiquant les finalités, les catégories de données, les destinataires, la durée de conservation et la base juridique.
- Une liste des sous-traitants. Chaque fournisseur qui touche aux données de l'acheteur, avec les noms et un processus de notification de changement.
- Une évaluation de l'impact du transfert (TIA). Pour toute donnée quittant l'EEE — même pour un fournisseur SaaS américain avec un sous-traitant sur la côte ouest.
- Un processus de notification de violation. Délai de 72 heures pour l'autorité de contrôle ; délai sans retard injustifié pour les personnes concernées en cas de violations à haut risque.
- Un processus relatif aux droits des personnes concernées. Réception des DSAR, vérification de l'identité, SLA de réponse (30 jours) et le travail d'ingénierie pour satisfaire une demande de suppression ou d'exportation.
- Un calendrier de conservation. Ce que nous conservons, combien de temps, comment c'est supprimé et quel système est responsable de la suppression.
- Une politique de cookies et de tracking. Ce qui s'exécute sur le site marketing, l'application produit, le tableau de bord admin et pourquoi chaque cookie existe.
- Un document de présentation de la sécurité. Chiffrement en transit, chiffrement au repos, gestion des clés, contrôle d'accès, réponse aux incidents.
- Une posture de disponibilité. Engagements de temps de disponibilité (uptime), ce qui est exclu (un SLA équitable) et le scénario de reprise après sinistre.
Le travail d'ingénierie qui soutient chaque élément
Un acheteur qui lit les dix documents demandera ensuite à l'équipe d'ingénierie de lui présenter la mise en œuvre. Les éléments non évidents, par ordre de fréquence d'apparition :
Exécution des demandes d'accès des personnes concernées (DSAR)
L'acheteur veut voir vos points de terminaison (endpoints) de suppression et d'exportation, avec journalisation d'audit et vérification d'identité forcée. Le travail d'ingénierie :
- Un
DELETE /api/users/{id}qui annule le compte, purge les données personnelles et conserve une entrée dans le journal d'audit sans les données personnelles elles-mêmes. - Un
GET /api/users/{id}/exportqui renvoie une archive lisible par machine de chaque entité ayant référencé l'utilisateur. - La vérification de l'identité sur les deux — avec un timing égalisé par bcrypt même lorsque l'e-mail n'existe pas (pour que le temps de réponse ne permette pas l'énumération des utilisateurs).
Gestion des sous-traitants
L'acheteur veut une liste et un processus de notification de changement. Travail d'ingénierie :
- Une liste de sous-traitants versionnée dans la documentation, avec un flux RSS ou un webhook pour les changements.
- Un chemin de code qui rejette les dépendances qui envoient des données en dehors de la liste documentée (un contrôle CI ou une liste d'autorisation au runtime).
Résidence de l'UE pour l'inférence et le stockage
De nombreux acheteurs B2B n'achèteront pas un SaaS dont la base de données principale est située aux États-Unis. Le travail d'ingénierie :
- Fixer la région MongoDB sur l'UE (
eu-west-1ou similaire). - Fixer tout fournisseur d'inférence tiers sur un endpoint de l'UE, et faire apparaître cela dans le DPA.
- Documenter la résidence des données dans la présentation de la sécurité.
Application de la conservation
La plupart des startups peuvent produire une politique de conservation. La question plus difficile est : « est-elle appliquée? » Travail d'ingénierie :
- Une tâche planifiée qui scanne les enregistrements ayant dépassé leur délai de conservation et les supprime.
- Un journal de la tâche, accessible à l'acheteur sur demande.
- Un test explicite que la tâche s'exécute (pas seulement une assertion CI qu'elle compile).
Journalisation d'audit
Presque tous les questionnaires de sécurité le demandent. Travail d'ingénierie :
- Une entité de journal d'audit centralisée, en ajout uniquement (append-only), alimentée par un intercepteur ou un middleware.
- Conservation : plus longue que ce que l'acheteur attend (30 jours par défaut, configurable à la hausse). Jamais plus courte.
Contrôle d'accès sur le tableau de bord admin
Les acheteurs veulent savoir qui, dans votre entreprise, peut voir leurs données. Travail d'ingénierie :
- Une politique d'accès documentée qui nomme les rôles, les humains dans chaque rôle et la piste d'audit des accès.
- Un TTL court sur l'accès à la production (nous utilisons un TTL de 4 heures délivré à la demande avec un commentaire de justification).
Le piège : le SOC 2 comme destination vs une pratique continue
L'erreur que commettent la plupart des entreprises SaaS B2B en démarrage est de traiter le SOC 2 comme une ligne d'arrivée. Ce n'est pas le cas. Les audits SOC 2 sont ponctuels ; l'acheteur lira votre posture de contrôle continu, pas seulement le rapport d'audit le plus récent. Le travail d'ingénierie qui rend cela continu :
- Le planificateur de conservation s'exécute dans la CI comme une tâche de vérification (la requête renvoie-t-elle des résultats non périmés?).
- Les écritures du journal d'audit alimentent un tableau de bord que quelqu'un surveille réellement.
- La liste des sous-traitants est régénérée automatiquement à partir du fichier de verrouillage des dépendances (lockfile) à chaque version.
Un acheteur lit ces signaux directement. Il demandera : « montrez-moi le tableau de bord ». Préparez le tableau de bord.
Ce qui importe réellement à l'acheteur
D'après notre expérience sur cinq cycles d'approvisionnement B2B, les acheteurs se soucient de trois choses dans cet ordre :
- Visibilité. « Quand quelque chose change, puis-je le voir? » (changements de sous-traitants, notifications de violation, mises à jour de politique).
- Réversibilité. « Quand je pars, puis-je récupérer mes données et pouvez-vous les supprimer? » (exportation de données, suppression de données, calendrier de conservation).
- Proportionnalité. « La posture de sécurité est-elle proportionnelle aux données que nous vous confions? » (chiffrement, contrôle d'accès, journal d'audit).
Tout élément de la checklist ci-dessus qui ne sert aucun de ces trois points est de la décoration. Supprimez-le.
