Wanneer moeten datalekken nu gemeld worden?

| AE 4486 | Privacy | 29 reacties

data-lek.pngVeel vragen krijg ik de laatste tijd over datalekken. Bedrijven zijn gehackt, meestal door goedwillende types die alleen melden dat er iets mis is, of mensen lezen dat hun data is gestolen en vragen zich af of ze iemand aansprakelijk kunnen stellen. Of, iets algemener, of ze niet überhaupt hadden moeten horen van een bedrijf dat daar persoonsgegevens zijn buitgemaakt.

Op dit moment is er maar één daadwerkelijk wettelijk geldende datalekmeldplicht. Als bij een telecomprovider (zoals KPN of Vodafone) een inbreuk op de beveiliging plaatsvindt, en dit “nadelige gevolgen” heeft voor de privacy van abonnees, dan moeten deze worden geïnformeerd over de inbreuk (art. 11.3a Telecomwet). Ook het Agentschap Telecom, de toezichthouder hier, moet worden geïnformeerd.

Voor andere bedrijven is er geen datalekmeldplicht. Er wordt wel eens gesteld dat ook de huidige Wet bescherming persoonsgegevens een datalekmeldplicht met zich meebrengt. Artikel 33 Wbp zegt namelijk dat je nadere toelichting op je verwerkingen moet geven om een “behoorlijke en zorgvuldige” verwerking te realiseren. En daar kan ook onder vallen dat je moet melden dat er iets misgegaan is. Maar dit is nog nooit getest.

De toekomstige Europese Privacyverordening zal een expliciete plicht bevatten. Als het lek “waarschijnlijk negatieve gevolgen” heeft voor de privacy van de betrokken personen, moet deze worden geïnformeerd. Ook de privacytoezichthouder moet op de hoogte worden gesteld. Wanneer dit van kracht wordt, is echter nog niet bekend.

Deze Europese datalekmeldplicht werd een beetje ondergesneeuwd door het eigen kabinetsvoorstel voor een meldplicht. Maar dat lijkt nu van de baan omdat de Privacyverordening hoe dan ook de enige privacywet gaat worden.

Wat ik in al die voorstellen mis, is een stevige sanctie. Ja, er wordt geschermd met boetes, maar is dat goed genoeg? Ik blijf erbij dat mijn idee om een gefixeerd schadebedrag in de wet te zetten, beter gaat werken. Als een persoonsgegeven 100 euro waard is, en een bestand met 10.000 adressen wordt gelekt, dan heb je 10.000 boze consumenten die via een massaclaim 1.000.000 euro kunnen eisen. En niet één toezichthouder die al of niet gaat optreden.

Arnoud

Deel dit artikel

  1. Is het bepalen of vaststellen van zo’n waarde niet extreem lastig? Zeker omdat dan ook de vraag is wat de waarde van een persoonsgegeven is, en omdat het privacy probleem hem vooral zit in de relatie tussen de waarden en niet de individuele waarden. Simpel voorbeeld: hier in Duitsland is de postcode niet zoveel waard (de postcode wijst een gebied ter grootte van enkele wijken aan). De combinatie met naam is al veel meer waard.

    (edit:) Vergelijk dit met de relatie tussen website, wachtwoord en username; daar heb je toch meer aan meestal. Of credit card nummer met de bijbehorende authenicatiegegevens.

  2. Nu even een speciale omstandigheid. Bedrijf X bouwt een web applicatie en plaatst deze in de Cloud. De applicatie wordt gebruikt door tientallen andere bedrijven (Y1, Y2, …, Yn) die deze gebruiken voor hun klanten-administratie. Nu wordt de Cloud gehacked en de volledige database wordt gejat. Bedrijf X zal straks alle bedrijven Yn moeten informeren over deze hack, maar wie is er vervolgens verantwoordelijk dat ook de klanten van de bedrijven Yn worden geinformeerd? Mag bedrijf X gebruik maken van de database om alle klanten rechtstreeks te waarschuwen over deze hack, of mag dat niet omdat deze gegevens vertrouwelijke informatie zijn van de bedrijven Yn?

    En dan nu nog een maatje complexer. Bedrijf X maakt een Cloud-oplossing en heeft diverse bedrijven Yn als partner. Deze partners zitten wereldwijd en stellen de applicatie in voor binnen hun gebied. (De Cloud-oplossing kan meerdere nationaliteiten ondersteunen, de partners bepalen welke nationaliteit ze beheren en stellen hun deel daarvoor in.) Deze partners verkopen weer licenties aan bedrijven Zm en deze bedrijven hebben zelf weer honderden klanten. Dit is een zeer complexe situatie maar toevallig werk ik momenteel aan een dergelijke toepassing. Waar liggen dan weer de verantwoordelijkheden? Want al die bedrijven en partners zitten allen op dezelfde Cloud-omgeving…

    • Dat is toch niet zo moeilijk. Ik kan me voorstellen dat het zo zal zijn: de klant die zijn gegevens in bewaring geeft bij een bedrijf, stelt het bedrijf aansprakelijk die zegt zorg te dragen voor de veiligheid van zijn/haar klantgegevens. Bedrijf X kan aangeklaagd worden door bedrijf Yn als het hun eigen persoonsgegevens betreft (dus bijv. personeelsgegevens), niet voor de gelekte klantgegevens.

      Bedrijf Yn kan aangeklaagd worden door de klanten. Bedrijf Yn heeft namelijk een plicht en moet ervoor zorgen dat zij zaken doet met een betrouwbare partner (ik vraag bijv. niet aan mijn neefje van 5 of hij mijn paspoort in beheer wil houden). Bedrijf Yn had bij het plaatsen van kritieke data ook de betreffende server zelf in beheer kunnen nemen. De keuze om dit niet te doen is aan Yn. Bedrijf X en bedrijf Yn zouden wel in een contract kunnen afspreken wat de consequenties zijn bij een toekomstig datalek en hoe de verdeling eruit gaat zien van de kosten die daaruit voortvloeien.

  3. @1

    Dat is waarom een vast bedrag in de wet zo’n goed idee is. Dat voorkomt dat benadeelden bij claims die waarde moeten gaan aantonen.

    Het zorgt er ook voor dat de schade door bedrijven niet meer te externaliseren valt. Nu is het zo dat juist omdat die schade zo moeilijk aan te tonen is, in de risico-afwegingen van bedrijven de schade aan benadeelden niet meetelt. De gedachte achter een vaste boete per “gegeven” is dat die sommetjes veranderen, en dus een economische aanmoediging zijn om privacy en beveiliging goed (of in ieder geval beter) te regelen.

  4. Een vaste boete is een slecht idee en zal niemand bewegen om beter met de data om te gaan.

    Een huismoeder met een kralen shopje die in 10 jaar tijd 1.000 klanten heeft bediend wordt gehacked. Zij moet dan 100k betalen?

    Een vaste boete is hetzelfde als een minimum straf in het strafrecht en gaat voorbij aan verzachtende omstandigheden.

    @Wim. Het is allemaal niet zo moeilijk. De gene die de data verzameld heeft is verantwoordelijk voor die data. Of deze vervolgens een claim in kunnen dienen bij hun lveranciers is een tweede maar niet heel relevant.

  5. Een huismoeder met een kralen shopje die in 10 jaar tijd 1.000 klanten heeft bediend wordt gehacked. Zij moet dan 100k betalen?

    Ik zie het probleem niet? In tegendeel, mevrouw denkt wel twee keer na over hoe zij haar gegevens beveiligt. Of, waarschijnlijker, zij legt dit risico neer bij de partij die haar website ontwikkelt, welke het op zijn beurt weer laat verzekeren. Bij dergelijke verzekeringen krijg je vervolgens wel strakke audits om het risico te ‘beperken’. Het is zo’n verzekeraar er vervolgens ook alles aan gelegen om dit te voorkomen.

  6. @5: Ik ben het met je eens. Echter voor bestaande kralenshopjes kan het een grote investering zijn om nu ineens een audit en een verzekering te laten doen. Voor nieuwe kralenshopjes zou het onderdeel van het startbudget worden. Maar goed, dat is dan pech?

    Een “kralen shopje” is trouwens een shopje dat van kralen is gemaakt, maar dat terzijde…

  7. @6 Matthijs, het wordt ook niet makkelijk gemaakt door het Engelse woord voor winkel te gebruiken. Desalniettemin heb je helemaal gelijk, en bedoelde ik dus een kralenshopje.

    Echter voor bestaande kralenshopjes kan het een grote investering zijn om nu ineens een audit en een verzekering te laten doen. Voor nieuwe kralenshopjes zou het onderdeel van het startbudget worden. Maar goed, dat is dan pech?

    Ik denk dat dat wel meevalt. Leveranciers van webshops zoals Magento sluiten deals met verzekeraars dat zij de codebase (wat 95% iedere Magentoshop is) certificeren oid, daarna valt een audit van de omliggende componenten wel mee. Daarnaast stelt een random shopje met duizend klanten voor de gemiddelde verzekeraar natuurlijk niet zo veel voor, dus die pakt gewoon het schaalvoordeel daar.

    Daarnaast, als die huisvrouw al tien jaar lang die shop heeft hoeft zij natuurlijk niet al haar klantgegevens in haar database te laten staan. Ze kan ook de facturen uitprinten en in een kluis leggen, om vervolgens alle oude gebruikers uit de webshop te verwijderen – dergelijke maatregelen zijn we niet gewend, maar ik denk dat we die nu wel eens moeten gaan overwegen.

    Daarnaast zal je meer SaaS-aanbieders krijgt die kant en klare webshops aanbieden welke dergelijke risico’s op zich nemen. Dat lijkt me ook een goed iets. Hoewel iedereen in staat gesteld moet kunnen worden imho om zijn eigen webshop te draaien, leert de praktijk van de afgelopen vijftien jaar dat dat gewoon niet veilig lukt/kan.

  8. Leuk, dus we moeten verplichte audits gaan doen en verzekeringen afsluiten waarvan de premie na een aantal incidenten compleet onbetaalbaar worden. De grote ketens kunnen blijven bestaan en de kleine middenstander is de pineut.

    Alle (sport) verenigingen moeten hun contributie verhogen om de juiste verzekeringen af te kunnen sluiten. Innovatie wordt compleet de nek omgedraaid omdat je bijna niet meer een kleine website kan maken zonder enorme risico’s te moeten nemen of dure verzekeringen af te sluiten.

    Natuurlijk moeten er sancties staan op het onzorgvuldig omgaan met gegevens maar automatische boetes (die ook nog naar de consument gaan) is vragen om een hoop narigheid en ongewenste bij effecten.

  9. Ik zie het verschil niet tussen automatische boetes naar de consument en automatische boetes naar een toezichthouder, behalve dat je de prikkel bij de markt legt om te handhaven.

    En waarom is dit anders dan de verplichte verzekering voor aansprakelijkheid voor fysieke schade? Moet ook elke sportvereniging afsluiten, net als elk bedrijf trouwens. En daardoor gaan mensen opletten wanneer anderen schade kunnen lijden.

  10. Daarnaast, als die huisvrouw al tien jaar lang die shop heeft hoeft zij natuurlijk niet al haar klantgegevens in haar database te laten staan. Ze kan ook de facturen uitprinten en in een kluis leggen, om vervolgens alle oude gebruikers uit de webshop te verwijderen – dergelijke maatregelen zijn we niet gewend, maar ik denk dat we die nu wel eens moeten gaan overwegen.

    Het is twijfelachtig of daarmee nog wel wordt voldaan aan de fiscale bewaarplicht. En los daarvan, wat doen we dan als er een inbraak is waarbij die kluis gestolen of opengebroken wordt? Of als er een woningoverval is waarbij ze de kluis open moet maken? De inbreker zal mogelijk gokken dat er geld in ligt.

    Ik vind een minimumboete een bijzonder slecht idee, omdat simpelweg elke redelijkheid en proportionaliteit daardoor vervalt. De schade die ik oploop doordat bekend is dat ik 2 jaar geleden een paar kralen heb gekocht, met naam en adres erbij, is minimaal. Het is niet hoe het hoort, maar ik zie niet hoe ik hier op enige manier last van krijg. Ik vind het dan niet proportioneel om met zulke minimale schade, een huisvrouw een faillissement in te duwen. Ik geloof niet dat de samenleving daar beter van wordt.

    Of, waarschijnlijker, zij legt dit risico neer bij de partij die haar website ontwikkelt, welke het op zijn beurt weer laat verzekeren. Bij dergelijke verzekeringen krijg je vervolgens wel strakke audits om het risico te ‘beperken’. Het is zo’n verzekeraar er vervolgens ook alles aan gelegen om dit te voorkomen.

    Als ik op dit moment een beroepsaansprakelijkheidsverzekering afsluit, verplicht die verzekering mij om de aansprakelijkheid af te schuiven voor zover mogelijk. De kralenshop kan dat risico dus niet op mij als webbouwer afschuiven, want dat mag ik niet accepteren van de verzekeraar.

    Mocht ik zelf als programmeur risico op gigantische schades lopen bij fout in de software (ook als er geen roekeloosheid of nalatigheid is), dan reken ik dat risico ook gewoon door aan de klant. Ik ga geen risico van € 100.000 lopen voor een webshopje van € 2000. Op het moment dat de risico’s zo hoog zijn, neem ik allerlei maatregelen om nog veel zekerder te zijn van de kwaliteit, maar dan kost het minstens € 20.000. Ook als ik het volledig zou kunnen verzekeren zouden de kosten omhoog gaan, want dit soort verzekeringen zijn erg duur.

    Ik denk over het geheel dus dat we met een dergelijke opzet de samenleving niet dienen. Kosten van software-ontwikkeling schieten omhoog en we jagen mensen een faillissement in door fouten die eigenlijk heel weinig schade hebben veroorzaakt.

    Daarmee wil ik niet zeggen dat er niet meer boetes moeten komen. Bij ernstigere gegevenslekken, bijvoorbeeld medische gegevens, is het wel aannemelijk dat ik er daadwerkelijk schade van ondervindt. Die gegevens horen ook veel beter (en duurder) beveiligd te zijn, en daar is een hoge boete al heel snel redelijk. Maar in het algemeen moet er altijd een redelijke afweging gemaakt worden aan de hand van de ernst van het lek en de redelijk aan te nemen schade voor de betrokken personen, en in hoeverre de gegevenshouder roekeloos of nalatig heeft gehandeld. De samenleving gaat er niet op vooruit als we zonder die afweging dergelijke boetes op gaan leggen.

  11. @Arnoud, het verschil tussen een automatische boete naar de consument toe en die naar de toezichthouder is dat er een prikkel bestaat om sites te hacken. Ik denk dat je op een willekeurige middag zo € 1.000 euro binnen kan slepen door je in te schrijven op forums met verouderde software, deze vervolgens hacken zodat de lijst met users bekend wordt en dan incasseren.

    Hier zou je zelfs botjes op los kunnen laten die dit geautomatiseerd voor je gaan doen.

    Daar buiten zijn dit soort risico’s enorm moeilijk te verzekeren of tegen enorme premies. Dit omdat de kans op schade enorm groot is en daarbij de schade ook nog eens heel groot is.

    Er zal altijd, een behoorlijke afweging gemaakt moeten worden over de ernst van het lek en de verwijtbaarheid ervan voordat er boetes komen.

  12. De geschetste scenario’s gaan ervan uit dat als het voorstel van Arnoud wordt aangenomen, de manier waarop ondernemers omgaan met persoonsgegevens hetzelfde blijft. Dat lijkt me dus niet zo waarschijnlijk. Zo komt er een einde aan de praktijk van het oneindig bewaren van persoonsgevens. Ondernemers gaan eerst nadenken of zij die geboortedatum eigenlijk wel nodig hebben. En natuurlijk wordt de software die gebruikt wordt voor de opslag door de branche een stuk beter onderzocht (beter dan ‘niet’, bedoel ik).

    Overigens voel ik er wel wat voor om het boetebedrag af te laten hangen van het soort gegevens dat men ‘lekt’.

  13. @NP: Maar dat kan nu toch ook al, met boetes van de toezichthouder?

    Natuurlijk zal altijd verwijtbaarheid/nalatigheid een rol spelen. Een boete opleggen voor een overmachtgebeurtenis is volstrekt ongepast. Het idee is dat je altijd eerst kijkt of er sprake is van verwijtbaar handelen. Zo niet, dan kun je de schade niet toerekenen aan de veroorzaker. En pas nadat het verwijtbaar is, kom je toe aan de vraag hoe hoog de schade is die moet worden vergoed (en eventueel compenseren met “eigen schuld” of redelijkheid en billijkheid).

    Het probleem zit hem in hoe hoog die schade is. Want als die kralenwinkel nu mijn adresgegevens lekt, kan ik niet bewijzen dat ik daardoor schade lijd. Ik kan niets, want zonder schade geen claim. Formeel-juridisch stel ik dus voor om een vermoeden van schade te introduceren, met een bedrag erop zodat we ergens kunnen beginnen. Het lijkt me prima om tegenbewijs toe te staan, en ook het idee van een safe harbor (“Niet aansprakelijk is hij die al het redelijke heeft gedaan om de gegevens te beschermen”) staat me wel aan.

  14. Of is het een indicatie dat we doorschieten? Een ip-adres is al een persoonsgegeven dus als er een webserver log op straat komt te liggen zou dat al tot de boetes kunnen leiden. Er zijn genoeg gratis statistiek scripts die dit openbaar tonen=> kassa!

    En zelfs N.A.W. gegevens zijn twijfelachtig voor mensen die gewoon in het telefoonboek staan. Wat is precies de schade daar door?. Scholen en verenigingen kunnen geen ledenlijsten meer maken omdat de kans dat dit gelekt wordt veel te groot is en dus tot schade vergoedingen kan leiden.

    Er moet dus altijd een goede afweging gemaakt worden over het soort gegevens en de ernst van het lek. Medische gegevens is absoluut een boete waard (en wat mij betreft een veelvoud van die € 100,- en direct naar de consument, maar je kan niet alles op 1 hoop gooien.

  15. @16: mijn advies aan de ondernemer: kies een betere statistieksite, of nog beter: neem een open source statistiek script dat ’s nachts door de Apache logs rent. Na één breed-gepubliceerde boete/schadevergoeding zullen een heleboel ondernemers zo’n overstap maken.

    Er zijn ook mensen die (om goede redenen) hun adres geheim willen houden. Wie gaat de verhuiskosten van het “blijf van mijn lijf”-huis vergoeden als een ondernemer dat lekt?

  16. @17: Alsof jij een pakketje onder je eigen naam naar een blijf van mijn lijf huis gaat sturen? Of de sportvereniging een adreswijziging stuurt die op de ledenlijst geplaatst mag worden?

    Het punt is, dat het ene lek het andere niet is. En alleen daarom al een automatische boete niet wenselijk is. Of vindt je echt dat een ledenlijst van een sportvereniging, of de klassenlijst niet meer kan?

  17. Of is het een indicatie dat we doorschieten? Een ip-adres is al een persoonsgegeven dus als er een webserver log op straat komt te liggen zou dat al tot de boetes kunnen leiden. Er zijn genoeg gratis statistiek scripts die dit openbaar tonen=> kassa!

    Als een dergelijke nieuwe wet bedrijven motiveert om hun web server logs te anonimiseren, lijkt me dat een prima ontwikkeling. En ja, ik vind dat als jij niet in staat bent dergelijke gegevens geheim te houden, je ze eigenlijk niet zou mogen verzamelen. En dat is te bereiken via een dergelijke boeteconstructie.

  18. Uiteraard kunnen we op alle lekken gewoon hoge boetes zetten. Datalekken zullen zeldzamer worden, mensen die toch data lekken zullen hard gestraft worden.

    Maar daarmee bereiken we ook andere effecten. Als de sportvereniging per ongeluk de een ledenlijst lekt, kunnen we zeggen: dat zijn 500 mensen, dus € 50.000 boete. Ik ga even uit van een boete door de toezichthouder. Wie gaat die boete dan betalen? Ik zie maar drie opties: of de sportvereniging gaat failliet, het wordt betaald uit reserves (waardoor andere plannen geschrapt moeten worden), of alle leden zullen geld in moeten leggen om de boete te betalen. Of we moeten het bestuur hoofdelijk aansprakelijk stellen. Maar zie dan nog maar eens nieuwe bestuursleden voor die club te vinden.

    De sportvereniging kan zich hiertegen indekken. Ze gebruiken uitsluitend zeer veilige software en maken uitgebreide procedures waarin absoluut gegarandeerd is dat deze situatie niet voor kan komen. Dat is geen probleem, er zijn al allerlei situaties waarin software vrijwel foutloos geschreven kan worden. Maar dat is wel heel duur. Wie gaat dat betalen? De leden van de sportvereniging, in hun contributie.

    Het verhaal werkt ongeveer hetzelfde voor een school. Kort gezegd, het kan allemaal. Hard straffen bij een foutje, heel veilige software en hele strikte procedures. Maar bij wie komen die kosten uiteindelijk terecht?

  19. De kosten zullen afhangen van waar de lat van ‘verwijtbaar handelen’ precies wordt gelegd. (Zie commentaar van Arnoud hierboven.) Een sportvereniging die de ledenlijst aan alle leden beschikbaar stelt handelt al sneller verwijtbaar dan als alleen de secretaris toegang heeft.

  20. Een ding waaraan de softwarebakkers kunnen beginnen is de EUropese privacy-eisen meenemen wanneer ze nieuwe features aan hun software toevoegen. Geen “integratie” van tekstverwerkers en spreadsheet programma’s met “sociale netwerken”, want dat is een uitnodiging voor een bijna oneindige reeks privacyblunders. Op zich is het niet moeilijk om software te maken die “privacybewust” is; de NSA heeft er in de vorige eeuw zelfs normen voor opgesteld; alleen ging het er toen om om staatsgeheimen te beschermen tegen ongewenste openbaarmaking. (Het principe is gegevens toekennen aan beveiligingsdomeinen en voor ieder domein toegangsregels vaststellen en afdwingen.)

    Tot heden was er niet veel vraag naar “privacybewuste software”, maar (dreigende) boetes voor de gebruikers bevorderen de vraag. Het zou me niet verbazen als standaard (webshop, verenigings-) software over een jaar of twee standaard met privacy-bescherming komt. Gewoon omdat de markt er om vraagt.

  21. Een ding waaraan de softwarebakkers kunnen beginnen is de EUropese privacy-eisen meenemen wanneer ze nieuwe features aan hun software toevoegen.
    Ik zou het wel willen, maar management vind dit maar vervelend en vreest dat dit ten koste gaat van de nieuwe functionaliteit die er ook in zit. Probleem is dat er best veel developers zijn die aan de beveiliging willen werken, die ook de stabiliteit willen verbeteren, en die willen zorgen dat software ook voldoet aan de wettelijk gestelde eisen. Maar ieder software-bedrijf heeft uiteindelijk het nadeel dat developers niet het beleid bepalen. Er zijn de verkopers van de software plus de helpdesk die beiden in contact staan met klanten en vooral aangeven wat klanten graag willen en waar klanten ontevreden over zijn. Management hoort deze zaken aan en wil dan al die wensen in de volgende release zien. En die moet volgende maand al af zijn, getest en wel. Wat? Te weinig tijd? Geen probleem want dan huren ze wel wat gedetacheerd personeel in om mee te helpen. Of ze outsourcen delen van de code aan India, Dubai of de Filippijnen. Outsourcen heeft dankzij de “lagere kosten” ook vaak de voorkeur, maar het maakt de code er meestal niet beter op.

    Natuurlijk is het vooral een probleem voor de gebruikers die de software van de software-boer inkopen, met een contract erbij die de software-boer zoveel mogelijk vrijstelt in geval van bepaalde vormen van schade. En omdat dit B2B contracten zijn mag er ook best veel op die manier worden vastgelegd. Om het erger te maken, de concurrentie is vaak ook niet beter zodat je als gebruiker tussen twee (of meer) kwaden moet kiezen.

    Zolang de software-boer niet mede verantwoordelijk gehouden kan worden, zeker bij closed-source code, zal de situatie ook niet snel veranderen…

  22. @22: Ik zie wel een groeiende bewustwording bij onze klanten. Met name door alle ophef over cookies. Dat is niet alléén maar lastig, maar zorgt er ook voor dat mensen beginnen na te denken waaróm er zo’n ophef is. En als de wens vanuit de klant komt dan wordt eraan gewerkt. En als bedrijf kun je het ook als feature marketen: “Voldoet aan zus-en-zo”, maar inderdaad alleen als er vraag naar is.

  23. Ik zie wel een groeiende bewustwording bij onze klanten.
    Ik ook wel, en ik zie dat ook bij management. Maar managers en klanten willen niet betalen voor betere beveiliging of om te voldoen aan de cookiewetgeving. Dergelijke zaken zijn geen “functionaliteit” dus voor klant en management “waardeloos”. Overigens, ik het project waaraan ik werk is ook spontaan een verzoek gekomen om de cookie-melding weer te geven, en die melding werd zelfs verrijkt met een website waar je eenvoudig een stukje JavaScript kon laten genereren in een bepaalde kleur, met specifieke vormgeving en andere toeters en bellen. Jammer alleen dat de applicatie een Silverlight applicatie is en JavaScript dan erg onhandig wordt. Dit is dus weer een situatie waarbij hogerop te makkelijk nadenkt over wat een geschikte oplossing is. Ze zien iets dat snel en makkelijk te gebruiken lijkt, dus moet dat erin en wel in een half uurtje of zo. Zonder er verder bij na te denken waar het nou precies aan moet voldoen. Die melding blijft dan ook nog een tijdje op de ToDo lijst staan, met feedback erbij die aangeeft dat we meer en betere informatie nodig hebben en dat de aangegeven oplossing niet toepasbaar is…

    Probleem blijft dat veel software-boeren niet geleid worden door professionele software-ontwikkelaars maar door managers die veel van de materie zelf zeten, maar verder veel kennis missen en vooral reageren op signalen vanuit de markt.

  24. Is in artikel 13 van de huidige Wet bescherming persoonsgegevens niet al te lezen dat er een meldplicht van een datalek bestaat? Zo zou een website aan haar leden moeten melden dat de emailadressen en wachtwoorden per ongeluk zijn gepubliceerd zodat de leden op andere websites hun wachtwoorden kunnen veranderen. In artikel 13 staat namelijk dat de organisatie maatregelen moet treffen die verdere (onrechtmatige) verwerking van persoonsgegevens voorkomen.

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS