Dit is geen juridisch advies. Het is de praktische checklist die wij voor onszelf hebben opgesteld tijdens het werken met klanten in Duitsland, Italië en het Verenigd Koninkrijk, en die wij bij elk nieuw project herhalen. Het vervangt uw jurist niet, maar het maakt het gesprek met uw jurist veel korter.
Het basiskader: uw klant is de verwerkingsverantwoordelijke, u bent vrijwel zeker de verwerker, en elke clouddienst die u gebruikt is een subverwerker. Zodra die drie begrippen correct zijn geplaatst, valt de rest van de lijst vanzelf op zijn plaats.
De AVG is geen papierwerk; het is een architecturale beslissing. De documenten beschrijven de architectuur — zij vervangen haar niet.
01De contractlaag: een verwerkersovereenkomst en modelcontractbepalingen
U hebt een ondertekende verwerkersovereenkomst nodig met elke EU-klant. Omdat Türkiye geen adequaatheidsbesluit heeft, gaat die overeenkomst, als gegevens in Türkiye worden verwerkt, vergezeld van modelcontractbepalingen en een korte transfer impact assessment. In de praktijk reizen deze drie documenten samen, en eenmaal goed opgesteld worden ze bij elk project hergebruikt.
Stap twee is de lijst van subverwerkers. Elke dienst die u gebruikt — hosting, transactionele e-mail, foutregistratie, analytics, back-ups — staat erop met naam, doel en regio, en die lijst wordt met de klant gedeeld. Er een regel aan toevoegen is volgens het contract een meldingsplichtige gebeurtenis, en daarom is het houden van een pagina met een link ernaartoe de meest praktische aanpak.
02De architectuurlaag: regio, bewaartermijn, verwijdering
Voor EU-klanten is onze standaard ondubbelzinnig: database en objectopslag in een EU-regio (Wenen of Ierland), waarbij back-ups in dezelfde regio blijven. Die ene beslissing vereenvoudigt de antwoorden op de honderd vragen die daarna volgen. Als het ontwikkelteam er vanuit Türkiye toegang toe heeft, is dat toegang op afstand, en zo wordt het ook in de verwerkersovereenkomst beschreven.
Bewaartermijnen worden per gegevenstype vastgelegd: contract- en factuurgegevens voor de wettelijk verplichte jaren, marketingtoestemmingen tot intrekking, serverlogboeken negentig dagen, cv's van kandidaten zes maanden. Die termijnen in de software vastleggen — een verwijderdatumveld en een nachtelijke taak — is betrouwbaarder dan ze in een document te schrijven.
Behandel verzoeken om verwijdering en export vanaf dag één als een functie. Kunt u de gegevens van één gebruiker in één handeling exporteren en wissen, dan houdt de wettelijke termijn van dertig dagen op een bron van stress te zijn. Het er later aan toevoegen is altijd lastig, omdat de gegevens dan al over vijf tabellen zijn verspreid.
03Dagelijkse praktijk: cookies, formulieren, datalekplan
De cookiebanner is geen ontwerpelement maar een technische belofte: analytics- en marketingscripts mogen niet laden vóór toestemming, en 'weigeren' moet even zichtbaar zijn als 'accepteren'. Een site die deze twee zaken goed regelt, heeft al de eerste twee punten van elke audit doorstaan.
Scheid bij formulieren de doeleinden: een projectaanvraag en een nieuwsbriefinschrijving zijn twee verschillende toestemmingen, en geen enkel vakje komt vooraf aangevinkt binnen. Elk formulier verwijst naar een privacyverklaring, en die verklaring beschrijft daadwerkelijk de velden van dat formulier.
Het laatste punt is degene die niemand wil voorbereiden: het datalekplan. Eén pagina die vermeldt wie wordt geïnformeerd, waar de logs worden gelezen, wat aan de klant wordt geschreven, en wie verantwoordelijk is voor de tweeënzeventig-uursklok. Die pagina op een rustige dag schrijven is veel goedkoper dan hem op een slechte dag te schrijven.
Geschreven door
Het Paradigma7-team
Product, engineering en operations
We zijn een op Ankara gebaseerd team dat software voor Europa bouwt. Niets hier is theorie: dit zijn de processen die we werkelijk op klantprojecten uitvoeren.
Over ons