Je hebt een privacyverklaringtemplate gedownload, een paar bedrijfsnamen ingevuld en het document online gezet. Dan meldt een klant dat zijn juridische afdeling vragen heeft over de verwerkersrol, subverwerkers en de procedure bij datalekken in hun data. Je staart naar je template en realiseert je: dit klopt niet voor wat jij aanbiedt.

Dat is precies het probleem met standaardtemplates bij een SaaS-product. Bij een gewone website ben je één ding: een verwerkingsverantwoordelijke die bezoekers heeft. Bij een SaaS-product ben je twee dingen tegelijk. Je verwerkt data van je klanten als verwerker, maar ook je eigen gebruikersdata als verwerkingsverantwoordelijke. Die tweedeling heeft grote gevolgen voor wat je moet documenteren, aan wie je het moet uitleggen en welke clausules je absoluut niet mag missen.

De kern van het verschil: twee petten op één hoofd

Bij een gewone website verwerk je persoonsgegevens van je eigen bezoekers. Jij bepaalt het doel en de middelen, jij bent verwerkingsverantwoordelijke, klaar.

Bij een SaaS-product speelt er iets extra’s. Stel: je levert een HR-tool aan een bedrijf met vijftig medewerkers. Die medewerkers voeren hun verlofaanvragen, salarisstroken en functioneringsgesprekken in jouw systeem in. Dat bedrijf (jouw klant) is verwerkingsverantwoordelijke voor die medewerkerdata. Jij bent hun verwerker: jij verwerkt die gegevens in opdracht van de klant, niet voor eigen doeleinden.

Tegelijkertijd heb jij ook rechtstreeks te maken met je klantcontact (de HR-manager die het account beheert), je eigen interne medewerkers en je eigen analyticsdata. Daarvoor ben jij wél verwerkingsverantwoordelijke.

Dat maakt een privacyverklaring voor SaaS een document dat twee verhalen tegelijk moet vertellen, aan twee soorten lezers, over twee sets verantwoordelijkheden. Een standaard websitetemplate vertelt er één.

Stap 1: Breng je verwerkingslagen in kaart

Voordat je ook maar één zin schrijft, moet je drie aparte categorieën definiëren:

  • Eindgebruikers: de mensen die daadwerkelijk in je applicatie werken, vaak medewerkers van je klant.
  • Klantorganisaties: de bedrijven of personen die een abonnement bij je hebben, de contractpartij.
  • Interne medewerkers: je eigen team dat toegang heeft tot systemen, klantdata of supporttickets.

Elke laag heeft andere gegevens, andere grondslagen en andere rechten. Gooi ze niet op één hoop in je verklaring, want dan snapt niemand meer wie nu wat mag vragen.

Stap 2: Definieer de accountgegevens-verwerking

Bij registratie verzamel je minimaal een naam, e-mailadres en wachtwoord. Maar bij SaaS komt daar vaak meer bij: bedrijfsnaam, btw-nummer, het aantal seats, de gekozen module. Leg per veld vast op welke grondslag je dit verwerkt.

De grondslag voor een e-mailadres dat je gebruikt om de factuur naartoe te sturen is uitvoering van de overeenkomst. De grondslag voor een marketingnieuwsbrief na afloop van een trial is toestemming. Dat onderscheid moet leesbaar zijn in je verklaring.

Denk ook na over bewaartermijnen na opzegging. Een klant zegt zijn abonnement op in december. Hoe lang bewaar jij zijn accountgegevens nog? Tien jaar voor de fiscus (facturen), maximaal zeven jaar in je CRM, en projectdata? Dat laatste hangt af van wat je in je verwerkersovereenkomst hebt afgesproken.

Stap 3: Beschrijf gebruiksdata en telemetrie eerlijk

Sessielogs, feature-gebruik, laadtijden, foutrapportages: je verzamelt ze waarschijnlijk allemaal. Prima, maar benoem het doel expliciet. “Wij verbeteren onze software” is te vaag. “Wij analyseren welke functies weinig worden gebruikt om de interface te vereenvoudigen” is concreet.

Als je dit baseert op gerechtvaardigd belang, moet je ook de afweging kunnen onderbouwen. Jouw belang (productontwikkeling) versus het belang van de gebruiker (niet gevolgd worden). Leg die redenering kort uit in je verklaring, ook al voelt dat oncomfortabel. Rechters en toezichthouders waarderen transparantie boven verborgen houden.

Stap 4: Verwerk de betalingsstroom transparant

Gebruik je Stripe, Mollie of een andere betaalprovider? Dan raakt de kaartdata die provider, niet jouw server. Dat is goed, want jij hoeft daarmee minder te beveiligen. Maar je verklaring moet dit correct weergeven.

Schrijf niet “wij slaan je betaalgegevens veilig op” als dat technisch gezien Stripe doet. Schrijf in plaats daarvan: “Betalingen worden verwerkt door Stripe. Wij ontvangen geen volledige kaartgegevens; Stripe stuurt ons een bevestiging en een transactie-ID.” Dan klopt je verklaring met de werkelijkheid, en dat is precies wat de AVG vraagt.

Stap 5: Maak de sub-verwerkers-lijst functioneel

Een lijst met logo’s van AWS, Intercom en Mailchimp ziet er mooi uit maar helpt niemand. Maak de lijst bruikbaar door per sub-verwerker aan te geven:

  • de functie (hosting, klantsupport, transactionele e-mail, analytics)
  • de vestigingslocatie of het land van de server
  • de grondslag voor eventuele doorgifte buiten de EER (adequaatheidsbesluit, standaardcontractbepalingen)

Als jij AWS in Ierland gebruikt voor hosting en Intercom in de VS voor support, dan zijn dat twee aparte doorgifte-situaties met elk hun eigen grondslag. Houd ze gescheiden in je documentatie.

Stap 6: Schrijf het verwerkersgedeelte slim

Zakelijke klanten willen een verwerkersovereenkomst (DPA) met jou afsluiten. Dat is een apart juridisch document, geen onderdeel van je privacyverklaring. Maar de twee moeten wel op elkaar aansluiten.

In je privacyverklaring verwijs je naar de DPA voor de details: “Voor de verwerking van persoonsgegevens die onze zakelijke klanten in ons platform invoeren, sluiten wij een verwerkersovereenkomst. Zie onze DPA-pagina voor de volledige voorwaarden.” Zo hoef je de inhoud van de DPA niet te dupliceren, maar is de verwijzing er wel. Iemand die de privacyverklaring leest, weet dan waar hij naartoe moet voor de verwerkersverhoudingen.

Stap 7: Stel bewaartermijnen per categorie vast

Dit is het onderdeel waar de meeste SaaS-verklaringen vaag blijven. “Wij bewaren gegevens zo lang als nodig” is geen bewaartermijn, dat is een wens. Wees concreet per categorie:

  • Actieve accounts: zolang het abonnement loopt plus een redelijke uitloopperiode van drie maanden voor data-export.
  • Inactieve accounts (trial verlopen, niet verlengd): zes tot twaalf maanden, afhankelijk van je retentiestrategie.
  • Back-ups: maximaal dertig tot negentig dagen, afhankelijk van je back-upbeleid.
  • Audit-logs: twee jaar voor beveiligingsdoeleinden.
  • Fiscale records (facturen): zeven jaar conform de Nederlandse bewaarplicht.

Dit klinkt als veel werk, maar als je dit eenmaal hebt vastgesteld, heb je ook een intern bewaarbeleid dat je technisch team kan implementeren.

Stap 8: Richt de rechten-procedure in voor de dubbele route

Hier wordt het ingewikkeld. Een eindgebruiker (medewerker van je klant) dient een inzageverzoek in bij jou. Maar jij bent niet zijn verwerkingsverantwoordelijke voor de data die zijn werkgever in jouw systeem heeft gezet. Zijn werkgever is dat.

Je verklaring moet deze route duidelijk beschrijven. Iets als: “Als jij als eindgebruiker inzage wil in gegevens die jouw werkgever of organisatie via ons platform verwerkt, dien je dit verzoek in bij die organisatie. Zij zijn verwerkingsverantwoordelijke voor die gegevens. Voor gegevens die wij zelf verzamelen (accountprofiel, logingeschiedenis) kun je direct contact met ons opnemen.”

Die tweedeling voorkomt verwarring en beschermt jou juridisch.

Checklist: tien clausules die een standaard websitetemplate mist

Controleer of je privacyverklaring voor SaaS al deze onderdelen bevat:

  • Expliciete onderscheid tussen verwerkingen als verwerkingsverantwoordelijke en als verwerker
  • Verwijzing naar de verwerkersovereenkomst voor zakelijke klanten
  • Aparte beschrijving per gebruikerslaag (eindgebruikers, klantorganisaties, intern)
  • Grondslag per gegevenssoort bij registratie en facturatie
  • Doel en grondslag van telemetrie en sessiedata
  • Beschrijving van welke betaaldata bij de provider blijft en wat jij ontvangt
  • Sub-verwerkers-lijst met functie, locatie en doorgifte-grondslag
  • Bewaartermijnen per specifieke categorie (geen vage formuleringen)
  • Route voor inzageverzoeken van eindgebruikers die via een klantorganisatie binnenkomen
  • Procedure voor klanten die hun sub-verwerkers-lijst willen opvragen of wijzigingen daarin willen ontvangen

Een privacyverklaring voor SaaS is een eigen document dat de dubbele positie van jouw product beschrijft: verwerker voor je klanten, verwerkingsverantwoordelijke voor je eigen gebruikersdata. Per verwerkingslaag vraagt dat om concrete keuzes, eerlijke beschrijvingen van telemetrie en betalingsstromen, en een heldere procedure voor inzageverzoeken die via klantorganisaties lopen.

Als je de stappen in dit artikel doorloopt, heb je niet alleen een betere privacyverklaring, maar ook intern meer duidelijkheid over wat je verwerkt en waarom. Gebruik de generator op deze site als startpunt en vul de SaaS-specifieke onderdelen in op basis van wat je hier hebt gelezen.