In de eerste uren van een beveiligingsincident kunt u geen volledig technisch beeld krijgen van wat er is gebeurd. Uw team probeert mogelijk nog te begrijpen welk account in gevaar is gebracht, tot welke gegevens toegang is verkregen, hoe ver de aanvaller is gekomen of het incident nog actief is.
Naast uw onderzoek begint de druk om te handelen onmiddellijk. Medewerkers horen fragmenten en moeten weten wat ze moeten doen. Ondertussen kunnen klanten serviceverstoring, verdachte activiteit of ongebruikelijke verzoeken om wachtwoordreset opmerken. Zakenpartners kunnen vragen of hun systemen of gegevens betrokken zijn, en het leiderschap moet beslissen wie spreekt, wat bevestigd kan worden en wanneer stilte een risico op zich wordt.
Communicatie over beveiligingsincidenten is moeilijk omdat een bedrijf transparant moet zijn voordat het alle antwoorden heeft, maar voldoende geïnformeerd om niet te gissen. Communicatie die te vroeg wordt verzonden kan verwarring veroorzaken, maar als deze te laat wordt verzonden, kan dit het vertrouwen schaden, beschermende actie vertragen en regelgevende vragen oproepen.
Het is onwaarschijnlijk dat kleine en middelgrote bedrijven hun incidentresponsplan hebben opgesteld of geoefend, en dit kan extra chaos veroorzaken. Zelfs voor grotere bedrijven met een plan kunnen de technische stappen gedocumenteerd zijn: het incident indammen, toegang resetten, bewijsmateriaal bewaren, systemen herstellen. Communicatie kan voor later worden uitgesteld, totdat het incident plotseling escaleert of verandert.
Een deel van de voorbereiding op een incident is weten wie van u moet horen, wat zij moeten weten, wie het bericht goedkeurt en hoe u feiten duidelijk kunt communiceren terwijl het onderzoek nog gaande is.
Communicatieplanning hoort bij incidentrespons
De tweesporenstructuur voor uw respons
Begin met de doelgroep, niet met de aankondiging
Wat u intern moet communiceren
Hoe u klanten op de hoogte stelt van een datalek
Wanneer u toezichthouders moet informeren
Bereid berichten voor voordat u ze nodig heeft
Hoe Proton Pass for Business kan helpen
Communicatieplanning hoort bij incidentrespons
Incidentrespons wordt vaak beschreven als een technisch proces, maar een echt incident wordt al snel multidisciplinair. IT-teams kunnen de dreiging indammen, maar leiderschap, juridische zaken, klantenondersteuning, HR, communicatie en operations moeten allemaal weten wat er gebeurt en wat ze mogen zeggen.
De richtlijnen van het NCSC over effectieve communicatie bij een cyberincident(nieuw venster) — algemene best practices die ook buiten het VK van toepassing zijn — maken dit punt duidelijk: organisaties geven vaak prioriteit aan technische respons en schuiven communicatie naar de achtergrond, ook al bepaalt communicatie hoe medewerkers, klanten, belanghebbenden en de media de organisatie tijdens een crisis waarnemen.
Niet elk incident vereist een publieke verklaring. Maar het bedrijf moet van tevoren weten wie beslist wat er wordt gecommuniceerd, wie externe berichten goedkeurt, wie met klanten spreekt en wie de regelgevende rapportage afhandelt.
Een sterk responsplan voor datalekken moet een communicatielaag bevatten. Dit moet praktische details bevatten:
- Contactlijsten
- Concepttemplates
- Goedkeuringsroutes
- Juridische toetsing
- Gesprekspunten voor klantenondersteuning
- Verantwoordelijkheden voor melding aan toezichthouders
- Registraties van wat is verzonden, wanneer en naar wie.
De tweesporenstructuur voor uw respons
Incidentrespons vereist twee sporen: technische respons en communicatierespons. Ze lopen parallel aan elkaar en de incidentleider/responsverantwoordelijke verbindt ze beide.
| Linkerspoor: Technische respons | Rechterspoor: Communicatierespons |
| Het incident indammen | Het interne team updaten |
| Getroffen accounts beveiligen | Getroffen klanten of partners informeren |
| Bewijsmateriaal bewaren | Melding aan toezichthouders beoordelen |
| Systemen herstellen | Houd berichten consistent terwijl feiten veranderen |
Hierdoor kunt u uw respons structureren en ervoor zorgen dat de samenwerking doorgaat terwijl teamleden verschillende taken op zich nemen.
Begin met de doelgroep, niet met de aankondiging
Communicatie over beveiligingsincidenten mislukt wanneer één bericht iedereen probeert te bedienen. Medewerkers, klanten, partners en toezichthouders hebben verschillende niveaus van detail nodig omdat ze verschillende beslissingen moeten nemen.
Uw interne team heeft eerst duidelijkheid nodig
Ze hebben niet elk detail nodig — vooral niet terwijl het onderzoek nog gaande is — maar ze hebben wel duidelijkheid nodig over wat bevestigd is, wat ze nu moeten doen en wie de respons leidt. Dat betekent weten welke systemen of accounts ze moeten vermijden, welke actie ze onmiddellijk moeten ondernemen en welke vragen nog openstaan.
Medewerkers moeten ook weten wat ze niet moeten doen. Bijvoorbeeld:
- Bespreek het incident niet openbaar
- Reset inloggegevens niet buiten het goedgekeurde proces
- Neem geen contact op met klanten met geïmproviseerde uitleg
- Stuur verdachte berichten niet door zonder begeleiding.
Klanten en partners moeten weten hoe ze worden getroffen
Ze willen weten of hun gegevens, toegang, betalingen, service of activiteiten worden beïnvloed. Een goede klantmelding moet uitleggen:
- Wat bekend is
- welk type gegevens mogelijk betrokken zijn
- wat het bedrijf doet
- wat klanten nu moeten doen, indien nodig
- waar ze updates kunnen krijgen
De toon moet eenvoudig en direct zijn. Een klant heeft ook geen forensische gegevens nodig. Die heeft alleen genoeg informatie nodig om zichzelf te beschermen.
Toezichthouders hebben een feitelijk verslag nodig
Een melding van een GDPR-schending aan de relevante toezichthoudende autoriteit (de ICO(nieuw venster) in het VK, de nationale autoriteit voor gegevensbescherming in elke EU-lidstaat) is geen marketingbericht of geruststellende mededeling aan klanten. In plaats daarvan moet het een feitelijk verslag zijn van wat er is gebeurd, wie er getroffen is en wat u eraan doet. Wat u precies moet opnemen in de sectie over het melden aan toezichthouders, staat hieronder.
Wat intern gecommuniceerd moet worden
Uw medewerkers maken deel uit van de respons, zelfs als ze niet in het incidentteam zitten. Een verward team kan per ongeluk meer ruis creëren, onjuiste informatie delen of de beheersing vertragen. Aan de andere kant kan een goed geïnformeerd team helpen accounts te beschermen, klanten naar het juiste kanaal te verwijzen en te voorkomen dat speculatie groeit.
Een interne aankondiging van een beveiligingsincident moet het volgende bevatten:
- een duidelijke samenvatting van wat tot nu toe is bevestigd, in begrijpelijke taal
- welke systemen, accounts, teams of gegevens mogelijk getroffen zijn
- wat het bedrijf nu doet
- wat medewerkers onmiddellijk moeten doen
- wie extern mag communiceren
- waar updates worden geplaatst
- hoe gerelateerde verdachte activiteit te melden
Er zijn aspecten die niet opgenomen moeten worden: aanvalsvectoren, oorzaakanalyse en specifieke kwetsbaarheden worden over het algemeen niet intern gedeeld terwijl een incident gaande is, en vaak daarna ook niet, omdat die gegevens andere aanvallers kunnen helpen, juridische blootstelling kunnen creëren of hiaten kunnen blootleggen die nog niet zijn gedicht.
Het eerste interne bericht hoeft niet elke vraag te beantwoorden, het moet orde scheppen. Medewerkers moeten bijvoorbeeld wachtwoorden alleen via een goedgekeurd proces resetten, een specifiek systeem vermijden, verdachte e-mails bewaren of stoppen met het gebruik van gedeelde inloggegevens totdat het responseteam de beoordeling heeft afgerond.
Het beoordelen van uw bestaande toegangscontroles aan de hand van best practices voor wachtwoordbeheer is ook essentieel. Tijdens een incident kan verouderd of informeel delen van inloggegevens het moeilijker maken om te begrijpen wat er is blootgesteld.
Protons gidsen over bescherming tegen datalekken en preventie van datalekken voor bedrijven leggen uit hoe gelaagde controles de blootstelling verminderen voordat een datalek optreedt. Veilig beheer van inloggegevens is een van die lagen, omdat het bedrijven helpt te weten welke accounts bestaan, wie er toegang toe heeft en wat snel moet worden gewijzigd.
Hoe klanten te informeren over een datalek
Een melding van een datalek aan klanten is moeilijker omdat het reputatie- en juridische gevolgen heeft. Mensen maken zich misschien zorgen over identiteitsdiefstal, overname van accounts, financiële fraude of blootstelling van privé-informatie. Ze kunnen ook gefrustreerd zijn dat het bedrijf het incident niet heeft voorkomen.
Een goed klantbericht moet eerlijk zijn zonder alarmerend te zijn. Het moet technisch jargon vermijden, maar wel duidelijk zijn. Klanten moeten begrijpen welke gegevens betrokken waren, welk risico dat oplevert en wat ze vervolgens moeten doen.
Een nuttige structuur is:
- wat er is gebeurd, op een detailniveau dat geschikt is voor klanten
- wanneer het bedrijf er weet van kreeg
- welke informatie of diensten mogelijk getroffen zijn
- welke stappen het bedrijf heeft genomen
- wat klanten nu moeten doen
- hoe het bedrijf updates zal verstrekken
- wie klanten kunnen contacteren met vragen
Als het onderzoek nog gaande is, moet dit worden gemeld. Nauwkeurigheid en transparantie helpen het vertrouwen te herstellen. Openheid over de impact vereist niet dat technische gegevens worden onthuld die iemand zouden helpen de aanval te herhalen.
Bij ernstige incidenten hebben klanten mogelijk praktische instructies nodig: wijzig een wachtwoord, schakel MFA in, let op phishing-e-mails, neem contact op met hun bank en negeer berichten die beweren van het bedrijf afkomstig te zijn, tenzij ze via een officieel kanaal komen. De melding moet die stappen gemakkelijk te begrijpen maken.
Wanneer en hoe regelgevende instanties te informeren
Niet elk beveiligingsincident hoeft te worden gemeld aan de toezichthoudende autoriteiten. Een meldingsplichtige inbreuk onder de Britse en EU-GDPR hangt af van of een inbreuk op persoonsgegevens waarschijnlijk een risico vormt voor de rechten en vrijheden van mensen.
De richtlijnen van de ICO over inbreuken op persoonsgegevens(nieuw venster) weerspiegelen een vereiste die zowel in de Britse als de EU-GDPR voorkomt: organisaties moeten een meldingsplichtige inbreuk zonder onnodige vertraging melden en uiterlijk binnen 72 uur nadat ze er kennis van hebben genomen. Een late melding vereist redenen voor de vertraging.
Dat venster van 72 uur kan druk opleveren, vooral wanneer het onderzoek nog niet is afgerond. De GDPR erkent dat organisaties niet alle gegevens binnen de eerste 72 uur hebben, dus informatie kan in fasen worden verstrekt, zolang verdere updates zonder onnodige vertraging worden gegeven.
Een melding aan de relevante toezichthoudende autoriteit (de ICO in het VK, of de nationale autoriteit voor gegevensbescherming in de EU) moet gewoonlijk het volgende bevatten:
- de aard van de inbreuk op persoonsgegevens
- de categorieën en het geschatte aantal getroffen personen
- de categorieën en het geschatte aantal getroffen persoonsgegevens
- de naam en contactgegevens van de DPO of een ander contactpunt
- de waarschijnlijke gevolgen van de inbreuk
- de maatregelen die zijn genomen of voorgesteld om het aan te pakken
De ICO biedt ook een centrale pagina om een inbreuk te melden(nieuw venster) en organisaties naar het juiste meldproces te leiden.
Voor getroffen personen ligt de drempel anders. Wanneer een inbreuk op persoonsgegevens waarschijnlijk een hoog risico vormt voor de rechten en vrijheden van mensen, moeten zij zonder onnodige vertraging worden geïnformeerd. Dit is een situatie waarin juridische, privacy- en leidinggevende teams vroegtijdig betrokken moeten worden, zelfs in een klein bedrijf.
Bereid berichten voor voordat u ze nodig heeft
Het slechtste moment om een communicatieproces te ontwerpen is tijdens een incident. Het is niet nuttig om verklaringen of richtlijnen uit te brengen die moeten worden bijgewerkt en gewijzigd.
Daarom is het nuttig om de structuur van uw berichten voor te bereiden voordat u ze nodig heeft. Niet de definitieve formulering, want elk incident zal anders zijn, maar de structuur: wie het bericht moet goedkeuren, welke gegevens moeten worden opgenomen, waar updates worden vastgelegd en wie verantwoordelijk is voor elk publiek.
Een eenvoudige communicatiekit is genoeg om het eerste uur minder chaotisch te maken. Deze kan het volgende bevatten:
- Een sjabloon voor een interne aankondiging van een incident
- Een sjabloon voor een melding aan klanten
- Een sjabloon voor een update voor partners of leveranciers
- Gesprekspunten voor klantenondersteuning
- Checklist voor een melding aan de toezichthoudende autoriteit
- Lijst met goedgekeurde woordvoerders
- Escalatiecontacten voor juridische zaken, IT, privacy, leidinggevenden en communicatie
- Een plek om alle updates en beslissingen vast te leggen
Voorbereiding geeft een team een veilig startpunt wanneer snelheid en nauwkeurigheid beide belangrijk zijn. Een voorbereid sjabloon zorgt dat er meer aandacht overblijft voor de feiten van het incident: wat er is gebeurd, wie er getroffen is, wat er al is gedaan en wat mensen vervolgens moeten doen.
Hoe Proton Pass for Business kan helpen
Communicatie over beveiligingsincidenten hangt af van feiten. Hoe duidelijker een bedrijf toegang beheert vóór een incident, hoe eenvoudiger het is om uit te leggen wat er is gebeurd, wat er mogelijk is getroffen en wat er is gewijzigd.
Een zakelijke wachtwoordbeheerder zoals Proton Pass for Business helpt teams om blootstelling door inloggegevens te verminderen. Medewerkers kunnen sterke wachtwoorden genereren, deze opslaan in versleutelde wachtwoordkluizen, automatisch aanvullen gebruiken, inloggegevens veilig delen, passkeys beheren en ingebouwde tweestapsverificatie gebruiken. Beheerders kunnen wachtwoordbeleid toepassen, activiteitenlogboeken bekijken, toegang beheren met op rollen gebaseerde controles en provisioning ondersteunen via SCIM- en SSO-integraties.
Tijdens een incident kunnen deze functies bedrijven helpen met meer vertrouwen te handelen. Als een medewerkersaccount in gevaar is gebracht, kunnen beheerders toegang controleren, gedeelde inloggegevens identificeren die mogelijk moeten worden geroteerd, sterkere verificatie afdwingen en de afhankelijkheid van wachtwoorden die via chat of spreadsheets worden gekopieerd verminderen.
Wees voorbereid om te reageren voordat een schending plaatsvindt met een zakelijke wachtwoordbeheerder.
