Ik zie privacy niet als een irritante verplichting.

Ik zie privacy als onderdeel van professioneel bouwen, beheren en beschermen.

Of je nu een website maakt, een server beheert, e-mail instelt, back-ups regelt of een compleet netwerk onderhoudt: zodra er persoonsgegevens, accounts, logging, formulieren, cookies of gebruikersdata bij komen kijken, speelt verantwoordelijkheid een grote rol.

Veel ondernemers denken dat een webdeveloper of netwerkbeheerder automatisch alles juridisch en technisch perfect regelt.

En veel developers of beheerders denken juist dat de klant automatisch verantwoordelijk is voor alles wat met privacy, voorwaarden, cookies of gebruikersgedrag te maken heeft.

Daar zit precies het probleem.

Als niemand vooraf duidelijk opschrijft wie waarvoor verantwoordelijk is, ontstaat er achteraf discussie.

De AVG staat voor Algemene Verordening Gegevensbescherming. Internationaal wordt dit de GDPR genoemd.

Deze wet draait om één kernvraag:

Gaan organisaties zorgvuldig om met persoonsgegevens?

Persoonsgegevens zijn bijvoorbeeld:

• Namen
• E-mailadressen
• Telefoonnummers
• IP-adressen
• Accountgegevens
• Contactformuliergegevens
• Bestelgegevens
• Nieuwsbriefinschrijvingen
• Serverlogs
• Back-ups met klantdata
• Trackingcookies en analyticsdata

Ook kleine websites en kleine bedrijven kunnen dus al met AVG / GDPR te maken hebben.

In veel gevallen is de klant de verwerkingsverantwoordelijke.

Dat betekent dat de klant bepaalt waarom persoonsgegevens worden verwerkt en met welk doel.

De klant bepaalt bijvoorbeeld:

• Waarom er een contactformulier nodig is
• Welke klantgegevens worden verzameld
• Welke nieuwsbriefsoftware wordt gebruikt
• Of er marketingcookies nodig zijn
• Welke externe partijen worden ingezet
• Hoe lang gegevens bewaard moeten blijven

Maar als developer of netwerkbeheerder maak ik vaak technische keuzes die invloed hebben op privacy en security.

Daarom vind ik het te makkelijk om alleen maar te zeggen: “De klant is verantwoordelijk.”

Je zou kunnen zeggen dat verantwoordelijkheid in de praktijk vaak gedeeld is.

Soms voelt het bijna als 50% / 50%.

De klant moet eerlijk zijn over wat hij wil verzamelen, welke tools hij gebruikt en wat hij met gegevens doet.

De developer of netwerkbeheerder moet eerlijk zijn over wat technisch wordt gebouwd, wat risico’s zijn en waar juridische controle nodig is.

Maar 50/50 is niet altijd letterlijk waar.

Als een eindgebruiker massaal virussen binnenhaalt door overal op te klikken, illegale software installeert of beveiligingswaarschuwingen negeert, dan kun je als developer of netwerkbeheerder daar natuurlijk niet volledig verantwoordelijk voor worden gehouden.

Andersom geldt ook: als een developer tracking scripts plaatst zonder toestemming, formulieren onveilig opslaat of een cookiebanner verkeerd implementeert, dan kan hij niet alles afschuiven op de klant.

Ik vind dat developers, netwerkbeheerders en klanten veel vaker duidelijke afspraken moeten maken vóórdat het project begint.

Niet pas wanneer er paniek is.

Niet pas wanneer een website verkeerd trackt.

Niet pas wanneer er een datalek is.

Niet pas wanneer een klant zegt: “Maar ik dacht dat jij dat geregeld had.”

Een goed contract legt vast:

• Wat er precies wordt geleverd
• Wat niet binnen de opdracht valt
• Wie juridische teksten aanlevert
• Wie cookies en tracking controleert
• Wie verantwoordelijk is voor updates
• Wie back-ups controleert
• Wie toegang heeft tot persoonsgegevens
• Wie verantwoordelijk is na oplevering
• Wat er gebeurt bij fouten, hacks of datalekken
• Wanneer extra werk ook echt extra werk is

Als webdeveloper maak ik keuzes die direct invloed hebben op privacy.

Denk aan:

• Contactformulieren
• Analytics
• Cookiebanners
• Meta Pixel
• Google Maps
• YouTube embeds
• Nieuwsbriefkoppelingen
• Chatwidgets
• reCAPTCHA
• WordPress plugins
• Betaalsystemen
• Loginomgevingen

Elke tool kan data verwerken.

Daarom vind ik dat je als developer niet alleen moet vragen: “Werkt het?”

Je moet ook vragen: “Is dit netjes, veilig en uitlegbaar?”

Hetzelfde geldt voor de netwerkbeheerder.

Een netwerkbeheerder heeft vaak toegang tot systemen, accounts, servers, back-ups, e-mail, firewalls, gebruikersrechten en soms complete bedrijfsomgevingen.

Daarmee draag je een serieuze verantwoordelijkheid.

Maar ook hier geldt: je kunt niet alles dragen als de klant of eindgebruiker structureel onverstandig handelt.

Voorbeelden:

• Gebruikers klikken massaal op phishingmails
• Medewerkers delen wachtwoorden
• De klant weigert 2FA te gebruiken
• Updates worden uitgesteld omdat het “nu niet uitkomt”
• Er wordt illegale of onbekende software geïnstalleerd
• Back-upadvies wordt genegeerd
• Beveiligingsbudget wordt structureel geweigerd

In zulke situaties moet vooraf duidelijk zijn waar jouw verantwoordelijkheid stopt.

De klant neemt aan dat de developer alles juridisch heeft geregeld.

De developer neemt aan dat de klant de privacyverklaring heeft gecontroleerd.

De netwerkbeheerder neemt aan dat medewerkers veilig omgaan met wachtwoorden.

De klant neemt aan dat de beheerder elk virus, elke fout en elke hack kan voorkomen.

En precies daar gaat het mis.

Aannames horen niet thuis in professionele samenwerking.

Je moet dingen uitspreken, opschrijven en bevestigen.

Als ik een website of webshop bouw, wil ik vooraf duidelijk hebben:

• Wie levert de algemene voorwaarden aan?
• Wie levert de privacyverklaring aan?
• Wie levert de cookieverklaring aan?
• Welke cookies en scripts worden gebruikt?
• Moeten marketingcookies standaard geblokkeerd worden?
• Wordt Google Analytics, Meta Pixel of andere tracking gebruikt?
• Worden formulieren opgeslagen in WordPress?
• Wie heeft toegang tot formulierinzendingen?
• Wie onderhoudt plugins, thema’s en beveiliging?
• Wat gebeurt er als de klant later zelf scripts toevoegt?

Ik vind dat je dit niet achteraf moet ontdekken.

Dit hoort in de offerte, overeenkomst of opleverdocumentatie.

Bij netwerkbeheer wil ik vooraf duidelijk hebben:

• Wie is verantwoordelijk voor gebruikersaccounts?
• Wie bepaalt wie toegang krijgt tot welke bestanden?
• Wordt 2FA verplicht?
• Hoe vaak worden back-ups gemaakt?
• Wie controleert of back-ups werken?
• Wie mag software installeren?
• Hoe wordt omgegaan met phishing en malware?
• Wie meldt incidenten of datalekken?
• Welke responstijd is afgesproken?
• Valt securitymonitoring binnen het contract?
• Wat gebeurt er als advies bewust wordt genegeerd?

Zonder zulke afspraken ontstaat er een gevaarlijke verwachting:

“Jij beheert het netwerk, dus alles is jouw schuld.”

Zo werkt het niet.

Ik merk dat veel klanten deze documenten door elkaar halen.

Maar ze hebben verschillende functies.

Een cookiebanner is vaak het perfecte voorbeeld van schijnveiligheid.

Hij staat op de website, ziet er professioneel uit en geeft bezoekers het gevoel dat alles netjes geregeld is.

Maar technisch kan het alsnog fout zijn.

Bijvoorbeeld:

• Analytics laadt al vóór toestemming
• Marketingcookies worden niet geblokkeerd
• De weigeren-knop is verstopt
• Toestemming wordt niet goed opgeslagen
• Scripts blijven actief na intrekken van toestemming
• De cookieverklaring komt niet overeen met de echte website

Daarom vind ik dat je als developer goed moet testen wat een cookiebanner daadwerkelijk doet.

Een contactformulier lijkt simpel.

Maar ook daar kun je fouten maken.

Ik vraag mezelf altijd af:

• Hebben we dit veld echt nodig?
• Moet een telefoonnummer verplicht zijn?
• Moeten formulierinzendingen in WordPress worden opgeslagen?
• Wie kan de inzendingen zien?
• Worden gegevens veilig per e-mail verstuurd?
• Is HTTPS actief?
• Wordt spambeveiliging privacyvriendelijk ingericht?
• Hoe lang blijven inzendingen bewaard?

Een goed formulier verzamelt niet alles wat handig lijkt.

Een goed formulier verzamelt alleen wat nodig is.

Bij security zie ik vaak dezelfde botsing.

Een klant wil maximale bescherming, maar wil geen sterke wachtwoorden afdwingen.

Een klant wil geen virussen, maar medewerkers klikken zonder training op phishinglinks.

Een klant wil geen downtime, maar wil niet betalen voor monitoring, back-ups of onderhoud.

Dan moet je eerlijk zijn.

Security is geen knop die je één keer aanzet.

Security is een combinatie van techniek, gedrag, budget, beleid en discipline.

Ik geloof in een praktische aanpak.

Geen eindeloze juridische paniek.

Geen overdreven papierwerk zonder inhoud.

Maar wel duidelijke afspraken en technische zorgvuldigheid.

Mijn ideale werkwijze is:

• Vooraf bespreken welke data wordt verwerkt
• Tools, scripts, cookies en plugins inventariseren
• Privacyvriendelijke alternatieven voorstellen waar mogelijk
• Duidelijk opschrijven wie waarvoor verantwoordelijk is
• Geen tracking plaatsen zonder bewuste keuze
• Geen vage beloftes doen over juridische zekerheid
• Opleveren met een technische privacy-check
• Onderhoud en beheer apart afspreken
• Incidenten serieus nemen en documenteren

Als klant kun je niet alles over de schutting gooien.

Je kunt niet verwachten dat een developer of netwerkbeheerder verantwoordelijk blijft voor alles wat jij later toevoegt, wijzigt of negeert.

Voorbeelden:

• Je plaatst later zelf een trackingpixel
• Je installeert zelf een plugin
• Je kopieert privacyteksten van een andere website
• Je negeert update-advies
• Je weigert 2FA
• Je deelt wachtwoorden met medewerkers
• Je bewaart klantdata langer dan nodig
• Je voegt tools toe zonder controle

Dan verschuift de verantwoordelijkheid.

Daarom moet beheer, onderhoud en wijzigingsbeheer duidelijk zijn afgesproken.

Ik ben het ermee eens dat een developer of netwerkbeheerder geen juridisch specialist hoeft te zijn.

Maar dat mag geen excuus worden om privacy en security te negeren.

Als professional hoor je minimaal te begrijpen:

• Dat persoonsgegevens beschermd moeten worden
• Dat trackingcookies toestemming kunnen vereisen
• Dat formulieren data verwerken
• Dat plugins risico’s kunnen introduceren
• Dat toegang tot systemen verantwoordelijkheid geeft
• Dat back-ups ook persoonsgegevens kunnen bevatten
• Dat logging privacygevoelig kan zijn
• Dat afspraken schriftelijk moeten worden vastgelegd

Je hoeft niet alles juridisch op te lossen.

Maar je moet risico’s wél herkennen en bespreekbaar maken.

• Controleer welke cookies geplaatst worden
• Controleer of tracking pas na toestemming laadt
• Maak een lijst van externe scripts
• Controleer formulieren en opgeslagen inzendingen
• Gebruik HTTPS
• Beperk plugins tot wat echt nodig is
• Gebruik privacyvriendelijke analytics waar mogelijk
• Controleer wie toegang heeft tot persoonsgegevens
• Adviseer juridische controle van privacyverklaring en voorwaarden
• Leg vast wat na oplevering onder onderhoud valt

• Leg vast wie toegang krijgt tot welke systemen
• Adviseer of verplicht 2FA waar mogelijk
• Maak afspraken over wachtwoordbeleid
• Maak back-upbeleid concreet
• Test periodiek of back-ups werken
• Documenteer securityadvies
• Leg vast wat buiten beheer valt
• Maak afspraken over incidentrespons
• Regel logging zorgvuldig
• Bespreek gebruikerstraining tegen phishing en malware

Ik zie contracten niet als iets kils.

Ik zie ze als bescherming voor beide kanten.

Een goed contract beschermt de klant omdat duidelijk is wat hij mag verwachten.

Een goed contract beschermt de developer of beheerder omdat duidelijk is wat niet onder zijn verantwoordelijkheid valt.

En een goed contract beschermt de eindgebruiker omdat privacy, security en beheer niet worden vergeten.

Voor mij draait AVG / GDPR niet alleen om regels.

Het draait om vertrouwen.

Een bezoeker moet erop kunnen vertrouwen dat zijn gegevens niet zomaar worden verzameld.

Een klant moet erop kunnen vertrouwen dat een developer of beheerder professioneel meedenkt.

Een developer of netwerkbeheerder moet erop kunnen vertrouwen dat de klant zijn eigen verantwoordelijkheid serieus neemt.

Daarom geloof ik in duidelijke contracten, goede documentatie en eerlijke communicatie.

Niet alles is de schuld van de developer.

Niet alles is de schuld van de klant.

Niet alles is de schuld van de netwerkbeheerder.

Maar iedereen heeft wel een rol.

En hoe beter je die rol vooraf vastlegt, hoe kleiner de kans op ruzie achteraf.

Deze pagina is geschreven vanuit mijn praktische visie als maker, developer en technisch professional.

Dit is geen juridisch advies.

Voor sluitende algemene voorwaarden, privacyverklaringen, cookieverklaringen, verwerkersovereenkomsten of aansprakelijkheidsafspraken is het verstandig om een jurist of privacy-specialist in te schakelen.

Wat ik wél wil meegeven: wacht daar niet mee tot het fout gaat.