Ik hoop dat die orthodontist z’n webbouwer aansprakelijk stelt voor die 12.000 euro boete

De Autoriteit Persoonsgegevens heeft een boete van 12.000 euro uitgedeeld aan een orthodontistenpraktijk omdat die op een aanmeldformulier geen ssl-verbinding gebruikte. Dat meldde Tweakers vorige week. Door het ontbrekende ‘slotje’ liepen patiënten de kans dat gevoelige gegevens, zoals hun BSN, in verkeerde handen zouden terechtkomen. Opmerkelijk dat die basale beveiligingsmaatregel er niet was, maar minstens zo opmerkelijk dat de AP er voor in actie kwam gezien de beperkte scope. Maar goed, ik ben dus fan van kleine boetes voor kleine overtredingen.

De betreffende website bood klanten van de orthodontist gelegenheid afspraken te maken voor een behandeling. Op zich logischerwijs vroeg men om onder meer NAW-gegevens, geboortedatum, BSN, telefoonnummers van de patiënt en de ouders, gegevens over de school, huisarts, tandarts en de verzekeringsmaatschappij.” Dat formulier werd zonder beveiliging (dus SSL-, TLS-certificaat oftewel “slotje”) opgestuurd, wat inderdaad een beveiligings-dingetje is.

Is het heel erg? Mwa. Technisch betekent het dat iedereen die in het netwerk tussen de klant en de orthodontist zit, de data kan onderscheppen. Het klassieke voorbeeld is het internetcafé of bibliotheek, waar je met de juiste software alles kunt zien dat anderen in diezelfde ruimte opsturen naar websites. Door https te gebruiken, is dit niet langer inzichtelijk – de communicatie naar de site is versleuteld en daarmee niet meer te lezen.

Het aantal scenario’s waarin dit een reëel risico is, is dus beperkt. Vanuit huis is dit bijvoorbeeld geen issue, de buren die ook bij Ziggo zitten kunnen sowieso niet meelezen. Huisgenoten mogelijk wel. Werk je met mobiel internet, dan is dit ook geen serieus risico. Maar natuurlijk is er een niet te verwaarlozen groep mensen die alleen via publieke terminals (zoals de bieb) kan werken, en ook die moet gewoon veilig internet op kunnen.

Daar komt bij: al sinds jaar en dag weet iedereen dat zo’n slotje weinig moeite is, zeker sinds initiatieven als Let’s Encrypt die je gratis certificaten geven om het slotje te realiseren. Dus het voelt als “oké beperkt risico maar het is zo gedaan, doe het dus gewoon” voor mij. Ik blogde er ooit in 2013 over en concludeerde dat het eigenlijk onvermijdelijk is, behalve wellicht bij triviale formulieren zoals de plek hieronder waarin u het hartgrondig met mij oneens gaat zijn.

In het boetebesluit kan de AP het nog simpeler houden: het gaat hier om persoonsgegevens in de zorg, daarbij is NEN 7510-2 leidend en daaruit volgt het gebruik van TLS. Punt, klaar, next. En dan gaat het om zeer gevoelige gegevens, ook nog eens (vooral) van kinderen en dan mag dat al helemaal niet gebeuren. Normaal kom je dan op een boete van een ton, maar omdat deze orthodontist dat absoluut niet kan betalen wordt deze gematigd naar 12.000 euro.

En dan gooi ik met dit citaat even de knuppel in het hoenderhok:

[Betrokkene] heeft erkend dat de oude website geen gebruik maakte van een versleutelde verbinding. De ontwikkelaar van de oude website heeft haar nooit gewezen op die mogelijkheid. Anders had zij daar zeker gebruik van gemaakt, aldus [betrokkene].
We hebben het dus over 2019. Let’s Encrypt was toen al best bekend, en het algemene idee dat SSL-certificaten verstandig waren ook. Om dus nog maar niet te spreken van die NEN-norm in de zorg. Dan wil ik van een kleine orthodontie-praktijk nog wel geloven dat die weinig verstand van internet heeft (de nieuwe site heeft geen online formulier meer maar een uit te printen pdf, ik bedoel maar)  maar van de webbouwer mag dit wel verwacht worden toch?

Oftewel, die orthodontist mag de webbouwer op grond van schending zorgplicht aansprakelijk houden voor die 12.000 euro wat mij betreft.

Arnoud

53 reacties

  1. Arnoud

    Veel kleine boetes voor kleine overtredingen zijn inderdaad effectief en veel rechtvaardiger dan af en toe er iemand “uitpikken”. Langs de andere kant betreft het hier de zorg met een zeer specifieke norm.

    Vergeet niet dat een web formulier ook een “achterkant” heeft. Vaak wordt er van het formulier een e-mail gemaakt, zeker bij zeer lage volumes. Dat hoeft geen probleem te zijn als alles in hetzelfde domein gebeurd, maar dat is vaak niet goed geregeld.

    Ik begrijp de invulbare pdf, lijkt me een eenvoudige oplossing.

    Uiteraard is de dienstverlener hier zwaar in gebreke gebleven. In de webbouwers wereld lopen velen veel achter op wat professioneel werken is.

    1. Daar kaart je zeker een goed punt aan; Communicatie vanuit een formulier wordt denk ik vaak via e-mail doorgezonden. Nu zijn er allerlei maatregelen die e-mailproviders op gebied van security kunnen nemen. En daar tussen gaan zitten is nog een stuk moeilijker dan op wifi. Maar bij een formulier waarin patiëntgegevens gedeeld worden zou ik zeker adviseren om dat niet via de mail door te sturen.

      1. Ik zie e-mail inderdaad ook als de zwakke plek hier. Echter, wat is het alternatief? Moet je de gegevens laten staan op een shared webhostingdienst? Waarvan de provider ongetwijfeld het MySQL ‘root’ account gebruikt voor het zelf-geknutselde contactformuliertje op hun eigen webpagina? Of moet je de website gaan draaien in je eigen omgeving (en dus direct een gat in je firewall prikt naar je 2012 Small business servertje? Want zo werkt het wel in dergelijke omgevingen)

        Natuurlijk zijn hier oplossingen voor. Je kunt de verwerkingspagina direct een TLS-encrypted verbinding met de SMTP server van de ontvanger op laten zetten, je kunt de data via HTTPS of andere secure-API protocol posten naar het administratiesysteem van de praktijk, je kunt de data gelijk versleutelen via asymmetrische encryptie voordat je het opstuurt… Maar als een gratis TLS certificaat configureren al te veel blijkt te zijn…

  2. Even als advocaat van de duivel: Maar waarom zou een webbouwer nou weer meer moeten weten over de regels die gelden voor in de zorg. Immers, de AP heeft gesteld dat de boete is opgelegd omdat specifieke zorg-gerelateerde persoonsgegevens (NEN 7510-2) onversleuteld zijn verstuurd. Dat lijkt me dus iets voor de zorgverlener om attent op te zijn. Tenzij de webbouwer heeft gezegd: ik ben professional in het domein van zorgverlening en die NEN normen eet ik als ontbijt.

    1. Zoals Arnoud zegt in het artikel, HTTPS is zo enorm vanzelfsprekend dat een websitebouwer die daar géén rekening mee houdt gewoon zijn zorgplicht niet goed uitvoert. Je maakt een aanmeldformulier voor een orthodontist, dan is 1 + 1 gewoon 2 en moet je daar zorgvuldig mee omgaan.

      1. In 2019 had de ontwikkelaar de orthodontist op zijn minst er op moeten wijzen dat een formulier zonder HTTPS bepaalde risico’s (technisch/vanwege mogelijke regelgeving) geeft.

        Aan de andere kant; als je voor een appel en een ei ergens een website ‘haalt’ (aanname), dan kun je ook niet het beste verwachten.

        1. Maar HTTPS in het algemeen is geen verplichting. Dus dat de ontwikkelaar er op had moeten wijzen lijkt me irrelevant in deze zaak. Het is nu relevant omdat er persoonsgegevens in de zorg zonder HTTPS worden gedeeld.

          Ander voorbeeld: ondernemende klant vraagt webbouwer website te bouwen. Klant vraagt daarna de site ook naar het Duits te vertalen en op een .de te zetten. De klant krijgt daarna een abmahnung omdat hij geen impressum op de site heeft staan, want Duitsland verplicht commerciële websites om een colofon te tonen. Is de webbouwer aansprakelijk of de ondernemende klant? Maw, moet de webbouwer, behalve NEN 7510-2 (persoonsgegevens in de zorg), ook de Telemediengesetz (Duitse mediawet) kennen?

          1. Als er persoonsgegevens worden gevraagd, moeten deze beveiligd zijn, da’s basis basis AVG. Ik zie echt niet hoe een website van meer dan 1 pagina AVG-conform kan zijn als er geen https gebruikt wordt.

            Als de webbouwer een Duitse website maakt, is het vanzelfsprekend dat hij de daar geldende basiswetgeving kent of even enkele vragen stelt. Volgens mij is dit trouwens in meer landen een verplichting, ik denk zelfs dat het een EU verplichting is, zelfs los van de verplichtingen die daaromtrent door de AVG worden opgelegd.

          2. U doet nu net alsof SSL een of andere vage techniek is waarvan het gebruik louter uit een obscure wet met een bijzonder beperkt bereik voortvloeit.

            Dat is natuurlijk niet zo. Ook los van deze bijzondere verplichting in de zorg is fatsoenlijke databeveiliging al enkele decennia de norm. Als website bouwer moet je toch in ieder geval een basale kennis hebben van beveiliging en de meest gangbare technieken toepassen. Daar valt SSL nu onder. Of dat ten tijde van het bouwen van de website ook zo was daar weet ik niet voldoende van. Feit is echter wel dat u veel te makkelijk het straatje van deze webbouwer schoonveegt

            1. Maar voor de gemiddelde computerleek is SSL ook gewoon een vage techniek waar ze niets van snappen. Mijn antwoord op dit soort opmerkingen dat mensen het best wel snappen is door gewoon te melden dat de halve bevolking een beneden-gemiddelde intelligentie heeft! En dat is gewoon een feit! (Want zo werken statistieken!)

              Dit kun je overal naar doortrekken. Zo hebben de helft van de webdevelopers een beneden-gemiddelde kennis over SSL. En dat is best beangstigend als je dan kijkt naar de enorme aantallen webdevelopers die er zijn in Nederland, inclusief veel prutsers…

              Bedenk ook dat als je ooit naar een chirurg moet, die chirurg mogelijk met enkele zesjes net met de hakken over de sloot is geslaagd en je dus misschien niet de beste en slimste chirurg krijgt die aan je binnenwerk gaat sleutelen. Want ook hier is de helft van alle chirurgen beneden de gemiddelde kwaliteit die je mag verwachten…

              Dus hoewel jij en ik redelijk bekend zijn met SSL kun je niet aannemen dat iedereen dezelfde kennis heeft. Je hebt ook helemaal geen diploma’s of minimale intelligentie nodig om een webdeveloper te worden. Mensen met het IQ van een walnoot kunnen gewoon websites bouwen als ze dat willen. En als iemand anders hen daarvoor inhuurt dan krijg je dus boetes van 12.000 euro…

              1. Wim

                Mijn slecht karakter : Je kennis van statistiek is duidelijk onder de mediaan.

                Ruim meer dan de helft van de bevolking verdient minder dan het gemiddelde inkomen. of een leukere : meer dan de helft van de bevolking leeft langer dan de gemiddelde leeftijd.

                Mijn ervaring is dat dit weinig met intelligentie te maken heeft, maar veel meer met de wil bepaalde zaken even te lezen. SSL is als principe zeer eenvoudig en de bij de meeste hosters is het meer werk het uit te zetten. bv. Even lezen over het Schrems II arrest vereist geen zeer grote intelligentie, maar dat geeft al enkele aandachtspunten. De details is een ander verhaal.

                1. Meh. Veel mensen weten het verschil niet eens tussen gemiddelde en mediaan en diverse mensen zullen nog nooit van mediaan gehoord hebben. 🙂 Maar IQ-testen worden gebaseerd op de Bell curve waarbij er ruwweg evenveel personen zijn aan beide kanten van het gemiddelde. Dan wordt ook eigenlijk mediaan bedoeld. 🙂

                  Maar de wil om te lezen vind je nauwelijks onder ICT’ers. Velen gaan automatisch aan de slag zonder zelfs maar een handleiding te lezen. Veel van de prutsers volgen een simpele YouTube video met wat extra info van StackOverflow of Quora en denken dan dat ze al goed genoeg zijn. Onder die prutsers heeft niemand ook maar enige aandacht voor beveiliging. Dat is ook waarom nog steeds HTTP wordt gebruikt en wachtwoorden regelmatig als plain-text worden opgeslagen. En waarom 123abc nog steeds zo populair is als wachtwoord.

                  Kijk, voor sommige beroepen moet je de nodige diploma’s hebben voor je ermee aan de gang mag. Een chirurg zal toch best een behoorlijke opleiding moeten afronden voordat hij even je borstkas mag opensnijden. En een jurist zal ook eerst de nodige papieren moeten behalen voor hij juridisch advies mag geven. Maar iedere “idioot” met 5 dagen ervaring in PHP kan al websites maken en verkopen, ook al is het merendeel copy/paste van het Internet. Het neefje van 16 dat computerlessen op school heeft gevolgd is goedkoper om in te huren dan een professional met jarenlange ervaring. Het neefje vraagt 50 euro en een kratje bier. De professional vraagt 2500 euro plus 500 per jaar voor onderhoud. Dan wint vaak het neefje…

                  Probleem is dat de gemiddelde persoon relatief dom en onwetend is en vaak ook helemaal niet geïnteresseerd in de gehele materie. Die wil gewoon een werkende site waar nieuwe klanten kunnen registreren en daarmee is het klaar. Oh, maar wel voor de laagste prijs, natuurlijk…

                  Dat er dan boetes van 12.000 euro worden uitgedeeld helpt dan hopelijk een beetje, maar de meesten zullen daar niet eens van gehoord hebben.

                  1. Welke papieren moet een jurist hebben om advies te geven? Ik dacht dat men zich zomaar jurist mocht noemen.

                    En eigenlijk snap ik al helemaal niet waarom we het in deze specifieke geval over webbouwers hebben. Want webbouwer en hoster zijn twee verschillende dingen. En een webbouwer heeft vrijwel niks met SSL te maken. Alleen als de site live gaat, moet er een certificaat aan de hoster worden gegeven, of moet de hoster om een certificaat worden gevraagd. Eigenlijk zou de hoster dus aangekeken moeten worden op dat ze nog HTTP zonder S toestaan. HTTP zou eigenlijk alleen gebruikt moeten worden om te redirecten naar HTTPS. En alle hosters moet eigenlijk een grote enge rode doodsknop hebben om verdere HTTP gebruik toe te staan.

                    1. Je hebt gelijk. Iedereen mag zichzelf jurist noemen. Hey, ik ben een jurist! 😀 Toch zullen veel mensen al snel controleren welke kwalificaties een jurist heeft. 🙂

                      Overigens gaat het om de vraag wie er verantwoordelijk is dat de site geen SSL heeft ondersteund. En dan heb je dus be bouwer ervan, de hoster of beheerder en uiteindelijk de eigenaar. Die eigenaar krijgt in principe de boete terwijl bouwer en beheerder alleen maar werk in opdracht uitvoerden, alsof ze ingehuurde werknemers zijn. Het is dus nog best een opgave om te zien of de beheerder of bouwer erop aangesproken kunnen worden dat er slecht werk was afgeleverd…

                      Probleem is dat de beheerder mogelijk niet bewust was dat er prive-gegevens werden bijgehouden en dus alleen naar de logs keek en zag dat deze draaide. En de bouwer had kunnen denken dat de beheerder het wel onder HTTPS zou dumpen en het dan veilig genoeg zou gaan. Eigenlijk is de eigenaar de egine die het volledige plaatje ziet en die heeft er geen bal verstand van en dan krijg je dus boetes…

                      En ja, alle hosts zouden automatisch alleen HTTPS moeten aanbieden maar veel kleinere hosts hebben nog geen zin om daarin te investeren. Zeker als de bouwer gewoon aangeeft dat er een virtuele server gehuurd kan worden waar je dan simpelweg zelf de gehele hosting in elkaar zet. Virtuele Linux server met Apache en standaard HTTP en klaar. Via FTP de site uploaden en verder niet moeilijk doen want als het werkt dan is het klaar…

                      Waarbij je dus moet beseffen dat veel bouwers hun site bouwen onder HTTP en niet HTTPS want dat is makkelijker te debuggen. Zeker als je dan via fiddler ook even al het netwerk-verkeer gaat volgen.

                      SSL is niet zo moeilijk mits je er maar even mee bezig gaat. Maar ja, wie zichzelf aanleert om websites te bouwen zal daar niet snel aandacht voor hebben.

                      Maar…

                      Alle moderne webbrowsers geven tegenwoordig wel een signaal als een site geen HTTPS ondersteunt en zullen standaard eerst HTTPS proberen. De vraag is dan of de eigenaar dat heeft opgemerkt in zijn eigen browser. Aan de andere kant, er is een goede kans dat die eigenaar nog Windows XP of Windows 7 gebruikt want mensen die niet in de ICT actief zijn zullen ook niet snel hun hardware upgraden. Ik moest zelf on 2005 nog werken aan 16-bit software voor Windows 3.11 omdat sommige bedrijven niet konden upgraden omdat een deel van hun software niet onder 32-bit systemen kon draaien…

    2. De webbouwer hoeft dit specifieke feit niet te weten. Maar in 2019 moest hij op de hoogte zijn van de AVG. De gegevens die ingevuld moeten worden zijn per definitie gevoelig. Dus je kunt rustig verlangen, dat deze aangeeft dat er een beveiliging moet worden gebruikt.

    1. Daar zeg je wel wat, als het een professionele partij was!

      Ik heb zelf (heel lang geleden) tijdens mijn studie voor een aantal vereningingen de website opgezet, inclusief forums e.d. Het begon met de vereniging waar ik zelf lid van was en de rest was eigenlijk niet meer dan een kopie van de site met een aangepaste opmaak. Ik had studie genoten die hetzelfde deden, soms ook voor bedrijven en tegenwoordig leer je op sommige middelbare scholen al full stack development. En er is voldoende vraag naar partijen die goedkoop een website willen maken, google maar eens.

      Het zou mij niet verbazen als de site door een hobbyist is gemaakt en dan zou ik toch echt de verantwoordelijkheid bij de orthodontist leggen.

      Dus voor we aan titel van de blogpost toekomen, zou ik eerst wel eens willen weten ‘wie’ de bouwer was.

        1. Mijn 12 jarige neefje maakt al websites als hobby en voor school opdrachten. Mijn website voor de club ging volgens het oproep principe “we hebben een website nodig, maar geen geld. Is er een lid die een beetje handig is die dit kan maken”. Kreeg achter af een platenbon als bedankje.

          M.i. is het alleszins redelijk dat als je als organisatie een duidelijke amateur vraagt iets voor je te maken dat je er niet vanuit mag gaan dat die bekend is met alle regels en dat je daar zelf verantwoordelijk voor bent.

          Een beunhaas zie meer als iemand die amateur/onkundig is en zich als professional/kundig voordoet.

          1. Ja, die zie ik. Het voelt ergens wel gek, als ik als organisatie dat neefje had gevraagd om te komen cateren (hij kan zo lekker koken thuis) dan zou ik toch héél boos worden als al het personeel salmonella krijgt van de eiersalade. Had ik dan beter na moeten denken of had ik dat toch de kok mogen verwijten, handen wassen en opletten met rauw vlees en eieren?

            1. Ik denk dat je eerst duidelijke afspraken moet maken als je een neefje van 12 laat koken voor jouw feestje. Maar een kind van 12 kan geen contracten tekenen dus dan weet je dat je al fout zit. Verder kun je als opdrachtgever ook iets verder kijken en vragen welke kwalificaties hij heeft. Meestal kijkt men echter niet zo ver en dat is het probleem. Kun je wel boos worden maar had je dat neefje van 12 wel in mogen huren? (Kinderarbeid?)

              Kun je wel zo makkelijk de verantwoording van jou af schuiven als je zelf beter had moeten weten bij het inhuren van werkkrachten? Als ik mijn auto uitleen aan een jochie van 12, is dat jochie dan verantwoordelijk als de auto over de kop gaat en total-loss raakt?

                1. Je praat dan over een arbeidsovereenkomst met een minderjarige en er zijn wetten tegen kinderarbeid, he? Vanaf 16 kunnen ze als werknemer zelfstandig aan het werk maar voor jongere kinderen is toestemming van de ouders nodig. En dan zijn het werknemers en dus niet verantwoordelijk voor de fouten die ze maken. Hooguit dat ze ontslagen kunnen worden…

                  De andere mogelijkheid is dat het kind als een ZZP’er wordt ingehuurd. Alleen, beneden de 18 kun je niet je eigen bedrijf starten zonder toestemming van de ouders. Bij minderjarigen kun je het kind sowieso niet aansprakelijk stellen maar moet je de ouders aansprakelijk stellen. En die ouders gaan natuurlijk niet toegeven. De vraag is of professioneel web development past bij een minderjarige. Grote kans dat een rechter zal aangeven dat een kind dit soort werk niet kan doen zonder dat er een volwassene meekijkt. Dan hoop ik dat je een duidelijk contract met je neefje en zijn ouders hebt afgesloten en niet alles mondeling hebt geregeld. En als de “beloning” een kratje bier en 100 euro is dan zal de rechter het waarschijnlijk niet serieus nemen… Je krijgt waar je voor betaalt. Op zijn best kun je dat geld weer terugeisen. Lekker, 100 euro terug op een boete van 12.000 euro… 😀

                  Je sluit dus een overeenkomst met een minderjarige en ik neem even aan dat de ouders hier niet expliciet toestemming voor geven. Dat een 12-jarige als web developer werkt is nog steeds niet normaal in Nederland. Ook niet op 16 of 17 jaar. Ze hebben misschien wel de kennis om code te kloppen maar niet van de vele regels qua beveiliging waar ze rekening mee moeten houden. De overeenkomst wordt dan gewoon nietig verklaard omdat jij beter had moeten weten dan een minderjarige inhuren voor je website…

                  Je kan het dan nog gooien op een onrechtmatige daad door het kind maar onder de 14 zijn ze beschermd en kan hen niets worden toegerekend. Ja, je kunt schade claimen als het kind iets doet, maar niet iets nalaat te doen. In deze kwestie heeft ket kind dan nagelaten om aan bescherming te denken, dus kansloos.

                  Kinderen van 14 en 15 zijn niet beschermd maar de ouders zijn dan niet aansprakelijk, tenzij ze wisten dat het kind iets fout deed. Onwaarschijnlijk. Moet je de schadeclaim dus bij het kind neerleggen, wat hij van zijn zakgeld mag betalen. Nou ja, de wettelijke aansprakelijkheidsverzekering kan worden aangesproken maar die komt met een batterij juristen en advocaten die jouw argumenten totaal de grond in stampen. Ook kansloos…

                  Boven de 16 kan hen een onrechtmatige daad worden aangerekend en dan is het argument dat ze hadden moeten weten dat SSL verplicht was. Dat ze dat niet inbouwen en jij daardoor schade hebt is dan door hen nalatig geweest en dus onrechtmatig. Maar je kunt de ouders dan niet meer voor de schade laten opdraaien en de WA verzekering van het kind, als dat er is, stampt jouw argumenten alsnog de grond in. Ook vrij kansloos.

                  Het verschil bij “Kinderen kopen een huis” is dat de kinderen niet een huis kopen, maar alleen beslissen welk huis hun ouders moeten kopen. De ouders geven dan aan de programmamakers een volmacht de keuze van hun kinderen te accepteren. De kinderen tekenen alleen met toestemming van de ouders een contract om op TV te komen. Dat de kinderen een koopcontract tekenen is daarbij meer ceremonieel want dat staat leuk op TV.

  3. Het verbaast mij dat de site 11 maanden zonder certificaat werkte, blijkbaar zonder dat een van de patiënten de orthodontist op de gebrekkige beveiliging wees. Ik ben zelf ooit eens tegen zo’n website van een behandelaar aangelopen. Ik heb toen de behandelaar uitgelegd wat het probleem was en gezegd dat ik vond dat dit voor het einde van de week veranderd moest zijn. Ook uitgelegd dat de AP en het medisch tuchtcollege hier niet vrolijk van worden. Resultaat: de behandelaar was blij wat geleerd te hebben en volgende ochtend zat er een slotje op.

    1. Het verbaast mij dat de site 11 maanden zonder certificaat werkte, blijkbaar zonder dat een van de patiënten de orthodontist op de gebrekkige beveiliging wees.

      Dat zou me verbazen, aangezien de AP verlangt dat je als betrokkene eerst een klacht indient bij de verantwoordelijke:

      Heeft u uw klacht al ingediend bij de organisatie waarover uw klacht gaat? De AP gaat pas met uw klacht aan de slag als u de klacht eerst schriftelijk heeft ingediend bij de organisatie zelf. En u het bewijs daarvan bij de AP heeft aangeleverd.
      Mogelijk heeft iemand de orthodontist er wel op gewezen, maar is daar niets mee gedaan.

  4. HTTPS is ondertussen zo vanzelfsprekend dat ik het in ieder geval standaard instel bij alles wat ik bouw. Maar er zijn volgens mij nog genoeg webbouwers die geen verstand van zaken hebben en ooit eens iets met WordPress en PHP hebben gedaan en dan even snel voor een vriend een site in elkaar hacken die een beetje leuk oogt en zorgt dat klanten zich kunnen inschrijven. Zonder HTTPS natuurlijk, want dat is voor dat soort ontwikkelaars nog veel te moeilijk.

    Je moet namelijk ook ooit van Let’s Encrypt gehoord hebben en dat is niet altijd het geval.

    Probleem bij Let’s Encrypt is dat je het certificaat ook regelmatig moet laten verversen en dat betekent weer het gebruik van een scriptje dat je b.v. iedere week even uitvoert op je server. Heb ik weer Certify The Web voor op mijn windows-bak maar dat kost geld als je er meerdere sites op host!

    Lastiger wordt het als de site draait op een shared host want dat is lekker goedkoop (en vaak onveilig!) maar heeft wel een nadeel. Niet alleen deel je dan een server met honderden andere sites van andere gebruikers en bedrijven maar vaak ben je ook beperkt in wat je op zo’n host kan doen en even een scriptje draaien om een certificaat te verversen zit er meestal niet in. (Vaak moet je bij de host dan een SSL certificaat kopen!)

    Maar goed, als een website met privacy-gevoelige informatie op een shared host staat dan vind ik het ontbreken van SSL onbelangrijk. Want op zo’n host is het theoretisch mogelijk dat iedereen toegang tot de data kan krijgen indien de host niet alles goed afschermt! Ik vraag mij dan ook af in hoeverre de host dan mede verantwoordelijk kan zijn voor het ontbreken van de beveiliging? Had de host moeten waarschuwen dat er geen privacy-gevoelige gegevens mee verwerkt mogen worden?

    Vraag mij spontaan af of Wix de boete had mogen betalen als de site op Wix was aangemaakt en Wix geen SSL aanbood. Er zijn veel van dergelijke bouwsites en lang niet allen ondersteunen SSL. Moeten die hun gebruikers voorlichten hierover?

      1. Ja en nee. Op dit moment is het vrijwel standaard maar in 2019 was SSL nog niet een onderdeel bij shared hosting. Dat heeft ook te maken met de moderne browsers die tegenwoordig standaard de HTTPS site proberen te laden en de HTTP als onveilig aanmerken. Dat begon zo rond 2018 en is nu de standaard aan het worden. En je moet de SSL dan natuurlijk wel aan zetten op je site, want ik weet niet of dat overal standaard gebeurt…

        1. Bij mijn hoster gratis https voor alle klanten sinds april 2017. Daarvoor had ik een betaald certificaat van 10-15 euro/jaar.

          Https is volop opgekomen na het stoppen van de ondersteuning van windows XP in april 2014. Als je een website maakt voor geld, is een basis certificaat echt geen kost, ook niet in 2015.

          Ik heb geen enkele compassie met zo’n prutsers. Als dienstverlener moet je de minimum eisen in je sector volgen en weten wat je niet kan/wil doen.

          1. Leuk voor jou en jouw host, maar dat geldt niet overal. Sowieso maar de vraag waar deze orthodontist zijn website liet hosten maar ook dat was mogelijk door de webbouwer uitgekozen. Voor dezelfde prijs had die orthodontist gewoon een simpele NAS staan met ingebouwde web server functies waar dus geen HTTPS op ondersteund wordt of standaard uit staat.

            Een orthodontist zal niet veel kennis hebben van websites, volgens mij. En volgens mij zullen ze ook niet snel veel geld uitgeven aan zo’n website en een professionele webbouwer kost al snel veel geld terwijl het neefje van je vriendin het mogelijk doet voor 50 euro en een kratje bier… Of iemand in India of Dubai die het voor 75 euro helemaal in orde maakt voor jou.

            Feit is dat er veel prutsers actief zijn die zich web developer noemen omdat ze een beetje met PHP hebben gedaan. Ik ben veel van die prutsers al tegengekomen die gewoon totaal niet op de hoogte waren van de mogelijkheden, maar alleen een trucje hadden geleerd en dit bleven herhalen… En aan mij de eer om hun rotzooi op te ruimen en een deugdelijke site neer te zetten. 🙂 (Hey, daar verdien ik aan!)

            Probleem is dat er steeds veel mensen net beginnen aan web development en dan vooral door zelfstudie. Zie je soms van die prutsers hele websites maken met een Android-mobieltje en veel geduld en maar vragen waarom iets niet werkt terwijl ze overal via copy/paste hun code halen. Probleem is dat deze mensen nog nooit hebben gehoord van wat je wel en niet kan. Probleem zie je ook bij auto’s waarbij soms een jochie van 12 gewoon gaat “spelen” met de auto van zijn ouders en vervolgens over de kop slaat. Lastig is dan dat ze ook nog eens minderjarig zijn en dus niet zelf verantwoordelijk gehouden kunnen worden. Een webbouwer van 17 of jonger kun je dan ook moeilijk verantwoordelijk houden voor de schade. Dat kan je namelijk niet contractueel afspreken omdat ze niet zomaar contracten kunnen aangaan…

            Dus de zaak is enorm interessant omdat we niet weten waar het werd gehost en wie het heeft gebouwd. En of er zelfs een contract was met de webbouwer of dat het alleen een vriendendienst was…

  5. Gelukkig kun je ook gewoon telefonisch een afspraak maken. Oh wacht! Ja, dat LetsEncryptcertificaat had er op moeten zitten. Nee, het is geen gapend gat. De telefoon is dat net zo zeer. Rest mij de vraag wat een ortho met je BSN moet.

    1. BSN is noodzakelijk omdat het hier om de zorg gaat en zorgverleners zijn verplicht een BSN te registreren van hun patiënten. Dat komt omdat medische gegevens dan centraal kunnen worden uitgewisseld tussen de diverse zorgverleners. Je huisarts kan dan zien hoeveel gaatjes je in je gebit hebt en je apotheek kan je tandarts dan inlichten over de bloedverdunners die je gebruikt.

      Overigens is het gebruik van Let’s Encrypt nog niet zo eenvoudig omdat deze regelmatig moet worden vernieuwd. (Iedere 90 dagen!) Dat moet dan weer via een script op je server en daarvoor heb je dan weer extra rechten op je server nodig. Zeker onder Windows is dit nog wel een uitdaging omdat de meeste ontwikkelaars die met Let’s Encrypt werken veelal onder Linux werken. Je kunt b.v. de CertBot van EFF gebruiken, alleen ondersteunt deze dus geen Windows. En toegang via SSH tot je server met een SUDO opdracht is vaak ook niet mogelijk. Daar zie je overigens ook een mooi lijstje van hosts die waarschijnlijk geen HTTPS ondersteunen!

      1. Dat BSN-nummer staat dan toch hoogstwaarschijnlijk al geregistreerd in je dossier lijkt me? Het is natuurlijk onnodig risico, als je bij elke nieuwe zorgverlener opnieuw je BSN zou moeten opgeven. Het eenmalig tonen van je ID bij een eerste bezoek lijkt me veiliger en meer dan voldoende om aan te tonen dat het om jou gaat.

        Let’s encrypt is super eenvoudig. Je hebt vanaf € 7,-/mnd een VPS met root toegang. Verder zijn er talloze hosting providers die via webmin of iets dergelijks ook let’s encrypt aanbieden. Als je als webontwikkelaar Let’s encrypt ingewikkeld vind, dan moet je eens serieus gaan nadenken of je niet iets anders zou moeten gaan doen.

        Neemt niet weg dat de Ortho in dit verhaal waarschijnlijk onwetend is. Ik vind de straf daarom belachelijk hoog. Er ligt wat mij betreft ook verantwoordelijkheid bij de gebruiker van het formulier die toch echt een waarschuwing in zijn browser krijgt dat de pagina niet versleuteld is.

        1. Wettelijk moet bij ieder patiëntcontact het bsn worden uitgewisseld om vast te stellen dat je echt de juiste patiënt voor je hebt. Dus ook bij vervolgafspraken, je moet en zal met het bsn nagaan dat dit echt de juiste De Vries is. Dat je het met geboortedatum en 06-nummer ook prima kan, is juridisch niet relevant.

          1. Maar…. dat gebeurt dus echt nooit. Ik heb echt nog nooit mijn paspoort moeten laten zien bij tandarts of huisarts, na mijn eerste bezoek. Bovendien kan ik in zo’n webformulier elk willekeurig BSN invullen. Dat lijkt me dus zeker niet voldoende om te bepalen of het om de juiste de Vries gaat. Dan is het tonen van een ID bij het bezoek dan toch veel beter?

            1. Het idee is dat ze met jouw bsn én naam controleren en daarna de afspraak noteren, gekoppeld aan jouw dossier. Ik weet dat er veel goed vertrouwen in de procedure aan de balie zit, maar als je een systeem gaat bouwen dan is “ach dat trekt Jantien wel recht, die kent haar pappenheimers” geen rechtvaardiging meer. Dan moet het er gewoon in. Ja, dat is voor de bühne dus…

        2. Een aanmeldformulier lijkt me specifiek bedoeld voor nieuwe patiënten. Hiervan is dus zeer waarschijnlijk nog geen dossier aanwezig. De AVG is m.i. vrij duidelijk wie er verantwoordelijk is voor de verwerking van persoonsgegevens (namelijk de verwerkingsverantwoordelijke).

  6. Maar. De orthodontist is toch verantwoordelijk voor de verwerking van de data? En deze heeft vast te leggen in een overeenkomst dat de verwerking veilig gebeurt en zich ervan te verwittigen dat de ontwikkelaar een omgeving biedt die veilig omgaat met de gegevens van de orthodontist, te toetsen middels een dpia?

    1. Dat is zeker zo, hoewel ik twijfel of een DPIA echt nodig is gezien het hier niet om een verwerking met hoog risico gaat. Wel bijzondere persoonsgegevens, maar dat is niet hetzelfde. Maar je kunt als verwerkingsverantwoordelijke prima de schade door een gebrekkige beveiliging verhalen op de verwerker.

      Je raakt wel aan een teer punt: volgens mij is het inderdaad zo dat de verantwoordelijke actief moet nagaan of de verwerker het goed doen. In het contract zetten “Verwerker garandeert AVG compliance” en dan achterover zitten is volgens mij een AVG schending voor de verantwoordelijke. Desondanks is dit de praktijk, vaak met het argument “de verwerker heeft er meer verstand van”. Volgens mij mag dat dus niet, erop vertrouwen dat de verwerker er verstand van heeft.

      1. Verder vraag ik me af of in dit geval het wel draait om verantwoordelijheden van verwerker en verantwoordelijke onder de AVG.

        Het gaat er meer om, in mijn optiek, dat de orthodontist een ondermaatse website gekocht heeft. Dat is de oorzaak van de problemen, en heeft verder niets te maken met wie de verwerker is. In dit geval is dat toevallig ook de websitebouwer (dat lijkt toch het geval te zijn) maar het zou net zo goed een derde partij kunnen zijn of de orthodontist zelf.

        1. Klopt, de webbouwer is natuurlijk geen verwerker. Als ie – zoals vaker bij het mkb – bouwt én de hosting doet dan is ie vanwege dat laatste wel verwerker, maar dat zijn twee aparte petten. Ik maakte dit uitstapje omdat ik het vaak zie gebeuren. De redenering gaat echter net zo goed op als je zegt “de softwareleverancier” of “de ontwikkelaar”. Je mag als verantwoordelijke nooit vertrouwen op contractuele toezeggingen, je moet controleren.

  7. Stel het datalek was mogelijk in papieren vorm (dossiers) doordat de aannemer een onveilig slot had geplaatst. Zou je die dan aansprakelijk kunnen stellen? Ik twijfel. In de bouw heb je allerlei gecertificeerde dienstverleners. Voor elektra, gas, maar ook sloten… Als je als klant kiest voor een niet gecertificeerde installateur, is dat voor eigen risico… Meestal wijst je verzekeraar je daar wel op. In dit geval de AVG… Ik denk dat je als dienstverlener in de zorg ook wel een soort plicht hebt je te verdiepen in wie een geschikte partij is voor je ict klus…

  8. Een veel wrzenlijker vraag is of de AP wel bevoegd is om boets over technische realisaties uit te gaan delen. Nergens in GDPR staat bemoemd dat dit onder een datalek of als taak bij de toezichthouder hoort voor GDPR. Een wet veranderen met een eigen uitleg van definiries of misbruik van vertalingen is niet goed.

    1. Voor mij is dat geen vraag. De AP is zeer zeker bevoegd om te oordelen of een verwerkingsverantwoordelijke adequate beveiliging (art. 32 AVG) heeft toegepast. In dit geval sluit de AP ook aan bij de in de zorg verplichte NEN norm, die gewoon https dwingend voorschrijft. De stap om dan te zeggen “je beveiliging is niet adequaat als je de in jouw branche verplichte NEN norm niet volgt” is voor mij triviaal. Waarom vind jij dit in hemelsnaam ‘misbruik’?

      1. Een norm beschrijft een gestandaardiseerde manier om handelingen uit te voeren, zodat de resultataten voldoen aan zekere kwaliteitseisen. Over het algemeen is volgen van een norm een contractuele afspraak.

        In dit geval is de norm opgenomen in een wet, en het volgen daarvan voor iedereen verplicht.

        Wat raar is, is als de wet waarin die norm verplicht wordt gesteld wordt gebroken (zoals hier het geval lijkt te zijn, in dit geval de Wet aanvullende bepalingen verwerking persoonsgegevens in de zorg), dat er dan een sanctie volgt op basis van de AVG. Onder de AVG is de norm echter niet verplicht.

        Als de zorgverlener de norm niet gevolgd heeft (en dit contractueel opgelegd heeft aan de websitebouwer) dan moet de zorgverlener op basis van die wet vervolgd worden, en de in die wet voorziene straf opgelegd krijgen, niet op basis van de AVG!

        Details misschien, maar juridisch klopt het volgens mij niet om een AVG inbreuk vast te stellen en sanctioneren op basis van een verplichting die volgt uit een andere wet.

          1. De AP kan alleen boetes opleggen op grond van de AVG, dus de boete is voor het niet-naleven van artikel 32 AVG.

            De AP moet de boete motiveren en doet dat door te zeggen dat het niet volgen van een in jouw branch verplichte norm niet adequaat is. Adequaatheid is immers iets dat je vaststelt per verwerkingsverantwoordelijke. Wat voor een kleine webwinkel met breibenodigdheden adequaat is, kan zwaar onder de maat zijn voor de personeelsadministratie van de Shell of de cliëntdossiers van een Big Four accountantskantoor, toch?

            Het is volgens mij niet raar om bij de invulling van een norm te kijken naar wat in de branch geldt. Het hoeft daarbij niet eens een wet te zijn. Neem een webshop die het Thuiswinkel Waarborg certificaat heeft. Die is dan verplicht om SSL te hebben, dat staat in de certificeringseisen. Als de AP dan die webshop betrapt op geen SSL, dan kan de AP volgens mij prima zeggen “overtreding artikel 32, want u heeft middels de certificering erkend dat zonder SSL inadequaat zou zijn voor u”.

            1. De AP moet de boete motiveren en doet dat door te zeggen dat het niet volgen van een in jouw branch verplichte norm niet adequaat is.

              Maar dan zou de orthodontist dubbel gestraft kunnen worden voor hetzelfde vergrijp. Eenmaal omdat hij zich niet aan de Wet aanvullende bepalingen etc heeft gehouden, en dan nog eens op basis van de AVG.

              De AP kan voor adequaat best aansluiten bij wat gebruikelijk is in de branche, maar dan had de AP eigenlijk, om netjes te zijn, in zijn overwegingen moeten stellen dat die norm verplicht is en dat daarom wordt aangenomen dat het volgen daarvan gebruikelijk is. De maatstaf waartegen adequaat moet worden afgewogen is wat gebruikelijk is, niet wat wettelijk verplicht is (maar misschien door niemand gevolgd wordt).

              Neem een webshop die het Thuiswinkel Waarborg certificaat heeft. Die is dan verplicht om SSL te hebben, dat staat in de certificeringseisen. Als de AP dan die webshop betrapt op geen SSL, dan kan de AP volgens mij prima zeggen “overtreding artikel 32, want u heeft middels de certificering erkend dat zonder SSL inadequaat zou zijn voor u

              Dat ben ik dus absoluut niet met je eens. Dat is een commercieel certificaat, en niet voldoen aan de voorwaarden is een zaak tussen de de webwinkel en de certificerende organisatie, van niemand anders.

              Daarbij speelt ook dat normen (tenzij ze natuurlijk in de wet staan) bedoeld zijn om te verzekeren dat niet-specialisten aan bepaalde kwaliteitseisen voldoen. Specialisten voldoen, uit hoofde van hun ‘specialist-zijn’, sowieso aan die bepaalde kwaliteitseisen, zij kunnen inschatten wanneer zij de norm niet hoeven te volgen en toch kwalitatief goede resultaten kunnen leveren.

              Een IT specialist van die webwinkel heeft dus de vrijheid om zich niet aan de betreffende norm te houden. Hij moet de redelijkheid van afwijken van de norm dan natuurlijk wel kunnen verantwoorden als de resultaten toch niet zo goed zijn als ze zouden moeten zijn.

              Voldoen aan een norm is een garantie dat het resultaat voldoende goed is, maar het omgekeerde is niet het geval: Afwijken van een norm is op zich geen aanwijzing dat het resultaat onvoldoende goed is.

              1. De AP kan voor adequaat best aansluiten bij wat gebruikelijk is in de branche, maar dan had de AP eigenlijk, om netjes te zijn, in zijn overwegingen moeten stellen dat die norm verplicht is en dat daarom wordt aangenomen dat het volgen daarvan gebruikelijk is. De maatstaf waartegen adequaat moet worden afgewogen is wat gebruikelijk is, niet wat wettelijk verplicht is (maar misschien door niemand gevolgd wordt).

                Dat stáát toch ook in de overwegingen bij de boete?

  9. Een boete van 12000. Is dat nou proportioneel gezien de mogelijke lekken die het creëert? Soortgelijk: de boete voor de PVV voor het vergeten van BCC en het niet melden ervan. Allebei gevalletjes “mag niet”, naar een nulletje minder icm verhoging bij recidivisme lijkt mij redelijker. Alhoewel dit soort incidenten natuurlijk wel een geldgenererende en redelijk effectieve publiciteitscampagne zijn over de niet altijd anonieme rug van de overtreder.zelfs over de virale component is nagedacht.

    1. Nee, mee eens. Daar dit lek ook Burger Service Nummer kon lekken vind ik de boete eigenlijk nog best laag! De boete moet redelijk proportioneel zijn op basis van het soort data dat werd gelekt, de hoeveelheid data en hoe lang het lek heeft bestaan. Plus de eenvoud van de maatregelen die men had kunnen nemen om dit te voorkomen…

      Het AP meldt ook dat er geen boete-verlagende factoren waren. De schuld werd neergelegd bij de webbouwer en er zou aan een nieuwe site gewerkt worden waarbij ook gewoon geen SSL zou zijn, want meneer “wist daar niets vanaf”…

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.