Datacenter en Recht ICTRECHT

Transcriptie

1 2016 Datacenter en Recht ICTRECHT

2 COLOFON Datacenter Visie is een uitgave van Dutch Datacenter Association (DDA), de branche organisatie voor commerciële datacenters in Nederland. De 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 DDA is deelnemer van DINL, EUDCA en de Digital Gateway to Europe. Redactie E. W. 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 Marketing & artwork Noor van den Bogaard (DDA) Michiel Cazemier, Gaby Dam (Splend) Editie Datacenter & Recht 2016: Jaargang 1, nummer 1, mei 2016 Print oplage 100 Beschikbaarheid Onze publicaties zijn gratis te downloaden op

3 INHOUD Hoofdstuk 1 - Contractering algemeen 1.1 Contractsluiting in de ICT Aandacht voor aansprakelijkheid 13 Hoofdstuk 2 - Continuïteit 2.1 Factsheet Continuïteit in de cloud Blog: Continuïteit: hoe regelt u dat? De curator krijgt recht op toegang tot de cloud 21 Hoofdstuk 3 - Privacy 3.1 Impact van de meldplicht datalekken Safe Harbor ongeldig Het Privacy Shield 28 Hoofdstuk 4. - Checklist 4.1 Heeft u al beleid over de datalekmeldplicht? Aandacht voor aansprakelijkheid Checklist Service Level Agreement 34 3

4 GRAAG STELLEN WIJ AAN U VOOR: ONZE DEELNEMERS 4

5 ONZE PARTNERS Perf-it ICTRECHT 5

6 6

7 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 8

9 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 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). 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. Een uitzondering op deze regel geldt wanneer de overeenkomst per , Skype of dergelijke individuele communicatie tot stand komt. Er is dan dus geen document nodig. Uiteraard kunnen in deze situaties bewijsproblemen 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). 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). 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 9

10 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. 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. 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). 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 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). 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

11 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. 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. 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. 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 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. 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. 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. 11

12 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. 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. 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. 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. 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. 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 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. 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. 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

13 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 Gebruikelijk is de aansprakelijkheid te beperken door een financiële grens ( cap ) te 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. 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. 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. 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. Bij duurovereenkomsten kan de formulering aan een aantal facturen worden opgehangen: 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 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 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: Aansprakelijkheid is beperkt tot hetgeen de verzekeraar van Leverancier ter zake uitkeert. Vindt geen uitkering plaats, dan is de aansprakelijkheid beperkt tot 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 13

14 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: 3. 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. 4. 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. 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. 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. Vier opties bij verzekeren Als geen deugdelijke verzekering aanwezig is bij de leverancier, zijn er vier opties: 1. 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. 2. 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. 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. Directe versus indirecte schade 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. 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 15

16 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 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). 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. 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. 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. 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

17 Consumentenrecht 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 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. 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

18 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 dienst 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

19 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 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 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. 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. 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. 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. 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. 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. 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 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

20 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? 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. 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. 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. 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. 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. 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. Juridische antwoorden op de andere risico s van de cloud: beveiliging en privacy, komen in volgende blogs aan de orde. 20

21 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. 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. 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. 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. 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 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): 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. 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. 21

22 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 ,- of 10% van de jaaromzet per overtreding. Wat betekent dit voor uw bedrijf? 1. Wat is een datalek? 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. 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. 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. 2. Wanneer moet u een datalek melden aan de toezichthouder? 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: 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? 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