applatenmaken.com/kennisbank/ketenincident
Uw toeleverancier is gehackt, niet uw leverancier
Bol moest deze maand opnieuw klanten waarschuwen over een datalek bij CEVA Logistics, een partij waar die klanten zelf nooit iets mee te maken hebben gehad. Dat is het patroon van een ketenincident: het gebeurt twee schakels verderop en komt bij u terecht als een gesprek dat u moet voeren. Deze pagina gaat over hoe u dat voorbereidt.
Waarom u de partij bent die moet uitleggen
Uw klant heeft één relatie: die met u. Dat een deel van uw dienstverlening bij een andere partij is ondergebracht en dat die partij weer werkt met een derde, is voor hem een interne kwestie van uw organisatie. Gaat het daar mis, dan is het uw naam die in de mail staat.
Juridisch klopt dat beeld ook grotendeels. Verwerkt een partij persoonsgegevens in uw opdracht, dan blijft u de verwerkingsverantwoordelijke, ook als die partij het werk heeft doorgezet naar een ander. De keten van verantwoordelijkheid loopt door, terwijl de keten van informatie dat vaak niet doet.
Dat is precies waar het misgaat. U hoort het pas als het al bij uw leverancier is aangekomen, en die hoorde het van zijn leverancier, en die had het misschien al een week eerder ontdekt. Ondertussen loopt uw eigen meldtermijn vanaf het moment dat u het weet, wat u tot de laatste maakt die kan handelen en de eerste die moet uitleggen.
- Wat een ketenincident is
- Een incident bij een partij waarmee u zelf geen contract heeft, maar die werkt voor iemand die dat wel heeft.
- Waarom het u raakt
- Uw klant kent alleen u, en bij persoonsgegevens blijft u verantwoordelijk voor de hele keten.
- Het praktische probleem
- Informatie reist langzamer door de keten dan verantwoordelijkheid.
- Wat het oplost
- Vooraf weten wie er achter uw leverancier zit, en vastleggen wie u binnen hoeveel tijd belt.
Wie er in uw keten zitten
De eerste stap is de meest saaie en de meest nuttige: vaststellen wie er allemaal bij uw gegevens kan. Bij de meeste organisaties is die lijst langer dan verwacht en bevat hij minstens één partij waarvan niemand wist dat ze erin zat.
| Type partij | Wat zij van u hebben | Waar u op let |
|---|---|---|
| Uw softwareleverancier | ✓Toegang tot uw productieomgeving en uw code | !Wie er bij hem toegang heeft en hoe dat wordt ingetrokken |
| De hostingpartij daarachter | ✓De machines waarop uw gegevens staan | !Of uw leverancier ze zelf beheert of doorzet naar een derde |
| Diensten die uw software aanroept | ✓Vaak persoonsgegevens, per bericht of per verzoek | !Dat ze in uw register staan, ook de kleine zoals een mailverzender |
| Partijen in uw fysieke proces | ✓Namen, adressen en soms bestelgegevens | !Vervoer, opslag en verwerking; hier zat het incident van deze maand |
| Onderaannemers van al het bovenstaande | ✓Alles wat de partij boven hen heeft doorgegeven | !Dat u toestemming geeft en niet achteraf hoort wie erbij zat |
Deze inventarisatie overlapt met wat u voor uw verwerkingsregister al zou moeten hebben. Is dat register actueel, dan bent u snel klaar; is het dat niet, dan levert deze oefening meteen twee resultaten op. Wat er in de afspraken met die partijen hoort, staat in wat hoort in een verwerkersovereenkomst.
Wat u vooraf vastlegt
Bij een ketenincident is de enige knop die u nog heeft, de afspraak die u vooraf heeft gemaakt. Deze punten maken in de praktijk het verschil tussen een beheerst traject en twee weken bellen.
De laatste vraag voorkomt het scenario waarin een partij verderop in de keten uw klanten benadert zonder dat u het weet.
Merk op dat de derde vraag vaak het verschil maakt. Een leverancier die pas meldt bij bevestiging, kan legitiem een week wachten terwijl u die week nodig had. Bij een vermoeden meteen een seintje krijgen kost u een enkele keer een vals alarm en levert u de rest van de tijd bruikbare voorsprong op.
Het gebeurt: wat doet u in de eerste dagen
De volgorde hieronder is bewust: eerst vaststellen wat er speelt, dan pas communiceren. Omgekeerd beginnen levert een tweede mail op waarin u uw eerste moet corrigeren, en dat kost meer vertrouwen dan de vertraging.
- Leg vast wanneer u het hoorde
Dat moment is het startpunt van uw termijnen en de eerste vraag die u later krijgt. Noteer ook van wie u het hoorde en wat er precies is gezegd.
- Stel vast of het uw gegevens raakt
Een incident bij een partij in uw keten betekent niet automatisch dat uw gegevens erbij zitten. Vraag om een afbakening: welke gegevens, van welke opdrachtgevers, over welke periode.
- Beoordeel of u moet melden
Bij persoonsgegevens speelt de datalekmelding, bij verstoring van uw dienstverlening mogelijk de meldplicht onder de Cyberbeveiligingswet. Zie hiervoor de meldketen bij een incident.
- Bepaal wat u uw klanten vertelt
Wat er is gebeurd, welke gegevens het betreft, wat u doet en wat zij zelf kunnen doen. Wacht niet op volledigheid, maar zeg wel duidelijk wat u nog niet weet.
- Leg achteraf de keten opnieuw langs de meetlat
Een incident is de enige gelegenheid waarbij iedereen wil meewerken aan betere afspraken. Gebruik dat moment voordat het wegzakt.
Bij de derde stap geldt: of iets als datalek of als significant incident kwalificeert, is een juridische beoordeling. Leg die voor aan uw functionaris gegevensbescherming of een jurist. Deze pagina is uitleg en geen juridisch advies.
Veelgestelde vragen
Wat is een ketenincident?
Een incident bij een partij waarmee u zelf geen contract heeft, maar die werkt voor een leverancier van u. Het bericht van deze maand waarin Bol klanten waarschuwde naar aanleiding van een datalek bij CEVA Logistics is daar een voorbeeld van: de eindklant had met die partij nooit een relatie.
Ben ik verantwoordelijk voor een incident twee schakels verderop?
Bij persoonsgegevens blijft u verwerkingsverantwoordelijke voor de verwerkingen die in uw opdracht plaatsvinden, ook als uw verwerker het werk heeft doorgezet naar een ander. Praktisch gezien bent u sowieso de partij die uw klanten moet informeren, want zij kennen alleen u.
Hoe kom ik erachter wie er in mijn keten zitten?
Door het uit te vragen bij uw leveranciers en vast te leggen. Vraag om een overzicht van onderaannemers en subverwerkers, en spreek af dat u toestemming geeft voordat er een wordt toegevoegd. Die inventarisatie overlapt met wat u voor uw verwerkingsregister al zou moeten hebben.
Wat is de belangrijkste afspraak om te maken?
Dat uw leverancier u informeert bij een vermoeden en niet pas bij bevestiging, binnen een termijn die korter is dan uw eigen meldtermijn. Wachten op bevestiging kan legitiem een week duren, en dat is precies de week die u nodig had om zelf te kunnen handelen.
Moet ik melden als het incident niet bij mij plaatsvond?
Dat hangt af van de gevolgen bij u, niet van de plaats van het incident. Zijn er persoonsgegevens uit uw verwerking betrokken, dan kan de meldplicht voor datalekken gelden. Wordt uw dienstverlening verstoord en valt u onder de Cyberbeveiligingswet, dan speelt die meldplicht. Beide beoordelingen legt u voor aan een jurist.
Wanneer informeer ik mijn klanten?
Zodra u kunt zeggen wat er is gebeurd, welke gegevens het betreft en wat zij zelf kunnen doen. Eerder communiceren leidt vaak tot een tweede bericht waarin u het eerste moet corrigeren, en dat kost meer vertrouwen dan de vertraging. Zeg wel expliciet wat u nog niet weet, in plaats van het weg te laten.
Wat als mijn leverancier zelf uw klanten benadert?
Dat is een scenario dat u vooraf uitsluit. Leg vast wie er richting uw klanten communiceert en wie dat juist niet doet. Zonder die afspraak kan een partij verderop in de keten uw klanten benaderen met informatie die u zelf nog niet heeft, en verliest u de regie over uw eigen relatie.
Wat kan ik na afloop het beste doen?
De keten opnieuw langs de meetlat leggen terwijl iedereen nog bereid is mee te werken. Vlak na een incident is de enige periode waarin afspraken over meldtermijnen, onderaannemers en bewaartermijnen zonder discussie worden aangescherpt. Een halfjaar later kost dezelfde vraag drie gesprekken.