Legal hold bij cyberincidenten voor GDPR, NIS2 en DORA

Om 04:17 ontving Maria, de CISO van een fintech-SaaS-aanbieder, het telefoontje waarop iedere securityleider zich voorbereidt en waarvan iedereen hoopt dat het nooit komt. Kritieke productieservers reageerden niet meer. Bestanden waren versleuteld. Op het scherm van een junior beheerder stond een losgeldbericht open.

Om 04:28 wilde het incidentresponsteam getroffen systemen isoleren en schone infrastructuur opnieuw uitrollen. Om 04:41 vroeg engineering of zij inloggegevens konden roteren, tijdelijke bestanden konden opschonen en containers opnieuw konden opbouwen. Om 05:03 waarschuwde de functionaris voor gegevensbescherming dat de gecompromitteerde omgeving klantidentificatoren en transactiemetadata bevatte. Om 05:16 sloot de juridisch adviseur aan op de crisisbridge met één instructie: “Vernietig geen mogelijk bewijsmateriaal. Mogelijk moeten we een legal hold instellen.” Om 05:30 vroeg de COO of DORA-rapportageverplichtingen waren geactiveerd. Om 06:00 dacht Maria aan de NIS2-klok: een vroege waarschuwing kan binnen 24 uur verschuldigd zijn, een uitgebreidere melding binnen 72 uur en een eindrapport binnen een maand.

Toen kwam de vraag die bepaalt of een cyberincident verdedigbaar of chaotisch wordt:

“Hebben we de logboeken nog?”

Dit is het governanceprobleem na incidenten dat veel responsplannen onderschatten. Detecteren, indammen en herstellen is niet genoeg. In 2026 moeten organisaties ook kunnen aantonen wat er is gebeurd, relevant bewijsmateriaal bewaren, voorkomen dat forensische artefacten worden aangetast, GDPR-gegevensminimalisatie respecteren, NIS2-toezicht ondersteunen en DORA-ICT-risicoregistraties bijhouden die bestand zijn tegen audit, gerechtelijke procedures en toetsing door toezichthouders.

Legal hold bij cyberincidenten en het bewaren van bewijsmateriaal liggen op het snijvlak van security operations, privacy, juridische zaken, compliance, cloudengineering, leveranciersmanagement en audit. Als het proces tijdens een inbreuk wordt geïmproviseerd, kan de organisatie het bewijsmateriaal verliezen dat nodig is voor oorzaakanalyse, rapportage aan toezichthouders, verzekeringsclaims, juridische verdediging, disciplinaire maatregelen en assurance richting klanten. Als het te ruim wordt toegepast, kan de organisatie te veel persoonsgegevens bewaren en een tweede complianceprobleem creëren.

De aanpak van Clarysec is om legal hold als een beheerst ISMS-proces in te richten, niet als een paniekreactie. Het model verbindt ISO/IEC 27001:2022-governance, ISO/IEC 27002:2022-beheersmaatregelen voor bewijsmateriaal en logging, GDPR-verantwoordingsplicht, NIS2-incidentrapportage en DORA-ICT-risicobewijsmateriaal tot één operationeel systeem. Dat systeem vertelt teams wat zij moeten bewaren, wie bewaring mag autoriseren, hoelang bewijsmateriaal onder hold blijft, wie er toegang toe mag hebben en wanneer verwijdering kan worden hervat.

De eerste 24 uur bepalen of het bewijsmateriaal behouden blijft

Bij veel echte incidenten wordt bewijsmateriaal niet door aanvallers vernietigd. Het wordt vernietigd door reguliere operationele processen.

Een bewaartermijn voor cloudlogboeken verloopt. Een container wordt opnieuw uitgerold. Een endpoint wordt opnieuw geïnstalleerd voordat het geheugen is veiliggesteld. Een SaaS-beheerder exporteert een CSV voor onderzoek en bewerkt daarna het bestand. Een goedbedoelende engineer verwijdert malafide scripts voordat een forensische kopie is gemaakt. Een bewaartaak in een datawarehouse verwijdert de registraties die nodig zijn om vast te stellen welke klanten zijn getroffen.

De organisatie kan operationeel nog steeds herstellen, maar verliest bewijs. Dat onderscheid is relevant.

Onder GDPR moet een verwerkingsverantwoordelijke kunnen aantonen dat de beginselen voor gegevensbescherming worden nageleefd, waaronder integriteit en vertrouwelijkheid, doelbinding, gegevensminimalisatie en opslagbeperking. Als een inbreuk in verband met persoonsgegevens waarschijnlijk een risico voor natuurlijke personen oplevert, kan Article 33 vereisen dat de toezichthoudende autoriteit zonder onredelijke vertraging en, waar mogelijk, binnen 72 uur na kennisname wordt geïnformeerd. Als de inbreuk waarschijnlijk een hoog risico voor natuurlijke personen oplevert, kan Article 34 vereisen dat getroffen betrokkenen worden geïnformeerd.

Onder NIS2 moeten essentiële en belangrijke entiteiten significante incidenten beheren via gefaseerde rapportage en toezicht. Onder DORA moeten financiële entiteiten ICT-gerelateerde incidenten registreren, majeure incidenten classificeren, deze rapporteren, oorzaakanalyse uitvoeren en bewijsmateriaal bewaren over ICT-activa, bedrijfsfuncties en afhankelijkheden van derde partijen heen.

ISO/IEC 27001:2022 biedt hiervoor de managementsysteemstructuur. Clausule 4.2 vereist dat een organisatie de behoeften en verwachtingen van belanghebbenden bepaalt, inclusief wettelijke, regelgevende en contractuele eisen die relevant zijn voor informatiebeveiliging. Clausule 4.3 vereist dat het ISMS-toepassingsgebied interfaces en afhankelijkheden meeneemt; dat is kritisch wanneer bewijsmateriaal zich bevindt bij een cloudprovider, managed security provider, betaalplatform of uitbestede helpdesk. Clausule 6.1 koppelt deze verplichtingen aan informatiebeveiligingsrisico’s en risicobehandeling. Clausule 7.5 vereist beheerste gedocumenteerde informatie. Clausule 8 vereist operationele planning en beheersing.

Clarysec’s Zenith Blueprint: een 30-stappenroadmap voor auditors legt uit waarom dit vóór het incident moet worden ontworpen, niet tijdens het incident. In de fase Controls in Action, stap 23, staat in de guidance voor ISO/IEC 27002:2022 beheersmaatregel 5.28:

“Wanneer zich een informatiebeveiligingsincident voordoet, is een van de meest kritieke, maar vaak over het hoofd geziene elementen van respons bewijsmateriaal. Geen logboeken, geen screenshots, geen losse reconstructies, maar correct bewaard, chain-of-custody-respecterend en manipulatiebestendig bewijsmateriaal.”

Dezelfde stap 23 voegt toe dat “wat u kunt aantonen net zo belangrijk is als wat er daadwerkelijk is gebeurd.” Die zin markeert het verschil tussen incidentrespons en verdedigbare incidentrespons. Een toezichthouder, klantauditor, rechtbank, verzekeraar of bevoegde autoriteit accepteert geen mondelinge reconstructie als de organisatie geen bewaarde logboeken, betrouwbare tijdstempels, beheerste registraties en gedocumenteerde chain-of-custody kan tonen.

Legal hold is niet “alles voor altijd bewaren”

Een legal hold bij een cyberincident is een formele opschorting van reguliere verwijdering of vernietiging voor gedefinieerde registraties, logboeken, back-ups, images, communicatie en ander bewijsmateriaal dat relevant kan zijn voor een onderzoek, gerechtelijke procedure, verzoek van een toezichthouder, audit of contractueel geschil.

De meest voorkomende fout is legal hold behandelen als een algemene instructie: “Niets verwijderen.” Dat creëert privacy-, kosten- en operationele risico’s. GDPR verdwijnt niet tijdens een cyberincident. Persoonsgegevens moeten nog steeds rechtmatig, behoorlijk en transparant worden verwerkt, voor specifieke doeleinden, beperkt tot wat noodzakelijk is en niet langer bewaard dan noodzakelijk. Article 5(2) voegt daar verantwoordingsplicht aan toe: de organisatie moet deze keuzes kunnen aantonen.

Hier wordt de beleidsbibliotheek van Clarysec praktisch toepasbaar. Het mkb-Beleid voor gegevensbewaring en veilige vernietiging bepaalt:

“Legal hold en opschorting van verwijdering gaan vóór standaardbewaarvereisten en voorkomen verwijdering van gegevens.”

Voor grotere organisaties stelt het Enterprise Beleid voor gegevensbewaring en vernietiging, Clausule 6.4.1:

“Als een legal hold en opschorting van verwijdering wordt uitgevaardigd (bijv. in afwachting van gerechtelijke procedure, onderzoek of audit), moeten gegevens die anders voor vernietiging in aanmerking komen, langer dan hun normale bewaartermijn worden bewaard.”

Hetzelfde Enterprise-beleid vereist dat de hold wordt:

“Gedocumenteerd en goedgekeurd door de juridisch adviseur en de functionaris voor gegevensbescherming (FG)”

Dat goedkeuringsmodel is geen bureaucratie. Het is het afwegingsmechanisme tussen bewaring van bewijsmateriaal en terughoudendheid vanuit privacy. De juridisch adviseur bevestigt de grondslag voor gerechtelijke procedure, onderzoek of regelgeving. De FG bevestigt dat de reikwijdte, het doel, de categorieën persoonsgegevens, toegangsbeheersmaatregelen en verlenging van de bewaartermijn proportioneel blijven.

Voor mkb-organisaties zonder volledige juridische afdeling of FG-functie kan dezelfde beslislogica worden uitgevoerd door een vCISO, privacy-eigenaar, algemeen directeur en externe juridisch adviseur, zolang de autorisatie gedocumenteerd, tijdgebonden en beoordeeld wordt.

De compliancespanning die elke CISO moet oplossen

Na een ernstig incident vragen verschillende stakeholders om verschillend bewijsmateriaal. Juridische zaken wil bewaring. Privacy wil minimalisatie. Toezichthouders willen feiten. Operations wil herstel. Klanten willen assurance. Auditors willen objectief bewijsmateriaal.

Deze eisen beheren via afzonderlijke privacy-, juridische, SOC- en auditworkflows leidt tot tegenstrijdigheden. Een geïntegreerd ISO/IEC 27001:2022 ISMS maakt ze onderdeel van één proces voor risico, beheersmaatregelen en bewijsmateriaal.

De beheersmaatregelenstack voor verdedigbare bewaring van bewijsmateriaal

Legal hold bij cyberincidenten is niet één ISO/IEC 27002:2022-beheersmaatregel. Het is een samenhang tussen beheersmaatregelen.

Clarysec’s Zenith Controls: de cross-compliancegids koppelt ISO/IEC 27002:2022 beheersmaatregel 5.28, Verzamelen van bewijsmateriaal, als corrigerende beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt. Deze valt binnen de cybersecurityconcepten Detect en Respond en de operationele capability voor beheer van informatiebeveiligingsgebeurtenissen.

Dezelfde Zenith Controls-gids verbindt 5.28 met respons op informatiebeveiligingsincidenten, logging en monitoring, bescherming van registraties en eventrapportage. De logica is praktisch: incidentresponders hebben logboeken en artefacten nodig voordat herstelmaatregelen de situatie wijzigen, regelgevende rapporteurs hebben betrouwbare feiten nodig en onderzoekers hebben bewijsmateriaal nodig dat niet is gewijzigd.

ISO/IEC 27002:2022 beheersmaatregel 5.33, Bescherming van registraties, is even belangrijk. Deze ondersteunt wettelijke en compliance-eisen, beheer van bedrijfsmiddelen en informatiebescherming. De maatregel koppelt bescherming van registraties aan classificatie, back-ups, veilige vernietiging, wettelijke en contractuele eisen, toegangscontrole en incidentrespons. In de praktijk moet een legal hold niet alleen bewijsmateriaal vastleggen. De hold moet ook de integriteit, vertrouwelijkheid en beschikbaarheid van het bewijsdossier zelf beschermen.

Voor logging vormt ISO/IEC 27002:2022 beheersmaatregel 8.15, Logging, de basis. Deze is verbonden met 8.16, Monitoringactiviteiten, en 8.17, Kloksynchronisatie. Als logboeken onvolledig zijn, door beheerders kunnen worden bewerkt, niet tijdgesynchroniseerd zijn of te kort worden bewaard, kan het bewijsproces al falen voordat het onderzoek begint.

De Zenith Blueprint, fase Controls in Action, stap 19, versterkt dit met praktische taal over logging:

“Logboeken die activiteiten, uitzonderingen, fouten en andere relevante gebeurtenissen vastleggen, moeten worden geproduceerd, opgeslagen, beschermd en geanalyseerd.”

Dezelfde guidance waarschuwt dat bescherming van logboeken ook het beperken van toegang omvat en het gebruik van mechanismen zoals hashing of write-once-opslag om manipulatie te voorkomen. Stap 19 verbindt kloksynchronisatie met forensische samenhang en legt uit dat gesynchroniseerde klokken logboeken uit verschillende systemen op elkaar laten aansluiten voor onderzoek.

GDPR-verantwoordingsplicht: bewaar wat nodig is, onderbouw wat u bewaart

GDPR creëert de meest zichtbare spanning bij het bewaren van incidentbewijsmateriaal. Beveiligingsteams willen vaak meer gegevens. Privacyteams willen minder. Een verdedigbare legal hold verenigt beide.

Logboeken en artefacten kunnen IP-adressen, gebruikers-ID’s, e-mailadressen, apparaat-ID’s, authenticatieregistraties, tekst uit supporttickets, screenshots, klantexporten of bijzondere categorieën persoonsgegevens bevatten. Bewaring van bewijsmateriaal is daarom verwerking. De legal-holdkennisgeving moet de rechtsgrondslag, het doel, de reikwijdte, toegangsbeperkingen, beoordelingsdatum voor bewaring en trigger voor vernietiging documenteren.

Clarysec’s mkb-Beleid inzake gegevensbescherming en privacy stelt:

“Alleen de minimaal noodzakelijke persoonsgegevens mogen worden verzameld en bewaard”

Het Enterprise Beleid inzake bewijsverzameling en forensisch onderzoek verankert forensische bewijsbehandeling expliciet in:

“GDPR Article 5, inclusief doelbinding en gegevensminimalisatie”

Dat is het operationele principe. Bewaar geen volledige productiedatabase als het relevante bewijsmateriaal bestaat uit een beperkte audittrail, toegangslogboek, queryregistratie en lijst met getroffen gebruikers. Geef niet iedere responder toegang tot ruw bewijsmateriaal als gepseudonimiseerde extracten of rolgebaseerde toegang volstaan. Bewaar incidentartefacten niet onbeperkt nadat de juridische, regelgevende en auditbehoefte is vervallen.

Een goede GDPR-bewuste legal-holdregistratie beantwoordt zeven vragen:

1. Welk incident of onderzoek heeft de hold geactiveerd?
2. Welke categorieën persoonsgegevens kunnen zijn opgenomen?
3. Waarom is elke bewijscategorie noodzakelijk?
4. Wie heeft de hold goedgekeurd en wanneer?
5. Wie heeft toegang tot het bewijsmateriaal?
6. Wanneer wordt de hold beoordeeld?
7. Welk verwijderings- of veilige vernietigingsproces wordt hervat wanneer de hold wordt vrijgegeven?

Zo voorkomt bewaring van bewijsmateriaal dat privacy-overbewaring ontstaat.

NIS2: legal hold voor gefaseerde incidentrapportage

Voor organisaties binnen de reikwijdte verandert NIS2 de verwachting rond bewijsmateriaal van “intern nuttig” naar “nodig voor toezicht”.

NIS2 is van toepassing op veel essentiële en belangrijke entiteiten in de EU, waaronder aanbieders van digitale infrastructuur, aanbieders van cloudcomputingdiensten, datacenteraanbieders, content delivery networks, aanbieders van vertrouwensdiensten, aanbieders van elektronische communicatie, managed service providers, managed security service providers en bepaalde digitale aanbieders zoals onlinemarktplaatsen, onlinezoekmachines en socialenetwerkplatformen.

Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, beoordeling van doeltreffendheid, training, cryptografie, beveiliging binnen human resources, toegangscontrole, beheer van bedrijfsmiddelen en authenticatie. Article 20 maakt bestuursorganen verantwoordelijk voor het goedkeuren van en toezicht houden op deze maatregelen.

Voor legal hold is Article 23 het kernpunt binnen NIS2. Significante incidenten vereisen gefaseerde rapportage: een vroege waarschuwing binnen 24 uur na kennisname, een incidentmelding binnen 72 uur, tussentijdse rapporten op verzoek en een eindrapport uiterlijk één maand na de 72-uursmelding. Het eindrapport vereist een beschrijving, ernst, impact, waarschijnlijk type dreiging of oorzaak, risicobeperkende maatregelen en, waar van toepassing, grensoverschrijdende impact.

Als het incident persoonsgegevens raakt, kunnen NIS2-bevoegde autoriteiten samenwerken met GDPR-toezichthoudende autoriteiten. Dat vergroot de behoefte aan één bewijsnarratief dat zowel cybersecuritytoezicht als privacyverantwoordingsplicht ondersteunt.

DORA: ICT-risicobewijsmateriaal gaat verder dan beveiligingslogboeken

Voor financiële entiteiten is DORA het sectorspecifieke regime voor operationele weerbaarheid. Het is van toepassing vanaf 17 januari 2025 en bestrijkt ICT-risicobeheer, rapportage van majeure ICT-incidenten, weerbaarheidstesten, informatie-uitwisseling en ICT-risicobeheer voor derde partijen. Voor financiële entiteiten die ook essentieel of belangrijk zijn onder NIS2, functioneert DORA doorgaans als de sectorspecifieke rechtshandeling van de Unie voor ICT-risico en incidentrapportage.

DORA is bewust bewijsintensief opgezet. Article 17 vereist een proces voor beheer van ICT-gerelateerde incidenten. Article 18 behandelt classificatie van ICT-gerelateerde incidenten en cyberdreigingen. Article 19 bestrijkt rapportage van majeure ICT-gerelateerde incidenten. Financiële entiteiten moeten ook governance- en beheersingsregelingen onderhouden, kritieke of belangrijke functies identificeren, ICT-activa en afhankelijkheden documenteren en oorzaakanalyse uitvoeren.

Dat betekent dat een DORA-legal hold bewijsmateriaal over operationele weerbaarheid moet omvatten, niet alleen beveiligingsartefacten. Na een compromittering van cloudidentiteit die betalingsactiviteiten raakt, kan de hold identiteitsproviderlogboeken, geschiedenis van geprivilegieerde toegang, cloudauditlogboeken, SIEM-waarschuwingen, endpointimages, analyse van klanttransactie-impact, registraties van activering van bedrijfscontinuïteit, back-up- en herstelbewijsmateriaal, leverancierscommunicatie, briefings aan het bestuursorgaan, oorzaakanalyse en validatie van herstelmaatregelen omvatten.

DORA maakt ICT-bewijsmateriaal van derde partijen ook onvermijdelijk. Articles 28 tot en met 30 vereisen ICT-risicobeheer voor derde partijen, registers van contractuele regelingen, due diligence, beoordeling van concentratierisico en schriftelijke contracten met rechten en verplichtingen. Voor kritieke of belangrijke functies moeten contracten kennisgevings- en rapportageverplichtingen van de aanbieder, incidentondersteuning, samenwerking met autoriteiten, toegangs-, inspectie- en auditrechten en exitstrategieën ondersteunen.

Als uw cloudprovider, MSP, MSSP, betalingsverwerker of SaaS-afhankelijkheid de relevante logboeken beheert, moet uw legal-holdproces al in leverancierscontracten zijn ingebed. Anders kunt u tijdens een majeur incident ontdekken dat het standaardbewaarvenster van uw aanbieder korter is dan uw regelgevende rapportagelevenscyclus.

Hoe Clarysec legal hold operationaliseert tijdens een SaaS-inbreuk

Neem Maria’s fintech-SaaS-omgeving. Het incident kan ongeautoriseerde toegang omvatten tot klantidentificatoren, transactiemetadata, beheerderssystemen en uitbestede SOC-registraties. Het bedrijf bedient financiële instellingen in de EU, vertrouwt op cloudinfrastructuur en kan te maken krijgen met GDPR, contractuele DORA-verplichtingen en NIS2-plichten.

De eerste actie is niet alles bewaren. De eerste actie is een beheerst besluit activeren.

De incidentleider stuurt een legal-holdverzoek naar de juridisch adviseur, FG of privacyverantwoordelijke, CISO en bedrijfseigenaar. Het verzoek bevat incident-ID, datum en tijd, getroffen systemen, vermoedelijke gegevenscategorieën, initiële regelgevende routes, voorgestelde bewijscategorieën en directe verwijderingsrisico’s.

Met het Enterprise Beleid voor gegevensbewaring en vernietiging wordt de hold gedocumenteerd en goedgekeurd door de juridisch adviseur en de FG. Voor mkb-organisaties biedt het Beleid voor gegevensbewaring en veilige vernietiging de regel voor opschorting van verwijdering. De autorisatie bevat een beoordelingsdatum die is afgestemd op onderzoeksmijlpalen, regelgevende rapportagetermijnen en verwacht risico op gerechtelijke procedure of contractueel geschil. Er staat niet “voor altijd”. Er staat: “tot vrijgave door een geautoriseerd besluit na beoordeling”.

Vervolgens bevriest het team relevante logboeken en artefacten. Het mkb-Beleid voor logging en monitoring bepaalt:

“Logboeken moeten onder legal hold en opschorting van verwijdering worden geplaatst en worden beschermd tegen wijziging of verwijdering”

Het team schort verwijdering op voor SIEM-cases, identiteitslogboeken, cloudauditlogboeken, applicatielogboeken, databasequerylogboeken, WAF-events en metadata van SOC-waarschuwingen. Geëxporteerde logboeken worden opgeslagen in beperkte bewijsopslag met hashing, versiebeheer en alleen-lezenrechten waar passend.

De verzamelregel is eenvoudig: bewaar bewijsmateriaal zonder originelen te bewerken. Het mkb-Beleid inzake bewijsverzameling en forensisch onderzoek stelt:

“Er moet altijd een forensische kopie of export worden gemaakt; het oorspronkelijke bewijsmateriaal mag nooit rechtstreeks worden bewerkt.”

Engineers mogen herstelmaatregelen uitvoeren, maar pas nadat vereiste momentopnamen, exporten of forensische kopieën zijn gemaakt, tenzij onmiddellijke indamming noodzakelijk is om voortdurende schade te voorkomen. Als noodherstel eerst plaatsvindt, wordt de reden gedocumenteerd.

Hetzelfde mkb-beleid stelt:

“Voor elk incident moet een eenvoudig chain-of-custody-logboek (bijv. Excel-bestand of sjabloondocument) worden bijgehouden.”

Voor enterprise-omgevingen vereist het Beleid inzake bewijsverzameling en forensisch onderzoek, Clausule 5.6:

“Een chain-of-custody-logboek moet alle fysieke of digitale bewijsmateriaal begeleiden vanaf het moment van verwerving tot archivering of overdracht en moet documenteren:”

In de praktijk registreert het chain-of-custody-logboek bewijs-ID, beschrijving, bronsysteem, verzamelaar, verwervingsmethode, hashwaarde waar van toepassing, tijdsbron, opslaglocatie, toegangsgebeurtenissen, overdrachten, analysekopieën en uiteindelijke bestemming.

Tot slot moet ook het onderzoeksdossier zelf worden beschermd. Het Enterprise Beleid voor audit en compliancemonitoring bepaalt:

“Alle auditlogboeken, bevindingen en rapportages over herstelmaatregelen moeten worden bewaard, versleuteld en beschermd tegen manipulatie.”

Die eis geldt voor de incidenttijdlijn, het besluitvormingslogboek, de legal-holdkennisgeving, communicatie met toezichthouders, klantcommunicatie, oorzaakanalyse en bewijsmateriaal van herstelmaatregelen.

De gedocumenteerde informatie die auditors zullen inspecteren

ISO/IEC 27001:2022 Clausule 7.5 vereist dat gedocumenteerde informatie die nodig is voor het ISMS en door de norm wordt vereist, wordt beheerst. De Zenith Blueprint, fase ISMS Foundation and Leadership, stap 6, vertaalt dit naar praktische vereisten: documenten moeten identificatie, formaat, beoordeling, goedkeuring, versiebeheer, gecontroleerde toegang, integriteitsbescherming, wijzigingsbeheer, bewaring en bestemming hebben.

Stap 6 merkt ook op dat registraties zoals monitoringlogboeken, auditrapporten en incidentonderzoeksdossiers vertrouwelijk kunnen zijn en op need-to-know-basis moeten worden gedeeld, met bewerkingsrechten beperkt tot geautoriseerde gebruikers.

Een verdedigbaar bewijspakket moet omvatten:

• Legal-holdkennisgeving en goedkeuring.
• Incidentclassificatie en ernstbesluit.
• Bewijsinventaris.
• Chain-of-custody-logboek.
• Bevestiging van bewaring van logboeken.
• Registraties van forensische images of exporten.
• Hashwaarden of integriteitscontroles waar van toepassing.
• Toegangslijst voor bewijsopslag.
• Bewijsmateriaal voor regelgevende rapportage.
• Privacybeoordeling en impactanalyse voor persoonsgegevens.
• Verzoeken om leveranciersbewijsmateriaal en antwoorden.
• Oorzaakanalyse.
• Bewijsmateriaal van herstelmaatregelen en validatie.
• Beoordeling van de hold en besluit tot vrijgave.

Hoe sterker de beheersing van gedocumenteerde informatie, hoe eenvoudiger de audit.

Leveranciers- en cloudbewijsmateriaal: het faalpunt dat veel teams missen

Het lastigste bewijsmateriaal bevindt zich vaak niet binnen uw organisatie. Het wordt beheerd door een cloudprovider, SaaS-platform, MSSP, MSP, betalingsverwerker, identiteitsprovider of uitbesteed ontwikkelteam.

NIS2 Article 21 omvat beveiliging van de toeleveringsketen en beveiligingsaspecten van relaties met directe leveranciers of dienstverleners. DORA gaat verder voor financiële entiteiten en vereist ICT-registers van derde partijen, due diligence, analyse van concentratierisico en contracten met incidentondersteuning, leveranciersrapportage, samenwerking met autoriteiten, auditrechten en exitbepalingen voor kritieke of belangrijke functies.

NIST Cybersecurity Framework 2.0 behandelt risico in de toeleveringsketen ook als een levenscyclusdiscipline. De Govern Function omvat uitkomsten voor leveranciersrisicobeheer rond strategie, rollen, contracten, due diligence, monitoring, incidentdeelname en exitbepalingen. CSF Profiles kunnen doelvereisten voor cybersecurity richting leveranciers formuleren, wat nuttig is bij het vertalen van legal-holdbehoeften aan bewijsmateriaal naar contractuele voorwaarden.

Leverancierscontracten moeten ingaan op:

• Typen beveiligingslogboeken die voor de klant beschikbaar zijn.
• Standaardbewaartermijnen en opties voor verlengde bewaring.
• Proces voor noodverzoeken tot bewaring.
• Tijd tot bewaring van bewijsmateriaal na klantverzoek.
• Forensische exportformaten.
• Ondersteuning voor chain-of-custody.
• Samenwerking met toezichthouders.
• Bewijsverplichtingen van subverwerkers of onderaannemers.
• Beperkingen rond gegevenslocatie en overdracht.
• Veilige verwijdering na vrijgave van de hold.

De Zenith Blueprint, fase Controls in Action, stap 18, geeft vergelijkbare discipline voor overdracht van fysieke media en vereist encryptie, manipulatie-indicerende verpakking, tracking, transportlogboeken, mediainventaris en audit van het register. Dezelfde logica geldt voor overdracht van cloudbewijsmateriaal: behoud integriteit, volg de bewaring, beperk toegang en bevestig ontvangst.

Hoe auditors en toezichthouders uw legal-holdproces toetsen

Een legal-holdproces ziet er anders uit afhankelijk van het mandaat van de beoordelaar. Clarysec gebruikt Zenith Controls als cross-compliancekompas, zodat hetzelfde bewijspakket meerdere perspectieven kan bedienen zonder dubbel werk.

De ISO-auditor let op conformiteit en objectief bewijsmateriaal. De GDPR-beoordelaar let op noodzakelijkheid, doelbinding en aantoonbare verantwoordingsplicht. De NIS2-beoordelaar let op feiten voor significante incidentrapportage en managementverantwoordelijkheid. De DORA-beoordelaar let op ICT-risicogovernance, afhandeling van majeure incidenten, afhankelijkheden van derde partijen en geleerde lessen. De COBIT 2019- of ISACA-achtige auditor let op governance, ontwerp van beheersmaatregelen, werking van beheersmaatregelen en assurance over informatiekwaliteit.

Eén bewijspakket kan al deze partijen bedienen, als het zo is ontworpen.

Een praktische checklist voor legal hold bij cyberincidenten in 2026

Gebruik deze checklist vóór het volgende ernstige incident, niet tijdens het incident.

Deze checklist wordt krachtiger wanneer deze wordt ingebed in het ISMS-risicobehandelingsplan, leveranciersbeveiligingsvereisten, incidentresponsrunbooks, loggingarchitectuur en privacygovernance.

Van paniek na een inbreuk naar auditbestendige weerbaarheid

Het telefoontje om 04:00 blijft altijd stressvol. Het hoeft geen chaos te worden.

Een volwassen legal-holdproces voor cyberincidenten geeft iedere stakeholder een beheerst pad. Juridische zaken krijgt verdedigbare bewaring. Privacy krijgt minimalisatie en beoordeling. De CISO krijgt integriteit van bewijsmateriaal. De FG krijgt verantwoordingsplicht. Het bestuur krijgt betrouwbare feiten. NIS2-, DORA- en GDPR-beoordelaars krijgen objectief bewijsmateriaal in plaats van geïmproviseerde uitleg.

Clarysec’s 30-stappenmethodologie behandelt legal hold niet als een op zichzelf staand juridisch memo. Zij behandelt het als een operationele ISMS-capability.

In Zenith Blueprint bouwt stap 6 de bibliotheek met gedocumenteerde informatie, inclusief regels voor bewaring en bestemming. Stap 19 versterkt logging en kloksynchronisatie zodat onderzoeken tijdlijnen kunnen reconstrueren. Stap 23 operationaliseert bewijsverzameling en chain-of-custody. Stap 18 voegt discipline toe voor mediabehandeling wanneer bewijsmateriaal fysiek of tussen partijen wordt verplaatst.

In Zenith Controls verbindt Clarysec de onderliggende ISO/IEC 27002:2022-beheersmaatregelen, zodat klanten zien hoe bewijsverzameling afhankelijk is van logging, monitoring, incidentrespons, bescherming van registraties, toegangscontrole, back-ups, privacy en wettelijke eisen.

In de beleidsbibliotheek van Clarysec zijn de praktische workflowankers al gedefinieerd: Beleid voor gegevensbewaring en vernietiging, Beleid voor gegevensbewaring en veilige vernietiging voor het mkb, Beleid inzake bewijsverzameling en forensisch onderzoek, Beleid inzake bewijsverzameling en forensisch onderzoek voor het mkb, Beleid voor logging en monitoring voor het mkb, Beleid inzake gegevensbescherming en privacy voor het mkb en Beleid voor audit en compliancemonitoring.

Als uw incidentresponsplan zegt “bewijsmateriaal bewaren”, maar geen legal-holdbevoegdheid, bewijsreikwijdte, opschorting van bewaartermijnen, chain-of-custody, bewaring door leveranciers, GDPR-minimalisatie en vrijgavecriteria definieert, is het nog niet auditgereed.

Bouw het proces vóór de inbreuk. Clarysec kan u helpen een verdedigbare capability voor legal hold bij cyberincidenten en bewaring van bewijsmateriaal te creëren met Zenith Blueprint: een 30-stappenroadmap voor auditors, Zenith Controls: de cross-compliancegids en Clarysec-beleidssjablonen, waaronder het Beleid voor gegevensbewaring en vernietiging, Beleid inzake bewijsverzameling en forensisch onderzoek, Beleid voor audit en compliancemonitoring, Beleid voor logging en monitoring voor het mkb, Beleid inzake gegevensbescherming en privacy voor het mkb en Beleid inzake bewijsverzameling en forensisch onderzoek voor het mkb.

Download de toolkits, vraag een Clarysec-beleidsbeoordeling aan of boek een gereedheidsbeoordeling voor bewaring van bewijsmateriaal vóór uw volgende audit, toezichtsverzoek of majeure beveiligingsbeoordeling door een klant.