Nieuws & Blogs – Standaard verwerkersovereenkomsten #5: Privacyconvenant 3.0

De verwerkersovereenkomst is voor organisaties vaak meer een noodzakelijke administratieve drempel, dan een moment om eens goed na te denken over een veilige omgang met persoonsgegevens. Zeker wanneer de verwerking van persoonsgegevens grote overlap kent voor elke klant of leverancier, is het noodzakelijk om een goed model te hanteren. Veel brancheorganisaties bieden daarom een template aan, die hun leden kunnen gebruiken. In deze editie van de serie “Standaard verwerkersovereenkomsten”, de verwerkersovereenkomst die hoort bij het Privacyconvenant 3.0. Dit is het model wat gangbaar is in het basis- en voortgezet onderwijs en in het MBO.

Voor wie is deze standaard?

Het Privacyconvenant is ontwikkeld door de PO-, VO- en MBO-raad, samen met vertegenwoordigers van leveranciers. Het convenant bevat afspraken tussen de onderwijssector en leveranciers van digitale onderwijsmiddelen, bedoeld om te zorgen dat scholen de regie houden op het gebied van privacy. Als onderdeel van het convenant is dit model voor de verwerkersovereenkomst opgesteld. Door het convenant te ondertekenen, verklaart een leverancier onder meer dat men dit model zal hanteren. Scholen in het primair en voortgezet onderwijs en het MBO kunnen er zo op rekenen dat leveranciers zich aan de verplichtingen hebben verbonden die in de sector als basis gelden. Het gebruik van deze modelovereenkomsten wordt scholen ten zeerste aangeraden, maar is niet verplicht.

Er zijn twee eerdere versies van dit model in gebruik geweest, vandaar de aanduiding in de naam Privacyconvenant 3.0. De huidige versie is vlak voor de inwerkingtreding van de Algemene verordening gegevensbescherming (AVG) opgesteld, in maart 2018. Wanneer een oudere versie van het model is afgesloten, blijft dit in principe gewoon van kracht zolang de partijen niet besluiten een nieuwe versie te ondertekenen.

Wat kenmerkt deze verwerkersovereenkomst?

Omdat het model bedoeld is voor leveranciers van digitale onderwijsmiddelen, wordt in het model zeer specifiek ingegaan op begrippen die bij deze leveranciers passen. Zo komen in de definities de begrippen Keten iD, leermiddelen en toetsen aan bod. Ook wordt verwezen naar het Privacyconvenant, om de verbinding te leggen met meer algemene afspraken waaraan de leverancier zich dient te houden. Daarnaast wordt verwezen naar een ‘Standaardattributenset’: een gestandaardiseerde lijst van persoonsgegevens. Veel noodzakelijke keuzes bij het overeenkomen van een verwerkersovereenkomst, zijn dus al gemaakt. Ook wordt het model eenvoudiger te gebruiken, doordat algemene termen die vaak in een verwerkersovereenkomst staan, zijn vervangen door herkenbare bewoordingen.

De hoofdtekst van de verwerkersovereenkomst dient bij voorkeur integraal te worden gehanteerd. Zo wordt er bijna niet gewerkt met artikelen waar de opstellers nog een keuze dienen te maken voor één van de voorgestelde opties. Er zijn twee uitzonderingen hierop: er is een standaard bepaling over het uitwisselen van het onderwijskundig rapport, en een bepaling die alleen voor distributeurs van toepassing is. In beide gevallen betreft het bepalingen die kunnen worden verwijderd, indien de beschreven situatie niet van toepassing is.

Geen bijzaak: de bijlagen

Zoals we bij alle model verwerkersovereenkomsten in deze blogserie hebben gezien, wordt met bijlagen gewerkt om de bijzonderheden van de verwerking en de beveiliging te beschrijven. Deze bijlagen, de Privacybijsluiter en Beveiligingsbijlage genoemd, worden in veel gevallen standaard ingevuld door de verwerker.

Als aanbieder van de dienst weet de leverancier immers vaak het beste welke persoonsgegevens nodig zijn om de dienst aan te bieden. Desondanks dient een school natuurlijk altijd goed te controleren of de Privacybijsluiter correct is ingevuld. Een risico is bijvoorbeeld dat bepaalde typen persoonsgegevens niet worden benoemd, die wel worden gedeeld met de leverancier. Strikt genomen krijgt de leverancier dan onbevoegd toegang tot die persoonsgegevens.

Ook wat betreft de beveiligingsmaatregelen heeft de verwerker in zulke gevallen vaak de expertise om een overzicht met ‘passende’ maatregelen samen te stellen. In de beveiligingsbijlage wordt de leverancier opgedragen om een ‘verklaring’ te plaatsen, waaruit blijkt dat wordt voldaan aan de eisen die de AVG stelt aan beveiligingsmaatregelen. Ook is er de mogelijkheid om eventuele certificeringen van de dienst te beschrijven. Tot slot bieden de bijlagen voorschriften voor de omgang met datalekken, en dient te worden ingevuld met wie de leverancier contact opneemt wanneer een (mogelijk) datalek zich voordoet.

Overige bijzonderheden en tips

Eventuele afwijkingen van de standaardtekst van het model dienen in een nieuwe bijlage te worden opgenomen. In de praktijk zijn afwijkingen echter ook mogelijk door deze door te voeren in de hoofdtekst. Dit kan tot vervelende situaties leiden, doordat een verwerkersovereenkomst lijkt te voldoen aan het Privacyconvenant-model, maar er toch afwijkende bepalingen in de hoofdtekst staan. Partijen dienen dus, helaas, altijd scherp naar de volledige tekst van de verwerkersovereenkomst te kijken, alvorens deze te ondertekenen.

In de aansprakelijkheidsbepaling, vaak een punt van discussie, is ten slotte een verwijzing opgenomen naar een eventuele overeenkomst of regeling waarin de aansprakelijkheid van de leverancier beperkt is. Deze beperking kan voor schade die met de verwerkersovereenkomst samenhangt blijven bestaan, behalve voor schade door een verhaalsactie op grond van artikel 82 AVG, of een schadevergoedingsactie door een aan de toezichthouder betaalde geldboete die geheel of gedeeltelijk toerekenbaar is aan de andere partij.

Deze blog is de laatste editie van de serie “Standaard verwerkersovereenkomsten”. Hierin hebben wij de afgelopen weken de meeste gangbare modellen van de verplichte verwerkersovereenkomst behandeld. Eerder kwamen de verwerkersovereenkomsten van de BoZ, de VNG, de ARBIT/ARVODI en NLdigital aan de orde.