[Artikel] Wetswijzing meldplicht datalekken en verhoging boetes per 01-2016

[Christine]

...maar het willens wetens niet melden van een lek waarvan je kunt weten dat het problemen op kan leveren lijkt me sowieso wel een onrechtmatige daad indien er door jou nalaten schade ontstaat die anders voorkomen of beperkt had kunnen worden

 

Ik heb slechte ervaringen met het melden van ernstige datalekken bij bedrijven. Volgens het scenario

- je vindt een ernstig lek in de webmail van een provider

- je meldt dat keurig bij die provider

- je krijgt een brief van de advocaat van de provider die je van hacking beschuldigt

 

(gelukkig een minderheid van providers, de meeste sturen een bedankmailtje voor het melden)

 

 

[Christine]

2) Wat is het verschil tussen een datalek en 'lek geprikt worden' door een ander (zoals een hacker)?

 

Dat is het zelfde. Een datalek is een mogelijkheid voor een hacker om je systeem binnen te dringen. De verantwoordelijkheid voor het lek hoeft niet bij de eigenaar van het te hacken bedrijf te liggen. Het kan zijn dat je software gebruikt die als veilig te boek staat en door miljoenen servers wordt gebruikt, en die toch een lek bevat. Dat is wel 's gebeurd met openSSL. Iedereen heeft dat, of je het weet of niet, en toch was het lek.

 

 

[RT....]

Ik ben voor de zekerheid ook maar in de stukken gedoken. Net als Christine word ik er geen wijs uit, het spijt me. Zo worstel ik met vragen als:

 

1) Wat is nu precies volgens de wet een 'datalek'?

Zie artikel 13 Wbp

 

2) Wat is het verschil tussen een datalek en 'lek geprikt worden' door een ander (zoals een hacker)?

geen

 

3) Als ik een (mogelijk) lek ontdek, zeg maar een 'bugje' uit mijn site haal (wat ik wekelijks doe), moet ik dat melden?

Artikel 34a

 

1. De verantwoordelijke stelt het College onverwijld in kennis van een inbreuk op de beveiliging, bedoeld in artikel 13, die leidt tot de aanzienlijke kans op ernstige nadelige gevolgen dan wel ernstige nadelige gevolgen heeft voor de bescherming van persoonsgegevens.

 

Nee dus.

 

4) Hoe moet ik dat melden, moet ik compleet logboek met wijzigingen in mijn site gaan bijhouden en wekelijks naar de overheid mailen?

nee hoor

 

5) Is degene die mijn site aanvalt (de hacker) niet de gene die bestraft moet worden?

Ook. Maar als je iemand neergeschoten ziet worden, dan laat je 'm ook niet doodbloeden ;)

 

6) Hoe toon ik juridisch aan dat ik voldoende heb gedaan om mijn site te beveiligen?

Hetgeen doen wat mogelijk is gelet op de omstandigheden en de te beschermen data etc... Zie ook de Klederluik-criteria

 

7) Als ik een 'lek' op tijd ontdek (en er dus nog niks mis gegaan is) en ik fix het lek, waarom moet ik dat toch melden?

Als het ernstige nadelige gevolgen heeft voor de bescherming van persoonsgegevens, dan meld je het.

 

 

[Ab Bauer]

RT ,

Dank voor de uitgebreide antwoorden op mijn vragen. Het wordt me iets duidelijker, maar veel dingen lijken me toch in tegenspraak. Zo geef je als antwoord op mijn vraag 3) dat ik een (mogelijk) lek niet hoef te melden maar zeg je bij vraag 7) dat ik het weer wél moet melden?

 

Het grappige is dat ik vroeg om een uitleg in 'gewone mensen' taal, maar die is blijkbaar niet te geven.

Leuk om te lezen over een kelderluik uit 1961, maar liever had ik gewoon een eenvoudige handleiding waar ik me aan moet houden om geen gedoe te krijgen, zodat ik verder kan met ondernemen in plaats van dit soort (naar mijn idee) geneuzel.

 

[RT....]

Volgens mij staat er gewoon in normale mensentaal bij zowel vraag 3 als 7: indien dat (lek) ernstige gevolgen kan hebben.

 

Waarschijnlijk niet dus als t gaat om 'een wekelijks bugje'

[Ab Bauer]

indien dat (lek) ernstige gevolgen kan hebben.

En wie gaat dat beoordelen? Ikzelf? Dan zeg ik dat het allemaal wel mee viel.

Iets met slapende honden en zo...

 

Bovendien, als ik mijn code heb aangepast, hoe gaat de Overheid bewijzen dat ik iets niet heb doorgeven? De oude code (met het lek) heb ik immers overschreven. Gaat de Overheid back-ups of zo opvragen van mijn oude versies van de site? Vandaar mijn vraag of ik een log-boek voor de Overheid moet gaan bijhouden met alle stukjes code die ik heb aangepast.

 

Het punt is dat beveiliging een doorlopend kat en muis spel is tussen site eigenaren en kwaadwillenden. Dat er wekelijks tips voorbij komen om je site te verbeteren lijkt mij niet zo vreemd, de updates en patches vliegen je om de oren. Als ik als developer een stukje code zie wat volgens mij beter kan, dan fix ik dat meteen.

 

Nu moet ik me bij alle veranderingen in de code gaan afvragen of ik hiermee iets wat niet gebeurd is (maar wel had kúnnen gebeuren) moet gaan melden aan een organisatie van de Overheid.

 

Ben ik nou de enige die het kafkaesque hier van in ziet?

 

[Norbert Bakker]

Ben ik nou de enige die het Kafkaesque hier van in ziet?

Nee, iedere wettelijke meldplicht is bewust Kafkaesk gemaakt. Dat is nu juist de bedoeling!

 

Het (tijdig) melden van ernstige lekken/inbreuken moet minder neerwaarts risico (boetes, privaat- en strafrechtelijke vervolging) opleveren dan de natuurlijke neiging om het niet te melden en in de doofpot te stoppen.

 

Leuk om te lezen over een kelderluik uit 1961, maar liever had ik gewoon een eenvoudige handleiding waar ik me aan moet houden om geen gedoe te krijgen

Welkom in de complexe Nederlandse samenleving waarin iedereen wordt geacht de wet te kennen, en de ongeschreven rechtsplicht.

 

Het Kelderluik-arrest vind ik in deze de discusse overigens zeer raak gevonden: het pakt namelijk de essentie : iemand laat een luik (of een lek ) open terwijl hij /zij er rekening mee had moeten houden dat dat problemen op kon leveren.

 

Concreet voorbeeld:

Een e-commerce bedrijf draait op een Open source CMS ("met wel 75 miljoen gebruikers die het volgens Elvis niet mis kunnen hebben") waarvan al sinds begin 2015 bekend is dat er een bepaalde ernstige kwestbaarheid is, en een patch beschikbaar is gesteld om die kwetsbaarheid op te lossen. Om wat voor reden dan ook verzuimd de IT afdeling van dit bedrijf om die patch te installeren en blijft de kwestbaarheid (onbewust) bestaan.

Enige tijd later pleegt een hacker via deze kwetsbaarheid een inbraak en steelt daarbij privacygevoelige informatie.

 

Voorheen werd dat met de mantel der liefde bedekt en hoorde je daar nooit wat van. Vanaf 2016 loopt dat bedrijf het risico dat er een boete van 8 ton opgelegd kan worden. Ook leuk voor de hacker: die kan het bedrijf daarmee leuk gaan afpersen voor hogere bedragen (betalen of ik ga lekken dat jullie een ongemeld lek hebben)

 

Doel van het geheel: hopelijk worden bedrijven zich veel meer bewust van de kwetsbaarheden en gaan ze daar pro-actiever mee om. Voorkomen in plaats van genezen

 

 

[Ab Bauer]

Een e-commerce bedrijf draait op een Open source CMS ("met wel 75 miljoen gebruikers die het volgens Elvis niet mis kunnen hebben") waarvan al sinds begin 2015 bekend is dat er een bepaalde ernstige kwestbaarheid is, en een patch beschikbaar is gesteld om die kwetsbaarheid op te lossen. Om wat voor reden dan ook verzuimd de IT afdeling van dit bedrijf om die patch te installeren en blijft de kwestbaarheid (onbewust) bestaan. Enige tijd later pleegt een hacker via deze kwetsbaarheid een inbraak en steelt daarbij privacygevoelige informatie.

Wahaha, geweldig Norbert, hoe je via deze band toch je punt scoort in de WordPress discussie!

De data risk verzekering keert zeker niet uit bij WordPress gebruik? :)

 

Maar in de praktijk zal de soep niet zo heet gegeten worden hoor, weet ik uit ervaring.

Zie de spam wetgeving, de opt-in op nieuwsbrieven en de cookie wetgeving.

Concreet: Je wacht als webshophouder gewoon af en kijkt welke collega website er de eerste waarschuwing of boete krijgt. Er zijn altijd mensen die het te bont maken en aan de hand van hoe die aangepakt worden zie je meteen tot hoe ver je kunt gaan.

 

 

[Christine]

Om wat voor reden dan ook verzuimd de IT afdeling van dit bedrijf om die patch te installeren en blijft de kwestbaarheid (onbewust) bestaan.

 

 

Dat is het probleem met data lekken. Niet dat ze er zijn, maar dat ze niet onmiddellijk verholpen worden.

[Norbert Bakker]

Wahaha, geweldig Norbert, hoe je via deze band toch je punt scoort in de WordPress discussie!

Klein speldenprikje Hans, ik kon het niet laten :)

 

Maar FF serieus: Mijn punt is dus niet dat WP onveilig is of zou zijn, maar dat bedrijven die WP gebruiken in combinatie met privacy gevoelige informatie niet risicobewust genoeg zijn. Dat geldt niet alleen voor de kleintjes, ook voor de groten

 

De data risk verzekering keert zeker niet uit bij WordPress gebruik? :)

Ik zie niet in waarom niet. Zolang je zorgt dat je systemen onderhouden zijn en alle bekende kwetsbaarheden getackeld. Dan heb je gewoon dekking voor schade door onbekende kwetsbaarheden of eigen (beoordelings)fouten. Er is immers een onzeker voorval en je hebt de voorzorgsmaatregelen getroffen die redelijkerwijs van je verwacht mogen worden

 

Wedervraag: als jij je voordeur 6 maanden lang wagenwijd open laat staan, en je alle aanwijzigingen van je buren dat de deur openstaat negeert, vind je het dan vreemd dat er vroeg of laat bij je wordt gestolen en dat jouw inboedelverzekeraar dan niet uitkeert?

Hier heb je dus niet de voorzorgsmaatregelen getroffen die men redelijkerwijs mag verwachten, en je zou zelf kunnen stellen dat er geen onzeker voorval is: net als onbeveiligde sites is een open voordeur een uitnodiging waar vroeg of laat een kwaadwillend iemand misbruik van maakt.

 

Maar in de praktijk zal de soep niet zo heet gegeten worden hoor, weet ik uit ervaring.

Zie de spam wetgeving, de opt-in op nieuwsbrieven en de cookie wetgeving.

Concreet: Je wacht als webshophouder gewoon af en kijkt welke collega website er de eerste waarschuwing of boete krijgt. Er zijn altijd mensen die het te bont maken en aan de hand van hoe die aangepakt worden zie je meteen tot hoe ver je kunt gaan.

 

Volgens mij zitten we nog steeds op totaal verschillende golflengtes. De verstandige webshophouder wacht juist niet af, maar gaat zorgen dat z'n risico- en securitybeleid op orde is, alle bekende kwetsbaarheden geinventariseerd en alle uitgevoerde werkzaamheden gedocumenteerd. En mocht er ondanks alle pro-actieve maatregelen toch een ernstig lek zijn als gevolg van een nog onbekende kwetsbaarheid, dan maakt de ondernemer daar melding van: op die manier krijg je geen waarschuwing en geen boete: je neemt immers de veiligheid van je klanten/consumenten serieus en hebt passende actie ondernomen om schade te voorkomen en te beperken.

 

[Christine]

Een beetje uitleg in een video van Brenno de Winter.

[Ab Bauer]

Aardig filmpje en Brenno de Winter is altijd ++, maar ik word er nauwelijks wijzer van.

 

Waar ik nog het meeste mee zit is het volgende: Het doel van de meeste hackers is om juist 'onopgemerkt' data te stelen volgens mij. Daardoor zal het in de meerderheid van de gevallen je niet eens opvallen dat je een lek hebt (gehad). Het lijkt dan alsof de 'onnozelen' geen boete krijgen omdat ze het nooit in de gaten hebben gehad dat ze een lek hadden. Terwijl de oplettende website beheerders, die het lek ontdekken, juist een boete krijgen als ze het niet melden.

 

Verder is beveiliging een continuüm. Van helemaal niks doen, updates negeren en 'admin-12345' als wachtwoord, tot aan alles hyper encrypted en een leger aan beveiligingsexperts in dienst hebben. Is er ergens een streep aan te geven? Een soort 'ondergrens' van maatregelen dat als je die hebt genomen je redelijkerwijs kunt aantonen dat je je beveiliging 'professioneel' op orde had?

 

Waar ligt de 'streep'?

[prinsrachid]

Is er ergens een streep aan te geven? Een soort 'ondergrens' van maatregelen dat als je die hebt genomen je redelijkerwijs kunt aantonen dat je je beveiliging 'professioneel' op orde had?

Waar ligt de 'streep'?

Ik denk persoonlijk dat die ongeveer hier liggen:

 

College bescherming persoonsgegevens (CBP): Richtsnoeren voor beveiliging van persoonsgegevens

 

Nationaal Cyber Security Centrum (NCSC): Richtlijnen voor webapplicaties, deel 1 & 2

[Ab Bauer]

Dank voor de prima links, hier kan ik wat mee.

 

De documenten staan vol waardevolle informatie, alleen is het jammer dat er ook weer eindeloos wordt doorverwezen, naar kamerstukken, richtlijnen en 'best-practices'. Uiteindelijk kom ik uit bij een "NEN-ISO/IEC 27001+C11:2014+C1:2014 nl" norm die je voor €156,48 kan downloaden.

 

Ik vraag me wel af wat we nu in de praktijk hiermee moeten. Hoewel het voor mij geen onbekend terrein is, zijn sommige zaken erg moeilijk te volgen. De gemiddelde webshop-eigenaar (niveau 'WordPress, met WooCommerce met iDeal plugin eraan') trekt dit echt niet.

 

Je zult dus als webshop-eigenaar een flinke investering moeten doen om een security expert hiervoor in te huren. En dan nog kan morgen weer een nieuwe zwakke plek in je software ontdekt worden.

 

Ik schat dat van de ongeveer 70.000 webshops in Nederland er minstens 50.000 zijn die de beveiliging niet op dit niveau kunnen krijgen.

 

Of deze webshops moeten verdwijnen heb ik verder geen oordeel over.

 

[Ab Bauer]

Ik ben nog even aan het doorlezen, met name over de SSL certificaten. Want daar is veel onduidelijkheid over. Volgens mij moet je als webshop alleen op het betaal gedeelte van je shop een SSL certificaat hebben. Op de rest van je site zie ik het nut niet, bovendien maakt het je site trager. Daar is je klant maar ook Google niet blij mee (hoewel er weer verhalen zijn dat SSL goed voor je ranking is).

 

Al met al begin ik aardig de hoop te verliezen dat we de strijd tegen de hackers ooit nog gaan winnen.

Iedereen staat er ook zo verschillend in. Je hebt de grote massa consumenten die privacy en security totaal niet belangrijk vinden. Voor mij als developer begint security een steeds groter deel van mijn werk te worden en ik zou liever interessantere dingen dingen doen. Dan heb je de security experts die echt weten hoe het zit. Angst zaaien voor lekken zorgt voor meer handel dus neem ik ze ook met een korreltje zout. Tenslotte de Overheid.. die is van goede wil maar loopt hopeloos achter en aan de hand van de externen (die hun eigen agenda hebben).

 

Grappig detail: Toen ik vanmorgen op een link naar cbpweb.nl klikte, kreeg ik de volgende alert in mijn browser (zie plaatje)

[prinsrachid]

Ik ben nog even aan het doorlezen, met name over de SSL certificaten. Want daar is veel onduidelijkheid over. Volgens mij moet je als webshop alleen op het betaal gedeelte van je shop een SSL certificaat hebben. Op de rest van je site zie ik het nut niet, bovendien maakt het je site trager. Daar is je klant maar ook Google niet blij mee (hoewel er weer verhalen zijn dat SSL goed voor je ranking is).

De 'vertraging' door SSL is volgens mij niet echt meer een issue. Computers zijn inmiddels zo snel, dat je van die ver- en ontsleuteling niet echt meer wat merkt. Althans, niet meer dan al die onderliggende bestanden (css, jquery, responsive zooi, etc) die moeten worden geladen.

 

Ik denk dat de conclusie "alleen bij een webshop" een beetje te kort door de bocht is. Persoonlijk interpreteer ik de grens zodanig dat je moet beveiligen zodra je met persoonlijke (e-mailadres, naam, plaats, etc) en/of beveilingsgegevens (passwords) aan de gang gaat. Er zijn ook best makkelijke en gratis tests voor.

 

Het feit dat er websites zijn waarbij je zonder encryptie je wachtwoord moet versturen, vind ik eigenlijk volstrekt onacceptabel. Ik had me al eens beklaagd over het gebrek aan een SSL-certificaat op deze website, maar ook landelijke ketens vertikken het soms gewoon. Zo kwam ik bijvoorbeeld laatst bijvoorbeeld nog The ReadShop tegen, mét webshop en zónder certificaat. Gewoon vreemd.

 

Verder denk ik eigenlijk dat ook de kosten die gemoeid zijn met het beveiligen een klein beetje mee mogen wegen in de beoordeling of het al dan niet laakbaar is om geen beveiliging op je website te hebben. Een SSL-certificaat kost tegenwoordig 9 euro ex. btw. Je kunt dat niet bepaald prohibitief voor je bedrijfsvoering noemen. Als een website niet minimaal zo'n SSL-certificaatje heeft, dan vind ik dat gewoon pure lamlendigheid.

 

Grappig detail: Toen ik vanmorgen op een link naar cbpweb.nl klikte, kreeg ik de volgende alert in mijn browser (zie plaatje)

Ja, ik kreeg ook zo'n foutmelding. En ik weet ook waar het mis is gegaan. Normaal vraag je een SSL-certificaat aan op 'https://www.website.nl'. Vervolgens is ook (vaak gratis) automatisch 'https://website.nl' ^{(zonder www.)} meebeveiligd. CBP blijkt alleen beveiliging te hebben aangevraagd voor 'https://website.nl'. En als je dat doet, krijg je er niet automatisch 'https://www.website.nl' bij... Dus als je handmatig 'https://www.website.nl' intypt, is dat deel niet beveiligd. Beetje een aanfluiting, maar goed. 8)

[Ab Bauer]

Als het SSL certificaat het enige was dan was er niks aan de hand. Of SSL overal op je site nodig is kun je om discussiëren, maar voor die paar tientjes moet je het zeker niet laten.

 

Het punt is dat als je goed de documenten van het CBP en vooral Nationaal Cyber Security Centrum leest die vol staan met echte 'high end' security issues en wat je daar tegen kan doen.

 

Mijn argument is dat als deze documenten echt de norm worden, de gemiddelde 'mom and pop' webshop dit absoluut niet voor elkaar krijgt. Je moet daar echt professionele kennis voor hebben. Ik hoop dat je dat toch met me eens bent.

 

Moet je voor de lol eens kijken op de website van de grootste organisatie voor webwinkels (Thuiswinkel.org).

Die zeggen alleen maar "neem contact op met uw webbouwer hierover".

 

Alsof we alle 50.000 'mom and pop' webshops voor 1 januari professioneel beveiligd kunnen krijgen.

De meeste webshops maken nauwelijks winst, dus hoe gaan die ooit de kosten van professioneel security advies opbrengen?

 

[Norbert Bakker]

Alsof we alle 50.000 'mom and pop' webshops voor 1 januari professioneel beveiligd kunnen krijgen.

De meeste webshops maken nauwelijks winst, dus hoe gaan die ooit de kosten van professioneel security advies opbrengen?

Niet, de meeste gaan verdwijnen.

 

Meest logische gevolg IMHO is dat die webshops vroeg of laat geen contract meer kunnen afsluiten met een bank of PSP als ze niet kunnen aantonen aan ( nader te bepalen) minimale veiligheidsnormen te voldoen.

[Ward van der Put]

Alsof we alle 50.000 'mom and pop' webshops voor 1 januari professioneel beveiligd kunnen krijgen.

De meeste webshops maken nauwelijks winst, dus hoe gaan die ooit de kosten van professioneel security advies opbrengen?

Zo'n 99% van die 50.000 webshops deelt hooguit 50 platforms, dus dan is de schade nog te overzien.

(Of in lijn met de eerdere discussies: WordPress veiliger maken zet meer zoden aan de dijk dan individuele WordPress-sites dichttimmeren.)

 

Mijn ervaring is dat de meeste professionele ontwikkelaars héél goed op de hoogte zijn van wat er nodig is voor een goede beveiliging. Er wordt alleen structureel en willens-en-wetens gekozen voor een compromis vanwege met name de kosten. Het SSL-certificaat is daarvan een schrijnend voorbeeld: zonder kun je niet veilig persoonsgegevens verwerken, maar er wordt toch op grote schaal op bespaard voor een paar tientjes per jaar...

 

Meest logische gevolg IMHO is dat die webshops vroeg of laat geen contract meer kunnen afsluiten met een bank of PSP als ze niet kunnen aantonen aan ( nader te bepalen) minimale veiligheidsnormen te voldoen.

Ja, dergelijke vormen van zelfregulering kennen we bijvoorbeeld al in de vorm van PCI DSS compliance (PDF) voor het verwerken van creditcardbetalingen.

 

 

[Hans v N]

Wat ik mis in deze discussie is enige vorm van proportionaliteit. Kan me geen topic herrineren waar men zo doorslaat dan in dit geval.

 

Dat grote (en kleinere) bedrijven met écht prive gevoelige informatie, denk aan de gezondheidszorg, het bank en verzekeringswezen enz hun veiligheid moeten opschroeven en bij falen daarvan moeten melden is een prima zaak. De hoge boetes moeten deze sectoren in beweging brengen.

 

Maar om dan een donderwolk met bliksem boven de kleine webshop te hangen gaat mij veel te ver. De wetgever krijgt weliswaar de mogelijkheid om (hoge) boetes op te leggen maar zal dat proportioneel (moeten) doen.

 

Als een hacker de klantgegevens van mijn WP webshop steelt dan heeft hij niet veel meer dan wat vroeger in het telefoonboek stond. Ik werk bewust niet met passwords. Ten eerste omdat dat de conversie negatief beïnvloedt maar zeker ook omdat ik die informatie, die gevoelig is omdat gebruikers heel vaak dezelfde passwords gebruiken, niet wil hebben.

 

Ik ben vooralsnog dus nergens bang voor. 8) Uiteraard zorg ik er wel voor dat ik alles doe om ook vrij ongevoelige informatie met zorg te behandelen door regelmatig up te daten en de veiligheid van de site te optimaliseren (zijn plugin's voor).

 

 

 

 

[RT....]

Als een hacker de klantgegevens van mijn WP webshop steelt dan heeft hij niet veel meer dan wat vroeger in het telefoonboek stond.

In het telefoonboek stond bij mijn adres niet wat ik op jouw webshop heb gekocht. Dat is niet zo boeiend als ik een fles powergel koop, maar wordt al vervelender als gekochte goederen iets...persoonlijker worden. ;)

 

Overigens is het helemaal niet nodig om moord en brand te schreeuwen. Dat je persoonsgegevens voldoende moest beschermen is niet nieuw. Dat je een lek moet melden is voor degene die geen elektronische communicatiediensten aanbieden wel nieuw. Maar is dat nou zo'n probleem?

 

Voordat het CBP een boete op kan leggen, moet ze bovendien eerst een bindende aanwijzing geven. In die aanwijzing staat dan welke wettelijke bepalingen zijn overtreden, en wat je kunt doen om de overtreding (gedeeltelijk) kunt herstellen.

Je moet het wel heeeel bont maken wil je een boete van 810.000 opgelegd krijgen.

 

 

 

 

 

[Ab Bauer]

Overigens is het helemaal niet nodig om moord en brand te schreeuwen. Dat je persoonsgegevens voldoende moest beschermen is niet nieuw. Dat je een lek moet melden is voor degene die geen elektronische communicatiediensten aanbieden wel nieuw. Maar is dat nou zo'n probleem?

 

Voordat het CBP een boete op kan leggen, moet ze bovendien eerst een bindende aanwijzing geven. In die aanwijzing staat dan welke wettelijke bepalingen zijn overtreden, en wat je kunt doen om de overtreding (gedeeltelijk) kunt herstellen.

Je moet het wel heeeel bont maken wil je een boete van 810.000 opgelegd krijgen.

Grappig hoe je dingen soms als een boemerang terug krijgt. Toen dit topic gepost werd was ik de eerste die zei dat het allemaal wel mee zou vallen. Daar kreeg ik toen op terug dat het dus niet allemaal wel meevalt. Persoonlijk denk ik toch wel dat het allemaal gaat meevallen. Nederland 'gedoogland'. Natuurlijk komen er eerst waarschuwingen en de eerste die een echte boete krijgt gaat moord en brand schreeuwen. Dan komen allemaal organisaties zoals Thuiswinkel.org te hulp en wordt het hele boetegebeuren afgezwakt.

Waar het mij om gaat is de onduidelijkheid. Ik heb niks tegen strenge regels maar ik wil dan wel precies weten wat die regels zijn en hoe de handhaving in de praktijk gaat werken.

 

 

.

[RT....]

Ik denk ook dat het wel mee zal vallen. Het is in ieder geval niet zo spannend als 'als ik gehackt word moet ik 810.000 boete betalen!'.

De regels zijn helder in die zin dat je hetgeen moet doen wat van jou verwacht kan worden in de gegeven omstandigheden. Je hoeft van je webshopje geen fort-knox te maken, maar je moet ook de voordeur niet wagenwijd open laten staan. Of een slot gebruiken dat 10 jaar geleden al met een paperclip open gefriemeld kon worden.

 

Of jíj in een specifiek geval je hebt gehouden aan de regels, en of je dan wel of niet boete-plichtig bent hangt van zóveel factoren af, dat al die gevallen niet concreet kunnen worden beschreven. Daarom is er gekozen voor een norm (vergelijk het met de norm voor een onrechtmatige daad).

[prinsrachid]

Als het SSL certificaat het enige was dan was er niks aan de hand. Of SSL overal op je site nodig is kun je om discussiëren, maar voor die paar tientjes moet je het zeker niet laten.

Ik ga even net doen of de beheerders van deze website deze en een andere draad met meer dan gemiddelde interesse hebben gevolgd en daar zelfs naar hebben gehandeld. Hulde!

[Ab Bauer]

Zijn we al wat verder dan de (concept) 'consultatieversie' van het 'richtsnoer'?

https://cbpweb.nl/sites/default/files/atoms/files/richtsnoeren_meldplicht_datalekken.pdf

 

Het was iets met soep niet zo heet gegeten en zo...