Volg Software Zaken

Help een datalek – procedure meldplicht datalekken

| Sieuwert van Otterloo | Privacy Security

Bijna elke organisatie in Nederland verwerkt persoonsgegevens en moet zich dus houden aan de privacywetgeving. Deze privacywetgeving verplicht bedrijven om een procedure te hebben voor het melden van datalekken. Op het niet melden van lekken staat namelijk een hoge boete. In dit artikel hebben we een voorbeeldprocedure geschreven geschikt voor de meeste bedrijven.

Waarom een procedure meldplicht datalekken

Nederland heeft meerdere privacywetten. Sinds 2001 geldt de wet bescherming persoonsgegevens. In 2016 is hier de meldplicht datalekken aan toegevoegd. Vanaf mei 2018 geldt ook de Algemene Verordening Gegevensbescherming (AVG), de Nederlandse versie van de General Data Protection Regulation (GDPR). Sinds 2016 geldt er een verplichting voor bedrijven om alle datalekken waarbij persoonsgegevens betrokken zijn te melden. Het gaat om een dubbele meldplicht. Ten eerste aan de overheid (de Autoriteit Persoonsgegevens) zodat deze inzicht heeft hoe vaak datalekken voorkomen. Ten tweede aan de personen van wie de data gelekt is, zodat zij eventueel maatregelen kunnen nemen.

Het is niet wettelijk verplicht om een procedure te hebben, maar wij raden dat wel sterk aan. Zonder procedure is de kans groot dat er teveel tijd verloren gaat. Voor bedrijven die een gecertificeerd beveiligingsbeleid willen (volgens ISO 27001 of Security Verified) is het opstellen van een procedure daarom wel verplicht. De procedure hoeft niet opgestuurd te worden. Het is voldoende als deze binnen de organisatie bekend is.

Wie kan deze procedure gebruiken

schema-meldplicht-datalekkenDe onderstaande procedure is geschikt voor alle Nederlandse organisaties die geen financiële instelling zijn en geen telecombedrijf. De procedure is een samenvatting op de richtsnoeren van de autoriteit persoonsgegevens zelf. We raden iedereen aan deze ook te lezen, onder andere omdat hierin goede voorbeelden genoemd zijn voor de te nemen besluiten.

We hebben de procedure zo eenvoudig mogelijk gehouden. Het is toegestaan om extra stappen toe te voegen. Denk bijvoorbeeld aan overleg met interne juristen of hoofd communicatie. Ook hebben we voor de eenvoud in dit artikel de Data Protection Officer (DPO) of de Functionaris Persoonsgegevens (FG) niet opgenomen. Deze rol is namelijk niet verplicht om in te vullen. Als u deze persoon wel heeft in uw bedrijf, is het zinvol deze ook in het proces te betrekken.

Als u wel een financiële instelling bent die valt onder de WFT, of een bedrijf dat onder de telecomwet valt, dan moet u de richtsnoeren erbij pakken. Hierin staan stroomschema’s zoals hiernaast weergegeven, die u dan kunt volgen.

Stap 0: definities datalekken

De volgende definities zijn gebaseerd op de richtsnoeren meldplicht datalekken van de autoriteit persoonsgegevens. Het securityteam moet deze definities kennen en toepassen.

  • Een incident is een concrete gebeurtenis waarbij de beschikbaarheid, confidentialiteit of integriteit van een informatie-asset is geschonden. Niet elk incident is een datalek. Het is wel verstandig elk incident te loggen en te analyseren.
  • Een datalek is een incident waarbij er persoonsgegevens verloren zijn gegaan of als er onrechtmatige verwerking heeft plaatsgevonden.
  • Een persoonsgegeven is elk gegeven dat herleidbaar is tot een natuurlijk persoon. Denk aan email, telefoonnummer, voornaam_achternaam, huisadres, kenteken, IP-nummer, bankrekeningnummer, MAC-adres, foto’s met gezichten erop, inkomen, geboortedatum. Niet persoongegevens zijn gemiddeldes over grotere groepen.

Elk beveiligingsincident moet worden gemeld bij het securityteam en wordt door het team gelogd en bestudeerd. Zij bepalen of er sprake is van een datalek.

Stap 1: Melden van datalekken aan securityteam

Iedereen in de organisatie die werkt met persoonsgegevens, moet weten dat er een meldplicht datalekken is en dat zij een incident of datalek direct moeten melden. Veel organisaties hebben een securityteam van 2-3 mensen en maken een speciaal email-adres voor dit team. Als er geen team is, dan moet iedereen melden bij de directie. Het is verstandig deze informatie op te nemen in security-trainingen, in personeelshandboeken en wellicht op te hangen bij de koffie-automaat. Op deze manier weet iedereen hoe te melden.

Stap 2: vastleggen en analyseren

Vastleggen en uitzoeken: Het securityteam (of de directie) logt het incident, bestudeert het incident. Zoek uit wat er wanneer en waar is gebeurd en welke apparatuur en partijen hierbij betrokken zijn geweest.

Directe actie: Indien nodig, neem direct actie om het lek te dichten of te stoppen. Denk aan uitzetten servers, blokkeren accounts of verwijderen gevoelige data.

Besluit persoonsgegevens: Het team bepaalt welke persoonsgegevens van hoeveel en welke personen er betrokken zijn. Als uitkomst hiervan wordt het aantal personen vastgelegd, welke soorten gegevens en of er sprake is van bijzondere gegevens.

Bepaal de verantwoordelijke: Het team bepaalt wie de verantwoordelijke voor de gegevens is. Dit wordt bepaald door na te gaan hoe de gegevens zijn verkregen en door bestudering van alle bewerkers-overeenkomsten waaronder de gegevens zijn doorgegeven. De verantwoordelijk kan een klant zijn, of de organisatie zelf.

Bepaal uitsluitbaarheid: Soms is het redelijkerwijs uit te sluiten is dat persoonsgegevens onrechtmatig zijn verwerkt. Dit is bijvoorbeeld het geval bij diefstal van een laptop die voorzien is van sterke encryptie. Goede encryptie leidt tot uitsluitbaarheid. Zonder goede encryptie is er geen uitsluitbaarheid.

Stap 3a: Melden als bewerker/verwerker

Heel vaak is de organisatie die een datalek ontdekt, niet zelf verantwoordelijk  voor het melden van een datalek. Als u IT-leverancier bent, zult u meestal bewerker / verwerker zijn en persoonsgeveven alleen via een klant krijgen. U moet dan dus de klant waarschuwen en deze moet besluiten of er een melding aan de AP moet worden gedaan. In de verplichte verwerkersovereenkomst staat wie de verantwoordelijke is.

Als de organisatie zelf niet de verantwoordelijke is, wordt er melding gedaan conform de contactgegevens in bewerkersovereenkomst. Indien dit niet duidelijk is of niet uitvoerbaar, wordt contact opgenomen via telefoonnummer op website van partij. Het streven is om dit te doen binnen 8 kantooruren na ontdekking incident (of conform termijn in bewerkersovereenkomst). De verantwoordelijke moet zorgen voor de overige meldingen. De organisatie volgt verder alleen de instructies van de verantwoordelijke.

Stap 3b: Melden als verantwoordelijke

Als er sprake is van een niet uitsluitbaar datalek en de organisatie verantwoordelijke is, dan doet het security-team het volgende:

  • Op de hoogte brengen overige directie en eventueel juridische zaken, zoadat zij kunnen meedenken over communicatie.
  • Afronden onderzoek en goed vastleggen uitkomsten in een apart indicentrapport
  • Inschatten ernst incident: Een incident is ernstig als er sprake is van (een aanzienlijke kans op) ernstige nadelige gevolgen voor de bescherming van persoonsgegevens. Een incident met gevoelige persoonsgegevens is altijd ernstig, ook met 1 persoon. Een incident zonder gevoelige persoonsgegevens is ernstig bij een voldoende omvang.
    Toetsen van het incident aan de voorbeelden op pagina 26 van de richtsnoeren. Eventueel oordeel of datalek ernstig is bijstellen.
  • Als het datalek ernstig is, dan moet het incident via het webformulier gemeld worden bij de Autoriteit Persoonsgegevens. Dit moet indien mogelijk binnen 72 uur na ontdekking.
  • Het security-team schat in of het melden aan betrokkenen mogelijk is en of een melding eventueel nadelige gevolgen heeft voor de betrokken persoon. Als het mogelijk is om te melden, dit geen nadelen heeft voor betrokkenen en er geen sprake is van goede encryptie, worden het datalek gemeld aan betrokkenen.
  • Het securityteam denkt na over verbeteringen die toekomstige datalekken kunnen voorkomen. Dit hoeft niet direct maar kan bijvoorbeeld elke maand gebeuren.

De afbeelding hieronder, afkomstig uit de richtsnoeren, laat de voorbeelden zien van datalekken die moeten worden gemeld.

voorbeelden-datalekken-melding

Stap 4: Review elk half jaar

De gegevens van het incident, alle besluiten en de melding worden bewaard als onderdeel van het ISMS door het information security team. Meldingen moeten minimaal een jaar worden bewaard vanuit de wet bescherming persoonsgegevens.
Eind juni en eind december worden moeten alle incidenten van het afgelopen half jaar nogmaals bestudeerd. Er wordt dan opnieuw gekeken met eventuele nieuwe informatie of er alsnog gemeld moet worden. Als dat zo is, wordt er alsnog gemeld.

Stap 5: Voorbereid zijn op datalekken

Het melden van een datalek is een stuk makkelijker als men zich goed voorbereidt. De volgende stappen kunt u nu al nemen om het risico van datalekken te verkleinen:

  • Het in kaart brengen van processen waarin persoonsgegevens worden gebruikt. Per proces moet uitgezocht worden om wat voor persoonsgegevens het gaat.
  • Zorgen dat er altijd een bewerkersovereenkomst is met elke klant en leverancier waarmee persoonsgegevens worden gedeeld. Dit is wettelijk verplicht en zorgt voor duidelijkheid over wie er moet melden.
  •  Zorgen voor goede beveiliging van de organisatie. Dit kan bijvoorbeeld door het opzetten van een Informatiebeveiligingsbeleid volgens ISO 27001. Eventueel kan dit ook gecertificeerd worden.
  •  Training: Door het regelmatig geven van security awareness training wordt iedereen goed op de hoogte gebracht van het belang van beveiliging. Het geven van trainingen aan iedereen is vaak een verplicht onderdeel van goed beveiligingsbeleid. Dit geldt bijvoorbeeld als u wilt voldoen aan ISO 27001 of aan Security Verified.

Als u hulp wilt met deze voorbereidingen of met een melding, neem gerust contact op met SoftwareZaken.

Bron afbeelding: Eric Miller World Bank CC via Flickr

Sieuwert van Otterloo
Author: Sieuwert van Otterloo
Dr. Sieuwert van Otterloo is IT-expert en startup enthusiast. Hij heeft veel ervaring met scrum, agile, IT-beveiling, IT-contracten, IT-strategie. Sieuwert is als expert toegelaten bij NVBI, LRGD en SGOA.