Trusselsintelligens i ISO 27001 til NIS2 og DORA

Kl. 07:42 en tirsdag morgen modtager CISO’en i en europæisk fintech-virksomhed fire beskeder, før kaffen er drukket.

Den første er en national CERT-advarsel om, at en sårbarhed i fjernadgang aktivt udnyttes. Den anden er en leverandørbulletin, der bekræfter, at den berørte komponent anvendes i en administreret filoverførselstjeneste. Den tredje er en Managed Detection and Response-meddelelse, der markerer usædvanlig udgående trafik fra et ikke-produktionssubnet. Den fjerde er fra CFO’en: “Påvirker det vores DORA-beredskabspakke, og skal vi underrette nogen efter NIS2?”

Det er udfordringen med trusselsintelligens i 2026. Det handler ikke om at indsamle flere feeds. Det handler om at dokumentere, at relevant cybertrusselsintelligens modtages, valideres, routes, behandles og omsættes til bevismateriale for risiko, detektion, sårbarheder, hændelser, leverandører og bestyrelse.

Mange organisationer abonnerer allerede på leverandørmeddelelser, CISA-advarsler, ENISA-opdateringer, nationale CERT-meddelelser, ISAC-bulletiner, cloududbyderes sikkerhedsmeddelelser, CVE-feeds, MDR-rapporter, databaser over udnyttelighed og dark web-overvågning. Alligevel opstår der travlhed, når en reel meddelelse lander. SOC’et skriver en detektionsregel. Infrastrukturteamet søger i aktivfortegnelser, som måske ikke er ajour. Compliance spørger, om hændelsen påvirker NIS2 eller DORA. Ledelsen ønsker et klart svar, før organisationen overhovedet ved, om den sårbare komponent findes i produktionsmiljøet.

Problemet er ikke mangel på data. Problemet er manglen på en driftsmodel, der kan revideres.

Et trusselsfeed, som ingen bruger, er ikke en kontrol. En sårbarhedsmeddelelse, der ikke ændrer patchprioritet, er ikke bevismateriale. En leverandørmeddelelse, der aldrig når risikoregisteret, er ikke sikkerhed i forsyningskæden. En CSIRT-advarsel, der ikke opdaterer overvågning, hændelsestriage eller ledelsesrapportering, er blot støj i indbakken.

Clarysecs tilgang er enkel: trusselsintelligens skal fungere som et operativt system for risikobeslutninger. Den skal integreres i ISMS-omfang, risikovurdering, anvendelighedserklæring (SoA), hændelsesplaybooks, sårbarhedstriage, logning og overvågning, leverandørstyring, ledelsesrapportering og revisionsbevismateriale.

Hvorfor trusselsintelligens nu er en kontrol på bestyrelsesniveau

NIS2 har ændret tonen i cybersikkerhedsstyring. Direktivet bringer mange SaaS-udbydere, cloududbydere, udbydere af administrerede tjenester, udbydere af administrerede sikkerhedstjenester, digitale infrastrukturorganisationer og digitale tjenesteudbydere ind i anvendelsesområdet som væsentlige eller vigtige enheder afhængigt af sektor, størrelse og medlemsstatens udpegning.

NIS2 Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger til at styre risici. Disse omfatter risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, sikkerhed ved anskaffelse, udvikling og vedligeholdelse, herunder håndtering og offentliggørelse af sårbarheder, vurdering af effektivitet, grundlæggende cyberhygiejne og uddannelse, kryptografi, HR-sikkerhed, adgangsstyring, politik for styring af aktiver og MFA eller løbende autentifikation, hvor det er relevant.

NIS2 Article 20 kræver også, at ledelsesorganer godkender risikostyringsforanstaltninger for cybersikkerhed, fører tilsyn med implementeringen og modtager træning. For væsentlige enheder kan den maksimale administrative bøde udgøre mindst EUR 10 millioner eller 2 procent af den globale årlige omsætning, alt efter hvad der er højest. For vigtige enheder kan den udgøre mindst EUR 7 millioner eller 1,4 procent.

For trusselsintelligens bliver spørgsmålet på bestyrelsesniveau: hvordan ved vi, at fremspirende trusler ændrer vores kontroller, før de bliver til hændelser?

DORA tilføjer endnu et lag for finansielle enheder og relevante IKT-tredjepartsudbydere. DORA finder anvendelse fra 17. januar 2025 og kræver en robust, omfattende og veldokumenteret ramme for styring af IKT-risiko, der er integreret i det samlede risikostyringssystem. DORA’s ramme forventer, at organisationer identificerer og klassificerer IKT-understøttede forretningsfunktioner og aktiver, beskytter og forebygger, detekterer anomal aktivitet, reagerer og genopretter, styrer sikkerhedskopier og gendannelse, lærer af IKT-hændelser, kommunikerer under kriser og styrer IKT-tredjepartsrisici.

DORA kræver også hændelsesstyring, klassificering og rapportering for IKT-relaterede hændelser. Articles 17, 18 og 19 dækker processer for hændelsesstyring, klassificering af IKT-relaterede hændelser og cybertrusler samt rapportering af større IKT-relaterede hændelser. Article 10 fokuserer på detektion af anomale aktiviteter. Articles 6 til 11 beskriver styringsrammen for IKT-risikostyring samt forventninger til identifikation, beskyttelse, forebyggelse, detektion, respons og genopretning.

Sagt enkelt forventer DORA trusselsinformeret robusthed. Ikke statisk robusthed. Ikke robusthed baseret på en årlig politikgennemgang. Trusselsinformeret robusthed.

ISO/IEC 27001:2022 leverer ledelsessystemets motor, der forbinder disse forventninger. Clauses 4.1 til 4.4 kræver, at organisationen forstår sin interne og eksterne kontekst, interessenter, juridiske og regulatoriske forpligtelser, ISMS-omfang, afhængigheder og samvirkende processer. Clauses 6.1.1 til 6.1.3 kræver en gentagelig proces for risikovurdering og risikobehandling, valg af kontroller, sammenligning med Annex A, en anvendelighedserklæring (SoA), behandlingsplanlægning og risikoejerens godkendelse af restrisiko.

Trusselsintelligens hører hjemme dér, ikke som et sideløbende dashboard, men som input til kontekst, risiko, kontrolvalg, behandling, overvågning, ledelsens gennemgang og løbende forbedring.

Efterlevelsesfælden: trusselsfeeds uden beslutningssporbarhed

Det mest almindelige svigtmønster er tilsyneladende enkelt: organisationen modtager trusselsintelligens, men kan ikke dokumentere, hvordan den ændrer beslutninger.

En svag beviskæde ser typisk sådan ud:

Her hjælper Clarysecs implementeringsmetode organisationer med at gå fra “vi modtager intelligens” til “vi operationaliserer intelligens.”

I Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint omsætter Controls in Action-fasen eksplicit trusselsintelligens til en praksis, der kan revideres. Step 22, organisatoriske kontroller, angiver:

Etablér en dokumenteret liste over kilder til trusselsintelligens (5.7) fra leverandører, ISAC’er eller åbne kilder, og fastlæg, hvordan intelligens valideres og integreres i beslutningstagningen. Definér, hvem der modtager trusselsopdateringer, og hvordan de anvendes, f.eks. til patchprioritering og awareness-træning. Udarbejd en kort briefing om trusselstendenser, som distribueres kvartalsvist til nøgleinteressenter.

Denne anvisning er broen mellem trusselsdata og bevismateriale for efterlevelse. Et register over trusselsintelligens er ikke blot en liste over kilder. Det dokumenterer relevans, ejerskab, validering, routing, integration og forretningsmæssig anvendelse.

ISO 27001-kontrollogik: kæden for trusselsintelligens

ISO/IEC 27002:2022-kontrol 5.7, trusselsintelligens, kræver, at organisationer indsamler og analyserer oplysninger om trusler mod informationssikkerheden og anvender dem til at producere trusselsintelligens. I Zenith Controls: The Cross-Compliance Guide Zenith Controls klassificeres kontrol 5.7 som forebyggende, detekterende og korrigerende. Den understøtter fortrolighed, integritet og tilgængelighed, er tilpasset cybersikkerhedsbegreberne Identify, Detect og Respond og ligger inden for trussels- og sårbarhedsstyring som en operationel kapacitet.

Den klassificering er vigtig. Trusselsintelligens forebygger ved at informere hærdning, patchning, træning og leverandørkontroller. Den detekterer ved at forme overvågning, SIEM-regler og trusselsjagt. Den korrigerer ved at forbedre hændelseshåndtering, erfaringer og risikobehandling.

Zenith Controls kortlægger også ISO/IEC 27002:2022-kontrol 5.7 til understøttende kontroller:

Sårbarhedsforbindelsen er særligt vigtig. Zenith Controls behandler kontrol 8.8, styring af tekniske sårbarheder, som forebyggende og direkte forbundet med kontrol 5.7, fordi trusselsintelligens fra den virkelige verden viser, hvilke sårbarheder der aktivt udnyttes. Den forbinder også 8.8 med 8.16, overvågningsaktiviteter, fordi observerede exploitforsøg bør eskalere patchhastigheden.

Det skaber en praktisk kæde for trusselsintelligens:

1. Ekstern eller intern intelligens ankommer.
2. Relevans valideres mod aktiver, leverandører, geografi, sektor, forretningstjenester og data.
3. Risiko opdateres.
4. Patch- og konfigurationsprioriteter ændres.
5. Detektionslogik justeres.
6. Hændelsesplaybooks og klassificeringstærskler gennemgås.
7. Leverandør- og cloudafhængigheder kontrolleres.
8. Ledelsen modtager trendrapportering.
9. Bevismateriale opbevares til revisorer, tilsynsmyndigheder og kunder.

Politikker, der omsætter intelligens til ansvarlig adfærd

Politikker er dér, hvor kontrollogik bliver til rollebaseret ansvarlighed. Clarysecs politikpakker for SMV’er og enterprise omfatter koblingspunkter for trusselsintelligens på tværs af risikostyring, endpoint-beskyttelse, sårbarhedsstyring, logning, overvågning og revisionsbevismateriale.

For SMV’er fastsætter Endpoint Protection - Malware Policy Endpoint Protection - Malware Policy - SMV en direkte forventning i styringskrav, klausul 5.4.1:

IT-supportleverandøren skal overvåge troværdige kilder til trusselsintelligens, f.eks. CISA, ENISA og større antivirusleverandører, og sikre, at detektionssignaturer holdes ajour

Værdien af denne klausul er placeringen af ansvar. Trusselsintelligens er ikke “nogen i IT bør tjekke advarsler.” Det er en eksplicit leverandørforpligtelse.

Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy - SMV forstærker den samme model i roller og ansvar, klausul 4.2.1:

Overvåger systemer for sårbarheder og tilgængelige patches ved brug af leverandøradvarsler, trusselsmeddelelser og notifikationer fra operativsystemer

Den identificerer også, i krav til implementering af politikken, klausul 6.2.1.3, den type kilde, der skal udløse handling:

Betroede trusselsmeddelelser, f.eks. CISA, ENISA og nationale CERT-advarsler

For enterprise fastsætter Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy i roller og ansvar, klausul 4.5.1:

Overvåg trusselsmeddelelser, f.eks. CVE, CISA KEV og leverandørbulletiner, og eskalér kritiske sårbarheder.

Eskalationskravet er afgørende. En sårbarhed bliver hastende, når udnyttelighed, eksponering, forretningskritikalitet, datafølsomhed og trusselsaktivitet konvergerer.

Risk Management Policy Risk Management Policy indlejrer trusselsintelligens i analysen. Krav til implementering af politikken, klausul 6.2.2, fastsætter:

Analysen skal tage højde for effektiviteten af eksisterende kontroller, relevant trusselsintelligens, aktivkritikalitet og sårbarhedens alvorlighed.

Denne klausul er kernen i revisionsklar trusselsintelligens. Den dokumenterer, at risikoanalyse ikke er teoretisk.

Logging and Monitoring Policy Logging and Monitoring Policy omsætter intelligens til detektion. Dens formål, klausul 1.2, fastsætter:

Revisionslogning, overvågning og trusselsdetektion er kritiske for anomalidetektion, trusselsrespons, forensisk gennemgang, revisionsberedskab og juridisk efterlevelse. Denne politik sikrer, at alle systemgenererede hændelser registreres, opbevares og korreleres korrekt med tidsmæssig nøjagtighed baseret på synkroniseret tid.

Endelig forklarer Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, hvorfor disciplin omkring bevismateriale er vigtig. Mål, klausul 3.4, kræver, at organisationen genererer bevismateriale:

At generere juridisk forsvarligt bevismateriale og et revisionsspor til støtte for regulatoriske forespørgsler, retssager eller anmodninger fra kunder eller partnere om dokumentation.

Når NIS2, DORA, en kunde eller en ISO-revisor spørger, hvad I vidste, hvornår I vidste det, hvem der besluttede, og hvad der ændrede sig, er dette revisionsspor forskellen mellem moden sikkerhedsdokumentation og defensiv brandslukning.

Opbyg registeret over trusselsintelligens

Et modent register har to lag: kildestyring og hændelsessporing. Kildestyring definerer, hvad organisationen har tillid til, hvem der ejer det, hvordan det valideres, og hvilke handlinger det kan udløse.

Hændelsessporing registrerer, hvordan en konkret meddelelse blev til bevismateriale. Hvis vi vender tilbage til tirsdag morgens filoverførselsscenarie, bør registerposten indeholde tilstrækkelige oplysninger til at understøtte risiko-, respons- og efterlevelsesbeslutninger.

Dette er ikke bureaukrati. Det er den faktiske registrering, der dokumenterer, at organisationen har en defineret proces for modtagelse, validering, triage, eskalering og bevismateriale.

Fra meddelelse til revisionsbevismateriale: en praktisk arbejdsgang

En arbejdsgang for trusselsintelligens skal hurtigt besvare seks spørgsmål: er vi eksponeret, hvor alvorligt er det, hvad skal ændres, hvem ejer det, skal vi rapportere, og hvilket bevismateriale skal opbevares?

1. Validér eksponering og forretningspåvirkning

ISO/IEC 27001:2022 clauses 4.1 til 4.4 kræver, at ISMS afspejler organisationens faktiske kontekst, forpligtelser og afhængigheder. Den første opgave er ikke blind patchning. Det er at validere eksponering.

Spørg:

• Kører vi den berørte teknologi?
• Er den eksponeret mod internettet?
• Anvendes den af en kritisk forretningstjeneste?
• Behandler den personoplysninger?
• Drives den af en leverandør eller udbyder af administrerede tjenester?
• Er den relevant for en DORA-kritisk eller vigtig funktion?
• Er den relevant for tjenester inden for NIS2-anvendelsesområdet?
• Er der kontraktlige underretningsforpligtelser over for kunder?
• Er logfiler tilgængelige, komplette og tidssynkroniserede?

Hvis personoplysninger kan være berørt, indgår GDPR-ansvarlighed også i analysen. GDPR kræver passende behandlingssikkerhed og dokumenterbar ansvarlighed, herunder evnen til at vurdere, om der er sket et brud på persondatasikkerheden, og om underretning er påkrævet.

2. Opdater risikoregisteret

Risk Management Policy Risk Management Policy - SMV giver en enkel tidsregel i styringskrav, klausul 5.1.3:

Risici skal gennemgås kvartalsvist og opdateres, når væsentlige hændelser opstår.

En troværdig meddelelse om aktiv udnyttelse er en væsentlig hændelse. Opdateringen må ikke vente på næste kvartalsgennemgang.

Dette knytter direkte an til ISO/IEC 27001:2022 clauses 6.1.1-6.1.3. Organisationen identificerer risiko, analyserer sandsynlighed og konsekvens, prioriterer behandling, vælger kontroller, vedligeholder anvendelighedserklæringen (SoA), udarbejder en behandlingsplan og indhenter godkendelse af restrisiko.

3. Prioritér sårbarhedsbehandling ved hjælp af exploitintelligens

Zenith Blueprint, Controls in Action-fasen, Step 19, teknologiske kontroller I, forklarer, hvorfor sårbarhedsstyring er central cyberhygiejne:

Styring af sårbarheder er et af de mest kritiske områder i moderne cyberhygiejne. Selvom firewalls og antivirusværktøjer yder beskyttelse, kan de undermineres, hvis upatchede systemer eller fejlkonfigurerede tjenester efterlades eksponeret. For at opfylde denne kontrol bør organisationer implementere en struktureret og gentagelig proces til at identificere, vurdere og håndtere sårbarheder.

CVSS alene er ikke nok. En sårbarhed med middel score, som aktivt udnyttes på et internetvendt system, kan være mere hastende end en sårbarhed med høj score, der ligger skjult i et segmenteret laboratoriemiljø.

Dette skaber en juridisk forsvarlig beslutning. Det understøtter også NIS2 Article 21(2)(e) for håndtering af sårbarheder, NIS2 Article 21(2)(g) for cyberhygiejne og DORA-forventninger til IKT-risikostyring.

4. Omsæt intelligens til overvågning og detektion

Trusselsintelligens skal nå frem til logning og overvågning. Logging and Monitoring Policy Logging and Monitoring Policy - SMV fastsætter i krav til implementering af politikken, klausul 6.2.1:

Sikkerhedsværktøjer, f.eks. antivirus, firewalls og VPN’er, skal konfigureres til at generere alarmer for definerede trusselsscenarier, herunder:

Uddraget fastlægger kontrolhensigten klart: definerede trusselsscenarier skal drive alarmering.

Zenith Blueprint, Controls in Action-fasen, Step 19, beskriver overvågningsaktiviteter på denne måde:

Hvis logning er handlingen at registrere, hvad der sker i jeres miljø, er overvågning handlingen at observere, forstå og reagere på disse hændelser. Denne kontrol handler om aktivt at observere netværk, systemer og applikationer for at detektere usædvanlig aktivitet, ikke kun efterfølgende, men i realtid eller nær realtid, hvor det er muligt.

For filoverførselsscenariet skal SOC’et eller IT-udbyderen:

• Tilføje eller validere IOC’er fra CERT- og leverandørmeddelelsen.
• Søge i logfiler efter kendte exploitstier, mistænkelige uploads, web shell-indikatorer, usædvanlig procesudførelse og uventede udgående forbindelser.
• Bekræfte, at autentifikation, administratoraktivitet, filadgang, API- og netværkslogfiler opbevares.
• Justere SIEM-alarmer for exploitmønsteret.
• Oprette et sagsnotat, der forklarer, hvad der blev søgt efter, hvad der blev fundet, og hvem der gennemgik det.
• Eskalere til hændelsesklassificering, hvis indikatorer viser kompromittering, dataeksponering eller servicepåvirkning.

Det er her hændelsesrapportering bliver praktisk. NIS2 Article 23 kræver trinvis rapportering af væsentlige hændelser, herunder tidlig varsling inden for 24 timer, underretning inden for 72 timer, mellemliggende opdateringer efter anmodning og en endelig rapport senest én måned efter underretningen. DORA kræver, at finansielle enheder detekterer, styrer, klassificerer og rapporterer større IKT-relaterede hændelser gennem den trinvise proces, der er fastsat i forordningen og tilhørende tekniske standarder.

Trusselsintelligens hjælper med at afgøre, om organisationen stadig befinder sig i sårbarhedsrespons, vurdering af sikkerhedshændelse eller reguleret hændelsesrapportering.

Én arbejdsgang, flere efterlevelsesforpligtelser

Trusselsintelligens er en ideel integreret arbejdsgang for efterlevelse, fordi det samme bevismateriale understøtter flere regelsæt.

NIST CSF 2.0 er særligt nyttig til ledelseskommunikation. Dens kernefunktioner, Govern, Identify, Protect, Detect, Respond og Recover, omsætter teknisk intelligens til en fortælling, der kan forstås på bestyrelsesniveau:

• Govern: kilder til trusselsintelligens, ejere og rapporteringslinjer er defineret.
• Identify: berørte aktiver, leverandører, forretningstjenester og data er kortlagt.
• Protect: patchning, hærdning, segmentering og endpointsignaturer er opdateret.
• Detect: overvågningsregler, IOC’er og trusselsjagtopgaver er implementeret.
• Respond: hændelsesplaybooks, triageregler og underretningstærskler er gennemgået.
• Recover: backups, gendannelsesprioriteter og erfaringer er valideret.

Det omsætter rå cybertrusselsintelligens til risikostyring.

Revisors perspektiv: hvad de vil bede om

En stærk proces for trusselsintelligens skal kunne modstå forskellige revisionsstile. En ISO-revisor, NIS2-gennemgangsansvarlig, DORA-tilsynsmyndighed, NIST CSF-assessor, COBIT 2019-orienteret revisor, ISACA-professionel eller databeskyttelsesgennemgang kan bruge forskelligt sprog, men de samles alle om bevismateriale.

Zenith Controls giver den tværgående efterlevelsesfortolkning til disse drøftelser. For kontrol 8.16, overvågningsaktiviteter, forbinder guiden overvågning med GDPR-sikkerhed og ansvarlighed ved brud, NIS2-hændelseshåndtering og -rapportering samt DORA-forventninger til detektion og respons. For kontrol 8.8, styring af tekniske sårbarheder, forbinder den sårbarhedsstyring med GDPR-behandlingssikkerhed, NIS2 Article 21(2)(e) og proaktiv DORA-styring af IKT-risiko.

Det er denne konvergens i bevismateriale, revisorer vil se.

Ledelsesrapportering: den kvartalsvise briefing om trusselstendenser

Registeret over trusselsintelligens må ikke dø i SOC’et. Zenith Blueprint anbefaler en kort kvartalsvis briefing om trusselstendenser til nøgleinteressenter. Clarysec anbefaler en én-sides ledelsesrapport med fem afsnit:

1. De tre mest relevante trusselstendenser efter forretningspåvirkning.
2. Mest eksponerede teknologier eller leverandører.
3. Kritiske sårbarheder, der er patchet, afbødet eller accepteret.
4. Forbedringer af detektion og respons.
5. Beslutninger, der kræves fra ledelsen.

En stærk ledelsesbriefing oplister ikke 400 CVE’er. Den forklarer risikobevægelse. For eksempel:

• Ransomware rettet mod udbydere af administrerede tjenester øgede prioriteten for leverandørgennemgang.
• Udnyttelse af filoverførselsplatforme udløste nødpatchning og en kompenserende firewallregel.
• Angreb på cloudidentiteter medførte gennemgang af MFA-undtagelser og hærdning af betinget adgang.
• Sektor-ISAC-intelligens førte til nye phishing-simuleringer for økonomi- og supportteams.
• DORA-kortlægning af kritiske funktioner afslørede ét overvågningshul i en tredjepartsarbejdsgang.

Denne briefing understøtter NIS2-ledelsesansvar, DORA-styring af IKT-risiko, ISO/IEC 27001:2022-ledelsens gennemgang og kundedokumentation.

Almindelige svigtmønstre

Programmer for trusselsintelligens ser ofte modne ud på slides, men står svagt ved revision. De mest almindelige svigtmønstre er:

• For mange feeds og ingen valideringskriterier.
• Ingen kobling mellem intelligens og aktivfortegnelse.
• Ingen dokumenteret risikoopdatering efter større meddelelser.
• Patchprioritet baseret alene på scannerens alvorlighed.
• Leverandørmeddelelser håndteres uden for ISMS.
• SOC-regler opdateres uden ændringsregistreringer.
• Hændelsestærskler er ikke tilpasset NIS2- eller DORA-rapporteringsarbejdsgange.
• Bestyrelsesrapportering fokuserer på alarmvolumen i stedet for forretningsrisiko.
• Intet bevismateriale for, at erfaringer har ændret kontroller.
• Ingen ejer for vedligeholdelse af registeret over trusselsintelligens.

Løsningen er ikke at købe endnu et feed. Løsningen er kontrolintegration.

En 10-punkts tjekliste for beredskab i 2026

Brug denne tjekliste som en praktisk intern gennemgang.

Hvis svaret på et af disse spørgsmål er “nej,” har organisationen ikke blot et problem med trusselsintelligens. Den har et problem med ISMS-integration.

Hvordan Clarysec hjælper med at omsætte trusselsintelligens til bevismateriale

Clarysecs metode er designet til organisationer, der har brug for praktisk sikkerhed og troværdig efterlevelse på samme tid.

Zenith Blueprint giver den 30-trins implementeringsrute, herunder Step 22 for registeret over trusselsintelligens og Step 19 for sårbarhedsstyring og overvågningsaktiviteter. Clarysecs enterprise- og SMV-politikker omsætter disse forventninger til rollebaserede procedurer for risikostyring, sårbarhedsstyring, endpoint-beskyttelse, logning, overvågning og revisionsbevismateriale. Zenith Controls giver derefter den tværgående efterlevelsesfortolkning og viser, hvordan ISO/IEC 27002:2022-kontroller forbindes med NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 og revisionsbevismateriale.

For tirsdag morgens CISO bliver svaret til CFO’en klart:

“Vi modtog meddelelsen, validerede eksponeringen, opdaterede risikoregisteret, prioriterede patchning baseret på aktiv udnyttelse, justerede overvågningen, kontrollerede leverandørafhængigheden, vurderede tærskler for hændelsesrapportering, briefede ledelsen og opbevarede bevismateriale. Vi gætter ikke. Vi følger vores ISMS.”

Sådan bør trusselsintelligens i ISO 27001 til NIS2-cyberhygiejne og DORA-dokumentation for IKT-risiko se ud i 2026.

Næste skridt

Hvis jeres organisation modtager trusselsintelligens, men ikke kan dokumentere, hvordan den ændrer risikobeslutninger, kontroller, detektion, hændelseshåndtering, leverandørstyring og regulatorisk bevismateriale, så start med tre handlinger i denne uge:

1. Opbyg eller opdater jeres register over trusselsintelligens med Zenith Blueprint, Controls in Action-fasen, Step 22.
2. Kortlæg jeres nuværende proces mod ISO/IEC 27002:2022-kontrollerne 5.7, 8.8, 8.15, 8.16, 8.7 og 5.25 med Zenith Controls.
3. Tilpas jeres politikker, især Risk Management Policy, Vulnerability and Patch Management Policy, Logging and Monitoring Policy og Audit and Compliance Monitoring Policy, så hver meddelelse kan blive til juridisk forsvarligt bevismateriale.

Clarysec kan hjælpe jer med at omsætte trusselsfeeds, meddelelser, leverandørmeddelelser, sårbarhedsintelligens og detektionssignaler til en driftsmodel, der er tilpasset ISO/IEC 27001:2022, klar til NIS2 og bevidst om DORA.

Download Clarysec-værktøjssættene, anmod om en gennemgang, eller book en beredskabsvurdering for at se, hvordan jeres nuværende proces for trusselsintelligens vil klare sig over for en ISO-revisor, NIS2-gennemgangsansvarlig, DORA-tilsynsmyndighed eller kundes anmodning om dokumentation.