Threat intelligence delen met ISO 27001 in 2026

Om 07:40 op een dinsdagochtend ontvangt Maria, de CISO van een snelgroeiend Europees betaalplatform, een bulletin met hoge betrouwbaarheid van een ISAC voor financiële diensten. Een campagne voor diefstal van inloggegevens richt zich op betalingsdienstverleners die een specifieke integratie met een identiteitsprovider gebruiken. Het beveiligingsadvies bevat command-and-control-domeinen, verdachte OAuth-applicatienamen, user-agent-strings, waargenomen tactieken en een aanbeveling om secrets voor getroffen tenants te roteren.

Binnen enkele minuten stelt de organisatie de vragen die het delen van cyberdreigingsinformatie in 2026 bepalen.

Het SOC wil de indicatoren direct in de SIEM laden. Juridische Zaken vraagt of het bedrijf eigen telemetrie mag terugdelen met de ISAC. De FG vraagt of IP-adressen, gebruikersnamen, ticketfragmenten, authenticatielogboeken of endpointdetails persoonsgegevens bevatten. De COO wil weten of klanten moeten worden gewaarschuwd. De CEO, net terug van een NIS2-managementtraining, stuurt de waarschuwing door met twee woorden: “Ons plan?”

Vervolgens stelt de compliancemanager de belangrijkste vraag: “Als de toezichthouder volgende maand vragen stelt, kunnen we dan aantonen dat ons delen van cyberdreigingsinformatie rechtmatig, goedgekeurd, nuttig en beheerst was?”

Dat is de nieuwe realiteit. DORA is verschoven van implementatiedeadline naar toezicht in de praktijk. NIS2 is verschoven van gereedheidsprojecten naar operationele samenwerking. GDPR blijft van toepassing, ook wanneer de gegevens beveiligingstelemetrie zijn. Het delen van threat intelligence is niet langer een informele Slack-uitwisseling tussen beveiligingsteams. Het is een beheerste activiteit waarbij vertrouwelijkheid, gegevensminimalisatie voor persoonsgegevens, goedkeuringen voor openbaarmaking, registraties, verwachtingen van toezichthouders en auditbewijs samenkomen.

Voor CISO’s, compliancemanagers, auditors en bedrijfseigenaren is de vraag niet óf zij moeten deelnemen aan regelingen voor het delen van cyberdreigingsinformatie. De echte vraag is hoe zij snel genoeg kunnen delen om verdedigers te helpen, terwijl zij onrechtmatige openbaarmaking, schendingen van klantvertrouwelijkheid, lekkage van concurrentiegevoelige informatie, onbeheerde publicatie van kwetsbaarheden en zwak bewijs voorkomen.

ISO/IEC 27001:2022 vormt de governance-ruggengraat die dit mogelijk maakt. Niet als certificaat aan de muur, maar als managementsysteem dat het delen van cyberdreigingsinformatie omzet in een herhaalbaar, verdedigbaar en GDPR-veilig operationeel model.

Waarom het delen van cyberdreigingsinformatie in 2026 is veranderd

De eerste golf van DORA- en NIS2-voorbereiding richtte zich op toepassingsgebied, termijnen voor incidentmelding, ICT-risico’s van derden, bestuursverantwoordelijkheid en gapassessments. Dat werk was noodzakelijk, maar toezichthouders en klanten stellen nu meer operationele vragen:

• Aan welke ISAC’s, CERT’s, CSIRT’s, leveranciersfora of vertrouwde communities neemt u deel?
• Wie is bevoegd om de organisatie extern te vertegenwoordigen?
• Hoe bepaalt u wat mag worden gedeeld?
• Hoe voorkomt u dat persoonsgegevens, klantsecrets, kwetsbaarheidsdetails en gevoelige architectuur openbaar worden gemaakt?
• Hoe werkt input uit threat intelligence door in monitoringregels, patchprioriteiten, risicoregisters, incidentdraaiboeken, leveranciersbeoordelingen en weerbaarheidstests?
• Waar is het bewijs?

DORA is vooral direct relevant voor financiële entiteiten. Het behandelt digitale operationele weerbaarheid als een door het bestuur gedragen ICT-risicobeheersysteem, niet als een IT-checklist. DORA is van toepassing vanaf 17 januari 2025; in 2026 worden veel financiële entiteiten daarom beoordeeld op de vraag of hun processen in de praktijk werken.

DORA Article 45 staat het delen van informatie over cyberdreigingen en threat intelligence tussen financiële entiteiten toe wanneer het doel is de digitale operationele weerbaarheid te versterken. Het delen moet plaatsvinden binnen vertrouwde communities en onder afspraken die gevoelige bedrijfsinformatie, persoonsgegevens, vertrouwelijkheid, intellectuele eigendom en mededingingsrechtelijke grenzen beschermen. In gewone taal betekent DORA niet: “deel alles”. Het betekent: “deel veilig, doelgericht en onder beheerste voorwaarden”.

NIS2 creëert vergelijkbare druk buiten de financiële sector. De richtlijn is van toepassing op veel essentiële en belangrijke entiteiten in zeer kritieke en andere kritieke sectoren, waaronder digitale infrastructuur, managed service providers, managed security service providers, cloudcomputingdiensten, datacenterproviders, online marktplaatsen, zoekmachines, socialenetwerkplatforms, banken en financiëlemarktinfrastructuren. NIS2 Article 20 maakt managementorganen verantwoordelijk voor het goedkeuren van maatregelen voor cyberbeveiligingsrisicobeheer, het toezien op de implementatie en het volgen van training. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, kwetsbaarhedenbeheer, beoordeling van doeltreffendheid, cyberhygiëne, training, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen, MFA en beveiligde communicatie. Article 23 vereist gefaseerde melding van significante incidenten, inclusief een vroegtijdige waarschuwing binnen 24 uur, een incidentmelding binnen 72 uur en een eindrapport uiterlijk één maand na de incidentmelding.

GDPR voegt de privacygrens toe. Persoonsgegevens omvatten alle informatie over een geïdentificeerde of identificeerbare natuurlijke persoon. Beveiligingslogboeken, IP-adressen, gebruikersnamen, e-mailadressen, endpointnamen, authenticatiegebeurtenissen, supporttickets, malwaresamples, schermafbeeldingen en notities uit fraudeonderzoek kunnen allemaal persoonsgegevens zijn. GDPR vereist rechtmatige, behoorlijke, transparante, doelgebonden, geminimaliseerde, accurate, opslagbeperkte en beveiligde verwerking. Ook geldt verantwoordingsplicht: de organisatie moet naleving kunnen aantonen.

Het resultaat is een governancevraagstuk. Het delen van threat intelligence moet snel genoeg zijn om de verdediging te verbeteren, voldoende beheerst zijn om toezichthouders tevreden te stellen en gedisciplineerd genoeg zijn om privacy- en vertrouwelijkheidsinbreuken te voorkomen.

ISO 27001 als compliancehub voor het delen van threat intelligence

ISO/IEC 27001:2022 is zeer geschikt voor deze uitdaging, omdat de norm begint bij context, belanghebbenden, toepassingsgebied, risico, leiderschap, operationele beheersing, monitoring, interne audit, directiebeoordeling en continue verbetering.

Clausules 4.1 tot en met 4.4 vereisen dat organisaties interne en externe kwesties begrijpen, belanghebbenden en hun eisen identificeren, het ISMS-toepassingsgebied definiëren en het managementsysteem onderhouden. Voor een DORA- of NIS2-organisatie kunnen belanghebbenden onder meer bevoegde autoriteiten, CSIRT’s, klanten, ICT-providers, ISAC’s, sectororganisaties, verwerkers, verwerkingsverantwoordelijken, verzekeraars, interne audit en het bestuur zijn.

Clausules 5.1 tot en met 5.3 vereisen betrokkenheid van het leiderschap, beleidsrichting, verantwoordingsplicht, middelen en toegewezen verantwoordelijkheden. Dit is belangrijk omdat het delen van threat intelligence faalt wanneer het wordt overgelaten aan informele technische discretie. Als de SOC-analist, juridisch adviseur, FG, CISO, PR-verantwoordelijke en bedrijfseigenaar verschillende aannames hanteren, zal de organisatie te veel delen, blokkeren of te laat reageren.

Clausules 6.1.1 tot en met 6.1.3 zetten het regelgevingsvraagstuk om in risicobeoordeling, risicobehandeling, selectie van beheersmaatregelen, besluiten over de Verklaring van Toepasselijkheid, behandelplannen en acceptatie van restrisico. Typische risico’s bij het delen van threat intelligence zijn onder meer:

• Persoonsgegevens die worden gedeeld zonder rechtsgrondslag of minimalisatie.
• Vertrouwelijke klantinformatie die aan een forum wordt bekendgemaakt.
• Kwetsbaarheidsdetails die worden gepubliceerd voordat mitigatie beschikbaar is.
• Indicatoren die worden geconsumeerd maar nooit operationeel worden gemaakt.
• ISAC-deelname die niet is verwerkt in incidentrespons, logging, kwetsbaarhedenbeheer of leveranciersrisico.
• Gebrek aan bewijs waaruit blijkt wie openbaarmaking heeft goedgekeurd en waarom.
• Mededingingsrechtelijk risico door het delen van commercieel gevoelige marktinformatie.
• Inconsistente communicatie met toezichthouders en klanten tijdens een significant incident.

Clausule 8.1 vereist vervolgens dat geplande processen worden geïmplementeerd en beheerst, met voldoende gedocumenteerde informatie om aan te tonen dat processen zijn uitgevoerd zoals gepland. Clausules 9 en 10 vereisen monitoring, meting, interne audit, directiebeoordeling, behandeling van afwijkingen, corrigerende maatregelen en continue verbetering. Kort gezegd maakt ISO/IEC 27001:2022 van het delen van cyberdreigingsinformatie een auditeerbaar operationeel model.

De twee ISO-beheersmaatregelen die delen laten werken

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandelt dit onderwerp als onderdeel van de fase Controls in Action, Stap 22: organisatorische beheersmaatregelen. Twee beheersmaatregelen uit ISO/IEC 27002:2022 staan centraal: 5.6, Contact met speciale belangengroepen, en 5.7, Threat Intelligence.

De Zenith Blueprint maakt duidelijk dat ISAC-deelname geen symbolisch netwerken is:

Deelname aan dergelijke groepen is geen symbolisch gebaar. Het is een strategische investering in intelligence, samenwerking en gedeelde weerbaarheid.

Voor beheersmaatregel 5.6 kunnen speciale belangengroepen bestaan uit nationale of sectorspecifieke netwerken voor cyberdreigingsinformatie, ISAC’s, regelgevende fora, leveranciersgroepen voor beveiligingsadviezen, opensourcegemeenschappen en academische werkgroepen. Extern delen moet echter doelbewust, rechtmatig en vrijgegeven zijn. De Zenith Blueprint voegt de volwassenheidsverwachting toe:

Volwassen ISMS-implementaties behandelen SIG-deelname als een beheerste activiteit, niet als een informeel voordeel.

Dat betekent dat een register wordt bijgehouden van groepen en fora waaraan wordt deelgenomen, officiële deelnemers worden aangewezen, notulen of samenvattingen worden vastgelegd en inzichten worden geïntegreerd in interne beoordelingen of actualisaties van beheersmaatregelen.

Beheersmaatregel 5.7 zet externe informatie om in actie. De Zenith Blueprint stelt:

Een organisatie kan zich niet verdedigen tegen wat zij niet begrijpt.

De gids waarschuwt ook voor het verwarren van patchfeeds met threat intelligence. Echte intelligence omvat profilering van dreigingsactoren, tactieken, technieken en procedures, indicatoren van compromittering, sectorspecifieke waarschuwingen, kwetsbaarheidscontext en strategische bedrijfsimpact. Bruikbare intelligence combineert interne monitoring, externe samenwerkingsverbanden, CERT- of ISAC-relaties, commerciële feeds en opensourcebronnen, maar alleen wanneer iemand deze beoordeelt, prioriteert en vertaalt naar actie.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls versterkt de waarde voor naleving over meerdere kaders heen. De gids positioneert beheersmaatregel 5.6 als preventief en corrigerend, ter ondersteuning van vertrouwelijkheid, integriteit en beschikbaarheid, met governance als primaire operationele capability. De gids koppelt 5.6 aan 5.7 Threat Intelligence, 5.5 Contact met autoriteiten, 5.31 Wettelijke, statutaire, regelgevende en contractuele eisen, en 8.8 Beheer van technische kwetsbaarheden. Beheersmaatregel 5.7 wordt gepositioneerd als preventief, detectief en corrigerend, gekoppeld aan Identify, Detect en Respond, met operationele capability op het gebied van dreigings- en kwetsbaarhedenbeheer.

De boodschap is eenvoudig: een volwassen programma voor het delen van cyberdreigingsinformatie heeft twee helften. Ten eerste: beheerste relaties. Ten tweede: beheerst gebruik van wat wordt ontvangen en gedeeld.

Een praktisch operationeel model voor beheerst delen

Een verdedigbaar operationeel model voor 2026 moet zes vragen beantwoorden voordat de eerste indicator wordt gedeeld.

Clarysec implementeert dit doorgaans als een lichte maar formele workflow:

1. Neem de intelligence in en classificeer deze.
2. Valideer de relevantie voor bedrijfsmiddelen, leveranciers, diensten, geografische gebieden en klanten.
3. Zet intelligence om in actie, zoals monitoringregels, kwetsbaarheidstickets, gebruikerswaarschuwingen, leveranciersvragen of risico-updates.
4. Beslis of uitgaand delen noodzakelijk, rechtmatig, veilig en toegestaan is volgens de lidmaatschapsregels.
5. Pas redactie, aggregatie, pseudonimisering of anonimisering toe.
6. Verkrijg de vereiste goedkeuringen.
7. Deel via een goedgekeurd kanaal.
8. Registreer wat is gedeeld, met wie, waarom, wanneer en onder wiens bevoegdheid.
9. Beoordeel de resultaten en actualiseer beheersmaatregelen.

Dit voorkomt de twee klassieke fouten: het beveiligingsteam ontvangt bruikbare intelligence maar er verandert niets, of het beveiligingsteam deelt bruikbare intelligence maar creëert juridische, contractuele of privacyblootstelling.

DORA Article 45: beheerst delen zonder vertrouwelijkheid te verliezen

Voor financiële entiteiten moet DORA Article 45 worden vertaald naar een interne standaard voor het delen van cyberdreigingsinformatie. Een praktische interpretatie omvat vijf voorwaarden.

Ten eerste moet het doel weerbaarheid zijn. Delen moet helpen bij het voorkomen, detecteren, reageren op of herstellen van cyberdreigingen. Het mag niet afglijden naar prijsinformatie, klantenlijsten, marktstrategie of commercieel gevoelige intelligence.

Ten tweede moet de community vertrouwd zijn. Dit betekent duidelijke lidmaatschapsregels, vertrouwelijkheidsverplichtingen, beveiligde kanalen, toegangscontrole en beperkingen op verdere openbaarmaking. ISO/IEC 27010:2015 ondersteunt veilige informatie-uitwisseling binnen vertrouwensgemeenschappen, inclusief vertrouwelijkheidsregels, wederkerigheid en vertrouwde communicatiekanalen. ISO/IEC 27032:2023 ondersteunt het delen van cyberbeveiligingsinformatie en situationeel bewustzijn. ISO/IEC 27035-2:2023 koppelt informatie-uitwisseling aan incidentresponsplanning, inclusief deelname aan CERT’s en branchegroepen.

Ten derde moet gevoelige informatie worden beschermd. Dit omvat bedrijfsgeheimen, architectuurdiagrammen, kwetsbaarheidsdetails, inloggegevens, klantidentificatoren en persoonsgegevens. Clarysec’s mkb Data Classification and Labeling Policy Data Classification and Labeling Policy - SME stelt:

Extern delen moet expliciet worden geautoriseerd en gelogd.

Die zin is het beheersprincipe achter een workflow voor DORA Article 45. De organisatie moet weten welke classificatie van toepassing is, wie vrijgave heeft goedgekeurd en waar de registratie wordt bewaard.

Ten vierde moeten persoonsgegevens worden geminimaliseerd. Het enterprise Data Protection and Privacy Policy Data Protection and Privacy Policy stelt:

Alleen gegevens die noodzakelijk zijn voor een specifiek, legitiem bedrijfsdoel mogen worden verzameld en verwerkt.

Het mkb-equivalent, Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME, stelt:

Alleen de minimaal noodzakelijke persoonsgegevens mogen worden verzameld en bewaard

Dit is belangrijk omdat threat-intelligenceteams vaak worden verleid om ruwe logboeken naar externe kanalen te kopiëren. In plaats daarvan moeten zij alleen delen wat de ontvanger nodig heeft, zoals een malafide domein, een hash, een tijdstempelbereik, een algemeen patroon of een gepseudonimiseerde zaakreferentie.

Ten vijfde moet de organisatie bewijs bewaren. DORA is opgebouwd rond gedocumenteerd ICT-risicobeheer, incidentclassificatie, rapportage, testen, governance voor derde partijen en managementverantwoordelijkheid. Als delen invloed heeft op incidentrespons, een scenario voor weerbaarheidstests of een leveranciersrisicobesluit, moet dat zichtbaar zijn in de ISMS-registraties.

NIS2-samenwerking: van juridisch toepassingsgebied naar operationele relaties

NIS2 verbreedt het gesprek buiten financiële entiteiten. De richtlijn is van toepassing op basis van sector, omvang en kritikaliteit, en kan ook ongeacht de omvang gelden voor bepaalde entiteiten, zoals verleners van vertrouwensdiensten, DNS-dienstverleners, TLD-registers, kritieke entiteiten en diensten voor domeinnaamregistratie.

Voor het delen van threat intelligence is governance de kernles. Article 20 maakt managementorganen verantwoordelijk voor het goedkeuren van en toezien op maatregelen voor cyberbeveiligingsrisicobeheer. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen. Article 23 vereist gefaseerde rapportage van significante incidenten.

Het delen van threat intelligence raakt al deze punten. Als een ISAC-beveiligingsadvies aangeeft dat een beheerde dienst van een leverancier wordt misbruikt, worden de verwachtingen voor de toeleveringsketen onder Article 21 relevant. Als intelligence wijst op een lopend significant incident, kunnen workflows voor Article 23-rapportage en klantcommunicatie worden geactiveerd. Als een significante cyberdreiging gevolgen kan hebben voor afnemers van diensten, heeft de organisatie een beheerst waarschuwingsproces nodig.

De Zenith Blueprint behandelt dit in de fase ISMS Foundation and Leadership, Stap 5, Communication, Awareness, and Competence. De gids adviseert planning voor externe communicatie waarbij klanten, toezichthouders, partners en het publiek worden geïdentificeerd, waarna wordt vastgelegd wat wordt gecommuniceerd, wanneer, door wie en met welke goedkeuring. De gids geeft het praktische voorbeeld van een incidentcommunicatieprocedure waarin de CISO een kennisgeving opstelt, Juridische Zaken deze beoordeelt en de CEO deze vóór verzending goedkeurt.

Het mkb Incident Response Policy Incident Response Policy - SME stelt:

De algemeen directeur (GM) is verantwoordelijk voor het autoriseren van alle besluiten over incidentescalatie, meldingen aan toezichthouders en externe communicatie.

Voor grotere organisaties legt het enterprise Incident Response Policy Incident Response Policy de basis voor bewijs vast:

Alle incidenten moeten worden geregistreerd in het Security Incident Management System (SIMS), inclusief:

Wanneer threat intelligence een incident, klantwaarschuwing, melding aan een toezichthouder of extern advies wordt, mag deze niet alleen in inboxen en chatgesprekken blijven staan. De informatie hoort thuis in het incidentbeheersysteem, met classificatie, acties, goedkeuringen, bewijs en geleerde lessen.

GDPR-veilige openbaarmaking: intelligence delen, geen onnodige persoonsgegevens

GDPR staat beveiligingsoperaties toe, maar creëert geen vrijzone voor ongecontroleerd delen van telemetrie. Veel threat-intelligence-artefacten kunnen persoonsgegevens bevatten:

• IP-adressen die verband houden met gebruikersactiviteit.
• E-mailadressen die bij phishingpogingen zijn gebruikt.
• Gebruikersnamen, apparaatnamen, endpoint-ID’s of tenant-ID’s van klanten.
• Authenticatielogboeken.
• Supporttickets.
• Schermafbeeldingen.
• Notities uit fraudeonderzoek.
• Malwaresamples die documenten of persoonlijke bestanden bevatten.
• Kwetsbaarheidsrapporten die blootstelling van klantgegevens bevatten.

In het model van Clarysec gaat elke beslissing over uitgaand delen door een privacy- en vertrouwelijkheidsfilter.

In Zenith Controls is ISO/IEC 27002:2022-beheersmaatregel 5.34, Privacy en bescherming van PII, gemapt als preventief en verbonden met classificatie, inventaris van bedrijfsmiddelen, datamasking, cloudbeveiliging, informatieoverdracht, toegangscontrole, identiteitsbeheer en project- of wijzigingsbeoordeling. De maatregel is ook gemapt op GDPR Articles 25 en 32 via privacy by design, beveiliging van de verwerking, encryptie, pseudonimisering, toegangscontrole en aantoonbare governance. Ondersteunende normen zijn ISO/IEC 27701:2021 voor privacy-informatiemanagement, ISO/IEC 27018:2019 voor bescherming van PII in omgevingen van externe verwerkers in de publieke cloud, en ISO/IEC 29100:2011 voor privacyprincipes.

Voor het delen van threat intelligence moeten de FG en het beveiligingsteam elkaar niet pas tijdens een crisis voor het eerst spreken. Zij moeten patronen, sjablonen, redactieregels en escalatiedrempels vooraf goedkeuren.

Praktijkvoorbeeld: een ISAC-waarschuwing wordt evidence-based weerbaarheid

Terug naar Maria’s betaalplatform. Het ISAC-beveiligingsadvies bevat malafide domeinen, verdachte OAuth-applicatienamen, user-agent-strings en een melding dat verschillende leden pogingen tot accountovername tegen gebruikers in finance operations hebben waargenomen. Het bedrijf vindt ook drie verdachte aanmeldpogingen in de eigen logboeken.

Zo zou Clarysec de respons operationaliseren met ISO/IEC 27001:2022, Zenith Blueprint, Zenith Controls en de policytoolkit.

Het uitgaande bericht bevat oorspronkelijk tijdstempels, bron-IP-adressen, doelgebruikersnamen, tenant-ID’s van klanten en schermafbeeldingen. Na beoordeling door de FG en Juridische Zaken wordt het teruggebracht tot:

• Tijdvenster in UTC.
• Aanvalspatroon.
• Waargenomen malafide domein.
• Algemeen getroffen roltype, zoals gebruikers in finance operations.
• Geen gebruikersnamen.
• Geen tenant-ID’s van klanten.
• Geen schermafbeeldingen.
• Geen klantnamen.
• Geen ruwe logboeken, tenzij daarom wordt gevraagd via een beheerst kanaal.

Als de activiteit een incident wordt, nemen de beheersmaatregelen van het Incident Response Policy het over. Als forensische artefacten worden verzameld, is het Evidence Collection and Forensics Policy-sme Evidence Collection and Forensics Policy - SME van toepassing:

Elk digitaal bewijsmiddel moet worden gelogd met:

Het beleid gaat intern verder met vereisten voor metadata van bewijsmateriaal, maar het auditprincipe is duidelijk: elk artefact dat wordt gebruikt voor onderzoek, delen, rapportage aan toezichthouders of klantcommunicatie heeft traceerbaarheid nodig.

Openbaarmaking van kwetsbaarheden is niet hetzelfde als het delen van threat intelligence

Een veelgemaakte fout is het behandelen van openbaarmaking van kwetsbaarheden, incidentmelding en het delen van threat intelligence als hetzelfde proces. Ze overlappen, maar zijn niet identiek.

Het delen van threat intelligence kan betrekking hebben op indicatoren, tactieken, sectorwaarschuwingen, gedrag van tegenstanders, mitigaties of waargenomen pogingen. Gecoördineerde openbaarmaking van kwetsbaarheden heeft betrekking op een specifieke zwakte in een product of dienst, vaak met een melder, hersteltermijn, beveiligingsadvies en besluit over publieke openbaarmaking. Incidentmelding betreft regelgevende of contractuele rapportage over een gebeurtenis die diensten, gegevens of klanten raakt.

Clarysec scheidt deze workflows, terwijl ze via het ISMS verbonden blijven. Het enterprise Coordinated Vulnerability Disclosure Policy Coordinated Vulnerability Disclosure Policy stelt:

Coördinatie en openbaarmaking: De organisatie moet publieke openbaarmaking coördineren met de melder. Standaard mogen geen kwetsbaarheidsdetails openbaar worden gemaakt totdat een oplossing of mitigatie beschikbaar is of ten minste in uitvoering is. Voor kritieke kwesties waarbij een oplossing niet snel kan worden geleverd, kan de organisatie een beveiligingsadvies met workaround-richtlijnen uitbrengen om gebruikers te waarschuwen, in overleg met relevante autoriteiten waar vereist. Van de melder wordt verwacht dat deze afziet van publieke openbaarmaking totdat de organisatie vrijgave verleent of een advies publiceert. Als algemene regel streeft de organisatie ernaar om binnen 90 dagen na ontvangst van de melding een advies te publiceren, of binnen een andere onderling overeengekomen termijn, in lijn met branchepraktijken, inclusief vermelding van de melder wanneer daarvoor toestemming is gegeven.

Hetzelfde beleid stelt ook:

Vertrouwelijkheid: Tot publieke openbaarmaking moet alle informatie over een gemelde kwetsbaarheid als Hoog vertrouwelijk worden behandeld. Details mogen intern alleen op need-to-know-basis worden gedeeld met personeel dat nodig is om de kwestie te valideren of te herstellen. De identiteit van de melder moet vertrouwelijk blijven wanneer daarom wordt verzocht. Alle communicatie met de melder moet worden versleuteld, onder meer door gebruik van de PGP-sleutel van de organisatie, om gevoelige kwetsbaarheidsdetails te beschermen.

Dit is cruciaal voor DORA Article 45 en NIS2-samenwerking. Een vertrouwde community kan de juiste plaats zijn om mitigaties of indicatoren op hoog niveau te delen, maar niet noodzakelijk exploitdetails, klantspecifieke gegevens of informatie over niet-gepatchte kwetsbaarheden.

Externe communicatie vereist dezelfde discipline. Het enterprise Social Media and External Communications Policy Social Media and External Communications Policy wijst beoordelingsverantwoordelijkheid voor content toe om naleving te waarborgen van wetten inzake vertrouwelijkheid, openbaarmaking door insiders, intellectuele eigendom en smaad. Dat is relevant wanneer een technisch beveiligingsadvies verandert in een publieke verklaring, klantkennisgeving, website-update of bericht aan een toezichthouder.

Mapping voor naleving over meerdere kaders: één workflow, veel verplichtingen

Een sterke workflow voor het delen van cyberdreigingsinformatie moet aan meerdere raamwerken voldoen zonder dubbele processen te creëren.

NIST CSF 2.0 is nuttig als neutrale ordeningslaag, omdat de GOVERN-functie belanghebbenden, wettelijke verplichtingen, afhankelijkheden, risicobereidheid, rollen, beleid en toezicht adresseert. De DETECT- en RESPOND-functies verwachten monitoring, integratie van threat intelligence, incidentverklaring, behoud van bewijs, melding en externe communicatie.

COBIT 2019 voegt managementverantwoordelijkheid toe. Praktijken zoals DSS05.04 Manage security threats, APO12 Manage risk, MEA03 Managed compliance with external requirements en APO13 Managed security helpen auditors te toetsen of intelligence de prestatie van beheersmaatregelen en governancerapportage verbetert.

Hoe auditors uw programma voor delen zullen toetsen

Een ISO/IEC 27001:2022-auditor begint bij het managementsysteem. De auditor vraagt hoe wettelijke, regelgevende, contractuele en belanghebbendenvereisten onder clausules 4.1 en 4.2 zijn geïdentificeerd. De auditor controleert of het delen van threat intelligence binnen het toepassingsgebied valt, of risico’s zijn beoordeeld, of beheersmaatregelen 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15 en 8.16 zijn opgenomen of gemotiveerd in de Verklaring van Toepasselijkheid, en of bewijs aantoont dat het proces volgens plan heeft gewerkt.

Een DORA-gerichte auditor of toezichthouder kijkt naar governance, bestuursverantwoordelijkheid, integratie in ICT-risicobeheer, incidentclassificatie, weerbaarheidstests, gevolgen voor derde partijen en voorwaarden van Article 45. De auditor vraagt of deelname aan regelingen voor informatie-uitwisseling is gedocumenteerd, of gevoelige gegevens en persoonsgegevens worden beschermd, of intelligence het ICT-risicobeheerkader actualiseert en of zij testscenario’s beïnvloedt.

Een NIS2-gerichte beoordelaar richt zich op toezicht door het bestuur, maatregelen onder Article 21, incidentafhandeling, leveranciersafhankelijkheden, kwetsbaarhedenbeheer, communicatie met klanten of afnemers van diensten, en samenwerking met CSIRT’s of bevoegde autoriteiten. De beoordelaar toetst of threat intelligence is verbonden met beoordeling van significante incidenten en gefaseerde rapportage.

Een privacyauditor richt zich op de beginselen van GDPR. De auditor vraagt of gedeelde gegevens persoonsgegevens waren, welke rechtsgrondslag van toepassing was, of minimalisatie is uitgevoerd, of pseudonimisering of redactie mogelijk was, of bewaring werd beheerst en of de organisatie verantwoordingsplicht kan aantonen.

Goed bewijs omvat:

• Goedgekeurd ISAC- of SIG-register.
• Deelnemers en plaatsvervangers op naam.
• Lidmaatschapsvoorwaarden en vertrouwelijkheidsverplichtingen.
• Intakelogboek voor threat intelligence.
• Triage- en relevantiebeoordelingen.
• Tickets voor detectie-engineering.
• Wijzigingen in prioritering van kwetsbaarheden.
• Escalaties van leveranciersrisico.
• Registraties van goedkeuringen voor openbaarmaking.
• FG- of privacynotities.
• Geredigeerde uitgaande berichten.
• Incidentregistraties in SIMS.
• Chain-of-custody-logboeken voor bewijsmateriaal.
• Notulen van directiebeoordelingen.
• Interne auditbevindingen en corrigerende maatregelen.

Veelvoorkomende valkuilen die Clarysec in de praktijk ziet

De meest voorkomende fout is informele deelname. Een security engineer sluit zich aan bij een besloten forum, ontvangt bruikbare intelligence en deelt interne waarnemingen zonder formele autorisatie. De intentie is goed, maar de audittrail is zwak en het vertrouwelijkheidsrisico is hoog.

De tweede fout is passieve consumptie. De organisatie abonneert zich op feeds, neemt deel aan ISAC-calls en stuurt adviezen door, maar niemand kan aantonen hoe intelligence beheersmaatregelen heeft gewijzigd. Threat intelligence moet detectielogica, patchprioriteiten, draaiboeken, risicoregisters, leveranciersbeoordelingen, bewustwordingscampagnes of weerbaarheidstests actualiseren.

De derde fout is het delen van ruwe logboeken. Teams sturen schermafbeeldingen, SIEM-exporten, e-mailheaders of packet captures extern zonder minimalisatie. Dit kan persoonsgegevens, klantidentificatoren, interne hostnamen, tokens of vertrouwelijke architectuur blootleggen.

De vierde fout is public relations verwarren met gereguleerde communicatie. Een LinkedIn-bericht over een aanvalstrend is niet hetzelfde als een klantwaarschuwing, melding aan een toezichthouder, CSIRT-update of gecoördineerd advies. Clarysec scheidt deze kanalen, wijst goedkeuringseigenaren toe en vereist registraties.

De vijfde fout is leveranciers negeren. Veel intelligence-waarschuwingen hebben betrekking op software van derden, cloudplatformen, managed service providers of identiteitsintegraties. Onder DORA, NIS2, NIST CSF, COBIT 2019 en leveranciersbeheersmaatregelen uit ISO/IEC 27002:2022 moet threat intelligence leveranciersrisicobeheer voeden.

Bouw uw pakket voor het delen van threat intelligence in 2026

De meeste organisaties hebben geen zware zelfstandige bureaucratie nodig. Zij hebben een compact governancepakket nodig dat werkt tijdens een echt incident. Clarysec adviseert:

• Procedure voor het delen van threat intelligence.
• Register van goedgekeurde communities voor delen.
• Intake- en triageformulier voor threat intelligence.
• Goedkeuringsformulier voor uitgaande openbaarmaking.
• Checklist voor privacy- en vertrouwelijkheidsbeoordeling.
• Matrix voor externe communicatie.
• Sjabloon voor ISAC-vergadersamenvatting.
• Regels voor koppeling van bewijs en incidenten.
• Metriekendashboard.
• Testplan voor interne audit.

De procedure moet verwijzen naar clausules over risicobeheer, communicatie, operationele beheersing, prestatie-evaluatie, interne audit en continue verbetering in ISO/IEC 27001:2022. De procedure moet worden gemapt op ISO/IEC 27002:2022-beheersmaatregelen 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15, 8.16 en relevante leveranciersbeheersmaatregelen. Ook moet zij verwijzen naar DORA Article 45, NIS2-samenwerking en verplichtingen voor incidentcommunicatie, en GDPR-beginselen.

Het belangrijkste is dat de procedure onder druk bruikbaar moet zijn. Als het proces een overleg met 12 personen vereist voordat een malafide domein met een vertrouwde ISAC kan worden gedeeld, faalt het. Als het toestaat dat ruwe klantlogboeken in een communityportaal worden geplakt, faalt het ook. Het doel is beheerste snelheid.

Zet het delen van threat intelligence om in evidence-based weerbaarheid

Het delen van cyberdreigingsinformatie in 2026 is niet alleen een bewijs van beveiligingsvolwassenheid. Voor financiële entiteiten is het verbonden met DORA Article 45 en digitale operationele weerbaarheid. Voor essentiële en belangrijke entiteiten ondersteunt het NIS2-samenwerking, incidentafhandeling, respons op kwetsbaarheden, leveranciersbeveiliging en waarschuwing van afnemers van diensten. Voor elke organisatie die persoonsgegevens uit de EU verwerkt, moet het door ontwerp GDPR-veilig zijn.

Clarysec helpt organisaties dit operationele model te bouwen zonder verdedigers te vertragen. We verbinden de Zenith Blueprint Zenith Blueprint, de policytoolkit en Zenith Controls Zenith Controls tot een werkend ISMS-proces: goedgekeurde communities, duidelijke rollen, privacyveilige openbaarmaking, koppeling met incidenten, bewijsregistraties, auditgereedheid en mapping over meerdere raamwerken.

Als uw organisatie deelneemt aan een ISAC, cyberadviezen ontvangt, indicatoren met peers deelt, aan autoriteiten rapporteert of openbaarmakingen van kwetsbaarheden afhandelt, is dit het moment om de workflow te formaliseren. Begin met een beoordeling van één uur van uw huidige afspraken voor delen en map deze vervolgens op ISO/IEC 27001:2022, DORA Article 45, NIS2 en GDPR.

Clarysec kan u helpen bij het opzetten van het register, de beleidsclausules, goedkeuringssjablonen, het model voor auditbewijs en het rapportagepakket voor het management die nodig zijn om het delen van cyberdreigingsinformatie snel, rechtmatig en verdedigbaar te maken.