RGPD, SOC2 et la checklist B2B SaaS qui déverrouille les achats

Quand un acheteur demande « êtes-vous conformes RGPD ? », il ne pose pas une question oui-ou-non. Il demande si votre entreprise peut produire les dix documents, les quatre registres et un journal d'audit que son acheteur doit accrocher au contrat. La checklist ci-dessous est celle que nous remettons à un prospect B2B quand il veut vérifier.

Les dix documents

Ceci n'est pas un conseil juridique, mais cela relie la checklist d'achat B2B UE typique au travail d'ingénierie et de politique qui supporte chaque item :

1. Un Data Processing Agreement (DPA) signé. Modèle contre-signable sur demande. Reflète RGPD art. 28.
2. Un registre des activités de traitement. ROPA interne qui liste les finalités, catégories de données, destinataires, durées de conservation et base légale.
3. Une liste de sous-traitants. Chaque fournisseur qui touche aux données de l'acheteur, avec noms et un processus de notification de changement.
4. Une analyse d'impact de transfert (TIA). Pour toute donnée qui quitte l'EEE — même un fournisseur SaaS américain avec un sous-traitant sur la côte ouest.
5. Un processus de notification de violation. Délai de 72 heures vers l'autorité de contrôle ; délai sans délai vers les personnes concernées pour les violations à haut risque.
6. Un processus de droits des personnes concernées. Intake DSAR, vérification d'identité, SLA de réponse (30 jours), et le travail d'ingénierie pour traiter une demande de suppression ou d'export.
7. Un calendrier de conservation. Ce que nous conservons, combien de temps, comment c'est supprimé, et quel système possède la suppression.
8. Une politique de cookies et de tracking. Ce qui tourne sur le site marketing, l'app produit, le dashboard admin et pourquoi chaque cookie existe.
9. Un document de vue d'ensemble de sécurité. Chiffrement en transit, chiffrement at rest, gestion de clés, contrôle d'accès, réponse aux incidents.
10. Une posture de disponibilité. Engagements d'uptime, ce qui est exclu (un SLA honnête) et l'histoire de disaster-recovery.

Le travail d'ingénierie qui supporte chaque item

Un acheteur qui lit les dix documents demandera ensuite à l'équipe d'ingénierie de le guider à travers l'implémentation. Les items contre-intuitifs, dans l'ordre de fréquence avec laquelle ils remontent réellement :

Traitement des Data Subject Access Requests (DSAR)

L'acheteur veut voir vos endpoints de suppression et d'export, journalisés en audit, avec vérification d'identité imposée. Le travail d'ingénierie :

• Un DELETE /api/users/{id} qui annule le compte, épure les données personnelles et conserve une entrée d'auditlog sans les données personnelles elles-mêmes.
• Un GET /api/users/{id}/export qui retourne une archive lisible par machine de chaque entité qui référençait l'utilisateur.
• Vérification d'identité sur les deux — timing bcrypt égalisé même quand l'email n'existe pas (pour que le temps de réponse ne fuite pas d'énumération d'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 webhook pour les changements.
• Un codepath qui refuse les dépendances qui envoient des données hors de la liste documentée (un check CI ou une allowlist runtime).

Résidence UE pour inférence et stockage

Beaucoup d'acheteurs B2B n'achètent pas un SaaS dont la base de données primaire est aux US. Le travail d'ingénierie :

• Pinner la région MongoDB sur l'UE (eu-west-1 ou équivalent).
• Pinner chaque fournisseur d'inférence externe sur un endpoint UE, et rendre cela visible dans le DPA.
• Documenter la résidence des données dans la vue d'ensemble de sécurité.

Application des durées de conservation

La plupart des startups peuvent produire une politique de conservation. La question plus difficile est « est-elle appliquée ? » Travail d'ingénierie :

• Un job planifié qui scanne les enregistrements au-delà de leur deadline de conservation et les supprime.
• Un log du job, accessible à l'acheteur sur demande.
• Un test explicite que le job tourne (pas seulement une assertion CI qu'il compile).

Journalisation d'audit

Quasiment chaque questionnaire de sécurité le demande. Travail d'ingénierie :

• Une entité auditlog centrale, append-only, alimentée par un interceptor ou middleware.
• Conservation : plus longtemps que ce que l'acheteur attend (90 jours par défaut, configurable vers le haut). Jamais plus court.

Contrôle d'accès au dashboard 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 personnes dans chaque rôle et le trail d'audit de l'accès.
• Un TTL court sur l'accès production (nous utilisons un TTL de 4 heures émis à la demande avec un commentaire de justification).

Le piège : SOC 2 comme destination vs pratique continue

L'erreur que font la plupart des SaaS B2B early-stage est de traiter SOC 2 comme une ligne d'arrivée. Ce n'en est pas une. Les audits SOC 2 sont point-in-time ; l'acheteur lit votre posture de contrôle continue, pas seulement le rapport d'audit le plus récent. Le travail d'ingénierie qui rend cela continu :

• Le scheduler de conservation tourne en CI comme job de vérification (la query retourne-t-elle des résultats non-stale ?).
• Les écritures auditlog alimentent un dashboard que quelqu'un surveille réellement.
• La liste de sous-traitants est auto-régénérée depuis la dependency-lockfile à chaque release.

Un acheteur lit ces signaux directement. Ils demanderont : « montrez-moi le dashboard ». Ayez le dashboard.

Ce dont l'acheteur se soucie réellement

Dans notre expérience à travers cinq cycles d'achat B2B, l'acheteur s'intéresse à 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 ? » (export 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 ce qui dans la checklist ci-dessus ne sert pas l'un de ces trois est de la décoration. Coupez-le.