Als je een product bouwt dat transactionele e-mails stuurt naar gebruikers in de Europese Unie, geldt de AVG voor jou. Niet alleen voor je marketingmails. Elke wachtwoordreset, orderbevestiging en accountmelding die je verstuurt, bevat persoonsgegevens en valt onder de regelgeving.
De meeste ontwikkelaars weten dat de AVG bestaat. Veel minder weten wat het in de praktijk betekent voor transactionele e-mail, en waar de echte risico's zitten. Deze gids behandelt de praktische keuzes die je moet maken: welke gegevens je mag verwerken, wat je verplichtingen zijn aan je gebruikers, hoe je een e-mailprovider kiest die geen compliance-problemen voor je creëert, en wat je moet doen als er iets misgaat.
Waarom transactionele e-mail een AVG-kwestie is
De AVG reguleert de verwerking van persoonsgegevens van mensen in de EU. Een e-mailadres is een persoonsgegeven. Net als een naam, een apparaat-identifier, een IP-adres, of iets anders dat te herleiden is naar een individu.
Wanneer je een transactionele e-mail verstuurt, verwerk je persoonsgegevens op meerdere manieren tegelijk: je slaat het adres van de ontvanger op, stuurt het door naar een e-mailprovider, logt delivery-events, en bewaart mogelijk open- en kliktracking-data. Elk van deze activiteiten is een verwerkingsactiviteit die een rechtsgrondslag nodig heeft onder de AVG.
Het goede nieuws: transactionele e-mail heeft een duidelijke rechtsgrondslag: gerechtvaardigd belang of uitvoering van een overeenkomst. Als een gebruiker zich heeft aangemeld voor je product en je stuurt een wachtwoordreset die ze hebben aangevraagd, heb je geen aparte toestemming nodig. Je voert een contract uit. Hetzelfde geldt voor orderbevestigingen, beveiligingsmeldingen en accountmeldingen.
Wat die duidelijke rechtsgrondslag niet heeft: marketingmails, re-engagementcampagnes, of alles wat de gebruiker niet direct heeft getriggerd. Daarvoor is expliciete toestemming nodig en horen ze thuis in een apart systeem.
Data minimalisatie: verwerk alleen wat nodig is
Het principe van data minimalisatie in de AVG vereist dat je alleen persoonsgegevens verzamelt en verwerkt die noodzakelijk zijn voor het aangegeven doel. Voor transactionele e-mail betekent dat: stel elk veld ter discussie dat je naar je e-mailprovider stuurt.
Moet je de volledige naam, het telefoonnummer of het bedrijf van de gebruiker meesturen in de e-mailpayload? Als het enige doel het versturen van een bezorgbevestiging is, waarschijnlijk niet. Stuur het minimum: ontvangstadres, de inhoud van de e-mail, en de metadata die noodzakelijk is voor bezorging en troubleshooting.
Dit geldt ook voor logging. Veel e-mailproviders loggen delivery-events standaard met uitgebreide metadata. Bekijk wat je provider bewaart en hoe lang. Jij bent de verwerkingsverantwoordelijke: jij bent verantwoordelijk voor die gegevens, ook als een derde partij ze namens jou verwerkt.
AhaSend geeft je directe controle over retentie via speciale headers die je per bericht meegeeft. Met ahasend-metadata-retention stel je in hoe lang metadata en delivery-logs bewaard blijven (1-30 dagen). Met ahasend-data-retention beheer je de retentie van de berichtinhoud zelf, en je kunt dit op 0 zetten voor directe verwijdering na verwerking. Zo kun je per e-mailtype een andere retentietermijn instellen: een wachtwoordreset hoeft niet even lang bewaard te blijven als een factuur. Meer details vind je in de documentatie voor retention headers.
Jij bent de verwerkingsverantwoordelijke. Je e-mailprovider is de verwerker.
Dit onderscheid is belangrijk. Onder de AVG bepaalt de verwerkingsverantwoordelijke het doel en de middelen van de verwerking. De verwerker verwerkt gegevens namens de verwerkingsverantwoordelijke. Als de ontwikkelaar of het bedrijf dat transactionele e-mails verstuurt, ben jij de verwerkingsverantwoordelijke. Je e-mailprovider is de verwerker.
Dit betekent:
- Jij bent verantwoordelijk voor de rechtmatigheid van de verwerking.
- Je e-mailprovider mag gegevens alleen verwerken volgens jouw instructies.
- Je moet een verwerkersovereenkomst afsluiten met je e-mailprovider.
Een verwerkersovereenkomst is niet optioneel. Het is een wettelijke vereiste onder artikel 28 van de AVG. Elke AVG-conforme e-mailprovider biedt een verwerkersovereenkomst aan. Als die van jou dat niet doet, is dat een alarmsignaal.
De verwerkersovereenkomst van AhaSend is beschikbaar op ahasend.com/dpa. Die voldoet aan de standaardvereisten: doelbinding, geheimhoudingsverplichtingen, openheid over sub-verwerkers, ondersteuning bij rechten van betrokkenen en procedures voor meldplicht datalekken.
Waar je gegevens staan, maakt verschil
De AVG beperkt de overdracht van persoonsgegevens buiten de Europese Economische Ruimte (EER), tenzij er adequate bescherming is. In de praktijk betekent dit: als je e-mailprovider data verwerkt via servers in de Verenigde Staten of andere landen buiten de EER, moet je controleren of het overdrachtsmechanisme juridisch geldig is.
Het Safe Harbor-kader bestaat niet meer. Privacy Shield bestaat niet meer. Overdrachten naar de VS vallen momenteel onder het EU-VS Data Privacy Framework, dat juridische aanvechting heeft gekregen en opnieuw ongeldig verklaard zou kunnen worden. Als je e-mailinfrastructuur Amerikaans is, draag je dit compliance-risico mee.
AhaSend is gevestigd in Amsterdam (AhaSend B.V., KvK 99533111) en verwerkt e-mail standaard op Europese infrastructuur. We bieden wel een US egress node voor klanten die dat nodig hebben voor performance of deliverability, maar data die via dat knooppunt wordt verzonden, is uitsluitend in transit en wordt nooit opgeslagen op Amerikaanse infrastructuur. Je gegevens blijven in Europa.
Dit is niet alleen belangrijk voor juridische compliance, maar ook voor je klanten. Zoals we bespraken in AhaSend vs SendGrid vs Resend vs Mailgun, krijgen Europese bedrijven steeds vaker te maken met vragen over welke infrastructuurproviders ze gebruiken, en "onze e-mailprovider staat in Californië" is niet het antwoord dat inkoopteams willen horen.
Suppressielijsten en het recht op vergetelheid
De AVG geeft gebruikers het recht op verwijdering (artikel 17), ook wel het "recht op vergetelheid" genoemd. Voor transactionele e-mail creëert dit een praktische spanning: als een gebruiker vraagt om verwijdering van zijn gegevens, moet je ook stoppen met het sturen van e-mails. Maar om te stoppen, moet je onthouden dat je hem niet moet e-mailen. Wat betekent dat je toch een record van zijn adres moet bewaren.
De standaardoplossing is een suppressielijst: een minimale registratie dat een adres geen e-mail mag ontvangen, zonder andere persoonsgegevens van die gebruiker op te slaan. Dit verschilt van een volledig accountrecord en wordt als compliant beschouwd omdat het het specifieke doel dient: het verwijderingsverzoek honoreren.
AhaSend ondersteunt suppressielijstbeheer met volledige API-toegang. Je kunt suppressies importeren, opvragen en synchroniseren met je eigen systemen. Wanneer je een verwijderingsverzoek ontvangt, voeg je het adres toe aan je suppressielijst: dat is de juiste aanpak, niet het verwijderen van het record bij je e-mailprovider (wat er juist toe zou leiden dat het adres opnieuw e-mails gaat ontvangen).
Je vindt de volledige uitleg in onze gids voor het importeren van een suppressielijst.
Meldplicht datalekken: de 72-uursnorm
Onder AVG artikel 33 moet je bij een datalek je toezichthoudende autoriteit informeren binnen 72 uur nadat je van het lek op de hoogte bent. Een datalek in de context van e-mail kan betekenen: ongeautoriseerde toegang tot je verzendlogs, een verkeerd geconfigureerde webhook die delivery-data blootstelt, of een incident aan de kant van je provider waardoor e-mailadressen worden gelekt.
De 72-uurstermijn begint wanneer je op de hoogte bent, niet wanneer het lek heeft plaatsgevonden. Dit maakt planning voor incidentrespons belangrijk: je moet weten wie besluit tot melding over te gaan, wie de melding opstelt, en welke toezichthoudende autoriteit relevant is voor jouw gebruikers.
Voor in Nederland gevestigde bedrijven is dat de Autoriteit Persoonsgegevens (AP). Hun meldportaal voor datalekken vind je op autoriteitpersoonsgegevens.nl/themas/beveiliging/meldplicht-datalekken.
Artikel 34 voegt een verdere verplichting toe: als het lek waarschijnlijk een hoog risico voor betrokkenen oplevert, bijvoorbeeld als de e-mailinhoud gevoelige informatie bevatte - moet je de getroffen gebruikers mogelijk ook direct informeren.
Een AVG-conforme e-mailprovider kiezen
Niet alle e-mailproviders zijn gelijk vanuit compliance-oogpunt. Bij het evalueren van providers zijn dit de vragen die je moet stellen:
Waar worden gegevens verwerkt en opgeslagen? Europese infrastructuur elimineert overdrachtsrisico volledig. Een provider die je gegevens in de VS opslaat, creëert doorlopende blootstelling, ongeacht wat hun privacybeleid zegt.
Bieden ze een verwerkersovereenkomst? Als dat niet het geval is, kun je ze wettelijk gezien niet gebruiken voor de verwerking van EU-persoonsgegevens.
Welke gegevens bewaren ze, en hoe lang? Sommige providers bewaren e-mailinhoud en metadata standaard onbeperkt. Dat zijn jouw gegevens, en jouw aansprakelijkheid.
Zijn ze transparant over sub-verwerkers? Je e-mailprovider maakt waarschijnlijk gebruik van externe infrastructuur. Onder de AVG moet je weten wie de materiële sub-verwerkers zijn, omdat hun gegevensverwerking jouw verantwoordelijkheid is.
Ondersteunen ze suppressielijstbeheer? Verwijderingsverzoeken correct afhandelen vereist dit.
AhaSend is gebouwd voor ontwikkelaars die op al het bovenstaande "ja" moeten kunnen antwoorden. Europese infrastructuur, een correcte verwerkersovereenkomst, instelbare dataretentie, transparantie over sub-verwerkers en een volledige suppressielijst-API. We hebben ook een aangestelde Functionaris Gegevensbescherming (FG). Een benoemde FG betekent dat er een persoon is die aanspreekbaar is op gegevensbeschermingsbeslissingen: geen beleidsdocument, maar een naam.
Zoals we bespraken in de vergelijking van AhaSend vs SendGrid vs Resend vs Mailgun, hebben de grote Amerikaanse providers andere standaardaannames over gegevensverwerking, aannames gebouwd voor de Amerikaanse markt, niet voor AVG-compliance.
Een voetnoot over tracking pixels en kliktracking
Open-tracking (de onzichtbare 1x1 pixel) en kliktracking (links herschrijven via een trackingdomein) gaan allebei gepaard met de verwerking van persoonsgegevens. Een open-event is gekoppeld aan een apparaat en IP-adres. Een klikevent legt vast wat de gebruiker klikte en wanneer.
Voor transactionele e-mail is het een genuanceerde vraag of tracking toestemming vereist. De richtsnoeren van de Artikel 29-werkgroep suggereren dat tracking die strikt noodzakelijk is voor bezorging en technische prestaties mogelijk geen toestemming vereist, terwijl tracking voor profilering of analysedoeleinden dat wel doet.
In de praktijk: als je opens bijhoudt om deliverability te begrijpen, valt dat waarschijnlijk onder gerechtvaardigd belang. Als je opens bijhoudt om gedragsgestuurde marketingworkflows te triggeren, is dat een ander verhaal en is toestemming waarschijnlijk vereist.
De veilige aanpak: wees expliciet naar gebruikers over wat je bijhoudt, geef ze een manier om zich af te melden, en gebruik trackinggegevens alleen voor het doel dat je hebt aangegeven.
Praktische checklist
Voordat je live gaat met transactionele e-mail naar EU-gebruikers, check je dit:
- Rechtsgrondslag gedocumenteerd voor elk type transactionele e-mail dat je verstuurt
- Verwerkersovereenkomst getekend met je e-mailprovider
- Data minimalisatie gecontroleerd: alleen noodzakelijke velden naar provider gestuurd
- Retentiebeleid ingesteld op je provideraccount
- Suppressielijst-workflow ingericht voor het afhandelen van verwijderingsverzoeken
- Incidentresponsprocedure gedocumenteerd met de 72-uursmeldplicht in het achterhoofd
- Trackingpraktijken getoetst aan wat je aan gebruikers hebt gecommuniceerd
- Locatie van e-mailinfrastructuur bevestigd als EER (of geldig overdrachtsmechanisme gedocumenteerd)
AVG-compliance is geen eenmalig vinkje. Het is een doorlopende discipline. Maar voor transactionele e-mail specifiek zijn de regels relatief helder, en het van het begin af aan goed inrichten is veel minder pijnlijk dan compliance achteraf proberen in te bouwen na een gebruikersklacht of een handhavingsonderzoek.
Als je benieuwd bent wat een mislukte of vertraagde transactionele e-mail kost - los van het compliance-aspect - is dat een apart onderwerp waard. Wat kost een mislukte e-mail je eigenlijk? behandelt de zakelijke impact in detail.
AhaSend is een transactionele e-mailprovider gevestigd in Amsterdam. Voor vragen over onze gegevensverwerkingspraktijken of voor het opvragen van onze verwerkersovereenkomst, mail naar [email protected].