ISO 27001-dreigingsinformatie voor NIS2 en DORA
Om 07:42 uur op een dinsdagochtend ontvangt de CISO van een Europese fintech vier berichten, nog vóór de koffie.
Het eerste is een waarschuwing van een nationale CERT dat een kwetsbaarheid voor externe toegang actief wordt uitgebuit. Het tweede is een leveranciersbulletin dat bevestigt dat de getroffen component wordt gebruikt binnen een beheerde dienst voor bestandsoverdracht. Het derde is een melding van managed detection and response die ongebruikelijk uitgaand verkeer vanaf een niet-productiesubnet signaleert. Het vierde komt van de CFO: “Raakt dit ons DORA-readinesspakket, en moeten we iemand onder NIS2 informeren?”
Dit is het vraagstuk rond dreigingsinformatie in 2026. Het gaat niet om het verzamelen van meer feeds. Het gaat erom aan te tonen dat relevante cyberdreigingsinformatie wordt ontvangen, gevalideerd, gerouteerd, opgevolgd en omgezet in bewijs voor risico, detectie, kwetsbaarheden, incidenten, leveranciers en governance.
Veel organisaties zijn al geabonneerd op leveranciersadviezen, CISA-waarschuwingen, ENISA-updates, meldingen van nationale CERT’s, ISAC-bulletins, beveiligingsmeldingen van cloudproviders, CVE-feeds, MDR-rapporten, databases over exploitbaarheid en darkwebmonitoring. Toch ontstaat er nog steeds hectiek zodra een werkelijk relevant advies binnenkomt. Het SOC schrijft een detectieregel. Infrastructuurteams doorzoeken inventarissen van bedrijfsmiddelen die mogelijk niet actueel zijn. Compliance vraagt of de gebeurtenis gevolgen heeft voor NIS2 of DORA. Het management wil een duidelijk antwoord voordat de organisatie zelfs maar weet of de kwetsbare component in productie aanwezig is.
Het probleem is niet een gebrek aan gegevens. Het probleem is het ontbreken van een auditbaar operationeel model.
Een dreigingsfeed die niemand gebruikt, is geen beheersmaatregel. Een kwetsbaarheidsadvies dat de patchprioriteit niet wijzigt, is geen bewijs. Een leveranciersmelding die nooit het risicoregister bereikt, is geen beveiliging van de toeleveringsketen. Een CSIRT-waarschuwing die monitoring, incidenttriage of managementrapportage niet bijwerkt, is slechts ruis in de inbox.
De aanpak van Clarysec is eenvoudig: dreigingsinformatie moet een besturingsmechanisme voor risicobesluiten worden. Zij moet zijn ingebed in het ISMS-toepassingsgebied, de risicobeoordeling, de Verklaring van Toepasselijkheid, incidentdraaiboeken, kwetsbaarheidstriage, logging en monitoring, leveranciersgovernance, managementrapportage en het auditbewijspakket.
Waarom dreigingsinformatie nu een beheersmaatregel op bestuursniveau is
NIS2 heeft de toon van cybersecuritygovernance veranderd. De richtlijn brengt veel SaaS-aanbieders, cloudproviders, managed service providers, managed security service providers, organisaties voor digitale infrastructuur en digitale dienstverleners binnen het toepassingsgebied als essentiële of belangrijke entiteiten, afhankelijk van sector, omvang en aanwijzing door de lidstaat.
NIS2 Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen om risico’s te beheren. Deze omvatten risicoanalyse, incidentafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, beveiliging bij verwerving, ontwikkeling en onderhoud, inclusief kwetsbaarheidsafhandeling en openbaarmaking, beoordeling van doeltreffendheid, basale cyberhygiëne en training, cryptografie, personeelsbeveiliging, toegangscontrole, beheer van bedrijfsmiddelen en MFA of continue authenticatie waar passend.
NIS2 Article 20 vereist ook dat bestuursorganen maatregelen voor cybersecurityrisicobeheer goedkeuren, toezicht houden op de implementatie en training ontvangen. Voor essentiële entiteiten kan de maximale administratieve boete ten minste EUR 10 miljoen of 2 procent van de wereldwijde jaaromzet bedragen, afhankelijk van welk bedrag hoger is. Voor belangrijke entiteiten kan dit oplopen tot ten minste EUR 7 miljoen of 1,4 procent.
Voor dreigingsinformatie wordt de vraag op bestuursniveau: hoe weten we dat opkomende dreigingen onze beheersmaatregelen aanpassen voordat zij incidenten worden?
DORA voegt een extra laag toe voor financiële entiteiten en relevante ICT-dienstverleners van derden. DORA is van toepassing vanaf 17 januari 2025 en vereist een robuust, volledig en goed gedocumenteerd kader voor ICT-risicobeheer dat is geïntegreerd in het algemene risicobeheersysteem. Het DORA-kader verwacht dat organisaties door ICT ondersteunde bedrijfsfuncties en activa identificeren en classificeren, beschermen en preventieve maatregelen nemen, afwijkende activiteit detecteren, reageren en herstellen, back-ups en herstel beheren, leren van ICT-incidenten, communiceren tijdens crises en ICT-risico’s van derden beheren.
DORA vereist ook beheer, classificatie en rapportage van ICT-gerelateerde incidenten. Articles 17, 18 en 19 behandelen processen voor incidentbeheer, classificatie van ICT-gerelateerde incidenten en cyberdreigingen, en rapportage van majeure ICT-gerelateerde incidenten. Article 10 richt zich op detectie van afwijkende activiteiten. Articles 6 tot en met 11 beschrijven het kader voor ICT-risicobeheer en de verwachtingen voor identificatie, bescherming, preventie, detectie, respons en herstel.
Eenvoudig gezegd verwacht DORA dreigingsbewuste weerbaarheid. Geen statische weerbaarheid. Geen jaarlijkse beleidsweerbaarheid. Dreigingsbewuste weerbaarheid.
ISO/IEC 27001:2022 biedt de managementsysteemmotor die deze verwachtingen verbindt. Clauses 4.1 tot en met 4.4 vereisen dat de organisatie haar interne en externe context, belanghebbenden, wettelijke en regelgevende verplichtingen, ISMS-toepassingsgebied, afhankelijkheden en op elkaar inwerkende processen begrijpt. Clauses 6.1.1 tot en met 6.1.3 vereisen een herhaalbaar proces voor risicobeoordeling en risicobehandeling, selectie van beheersmaatregelen, vergelijking met Annex A, een Verklaring van Toepasselijkheid, behandelplanning en goedkeuring van restrisico door de risico-eigenaar.
Dreigingsinformatie hoort daar thuis: niet als losstaand dashboard, maar als input voor context, risico, selectie van beheersmaatregelen, behandeling, monitoring, directiebeoordeling en voortdurende verbetering.
De compliancevalkuil: dreigingsfeeds zonder traceerbaarheid van besluiten
Het meest voorkomende faalpatroon is bedrieglijk eenvoudig: de organisatie ontvangt dreigingsinformatie, maar kan niet aantonen hoe die besluiten verandert.
Een zwakke bewijsvoering ziet er meestal zo uit:
| Ontvangen signaal | Zwakke reactie | Zorgpunt voor de auditor |
|---|---|---|
| CERT-waarschuwing over actieve exploitatie | Doorgestuurd naar IT-mailbox | Geen bewijs van risicobeoordeling, eigenaarschap of actie |
| Leveranciersbulletin over kritieke patch | Toegevoegd aan ticketbacklog | Geen prioritering op basis van criticaliteit van bedrijfsmiddelen of exploitactiviteit |
| MDR-detectie van verdachte commandoregel | Gesloten als false positive | Geen gedocumenteerde triagecriteria of leermechanisme |
| Leveranciersmelding over gecompromitteerde afhankelijkheid | Gearchiveerd in inkoopmap | Geen update van leveranciersrisico of beoordeling van compenserende beheersmaatregelen |
| ISAC-waarschuwing over sectorcampagne | Genoemd in SOC-overleg | Geen update van monitoring, bewustwording of incidentdraaiboek |
Hier helpt de implementatiemethode van Clarysec organisaties om te bewegen van “we ontvangen intelligence” naar “we operationaliseren intelligence”.
In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint zet de fase Controls in Action dreigingsinformatie expliciet om in een auditbare praktijk. Step 22, organisatorische beheersmaatregelen, stelt:
Stel een gedocumenteerde lijst op van bronnen voor dreigingsinformatie (5.7), afkomstig van leveranciers, ISACs of open bronnen, en bepaal hoe intelligence wordt gevalideerd en geïntegreerd in besluitvorming. Definieer wie dreigingsupdates ontvangt en hoe deze worden toegepast (bijv. patchprioritering, bewustwordingstraining). Maak een korte briefing over dreigingstrends die per kwartaal aan belangrijke stakeholders wordt verspreid.
Die instructie vormt de brug tussen dreigingsgegevens en compliancebewijs. Een register voor dreigingsinformatie is niet slechts een lijst met bronnen. Het bewijst relevantie, eigenaarschap, validatie, routering, integratie en zakelijk gebruik.
ISO 27001-beheerslogica: de keten voor dreigingsinformatie
ISO/IEC 27002:2022-beheersmaatregel 5.7, dreigingsinformatie, vereist dat organisaties informatie met betrekking tot informatiebeveiligingsdreigingen verzamelen, analyseren en gebruiken om dreigingsinformatie te produceren. In Zenith Controls: The Cross-Compliance Guide Zenith Controls wordt beheersmaatregel 5.7 geclassificeerd als preventief, detectief en corrigerend. De beheersmaatregel ondersteunt vertrouwelijkheid, integriteit en beschikbaarheid, sluit aan op de cybersecurityconcepten Identify, Detect en Respond, en bevindt zich binnen dreigings- en kwetsbaarhedenbeheer als operationele capaciteit.
Die classificatie doet ertoe. Dreigingsinformatie werkt preventief doordat zij hardening, patching, training en leveranciersbeheersmaatregelen informeert. Zij werkt detectief doordat zij monitoring, SIEM-regels en huntingtaken vormgeeft. Zij werkt corrigerend doordat zij incidentrespons, geleerde lessen en risicobehandeling verbetert.
Zenith Controls koppelt ISO/IEC 27002:2022-beheersmaatregel 5.7 ook aan ondersteunende beheersmaatregelen:
| Relatie met ISO/IEC 27002:2022-beheersmaatregel | Waarom dit in de praktijk belangrijk is |
|---|---|
| 5.6 Contact met speciale belangengroepen | ISACs, CERT’s, professionele fora en sectorgemeenschappen zijn bronnen voor dreigingsinformatie, geen aanvullende netwerkactiviteiten |
| 8.7 Bescherming tegen malware | Indicatoren van compromittering, malafide URL’s, hashes, command-and-control-infrastructuur en aanvalspatronen werken endpoint- en e-mailverdediging bij |
| 8.8 Beheer van technische kwetsbaarheden | Informatie over exploitatie in het wild wijzigt de prioriteit van kwetsbaarheden en de urgentie van patches |
| 8.15 Logging | Logboeken leveren de feitelijke registratie die nodig is om naar indicatoren te zoeken en activiteit te reconstrueren |
| 8.16 Monitoringactiviteiten | Dreigingsinformatie vertelt het SOC wat het moet monitoren, terwijl monitoring interne dreigingsinformatie oplevert |
| 5.25 Beoordeling van en besluitvorming over informatiebeveiligingsgebeurtenissen | Door dreigingsinformatie onderbouwde triage helpt bepalen of een gebeurtenis een beveiligingsincident is |
De koppeling met kwetsbaarheden is bijzonder belangrijk. Zenith Controls behandelt beheersmaatregel 8.8, beheer van technische kwetsbaarheden, als preventief en direct verbonden met beheersmaatregel 5.7, omdat praktijkgerichte dreigingsinformatie aangeeft welke kwetsbaarheden actief worden uitgebuit. De gids verbindt 8.8 ook met 8.16, monitoringactiviteiten, omdat waargenomen exploitpogingen de patchurgentie moeten verhogen.
Dat creëert een praktische keten voor dreigingsinformatie:
- Externe of interne dreigingsinformatie komt binnen.
- Relevantie wordt gevalideerd ten opzichte van activa, leveranciers, geografie, sector, bedrijfsdiensten en gegevens.
- Risico wordt bijgewerkt.
- Prioriteiten voor patches en configuraties wijzigen.
- Detectielogica wordt afgestemd.
- Incidentdraaiboeken en classificatiedrempels worden beoordeeld.
- Leveranciers- en cloudafhankelijkheden worden gecontroleerd.
- Het management ontvangt trendrapportage.
- Bewijs wordt bewaard voor auditors, toezichthouders en klanten.
Beleidslijnen die intelligence omzetten in verantwoordelijk gedrag
Beleid is de plaats waar beheerslogica wordt omgezet in rolgebaseerde verantwoordingsplicht. De SME- en enterprise-beleidssets van Clarysec bevatten aanknopingspunten voor dreigingsinformatie in risicobeheer, endpointbeveiliging, kwetsbaarhedenbeheer, logging, monitoring en auditbewijs.
Voor mkb-organisaties stelt het Endpointbeveiligingsbeleid - malwarebescherming Endpoint Protection - Malware Policy - SME een directe verwachting vast in governancevereisten clausule 5.4.1:
De IT-supportverlener moet geloofwaardige bronnen voor dreigingsinformatie monitoren (bijv. CISA, ENISA, grote antivirusleveranciers) en ervoor zorgen dat detectiesignatures actueel blijven
De waarde van deze clausule is toewijzing. Dreigingsinformatie is niet “iemand binnen IT zou waarschuwingen moeten controleren”. Het is een expliciete leveranciersverplichting.
Het Beleid inzake kwetsbaarheden- en patchbeheer Vulnerability and Patch Management Policy - SME versterkt hetzelfde model in rollen en verantwoordelijkheden clausule 4.2.1:
Monitort systemen op kwetsbaarheden en beschikbare patches met behulp van leveranciersmeldingen, dreigingsadviezen en meldingen van besturingssystemen
Het benoemt ook, in vereisten voor beleidsimplementatie clausule 6.2.1.3, het type bron dat actie moet triggeren:
Vertrouwde dreigingsadviezen (bijv. CISA, ENISA, nationale CERT-waarschuwingen)
Voor enterprise-organisaties stelt het Beleid inzake kwetsbaarheden- en patchbeheer Vulnerability and Patch Management Policy in rollen en verantwoordelijkheden clausule 4.5.1:
Monitor dreigingsadviezen (bijv. CVE, CISA KEV, leveranciersbulletins) en escaleer kritieke kwetsbaarheden.
De escalatieverplichting is cruciaal. Een kwetsbaarheid wordt urgent wanneer exploitbaarheid, blootstelling, bedrijfscriticaliteit, gegevensgevoeligheid en dreigingsactiviteit samenkomen.
Het Beleid inzake risicobeheer Risk Management Policy verankert dreigingsinformatie in analyse. Vereisten voor beleidsimplementatie clausule 6.2.2 stelt:
De analyse moet rekening houden met de doeltreffendheid van bestaande beheersmaatregelen, relevante dreigingsinformatie, criticaliteit van bedrijfsmiddelen en ernst van kwetsbaarheden.
Die clausule vormt de kern van auditgereed gebruik van dreigingsinformatie. Zij bewijst dat risicoanalyse niet theoretisch is.
Het Beleid voor logging en monitoring Logging and Monitoring Policy zet intelligence om in detectie. De doelclausule 1.2 stelt:
Auditlogging, monitoring en dreigingsdetectie zijn essentieel voor anomaliedetectie, dreigingsrespons, forensische beoordeling, het aantonen van naleving bij audits en juridische naleving. Dit beleid zorgt ervoor dat alle door systemen gegenereerde gebeurtenissen correct worden geregistreerd, bewaard en gecorreleerd met tijdgesynchroniseerde nauwkeurigheid.
Tot slot legt het Beleid voor audit en compliancemonitoring Audit and Compliance Monitoring Policy uit waarom discipline rond bewijs belangrijk is. Doelstellingen clausule 3.4 vereist dat de organisatie bewijs genereert:
Om verdedigbaar bewijs en een audittrail te genereren ter ondersteuning van verzoeken van toezichthouders, gerechtelijke procedures of klantverzoeken om assurance.
Wanneer NIS2, DORA, een klant of een ISO-auditor vraagt wat u wist, wanneer u het wist, wie besloot en wat er veranderde, is deze bewijsvoering het verschil tussen volwassen assurance en defensieve hectiek.
Bouw het register voor dreigingsinformatie
Een volwassen register heeft twee lagen: brongovernance en gebeurtenisopvolging. Brongovernance definieert wat de organisatie vertrouwt, wie eigenaar is, hoe wordt gevalideerd en welke actie kan worden getriggerd.
| Bronnaam | Type | Validatieproces | Integratiepunt | Eigenaar |
|---|---|---|---|---|
| CISA KEV Catalog | Operationeel | Kruiscontrole met inventaris van bedrijfsmiddelen en blootstelling | Noodprioritering van patches triggeren | Kwetsbaarhedenbeheer |
| ENISA-adviezen | Strategisch | Beoordeling door risico-eigenaar of risicocomité | Risicoscenario’s en managementbriefing bijwerken | CISO |
| Sector-ISAC | Tactisch | IOC’s analyseren op relevantie voor de technologiestack | SIEM, EDR en huntingtaken bijwerken | SOC-lead |
| Bulletins van cloudproviders | Operationeel | Getroffen diensten en regio’s verifiëren | Escaleren naar cloud engineering | DevOps-lead |
| Meldingen van leverancierspatches | Operationeel | Product, versie en implementatiescope bevestigen | Toevoegen aan patchcyclus of noodwijziging | IT-operaties |
| MDR-meldingen | Tactisch en operationeel | Triage aan de hand van logboeken, activa en bekende baselines | Detectie-, onderzoeks- of incidentcase openen | Security operations |
| Beveiligingsmeldingen van leveranciers | Operationeel | Koppelen aan gecontracteerde diensten en gegevensstromen | Leveranciersrisico en compenserende beheersmaatregelen bijwerken | Leveranciereigenaar |
Gebeurtenisopvolging legt vast hoe een specifiek advies bewijs werd. Terug naar het dinsdagochtendscenario rond bestandsoverdracht: de registervermelding moet voldoende informatie bevatten om risico-, respons- en compliancebesluiten te ondersteunen.
| Veld | Voorbeeldvermelding |
|---|---|
| Datum en tijd ontvangen | 2026-05-26 07:42 UTC |
| Bron | Nationale CERT-waarschuwing, leveranciersbulletin, MDR-melding |
| Brontype | Overheidsadvies, leveranciersadvies, interne detectie |
| Getroffen technologie | Beheerde dienst voor bestandsoverdracht, versiebereik, afhankelijke bibliotheken |
| Proceseigenaar | Hoofd Platform Operations |
| Risico-eigenaar | CISO |
| Koppeling aan bedrijfsmiddel | Externe gateway voor bestandsoverdracht, workflow voor klantrapportage |
| Initiële ernst | Hoog, in afwachting van blootstellingsvalidatie |
| Vereiste acties | Blootstellingscontrole, patchstatus, detectiebeoordeling, leveranciersbevestiging |
| Compliancerelevantie | NIS2 Article 21, NIS2 Article 23 als aan criteria voor significante incidenten is voldaan, DORA ICT-risico en incidentlevenscyclus indien van toepassing |
| Locatie van bewijs | Ticket, update van risicoregister, SIEM-wijziging, managementnotitie |
Dit is geen bureaucratie. Het is de feitelijke registratie die bewijst dat uw organisatie een gedefinieerd proces heeft voor intake, validatie, triage, escalatie en bewijsvoering.
Van advies naar auditbewijs: een praktische workflow
Een workflow voor dreigingsinformatie moet snel zes vragen beantwoorden: zijn we blootgesteld, hoe ernstig is het, wat moet veranderen, wie is eigenaar, moeten we rapporteren en welk bewijs moet worden bewaard?
1. Valideer blootstelling en bedrijfsimpact
ISO/IEC 27001:2022 clauses 4.1 tot en met 4.4 vereisen dat het ISMS de feitelijke context, verplichtingen en afhankelijkheden van de organisatie weerspiegelt. De eerste taak is niet blind patchen. De eerste taak is blootstelling valideren.
Stel de volgende vragen:
- Gebruiken wij de getroffen technologie?
- Is deze vanaf internet bereikbaar?
- Wordt deze gebruikt door een kritieke bedrijfsdienst?
- Verwerkt deze persoonsgegevens?
- Wordt deze beheerd door een leverancier of managed service provider?
- Is deze relevant voor een kritieke of belangrijke functie onder DORA?
- Is deze relevant voor diensten binnen het toepassingsgebied van NIS2?
- Zijn er contractuele meldplichten richting klanten?
- Zijn logboeken beschikbaar, volledig en tijdgesynchroniseerd?
Als persoonsgegevens mogelijk zijn geraakt, komt ook GDPR-verantwoordingsplicht in de analyse. GDPR vereist passende beveiliging van de verwerking en aantoonbare verantwoordingsplicht, inclusief het vermogen om te beoordelen of zich een inbreuk in verband met persoonsgegevens heeft voorgedaan en of melding vereist is.
2. Werk het risicoregister bij
Het Beleid inzake risicobeheer Risk Management Policy - SME geeft een eenvoudige timingregel in governancevereisten clausule 5.1.3:
Risico’s moeten elk kwartaal worden beoordeeld en worden bijgewerkt wanneer zich significante gebeurtenissen voordoen.
Een geloofwaardig advies over actieve exploitatie is een significante gebeurtenis. De update mag niet wachten tot de volgende kwartaalbeoordeling.
| Risico-element | Bijgewerkte beoordeling |
|---|---|
| Dreiging | Actieve exploitatie van kwetsbaarheid in beheerde bestandsoverdracht |
| Kwetsbaarheid | Getroffen versie, blootgestelde interface, zwakke configuratie, ontbrekende patch |
| Bedrijfsmiddel | Platform voor uitwisseling van klantgegevens |
| Gevolg | Verstoring van dienstverlening, ongeautoriseerde toegang tot gegevens, regelgevende rapportage, impact op klantvertrouwen |
| Waarschijnlijkheid | Verhoogd door actieve exploitatie in het wild |
| Bestaande beheersmaatregelen | MFA, WAF, endpointbeveiliging, SIEM-monitoring, back-up, leveranciers-SLA |
| Beheersingshiaten | Patch niet bevestigd, detectie niet afgestemd, leveranciersbewijs in afwachting |
| Behandeling | Noodpatch, tijdelijke netwerkbeperking, IOC-hunt, leveranciersattest, impactbeoordeling voor klanten |
| Eigenaar van restrisico | CISO en eigenaar Platform Operations |
Dit sluit direct aan op ISO/IEC 27001:2022 clauses 6.1.1-6.1.3. De organisatie identificeert risico, analyseert waarschijnlijkheid en gevolgen, prioriteert behandeling, selecteert beheersmaatregelen, onderhoudt de Verklaring van Toepasselijkheid, stelt een behandelplan op en verkrijgt goedkeuring van restrisico.
3. Prioriteer kwetsbaarheidsbehandeling met exploitatie-intelligence
De Zenith Blueprint, fase Controls in Action, Step 19, Technological Controls I, legt uit waarom kwetsbaarhedenbeheer een kernonderdeel is van moderne cyberhygiëne:
Het beheren van kwetsbaarheden is een van de meest kritieke onderdelen van moderne cyberhygiëne. Hoewel firewalls en antivirustools bescherming bieden, kunnen zij worden ondermijnd als ongepatchte systemen of verkeerd geconfigureerde diensten blootgesteld blijven. Om aan deze beheersmaatregel te voldoen, moeten organisaties een gestructureerd en herhaalbaar proces implementeren voor het identificeren, beoordelen en aanpakken van kwetsbaarheden.
CVSS alleen is niet genoeg. Een kwetsbaarheid met een middelhoge score die actief wordt uitgebuit op een systeem dat vanaf internet bereikbaar is, kan urgenter zijn dan een kwetsbaarheid met een hoge score die diep in een gesegmenteerd lab zit.
| Factor | Vraag | Bewijs |
|---|---|---|
| Exploitactiviteit | Wordt exploitatie waargenomen of gerapporteerd door vertrouwde bronnen? | CERT-waarschuwing, CISA KEV-verwijzing, leveranciersbulletin, MDR-rapport |
| Blootstelling | Is het bedrijfsmiddel vanaf internet bereikbaar of bereikbaar voor leveranciers? | Inventaris van bedrijfsmiddelen, cloud security posture, netwerkscan |
| Bedrijfscriticaliteit | Ondersteunt het essentiële diensten of kritieke functies? | Business Impact Analysis, DORA-functiemapping |
| Gegevensgevoeligheid | Verwerkt het persoonsgegevens, gereguleerde financiële gegevens of vertrouwelijke klantgegevens? | Gegevensinventaris, DPIA, verwerkingsregistraties |
| Compenserende beheersmaatregelen | Kunnen WAF, firewallregels, segmentatie, EDR of uitschakeling van functies het risico beperken? | Wijzigingsticket, firewallregel, EDR-beleid |
| Operationeel risico | Kan noodpatching de levering van kritieke diensten verstoren? | Wijzigingsbeoordeling, rollbackplan, continuïteitsplan |
Dit levert een verdedigbaar besluit op. Het ondersteunt ook NIS2 Article 21(2)(e) voor kwetsbaarheidsafhandeling, NIS2 Article 21(2)(g) voor cyberhygiëne en de verwachtingen van DORA voor ICT-risicobeheer.
4. Zet intelligence om in monitoring en detectie
Dreigingsinformatie moet logging en monitoring bereiken. Het Beleid voor logging en monitoring Logging and Monitoring Policy - SME stelt in vereisten voor beleidsimplementatie clausule 6.2.1:
Beveiligingstools (bijv. antivirus, firewalls, VPN’s) moeten worden geconfigureerd om waarschuwingen te genereren voor gedefinieerde dreigingsscenario’s, waaronder:
Het fragment maakt de bedoeling van de beheersmaatregel duidelijk: gedefinieerde dreigingsscenario’s moeten waarschuwingen aansturen.
De Zenith Blueprint, fase Controls in Action, Step 19, beschrijft monitoringactiviteiten als volgt:
Als logging het vastleggen is van wat er in uw omgeving gebeurt, dan is monitoring het bekijken, begrijpen en reageren op die gebeurtenissen. Deze beheersmaatregel gaat over het actief observeren van netwerken, systemen en toepassingen om ongebruikelijke activiteit te detecteren, niet alleen achteraf, maar waar mogelijk realtime of bijna realtime.
Voor het scenario rond bestandsoverdracht moet het SOC of de IT-provider:
- IOC’s uit het CERT- en leveranciersadvies toevoegen of valideren.
- Logboeken doorzoeken op bekende exploitpaden, verdachte uploads, indicatoren van web shells, ongebruikelijke procesuitvoering en onverwachte uitgaande verbindingen.
- Bevestigen dat authenticatie-, beheerdersactiviteit-, bestandstoegangs-, API- en netwerklogboeken worden bewaard.
- SIEM-waarschuwingen afstemmen op het exploitpatroon.
- Een casenotitie aanmaken waarin wordt uitgelegd waarnaar is gezocht, wat is gevonden en wie het heeft beoordeeld.
- Escaleren naar incidentclassificatie als indicatoren wijzen op compromittering, gegevensblootstelling of service-impact.
Hier wordt incidentmelding praktisch. NIS2 Article 23 vereist gefaseerde rapportage van significante incidenten, inclusief een vroege waarschuwing binnen 24 uur, melding binnen 72 uur, tussentijdse updates op verzoek en een eindrapport uiterlijk één maand na de melding. DORA vereist dat financiële entiteiten majeure ICT-gerelateerde incidenten detecteren, beheren, classificeren en rapporteren via het gefaseerde proces dat door de verordening en bijbehorende technische normen is gedefinieerd.
Dreigingsinformatie helpt bepalen of de organisatie zich nog in kwetsbaarheidsrespons, beoordeling van beveiligingsgebeurtenissen of gereguleerde incidentrapportage bevindt.
Eén workflow, meerdere complianceverplichtingen
Dreigingsinformatie is een ideale geïntegreerde complianceworkflow omdat hetzelfde bewijs meerdere regimes ondersteunt.
| Raamwerk of regelgeving | Wat wordt verwacht | Bewijs uit dreigingsinformatie |
|---|---|---|
| ISO/IEC 27001:2022 | Contextbewust ISMS, risicobeoordeling, selectie van beheersmaatregelen, behandelplanning, voortdurende verbetering | ISMS-toepassingsgebied, risicoregister, Verklaring van Toepasselijkheid, behandelplan, input voor directiebeoordeling |
| ISO/IEC 27002:2022 | Dreigingsinformatie, kwetsbaarhedenbeheer, logging, monitoring, incidentbeoordeling, bescherming tegen malware | Register voor dreigingsinformatie, IOC-updates, SIEM-regels, patchtickets, notities van incidenttriage |
| NIS2 | Risicobeheer, incidentafhandeling, cyberhygiëne, kwetsbaarheidsafhandeling, beveiliging van de toeleveringsketen, governancetoezicht | Bewijs voor Article 20 en 21, managementbriefings, CSIRT-rapportageprocedure, opvolging van leveranciersadviezen |
| DORA | ICT-risicokader, detectie, continuïteit, incidentlevenscyclus, weerbaarheidstesten, ICT-risico van derden | ICT-activaclassificatie, detectiecases, registraties van incidentclassificatie, input voor weerbaarheidstesten, registraties van ICT-leveranciers |
| GDPR | Beveiliging van de verwerking, verantwoordingsplicht, ondersteuning voor detectie en melding van inbreuken | Gegevensimpactbeoordeling, toegangslogboeken, monitoringbewijs, registratie van inbreukbeoordeling |
| NIST CSF 2.0 | Resultaten voor Govern, Identify, Protect, Detect, Respond en Recover | Current Profile, Target Profile, geprioriteerd actieplan, risicocommunicatie |
| COBIT 2019 auditlens | Governance over risico, beheersmaatregelen, prestaties, assurance en verantwoordingsplicht | Eigenaarschap van beheersmaatregelen, managementmetrieken, assurancebewijs, opvolging van issueherstel |
NIST CSF 2.0 is bijzonder nuttig voor communicatie met leidinggevenden. De Core Functions, Govern, Identify, Protect, Detect, Respond en Recover, zetten technische intelligence om in een verhaal dat geschikt is voor het bestuur:
- Govern: bronnen voor dreigingsinformatie, eigenaren en rapportagelijnen zijn gedefinieerd.
- Identify: getroffen activa, leveranciers, bedrijfsdiensten en gegevens zijn in kaart gebracht.
- Protect: patching, hardening, segmentatie en endpointsignatures zijn bijgewerkt.
- Detect: monitoringregels, IOC’s en huntingtaken zijn geïmplementeerd.
- Respond: incidentdraaiboeken, triageregels en meldingsdrempels zijn beoordeeld.
- Recover: back-ups, herstelprioriteiten en geleerde lessen zijn gevalideerd.
Dit zet ruwe cyberdreigingsinformatie om in risicogovernance.
Het perspectief van de auditor: wat zij zullen opvragen
Een sterk proces voor dreigingsinformatie moet bestand zijn tegen verschillende auditstijlen. Een ISO-auditor, NIS2-beoordelaar, DORA-toezichthouder, NIST CSF-assessor, COBIT 2019-georiënteerde auditor, ISACA-professional of privacybeoordelaar kan andere taal gebruiken, maar zij komen allemaal uit bij bewijs.
| Auditperspectief | Waarschijnlijke auditvraag | Bewijs dat de vraag beantwoordt |
|---|---|---|
| ISO/IEC 27001:2022-auditor | Hoe beïnvloedt de externe en interne context ISMS-risico’s en beheersmaatregelen? | Register voor dreigingsinformatie, risicomethodologie, bijgewerkt risicoregister, onderbouwing van de Verklaring van Toepasselijkheid |
| ISO/IEC 27002:2022-beoordelaar van beheersmaatregelen | Hoe zijn beheersmaatregelen 5.7, 8.8, 8.16, 8.15, 8.7 en 5.25 met elkaar verbonden? | Bronnenlijst, kwetsbaarheidstriage, SIEM-afstemming, updates van malwaresignatures, registraties van gebeurtenisbeoordeling |
| NIS2-beoordelaar | Hoe voldoet u aan managementtoezicht, cyberhygiëne, kwetsbaarheidsafhandeling, incidentafhandeling en beveiliging van de toeleveringsketen? | Mapping van Article 20 en 21, managementbriefings, CSIRT-rapportageprocedure, workflow voor opvolging van leveranciersadviezen |
| DORA-toezichthouder | Hoe werkt dreigingsinformatie ICT-risico, detectie, weerbaarheidstesten en incidentclassificatie bij? | ICT-risicokader, mapping van kritieke functies, detectiecases, registraties van incidentclassificatie, scope van weerbaarheidstesten |
| NIST CSF-assessor | Wat zijn uw Current Profile, Target Profile en geprioriteerd actieplan? | CSF-profiel, gap assessment, actieplan, logboek voor continue updates |
| COBIT 2019- of ISACA-auditor | Wie is eigenaar van de beheersmaatregel, hoe worden prestaties gemeten en hoe worden uitzonderingen hersteld? | RACI, KPI’s, KRI’s, uitzonderingenregister, hersteltickets, formele managementgoedkeuring |
| GDPR-auditor of privacybeoordelaar | Hoe hebben monitoring en kwetsbaarhedenbeheer persoonsgegevens beschermd en de inbreukbeoordeling ondersteund? | Verwerkingskaart, logboeken, inbreukbeoordeling, bewijs voor technische en organisatorische maatregelen |
Zenith Controls biedt de cross-compliance-interpretatie voor deze gesprekken. Voor beheersmaatregel 8.16, Monitoringactiviteiten, verbindt de gids monitoring met GDPR-beveiliging en verantwoordingsplicht bij inbreuken, NIS2-incidentafhandeling en -rapportage, en DORA-verwachtingen voor detectie en respons. Voor beheersmaatregel 8.8, beheer van technische kwetsbaarheden, verbindt de gids kwetsbaarheidsafhandeling met GDPR-beveiliging van de verwerking, NIS2 Article 21(2)(e) en proactief ICT-risicobeheer onder DORA.
Dat is de convergentie van bewijs die auditors willen zien.
Managementrapportage: de kwartaalbriefing over dreigingstrends
Het register voor dreigingsinformatie mag niet in het SOC blijven steken. De Zenith Blueprint beveelt een korte kwartaalbriefing over dreigingstrends aan voor belangrijke stakeholders. Clarysec adviseert een managementrapport van één pagina met vijf onderdelen:
- Top drie relevante dreigingstrends naar bedrijfsimpact.
- Meest blootgestelde technologieën of leveranciers.
- Kritieke kwetsbaarheden die zijn gepatcht, beperkt of geaccepteerd.
- Verbeteringen in detectie en respons die zijn doorgevoerd.
- Besluiten die van het management worden gevraagd.
Een sterke managementbriefing somt geen 400 CVE’s op. Zij legt risicobeweging uit. Bijvoorbeeld:
- Ransomware gericht op managed service providers verhoogde de prioriteit van leveranciersbeoordelingen.
- Exploitatie van platforms voor bestandsoverdracht triggerde noodpatching en een compenserende firewallregel.
- Aanvallen op cloudidentiteiten veroorzaakten een beoordeling van MFA-uitzonderingen en hardening van voorwaardelijke toegang.
- Sector-ISAC-intelligence leidde tot nieuwe phishingsimulaties voor finance- en supportteams.
- DORA-mapping van kritieke functies bracht één monitoringhiaat in een workflow van een derde partij aan het licht.
Deze briefing ondersteunt NIS2-managementverantwoordelijkheid, DORA ICT-risicogovernance, ISO/IEC 27001:2022-directiebeoordeling en assurance richting klanten.
Veelvoorkomende faalpatronen
Programma’s voor dreigingsinformatie ogen vaak volwassen op slides, maar zijn zwak onder audit. De meest voorkomende faalpatronen zijn:
- Te veel feeds en geen validatiecriteria.
- Geen koppeling tussen intelligence en de inventaris van bedrijfsmiddelen.
- Geen gedocumenteerde risicoupdate na majeure adviezen.
- Patchprioriteit uitsluitend gebaseerd op scannerscore.
- Leveranciersadviezen worden buiten het ISMS behandeld.
- SOC-regels worden bijgewerkt zonder wijzigingsregistraties.
- Incidentdrempels zijn niet afgestemd op NIS2- of DORA-rapportageworkflows.
- Bestuursrapportage is gericht op waarschuwingsvolume in plaats van bedrijfsrisico.
- Geen bewijs dat geleerde lessen beheersmaatregelen hebben gewijzigd.
- Geen eigenaar voor het onderhouden van het register voor dreigingsinformatie.
De oplossing is niet het kopen van nog een feed. De oplossing is integratie van beheersmaatregelen.
Een 10-puntenchecklist voor gereedheid in 2026
Gebruik deze checklist als praktische interne beoordeling.
| Gereedheidsvraag | Ja of nee |
|---|---|
| Onderhouden wij een goedgekeurd register voor dreigingsinformatie met broneigenaren en validatieregels? | |
| Worden CERT-, CSIRT-, ISAC-, leveranciers-, cloud-, MDR- en leveranciersadviezen naar benoemde rollen gerouteerd? | |
| Triggeren significante adviezen een beoordeling van het risicoregister buiten de kwartaalcyclus? | |
| Omvat kwetsbaarheidsprioritering exploitactiviteit, criticaliteit van bedrijfsmiddelen, gegevensgevoeligheid en blootstelling? | |
| Worden IOC’s en dreigingsscenario’s omgezet in monitoringregels of huntingtaken? | |
| Worden endpointsignatures, clouddetecties en dynamische dreigingsfeeds gecontroleerd op actualiteit? | |
| Worden leveranciersmeldingen beoordeeld ten opzichte van risico’s in de toeleveringsketen en contractuele verplichtingen? | |
| Zijn criteria voor incidentclassificatie afgestemd op NIS2- en DORA-rapportageworkflows waar van toepassing? | |
| Ontvangt het management een kwartaalbriefing over dreigingstrends? | |
| Kunnen wij binnen één werkdag een bewijspakket produceren voor een auditor, toezichthouder of klant? |
Als het antwoord op een van deze vragen “nee” is, heeft de organisatie niet alleen een probleem met dreigingsinformatie. Zij heeft een ISMS-integratieprobleem.
Hoe Clarysec helpt dreigingsinformatie om te zetten in bewijs
De methode van Clarysec is ontworpen voor organisaties die praktische beveiliging en geloofwaardige compliance tegelijk nodig hebben.
Zenith Blueprint biedt de implementatieroute in 30 stappen, inclusief Step 22 voor het register voor dreigingsinformatie en Step 19 voor kwetsbaarhedenbeheer en monitoringactiviteiten. De enterprise- en SME-beleidslijnen van Clarysec zetten die verwachtingen om in rolgebaseerde procedures voor risicobeheer, kwetsbaarheidsafhandeling, endpointbeveiliging, logging, monitoring en auditbewijs. Zenith Controls biedt vervolgens de cross-compliance-interpretatie en laat zien hoe ISO/IEC 27002:2022-beheersmaatregelen aansluiten op NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 en auditbewijs.
Voor de CISO op dinsdagochtend wordt het antwoord aan de CFO duidelijk:
“We hebben het advies ontvangen, de blootstelling gevalideerd, het risicoregister bijgewerkt, patching geprioriteerd op basis van actieve exploitatie, monitoring afgestemd, leveranciersafhankelijkheid gecontroleerd, drempels voor incidentrapportage beoordeeld, het management geïnformeerd en bewijs bewaard. We gokken niet. We volgen ons ISMS.”
Zo hoort ISO 27001-dreigingsinformatie voor NIS2-cyberhygiëne en DORA ICT-risicobewijs er in 2026 uit te zien.
Volgende stappen
Als uw organisatie dreigingsinformatie ontvangt maar niet kan aantonen hoe die risicobesluiten, beheersmaatregelen, detectie, incidentrespons, leveranciersmanagement en regelgevend bewijs verandert, start dan deze week met drie acties:
- Bouw of actualiseer uw register voor dreigingsinformatie met Zenith Blueprint, fase Controls in Action, Step 22.
- Breng uw huidige proces in kaart ten opzichte van ISO/IEC 27002:2022-beheersmaatregelen 5.7, 8.8, 8.15, 8.16, 8.7 en 5.25 met Zenith Controls.
- Stem uw beleidslijnen op elkaar af, met name Beleid inzake risicobeheer, Beleid inzake kwetsbaarheden- en patchbeheer, Beleid voor logging en monitoring en Beleid voor audit en compliancemonitoring, zodat elk advies verdedigbaar bewijs kan worden.
Clarysec kan u helpen dreigingsfeeds, adviezen, leveranciersmeldingen, kwetsbaarhedenintelligence en detectiesignalen om te zetten in een operationeel model dat is afgestemd op ISO/IEC 27001:2022, gereed is voor NIS2 en rekening houdt met DORA.
Download de Clarysec-toolkits, vraag een walkthrough aan of boek een gereedheidsbeoordeling om te zien hoe uw huidige proces voor dreigingsinformatie standhoudt tegenover een ISO-auditor, NIS2-beoordelaar, DORA-toezichthouder of klantverzoek om assurance.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
