GDPR, SOC2 en de B2B-SaaS-checklist die inkoop ontgrendelt

Wanneer een koper vraagt "zijn jullie GDPR-compliant?", stellen ze geen ja-of-nee-vraag. Ze vragen of je bedrijf de tien documenten, vier registers en één auditlog kan produceren die hun inkoopfunctionaris aan het contract moet hangen. De checklist hieronder is degene die we aan een B2B-prospect overhandigen wanneer ze willen verifiëren.

De tien documenten

Dit is geen juridisch advies, maar het koppelt de typische EU B2B-inkoopchecklist aan het engineering- en beleidswerk dat elk item ondersteunt:

1. Een ondertekende Data Processing Agreement (DPA). Tegen-tekenbaar sjabloon op verzoek. Weerspiegelt GDPR art. 28.
2. Een verwerkingsactiviteitenregister. Interne ROPA die doelen, datacategorieën, ontvangers, bewaartermijn en rechtsgrond opsomt.
3. Een sub-processor-lijst. Elke leverancier die koperdata aanraakt, met namen en een change-notification-proces.
4. Een transfer impact assessment (TIA). Voor elke data die de EER verlaat — zelfs een Amerikaanse SaaS-leverancier met een sub-processor aan de westkust.
5. Een breach notification-proces. 72-uur-deadline naar de toezichthoudende autoriteit; zonder-uitstel-deadline naar betrokkenen bij hoog-risico-inbreuken.
6. Een data subject rights-proces. DSAR-intake, identiteitsverificatie, respons-SLA (30 dagen), en het engineering-werk om een verzoek tot verwijdering of export te verwerken.
7. Een bewaarschema. Wat we bewaren, hoe lang, hoe het wordt verwijderd, en welk systeem de verwijdering in eigendom heeft.
8. Een cookie- en trackingbeleid. Wat draait op de marketingsite, de product-app, het admin-dashboard en waarom elke cookie bestaat.
9. Een security-overzichtdocument. Encryptie in transit, encryptie at rest, sleutelbeheer, toegangscontrole, incident-respons.
10. Een beschikbaarheidspostuur. Uptime-verbintenissen, wat is uitgesloten (een eerlijke SLA) en het disaster-recovery-verhaal.

Het engineering-werk dat elk item ondersteunt

Een koper die de tien documenten leest, zal het engineering-team daarna vragen om hen door de implementatie heen te loodsen. De niet-voor-de-hand-liggende items, in volgorde van hoe vaak ze werkelijk naar boven komen:

Data Subject Access Request (DSAR)-verwerking

De koper wil je verwijder- en export-eindpunten zien, audit-gelogd, met identiteitsverificatie afgedwongen. Het engineering-werk:

• Een DELETE /api/users/{id} die het account annuleert, persoonsgegevens zuivert en een auditlog-entry overhoudt zonder de persoonsgegevens zelf.
• Een GET /api/users/{id}/export die een machineleesbaar archief teruggeeft van elke entiteit die naar de gebruiker verwees.
• Identiteitsverificatie op beide — bcrypt-timing geëqualiseerd zelfs wanneer het e-mailadres niet bestaat (zodat de reactietijd geen user enumeration lekt).

Sub-processor-beheer

De koper wil een lijst en een change-notification-proces. Engineering-werk:

• Een versioned sub-processor-lijst in de documentatie, met een RSS-feed of webhook voor wijzigingen.
• Een codepad dat afhankelijkheden weigert die data buiten de gedocumenteerde lijst sturen (een CI-check of een runtime-allowlist).

EU-residentie voor inferentie en opslag

Veel B2B-kopers kopen geen SaaS waarvan de primaire database in de VS staat. Het engineering-werk:

• Pin de MongoDB-regio op de EU (eu-west-1 of vergelijkbaar).
• Pin elke externe inferentie-aanbieder op een EU-eindpunt, en maak dit zichtbaar in de DPA.
• Documenteer data-residentie in het security-overzicht.

Bewaartermijn-handhaving

De meeste startups kunnen een bewaarbeleid produceren. De lastigere vraag is "wordt het gehandhaafd?" Engineering-werk:

• Een geplande job die scant naar records voorbij hun bewaardeadline en ze verwijdert.
• Een log van de job, op verzoek toegankelijk voor de koper.
• Een expliciete test dat de job draait (niet alleen een CI-assertion dat het compileert).

Audit-logging

Bijna elke security-vragenlijst vraagt ernaar. Engineering-werk:

• Een centrale auditlog-entiteit, append-only, gevoed door een interceptor of middleware.
• Bewaring: langer dan de koper verwacht (90 dagen standaard, configureerbaar omhoog). Nooit korter.

Toegangscontrole op het admin-dashboard

Kopers willen weten wie binnen je bedrijf hun data kan zien. Engineering-werk:

• Een gedocumenteerd toegangsbeleid dat de rollen, de mensen in elke rol en het audittrail van toegang benoemt.
• Een korte TTL op productietoegang (wij gebruiken 4-uurs-TTL die on-demand wordt uitgegeven met een rechtvaardigingscommentaar).

De val: SOC 2 als bestemming versus continue praktijk

De fout die de meeste early-stage B2B-SaaS-bedrijven maken is SOC 2 als finishline te behandelen. Het is dat niet. SOC 2-audits zijn point-in-time; de koper leest je continue-control-postuur, niet alleen het meest recente auditrapport. Engineering-werk dat dit continu maakt:

• De bewaartermijn-scheduler draait in CI als een verificatiejob (geeft de query niet-stale resultaten terug?).
• De auditlog-schrijven voeden een dashboard dat iemand daadwerkelijk in de gaten houdt.
• De sub-processor-lijst wordt automatisch opnieuw gegenereerd uit de dependency-lockfile bij elke release.

Een koper leest deze signalen direct. Ze zullen vragen: "laat me het dashboard zien." Heb het dashboard.

Waar de koper werkelijk om geeft

In onze ervaring over vijf B2B-inkoopcycli geeft de koper om drie dingen in deze volgorde:

• Zichtbaarheid. "Wanneer er iets verandert, kan ik dat dan zien?" (sub-processor-wijzigingen, breach-meldingen, beleidsupdates).
• Omkeerbaarheid. "Wanneer ik wegga, kan ik dan mijn data krijgen en kun je het verwijderen?" (data-export, data-verwijdering, bewaarschema).
• Proportionaliteit. "Is het security-postuur proportioneel met de data die we je toevertrouwen?" (encryptie, toegangscontrole, auditlog).

Alles in de bovenstaande checklist dat niet een van deze drie dient, is decoratie. Snijd het weg.