AVG en EU-hosting: waar teams bij ontwikkelaarstools op moeten letten

Wanneer een onderneming een nieuw analysetool wil invoeren, is het verloop inmiddels ingespeeld: de functionaris voor gegevensbescherming vraagt naar de verwerkersovereenkomst, iemand controleert de serverlocatie, de privacyverklaring wordt aangevuld. Bij de gereedschapskist van de ontwikkelafdeling gaat het vaak anders: een teamlid vindt een nuttige tool, maakt een account aan, en drie maanden later is die een stil onderdeel van de dagelijkse werkpraktijk. Die ongelijke behandeling heeft geen inhoudelijke grond — ook gereedschap voor ontwikkelaars verwerkt gegevens, en sommige meer dan hun gebruikers zich bewust zijn.

Testdiensten zijn daarvoor een goed aanschouwingsobject. Een screenshotdienst bijvoorbeeld fotografeert webpagina's — en een foto van een webpagina bevat alles wat die webpagina toont. Bij een openbare marketingpagina is dat ongevaarlijk. Interessant wordt het aan de randen: stagingomgevingen die met kopieën van echte productiegegevens zijn gevuld. Pagina's die gebruikersreacties, beoordelingen of profielfoto's tonen. Adressen in wier URL-parameters sessiekenmerken of identificatoren steken. Wie zulke pagina's aan een externe dienst geeft, draagt onder omstandigheden persoonsgegevens over — ook al speelt in het hoofd alleen „we testen de lay-out".

De AVG, de Algemene verordening gegevensbescherming, ordent zo'n constellatie helder: de onderneming die de dienst gebruikt, blijft verwerkingsverantwoordelijke voor de gegevens; de dienst treedt in de regel op als verwerker. Die rolverdeling is geen formaliteit, maar heeft een praktisch gevolg: er is een verwerkersovereenkomst volgens artikel 28 nodig — gebruikelijk als standaarddocument van de aanbieder —, en de verantwoordelijkheid dat de verwerking in haar geheel rechtmatig is, verhuist niet met de gegevens mee naar de dienstverlener. Die blijft bij de onderneming.

De tweede standaardvraag geldt de plaats van de verwerking. Binnen de EU geldt de AVG rechtstreeks; bij aanbieders die gegevens in derde landen verwerken, begint daarentegen een eigen toetsingshoofdstuk: adequaatheidsbesluiten, modelcontractbepalingen, transfer impact assessments. Voor doorgiften naar de VS bestaat weliswaar een adequaatheidsbesluit, maar de voorgangers daarvan zijn al tweemaal door de rechter onderuitgehaald, en ook het huidige kader blijft juridisch omstreden. Niets daarvan maakt Amerikaanse diensten onbruikbaar — maar elk van die constructies is toetsingswerk dat bij een EU-locatie eenvoudigweg wegvalt. EU-hosting is in zoverre minder een keurmerk dan een afkorting: het maakt de beoordeling korter, niet overbodig.

ScanU, een dienst voor visuele regressietests en browserscreenshots, leent zich hier als concreet voorbeeld omdat de aanbieder de datalocatie expliciet maakt: de gegevens worden volgens opgave van de aanbieder in Frankfurt gehost, en de dienst positioneert zich uitdrukkelijk met het oog op de AVG — na te lezen op de Nederlandse introductiepagina van ScanU. Voor een Duitse onderneming betekent dat: de derdelandenvraag stelt zich voor de kerndienst vooralsnog niet, en de toetsing kan zich op de gebruikelijke punten concentreren — overeenkomst, bewaartermijnen, verwijdering, subverwerkers.

En precies hier hoort een eerlijke zin, die voor elke aanbieder geldt, ook voor de hier besproken: uitspraken op een productwebsite zijn het uitgangspunt van de toetsing, niet het resultaat ervan. „In Frankfurt gehost" en „AVG-gericht" zijn eigen verklaringen van de aanbieder — wie de dienst zakelijk wil inzetten, leest de verwerkersovereenkomst, controleert de lijst van subverwerkers en klaart uit wat er bij opzegging met de gegevens gebeurt. Een aanbieder die zulke documenten bereidwillig verstrekt, doet daarmee meer voor het vertrouwen dan welke marketingformulering ook; een aanbieder bij wie ze niet te vinden zijn, heeft de belangrijkste vraag al beantwoord.

Wie voor het eerst een verwerkersovereenkomst leest, kan zich daarbij aan vier plekken oriënteren. Ten eerste het voorwerp: beschrijft de overeenkomst concreet welke gegevens voor welk doel worden verwerkt, of blijft ze uitwisselbaar generiek? Ten tweede de technische en organisatorische maatregelen, meestal als bijlage: staan daar navolgbare gegevens over versleuteling, toegangscontrole en locatie — of gemeenplaatsen? Ten derde de regeling voor subverwerkers: wordt de klant over wisselingen geïnformeerd, en kan hij bezwaar maken? Ten vierde teruggave en verwijdering van de gegevens na afloop van de overeenkomst. Geen van die vragen veronderstelt een rechtenstudie — het zijn begripsvragen die elke technisch onderlegde persoon kan beantwoorden. En waar de overeenkomst zwijgt, is de gerichte navraag bij de aanbieder de eerlijkste test van zijn bereidheid tot informatie.

Een vaak over het hoofd gezien toetsingspunt zijn bewaartermijnen — terwijl ze gegevensbeschermingsrechtelijk een kernthema zijn, trefwoord dataminimalisatie: gegevens horen niet langer bewaard te worden dan het doel vereist. Bij screenshotdiensten bepaalt de bewaring van de controlehistorie hoe lang afbeeldingen van de eigen pagina's bij de aanbieder liggen. ScanU staffelt die historie naar prijsniveau — van drie dagen in het gratis tarief via 15 en 30 dagen tot 90 dagen in het grootste niveau, zoals de prijsniveaus van ScanU aangeven. Opmerkelijk daaraan: vanuit gegevensbeschermingsoogpunt is het kleinste niveau het zuinigste. Wie lange verlopen nodig heeft, bijvoorbeeld om regressies over maanden af te bakenen, kiest bewust de langere termijn — maar het zou een bewuste keuze moeten zijn, geen standaardinstelling waar nooit iemand over heeft nagedacht.

Minstens zo belangrijk als de toetsing van de aanbieder is het eigen gebruiksgedrag — want de meest effectieve gegevensbeschermingsmaatregel is om gevoelige gegevens helemaal niet in de dienst te stoppen. Voor testdiensten betekent dat concreet: testomgevingen vullen met synthetische voorbeelddata in plaats van met kopieën van de productiedatabase. Openbare pagina's en lay-outs testen in plaats van ingelogde weergaven met echte klantgegevens. Erop letten dat er in geteste URL's geen sessietokens of persoonsgebonden identificatoren zitten. Die regels kosten weinig, gelden voor elk URL-gebaseerd werktuig — en ze ontmijnen de gegevensbeschermingsvraag effectiever dan welke contractclausule ook.

Hoe zulke gebruiksregels eruit kunnen zien, past in drie zinnen voor de teamwiki. Ten eerste: in de dienst gaan alleen adressen van openbare pagina's of van stagingomgevingen met synthetische gegevens — nooit weergaven die echte klantgegevens tonen. Ten tweede: vóór het aanmaken van een nieuw controleproject wordt de URL één keer bewust op haar parameters nagelopen; sessietokens en persoonsgebonden identificatoren horen daar niet in thuis. Ten derde: gedeelde rapporten worden als interne documenten behandeld — doorgeven alleen aan betrokkenen, links niet in openbare kanalen. Zulke regels zijn in tien minuten geformuleerd en bij het inwerken van nieuwe collega's snel over te brengen. Hun waarde ligt minder in de bewoording dan in het feit dat het onderwerp één keer is uitgesproken: privacyincidenten bij het gebruik van gereedschap ontstaan zelden met opzet — meestal uit routine waarin nooit iemand de vraag heeft gesteld.

Ook gedeelde rapporten verdienen een gedachte. Deelbare controlerapporten zijn voor de samenwerking uitgesproken praktisch — precies daarom zou uitgeklaard moeten zijn wie een gedeeld rapport kan openen en hoe lang het beschikbaar blijft. Dat is geen bijzonderheid van testdiensten: voor rapporten geldt hetzelfde als voor gedeelde documenten in elk cloudwerktuig. Een rapport dat screenshots van een nog niet gepubliceerde productpagina bevat, is vertrouwelijk materiaal en zou zo behandeld moeten worden.

Hoe diep moet de toetsing gaan? De AVG zelf geeft het antwoord: risicogebaseerd. Een screenshotdienst die openbare marketingpagina's fotografeert, is van een ander kaliber dan salarisadministratiesoftware met loongegevens. Het zou onevenredig zijn beide met dezelfde vragenlijst te overladen — maar even verkeerd om het kleinere geval helemaal niet te bekijken. Een pragmatische middenweg voor gereedschap voor ontwikkelaars: rol uitklaren (verwerker?), overeenkomst verzamelen, datalocatie en subverwerkers noteren, bewaar- en verwijderingstermijnen vastleggen, gebruiksregels voor het team formuleren. Dat is in overzichtelijke tijd geregeld en dekt de wezenlijke plichten af.

Doorgespeeld aan het voorbeeld van een screenshotdienst ziet die lijst er zo uit. Rol: de dienst verwerkt de doorgegeven pagina-inhoud in opdracht van de onderneming — verwerker dus, bijgevolg de overeenkomst volgens artikel 28 verzamelen en archiveren. Datalocatie: bij de aanbieder nalezen en noteren; bij ScanU is Frankfurt opgegeven, waarmee de derdelandentoetsing voor de kerndienst wegvalt. Subverwerkers: lijst uit de contractstukken halen of opvragen — ook een EU-aanbieder kan onderaannemers inzetten, en pas die lijst maakt de keten compleet. Bewaartermijnen: het gekozen prijsniveau bepaalt hoe lang controlehistorie en daarmee screenshots worden bewaard; de termijn met de werkelijke behoefte vergelijken en de beslissing in één zin onderbouwen. Verwijdering: uitklaren wat er bij opzegging met rapporten en verlopen gebeurt. Wie deze vijf punten op één pagina documenteert, heeft voor een werktuig van deze risicoklasse het wezenlijke gedaan — en tegelijk een sjabloon dat bij het volgende werktuig opnieuw te gebruiken is. Antwoorden op typische vragen over de dienst zelf bundelt de aanbieder in de veelgestelde vragen over ScanU.

Daarbij hoort ook een vermelding in het register van verwerkingsactiviteiten — die verplichte documentatie waarin een onderneming vastlegt welke diensten welke gegevens voor welk doel verwerken. Dat klinkt bureaucratischer dan het is: voor een werktuig voor ontwikkelaars zijn dat een paar regels. De eigenlijke waarde ligt elders: wie de vermelding schrijft, moet de vragen beantwoord hebben. De documentatie dwingt de toetsing af die anders in de dagelijkse praktijk wegsijpelt.

Een tegenwerping uit de praktijk verdient daarbij een eerlijk antwoord: wordt de toetsing te log, dan vindt ze niet grondiger plaats, maar helemaal niet. Liggen er tussen „werktuig gevonden" en „werktuig vrijgegeven" zes weken en drie verantwoordelijkheden, dan maken ontwikkelaars het account op een gegeven moment privé aan — en wordt van een toetsbare dienst schaduw-IT waarvan niemand meer weet. Het gevolg daarvan is niet om van toetsing af te zien, maar om haar aan het risico aan te passen: een snelle, gedocumenteerde korte check voor werktuigen met weinig gegevensbetrokkenheid, de volledige toetsing voor alles wat aan productiegegevens of klantsystemen raakt. Een team dat weet dat de korte check enkele dagen duurt en meestal met een ja eindigt, heeft geen reden hem te omzeilen. De meest robuuste gegevensbeschermingsorganisatie is uiteindelijk die waarvan de officiële weg sneller is dan de omweg.

Blijft de algehele inschatting. De keuze voor gegevenszuinige, transparant gehoste werktuigen is geen juridische haarkloverij, maar deel van de vakmatige zorgvuldigheid die teams elders allang vanzelfsprekend vinden — niemand zou een database zonder back-upconcept draaien. EU-hosting, heldere bewaartermijnen en een zuivere verwerkersovereenkomst zijn daarbij drie goede criteria onder meerdere, geen vervanging van de eigen toetsing: ook een in Frankfurt gehoste dienst kan slecht geconfigureerd, verkeerd gebruikt of met de verkeerde gegevens gevuld zijn. De verantwoordelijkheid daarvoor draagt niet de aanbieder, maar de onderneming die hem inzet.

Het goede nieuws tot slot: de inspanning is eenmalig en overzichtelijk. Een uur gestructureerde toetsing per werktuig, een korte vermelding in de documentatie, twee gebruiksregels voor het team — meer is er voor de meeste werktuigen voor ontwikkelaars niet nodig. Vergeleken met de inspanning om een onbezonnen gegevensdoorgifte achteraf te moeten verklaren, is dat een zeer goede ruil.