Op 5 juni 2012 werd na geruime tijd en discussie over de implementatie van de Europese richtlijn 2009/136/EC de meldplicht datalekken in Nederland verankerd in de Telecommunicatiewet. In aanloop op deze wetsimplementatie werd er vanuit KPN, naast de lobby over vorming van deze wet, geanticipeerd over de wijze waarop dit in de bestaande processen van KPN moest gaan passen. In dit artikel wil ik jullie graag meenemen in de uitdagingen, do’s en don’ts en best-practices (learning by doing).

Wettelijk kader

In de Telecommunicatiewet is de meldplicht datalekken verankerd in artikel 11.3a. Deze meldplicht geldt voor het geval er, ondanks de genomen veiligheidsmaatregelen op grond van artikel 11.3 Tw, toch sprake is van inbreuken op de beveiliging die nadelige gevolgen (kunnen) hebben voor de veiligheid van de persoonsgegevens. Aanbieders zijn verplicht dergelijke inbreuken onverwijld te melden bij de ACM (Autoriteit Consument en Markt). De ACM kan vervolgens nagaan of de inbreuk gevolgen kan hebben voor de persoonlijke levenssfeer van degene wiens persoonsgegevens het betreft, of de door de aanbieder genomen maatregelen als afdoende kunnen worden beschouwd, en of er aanleiding is de abonnee wiens gegevens het betreft te informeren over de inbreuk. Indien de beveiligingsinbreuk waarschijnlijk ongunstige gevolgen zal hebben voor de gebruikers en/of abonnees, moeten ook zij op grond van artikel 11.3a Tw worden ingelicht.

De toezichthouder

Bij de implementatie van de meldplicht datalekken in de Telecommunicatiewet (Tw) werd de voormalige OPTA, sinds 2013 verder onder de naam ACM, aangewezen als toezichthouder op het artikel 11.3a Tw. De ACM is niet het directe meldpunt maar behandeld wel inhoudelijk de gemelde datalekken. Voor de toezichthouder is het met name van belang dat gemelde datalekken volledig, tijdig en correct worden afgewikkeld. De rol van de toezichthouder is dan ook dusdanig beperkt dat de toezichthouder overziet of de verantwoordelijke telecommunicatieaanbieder zich houdt aan de verplichtingen zoals beschreven in de wet en zonodig bijstuurt.

Meldpunt datalekken

De toezichthouder op de meldplicht datalekken in de Tw is niet het meldpunt waar datalekken gemeld dienen te worden. Deze rol is weggelegd voor het Agentschap Telecom (AT), onderdeel van het Ministerie van Economische Zaken. AT zorgt ervoor dat de meldingen kunnen worden geregistreerd en worden doorgegeven aan de toezichthoudende instantie. Het AT onderhoudt dan ook een nauwe samenwerking met ACM als het gaat om de meldplicht datalekken. Om een datalek te kunnen melden, kan de openbare telecommunicatie aanbieder, hierna Telco, gebruik maken van een elektronisch registratieformulier of telefonisch via een 24/7 bemande registratiedesk.

Impact en risico’s

Zoals beschreven in het wettelijk kader, dienen alle vastgestelde datalekken onverwijld te worden gemeld aan de betrokkene en aan de toezichthouder. ACM stelt zich op het standpunt dat ‘onverwijld’ betekent ‘binnen 24 uur’. Om een melding volledig te maken dient dan allereerst te worden vastgesteld wat de impact op de persoonlijke levenssfeer is voor de betrokkene en hoe het lek, indien mogelijk, zo snel mogelijk gedicht kan worden. Dit vereist de nodige inrichting in je organisatie, hierover leest u later meer. Indien de betrokkene niet onverwijld een melding ontvangt, resulteert dit in twee mogelijke consequenties voor de Telco:

1. Een boete of last onder dwangsom vanuit de toezichthouder voor het niet naleven van de Tw;
2. De mogelijkheid dat een betrokkene naar de media stapt en de betreffende Telco alsnog geconfronteerd wordt met het datalek via de media, hetgeen mogelijk ook weer leid tot punt 1 met alle nodige publiciteitsschade.

Het niet melden van een datalek waarbij de persoonlijke levenssfeer van de betrokkene geschaad is, zou zelfs zonder meldplicht datalekken, onverstandig zijn. Het kan immers zorgen voor een boomerang effect, wat natuurlijk alleen maar versterkt wordt wanneer daar ook nog een wettelijk voorschrift voor ligt. Het is daarom evident dat er een snelwerkend proces wordt geïmplementeerd dat zorgt voor een juiste opschaling en communicatiestructuur in de organisatie. Dit resulteert in strakke richtlijnen en protocollen over hoe om te gaan met datalekken. Doordat vooraf niet alle mogelijke incidenten zijn te scharen onder het datalekkenprotocol, is het protocol vrijwel altijd aan verandering en verbetering onderhevig.

Inventariseren organisatiestructuur

Maar hoe implementeer je nu een dergelijk proces of protocol in je organisatie? Ik denk dat dit verschilt per type organisatie, de grote ervan, de hoeveelheid klantgegevens dat een bedrijf verwerkt, de complexiteit van de processen en systemen die voor de verwerking van gegevens zorgen en de wijze waarop organisaties gegevens verzamelen. Het is ongetwijfeld zo dat een bedrijf van een kleinere omvang sneller in staat is om kortere lijnen te hebben tussen systeembeheerders, communicatie-experts en verzamelaars van persoonsgegevens. Bij grotere bedrijven ligt dit vaak complexer. Bij een bedrijf als KPN was dit een hele uitdaging. KPN bestaat uit ruim 31000 medewerkers, verwerkt dagelijks miljoenen persoonsgegevens van zijn klanten, heeft een bijzonder complexe technische infrastructuur en wellicht wel honderden, misschien wel duizenden verschillende klantingangen. Denk daarbij aan retailers, winkels, online en dat weer onderverdeeld in verschillende merken. Omdat KPN ook voor de invoering van de meldplicht datalekken wel eens met het fenomeen datalekken in aanraking kwam, was dit niet geheel nieuw waar het ging om de technische oplossingen en mitigerende acties. Maar het feit dat bepaalde meldingen via een nieuw communicatieproces binnen striktere tijdslijnen moesten worden opgelost, was wel een nieuwe invalshoek.

Security vs Privacy bij datalekken

Binnen KPN was er voor 2011 sprake van een intern meldingsprotocol voor de zogeheten ‘security incidenten’. Hieronder vielen destijds ook al de privacyincidenten zoals datalekken, maar deze werden niet als zodanig geclassificeerd en werden bovendien in veel gevallen naar goeddunken van de behandelende Security Officer individueel opgelost en gecommuniceerd. Het leek daarom ook een logische stap voor KPN om het bestaande securityincidentproces als uitgangspunt te hanteren voor het inrichten van een centraal datalekkenproces in het kader van de meldplicht. Een groot voordeel bij het bestaande securityincidentproces was dat er reeds een bedrijfsbrede ingang bestond waar datalekken gemeld konden worden. Ook werden medewerkers van KPN door het bestaan van het securityincidentproces reeds aangespoord om verlies/vermissing van bedrijfsgoederen en eventuele misstanden en vermoedens van lekken aan de zogeheten Helpdesk Security door te geven. Een ander groot voordeel bij het aanpassen van het huidige securityincidentproces, was dat het eerste wat je bij een datalek probeert te bereiken, het daadwerkelijk dichten van het lek is. Natuurlijk is dat niet in alle gevallen mogelijk, een incident kan natuurlijk ook voorkomen door een verkeerde administratieve eenmalige handeling of het feit dat een postsorteermachine een eenmalige storing heeft, waardoor facturen met daarin persoonsgegevens in de verkeerde enveloppe met een andere bestemming belanden. Het uitgangspunt om een stringent securityincidentproces te hanteren om zo snel mogelijk tot de kern van het probleem te komen, was voor KPN een logische keuze.

Spreken met business owners en stakeholders

Het inrichten van een datalekkenproces in een grote complexe organisatie vereist een aantal noodzakelijke handelingen. Allereerst moeten alle betrokken en verantwoordelijke collega’s bekend worden gemaakt met de noodzaak om datalekken te melden en de voorziene oplossing binnen KPN. Hiervoor zijn wij simpelweg met alle interne betrokken afdelingsmanagers gaan praten, hebben de noodzaak geïllustreerd in een ‘levendige’ presentatie en over de oplossing gebrainstormd. Pas toen alle verantwoordelijke afdelingen en collega’s akkoord waren met het voorstel, zijn wij overgegaan tot implementatie. Het proces dat vandaag de dag binnen KPN wordt gehanteerd, wordt daarom ook door alle betrokkenen gedragen. Bijgaande opsomming geeft een idee welke afdelingen bij dit proces betrokken zouden moeten worden:

• Klantcontact afdelingen,
• Communicatie,
• Juridische zaken en regelgeving,
• Security,
• Information Security, Compliance en Risk specialisten,
• Public Affairs,
• IT afdelingen,
• (en nog vele anderen).

Integreren of separaat proces?

Tijdens de ontwikkeling van het datalekkenproces zijn er momenten geweest waarin er werd overgewogen om het datalekkenproces los van de bestaande processen op te zetten. Een groot voordeel daarbij is dat dit geheel een eigen inrichting zou krijgen, waardoor meer flexibiliteit, minder noodzaak voor verandering teweeg brengt in bestaande registratiesystemen en organisatie en mogelijk sneller ingezet kan worden dan bij een aanpassing van de bestaande procesgang. Juist omdat het verzamelen van de meldingen een dusdanig grote rol betekende in de afwikkeling van de datalekken werd er door KPN uiteindelijk toch gekozen voor een integratie met bestaande processen en verscherping van de interne communicatie-uitingen en de protocollen voor het extern benaderen van klanten over datalekken.

Aanpassen proces

Bij het aanpassen van het proces, was het vooral van belang dat er bij elk datalek na binnenkomst van een melding bij de Security Helpdesk een select team van mensen werd opgeschakeld. Dit noemen wij intern: het Incident Response Team. Het Incident Response Team wordt geleid door een Security Manager, vaak in het bedrijfssegment waar het incident zich heeft voorgedaan, of waar het incident als eerste is genotificeerd. De Security Manager vormt een team met daarin in ieder geval een compliance manager, een communicatiespecialist en, in geval van een technisch incident, een technisch expert die de technische oplossing verzorgt. Naast de algemene leiding door de Security Manager verzorgt de compliance manager de communicatie naar de toezichthouder, waarborgt de communicatiespecialist dat de interne alsmede de externe communicatie zorgvuldig verloopt en zorgt de IT specialist waar nodig er voor dat het technisch euvel wordt verholpen.

Bewustwording en communicatie

Zoals al eerder genoemd in de afweging om het datalekkenproces al dan niet te integreren in de bestaande processen, is het evident dat meldingen van potentiële datalekken intern, bij voorkeur centraal, worden geregistreerd. Dit om een overzicht te bewaken en om er voor te zorgen dat de juiste mensen gaan rennen. In het geval van KPN was dit middels het securityincidentproces al centraal opgehangen, maar diende het bewustzijn onder alle medewerkers ten aanzien van het bestaan van de meldplicht datalekken alsook de noodzaak om ook twijfelgevallen te melden bij de centrale Security Helpdesk, wel vergroot te worden. Om dit te realiseren heeft KPN een mix van communicatiemiddelen opgetuigd om zodoende alle medewerkers te bereiken. Hierbij kan gedacht worden aan berichten op het Intranet, promotionele posters, een interne awareness film, verplichte cursussen, workshops en presentaties door de hele organisatie heen op zeepkisten en management bijeenkomsten. Hoewel de eigenlijke insteek was om zoveel mogelijk van de bewustwordingspresentatie als een cascade langs de lijnen van het management neer te laten dalen bij alle medewerkers, werd dat in de praktijk toch vaak het doorsturen van de presentatie per e-mail. Gelukkig leidde dit vervolgens tot vragen aan de Privacy Officer om het verhaal nader toe te lichten. Na een grootschalige communicatiecampagne, zou iedere medewerker een potentieel datalek moeten kunnen herkennen en melden bij de interne Security Helpdesk. Het werd nu tijd om het proces te testen.

Pilot over werking proces

Al voor op de inwerkingtreding van meldplicht datalekken op 5 juni 2012 had KPN ruim de gelegenheid om het proces intern te testen. Al snel bleek dat de verzameling van meldingen zich ophoopte en dat er een noodzaak voor het categoriseren van verschillende typen potentiële datalekken ontstond. Ondanks het feit dat er verscheidene meldingen binnenkwamen op de centrale helpdesk die helemaal geen datalek bleken te zijn, was het toch goed dat ook deze meldingen serieus naar de melder werden teruggekoppeld, waarbij een en ander nog eens werd uitgelegd om zodoende ook het melden te blijven stimuleren. Mijn motto en boodschap naar de organisatie was in die periode (en nog steeds) dan ook: “Als je twijfelt, gewoon melden. Ik heb liever 100 meldingen teveel dan 1 te weinig”. Dit motto bleek goed te werken. Vervolgens was het de taak aan het Incident Response Team om de meldingen te analyseren en te behandelen. Gaandeweg leerde wij dan ook dat bepaalde meldingen konden worden afgehandeld door de centrale Security Helpdesk en andere meldingen een diepgaander onderzoek vereisten. Snel werd duidelijk dat een onderlinge afstemming met zowel de melder (intern en extern) als de interne specialisten onontbeerlijk was. Na wat vallen en opstaan, wat met name op het gebied van verantwoordelijkheid lag, konden we gezamenlijk met alle stakeholders vaststellen dat het datalekken proces, geïntegreerd in de bestaande Security procesgang, werkt.

De eerste melding

Op 5 juni 2012 trad de meldplicht datalekken in werking. Feitelijk bleek er weinig te veranderen, daar KPN reeds over en weer contact had met de toezichthouder, ook met het oog op de komende meldplicht. Belangrijke les bij deze onderlinge werkwijze was: bij twijfel bellen en verwachtingen uitwisselen. Dankzij een goede samenwerking met de ACM werd het KPN vrij snel duidelijk wat er verwacht werd aan de zijde van de toezichthouder en bleek het nuttig om periodiek evaluatiegesprekken te voeren.

Complicaties bij interpretatie meldplicht

Natuurlijk bestaan er veel onduidelijkheden over de meldplicht datalekken en met name over de interpretatie van het datalek an sich. Ook bestond er vooral in de beginfase onduidelijkheid over welke zaken gemeld diende te worden en welke zaken niet. Wanneer leidt een incident of datalek tot een schending van de persoonlijke levenssfeer? Wanneer classificeer je een gegeven als een persoonsgegeven? Om daar maar heel kort over te zijn: dit zal je per geval moeten gaan beoordelen. Het is namelijk geen gegeven dat het lekken van bepaalde data direct of indirect tot een schending van de persoonlijke levenssfeer zal gaan leiden, noch is het niet generiek te bepalen of een gegeven in combinatie met andere gegevens weer te herleiden is tot een natuurlijk persoon. Al deze zaken zal je op case-by-case moeten beoordelen en telkens opnieuw moeten afwegen. Een ander discussieonderwerp waar wij intern tegen aanliepen is de vraag of ook gegevens van zakelijke gebruikers onder de meldplicht vallen. Daaruit hebben wij geconcludeerd dat zolang dit tevens eindgebruiker gegevens betreffen en in de essentie de persoonlijke levenssfeer van deze eindgebruiker geschaad is, dit als datalek als bedoeld in de Tw classificeert en dus onder de meldplicht valt. In het geval KPN als een bewerker van gegevens optreedt, dient een eventuele melding onverwijld aan de betreffende verantwoordelijke te worden gedaan, zodat deze op zijn beurt aan de meldplicht kan voldoen.

Afstemmen met de toezichthouder

Na de interne implementatie bleek al vrij snel de wens te bestaan om duidelijk de verwachtingen van de toezichthouder scherp te krijgen. Zoals al eerder genoemd heeft KPN dit in goed overleg met de toezichthouder kunnen evalueren. Belangrijk om in het achterhoofd te houden is dat de verantwoordelijkheid van de juiste en tijdige afwikkeling, communicatie en oplossing geheel bij de verantwoordelijke berust. In de meeste gevallen is dit simpelweg het gebruiken van je common sense, oftewel je boerenverstand. Ik daag vaak mijn eigen collega’s uit door de vraag te stellen: “Hoe zou je het zelf vinden, als jouw gegevens worden gelekt?”. Dit leidt altijd tot de nodige discussie, waarna vaak de juiste besluiten volgen.

Learning by doing

Zoals ik aan het begin van het artikel noemde, is het implementeren van de meldplicht datalekken, een kwestie van learning by doing. Niet in de laatste plaats omdat je niet te lang in de ‘theoretische discussie’ wilt blijven hangen. Het is goed om je aanpak te overdenken, maar wacht niet te lang met de executie. Toen ik vroeger bordspellen met vrienden moest leren op een regenachtige zondag, lazen we ook niet eerst uitvoerig de handleiding of spelinstructies door, maar gingen we na kennisname van de basisuitgangspunten gewoon spelen, wetende dat men gaandeweg het spel vrij snel door krijgt. Ik geloof dat dit bij dit soort verandertrajecten ook het geval is. Ik heb dan ook ten tijde van de implementatie regelmatig geroepen: “We gaan het gewoon doen en we zien wel waar we tegenaan lopen”.

Lessen en conclusies

Belangrijk om mee te nemen is denk ik dat je zorgvuldig je plan op stelt, met de juiste stakeholders praat, deze met je mee krijgt, begrijpt dat de communicatie of the essence is, zo veel mogelijk probeert op te lijnen met reeds bestaande initiatieven binnen jouw organisatie, waar mogelijk afstemt met de toezichthouder en uiteindelijk beseft dat het implementeren van een dergelijk traject een levendige en veranderlijke exercitie is. Ik kan nu na twee jaar dit proces in werking te hebben gezien ook wel te zeggen dat we er als KPN veel van hebben geleerd en we zelfs vandaag de dag het proces nog aan het verbeteren zijn, maar dat het proces er staat.

Dit artikel is tot stand gekomen in samenwerking met Jeroen Terstegge