Tag: verwerkersovereenkomst

About verwerkersovereenkomst

Subscribe Feeds

Microsoft maakt einde aan wachtwoorden, andere techbedrijven voorlopig niet

Geplaatst op in Security, 19 reacties

Microsoft kondigde onlangs aan gebruikers de keuze te bieden zonder wachtwoorden in te loggen, zo las ik bij Nutech.nl. Wie dat wil, kan sinds kort het wachtwoord van zijn Microsoft-account verwijderen en inloggen met gezichtsherkenning, een toegestuurde sms- of mailcode, een codegenerator of een fysieke sleutel. Op zich natuurlijk geen juridisch nieuws, maar ik licht het er toch even uit omdat a) security ontzettend belangrijk is binnen de ict en b) juristen zich regelmatig tegen wachtwoordbeleid aan bemoeien.

Microsoft maakt de stap omdat wachtwoorden fundamenteel onveilig zijn. Ze kunnen worden afgekeken, geraden of uit datalekken afgeleid. Eigenlijk was het altijd al een hele rare keuze, wachtwoorden. Mensen iets laten doen waar computers heel goed in zijn en mensen niet (onthoud acht tekens, waarvan minstens drie hoofdletters, minimaal één cijfer en één leesteken maar niet als eerste teken, u kent het wel), hoe kom je er bij. Maar goed, in de jaren zeventig was dat de enige logische keuze.

Ook het wijzigen van wachtwoorden komt uit die tijd. Het Amerikaanse ministerie van Defensie had recent ontdekt dat aanvallers wachtwoorden konden kraken, zelfs als ze versleuteld waren opgeslagen. Het terugrekenen van de versleuteling (jaja, ik weet het maar leg jij rainbow tables eens uit in gewone taal) kostte ongeveer zes weken, zo was de inschatting. De praktische oplossing: elke maand een nieuw wachtwoord, dan is de informatie voor de criminele aanvaller verouderd voordat deze hem gevonden heeft. Die regel belandde ergens in de algemene kennis van de ICT-securityspecialisten – en de juristen, want dit is praktische regelgeving en dat is hardnekkiger dan de Grondwet om te veranderen.

Al geruime tijd is er een verbetering, namelijk tweefactorauthenticatie. Daarbij heb je naast je wachtwoord ook bijvoorbeeld een vingerafdruk nodig of een fysiek token. Dat scheelt in het aanvalsgemak, maar:

Veel vormen van 2FA berusten nog steeds op het inloggen met wachtwoorden, wat deze manier van inloggen nog steeds kwetsbaar maakt voor aanvallen van buitenaf. Het is veiliger dan inloggen met alleen een wachtwoord, maar de kwetsbaarheden van het wachtwoord worden niet weggenomen.
Wie dat wil, kan sinds kort het wachtwoord van zijn Microsoft-account verwijderen en inloggen met gezichtsherkenning, een toegestuurde sms- of mailcode, een codegenerator of een fysieke sleutel. Dat is echt een stap vooruit, en ik hoop dan ook dat andere bedrijven snel gaan volgen. (Ik gebruik zelf al lange tijd een Bluetooth-koppeling: als mijn telefoon (die in mijn zak zit) te ver van mijn laptop is, dan gaat mijn laptop op slot. Een wachtwoord draagt daar niets meer aan bij.)

Het juridische haakje: u mag nu even de verwerkersovereenkomsten controleren op uw passende technische en organisatorische maatregelen onder artikel 32 AVG die u opgelegd zijn of die u aan verwerkers oplegt. Afgaande op de paar duizend verwerkersovereenkomsten uit onze contractenscanner staat daar namelijk in dat men sterke wachtwoorden moet hanteren (32% van de clausules) en maar zelden iets over 2FA (4%). Regelmatig wijzigen van wachtwoorden staat vrijwel altijd (78%) bij die wachtwoordclausules, wat binnen de securitywereld juist een slecht idee is – dan krijg je welkom42 of X5j13$#eOktober als wachtwoorden. Tijd dus om hier nieuwe regels over in te voeren.

Meelezende juristen en compliance officers: ondersteunt jouw securitybeleid en/of VO het gebruik van wachtwoordloze authenticatie?

Arnoud

RDC mag miljoenen Nederlandse autobezitters niet over datalek informeren

Geplaatst op in Privacy, 15 reacties

Ict-bedrijf RDC, waar de gegevens van miljoenen Nederlandse autobezitters werden gestolen, mag getroffen personen naar eigen zeggen niet over het datalek informeren. Dat meldde Security.nl onlangs. Het zou gaan om herleidbare gegevens van mogelijk 7,3 miljoen personen (afhankelijk van hoe veel dubbels er in de data zitten). Behalve om NAW-gegevens gaat het ook om e-mailadressen, kentekens, telefoonnummers en geboortedata, ideaal voor gerichte phishing natuurlijk. Maar RDC mag niets zeggen, omdat ze verwerker is.

Onduidelijk is hoe de datadiefstal kon gebeuren. De NOS (hoi Joost) ontdekte dat de data te koop stond, maar de RDC had vooralsnog geen verklaring over het hoe en wat. Wel heeft men direct een melding bij de Autoriteit Persoonsgegevens gedaan, en de autohandelaren voor wie zij werken ingelicht.

De RDC biedt het product AutoMotive Dashboard (AMD) aan. Dit “biedt u een geïntegreerd platform met databases en functionaliteit voor het analyseren van statistische automotive marktinformatie.” Hiervoor krijgt men data van de RDW, zoals informatie over de vervaldatum van apk-keuringen en grove informatie over de eigenaren van auto’s, zoals de cijfers van de postcode en geboortejaar.

En nee, dat is niet hetzelfde als NAW-gegevens, e-mailadressen, telefoonnummers, geboortedata et cetera. Kennelijk levert de RDW ruwe data aan RDC, die dan gaat anonimiseren? Dat lijkt me risicovol en onnodig, maar een andere verklaring heb ik niet.

In ieder geval, als RDC verwerker is van deze persoonsgegevens dan mag zij niet zelf een datalek melden bij de betrokkenen. De AVG legt die plicht nadrukkelijk bij de verwerkingsverantwoordelijke, hier dus de Rijksdienst voor het wegverkeer. RDC moet het datalek doorgeven aan die verantwoordelijke, daarna moet die beslissen of het datalek meldingsplichtig is. Dat is hier natuurlijk een gegeven, maar het is wel de RDW haar beslissing.

Het doet wel raar aan, want als het lek bij RDC zit dan kunnen die het beste aangeven wat er is gebeurd en wat er is gelekt. Maar omdat je als betrokkene uiteindelijk niets te maken hebt met uitbesteedpartijen en zorgvuldig geselecteerde partners, klopt het juridisch wel. De RDW meldt het aan jou, en als je dan claims hebt dan dien je die bij de RDW in. Die lost het intern maar op met RDC.

Arnoud

Wie met verwerkersovereenkomsten smijt, snapt niets van de AVG

Geplaatst op in Privacy, 7 reacties

Het is mijn verjaardag en dan mag ik even wat korter door de bocht dan normaal zijn: wie met verwerkersovereenkomsten gooit, snapt niets van de AVG. Een beetje een standaardverhaal opdringen aan je leveranciers, gewoon omdat het voor de compliance moet en zonder enige overweging wat je nu echt aan het afspreken bent. Kom nou toch.

De verwerkersovereenkomst is een raar ding in contractenland, en niet alleen omdat ‘ie de verkeerde naam heeft (huurderscontract? arbeidersovereenkomst? hypotheekgeverscontract?). De voornaamste reden is dat hij vrijwel altijd verkeerd wordt ingezet en ondertussen een heel onderhandelproces ernstig kan frustreren of zelfs tegenwerken. Daarom roep ik al tijden dat we ermee moeten stoppen. Maar ja, het moet van de AVG hè, dat document.

Eh, nee. Als je de AVG er bij pakt dan zie je dat je inderdaad verplicht bent bindende afspraken met je verwerkers te maken over wat ze gaan doen en hoe ze daarbij jou moeten helpen AVG compliant te blijven. Dat is ooit (in Wbp-tijd) praktisch uitgewerkt met het instrument van de bewerkersovereenkomst, wat niet zo raar was in een tijd dat er vaak zonder schriftelijk contract (hooguit een offerte, misschien algemene voorwaarden) diensten werden geleverd. Tegenwoordig is dat natuurlijk allang niet meer zo.

Toch blijven veel mensen het ding op tafel leggen als er een dienstcontract moet worden gesloten. Dat is dan meestal “de template” met als je mazzel hebt een bijlage 1 die ongeveer beschrijft wat er gebeurt in de hoofdovereenkomst. Maar de werkelijke verwerkersbepalingen zijn generiek – vrijwel altijd omdat ze de AVG klakkeloos overpennen met wat standaardfrases er omheen.

Daar heb je dus niets aan. De reden is simpel: de AVG eist dat je régelt dat je verwerker zich aan die eisen uit de wet houdt, en dat kan alleen door maatwerkafspraken te maken. Of in ieder geval door concreet te zeggen wát bijvoorbeeld die “adequate beveiliging” is die je keurig overpent uit artikel 32 AVG. Niet door enkel te zeggen dat verwerker zulks garandeert en verwerkingsverantwoordelijke dienaangaande vrijwaart. Dat is jezelf er lui van afmaken, niet willen nagaan wat de verwerker echt doet en denken dat een contractuele aansprakelijkheid of boete achteraf goed genoeg is naar je betrokkenen toe. Nee. Je moet voorkomen dat er dingen misgaat. Dáár zijn die verwerkersafspraken voor.

Dit is waarom ik al een hele tijd pleit voor verwerkersbepalingen in de hoofdovereenkomst. Bevestig dat het security incident protocol ook opgaat bij datalekken. Leg vast dat inzageverzoeken óók door de helpdesk worden opgepakt maar dat mensen geen geld gerekend wordt. En schrijf letterlijk op dat de security policy uit bijlage 3 door partijen als adequaat wordt gezien – met herzieningsprocedure natuurlijk. Durf je dat niet? Dan ga je dus in zee met een verwerker waarvan je niet durft te zeggen of ‘ie adequaat beveiligd is.

En oké, dat kan ook prima als een apart document. Dan houd je dat sausje dat je “een verwerkersovereenkomst” hebt, zodat je in je compliance rapport kunt zeggen dat je met al je verwerkers overeenkomsten hebt. Maar wat je dan dus hebt, is een document dat in elk artikel zegt waar die afspraken staan over inzagerechten, waarom de beveiliging adequaat is enzovoorts. Dan is het eigenlijk een checklist dat je echte contract aan de AVG voldoet, in plaats van een dubbeloptekst met vage frases.

Arnoud
PS: beetje laat, sorry Dick

Hoe hou je je verwerkersovereenkomsten op één lijn?

Geplaatst op in Ondernemingsvrijheid, Privacy, 6 reacties

Een lezer vroeg me:

Als ICT-dienstverlener krijg ik van al mijn klanten verwerkersovereenkomsten. Dat is tot daar aan toe, ik ben eigenlijk altijd ook wel verwerker. Maar iedereen doet het weer anders – en eist daarbij ook nog eens wat anders dan wat mijn leveranciers mij kunnen bieden. Hoe hou je dat nou op een praktische manier op één lijn, hoe zorg je er voor dat al die afspraken blijven kloppen? Is het echt de bedoeling van de AVG dat je bij iedere klant je contracten met de leveranciers gaat openbreken?

Ah, die verwerkersovereenkomst. Het blijft spijtig dat ze ’t ding niet afgeschaft hebben bij de AVG want het is een van de grootste tijdverspillers in de contractering. Zelden zo’n stukje contracten cargo culting gezien. Wat mij betreft blijft het devies: stoppen met dat ding. Maak scherpe privacy-specifieke afspraken in je SLA en je zit goed.

Oké, ik ben alweer rustig. Want het is een feit dat iedereen denkt dat je aparte documenten met aparte afspraken nodig hebt. En dat iedereen het anders doet, want elke casus is uniek en vereist de toegewijze inzet van een zeer ervaren jurist die op maat gesneden clausules produceert om het belang van de cliënt maximaal te dienen. En dan blijf je bezig met dit soort vragen.

Er zijn een paar manieren om dit praktisch op te lossen. Je kunt zeggen, ik heb mijn eigen verwerkersovereenkomst en daar heeft u het mee te doen. Maar als je grote klanten hebt, of de bedrijfsjurist/FG bemoeit zich ermee, dan werkt dat niet altijd. Dan kun je als alternatief een set harde en een set zachte punten voor een verwerkersovereenkomst maken. De harde zijn punten die je niet anders kunt doen, de zachte ben je bereid op toe te geven, eventueel uiterlijk tot een bepaalde grens. Dan onderhandel je in ieder geval een stuk sneller.

Als een klant iets eist dat je leverancier niet kan waarmaken, dan zit je inderdaad knel. Een van de twee zal dan water bij de wijn moeten doen. In principe zou dat de klant moeten zijn – sorry, reeds aangegane verplichtingen gaan niet zo ver en die contracten openbreken kan pas 1 juni 2020. Je kunt het natuurlijk ook als onderhandeltruc brengen: wat u nu vraagt, valt buiten de SLA dus ik moet even navragen wat dat met de prijs doet.

Want uiteindelijk zijn er geen juridische issues, er zijn alleen onderhandelpunten in juridische taal. Aarzel dus nooit een prijs te zetten op een tegenbod van de wederpartij. Je zult versteld staan hoe vaak je dan gelijk krijgt – of meer geld verdient.

Arnoud

Oh, en verwerkersovereenkomsten sluit je dus alleen met verwerkers, niet met al je partners

Geplaatst op in Privacy, 19 reacties

Een lezer vroeg e:

Ik ben een klein ict-bedrijfje dat onderhoud en apparatuur levert aan het mkb. Steeds vaker krijg ik verwerkersovereenkomsten onder mijn neus, en na even wat gesnuffeld te hebben aan de AVG vraag ik me af, bén ik eigenlijk wel verwerker voor al die klanten? Ik hoor het ook van branchegenoten dat ze standaard bij iedereen een verwerkersovereenkomst moeten tekenen. Waarom doet iedereen dat?

Dat doet iedereen omdat iedereen het doet en omdat het een zichtbare AVG-compliance actie is. “Dan hebben we het maar geregeld, en als iemand een keer geen verwerker is dan is de overeenkomst toch meteen van tafel”, aldus een bedrijfsjurist die ik tegenover me had bij zo’n ict-bedrijf.

Allereerst is er veel verwarring over het begrip ‘verwerker’. Omdat ‘verwerken’ een standaardbegrip is uit de AVG, denk ik dat een hele zwik ondernemers meent dat je een verwerkersovereenkomst moet tekenen als je iemand opdracht geeft om te gaan verwerken. Dat is natuurlijk onjuist: alleen als je opdrachtnemer kwalificeert als verwerker, is zo’n ding nodig. In veel meer gevallen dan mensen denken, is je opdrachtnemer verwerkingsverantwoordelijke (en, ik zeg het maar even, dan dus géén verwerker).

Ten tweede weten veel mensen niet wanneer iemand verwerker is, of wil men geen risico lopen en wordt de wederpartij maar even tot verwerker gebombardeerd. En ik geef toe, dit is ook een lastige. De kortdoordebochtomschrijvingen (de populairste “je verwerkt persoonsgegevens in het kader van een opdracht”) hebben altijd afbakeningsproblemen, en de wettelijke omschrijvingen en uitleg daarvan van de toezichthouders en hun Comité zijn zo vaag dat je er niet mee kunt werken.

Verwerkerschap is een afweging van factoren. Mijn algemene vuistregel is dat je eigenlijk werk uitvoert dat de ander (de verantwoordelijke) net zo goed zelf zou kunnen doen. Ik heb een boekhouder, maar ik kan ook een accountantskantoor inhuren voor de administratie. Ik heb een mailserver, ik kan ook een Office 365 dienstverlener inschakelen. Dan is de partij die je het werk laat overnemen, je verwerker.

Het lastige is dat een partij die werk voor je overneemt, dat ook kan doen zonder verwerker te zijn. Bij een administratiekantoor is dat wat lastig denkbaar, maar zo’n Office-dienstverlener kan zelf besluiten de dienstverlening aan te passen of andere beslissingen te nemen over de dataverwerking. Dat is in strijd met verwerker zijn. En veel ict-dienstverleners komen in zo’n grijs gebied terecht; ze verwerken andermans data maar nemen zelf beslissingen over hoe ze dat doen.

Het is goed mogelijk dat je na analyse tot de conclusie komt dat de dienstverlener toch verwerker is. Maar dan heb je er dus over nagedacht en wel samen met je dienstverlener. Heel wat anders dan met de inkoopvoorwaarden een verwerkersovereenkomst meesturen en eisen dat die even wordt getekend voor de compliance. En dat is volgens mij wat er vaak gebeurt.

Arnoud