Wanneer een onderneming persoonsgegevens laat verwerken door een externe partij, is een DPA (Data Processing Agreement) geen vrijblijvende formaliteit. Onder de GDPR moet de verwerking door een verwerker worden geregeld in een bindende overeenkomst of andere rechtshandeling wanneer die partij persoonsgegevens verwerkt in opdracht van de verwerkingsverantwoordelijke.
Denk bijvoorbeeld aan een externe payrollprovider, cloudleverancier, CRM-platform, IT-dienstverlener of marketingpartner die persoonsgegevens verwerkt volgens de instructies van jouw onderneming.
De eerste vraag is dus niet: “Werken we met persoonsgegevens?”, maar wel: “Welke rol heeft elke partij?”
Verantwoordelijkheden vaststellen
Niet elke externe leverancier is automatisch een verwerker. Een verwerkingsverantwoordelijke bepaalt waarom en op welke manier persoonsgegevens worden verwerkt. Een verwerker verwerkt die gegevens daarentegen in opdracht van de verantwoordelijke.
Dat onderscheid is cruciaal, want alleen wanneer er werkelijk sprake is van een verwerkersrelatie is artikel 28 GDPR van toepassing en moet een DPA worden gesloten. Een leverancier die zelf de doeleinden en essentiële middelen van de verwerking bepaalt, kan zelf verwerkingsverantwoordelijke zijn.
Een contract “DPA” noemen verandert die juridische kwalificatie niet. Sterker nog: wanneer een verwerker zelf de doeleinden en middelen van een verwerking begint te bepalen, beschouwt de GDPR hem voor die verwerking als verwerkingsverantwoordelijke.
Een DPA moet veel concreter zijn dan “de GDPR naleven”
Een correcte DPA vermeldt niet alleen dat partijen de privacywetgeving zullen respecteren. Artikel 28 GDPR vereist onder meer dat wordt vastgelegd:
- wat het onderwerp en de duur van de verwerking zijn;
- wat de aard en het doel van de verwerking zijn;
- welke soorten persoonsgegevens worden verwerkt;
- over welke categorieën van personen het gaat;
- welke rechten en verplichtingen de verwerkingsverantwoordelijke heeft.
Daarnaast moet de verwerker zich onder meer verbinden om alleen op gedocumenteerde instructies te verwerken, vertrouwelijkheid te waarborgen, passende beveiligingsmaatregelen te nemen en de verantwoordelijke te ondersteunen bij bepaalde GDPR-verplichtingen.
Een DPA van één pagina met alleen de boodschap “de verwerker respecteert de GDPR” is dus juridisch bijzonder mager.
Datalekken: afspraken maken vóór het misloopt
Een van de meest kritieke onderdelen in een DPA is het incidentenprotocol. Onder de GDPR moet een verwerker de verantwoordelijke zonder onredelijke vertraging informeren zodra een datalek wordt ontdekt. De verantwoordelijke heeft immers slechts 72 uur om de toezichthouder in te lichten en moet beoordelen of ook de getroffen personen moeten worden gewaarschuwd
“Zonder onredelijke vertraging” is in de praktijk te vaag. Een goede DPA maakt dit operationeel: binnen hoeveel uur meldt de leverancier het incident (bijvoorbeeld binnen 24 of 48 uur)? Welke technische details worden direct aangeleverd? Wie onderzoekt de oorzaak en wie draagt de kosten voor herstelmaatregelen en externe communicatie? Door dit vooraf contractueel vast te leggen, voorkom je kostbaar tijdverlies tijdens een crisis.
Je kunt GDPR-aansprakelijkheid niet volledig wegcontracteren
Hier zit een belangrijk verschil tussen commerciële afspraken en wettelijke aansprakelijkheid. Partijen kunnen contractueel afspraken maken over aansprakelijkheid, vrijwaringen en de onderlinge verdeling van kosten. Maar zo’n clausule kan de wettelijke rechten van betrokken personen onder de GDPR niet zomaar uitschakelen.
De GDPR kent eigen aansprakelijkheidsregels voor schade die het gevolg is van een inbreuk. De concrete aansprakelijkheid hangt af van onder meer de rol van elke partij, de aard van de inbreuk en de omstandigheden van het dossier. Dat betekent dat een onderneming zich niet volledig kan beschermen door simpelweg in een DPA te schrijven dat “alle verantwoordelijkheid bij de verwerker ligt”.
Een goede DPA verdeelt dus contractuele risico’s, maar verandert niet automatisch de wettelijke verantwoordelijkheden tegenover betrokkenen of toezichthouders.
Onderverwerkers: wie zit er eigenlijk achter je leverancier?
Een vaak onderschat punt is het gebruik van subverwerkers. Een verwerker mag niet zomaar een andere partij inschakelen voor de verwerking. Daarvoor is voorafgaande specifieke of algemene schriftelijke toestemming van de verwerkingsverantwoordelijke vereist. Bij algemene toestemming moet de verantwoordelijke bovendien worden geïnformeerd over geplande wijzigingen, zodat hij daartegen bezwaar kan maken.
Dat is vooral relevant bij cloud- en softwareleveranciers. Je contracteert bijvoorbeeld met één SaaS-provider, maar achter die dienst kunnen meerdere hosting-, support- of analysetools zitten. Bovendien blijft de eerste verwerker tegenover de verantwoordelijke volledig aansprakelijk voor de uitvoering van de gegevensbeschermingsverplichtingen van zijn subverwerker wanneer die daarin tekortschiet.
Waar bevinden je gegevens zich?
Ook de geografische locatie van gegevensverwerking verdient aandacht.
Wanneer persoonsgegevens buiten de Europese Economische Ruimte worden doorgegeven, gelden bijkomende regels voor internationale doorgiften. Een DPA alleen maakt zo’n doorgifte dus niet automatisch rechtmatig. In de praktijk moet daarom worden nagegaan welke partijen toegang hebben tot gegevens, waar systemen worden gehost en of aanvullende mechanismen of waarborgen nodig zijn. Dat maakt de lijst van subverwerkers en gebruikte IT-infrastructuur juridisch veel relevanter dan ze op het eerste gezicht lijkt.
Wat gebeurt er na het einde van de samenwerking?
Een DPA hoort ook te regelen wat er met persoonsgegevens gebeurt wanneer de dienstverlening stopt.
De GDPR bepaalt dat de verwerker, naar keuze van de verwerkingsverantwoordelijke, persoonsgegevens na afloop van de dienstverlening moet wissen of terugbezorgen, en bestaande kopieën moet verwijderen, tenzij de wet verdere bewaring verplicht.
Dat is in de praktijk een belangrijk exitpunt. Kan je jouw gegevens technisch terugkrijgen? In welk formaat? Hoe snel? Worden back-ups ook gewist? Wat gebeurt er met data bij een conflict of faillissement van de leverancier? Een sterke DPA kijkt dus niet alleen naar de samenwerking van vandaag, maar ook naar het einde ervan.
Een DPA is geen vervanging voor een privacybeleid of NDA
Een DPA, een privacybeleid en een NDA hebben elk een andere functie.
Een DPA regelt de verhouding tussen een verwerkingsverantwoordelijke en een verwerker. Een privacybeleid of privacyverklaring gaat onder meer over hoe persoonsgegevens worden verwerkt en welke informatie aan betrokkenen moet worden gegeven. Een NDA beschermt dan weer vertrouwelijke informatie in bredere zin. Die documenten kunnen elkaar aanvullen, maar zijn juridisch niet uitwisselbaar.
Ook een samenwerkingsovereenkomst of managementovereenkomst kan privacyclausules bevatten, maar wanneer artikel 28 GDPR van toepassing is, moeten de verplichte elementen van de verwerkersovereenkomst aanwezig zijn. De Europese Commissie heeft daarvoor zelfs standaardcontractbepalingen vastgesteld die partijen geheel of gedeeltelijk kunnen gebruiken.
Een standaardtemplate is zelden het hele verhaal
Een generieke DPA kan een goed vertrekpunt zijn, maar de echte waarde zit in de afstemming op de concrete verwerking. Een payrollprovider verwerkt andere gegevens en draagt andere risico’s dan een cloudhoster of marketingbureau. Ook de beveiligingsmaatregelen, bewaartermijnen, subverwerkers, internationale doorgiften en ondersteuning bij verzoeken van betrokkenen kunnen sterk verschillen.
Daarom is het nuttig om niet alleen te vragen of er “een DPA” bestaat, maar ook of die overeenkomst overeenstemt met wat er in de praktijk werkelijk gebeurt. Een professioneel opgestelde DPA zorgt niet alleen voor compliance, maar maakt ook duidelijk wie welke verantwoordelijkheid draagt wanneer er persoonsgegevens worden verwerkt, een incident plaatsvindt of de samenwerking eindigt. En net daar zit de juridische meerwaarde: niet in zoveel mogelijk clausules, maar in afspraken die aansluiten bij de werkelijke datastromen en risico’s van de onderneming.
