Datacenter en Recht ICTRECHT

2016

Datacenter en Recht

ICTRECHT

COLOFON Datacenter Visie is een uitgave van Dutch Datacenter Association (DDA), de branche organisatie voor commerciële datacenters in Nederland. D ​ e DDA verbindt de marktleidende datacenters in Nederland met als missie ​ het versterken van economische groei en het profileren van datacenters in de Nederlandse samenleving. In deze uitgave geven wij de afzonderlijke visies weer van de partners van de Dutch Datacenter Association op de ontwikkelingen van de Nederlandse datacenter sector voor 2016. DDA is deelnemer van DINL, EUDCA en de Digital Gateway to Europe.

Redactie

Marketing & artwork

T. @dutchdatacenter E. [email protected] W. http://www.dutchdatacenters.nl/

Noor van den Bogaard (DDA) Michiel Cazemier, Gaby Dam (Splend)

Editie

Datacenter & Recht 2016: Jaargang 1, nummer 1, mei 2016

Aan deze uitgave hebben meegewerkt: Arnoud Engelfriet, ICTRecht Lisette Meij, ICTRecht Niels Dutij, ICTRecht Itte Overing, ICTRecht Sten Demon, ICTRecht Stijn Grove, DDA Wouter Pegtel, Splend

Print oplage 100

Beschikbaarheid

Onze publicaties zijn gratis te downloaden op www.dutchdatacenters.nl © 2016 2

INHOUD Hoofdstuk 1 - Contractering algemeen 1.1 Contractsluiting in de ICT

9

1.2 Aandacht voor aansprakelijkheid

13

Hoofdstuk 2 - Continuïteit 2.1 Factsheet Continuïteit in de cloud

18

2.2 Blog: Continuïteit: hoe regelt u dat?

20

2.3 De curator krijgt recht op toegang tot de cloud

21

Hoofdstuk 3 - Privacy 3.1 Impact van de meldplicht datalekken

22

3.2 Safe Harbor ongeldig

26

3.3 Het Privacy Shield

28

Hoofdstuk 4. - Checklist 4.1 Heeft u al beleid over de datalekmeldplicht?

30

4.2 Aandacht voor aansprakelijkheid

33

4.3 Checklist Service Level Agreement

34

3

GRAAG STELLEN WIJ AAN U VOOR: ONZE DEELNEMERS

4

ONZE PARTNERS

Perf-it

ICTRECHT

5

6

INLEIDING Vertrouwen is de basis van iedere samenleving en economie. Hoewel je het liefst iedereen op zijn of haar blauwe ogen wil vertrouwen, is de realiteit helaas anders. De wereld is niet ideaal en afspraken en controle door middel van contracten en regels zijn het beste uitgangspunt totdat anders bewezen.

Zonder datacenters zou onze samenleving en economie stil vallen. Alle landen van de wereld zijn inmiddels afhankelijk van de online diensten die allemaal in datacenters staan. We zouden niet bij ons geld kunnen, geen belasting kunnen betalen of anders economisch kunnen handelen. Gezien deze belangen wil je zeker weten dat dit goed zit. Voor datacenters is het geven van vertrouwen core business. Immers bedrijven ‘outsourcen’ hun kritische IT-systemen, waar het hele bedrijf vaak afhankelijk van is, bij datacenters. Dan is vertrouwen in het datacenter uiterst belangrijk, naast uiteraard zaken als veiligheid en 100% bereikbaarheid. Deze publicatie is een samenwerking van de Dutch Datacenter Association en ICTRecht. We behandelen hierin de belangrijkste juridische aspecten rondom datacenters. We geven uitleg over onderwerpen als contracten, continuïteit, privacy maar ook hoe het nu eigenlijk zit met bevoegdheden van opsporingsdiensten. Tevens zijn ook een aantal praktische checklists toegevoegd. Dit is de eerste keer dat we deze publicatie uitbrengen en dit wordt een jaarlijks terugkerende publicatie. Dit natuurlijk in vertrouwen gezegd. Veel leesplezier gewenst, Stijn Grove Directeur Dutch Datacenter Association

8

CONTRACTERING ALGEMEEN 1.1 CONTRACTSLUITING IN DE ICT Een overeenkomst komt tot stand door aanbod en aanvaarding. Dit is niet anders in de ICT dan in andere rechtsgebieden. Maar hoe het aanbod moet worden gedaan en hoe aanvaarding kan plaatsvinden, dat kan in de ICT nog wel eens anders uitpakken. Mede vanuit de wens het elektronisch handelsverkeer te stimuleren, kent de wet dan ook diverse specifieke regels die gelden bij ICT-contractsluiting. Een opfriscursus: hoe contracteert men in de ICT?

Informatieplichten

ontstaan wanneer geen duidelijk document aanwezig is dat een en ander vastlegt. Het is dan ook aan te raden om ook in deze situaties een formeel document op te stellen (zie ook hierna over aktes).

Bij een elektronische overeenkomst bepaalt de wet (art. 6:227b en 227c BW) dat de dienstverlener vooraf “op duidelijke, begrijpelijke en ondubbelzinnige wijze” diverse informatie moet verschaffen over de wijze waarop de overeenkomst tot stand komt, of en hoe deze later nog te raadplegen is, hoe een onbedoelde aanvaarding kan worden hersteld, in welke talen de overeenkomst wordt gesloten en of eventuele gedragscodes van toepassing zijn. Gebeurt dit niet, dan is de overeenkomst vernietigbaar. Dit geldt ook bij zakelijke overeenkomsten, zij het dat men hier contractueel van kan afwijken (art. 6:227c lid 6 BW).

Bevestigen van aanvaarding Nadat een aanvaarding is ontvangen, moet de dienstverlener deze zo snel mogelijk bevestigen. Totdat deze bevestiging is ontvangen, mag de wederpartij de overeenkomst ontbinden (art. 6:227c lid 2 BW). En bevestigt de dienstverlener niet zo snel mogelijk, dan geldt dit als een verwerping van de aanvaarding zodat in het geheel geen overeenkomst tot stand komt (art. 6:221 lid 2 BW).

In het bijzonder moet de dienstverlener de overeenkomst op zo’n manier aanbieden dat de wederpartij deze kan opslaan voor latere kennisname. Artikel 6:227b BW beperkt deze eis tot “de voorwaarden, niet zijnde algemene voorwaarden” maar op grond van artikel 6:234 BW geldt dezelfde eis ook voor de algemene voorwaarden. Bijgevolg zal de gehele overeenkomst inclusief alle algemene voorwaarden en bijlagen moeten worden aangeboden in een op te slaan formaat, hetgeen in de praktijk betekent dat een PDF-bestand beschikbaar moet worden gesteld.

De bevestiging mag een automatisch gegenereerd bericht zijn. Dit heeft als risico dat een aanvaarding wordt bevestigd op een aanbod dat een fout bevat, bijvoorbeeld een onjuiste prijs. In geautomatiseerde systemen, met name bij e-commerce, is dit een niet te verwaarlozen risico. Men kan natuurlijk stellen dat het automatische bericht alleen de ontvangst bevestigt, maar dan moet er alsnog een later bericht worden verstuurd dat daadwerkelijk de overeenkomst bevestigt. Omgaan met fouten is een lastige in de online contractering. Hoofdregel is dat de wederpartij slechts een overeenkomst kan claimen als hij gerechtvaardigd mocht vertrouwen (art. 3:35 BW) op het aanbod, oftewel als de fout niet redelijkerwijs kenbaar voor hem was. Disclaimers op de website (zie

Een uitzondering op deze regel geldt wanneer de overeenkomst per e-mail, Skype of dergelijke individuele communicatie tot stand komt. Er is dan dus geen document nodig. Uiteraard kunnen in deze situaties bewijsproblemen 9

hoofdstuk 5.7) zullen hierbij niet baten: is het aanbod geloofwaardig, dan zit de aanbieder eraan vast ook al staat elders dat alle aanboden onder voorbehoud van typefouten en dergelijke zijn.

Een schriftelijke overeenkomst is echter slechts zelden wettelijk vereist. Toch is vaak behoefte aan de specifieke vorm van schriftelijke overeenkomst met handtekening, en wel vanwege de bewijskracht die dit oplevert. Een onderhandse akte levert tussen partijen in beginsel dwingend bewijs op over wat er is afgesproken, wat bij latere geschillen een waardevolle situatie kan zijn (art. 157 Rechtsvordering). Daarnaast vereist de levering van een auteursrecht, alsook de meeste andere in het ICT-handelsverkeer verkochte vermogensrechten, eveneens een akte (art. 2 Auteurswet jo. 3:83 BW). Een onderhandse akte moet in beginsel op papier zijn opgesteld en voorzien zijn van een ‘natte’ handtekening, oftewel een krabbel met pen gezet. Echter, onder voorwaarden is ook een elektronische akte rechtsgeldig (art. 156a Rechtsvordering). Kort gezegd is vereist dat de inhoud zodanig wordt vastgelegd dat deze ongewijzigd gereproduceerd kan worden voor zo lang als nodig. In de ICT-praktijk betekent dit een PDF-bestand, in beginsel in het PDF/1a formaat zoals vastgelegd in ISO standaard 19005-1.

Het standaardarrest is dat van webwinkel Otto, waarbij kopers geen overeenkomst konden claimen nadat zij een televisie uitkozen die abusievelijk voor €99 in plaats van €999 werd aangeboden. Aan de disclaimer van de webwinkel maakte het Hof weinig woorden vuil. Uit dit arrest volgt ook dat de wederpartij een onderzoeksplicht heeft (art. 3:11 BW) bij een twijfelachtig aanbod. Bevestigt de aanbieder in zo’n geval de juistheid van het aanbod, dan helpt een later beroep op welke fout dan ook niet meer.

Elektronische en schriftelijke contracten Veel is geschreven over elektronische contracten, digitale aktes en wat daarbij komt kijken. Het beeld lijkt hierdoor te zijn ontstaan dat een elektronische overeenkomst twijfelachtig kan zijn. Dit is echter pertinent onjuist. Het sluiten van een overeenkomst is immers vormvrij, en mag dus ook in elektronische vorm geschieden. Er zijn slechts zeer weinig overeenkomsten waarvoor de wet een geschrift als vormvereiste stelt.

Men kan zich afvragen wat werkelijk de toegevoegde waarde is van een elektronische akte met idem handtekening. In de zakelijke praktijk staat immers zelden het bestaan of de inhoud van het contract als zodanig ter discussie: men verschilt gewoonlijk van mening over de uitleg van de clausules, niet over het bestaan daarvan. En ook bij een akte staat de uitleg van clausules open voor partijen (via de Haviltex-norm).

In die gevallen waar de wet een geschrift eist, is in beginsel een elektronisch geschrift ook rechtsgeldig (art. 6:227a BW), behalve bij overeenkomsten waarvoor de rechter, een overheidsinstantie of notaris vereist. Dit zal in de ICT-praktijk zelden aan de orde zijn, behalve wellicht bij de aankoop van woningen via internet (art. 7:2 BW). Men zou dus een arbeidsovereenkomst met proeftijd of concurrentiebeding elektronisch kunnen sluiten als daarbij een elektronisch geschrift wordt geproduceerd (zie ook het meer specifieke art. 7:655 BW voor deze situatie).

Shrinkwrap, clickwrap en browsewrap In de dagelijkse ICT-praktijk worden drie types overeenkomsten onderscheiden waarbij de aanvaardingshandeling een andere is dan de traditionele handtekening onder een document. Het betreft hier met name softwarelicenties, hoewel de gebruikte techniek strikt gesproken niet software-specifiek is:

10

Een shrink-wrap licentie is een overeenkomst waarbij het openen van de verpakking (gewoonlijk met krimpfolie oftewel shrink wrap afgesloten) als aanvaardingshandeling wordt aangemerkt. Een opmerkelijke praktijk hierbij is dat zeker in de beginperiode van softwareverkoop de licentie in de verpakking was opgenomen, zodat men de voorwaarden pas kon lezen na deze te hebben aanvaard. Het moge duidelijk zijn dat hiermee geen aanvaarding kan worden geconstrueerd. Worden de voorwaarden op bijvoorbeeld de achterkant van de doos gedrukt, dan zijn zij tijdig leesbaar.

bedoeld. Dit geldt ook wanneer de wederpartij opties kiest: elke optie is bedoeld voor meerdere overeenkomsten en is dus nog steeds ‘algemeen’. Slechts wanneer de voorwaarden individueel uitonderhandeld worden, kan men spreken van een ICT-contract dat geen algemene voorwaarden bevat.

Onredelijk bezwarend Algemene voorwaarden mogen niet onredelijk bezwarend zijn, anders zijn zij door de wederpartij vernietigbaar (art. 6:233 sub a BW). Deze open norm komt grotendeels overeen met de eis uit art. 6:248 lid 2 BW, hoewel de toetsing van art. 6:233 sub a BW meer abstract gebeurt dan bij de vraag bij art. 6:248 BW of het beroep op een beding naar redelijkheid en billijkheid in deze situatie onaanvaardbaar is.

Een click-wrap licentie is een overeenkomst die als aanvaardingshandeling een klik op een knop met tekst als “I agree” of het aanvinken van een vakje “Ik ga akkoord met de voorwaarden” vereist. Deze vorm is vandaag de dag zeer gebruikelijk en kan in beginsel tot een rechtsgeldige overeenkomst leiden, mits de klik of het vinkje maar gevraagd wordt voordat de overeenkomst gesloten wordt. Fout is echter de staande praktijk om de voorwaarden in een venster te tonen vanuit waar zij wel gelezen, maar niet opgeslagen of uitgeprint kunnen worden.

Deze regeling van vernietiging geldt niet voor wat wij maar even grote bedrijven noemen (art. 6:235 BW): bv’s, nv’s, coöperaties, vof ’s en nog een assorti aan rechtsvormen (art. 2:360 BW) maar ook stichtingen en verenigingen die een bedrijf uitoefenen (art. 2:360 lid 3 BW). Deze bedrijven zijn groot genoeg om een onderhandelingspositie te hebben ten aanzien van leveranciers met algemene voorwaarden, is de gedachte. Klikt men zoals iedereen gedachteloos op “I accept” bij softwarelicenties of online contracten, dan is het bedrijf gewoon gebonden en kan men niet stellen dat de inhoud onredelijk bezwarend is. Alleen de algemene regel uit art. 6:248 lid 2 BW blijft over, maar dit vereist bewijs van onredelijkheid in de concrete situatie, een lastiger drempel dan de onredelijkbezwarendheid bij algemene voorwaarden. Bij overeenkomsten met consumenten geldt bij de eis van onredelijkbezwarendheid een grijze lijst (art. 6:237 BW) en een zwarte lijst (art. 6:236 BW). Bij bedingen op de grijze lijst moet de ICT-dienstverlener bewijzen dat het beding in zijn geval wél redelijk is, maar bij bedingen op de zwarte lijst is geen tegenbewijs mogelijk: deze zijn per definitie onredelijk bezwarend. In sommige gevallen kunnen ook kleine bedrijven middels reflexwerking aanspraak maken op deze lijsten. Hiervoor is vereist dat de transactie buiten het kennisgebied van de ondernemer valt, en dat de ondernemer in feite op één lijn met een consument te stellen is. De rechtspraak hierover is erg casuïstisch en men moet dan ook niet al te hard rekenen op reflexwerking als kleine ICT-ondernemer.

Een browse-wrap overeenkomst is een overeenkomst waarbij de aanvaarding wordt afgeleid uit het feit dat men de software (of vaker: de online dienst) gebruikt nadat men erop gewezen is dat aan dit gebruik voorwaarden worden gesteld. Of dit tot een rechtsgeldige overeenkomst leidt, betwijfelen wij ten zeerste. Hoewel ook een feitelijke handeling, zoals het gebruik van een website, als aanvaarding kan worden opgevat (art. 3:37 BW), zal het afhangen van hoe prominent naar de voorwaarden is verwezen en hoe vroeg in het proces dat gebeurt. Een enkele opname van een hyperlink “Algemene voorwaarden” in de voettekst of colofon van een website zal niet genoeg zijn (Attingo-arrest). Een duidelijke balk of popup die verwijst naar voorwaarden en die als eerste in beeld komt, kan waarschijnlijk wel tot een geldige toestemming leiden.

Algemene voorwaarden Veel ICT-contracten worden gesloten in de vorm van een elektronisch aanbod aangevuld met een als algemene voorwaarden opgesteld document als bijlage. Deze vorm is het eenvoudigst te automatiseren in bijvoorbeeld een webwinkel of online bestelformulier: de klant kiest producten en/of diensten en zet een vinkje bij “Ik accepteer de voorwaarden”, waarna de bestelling definitief wordt.

Terhandstelling algemene voorwaarden De wet eist als hoofdregel dat algemene voorwaarden ter hand worden gesteld (art. 6:234 lid 1 BW). Dit wil zeggen dat een stuk papier met daarop de voorwaarden wordt overhandigd aan de wederpartij. Simpeler kunnen wij het niet zeggen; toch worden met zeer grote regelmaat de creatiefste trucs uitgehaald om toch zonder dat stuk papier te kunnen werken. Dit is zeer riskant.

Voor ICT-dienstverleners Ook juridisch gesproken is werken met algemene voorwaarden vaak onvermijdelijk. De term “algemene voorwaarden” wordt gedefinieerd als voorwaarden bestemd om in meerdere overeenkomsten gebruikt te worden (art. 6:231 BW), en ICT-overeenkomsten zijn vrijwel altijd aldus 11

Er is een uitzondering voor het geval waarin het de ondernemer redelijkerwijs onmogelijk is de algemene voorwaarden bij elke overeenkomst ter hand te stellen. In die situatie mag hij volstaan met verwijzen naar Kamer van Koophandel of griffie van rechtbank, mits hij op eerste verzoek de voorwaarden alsnog ter hand stelt aan de wederpartij. Voor ICT-dienstverleners of handelaren is deze uitzondering van nul en generlei waarde, aangezien zij prima bij elke offerte de voorwaarden bij kunnen sluiten. Een depot van ICTvoorwaarden bij de Kamer van Koophandel is dan ook een verspilling van geld, maar komt toch relatief vaak voor “omdat het juridisch staat” om te kunnen zeggen dat de algemene voorwaarden zijn gedeponeerd ter griffie of bij de KVK te Amsterdam.

standaardsoftware om installatieprocedures mee te realiseren komt uit de VS waar dit een prima manier is om voorwaarden aan te bieden.

Ter hand stellen bij dienstverlening Voor het beschikbaar stellen van algemene voorwaarden van dienstverleners bestaat sinds 2009 een apart regime in het Nederlands recht (art. 6:230b BW). Zo ongeveer alles in de ICT, met uitzondering van licenties, de levering van ICTapparatuur en e-commerce, is als een dienst aan te merken. Er zijn voor een dienstverlener vier opties, ter vrije keuze van de dienstverlener: 1. Op eigen initiatief verstrekken door de dienstverlener. Dit stemt grofweg overeen met de ‘gewone’ terhandstelling.

Ook kent de rechtspraak een uitzondering op grond van redelijkheid en billijkheid bij professionele partijen die herhaaldelijk zaken met elkaar doen. Als bij een eerste overeenkomst de algemene voorwaarden correct ter hand zijn gesteld, is dit niet opnieuw nodig bij vervolgovereenkomsten. Wij vinden het echter riskant hierop een beroep te doen, en aangezien het overhandigen van een stuk papier (of elektronisch document bij eveneens elektronische offertes) buitengewoon eenvoudig is, zou dit ook niet nodig moeten zijn.

2. Voor de afnemer gemakkelijk toegankelijk maken op de plaats waar de dienst wordt verricht of de overeenkomst wordt gesloten. Binnen de ICT zou dit zelden moeten spelen, behalve wellicht bij ontwikkelwerk ter plaatse. 3. Voor de afnemer gemakkelijk elektronisch toegankelijk maken op een door de dienstverlener meegedeeld adres. In de praktijk kan de dienstverlener hiermee verwijzen naar de vindplaats (URL) op zijn website. Wel zal een specifieke URL moeten worden gebruikt, niet slechts “Voor de voorwaarden, zie onze website”.

Verder geldt de eis van terhandstelling niet voor wat wij maar even grote bedrijven noemen, net zoals zij geen beroep kunnen doen op de vernietigbaarheid wegens onredelijkbezwarendheid. Zij kunnen volstaan met verwijzen naar algemene voorwaarden en het is dan aan de partijen om uit te zoeken welke voorwaarden dit zijn.

4. Opname in alle door de dienstverlener verstrekte documenten waarin de diensten in detail worden beschreven. Dit zouden bijvoorbeeld de offerte of brochures over de diensten kunnen zijn.

Elektronisch ter hand stellen

In alle gevallen moet dit tijdig voor de sluiting van de overeenkomst gebeuren wanneer een schriftelijke overeenkomst wordt gesloten. Echter, als er geen aparte schriftelijke overeenkomst wordt aangegaan, dan moet dit voor de verrichting van de dienst meegedeeld of beschikbaar gesteld worden (art. 6:230e BW). Hoewel de wet van ‘schriftelijk’ spreekt, menen wij dat ook een elektronische overeenkomst onder de hoofdregel valt. Doel van de wet is immers het tijdig beschikbaar stellen van voorwaarden, en slechts wanneer men stilzwijgend of mondeling akkoord gaat met een dienst, is het logisch om pas bij aanvang van de dienstverlening de voorwaarden te melden.

In beginsel moeten algemene voorwaarden op papier ter hand gesteld worden. De wet noemt ook de elektronische terhandstelling als optie. De voorwaarden moeten dan zo worden aangeboden dat de wederpartij ze kan opslaan en er toegang toe heeft ten behoeve van latere kennisneming (art. 6:234 lid 2 BW). In de ICT-praktijk betekent dit een PDFbestand of aparte webpagina, in het laatste geval wel met een duidelijk zichtbare printknop of alle menu’s gewoon bereikbaar. Voor smartphones en tablets is een andere oplossing nodig: deze kunnen gewoonlijk niet printen. Een PDF-bestand zou een oplossing kunnen zijn. De praktijk werkt veel met venstertjes waarin men kan scrollen om de voorwaarden te lezen, en floepvensters (popups) waarin uitsluitend de tekst van de voorwaarden te vinden is en de menu’s en knoppen verborgen zijn. Deze praktijken zijn volstrekt onjuist in het licht van de wet maar zeer weerbarstig “want iedereen doet het” en de 12

1.2 AANDACHT VOOR AANSPRAKELIJKHEID Weinig vakgebieden waar zo driftig wordt geëxonereerd als in de ICT. Dit is begrijpelijk, aangezien de ICT een jong vakgebied is waar veel wordt geëxperimenteerd met nieuwe diensten, en waar het bovendien lastig is om fouten uit te sluiten. Het is bijvoorbeeld praktisch onmogelijk foutloze software te leveren of een SaaS-dienst permanent ongestoord beschikbaar te houden. Hoe vindt u nu een goede balans in een exoneratiebeding?

Een financiële grens trekken

Aansprakelijkheid is beperkt tot hetgeen Opdrachtgever in de drie maanden voorafgaand aan de schadebrengende gebeurtenis betaald heeft voor dat deel van de Opdracht dat aanleiding gaf tot de schade.

Gebruikelijk is de aansprakelijkheid te beperken door een financiële grens (‘cap’) te trekken:

Hiermee groeit het plafond mee met de omvang van de opdracht. Een nadeel is wel dat bij een snel optredende schadebrengende gebeurtenis de cap erg laag zal zijn. Wat is na drie weken immers “de som van in de afgelopen twaalf maanden uitgebrachte facturen”? Men zou kunnen werken met een bedrag als alternatief: het maximum van twaalf maanden aan facturen en € 50.000. Dan zal bij een snel optredende schade tot het vaste bedrag worden vergoed, en bij een later optredende schade de som van de betreffende facturen.

Aansprakelijkheid is beperkt tot een bedrag van € xxx per gebeurtenis en een bedrag van € xxx per kalenderjaar/ contractsjaar. Deze constructie heeft het voordeel van de eenvoud, maar vereist wel dat de bedragen realistisch in te schatten zijn. Dit zal in de praktijk vaak niet meevallen. Kleine bedragen zijn voor klanten snel onacceptabel, terwijl hoge bedragen niet per se in verhouding tot de overeenkomst staan en bovendien voor kleine leveranciers niet te dragen zijn en het risico van zijn faillissement meebrengen.

Aansprakelijkheid onder de verzekering Voor de hand ligt om de aansprakelijkheid van een dienstverlener te koppelen aan een verzekering, eventueel aangevuld met een laag plafond voor gevallen waarin de verzekering niet uitkeert:

Een flexibeler alternatief is dan ook het bedrag te koppelen aan de facturen: Aansprakelijkheid is beperkt tot hetgeen Opdrachtgever verschuldigd is voor dat deel van de Opdracht dat aanleiding gaf tot de schade.

Aansprakelijkheid is beperkt tot hetgeen de verzekeraar van Leverancier ter zake uitkeert. Vindt geen uitkering plaats, dan is de aansprakelijkheid beperkt tot € 2.500.

Vanuit leveranciersoogpunt kan hierbij “betaalde facturen” worden gehanteerd, als enigszins flauwe prikkel voor de klant om facturen snel te betalen. Let op dat bij veel opdrachten er per periode of stap in de uitvoering wordt betaald, bijvoorbeeld na iedere opgeleverde mijlpaal. In die situatie moet duidelijk zijn wat het “deel van de opdracht” is waar het schadebedrag uit afgeleid wordt.

Leverancier zal zich deugdelijk verzekerd houden; een kopie van de polisvoorwaarden bevindt zich in Bijlage B en wijzigingen worden tijdig toegezonden. Dit blijkt in de ICT echter lastiger dan in andere sectoren. Vanwege het jonge karakter van het vakgebied en de vaak experimentele aard van de diensten is het verzekeren van ICT-risico’s lange tijd niet goed mogelijk gebleken. Daar komt langzaam verandering in, door gespecialiseerde ICTverzekeringen met dekking voor beroepsfouten door bijvoorbeeld fouten in software, niet-beschikbaarheid van

Bij duurovereenkomsten kan de formulering aan een aantal facturen worden opgehangen:

13

diensten of het schenden van intellectuele eigendomsrechten. De prijzen van dergelijke verzekeringen zijn echter nog steeds aan de hoge kant. Een alternatief is overigens de aansprakelijkheid tot een hoog bedrag te beperken en daarnaast te eisen dat de leverancier een verzekering heeft. Hiermee komt het risico op nietuitkering door die verzekeraar te liggen bij de leverancier in plaats van bij de klant.

Verwijzen naar de polis Een “deugdelijk verzekerd”-clausule kan expliciete verwijzingen naar bedragen of dekking bevatten:

Wij raden dit af. Niet alleen is de redactie van zo’n clausule al buitengewoon ingewikkeld, omdat naar diverse uitzonderingen en cumulatieve bedragen moet worden verwezen, het is ook erg lastig om met één zin aan te geven wat een verzekering moet dekken. Polisvoorwaarden zijn immers niet voor niets vele pagina’s tekst. Logischer is om enkel een “deugdelijke verzekering” te eisen en de polis ter inzage te vragen. Dit betekent wel dat de klant nu moet inschatten of de verzekering van de leverancier voor hem (de klant) adequaat is. Maar dat is onzes inziens de juiste situatie, aangezien klant en leverancier op dit moment – tijdens de onderhandelingen immers – nog kunnen besluiten de verzekering aan te passen.

De leverancier neemt een deugdelijke verzekering en berekent de premieverhoging door aan de klant. Dit is een compromis ten opzichte van de vorige optie. Discussie kan ontstaan of de héle verhoging moet worden doorberekend: de leverancier heeft er immers ook baat bij wanneer andere klanten een aansprakelijkheidsclaim indienen.

De leverancier sluit geen aanvullende verzekering af, maar verlaagt de prijs om het kennelijk hoge risico voor de klant draaglijker te maken. Eventueel kan de klant zelf een verzekering nemen om het risico af te dekken. Zeker bij grote klanten en kleine leveranciers kan dit een optie zijn. Een ander aandachtspunt is of het wel wenselijk is het aansprakelijkheidsplafond te koppelen aan de beslissing van de verzekeraar.

Veel ICT-contracten maken onderscheid tussen directe en indirecte schade. Op basis van dit onderscheid wordt dan aansprakelijkheid voor indirecte schade gewoonlijk categorisch uitgesloten, en aansprakelijkheid voor directe schade op een of andere wijze tot een zeker plafond beperkt.

Als geen deugdelijke verzekering aanwezig is bij de leverancier, zijn er vier opties:

2.

4.

Directe versus indirecte schade

Vier opties bij verzekeren

De leverancier neemt op eigen kosten een verzekering die voor beide partijen wel deugdelijk is. Dit maakt de overeenkomst minder aantrekkelijk voor de leverancier en zal zelden acceptabel zijn.

De leverancier sluit speciaal voor deze klant een verzekering af die de klant direct als begunstigde aanwijst. In dat geval is het niet meer dan redelijk dat de premie voor rekening van de klant komt.

Immers, nu is een derde partij met inherente prikkel tot nietbetalen van geld de beslisser over de vraag of er geld moet worden betaald. Bovendien moet nu de klant inschatten of de verzekeringspolis van de leverancier voor zijn doeleinden adequaat is. Dit nog afgezien van het feit dat er meer klanten een claim kunnen indienen, waardoor het maximum aantal uitkeringen per jaar gehaald kan zijn voordat deze schade zich voordoet. Een klantvriendelijk alternatief is dan ook een combinatie van een objectief omschreven plafond, zoals twaalf maanden aan facturen of simpelweg een X bedrag, en een eis tot deugdelijk verzekerd zijn. Hiermee heeft de klant niets te maken met of de verzekeraar uitkeert maar kan hij wel verwachten dat onder normale omstandigheden de schade vergoed zal worden.

Leverancier zal zich deugdelijk verzekerd houden en in ieder geval een dekking van 2 miljoen per aanspraak en 5 miljoen per jaar realiseren voor fouten in verband met de overeenkomst.

1.

3.

Een nadeel van deze aanpak is dat de termen ‘direct’ en ‘indirect’ geen eenduidige betekenis in het Nederlands recht hebben. Schade is immers toerekenbaar of niet. In de literatuur is veel gespeculeerd over wat deze termen kunnen betekenen. Volgens sommigen gaat het om zaakschade (direct) versus vermogensschade (indirect), volgens anderen om dichtbij gelegen schade zoals het herstel van een beschadigde zaak (direct) versus verder weg gelegen schade zoals gederfde winst (indirect). De termen lijken geïnspireerd door Amerikaans recht. Hier worden direct damages en indirect damages (ook wel consequential damages) echter vaak ook niet eenduidig gedefinieerd. Direct damages betreft meestal de direct voorzienbare schade, terwijl indirect damages de iets minder voorzienbare maar nog steeds redelijkerwijs te verwachten 14

15

schade dekt. Gederfde winst is in die visie indirecte schade, het herstel van een beschadigde zaak direct. Het Amerikaans recht kent naast ‘echte’ vergoeding van schade ook een uitgebreid systeem van ‘punitive damages’, oftewel civiele boetes. Deze worden los van de werkelijke schade toegekend en kunnen vele honderden miljoenen dollars bedragen, afhankelijk van hoe zwaar de jury het gedrag van de gedaagde afkeurt. Zeer gebruikelijk is dan ook om aansprakelijkheid hiervoor uit te sluiten door ze mee te nemen in de omschrijving van ‘indirect damages’.

Opzet en bewuste roekeloosheid

Wie wil werken met directe en indirecte schade, wordt dringend aangeraden zelf een definitie van direct en indirect op te nemen. Een veel gekozen optie is de directe schade te definiëren als vermogensschade (art. 6:96 lid 1 BW) waarmee het ‘overig nadeel’ zoals immateriële schade, smartengeld en dergelijke wordt uitgesloten.

In de praktijk wordt zelden expliciet geëxonereerd voor deze situaties. Men sluit “alle aansprakelijkheid” uit of beperkt deze en gaat er vanuit dat de leverancier in dergelijke situaties geen beroep op de exoneratie zal doen, hetgeen logisch is nu dit vrij evident naar maatstaven van redelijkheid en billijkheid onaanvaardbaar zal zijn (art. 6:248 BW, Pseudovogelpestarrest). Echter, een risico van dit standpunt is dat het gehele exoneratiebeding nietig kan worden verklaard wegens strijd met de openbare orde of goede zeden (art. 3:40 BW) omdat het ook aansprakelijkheid uitsluit voor deze niet-exonereerbare situaties. Daar staat tegenover dat in de literatuur de heersende opvatting is dat zo’n beding slechts partieel nietig is omdat het ook legitieme situaties bestrijkt.

Behoudens in geval van opzet en bewuste roekeloosheid, is de aansprakelijkheid van Xyz beperkt... Geen mogelijkheid tot exoneratie bestaat wanneer de oorzaak van de schade gelegen is in opzet of bewuste roekeloosheid van de dienstverlener. Deze situaties worden gezien als dusdanig verwijtbaar dat het uitsluiten van aansprakelijkheid in strijd is met de openbare orde of goede zeden (art. 3:40 BW).

Specifiek bij ICT-contracten voegt dat weinig toe: in het algemeen zal alle geleden schade vermogensschade zijn, zeker als men bedenkt dat ook gederfde winst of geleden verlies hieronder valt. Letselschade als gevolg van ICT-dienstverlening komt slechts zeer zelden voor. Een beperktere keuze is directe schade in te vullen aan de hand van 6:96 lid 2 BW: redelijke kosten ter voorkoming of beperking van de schade, bereddering en dergelijke. Hiermee ontstaat een objectieve maatstaf voor schade, en is de te vergoeden schade meestal aardig beperkt omdat deze kosten binnen het redelijke moeten blijven en bovendien alleen normaliter relatief geringe schadeposten betreffen. De meeste schade zal dan onder sub a (beredderingskosten) gevangen worden; deze clausule dekt bijvoorbeeld het inschakelen van een alternatieve dienstverlener om een langdurig niet beschikbare dienst op te vangen, maar (in theorie) ook de kosten van het opnieuw genereren van verloren gegane gegevens uit een database. Zowel de omvang van de kosten als de maatregelen zelf moeten redelijk zijn. De simpelste oplossing in de praktijk is om simpelweg te stellen “Aansprakelijkheid wordt slechts aanvaard voor” gevolgd door een limitatieve opsomming van gebeurtenissen waarvoor aansprakelijkheid kan worden aanvaard. Uiteraard met alle gepaste toeters en bellen ter beperking van daadwerkelijke claims.

Expliciet uitzonderen van deze situaties verdient desondanks de aanbeveling. Echter, het steeds toevoegen van een uitzondering voor deze bijzondere gevallen maakt de artikelen niet per se leesbaarder. Het simpelste is dan ook een algemene uitzondering op te nemen: Bovengenoemde beperkingen van aansprakelijkheid gelden niet in gevallen van opzet of bewuste roekeloosheid. Alternatieve termen voor “bewuste roekeloosheid” zijn “grove nalatigheid” en “grove schuld”, met name in wat oudere modellen. Of de termen hetzelfde zijn, is in de juridische literatuur nog steeds onderwerp van discussie. Het lijkt erop dat “grove schuld” een ruimer begrip is dan “bewuste roekeloosheid”, zoals De Graaf in zijn dissertatie duidelijk uiteen zet. Hiermee kunnen nuanceverschillen ontstaan. In de praktijk worden de termen echter door elkaar gebruikt en zal gezien de context duidelijk zijn wat de bedoeling van partijen was. Wij verwachten dan ook geen problemen bij de keuze van de term.

16

Consumentenrecht

vergoeden ondanks de vérgaande aansprakelijkheidsbeperking in de overeenkomst. De eenmanszaak (in fysiotherapie) was in de relatie tot ICT-professional KPN eigenlijk gewoon als een consument te beschouwen.

Bij consumentenovereenkomsten zij erop gewezen dat het beperken van aansprakelijkheid op de grijze lijst (art. 6:237 sub f BW) van verdachte algemene voorwaarden vermeld is. De bewijslast dat het wel redelijk is de aansprakelijkheid te beperken, ligt daarmee bij de dienstverlener. Voor gratis diensten lijkt het algemeen aanvaard dat de aansprakelijkheid bij nul kan liggen (behoudens opzet en bewuste roekeloosheid). Wie niets betaalt, heeft niets te verwachten. Bij betaalde diensten ligt dit lastiger. Een aanzienlijke discrepantie in de hoogte van de schade versus de betaalde vergoeding zal al snel tot geslaagd bewijs leiden, zeker als de schade voor de dienstverlener niet goed verzekerbaar is. Echter, de exoneratie zal dan wel iets genuanceerder moeten zijn dan een totale uitsluiting. Dit kan ook in de zakelijke praktijk spelen: een kleine zakelijke wederpartij kan middels reflexwerking op één lijn met een consument worden gesteld. Zo moest KPN bij haar Online Back-up-dienst de volledige schade van een eenmanszaak

Conversie van te brede exoneraties Wanneer een beding zoals een exoneratie in te brede termen is geformuleerd, kan dit worden geconverteerd (art. 3:42 BW) naar een wél geldige bepaling, zeker wanneer daartoe een expliciet conversiebeding is opgenomen in de overeenkomst. Bij algemene voorwaarden ligt conversie niet in de rede, omdat men dan eenvoudig zeer eenzijdige bedingen kan opnemen in de wetenschap dat de rechter er wel wat redelijks van maakt. Een onredelijk bezwarende algemene voorwaarde zal worden vernietigd, niet geconverteerd. Hiermee zouden de gehele exoneratie van tafel zijn. Het is dus zeker in algemene voorwaarden aan te raden de exoneratie zo redelijk mogelijk te houden.

17

CONTINUÏTEIT 2.1 FACTSHEET CONTINUÏTEIT IN DE CLOUD Clouddiensten zijn tegenwoordig niet meer weg te denken uit de online wereld.Van een simpele e-maildienst tot volledige facturatie- of accountantprogramma’s, ondernemingen maken gebruik van allerlei clouddiensten. Hiermee ontstaat een grote afhankelijkheid en dat brengt risico’s met zich mee. Steeds vaker zal de vraag gesteld worden ‘Wat als mijn clouddienstverlener failliet gaat?’ of ‘Hoe kan ik er voor zorgen dat de dienst gecontinueerd wordt?’. Deze vragen leiden steeds vaker tot een risicoanalyse ten aanzien van de weerbaarheid van clouddiensten. Met back-up faciliteiten en exit-regelingen kunnen bepaalde zaken geregeld worden. Om écht continuïteit te waarborgen is een omvangrijkere oplossing nodig. Cloudrecht en de Stichting Continuïteit Internetdiensten (SCI) bieden die oplossing.

Continuïteit De beschikbaarheid van een clouddienst is essentieel. Voor zowel leverancier als afnemer is het van belang dat de continuïteit van de dienst gewaarborgd is. Verschillende bedreigingen kunnen ondervangen worden met een slimme en doortastende oplossing. Door technische, nanciële en juridische maatregelen te nemen wordt zekerheid geboden voor alle partijen. Het doel is het bieden van een volledige

oplossing die bestand is tegen bedreigingen zoals een faillissement of een overname van de leverancier. Of het nu gaat om een eenvoudige webapplicatie of een volledig ITlandschap, de oplossing is altijd binnen handbereik. Voorheen werd de oplossing gevonden in escrow-regelingen. Deze hebben als doel de broncode van de so ware veilig te

18

stellen voor de afnemer. De meeste escrow- overeenkomsten gaan uit van een afspraak tussen de leverancier, een ona ankelijke derde: de escrow-agent (soms een notaris) en de afnemer. Indien de leverancier dan failliet wordt verklaard, stelt de escrow-agent de broncode ter beschikking aan de afnemer. Deze regeling is om meerdere redenen niet toereikend. Allereerst is een clouddienst

Door bedrijfsonderdelen te onttrekken van de werkmaatschappij ontstaat er het risico van een ‘Actio Pauliana’, met name als de werkmaatschappij daadwerkelijk failleert. De curator hee dan de mogelijkheid om de constructie gedeeltelijk te vernietigen. Dit risico kan onder andere verkleind worden door transparant te blijven ten aanzien van de overdrachten en reële prijzen te hanteren voor de bedrijfsmiddelen. Overleg met uw accountant is daarom ook altijd nodig voor een goede continuïteitsoplossing.

meer dan alleen de broncode. De hosting, de data en aanverwante service onderscheiden een clouddienst van reguliere so ware en die zaken worden niet veilig gesteld door

De intellectuele eigendomsrechten en de benodigde hardware wordt door de werkmaatschappij van de clouddienstverlener overgedragen aan de TTP. Het personeel en de overeenkomsten met leveranciers en klanten zullen in eerste instantie bij de werkmaatschappij blijven. Er zal dus een splitsing plaatsvinden tussen de assets vanuit de werkmaatschappij.

een broncode-escrow. Daarbij kan een curator bij de vere ening van de boedel de intellectuele rechten die rusten op de so ware aan een ander overdragen. Hoe de nieuwe rechthebbende omgaat met de vóór faillissement afgesloten licenties is onzeker. Door de intellectuele rechten vooraf veilig te stellen wordt deze onzekerheid weggenomen.

De TTP fungeert in de nieuwe constructie als een veilige haven die zolang er geen bedreigingen van de continuïteit optreden niet per se een actieve functie hee . De daar geplaatste assets worden via licenties en eventuele lease van hardware aan de werkmaatschappij ter beschikking gesteld. Zodoende verandert er feitelijk weinig in de bedrijfsvoering van de clouddienstverlener en zijn de assets beschermd tegen bedreigingen van de werkmaatschappij.

Om écht continuïteit te kunnen bieden is er een completere oplossing nodig. Die oplossing hee betrekking op alle onderdelen van de clouddienst. De meeste clouddiensten bestaan grofweg uit (i) intellectueel eigendom, zowel eigen so ware als licenties van derden, (ii) hardware, zoals eigen of gehuurde servers, (iii) personeel, voor onderhoud aan de so ware en een helpdesk en (iv) overige overeenkomsten met leveranciers en klanten. Om een clouddienst weerbaar te maken tegen bedreigingen zoals een faillissement dient er gekeken te worden naar al deze ‘assets’.

Naast de TTP moet er een partij zijn die de clouddienst kan leveren in het geval dat er een bedreiging intreedt. De afnemers van de clouddienst kunnen dan bij deze partij aankloppen ten behoeve van de continuïteit van de dienst. Deze partij dient ona ankelijk van de werkmaatschappij te zijn, bij voorkeur een niet commerciële entiteit zoals een stichting. Hiervoor is ook de Stichting Continuïteit Internetdiensten (SCI) in het leven geroepen. Lees meer onder het kopje “Over de Stichting Continuïteit Internetdiensten”.

De oplossing De crux van de oplossing is gelegen in het buiten de macht van de curator brengen van de assets. De bovengenoemde bedrijfsonderdelen worden daarvoor in een aparte constructie ondergebracht. Daarbij wordt gebruik gemaakt van een ‘trusted third party’ (TTP) in de vorm van een stichting of een besloten vennootschap. Hiervoor kan een nieuwe rechtspersoon worden opgericht maar er kan ook gebruikgemaakt worden van reeds bestaande entiteiten zoals de holding.

De toeleveranciers (hoster/datacenter/so wareleverancier) moeten hun diensten na het intreden van een bedreiging gaan leveren aan de dan actief wordende stichting. Om dit te bewerkstelligen dienen er overeenkomsten te worden gesloten met de toeleveranciers door de stichting.

19

2.2 BLOG: CONTINUÏTEIT: HOE REGELT U DAT? 13 oktober 2015 door Itte Overing

Bent u afnemer of leverancier van een clouddienst? Dan heeft u vast nagedacht over de risico’s van het gebruik van de clouddienst. De standaard argumenten tegen het gebruik van de clouddienst gaan vaak over het (niet) beschikbaar zijn, beveiliging en privacy. Bij beschikbaarheid kan het gaan om het tijdelijk niet beschikbaar zijn, bijvoorbeeld vanwege een fout in de software of een probleem met de internetverbinding. Eerder schreef mijn collega Sten Demon over het juridische antwoord op dit risico: een duidelijke SLA.

De dienst kan echter ook permanent niet beschikbaar worden. Denk hierbij aan faillissement van de dienstverlener of feitelijke beëindiging van de clouddienst. Het voorgoed niet beschikbaar worden, kan voorkomen worden met een continuïteitsoplossing. Hoe regelt u dat en wie heeft u daarbij nodig?

In overleg met de clouddienstverlener wordt dan besloten hoe de oplossing vorm wordt gegeven. De oplossing draagt tevens bij aan de bedrijfscontinuïteit van de dienstverlener. Er wordt immers gekeken naar alle onderliggende contracten welke gelden ten aanzien van de door hem geleverde diensten. Daarnaast wordt er gekeken naar zijn ondernemingsstructuur. En, ten slotte, worden de risico’s zoveel als mogelijk gescheiden van de assets die essentieel zijn voor de dienst.

Met een clouddienst doel ik op via het internet bereikbare diensten. Zowel “private” als “public”. Uiteraard kennen we nog veel meer benamingen zoals IaaS, PaaS en SaaS. Alle verschillende soorten clouddiensten hebben als gemene deler dat ze bestaan uit de volgende componenten: internet aansluiting (access en glasvezel), elektriciteit, (virtuele) hardware, datacenter, software (applicatie en operating software), data en de mensen die de verschillende componenten bouwen, beheren en onderhouden.

Jurist, accountant, notaris, register valuator Over het algemeen is naast de kennis van de jurist ook de kennis van een accountant nodig. Denk hierbij aan de WBSO en innovatiebox, deze besparingen wilt u natuurlijk kunnen behouden. Er kunnen ook waarderingsvraagstukken spelen, dan is er (soms) een register valuator nodig. Voor aanpassingen in de onderneming, heeft u vaak zelfs een notaris nodig.

Essentiële onderdelen van de dienst Als u de continuïteit wilt waarborgen van een clouddienst, dan moet u de essentiële onderdelen waarborgen. Daarnaast moet er een partij zijn die op het moment dat het misgaat, ervoor zorgt dat de dienst ook daadwerkelijk doordraait. Die partij moet daarbij kunnen beschikken over de essentiële onderdelen van de clouddienst. Rechten en plichten van de verschillende belanghebbenden moeten vastgelegd worden in overeenkomsten. De belanghebbenden zijn natuurlijk de afnemers, de clouddienstverlener en de partij die de continuïteit moet gaan leveren als het misgaat.

Kan het makkelijker? Ja en nee. Ja, als u op zoek bent naar een gedeeltelijke oplossing die (naar alle waarschijnlijkheid) wel het direct offline gaan van de dienst bij het faillissement van de dienstverlener, voorkomt. Denk dan aan het doordraaien van een VPS, dit kan bewerkstelligd worden met een contract tussen uw klant en uw hosting service provider. Het antwoord is echter “nee” als u de continuïteit volledig wilt waarborgen en de discussie met de curator zoveel mogelijk wilt beperken. Bij de gedeeltelijke oplossingen zult u ook met de curator in onderhandeling moeten treden over de overige essentiële onderdelen van de clouddienst.

De oplossing Omdat elke clouddienst anders is ingericht (denk hierbij aan het verdienmodel van de dienstverlener maar ook aan de verschillen in de essentiële onderdelen), is de oplossing nooit hetzelfde. Om tot de juiste oplossing te komen wordt de dienst (en onderliggende overeenkomsten) geïnventariseerd.

Juridische antwoorden op de andere risico’s van de cloud: beveiliging en privacy, komen in volgende blogs aan de orde.

20

2.3 DE CURATOR KRIJGT RECHT OP TOEGANG TOT DE CLOUD Steeds meer bedrijven maken gebruik van de cloud voor hun administratie. De voordelen zijn legio, maar wanneer een bedrijf in zwaar weer komt, ontstaat er een probleem voor de curator of zaakwaarnemer. Deze heeft toegang nodig tot de administratie, maar de clouddienstverlener weigert nog wel eens die toegang omdat ook hij achterstallige facturen heeft bij het bedrijf. Een nieuwe wet zal de positie van de curator hierbij versterken.

De positie van de curator jegens een cloudleverancier was wettelijk niet geregeld. In twee rechtszaken (Oilily, LJN BJ5559 en Vict, LJN BZ5770) werd toegang onder voorwaarden geregeld.

Saillant detail is dat in de uitleg (Memorie van Toelichting) bij de wet staat dat de dienstverlener hier wel een redelijke vergoeding voor mag vragen, maar daar geen recht op heeft indien de boedel niet voldoende middelen bevat. Eventuele kosten dient de dienstverlener te verdisconteren in zijn tarieven, de wetgever stelt dat het hier om minimale kosten zou gaan.

De curator kan een clouddienstverlener verzoeken om afgifte van administratie. Kosten die hiervoor gemaakt moesten worden - bijvoorbeeld om het online boekhoudprogramma en data van de failliet weer aan te zetten en toegankelijk te maken - kon de clouddienstverlener verhalen bij curator. Dit gaat veranderen.

In de praktijk zal dit betekenen dat de aanbieder van online boekhoudsystemen tenminste een archiefsysteem moet aanbieden dat dan ook zonder (extra) betaling toegankelijk moet zijn voor curatoren. Na faillissement blijken er immers vaak geen of niet voldoende middelen in de boedel te zitten om schulden mee te betalen. In dit geval zou het wel gaan om een schuld ontstaan na datum faillissement. Deze boedelschulden worden altijd eerst voldaan, daarna (uiteraard iets gechargeerd) worden pas de schulden ontstaan voor datum faillissement voldaan indien er nog voldoende middelen zijn. In de meeste gevallen zijn er echter niet voldoende middelen beschikbaar, ook niet om enkel de boedelschulden te voldoen.

Op 21 februari (2014) is een voorontwerp met de werktitel: “Wet versterking positie curator” gepubliceerd. Het voorontwerp maakt onderdeel uit van het wetgevingsprogramma herijking van het faillissementsrecht. Het programma bestaat uit drie pijlers: 1. Fraudebestrijding, 2. Versterking van het reorganiserend vermogen van bedrijven en 3. Modernisering van de faillissementsprocedure. De Wet versterking positie curator maakt onderdeel uit van de eerste pijler: Fraudebestrijding. Op grond van de Wet versterking positie curator zal het verplicht worden voor de aanbieders van online boekhoudsystemen om de administratie op verzoek aan de curator beschikbaar te stellen. In het voorstel staat letterlijk (nieuw artikel 105b lid 2 zoals in te voegen in de Faillissementswet):

De clouddienstverlener moet ook de middelen ter beschikking stellen om de boekhouddata (binnen redelijk termijn) leesbaar te maken. Ik neem aan dat dit niet betekent dat de volledige applicatie (weer) moet werken. Waarschijnlijk heeft het dan ook de voorkeur niet de volledige applicatie weer aan te zetten en in te richten of op een zelfstandige drager af te geven. Een standaard archieffunctie kan wel iets afdoen aan vendor lock-in, aan de andere kant is het een “upsell” en is vendor lock-in wat mij betreft een ouderwetse en door gezonde concurrentie steeds meer achterhaalde wijze van klantenbinding.

“Derden die in de uitoefening van hun beroep of bedrijf, op welke wijze dan ook, de administratie van de gefailleerde geheel of gedeeltelijk onder zich hebben, stellen deze desgevraagd aan de curator ter beschikking, zo nodig met inbegrip van de middelen om de inhoud binnen redelijke tijd leesbaar te maken.” 21

PRIVACY - NIEUWE WETGEVING/SAFE HARBOR 3.1 IMPACT VAN DE MELDPLICHT DATALEKKEN Vanaf 1 januari 2016 is het wettelijk verplicht om datalekken te melden. Zowel grootschalige inbraak als ieder kwijtraken, diefstal of onbevoegd gebruik van persoonsgegevens telt als een datalek. En dat is nog niet alles.Wie data laat lekken of persoonsgegevens verwerkt zonder zich netjes aan de wet te houden, loopt kans op boetes die kunnen oplopen tot € 820.000,- of 10% van de jaaromzet per overtreding. Wat betekent dit voor uw bedrijf?

1. Wat is een datalek?

2. Wanneer moet u een datalek melden aan de toezichthouder?

De wet spreekt van een datalek wanneer persoonsgegevens verloren raken of onrechtmatig worden verwerkt. Onder onrechtmatige verwerking valt onder andere het aanpassen en/of veranderen van persoonsgegevens en onbevoegde toegang tot, of afgifte daarvan. Kortom: een nogal brede definitie. Er is dus niet alleen sprake van een datalek als een hacker toegang tot persoonsgegevens krijgt. Ook verlies van een USB-stick in de trein, of het sturen van een mailing met adressen in het CC-veld (in plaats van het BCC-veld) telt al als datalek. En zelfs verlies van gegevens zoals bij een brand in het datacentrum terwijl er geen back-up beschikbaar is, ziet de wet als een datalek.

Niet elk datalek moet worden gemeld. De wet bepaalt dat ‘ernstige’ datalekken binnen twee werkdagen bij de toezichthouder gemeld moeten worden. Een lek kan ernstig zijn als het een grote hoeveelheid data betreft (kwantitatief ernstig), maar ook als het om gevoelige gegevens gaat (kwalitatief ernstig). Een paar voorbeelden uit de tweede categorie: • • • • • •

U dient als bedrijf preventief de juiste beveiligingsmaatregelen te nemen om datalekken te voorkomen. Dit kan bijvoorbeeld door gebruik te maken van encryptietechnieken en regels te stellen over toegang door uw personeel.

inloggegevens; financiële gegevens; kopieën van identiteitsbewijzen; school- of werkprestaties; gegevens die betrekking hebben op levensovertuiging; gegevens die betrekking hebben op gezondheid.

3. Wanneer moet u een datalek melden aan de getroffen personen?

Lekken waarbij andere gegevens dan persoonsgegevens verloren zijn geraakt of gestolen worden, zijn geen datalekken. Als de broncode van uw nieuwe software wordt ontvreemd, of een lijst met bedrijfsnamen uit uw relatiebeheerpakket wordt gekopieerd, dan valt dat bijvoorbeeld buiten deze wet.

Indien het datalek waarschijnlijk ongunstige gevolgen heeft voor het privéleven van de personen van wie de gegevens gelekt zijn, dient u - naast de melding aan de toezichthouder - het lek tevens binnen twee werkdagen te melden aan

22

de personen waarvan de gegevens zijn gelekt. Dit zullen in de meeste gevallen klanten zijn. Ongunstige gevolgen zijn bijvoorbeeld:

op afstand kunt verwijderen van bijvoorbeeld een gestolen laptop. U moet er dan wel zeker van zijn dat niemand de gegevens heeft kunnen inzien. U draagt hiervoor de bewijslast.

• identiteitsfraude; • discriminatie; • reputatieschade.

De beoordeling of een datalek gemeld moet worden aan de toezichthouder en/of de getroffen personen, ligt te allen tijde bij u. Echter, maakt u een onjuiste inschatting dat er geen melding nodig is, dan kunt u dáár ook voor op de vingers getikt worden.

Wanneer kwantitatief ernstige gegevens (zie vorige vraag) zijn gelekt, is eigenlijk altijd sprake van een ongunstig gevolg. Dit moet dus ook altijd worden gemeld aan de getroffen personen.

5. Hoe dient u een datalek te melden? De toezichthouder stelt een standaardformulier beschikbaar voor het melden van een datalek. Bij een datalek moet dus dit formulier ingevuld worden. Dit formulier zal vervolgens opgeslagen worden in een register van de toezichthouder, dat niet openbaar is. Mocht er naar aanleiding van het lek een boete opgelegd worden, dan zal dit besluit wel openbaar zijn. Een datalek wordt vanzelfsprekend ook openbaar op het moment waarop het aan de getroffen personen wordt medegedeeld.

4. Wanneer hoeft u een datalek niet te melden? Een datalek dat aan het criterium van vraag 2 voldoet, moet u altijd melden aan de toezichthouder. Daarbij doet het er niet toe of het datalek door een fout kwam of het gevolg was van overmacht. Een datalek hoeft echter niet aan de getroffen personen gemeld te worden wanneer de gelekte persoonsgegevens onleesbaar zijn. Hiervan is bijvoorbeeld sprake wanneer de persoonsgegevens versleuteld zijn of wanneer u de gegevens

23

6. Welke informatie moet u over een datalek bewaren?

Let op: bent u bewerker en zijn bij een datalek ook gegevens met betrekking tot uw eigen klantadministratie gelekt, dan zult u ook zelf een melding van het lek moeten maken. U bent daar dan immers zelf verantwoordelijk voor.

Wanneer u een datalek aan de toezichthouder meldt, dient u een overzicht hiervan in uw administratie te bewaren. Dit overzicht moet de feiten en gegevens van het lek bevatten. Denk hierbij aan de oorzaak van het lek, de soort gegevens die gelekt zijn, het moment dat het lek is ontdekt en op welke wijze het lek gedicht is. Als u het datalek ook aan de getroffen personen heeft gemeld, is het belangrijk de communicatie hierover te bewaren. Voor het bewaren van de voornoemde gegevens dient u uit te gaan van een minimale bewaartermijn van één jaar. Maak hierover ook afspraken met de bewerker, zie hiervoor vraag 8.

•

7. Wat zijn de gevolgen van de wet?

•

9. Wat kunt u doen ter voorbereiding op de meldplicht? Goed voorbereid zijn op de meldplicht datalekken? Onderneem dan de volgende acties: •

De wet kent vanaf 1 januari 2016 de mogelijkheid om boetes op te leggen wanneer niet voldaan wordt aan de wet. Deze boetes kunnen onder meer opgelegd worden voor: • • • •

•

het niet melden van een datalek terwijl dat wel moet; het niet op orde hebben van de beveiliging; het verwerken van persoonsgegevens zonder toestemming; export van persoonsgegevens naar landen buiten de EU zonder dat goed geregeld te hebben.

•

•

inventariseer wie uw gegevens verwerken en of met deze partijen een bewerkersovereenkomst is gesloten; update uw bewerkersovereenkomsten met een bepaling omtrent datalekken; sluit met iedere partij waarmee u samenwerkt een NDA (Non Disclosure Agreement) waarin u persoonsgegevens benoemt; controleer hoe de bedrijven die voor u persoonsgegevens verwerken persoonsgegevens opslaan. Gebeurt dit veilig? Controleer dit uiteraard ook binnen uw eigen bedrijf; als bedrijven zeggen gecertificeerd te zijn (bijvoorbeeld ISO 27001), vraag dan naar de scope van deze certificering; ga na bij uw verzekeraar of verzekeringstussenpersoon of u verzekerd bent tegen het lekken van persoonsgegevens (een cyberrisico verzekering); hanteer intern een procedure voor de omgang met, en melding van, datalekken.

De boete kan oplopen tot € 820.000,- of 10% van de jaaromzet binnen Nederland. Vaak zal er eerst een waarschuwing gegeven worden, maar de toezichthouder mag besluiten direct een boete op te leggen als u opzettelijk of grof nalatig heeft gehandeld. Heeft u geen beleid over hoe datalekken te voorkomen of over hoe datalekken intern op te vangen en te melden, dan handelt u per definitie grof nalatig. Zorg er dus voor dat u uw processen op orde heeft!

•

8. Moet een bewerker datalekken melden?

11. Vragen?

In veel gevallen wordt het verwerken van persoonsgegevens uitbesteed aan een derde partij. Deze derde partij noemt de wet een bewerker. Data kan bijvoorbeeld toegankelijk zijn voor een clouddienstverlener die updates uitvoert op software, opgeslagen staan bij een hostingprovider, of beschikbaar zijn voor het marketingbedrijf dat e-mails in opdracht van klanten verzendt.

Komt u er niet uit of een datalek gemeld moet worden, heeft u vragen over hoe u afspraken met derde partijen moet regelen of heeft u hulp nodig bij het opstellen van een interne procedure voor het melden van een datalek? Neem dan contact met ons op via 020 66 31 941 of [email protected] en vraag naar onze privacyspecialisten.

10. Procedure meldplicht datalekken Zijn er gegevens gelekt en wilt u snel en overzichtelijk zien wat de procedure voor het melden van een datalek is? Zie de volgende pagina voor de beslisboom voor het melden van datalekken.

Een bewerker hoeft een datalek niet te melden bij de toezichthouder. Wel moet de bewerker er zorg voor dragen dat haar klanten deze melding tijdig bij de toezichthouder kunnen maken. Er zullen daarom schriftelijke afspraken moeten worden gemaakt waarin wordt vastgelegd op welke wijze de klanten door de bewerker op de hoogte worden gesteld van een datalek. Deze afspraken kunnen worden opgenomen in een bewerkersovereenkomst. 24

Zijn de gegevens die zijn gelekt aan te merken als persoonsgegevens? Voorbeelden: namen, klantnummers, klantprofielen, (e-mail)adressen.

nee

ja Zijn het uw ‘eigen’ klantgegevens die gelekt zijn?

U hoeft geen melding te doen.

Voorbeelden: de gegevens die een hoster opslaat, of waar een clouddienstverlener toegang tot heeft, zijn gegevens van hun klanten en geen ‘eigen’ gegevens . Deze partijen worden aangemerkt als bewerker.

ja

nee

Zijn er persoonsgegevens verloren geraakt of onrechtmatig verwerkt?

U moet het lek melden aan uw klanten.

Voorbeelden: een verloren laptop, een hack, brand in een datacentrum of een oud-werknemer met toegang tot persoonsgegevens. Neem bij twijfel contact met ons op.

nee

ja Zijn een groot aantal (kwantitatief) of gevoelige persoonsgegevens (kwalitatief) gelekt?

U hoeft geen melding te doen.

Voorbeelden: meer dan duizend persoonsgegevens of gegevens zoals bankrekeningnummers, inloggegevens, gegevens omtrent gezondheid. Neem bij twijfel contact met ons op.

ja

nee

U moet de toezichthouder uiterlijk op de tweede werkdag na het ontdekken van het datalek in kennis stellen van het datalek.

U hoeft geen melding te doen.

ja Heeft het datalek waarschijnlijk ongunstige gevolgen voor het privéleven van personen? Hiervan is bijvoorbeeld sprake wanneer er gevoelige persoonsgegevens zijn gelekt of als er een gevaar is voor identiteitsfraude. Neem bij twijfel contact met ons op.

ja

nee

Zijn de gelekte persoonsgegevens op een manier beveiligd zodat ze niet gelezen of gebruikt kunnen worden?

U hoeft alleen een melding te doen aan de toezichthouder.

Hiervan is bijvoorbeeld sprake wanneer er een goede encryptie is gebruikt. Neem bij twijfel contact met ons op.

nee

ja

U moet naast de toezichthouder ook de getroffen personen in kennis stellen van het datalek.

Is de manier waarop de encryptie ongedaan gemaakt kan worden ook gelekt? nee

ja U moet naast de toezichthouder ook de getroffen personen in kennis stellen van het datalek.

U hoeft alleen een melding te doen aan de toezichthouder. 25

3.2 SAFE HARBOR ONGELDIG

Per 6 oktober is het niet langer mogelijk persoonsgegevens naar de VS te transporteren of aldaar op te slaan met een beroep op het Safe Harbor-verdrag. Het Hof van Justitie bepaalde op die datum dat het convenant tussen de Europese Commissie en de VS ongeldig was, omdat het in strijd was met hoger Europees recht. De uitspraak zorgde voor veel consternatie: diverse media meldden dat het gebruik van Facebook niet langer toegestaan zou zijn. Dat is natuurlijk onjuist.Wel is het nu behoorlijk problematisch geworden om nog persoonsgegevens in de VS te (laten) verwerken.

Safe Harbor is een reactie op het beginsel uit de Europese Richtlijn gegevensbescherming, bij ons omgezet in artikel 79 Wet bescherming persoonsgegevens. Dit beginsel bepaalt dat export van persoonsgegevens naar landen buiten de Europese Unie niet toegestaan is, behalve als dat land een adequaat beschermingsniveau van persoonsgegevens hanteert. De Richtlijn biedt vervolgens de mogelijkheid voor de Europese Commissie om een beslissing te nemen dat een bepaald land onder nadere voorwaarden een adequaat niveau van bescherming hanteert. En in 2000 besloot de Europese Commissie dat het Safe Harbor-regime ontwikkeld door de Verenigde Staten hieronder valt.

naar een dergelijk Amerikaans bedrijf. (Uiteraard moet er nog steeds een bewerkersovereenkomst zijn met het bedrijf, of moet het bedrijf een eigen grondslag hebben om de gegevens te verwerken.) Het is enigszins opmerkelijk dat het gaat om zelfcertificering: er is geen toetsing, noch vanuit het Amerikaanse ministerie noch vanuit Europese toezichthouders, of een bedrijf zich werkelijk aan de Safe Harbor-regels of de Europese privacyregels houdt. De uitspraak die Safe Harbor ongeldig verklaart, is een uitkomst van het al lang lopende conflict dat Oostenrijker Max Schrems heeft met Facebook. Schrems probeert via de Ierse toezichthouder (Facebook opereert in Europa vanuit Ierland) af te dwingen dat Facebook zich aan de Europese gegevensbeschermingswetgeving houdt. De zaak begon met een inzageverzoek: wat weten jullie allemaal over mij. Later kwamen daar aanvullende eisen bij, zoals een handhavingsverzoek aan de Ierse toezichthouder om export naar de VS door het Ierse Facebook tegen te houden omdat

Kort gezegd komt Safe Harbor erop neer dat Amerikaanse bedrijven zich aanmelden bij het ministerie van Handel en daarbij verklaren zich aan de Europese regels omtrent bescherming van persoonsgegevens te conformeren. Een Europees bedrijf kan via de website van het ministerie deze aanmeldingen inzien en vervolgens gegevens exporteren 26

– Snowden – de VS toch zeker geen adequaat niveau van bescherming van persoonsgegevens bood.

Exit Safe Harbor, begin de paniek: wat nu? Er zijn nog twee formele routes open: de aparte toestemming van de betrokkene en de modelcontracten. Aparte toestemming zou betekenen dat elke Europese dienst die onder de motorkap met een Amerikaans bedrijf werkt, een popup moet gaan voeren met daarin de vraag “Mogen wij uw gegevens in de VS opslaan”. De cookiewet on steroids, als het ware. Dat kan niet waar zijn.

De toezichthouder weigerde dit verzoek in te willigen, met onder meer het argument dat in het Safe Harbor-convenant was vastgelegd dat de Verenigde Staten geacht worden een adequaat niveau te hebben. Deze uitspraak van de Europese Commissie was niet voor toetsing vatbaar, aldus de toezichthouder. De Ierse rechter bevestigde het oordeel. Hoewel het duidelijk is dat de VS zwaar tekort schiet, mag de rechter niet tornen aan dit convenant. De hoogste Ierse rechter besloot hier vragen over te stellen aan het Hof van Justitie: is een toezichthouder gebonden aan het oordeel van de Commissie of mag zij een eigen inschatting van de situatie maken?

Werken met modelcontracten is dan ook de meest toegepaste optie op dit moment. De breed opgeschreven standaardclausules die de Europese Commissie publiceerde, kunnen worden gebruikt om een contract samen te stellen dat althans in theorie voldoet aan de eisen uit artikel 79 Wbp. In theorie, want uiteindelijk moet ook díe regeling voldoen aan het Charter. En gezien de overwegingen van het Hof omtrent de Amerikaanse toegang tot persoonsgegevens, ligt het in de rede dat zij ook de grootste moeite zal hebben met een verwerking in de VS op basis van een modelcontract. Immers, ook dan kan de Amerikaanse Justitie eenvoudigweg met een beroep op ‘national security’ bij de gegevens.

Het Hof van Justitie begint met vaststellen dat de bescherming van persoonsgegevens een afgeleide is van het fundamentele recht tot bescherming van de persoonlijke levenssfeer, zoals vastgelegd in het Handvest (Charter) van fundamentele rechten dat bindend EU-recht is. Langs deze weg zegt het Hof dus eigenlijk dat alle EU-wetgeving getoetst kan (en moet) worden aan de grondrechten. Dit toont aan dat het beschermen van persoonsgegevens van het grootste belang is, en de uitleg van regelingen zoals de richtlijn gegevensbescherming moet dus ook streng in het voordeel van deze grondrechten worden uitgevoerd.

Naar de Europese clouddiensten dan maar? Immers, data opgeslagen bij Amazon in Ierland of Microsoft in Brussel valt onder een dochtermaatschappij die gewoon onder Europees recht valt. Het is nog maar de vraag of dat gaat helpen. We hebben al een tijdje een slepende rechtszaak tussen Microsoft en de Amerikaanse overheid, met de vraag centraal of de overheid gegevens mag opeisen bij Microsoft-dochters in Europa. De rechter in eerste instantie zei van wel, het hoger beroep loopt. Als dát overeind blijft, zijn ook die datacenters verboden terrein voor Europese bedrijven.

In de richtlijn wordt expliciet gesproken van nationale toezichthouders, zoals het College Bescherming Persoonsgegevens, die verantwoordelijk zijn voor handhaving op de bepalingen uit de richtlijn. Deze toezichthouders behoren dus, aldus het Hof, het laatste woord te hebben. Bovendien mag de Europese Commissie niet zomaar vaststellen dat iets “geacht wordt” veilig te zijn; dat beslist die toezichthouder en – uiteraard – uiteindelijk het Hof van Justitie zelf. Zeker als de Commissie iets vaststelt dat in strijd lijkt te zijn met de fundamentele rechten uit het Charter.

Alles bij elkaar weinig positiefs dus. Uiteindelijk komt het erop neer dat eigenlijk de VS gewoon te onbetrouwbaar is om persoonsgegevens te parkeren. Echter, de economische afhankelijkheid bij ICT-diensten van Amerikaanse leveranciers is zó groot dat rigoreus kappen met die dienstverlening eenvoudigweg onhaalbaar is in de praktijk. Gaat er wat gebeuren? Het zou me dan ook verbazen. De impact is namelijk zo groot dat weinigen er aan zullen willen. Eerst maar eens een jurist zorgvuldig naar laten kijken, en dan afwachten wat de concurrent gaat doen. Want het kost gewoon gigantisch veel geld om gelijkwaardige diensten te vinden – als die er al zijn. Als de concurrent lekker op Amazon blijft zitten, dan ben je weliswaar legaal bezig maar commercieel heel dom.

Vervolgens toetst het Hof het Safe Harbor-convenant aan het Charter en komt vrij eenvoudig tot de conclusie dat het convenant niet geldig kan zijn. Zelfcertificering is op zich al onder de maat, maar het is een andere uitzondering waarop het convenant sneuvelt. Het convenant vermeldt namelijk expliciet dat Amerikaanse bedrijven vanuit ‘national security, public interest, or law enforcement requirements’ gehoor moeten geven aan nationale wetgeving, zelfs als dat in strijd zou zijn met de Safe Harbor-vereisten. Dat biedt een gat waar men een spreekwoordelijke vrachtwagen doorheen kan rijden. Dit is onmogelijk te rijmen met de Europese waarborgen omtrent persoonsgegevens, en het convenant kan dan ook niet anders dan ongeldig zijn.

Wellicht dat de nieuwe wetgeving persoonsgegevens per 1 januari hier wat in gaat veranderen. Die heet weliswaar meldplicht datalekken maar hij zet ook boetes op het exporteren van persoonsgegevens zonder juridische basis. Maar u kent mij als professioneel cynicus: het zou me verbazen. 27

3.3 HET PRIVACY SHIELD Sinds oktober 2015 is er hard naar een oplossing gezocht voor het wegvallen van het Safe Harbor-verdrag. De oplossing is nu gevonden in het ‘Privacy Shield’. Dit nieuwe verdrag moet een betere grondslag worden voor het doorsturen van Europese persoonsgegevens naar de VS en de problemen van Safe Harbor oplossen.

Op 29 februari 2016 werd het Privacy Shield bekend gemaakt door de Europese Commissie. Het blijft de vraag of Privacy Shield de privacy van Europese inwoners wel voldoende kan beschermen. Wat zijn nu de belangrijkste verschillen tussen Safe Harbor en Privacy Shield?

En in deze lijst van grondslagen zien wij gelijk al een heikel punt. Massasurveillance door de VS blijft gewoon toegestaan onder deze grondslagen. De grondslagen zijn dermate breed opgesteld dat er bijna altijd wel een grondslag door de Amerikaanse overheid gebruikt kan worden. Bijna altijd is er wel een argumentatie op te zetten die aantoont dat er ten behoeve van cybersecurity massasurveillance uitgevoerd moet worden. De Europese rechter heeft juist Safe Harbor afgeschoten vanwege de onbeperkte mogelijkheden voor massasurveillance. De vraag is dan ook of dit overeind als dit getoetst wordt door de Europese rechter.

Ten eerste worden er strengere eisen gesteld aan bedrijven in de VS. Er zal meer toezicht worden gehouden en er zullen sancties volgen als er niet volgens de wet- en regelgeving wordt gehandeld. Bij een aantal vormen van persoonsgegevensverwerking moet een opt-out geboden worden aan individuen, maar dat is lang niet bij alle vormen het geval.

Moeten we de VS geloven op hun mooie blauwe ogen? Er worden weliswaar waarborgen vastgesteld om de Amerikaanse overheid aan toezicht te binden, zoals de belofte van de Amerikaanse overheid dat zij zich aan de regels zullen houden. Alleen, wie controleert deze belofte? En in hoeverre moeten wij een dergelijke belofte nog serieus nemen na alle openbaringen van Snowden?

Ten tweede krijgen personen het recht om een klacht in te dienen bij bedrijven die persoonsgegevens verwerken, bedrijven moeten hierop binnen 45 dagen reageren. Als de klacht niet naar wens van de betrokkene wordt afgehandeld, dan kan middels alternatieve geschillenbeslechting getracht worden om een oplossing te vinden of bij een Privacy Shieldpanel. Europese burgers kunnen ook hun klacht neerleggen bij de nationale toezichthouder. De nationale toezichthouder kan dan besluiten het gehele dataverkeer van een bedrijf naar de VS stop te leggen.

Een andere garantie voor de privacy zou de aanstelling van een onafhankelijke ombudsman moeten zijn. De Europese Commissie geeft aan dat dit een grote verbetering is voor de Europese burger. Europese burgers kunnen bij deze ombudsman klachten neerleggen over gedrag van de Amerikaanse overheid inzake het gebruik van persoonsgegevens. Echter, ook hier geldt, hoe onafhankelijk is deze ombudsman? En in hoeverre wordt deze ombudsman in de mogelijkheid gesteld om dit toezicht uit te voeren en klachten af te handelen?

Ten derde worden de rechten en de plichten van de Amerikaanse overheid beter vastgelegd. De Amerikaanse overheid wordt gebonden aan zes grondslagen om massasurveillance uit te mogen voeren; het opsporen en tegengaan van spionage van andere landen, het tegengaan van terrorisme, het tegengaan van de verspreiding van massavernietigingswapens, cybersecurity, het opsporen van bedreigingen voor de V.S. of haar bondgenoten en het opsporen van grensoverschrijdende criminaliteit.

28

De artikel 29 werkgroep

Bij de implementatie wordt het volgende voorlopige tijdspad verwacht:

Op 13 april heeft de artikel 29 werkgroep, een samenwerkingsverband van de nationale toezichthouders van alle Europese landen, zijn mening gegeven over het Privacy Shield. De werkgroep is tevreden over een aantal verbeteringen ten opzichte van het Safe Harbor-verdrag, zoals het aanstellen van een ombudsman, al zet de werkgroep ook vraagtekens bij de onafhankelijkheid van deze ombudsman. De werkgroep is ook van mening dat de privacy van Europese burgers niet voldoende is gewaarborgd met het Privacy Shield. Zo heeft de werkgroep zijn twijfels of Europeanen hun rechten goed kunnen uitoefenen en of de mogelijkheden om te klagen niet te beperkt en te complex zijn. Daarnaast maakt de werkgroep zich zorgen over de mogelijkheden van Amerikaanse geheime diensten om alsnog tot surveillance over te gaan, terwijl juist deze massasurveillance een van de redenen was om Safe Harbor te vernietigen.

1 juli 2016:

Volledige implementatie van het Privacy Shield.

Begin 2017:

Start handhaving van het Privacy Shield met bijbehorende controles.

Midden 2017: Gezamenlijke evaluatie tussen de EU en de VS over het verdrag.

Conclusie Hoewel de Europese Commissie het Privacy Shield heeft aangekondigd als dé oplossing voor alle problemen met Safe Harbor, is het maar de vraag of Privacy Shield ook daadwerkelijk een goede vervanger is. Massasurveillance blijft in feite gewoon toegestaan onder Privacy Shield. Ondanks dat de Amerikaanse overheid heeft beloofd dat zij zich zal onthouden van dergelijke inbreuken, durven wij hierbij vraagtekens te zetten. Het verleden heeft geleerd dat de Amerikaanse overheid niet geheel te vertrouwen is als het gaat om het respecteren van de privacy van Europese burgers. Op het Privacy Shield is al veel kritiek geuit door diverse belangenorganisaties. Als het Privacy Shield in de huidige vorm wordt aangenomen, dan is het waarschijnlijk dat het Hof van Justitie zich hierover zal gaan buigen.

De artikel 29 werkgroep dringt er bij de Europese Commissie op aan om de pijnpunten binnen het Privacy Shield weg te nemen en te zorgen voor een verdrag dat de privacy van Europeanen écht garandeert. De uitspraak van de werkgroep is enkel een advies aan de Europese Commissie. De Europese Commissie kan besluiten dit advies naast zich neer te leggen.

En nu? Het Europees Parlement moet nu het Privacy Shield gaan bekijken. Als zij hiermee akkoord gaan, dan kan daarna de Europese Commissie een definitieve beslissing nemen over het Privacy Shield. Het afwijzen van het Privacy Shield kan enorme gevolgen hebben voor de gegevensdoorgifte van Europa naar de VS. Het is dus daarom niet erg waarschijnlijk dat de Europese Commissie het Privacy Shield alsnog laat vallen. Maar of het overeind blijft bij het Hof van Justitie, blijft de vraag.

29

CHECKLIST 4.1 HEEFT U AL BELEID OVER DE DATALEKMELDPLICHT? Op 1 januari 2016 treedt de Wet Datalekmeldplicht in werking.Vanaf dat moment moeten bedrijven bij de toezichthouder én de consument melding doen van datalekken, oftewel inbraken en beveiligingslekken waardoor persoonsgegevens zijn ontvreemd.Wordt er niet gemeld, of blijkt na melding dat een bedrijf nalatig was, dan kunnen tot acht ton aan bestuurlijke boetes worden opgelegd. De hoogste tijd dus om beleid in te voeren, zodat uw organisatie klaar is voor deze nieuwe plicht.

Datalekken

Hierbij geldt wel de grens dat uw beveiliging niet perfect hoeft te zijn. De wet spreekt van een “passend beveiligingsniveau” gelet op de risico’s die de verwerking en de aard van te beschermen gegevens met zich meebrengen. Voor patiëntdossiers moeten dus strengere beveiligingsmaatregelen worden genomen dan voor het adressenbestand van de nieuwsbrief. Een zeer geavanceerde inbraak op dit laatste bestand zou dan géén datalek zijn, omdat de kosten en complexiteit om u daartegen te wapenen niet opwegen tegen de aard van deze gegevens. Eenzelfde inbraak op patiëntendossiers zou dan wel een datalek zijn, omdat men bij dergelijke gegevens nu eenmaal meer beveiliging mag verwachten.

Datalekken, oftewel inbreuken op de beveiliging van persoonsgegevens, zijn al een paar jaar een hot item in de pers. Nu bedrijven en instellingen steeds meer persoonsgegevens opslaan en daarbij steeds vaker deze via internet toegankelijk blijken, is de kans steeds groter dat persoonsgegevens worden ontvreemd, misbruikt of per abuis worden gepubliceerd. Vandaar dat de Wet bescherming persoonsgegevens onlangs is gewijzigd en een meldplicht over datalekken heeft opgenomen. Zo weten mensen wanneer zij hier nadeel van kunnen ondervinden, zodat zij maatregelen kunnen nemen zoals het wijzigen van hun creditcard of extra aandachtig zijn bij phishing-mails of andere oplichterstrucs die met deze persoonsgegevens kunnen worden uitgehaald.

Meldplicht Datalekken moeten worden gemeld. Hiermee weten betrokkenen dat er een probleem is, en ook de toezichthouder kan dan optreden. Er zijn dan ook twee meldplichten:

Wellicht denkt u bij de term ‘datalek’ aan een grootschalige inbraak waarbij alle klantgegevens worden gedownload, of een publicatie op een Russische hackersite van patiëntdossiers. De wettelijke definitie is echter veel breder. Iedere inbreuk op de beveiliging van persoonsgegevens wordt gezien als een datalek. En de wet (art. 13 Wbp) noemt “verlies of enige vorm van onrechtmatige verwerking” als een inbreuk. Ook wanneer gegevens binnen uw organisatie dus op te vragen zijn door ongeautoriseerde medewerkers, is strikt gesproken sprake van een datalek. Voor webwinkels of sites met online inschrijf- of bestelformulieren zou al sprake zijn van een datalek wanneer deze formulieren niet over een beveiligde verbinding (SSL) worden verzonden.

1. Melding aan de toezichthouder. Een datalek moet worden gemeld wanneer deze “leidt tot de aanzienlijke kans op ernstige nadelige gevolgen” of daadwerkelijk die gevolgen heeft. Meldingen aan de toezichthouder zijn vertrouwelijk. 2. Melding aan betrokkenen. Consumenten moeten worden geïnformeerd over een datalek dat hen aangaat wanneer dit lek “waarschijnlijk ongunstige gevolgen zal hebben voor diens persoonlijke levenssfeer”.

30

Voor beide meldingen moet u zelf de afweging maken of deze noodzakelijk is. Maakt u echter geen zorgvuldige afweging, dan kan dat tot een boete leiden. Het motto zal wat ons betreft dus zijn, liever drie keer nodeloos melden dan één keer een serieuze melding nalaten. Overigens kan de toezichthouder u opdragen alsnog een melding aan betrokkenen te doen.

artikel 13 Wbp krachtens welke wij u hierbij informeren dat mogelijk sprake kan zijn van ongunstige gevolgen voor uw persoonlijke levenssfeer”; u moet mensen melden “Er is een inbraak in onze administratie geweest en daarbij zijn uw naam en adresgegevens gekopieerd”.

Geen meldplicht Geen meldplicht bestaat wanneer de gelekte persoonsgegevens onbegrijpelijk of ontoegankelijk waren voor de ontvreemder. Dit zal met name spelen wanneer de persoonsgegevens middels versleuteling (encryptie) zijn beveiligd. Zulke beveiliging maakt gegevens immers onleesbaar wanneer men de sleutel niet kent. Ook andere vormen van onbegrijpelijk of ontoegankelijk maken, vallen hier onder. Vervoert u bijvoorbeeld papieren dossiers in een plofkoffer (die de dossiers onleesbaar maakt door er verf overheen te lekken bij ontvreemding), dan voldoet u ook aan deze eis.

Beide meldingen moeten vermelden om wat voor soort lek het gaat, waar meer informatie over het lek kan worden verkregen en wat u aanraadt om de negatieve gevolgen van het datalek te beperken. Aan de toezichthouder moet u aanvullend nog melden welke gevolgen het datalek zal hebben en wat u heeft gedaan (en gaat doen) om het lek te dichten en de gevolgen te beperken. Voor de duidelijkheid: een melding moet óók worden gedaan wanneer u meent dat de inbraak niet te voorkomen was en uw beveiliging passend was gezien de aard van de gegevens en de te verwachten risico’s. Het gaat er bij melding immers om dat toezichthouder en betrokkenen actie kunnen ondernemen tegen de te verwachten negatieve gevolgen.

Boetebevoegdheid Handhaving van de Wet bescherming persoonsgegevens is altijd een beetje een ondergeschoven kindje gebleven. De reden hiervoor lag met name in de zeer beperkte boetebevoegdheid van de toezichthouder. De nieuwe wet brengt hier verandering in. Op overtreding van vrijwel elke plicht uit de Wbp komt nu een boete te staan. Dit geldt ook voor het niet hebben van een adequate beveiliging en voor het niet melden wanneer men daartoe verplicht was. Deze boete kan in theorie oplopen tot € 810.000, de hoogste categorie uit het bestuursrecht. Echter, de toezichthouder zal wel eerst beleid moeten publiceren over welke soort boetes worden gesteld op welke soorten overtredingen. In beginsel kunnen overtredingen pas worden beboet nadat een bindende aanwijzing is opgelegd die niet wordt opgevolgd. Een bindende aanwijzing is een last (art. 5:2 Awb) die is opgelegd na een overtreding, bijvoorbeeld hoe de beveiliging moet worden aangescherpt. Echter, wanneer de overtreding opzettelijk is begaan of het gevolg is van “ernstig verwijtbare nalatigheid”, mag de toezichthouder direct een boete opleggen. Wanneer van dit laatste sprake is, is nog niet duidelijk. De term lijkt op het civielrechtelijke begrip “grove nalatigheid” maar in de context van bestuursrecht is dit geen gebruikelijke constructie. Het lijkt ons echter dat wanneer u geen beleid heeft omtrent het signaleren en melden van datalekken, er al snel sprake kan zijn van ernstig verwijtbare nalatigheid.

Informatievoorziening De wet eist dat de melding een “behoorlijke en zorgvuldige informatievoorziening” realiseert. Daarbij moet u rekening houden met het soort datalek en het soort gegevens maar ook vooral met “de kring van betrokkenen”. Dit betekent dat de taal van de melding afgestemd moet zijn op de ontvanger. In het algemeen mag dus niet volstaan worden met een formele brief in juridische taal die de ontvanger informeert over “een potentiële schending van beveiligingsplichten ex

Praktische aanpak De hoogste tijd dus om uw organisatie datalek-aware te maken. In de checklist hierna vindt u een aantal praktische punten. Het belangrijkste is dat mensen beseffen wanneer sprake is van een datalek. Dat hoeft zoals gezegd geen

31

complexe inbraak of grootschalige publicatie van gestolen gegevens te zijn. Het kwijtraken van een USB-stick met persoonsgegevens, of het in de oudpapierbak doen van uitgeprinte persoonsgegevens is ook al een datalek. Besef in combinatie met een duidelijk protocol waar meldingen te doen, is voor veel organisaties al genoeg zich te wapenen tegen de meeste datalekken. Overweeg enkele zichtbare maatregelen in te voeren die

concreet het probleem aanstippen, zoals het verstrekken van beveiligde USB-sticks zodat gegevens alleen met een wachtwoord toegankelijk zijn. Of plaats shredders naast de oudpapierbak. Sommige organisaties identificeren snel zwakke punten met een prijsvraag “Spot het datalek”: laat mensen situaties aandragen waarbij persoonsgegevens zichtbaar of kwetsbaar zijn waar dat niet de bedoeling is.

CHECKLIST ☑

☑

☑

Communiceer het bestaan van de datalekmeldplicht binnen de organisatie. Gebruik concrete voorbeelden die binnen uw organisatie kunnen voorkomen, zoals diefstal van laptops, ongeautoriseerde toegang tot klanten- of werknemersbestanden of het per abuis versturen van Excel-bestanden met persoonlijke informatie. Stel een protocol op waarbij duidelijk is aan wie intern moet worden gemeld, en wie vervolgens beslist over melding naar toezichthouder of betrokkenen. Bijvoorbeeld: o Iedere werknemer die een datalek vermoedt, dient dit te melden bij zijn direct leidinggevende. o Indien een leidinggevende van mening is dat het vermoeden serieus is, meldt het datalek bij de functionaris gegevensbescherming (FG) of bedrijfsjurist en bij de eindverantwoordelijke voor het betreffende bedrijfsproces. o De FG, bedrijfsjurist en eindverantwoordelijke beslissen gezamenlijk of een melding wordt gedaan. Dit besluit wordt gemeld aan de directie, die uiteindelijk de knoop doorhakt om te melden (of niet). Stel standaardteksten op over datalekken, die kunnen worden gebruikt om snel een melding naar betrokkenen te kunnen doen. Houd daarbij de doelgroep voor ogen en vermijd juridisch jargon.

32

☑

Registreer intern alle inbreuken op de beveiliging die als datalek kunnen kwalificeren. U bent dit wettelijk verplicht, los van of u deze inbreuken moet melden.

☑

Neem in uw bewerkersovereenkomsten een regeling op over het melden van datalekken die bij een bewerker optreden. U kunt daarbij kiezen voor: 1. De bewerker verstrekt de verantwoordelijke alle informatie, waarna deze de melding doet; 2. De bewerker meldt zelf bij de toezichthouder en betrokkenen; 3. De bewerker en de verantwoordelijke overleggen na een datalek wie de melding zal doen.

☑

Werk in bewerkersovereenkomsten uit wie opdraait voor een eventuele boete. Volgens de wet kan zowel de verantwoordelijke als de bewerker worden beboet, maar de bewerker alleen voor zover het datalek hem kan worden toegerekend.

☑

Neem in ICT-leveringsovereenkomsten garanties tegen datalekken op, waarbij de leverancier aansprakelijk wordt voor schade en boetes wanneer zijn software of diensten bij u tot datalekken leidt.

☑

Organiseer een ‘brandoefening’ waarbij een fictief datalek optreedt om na te gaan of de organisatie hier werkelijk mee om kan gaan.

4.2 AANDACHT VOOR AANSPRAKELIJKHEID Weinig vakgebieden waar zo driftig wordt geëxonereerd als in de ICT. Dit is begrijpelijk, aangezien de ICT een jong vakgebied is waar veel wordt geëxperimenteerd met nieuwe diensten, en waar het bovendien lastig is om fouten uit te sluiten. Het is bijvoorbeeld praktisch onmogelijk foutloze software te leveren of een SaaS-dienst permanent ongestoord beschikbaar te houden. Hoe vindt u nu een goede balans in een exoneratiebeding?

CHECKLIST Een goed aansprakelijkheidsbeding ☑ Is de polis opvraagbaar? Wilt u weten wat er in de polis staat en daar iets van vinden?

☑ Is de financiële grens eenvoudig objectief vast te stellen? Welke facturen tellen mee, over welke periode wordt gekeken en speelt btw op de factuur een rol of niet?

☑ Wordt expliciet vermeld dat de verzekering in stand moet blijven gedurende de looptijd van de overeenkomst?

☑ Staat de financiële grens in een reële verhouding tot de waarde van de overeenkomst? ☑ Als de grens wordt bepaald als een x aantal facturen, moeten deze dan ook betaald zijn om mee te tellen?

☑ Als directe en indirecte schade wordt onderscheiden, is dan een definitie van beiden opgenomen? En dekken deze definities tezamen álle vormen van schade?

☑ Heeft de ICT-leverancier een verzekering voor de schade?

☑ Is een uitzondering gemaakt voor opzet en bewuste roekeloosheid?

☑ Dekt deze expliciet beroepsaansprakelijkheid?

☑ Binnen welke termijn moeten aansprakelijkheidsstellingen worden gedaan?

☑ Is de aansprakelijkheid beperkt tot hetgeen de verzekering uitkeert of wordt een financiële grens getrokken en moet de leverancier los daarvan een verzekering hebben?

☑ Wordt hierbij te allen tijde een expliciete ingebrekestelling geëist of wordt aangesloten bij het wettelijk systeem waarbij dit soms niet nodig is?

☑ Worden eisen gesteld aan de inhoud van de verzekering?

33

4.3 CHECKLIST SERVICE LEVEL AGREEMENT

Tegenwoordig wordt steeds meer informatie online verwerkt. Hierbij wordt er over het algemeen gebruikgemaakt van SaaS- en cloudaanbieders. Deze aanbieders bieden hun specifieke software (bijvoorbeeld voor uw klantenadministratie) aan via online platformen en verschillende apps. Dit betekent dat u op ieder moment bij de data kan komen en deze data kan wijzigen.

Dat deze data ook op ieder moment beschikbaar is, is door verloop van tijd een gewoonte geworden. Verandering van de werktijden en flexibilisering van het thuiswerken of op locatie is hier over het algemeen de oorzaak van. Doordat de belangrijke gegevens worden opgeslagen bij een derde, bent u afhankelijk van deze partij. Bij een storing kunt u de data immers niet meer inzien of wijzigen, waardoor u uw werkzaamheden niet kan voortzetten. Dit kan behoorlijke gevolgen met zich meebrengen, waaronder schade als het gevolg van het niet kunnen halen van deadlines. Het is dan ook van groot belang dat u na een storing weer zo snel mogelijk aan de slag kan en liever nog wilt u dat er helemaal geen storing mogelijk is.

te werken als een ‘goed opdrachtnemer’. Een goed opdrachtnemer doet zijn best, werkt nauwkeurig en conform de verwachtingen en is aansprakelijk voor zijn fouten. Vaak neemt de dienstverlener in de overeenkomst op dat het bedrijf haar uiterste best doet om de website in de lucht te houden, óf er is zelfs helemaal niets opgenomen over de beschikbaarheid. Hier zijn de prijzen van de diensten dan ook naar. Toch wilt u specifieke afspraken maken met betrekking tot de beschikbaarheid omdat u zekerheid wilt hebben. Zo moet de dienst 99,9% van de tijd beschikbaar zijn, mag onderhoud alleen ’s nachts plaatsvinden en moet de aanbieder binnen één uur reageren op een storingsmelding. Dit zijn allemaal standaardafspraken die u maakt met de dienstverlener. Ook over de schadevergoeding dienen er afspraken te worden gemaakt. Zonder een dergelijke afspraak zal de dienstverlener aansprakelijk zijn voor de door u geleden schade.

De meeste SaaS-aanbieders en hostingbedrijven geven in eerste instantie weinig garanties met betrekking tot de beschikbaarheid. Op grond van de wet dient de dienstverlener

34

Wanneer de schade moeilijk te bepalen is, is het ook moeilijk om een vergoeding te eisen. U zult immers de schade moeten kunnen bewijzen. Daarom wordt de schadevergoeding vaak gefixeerd op een bepaald bedrag per storingsincident. Deze afspraken zullen worden vastgelegd in een afzonderlijke overeenkomst, de Service Level Agreement ofwel SLA. In deze overeenkomst zullen de precieze afspraken met betrekking tot de beschikbaarheid worden vastgelegd en zullen ook de afspraken omtrent schadevergoedingen worden opgenomen. Veelal hanteren de dienstverleners een standaard-SLA. SLA’s hebben verschillende serviceniveaus. Hoe meer u als afnemer betaalt, hoe meer garanties u krijgt van de dienstverlener. Het is toch de vraag of met deze standaard-SLA’s alle risico’s op de juiste wijze worden afgedekt. Daarom is het van belang om goed te kijken naar de gevolgen bij storingen, de omschrijving van wat een storing precies is en wie voor welke storing verantwoordelijk is. Het is verstandig om naast deze generieke afspraken, ook te kijken naar de aanvullende afspraken. Wij hebben voor u de belangrijkste zaken op een rijtje gezet.

CHECKLIST ● Zorg er voor dat duidelijk is wie welke verantwoordelijkheden heeft;

● Neem eventueel oplostijden op in de overeenkomst; ● Neem de contactgegevens op van de verantwoordelijke die op de hoogte gesteld dient te worden van de storingen en zorg er voor dat wijzigingen tijdig bekend zullen worden gemaakt;

● Geef duidelijk aan wat onder ‘ondersteuning’ valt en voor welke werkzaamheden kosten in rekening worden gebracht; ● Maak ook afspraken over de kosten voor eventueel meerwerk;

● Maak afspraken over het monitoren van de beschikbaarheidsgaranties en de periodieke rapportage van die cijfers;

● Maak afspraken over het maken van backups (hoe vaak, wanneer, waarvan), het bewaren en het terugzetten daarvan;

● Zorg voor een boeteclausule en een duidelijke omschrijving van wanneer de boete is verschuldigd;

● Neem een bepaling over de beschikbaarheid op, eventueel gedifferentieerd op type

● Maak duidelijk wie er verantwoordelijk is voor het claimen van de verschuldigde boete;

● beschikbaarheid (dienst, netwerk, stroom);

● Neem een bepaling op over de evaluatie van een bepaalde periode en de bijbehorende rapportages;

● Maak een scheiding tussen de impact en urgentie van de verschillende storingen en verwerk dit in een impact- en urgentiematrix;

● Maak afspraken over de kosten voor het in stand houden van de SLA;

● Verbind acties aan de storingen op basis van de impact- en urgentieniveau’s;

● Zorg er voor dat de overeenkomst enkel met wederzijds goedvinden kan worden gewijzigd;

● Geef duidelijk aan welke responstijden gehanteerd dienen te worden bij de verschillende impact- en urgentieniveau’s;

● Laat de SLA meelopen met de hoofdovereenkomst en zorg er voor dat de SLA eindigt wanneer de hoofdovereenkomst eindigt.

35

Meer informatie: @DutchDatacenter www.dutchdatacenters.nl

36