Meldtermijnen

Wanneer de entiteit kennis krijgt van het significante incident, niet wanneer het incident begon. Artikel 23, lid 4, rekent vanaf dat moment zowel de vroege waarschuwing (24 uur) als de incidentmelding (72 uur).

Volgens artikel 23, lid 4, onder a, geeft de vroege waarschuwing in voorkomend geval aan of het vermoeden bestaat dat het significante incident door onrechtmatige of kwaadwillige handelingen is veroorzaakt en of het grensoverschrijdende gevolgen kan hebben. De details volgen in de melding na 72 uur.

Nee: een maand na het versturen van de incidentmelding. Loopt het incident dan nog, dan is in plaats daarvan een voortgangsverslag verschuldigd, en het eindverslag binnen een maand na de afhandeling van het incident.

Ja. Een verlener van vertrouwensdiensten meldt significante incidenten die gevolgen hebben voor het verlenen van zijn vertrouwensdiensten binnen 24 uur na kennisname, in plaats van binnen 72 uur.

Volgens artikel 33 AVG meldt de verwerkingsverantwoordelijke een inbreuk in verband met persoonsgegevens zonder onredelijke vertraging en zo mogelijk uiterlijk 72 uur nadat hij er kennis van heeft gekregen aan de toezichthoudende autoriteit, tenzij het niet waarschijnlijk is dat de inbreuk een risico voor mensen inhoudt. Volgens artikel 34 moeten de betrokkenen zonder onredelijke vertraging worden ingelicht als de inbreuk waarschijnlijk een hoog risico inhoudt. NetSenX bereidt voor uw FG een melding onder artikel 33 voor; de beslissing en het indienen blijven bij u.

Artikel 14 van de Cyberweerbaarheidsverordening verplicht fabrikanten van producten met digitale elementen om actief uitgebuite kwetsbaarheden in hun producten en ernstige incidenten die de beveiliging van die producten raken in meerdere stappen te melden. Voor de stappen, hun termijnen en wie de meldingen ontvangt: zie Verordening (EU) 2024/2847, artikel 14. Deze meldplichten gelden vanaf 11 september 2026. Ze gelden voor fabrikanten, niet voor bedrijven die de producten alleen gebruiken, al kan het eigen incident van een gebruiker wel onder NIS2 of de AVG gemeld moeten worden.

DORA, de verordening digitale operationele weerbaarheid (Verordening (EU) 2022/2554), geldt sinds 17 januari 2025 voor financiële entiteiten zoals banken, verzekeraars, beleggingsondernemingen en betalingsinstellingen, en voor kritieke externe ICT-dienstverleners die op grond ervan zijn aangewezen. Artikel 19 verplicht financiële entiteiten ernstige ICT-gerelateerde incidenten te melden bij hun bevoegde autoriteit, met een eerste melding, een tussentijds verslag en een eindverslag; de termijnen staan in technische normen die op grond van artikel 20 zijn vastgesteld. Voor een financiële entiteit gaan de DORA-regels over ICT-incidenten voor op de algemene regels van NIS2. Levert u ICT-diensten aan een financiële entiteit, dan bereikt DORA u via het contract: artikel 30 noemt bepalingen die zulke contracten moeten bevatten, waaronder bijstand bij incidenten, auditrechten en exitplannen. Verwacht gedetailleerde vragen en clausules van financiële klanten.

Een incident dat ernstige operationele verstoring van uw diensten of financiële verliezen voor uw bedrijf heeft veroorzaakt of kan veroorzaken, of dat andere personen of organisaties heeft getroffen of kan treffen door aanzienlijke materiële of immateriële schade. Dat is de toets van artikel 23, lid 3, en alleen significante incidenten moeten worden gemeld. ‘Kan veroorzaken’ betekent dat u niet wacht tot de schade er is. Voor bepaalde digitale aanbieders, zoals cloud-, DNS- en managed service-providers, geeft Uitvoeringsverordening (EU) 2024/2690 preciezere drempels; voor anderen kunnen nationale wetten en toezichthouders richtsnoeren publiceren. Leg vooraf in uw incidentprocedure vast welke criteria u gebruikt, zoals diensten die een bepaalde tijd uitvallen, geraakte klantgegevens of een criminele dader, en wie de beslissing neemt. NetSenX bewaakt de termijnen zodra u besluit; het besluit is aan u.

Meestal niet als significant incident, maar het kan wel, en vrijwillig melden mag altijd. De plicht in artikel 23 betreft significante incidenten: die ernstige verstoring, financieel verlies of aanzienlijke schade voor anderen hebben veroorzaakt of hadden kunnen veroorzaken. Een aanval die gestopt is voordat hij enig effect had, voldoet daar normaal niet aan, maar een die heel dichtbij kwam, bijvoorbeeld ransomware die pas op de back-upserver werd ontdekt, mogelijk wel. NIS2 onderscheidt ook bijna-incidenten en significante cyberdreigingen, en artikel 30 laat entiteiten die vrijwillig melden, wat het CSIRT helpt anderen te waarschuwen. Leg elk zo'n voorval met uw redenering vast in het incidentregister, zodat u later kunt uitleggen waarom u wel of niet meldde. NetSenX bewaart de alerts achter elke beslissing.

Door vooraf alles voor te bereiden wat niet van het incident afhangt. De vroegtijdige waarschuwing van artikel 23, lid 4, onder a, is kort: ze meldt dat er een significant incident is en, waar van toepassing, of een onrechtmatige of kwaadwillige handeling wordt vermoed en of er grensoverschrijdende gevolgen kunnen zijn. De details volgen in de melding na 72 uur. Bereid dus een sjabloon van één pagina voor, het meldkanaal en de inlog voor uw nationale CSIRT of autoriteit, een aangewezen persoon met vervanger die mag melden, en een interne regel over wie beslist dat een incident significant is. Oefen eens per jaar. Kleine teams verliezen de meeste tijd met uitzoeken wat er gebeurde, dus zorg dat alerts ook 's nachts en in het weekend iemand bereiken. NetSenX start de termijnklok per incident en bewaart de alerts met tijd, apparaten en bestemmingen op één plek.

Een korte lijst met feiten, een klaarstaand kanaal en iemand die mag versturen. Voor de vroegtijdige waarschuwing zelf hebt u nodig: het tijdstip waarop u kennis kreeg van het incident; een eenvoudige beschrijving van wat tot nu toe geraakt is; of u een kwaadwillige of onrechtmatige handeling vermoedt; en of andere landen geraakt kunnen zijn. Begin voor de melding na 72 uur meteen te verzamelen: ernst en impact, geraakte systemen en diensten, indicatoren van compromittering zoals kwaadaardige adressen of bestandshashes, en de genomen maatregelen. Houd vanaf de eerste minuut een lopende tijdlijn bij van wie wat deed. Ga na of persoonsgegevens betrokken zijn, want er kan tegelijk een AVG-melding lopen. NetSenX levert het netwerkdeel van die tijdlijn: de eerste ongewone verbinding, betrokken apparaten, bestemmingen en volumes, en de termijnen van artikel 23 gerekend vanaf het moment van kennisname dat u vastlegt.

Soms. Volgens artikel 23, lid 1, stellen entiteiten die eronder vallen, waar passend, de afnemers van hun diensten onverwijld in kennis van significante incidenten die de verlening van die diensten waarschijnlijk nadelig beïnvloeden. Volgens artikel 23, lid 2, delen entiteiten, waar van toepassing, afnemers die mogelijk door een significante cyberdreiging worden getroffen ook mee welke maatregelen zij kunnen nemen, en waar passend de dreiging zelf. Toezichthouders kunnen zulke informatie ook bevelen. Het nationale recht regelt de details: in Duitsland kan het BSI bevelen afnemers te informeren (§ 35 lid 1 BSIG), en entiteiten in sectoren als financiën, digitale infrastructuur en beheer van ICT-diensten moeten hen over significante cyberdreigingen informeren (§ 35 lid 2). Contracten en de AVG kunnen eigen plichten toevoegen. Bereid een klantbericht voor als sjabloon in het incidentplan.

Vaak wel, als persoonsgegevens geraakt zijn, ook als er niets is gestolen. De AVG definieert in artikel 4, punt 12, een inbreuk in verband met persoonsgegevens als een inbreuk op de beveiliging die leidt tot vernietiging, verlies, wijziging of ongeoorloofde verstrekking van of toegang tot persoonsgegevens. Versleuteling door ransomware maakt gegevens onbeschikbaar, een inbreuk op de beschikbaarheid, en aanvallers kopiëren vaak data voordat ze versleutelen. Volgens artikel 33 meldt de verwerkingsverantwoordelijke de inbreuk zonder onredelijke vertraging en zo mogelijk binnen 72 uur nadat hij er kennis van kreeg bij de toezichthouder, tenzij het niet waarschijnlijk is dat de inbreuk een risico voor personen inhoudt, bijvoorbeeld omdat een recente back-up alles snel herstelde en er niets het netwerk verliet. Leg de redenering in beide gevallen vast. NetSenX kan laten zien of er vóór de versleuteling ongewone uploads van bewaakte apparaten vertrokken, wat voor die beoordeling telt.

Mogelijk wel bij de toezichthouder, maar vaak niet aan de betrokkenen. Artikel 34, lid 3, onder a, van de AVG zegt dat betrokkenen niet ingelicht hoeven te worden als de verwerkingsverantwoordelijke maatregelen had genomen, zoals versleuteling, die de gegevens onbegrijpelijk maken voor onbevoegden. De melding aan de toezichthouder volgens artikel 33 is een aparte vraag: die is nodig tenzij het niet waarschijnlijk is dat de inbreuk een risico voor personen oplevert, en dat hangt af van hoe sterk de versleuteling was, of de sleutel ook is uitgelekt en of de gegevens voor u nog beschikbaar zijn. Stond de sleutel op dezelfde gestolen laptop, of was de versleuteling zwak, behandel de gegevens dan als blootgesteld. Leg vast welke gegevens hoe versleuteld waren en waar de sleutels stonden. Netwerkbewijs van wat er wanneer is weggegaan, helpt uw functionaris gegevensbescherming beslissen.

Ja, in fasen, en te laat alleen met redenen. Artikel 33, lid 4, van de AVG staat toe de informatie zonder verdere onredelijke vertraging stapsgewijs te verstrekken als niet alles tegelijk kan, en artikel 33, lid 1, eist dat een melding na meer dan 72 uur vergezeld gaat van de redenen voor de vertraging. Wacht dus niet op het volledige beeld: stuur binnen de termijn een eerste melding met wat u weet, de aard van de inbreuk, de waarschijnlijke gevolgen, de genomen maatregelen en het contact van uw functionaris gegevensbescherming, en vul aan zodra feiten bekend worden. Leg vast wanneer u er kennis van kreeg en waarom een deel later kwam. Toezichthouders bieden meestal onlineformulieren die aanvullingen toestaan, zoals de Autoriteit Persoonsgegevens in Nederland. NetSenX bereidt uit de incidentgegevens een melding volgens artikel 33 voor uw FG voor; het indienen blijft bij u.

Wanneer de verwerkingsverantwoordelijke kennis krijgt van de inbreuk in verband met persoonsgegevens, niet wanneer de inbreuk begon. Artikel 33, lid 1, telt de 72 uur vanaf het moment van kennisname. Richtsnoeren van het Europees Comité voor gegevensbescherming gaan ervan uit dat een verwerkingsverantwoordelijke kennis heeft als hij met redelijke zekerheid weet dat er een beveiligingsincident is geweest waarbij persoonsgegevens zijn geraakt. Een kort eerste onderzoek om dat vast te stellen mag, maar het moet snel; kennisname uitstellen door niet te kijken kan niet. Een verwerker die een inbreuk ontdekt, moet de verwerkingsverantwoordelijke onverwijld inlichten (artikel 33, lid 2), en diens termijn begint meestal als hij het hoort. Leg daarom in uw incidentlog het exacte tijdstip vast waarop iemand concludeerde dat persoonsgegevens betrokken waren. NetSenX laat u dat moment per incident vastleggen en bewaart de alerts die tonen wanneer de activiteit begon.

Elke wet heeft een eigen melding, ontvanger en termijn, en één incident kan er meerdere uitlokken. Een significant incident bij een entiteit die eronder valt, gaat volgens artikel 23 van NIS2 naar het CSIRT of de bevoegde autoriteit; zijn persoonsgegevens geraakt, dan meldt de verwerkingsverantwoordelijke ook volgens artikel 33 van de AVG bij de privacytoezichthouder; een financiële entiteit meldt ernstige ICT-gerelateerde incidenten volgens artikel 19 van DORA in plaats van onder NIS2; en een fabrikant van producten kan plichten hebben onder de Cyberweerbaarheidsverordening, zie Verordening (EU) 2024/2847, artikel 14. Sommige nationale systemen hebben één portaal, maar ga er niet van uit dat één melding alles dekt. Houd één incidentdossier bij en maak elke melding daaruit, zodat de feiten kloppen. Artikel 35 van NIS2 vraagt NIS2-autoriteiten bovendien privacytoezichthouders te informeren over inbreuken die zij vernemen. NetSenX bewaakt de NIS2-termijnen en maakt uit dezelfde incidentgegevens een concept-AVG-melding volgens artikel 33.

Een incident dat een financiële entiteit als ernstig classificeert volgens de criteria van artikel 18 van DORA en de technische normen die daaronder zijn vastgesteld. Artikel 18 noemt criteria zoals het aantal en het belang van getroffen cliënten of financiële tegenpartijen, het bedrag of aantal getroffen transacties, reputatieschade, duur en uitvaltijd van de dienst, geografische spreiding, gegevensverlies dat beschikbaarheid, authenticiteit, integriteit of vertrouwelijkheid raakt, de kriticiteit van de getroffen diensten en economische impact. De normen maken daar drempels van. Alleen ernstige incidenten moeten volgens artikel 19 worden gemeld; significante cyberdreigingen mogen vrijwillig worden gemeld. Bouw de classificatie in uw incidentprocedure in, zodat het besluit snel, herhaalbaar en vastgelegd is, en spreek met uw ICT-leveranciers af hoe zij u de benodigde feiten aanleveren. Financiële klanten verwachten dat ook van hun leveranciers.

Die staan in de technische normen die op grond van artikel 20 van DORA zijn vastgesteld, niet in de verordening zelf; lees voor de exacte uren en dagen die normen en de richtsnoeren van uw bevoegde autoriteit. Artikel 19, lid 4, legt de volgorde vast: een eerste melding, een tussentijds verslag zodra de status van het oorspronkelijke incident aanzienlijk is veranderd of de afhandeling op basis van nieuwe informatie is gewijzigd, gevolgd door bijgewerkte meldingen waar nodig, en een eindverslag zodra de analyse van de grondoorzaak is afgerond. De normen bepalen ook inhoud en sjablonen. Omdat de termijnen gekoppeld zijn aan de detectie van het incident en de classificatie als ernstig, telt de snelheid van classificeren net zo zwaar als die van schrijven. Bent u ICT-leverancier van een financiële entiteit, dan eist uw contract waarschijnlijk dat u de klant snel genoeg informeert om die termijnen te halen.

Via het centrale meldplatform dat ENISA voor de Cyberweerbaarheidsverordening beheert. Volgens artikel 14 van Verordening (EU) 2024/2847 melden fabrikanten van producten met digitale elementen actief uitgebuite kwetsbaarheden in hun producten, en ernstige incidenten die de beveiliging van die producten raken, via dat platform; de melding gaat naar het CSIRT dat als coördinator is aangewezen in de lidstaat van de hoofdvestiging van de fabrikant en naar ENISA. Zie voor de stappen, termijnen en inhoud Verordening (EU) 2024/2847, artikel 14. Deze plichten gelden voor fabrikanten, ook softwarebedrijven die producten op de EU-markt brengen, niet voor bedrijven die de producten alleen gebruiken. Gebruikers kunnen na hetzelfde voorval eigen NIS2- of AVG-meldingen moeten doen. Ontwikkelt u software, zet dan een proces voor kwetsbaarheidsbeheer op en bepaal wie toegang heeft tot het platform voordat u het nodig hebt.

Vaak wel, maar het is een aparte beslissing naast de wettelijke meldingen. Een ransomware-aanval, datadiefstal, fraude of afpersing is meestal een strafbaar feit, en aangifte kan helpen bij de verzekeringsclaim, bij de bank die een frauduleuze overboeking probeert terug te halen en bij onderzoeken die uw zaak aan andere koppelen; sommige verzekeraars vragen om een proces-verbaalnummer. Aangifte vervangt geen melding bij het CSIRT, de bevoegde autoriteit of de privacytoezichthouder, en die vervangen geen aangifte. Veel landen hebben gespecialiseerde cybercrime-eenheden of onlineformulieren. Spreek vóór de aangifte met uw advocaten en incidentresponsbureau af welk bewijs u overdraagt en hoe u het veiligstelt, zodat u niet vernietigt wat rechercheurs nodig hebben. De vroegtijdige waarschuwing onder NIS2 vraagt al of u een onrechtmatige of kwaadwillige handeling vermoedt; dat antwoord en de aangifte moeten met elkaar kloppen.

De basis is overal gelijk: wat er gebeurde, wanneer, wat er geraakt is, hoe ernstig het is, wat u hebt gedaan en wie het contactpunt is. Volgens artikel 23, lid 4, van NIS2 zegt de vroegtijdige waarschuwing of een kwaadwillige of onrechtmatige handeling wordt vermoed en of er grensoverschrijdende gevolgen kunnen zijn; de melding na 72 uur voegt een eerste beoordeling van ernst en impact toe en, indien beschikbaar, indicatoren van compromittering; het eindverslag voegt een gedetailleerde beschrijving toe, het soort dreiging of de grondoorzaak, risicobeperkende maatregelen en grensoverschrijdende gevolgen. Volgens artikel 33, lid 3, van de AVG beschrijft een melding de aard van de inbreuk, de categorieën en het geschatte aantal betrokkenen en gegevensregels, de waarschijnlijke gevolgen, de genomen maatregelen en het contact van de functionaris gegevensbescherming. Houd feiten en aannames duidelijk gescheiden. NetSenX levert uit het netwerk tijden, apparaten, bestemmingen en volumes.

Ja, als het significant was of een meldplichtige inbreuk in verband met persoonsgegevens betrof; het oplossen neemt de plicht niet weg. Artikel 23 van NIS2 koppelt de meldplicht aan het significante incident, of het nog loopt of niet, en de termijnen lopen vanaf het moment dat u er kennis van kreeg. Ontdekt u pas nu dat de storing van vorige maand een aanval was, dan begint de klok bij die ontdekking en meldt u zo snel mogelijk, met uitleg over de tijdlijn. Volgens de AVG moet een inbreuk die waarschijnlijk een risico voor personen oplevert ook na indamming worden gemeld; de indamming kan het risico verlagen en de inhoud beïnvloeden. Een opgelost incident kunt u meestal direct melden met de al bekende feiten, maar volg het format van uw toezichthouder. Leg de data van optreden, kennisname en oplossing apart vast.

Vooral wat u ervoor en erna deed: tijdig melden, echt schade beperken en meewerken. Artikel 83, lid 2, van de AVG noemt de factoren die toezichthouders wegen, waaronder aard, ernst en duur van de inbreuk, opzet of nalatigheid, de maatregelen om de schade voor betrokkenen te beperken, de technische en organisatorische maatregelen die er al waren, eerdere inbreuken, de mate van medewerking met de toezichthouder, de betrokken categorieën gegevens en de manier waarop de toezichthouder van de inbreuk hoorde, met name of u die meldde. Voor de ernstigste inbreuken kunnen boetes volgens artikel 83, lid 5, oplopen tot 20 miljoen euro of 4% van de wereldwijde jaaromzet. In de praktijk: meld op tijd met feiten, toon de beveiligingsmaatregelen die er waren, dam de inbreuk snel in, informeer betrokkenen waar nodig en leg elke stap vast. NetSenX helpt met de tijdlijn en met een concept volgens artikel 33 voor uw functionaris gegevensbescherming.

Ja, als concept voor uw functionaris gegevensbescherming; beslissen en indienen blijven bij u. Uit de incidentgegevens stelt NetSenX een concept op met wat het netwerk toont: wanneer het probleem werd ontdekt en welke apparaten en bestemmingen betrokken waren. Artikel 33, lid 3, vraagt ook informatie die alleen u hebt, zoals de categorieën en het geschatte aantal betrokkenen en gegevensregels, de waarschijnlijke gevolgen, de genomen maatregelen en de contactgegevens van de FG. Netwerkbewijs heeft grenzen: NetSenX ziet verbindingen, volumes en bestemmingen, niet welke bestanden of records weggingen, dus de FG moet de inhoud uit andere bronnen aanvullen. Het concept bespaart tijd op vrijdagavond, als de termijn van 72 uur loopt, en houdt de feiten in lijn met uw NIS2-meldingen. Controleer het, vul het aan en dien het zelf in bij uw toezichthouder.

Ja, voor het deel van de controls dat over de tool zelf gaat. Accountants en ISO- of SOC 2-auditors toetsen IT general controls: wie toegang heeft tot systemen, hoe wijzigingen worden goedgekeurd en vastgelegd, en hoe beheer en incidenten worden bewaakt. Het auditlog van een beveiligingstool levert bewijs voor zijn eigen deel: wie accounts heeft, wie detectie-instellingen of meldregels wijzigde, wie elke alert sloot of erover besliste, en wanneer. In elk abonnement houdt NetSenX zo'n auditlog bij, met een bewaartermijn die met het abonnement meegroeit. Wijzigingen in uw ERP, bestandsservers of andere systemen legt het niet vast; die hebben eigen logs nodig. Exporteer het uittreksel voor de auditperiode en leg het naast uw toegangsreviews en wijzigingstickets, zodat de auditor één samenhangend verhaal ziet.

Met een auditlog dat elke wijziging, de persoon die haar deed en het tijdstip vastlegt, bewaard waar het niet stilletjes te bewerken is. Voor uw eigen systemen betekent dat: zet wijzigingslogging aan op firewalls, directoryservices, cloudconsoles en beveiligingstools, stuur de logs naar een centrale plek met beperkte toegang en koppel wijzigingen aan goedgekeurde tickets. Gedeelde beheerdersaccounts maken bewijs onmogelijk, dus geef ieder een eigen account op naam met multifactorauthenticatie. Controleer de logs op onverwachte wijzigingen, vooral buiten werktijd. Voor NetSenX zelf legt het auditlog in elk abonnement vast wie detectie-instellingen, meldregels of teamleden wijzigde en wie over alerts besliste, met tijdstempel; het uittreksel kunt u voor een auditor exporteren. Het dekt wijzigingen in NetSenX, niet instellingen in uw andere systemen.

Met een eenvoudige dekkingsverklaring die met bewijs is onderbouwd, inclusief de gaten. Zet elke locatie en elk netwerksegment op een rij, of een sensor of agent het bewaakt, sinds wanneer en wat het dekt; geef daarna aan wat niet bewaakt wordt, zoals gastwifi, een vestiging of een cloudomgeving, en hoe u dat anders afhandelt. Voeg bewijs toe: de sensorlijst, een recente alert uit elk bewaakt segment en de netwerkkaart. Auditors vertrouwen een eerlijke verklaring met bekende gaten meer dan een claim van volledige dekking die bij de eerste vraag omvalt. Bij NetSenX bewaakt één agent op de mirrorpoort van een switch (SPAN) of op een netwerk-TAP een heel segment, en het dashboard toont welke agents waar draaien; verkeer op een segment dat u niet spiegelt, blijft buiten beeld, en NetSenX doet niet alsof het anders is.

Alles wat alleen binnen dat segment gebeurt. Een sensor ziet het verkeer dat hij ontvangt; wordt een switchpoort niet naar hem gespiegeld en draait er geen agent op de hosts daar, dan blijven verbindingen tussen apparaten in dat segment onzichtbaar, zoals een aanvaller die van een pc naar de bestandsserver ernaast gaat. Verkeer dat het segment via een bewaakt punt verlaat, bijvoorbeeld naar internet of een andere locatie, ziet u mogelijk nog wel, maar juist de interne stappen van een inbraak zijn vaak wat u nodig hebt. Beslis op risico: spiegel eerst de segmenten met servers, administratie, financiën, HR en productie, daarna de rest. Waar spiegelen onpraktisch is, laat u de agent op de belangrijke hosts zelf draaien. NetSenX toont welke segmenten de sensoren en agents bewaken, zodat de gaten zichtbaar zijn.

Genoeg om elk incident en elke beslissing te reconstrueren zonder op iemands geheugen te vertrouwen. Per regel: een uniek kenmerk; wanneer het incident begon, wanneer en waarmee het werd opgemerkt, en wanneer het als significant werd aangemerkt of niet; een korte beschrijving en de geraakte systemen, diensten en gegevens; de ernstbeoordeling en wie die maakte; of het is gemeld, bij wie en op welke tijdstippen, met kopieën van de meldingen; de stappen voor indammen, verwijderen en herstellen met tijden en eigenaren; de grondoorzaak; en de lessen en veranderingen die volgden. Leg ook bijna-incidenten vast, met de reden dat ze niet zijn gemeld. Houd het log manipulatiebestendig en met toegangsbeheer. NetSenX levert het netwerkdeel automatisch: alerts met tijd, apparaten en bestemmingen, NIS2-termijnen per incident en het auditlog van wie wat besliste.

Met een vastlegging die elke alert koppelt aan een beslissing, een persoon, een tijdstip en een reden. Auditors willen zien dat alerts niet verdwijnen: elke alert is bekeken, ingedeeld als onschuldig, in onderzoek of incident, en afgesloten met een toelichting. Een spreadsheet volstaat voor een handvol alerts, maar loopt vast als het volume groeit en is achteraf makkelijk in te vullen. Gebruik waar mogelijk de werkstroom in de tool zelf, schrijf korte redenen in plaats van statussen van één woord, en controleer elk kwartaal een steekproef van gesloten alerts op de kwaliteit van de beslissingen. In NetSenX worden beslissingen van analisten over alerts in elk abonnement in het auditlog vastgelegd, met wie besliste en wanneer; vanaf Starter kunt u pdf-rapporten voor de auditor exporteren.

NIS2 stelt geen vaste bewaartermijn, dus bepaal er zelf een en schrijf op waarom. Verschillende regels wijzen dezelfde kant op. De AVG verplicht elke inbreuk in verband met persoonsgegevens te documenteren (artikel 33, lid 5), zodat de toezichthouder de naleving kan controleren, wat betekent dat u het dossier bewaart zolang zo'n controle redelijkerwijs kan komen. NIS2-toezichthouders kunnen bewijs van eerdere incidenten en meldingen vragen, verzekeraars kunnen een claim lang na het voorval onderzoeken, en verjaringstermijnen voor contractuele en aansprakelijkheidsclaims lopen in veel landen jaren. Sector- en nationale regels kunnen eigen termijnen stellen. Gebruikelijk is het incidentregister en de meldingen enkele jaren te bewaren en ruwe logs korter, met verwijdering van persoonsgegevens die niet meer nodig zijn. De bewaartermijn van alertgeschiedenis en auditlog in NetSenX hangt af van het abonnement; exporteer wat u langer moet bewaren.

Ja, voor de bewaakte segmenten, en die is vaak nauwkeuriger dan een getekend schema. Een kaart op basis van waargenomen verkeer toont welke apparaten er zijn, welke namen ze melden en wie met wie praat, inclusief verbindingen die niemand documenteerde, zoals een werkplek die een server bereikt die hij niet zou moeten bereiken of de externe sessie van een leverancier. Ze toont niet wat nooit verkeer verstuurt, segmenten zonder sensor of het bedoelde ontwerp, dus houd uw architectuurschema en controleer het met de waargenomen kaart. In elk abonnement maakt NetSenX zo'n netwerkkaart uit bewaakt verkeer, met wanneer elk apparaat voor het eerst en het laatst is gezien. Bedenk vóór u hem aan een externe auditor toont wat hij onthult: apparaatnamen kunnen namen van medewerkers bevatten en de kaart beschrijft uw interne structuur, dus toon hem op het scherm of onder een geheimhoudingsovereenkomst.

Ja. Artikel 33, lid 5, van de AVG verplicht de verwerkingsverantwoordelijke elke inbreuk in verband met persoonsgegevens te documenteren, met de feiten, de gevolgen en de genomen corrigerende maatregelen, of de inbreuk nu bij de toezichthouder is gemeld of niet. Zo kan de toezichthouder later de naleving controleren, ook uw besluit dat een inbreuk waarschijnlijk geen risico voor personen opleverde. Leg dus per inbreuk vast wat er gebeurde, welke gegevens en personen geraakt waren, waarom u concludeerde dat melden wel of niet nodig was, wie wanneer besliste en wat u veranderde. Houd een register van datalekken bij, los van maar gekoppeld aan uw beveiligingsincidentlog. Toezichthouders kunnen het opvragen bij een inspectie of na een klacht, en een ontbrekende vastlegging van een niet-gemeld lek oogt slechter dan het lek zelf. NetSenX bewaart het alertbewijs achter elke regel gedurende de bewaartermijn van uw abonnement.

Als het lek waarschijnlijk een hoog risico voor hun rechten en vrijheden oplevert. Artikel 34 van de AVG verplicht de verwerkingsverantwoordelijke dan hen onverwijld in te lichten, in duidelijke en eenvoudige taal, met de aard van de inbreuk, de waarschijnlijke gevolgen, de genomen of voorgestelde maatregelen en het contact van de functionaris gegevensbescherming. Hoog risico gaat meestal over gegevens die echte schade kunnen doen, zoals identiteitsbewijzen, bank- of gezondheidsgegevens, wachtwoorden of informatie die fraude mogelijk maakt. Artikel 34, lid 3, kent uitzonderingen: de gegevens zijn onbegrijpelijk gemaakt, bijvoorbeeld met sterke versleuteling; latere maatregelen maken het hoge risico onwaarschijnlijk; of individuele berichten zouden onevenredige inspanning vergen, en dan volstaat een openbare mededeling. Ook de toezichthouder kan eisen dat u betrokkenen informeert. Vertel mensen wat ze moeten doen, zoals wachtwoorden wijzigen of alert zijn op phishing.