Styring af CISA KEV for ISO 27001, NIS2 og DORA

Fredagssårbarheden, der blev et bestyrelsesanliggende

Klokken er 16:40 en fredag. Din SOC-leder videresender en CISA KEV-alarm, sårbarhedsscanneren bekræfter eksponering på en internetvendt gateway, og ENISA EUVD har en tilsvarende registrering af en udnyttet sårbarhed. Leverandøren har frigivet en patch, men den produktionsansvarlige advarer om, at øjeblikkelig implementering kan forstyrre en kundevendt tjeneste. Jura spørger, om personoplysninger kan være berørt. Den DORA-ansvarlige spørger, om platformen understøtter en kritisk eller vigtig funktion. NIS2-koordinatoren spørger, om dette kan udvikle sig til en væsentlig hændelse.

CISO’en stiller det eneste spørgsmål, der betyder noget:

“Kan vi dokumentere, at vi traf den rigtige beslutning hurtigt nok og med de rette godkendelser?”

Det er den reelle udfordring ved styring af kendte udnyttede sårbarheder i 2026. Det handler ikke kun om at identificere CVE’er eller presse patches hurtigere igennem. Det handler om at omsætte efterretninger om aktiv udnyttelse til en forsvarlig driftsmodel: modtagelse, triage, prioritering, nødændring, kompenserende kontroller, leverandøreskalering, godkendelse af undtagelser, opbevaring af bevismateriale, ledelsesrapportering og afhjælpningsbeslutninger, der kan fremlægges for tilsynsmyndigheder.

Mange organisationer har allerede SLA’er for sårbarheder. Nogle har feeds med trusselsintelligens. Enkelte arbejder med løbende eksponeringsstyring. Men når en sårbarhed allerede udnyttes aktivt, ændres risikokonteksten. En kendt udnyttet sårbarhed, der er opført i CISA KEV eller ENISA EUVD, skal ikke ligge i samme kø som en almindelig patchbacklog. Den skal udløse et særskilt styringsspor, fordi risikoen ikke længere er teoretisk.

Clarysecs synspunkt er enkelt: afhjælpning baseret på aktiv udnyttelse skal styres som en forretningsproces, der producerer bevismateriale, ikke som uformel teknisk brandslukning. Processen kan bygges på ISO/IEC 27001:2022 ISO/IEC 27001:2022, understøttes af ISO/IEC 27002:2022 ISO/IEC 27002:2022 og kortlægges på tværs af styringsforventningerne i NIS2, DORA, GDPR, NIST CSF 2.0 og COBIT 19.

Fra patchning til dokumenterbar styring

Traditionel sårbarhedsstyring starter ofte med alvorlighed: CVSS-score, aktivets kritikalitet, eksponering og tilgængelighed af patch. Styring baseret på aktiv udnyttelse tilføjer et skarpere spørgsmål: bliver denne sårbarhed allerede brugt af angribere, og har vi berørte aktiver, leverandører, cloudtjenester eller dataflows?

Den ændring påvirker arbejdsgangen. En kendt udnyttet sårbarhed skal udløse:

1. Validering af trusselsintelligens fra betroede kilder såsom CISA, ENISA, nationale CERT’er, leverandører, ISAC’er og MSSP’er.
2. Korrelation til aktiver, herunder interneteksponering, forretningsfunktion, dataklassificering og leverandørafhængighed.
3. Akut risikobeslutning, herunder patch nu, isolér, deaktivér funktion, anvend workaround, overvåg eller acceptér midlertidigt restrisiko.
4. Ændringsgodkendelse med sporbarhed, også når ændringen fremskyndes.
5. Indsamling af bevismateriale, herunder tidsstempler, godkendelser, logfiler, skærmbilleder, scanningsresultater, leverandørudtalelser og registreringer af kompenserende kontroller.
6. Ledelsesrapportering, især når sårbarheden påvirker kritiske tjenester, personoplysninger, regulerede finansielle tjenester eller væsentlige eller vigtige tjenester omfattet af NIS2.
7. Validering efter afhjælpning og opsamling af læring.

ISO 27001:2022 giver denne arbejdsgang et styringsmæssigt skelet. Klausul 4.1 til 4.4 kræver, at organisationen forstår interne og eksterne forhold, interessenter, juridiske og regulatoriske krav, grænseflader og afhængigheder og derefter definerer og vedligeholder ISMS-omfanget. I sårbarhedsstyring betyder det, at omfanget skal omfatte de faktiske systemer, cloudtjenester, tredjeparter og regulerede tjenester, hvor eksponering for udnyttede sårbarheder kan skabe forretningsmæssig påvirkning.

Klausul 5.1 til 5.3 flytter problemstillingen ud over IT-drift. Øverste ledelse skal afstemme ISMS’et med den strategiske retning, tildele ansvar, allokere ressourcer, kommunikere vigtigheden af efterlevelse og modtage rapportering om resultater. I praksis er et CISA KEV-match på en kritisk tjeneste ikke kun en patchsag. Det er et forhold, der udløser ledelsesmæssig ansvarlighed.

Klausul 6.1.1 til 6.1.3 udgør rygraden i risikostyringen: risikokriterier, risikoejere, vurdering af sandsynlighed og konsekvens, behandlingsmuligheder, Anvendelseserklæring, behandlingsplan og accept af restrisiko. Det er den mekanisme, der omsætter “vi kunne ikke patche endnu” til en dokumenteret, godkendt og tidsbegrænset undtagelse med kompenserende kontroller.

Klausul 8.1 bliver derefter afgørende, når teamet går fra beslutning til udførelse. Den kræver operationel planlægning og styring, herunder styring af planlagte ændringer og gennemgang af utilsigtede ændringer. I en KEV-sag skal organisationen handle hurtigt uden at miste kontrollen.

Clarysecs kontroltrekant for udnyttede sårbarheder

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls behandler styring af kendte udnyttede sårbarheder som en kombination af tre centrale kontroltemaer i ISO/IEC 27002:2022. Den angiver de emnerelaterede kontroller som “Threat intelligence (5.7)”, “Management of Technical Vulnerabilities (8.8)” og “Change Management (8.32)”.

Tilsammen danner disse kontroller en praktisk trekant:

Denne trekant forebygger en almindelig revisionssvaghed: at behandle sårbarhedsstyring som output fra en scanner i stedet for som en styret beslutningskæde. En revisor, tilsynsmyndighed eller kundesikringsfunktion vil ikke kun spørge, om en patch blev installeret. De vil spørge, hvordan organisationen blev opmærksom på forholdet, prioriterede, godkendte, implementerede og verificerede beslutningen.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint gør dette konkret i fasen Controls in Action, Step 22, hvor teams instrueres i at opbygge et register over trusselsintelligens:

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

I Step 19 beskriver Zenith Blueprint sårbarhedsstyring som moderne cyberhygiejne og understreger fremskyndet afhjælpning af kritiske sårbarheder:

Styring af sårbarheder er et af de mest kritiske områder i moderne cyberhygiejne. Selvom firewalls og antivirusværktøjer giver beskyttelse, kan de undergraves, hvis upatchede systemer eller fejlkonfigurerede tjenester efterlades eksponeret.

Den advarer også om, at scanningsfund ikke må arkiveres passivt. De skal triageres, tildeles og følges til lukning. Det er præcis den disciplin, som styring af CISA KEV og ENISA EUVD kræver.

Politikken omsætter hastværk til regler

En styringsmodel virker kun, når den er afspejlet i politikken. Clarysecs Enterprise Politik for sårbarheds- og patchstyring Politik for sårbarheds- og patchstyring, der i toolkit-sammenhænge også omtales som P19 Politik for sårbarheds- og patchstyring, placerer kravet om overvågning og eskalering klart:

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

Fra afsnittet “Roller og ansvar”, politikklausul 4.5.1.

Den samme Enterprise-politik fastsætter en skærpet forventning til afhjælpning af kritiske sårbarheder:

Kritisk (CVSS 9.0-10.0): Øjeblikkelig gennemgang; patchfrist på maksimalt 72 timer.

Fra afsnittet “Styringskrav”, politikklausul 5.2.1.

For SMV’er gør Clarysecs Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, også omtalt som P19S Vulnerability and Patch Management Policy-sme, det samme koncept operationelt og direkte:

Betroede trusselsmeddelelser (f.eks. CISA, ENISA og alarmer fra nationale CERT’er)

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.2.1.3.

Den fastsætter også den praktiske patchstandard:

Kritiske patches skal installeres senest 3 dage efter frigivelse, især for internetvendte systemer

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.1.1.

Formuleringen “især for internetvendte systemer” er vigtig. Styring af kendte udnyttede sårbarheder skal prioritere eksponerede systemer, fjernadgangstjenester, identitetsinfrastruktur, edge-enheder, SaaS-administrationspaneler og systemer, der behandler følsomme eller regulerede data.

Men hvad sker der, når forretningen ikke kan patche inden for SLA’en? Enterprise-politikken lukker kredsløbet:

Hvis en sårbarhed ikke kan afhjælpes inden for de definerede SLA’er på grund af driftsmæssige, tekniske eller leverandørmæssige begrænsninger, skal der indsendes en formel undtagelsesanmodning.

Fra afsnittet “Risikobehandling og undtagelser”, politikklausul 7.1.

SMV-versionen kræver patchlogfiler, der understøtter revisionsbarhed:

Logfiler skal indeholde enhedens navn, den anvendte opdatering, patchdatoen og årsagen til eventuel forsinkelse

Fra afsnittet “Styringskrav”, politikklausul 5.4.2.

Disse politikklausuler skaber rygraden i bevismaterialet. De gør det muligt for CISO’en at sige: Vi har regler for modtagelse af intelligens, prioritering, patchfrister, undtagelser og begrundelser for forsinkelser. Det er forskellen mellem reaktiv patchning og styret afhjælpning.

Nødændring uden at miste kontrollen

Kendte udnyttede sårbarheder tvinger ofte nødændringer igennem. At vente på næste møde i ændringsrådet kan være uforsvarligt. At omgå ændringsstyring helt kan være lige så uforsvarligt. Svaret er fremskyndet og sporbar ændringskontrol.

Clarysecs Enterprise Politik for ændringsstyring Politik for ændringsstyring, der også omtales som P05 Ændringsstyringspolitik, fastslår:

Nødændringer kan gennemføres med fremskyndet mundtlig eller delegeret godkendelse fra autoriserede roller.

Fra afsnittet “Krav til implementering af politikken”, politikklausul 6.5.1.

For SMV’er anerkender Clarysecs Politik for ændringsstyring Politik for ændringsstyring - SME samme driftsmæssige realitet:

Nødændringer eller ikke-planlagte ændringer kan implementeres straks som reaktion på kritiske driftsafbrydelser eller trusler. Dog:

Fra afsnittet “Risikobehandling og undtagelser”, politikklausul 7.4.1.

Ordet “dog” er dér, styringen lever. En nødændring skal stadig dokumentere udløseren, berørte systemer, risikobeslutningen, godkenderen, implementeringstidspunktet, valideringsresultatet og den retrospektive gennemgang. Zenith Blueprint, fasen Controls in Action, Step 21, beskriver ændringsstyring som en gentagelig arbejdsgang, hvor ændringer vurderes, godkendes, implementeres og gennemgås. Den advarer om, at mange hændelser ikke skyldes angribere, men fejlstyrede ændringer: en firewallregel, der er åbnet for bredt, en debugindstilling, der er efterladt aktiveret, eller en glemt afhængighed efter en migrering.

Ved afhjælpning af kendte udnyttede sårbarheder skal minimumsbevismaterialet for nødændringer omfatte:

Dette er ikke bureaukrati. Det er det mindst nødvendige revisionsspor for en beslutning truffet under pres fra en aktiv trussel.

Kortlægning af CISA KEV og ENISA EUVD til ISO 27001-bevismateriale

ISO 27001:2022 kræver ikke en bestemt kilde til trusselsintelligens. Standarden kræver, at organisationen identificerer krav, styrer risiko, implementerer kontroller, opbevarer dokumenteret information og forbedrer sig. CISA KEV og ENISA EUVD kan blive autoritative input til dette ledelsessystem.

Zenith Blueprint, fasen Risk Management, Step 13, anbefaler sporbarhed mellem risici, kontroller og klausuler:

Krydsreferér regler: Hvis bestemte kontroller implementeres specifikt for at overholde GDPR, NIS2 eller DORA, kan du notere det enten i risikoregisteret (som en del af begrundelsen for risikokonsekvensen) eller i SoA-noterne.

For en kendt udnyttet sårbarhed skal posten i risikoregisteret ikke blot sige “Patch CVE”. Den skal identificere trusselskilden, den berørte tjeneste, regulatorisk relevans, risikoejer, behandling, kontrolreferencer og placering af bevismateriale.

Tværgående efterlevelseskortlægning for NIS2, DORA, GDPR og styringsrapportering

Værdien af styring baseret på aktiv udnyttelse er, at én kontrolleret arbejdsgang kan besvare flere regulatoriske spørgsmål. Den samme sag, ændringsregistrering, undtagelsesformular, leverandørmail og valideringsscanning kan understøtte forskellige bevisgrundlag, når de kortlægges bevidst.

NIS2 ændrer samtalen for væsentlige og vigtige enheder, fordi Article 20 gør cybersikkerhed til et ansvar for ledelsesorganet. Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, håndtering og offentliggørelse af sårbarheder, cyberhygiejne, adgangsstyring, aktivstyring og autentifikation.

Article 23 tilføjer trinvis rapportering af væsentlige hændelser, herunder tidlig advarsel inden for 24 timer, underretning inden for 72 timer og slutrapport inden for én måned efter hændelsesunderretningen. Et CISA KEV- eller ENISA EUVD-match er ikke automatisk en rapporteringspligtig hændelse. Men det skal udløse en dokumenteret hændelsesvurdering, når udnyttelse, driftsafbrydelse, kundeskade eller datapåvirkning er sandsynlig.

DORA tilføjer et sektorspecifikt perspektiv for finansielle enheder. Den finder anvendelse fra 17. januar 2025 og kræver governance, dokumenteret styring af IKT-risiko, test, robusthed, hændelsesstyring og kontrol med IKT-tredjepartsrisiko. Article 13 er særligt relevant, fordi den kræver kapaciteter vedrørende sårbarheder og cybertrusselsintelligens, læring og overvågning af teknologisk udvikling. Article 17 kræver en proces for styring af IKT-relaterede hændelser, der registrerer hændelser og væsentlige cybertrusler, klassificerer efter prioritet og alvorlighed, eskalerer, identificerer rodårsager og genetablerer sikker drift.

DORA Articles 28 og 30 fremtvinger også leverandørdisciplin. Hvis en betalingsplatform afhænger af en cloud-WAF, en administreret database, en identitetsudbyder eller en SaaS-workflowmotor, der er berørt af en kendt udnyttet sårbarhed, kan bevismaterialet ikke stoppe ved “leverandøren siger, at der er patchet”. Det skal omfatte leverandørunderretning, kritikalitetsvurdering, anvendte kontraktrettigheder, kompenserende kontroller, vurdering af kundepåvirkning og verifikation efter afhjælpning.

GDPR tilføjer det datacentrerede spørgsmål. Article 32 kræver behandlingssikkerhed, mens Article 5(2) fastlægger ansvarlighed. Privatlivsgennemgangen skal starte før et bekræftet brud, ikke først når eksfiltrering er bevist.

En praktisk afhjælpningsregistrering for KEV og EUVD

Forestil dig et realistisk scenarie. ENISA EUVD og CISA KEV indikerer aktiv udnyttelse af en sårbarhed, der påvirker en internetvendt filoverførselstjeneste. Tjenesten understøtter kundeonboarding og lagrer begrænsede personoplysninger. Der findes en leverandørpatch, men applikationsejeren anmoder om et vedligeholdelsesvindue, og én relateret SaaS-komponent afhænger af leverandørafhjælpning.

Opret én registrering i sårbarhedsstyringsregisteret med disse felter:

Anvend derefter Clarysecs politikregler:

• Brug Enterprise Politik for sårbarheds- og patchstyring, hvis du driver en større organisation med formelle roller, SLA’er og eskalering.
• Brug SMV Vulnerability and Patch Management Policy-sme, hvis du har brug for en letvægtsmodel, der stadig kan revideres.
• Brug Enterprise Politik for ændringsstyring eller SMV Politik for ændringsstyring til at dokumentere nødgodkendelse, test, udrulning og retrospektiv gennemgang.
• Link registreringen til risikoregisteret og Anvendelseserklæring som anbefalet i Zenith Blueprint, Step 13.
• Tag kontrollerne i Zenith Controls som 5.7, 8.8 og 8.32, og tilføj derefter understøttende bevismateriale for leverandørstyring, cloudstyring, logning, hændelsesstyring og forretningskontinuitet, hvor det er relevant.

Til sidst skal revisionsbevismaterialet bevares. Clarysecs Enterprise Politik for revisions- og efterlevelsesovervågning Politik for revisions- og efterlevelsesovervågning, der også omtales som P33 Audit and Compliance Monitoring Policy, definerer et eksplicit mål:

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

Fra afsnittet “Mål”, politikklausul 3.4.

Det er formålet med arbejdsgangen. Du afhjælper ikke kun en sårbarhed. Du producerer forsvarligt bevismateriale for, at organisationen handlede forholdsmæssigt, rettidigt og under kontrol.

Hvordan revisorer vil teste den samme KEV-beslutning

En moden proces for kendte udnyttede sårbarheder skal kunne modstå forskellige revisionsperspektiver.

En ISO 27001:2022-revisor vil starte med ISMS-omfanget, interessenter, regulatoriske forpligtelser, risikovurderingsmetodik, Anvendelseserklæring og dokumenteret information. Revisoren vil spørge, om trusselsintelligens er integreret i risikovurderingen, om sårbarhedsstyring er gentagelig, om nødændringer er kontrollerede, om restrisiko accepteres af den rette risikoejer, og om bevismateriale opbevares.

En NIS2-orienteret vurderingspart vil fokusere på ledelsesansvar, risikostyringsforanstaltninger efter Article 21, leverandørsårbarheder, hændelseshåndtering, forretningskontinuitet og vurdering af væsentlige hændelser efter Article 23. De vil lægge vægt på tidsstempler, eskalering, beslutningsregistreringer og om ledelsesorganer blev informeret, hvor det var relevant.

En DORA-revisor eller kompetent myndighed vil spørge, om styringsrammen for IKT-risikostyring omfattede det berørte aktiv, forretningsfunktionen, afhængigheden og tredjepartstjenesten. De vil forvente hændelsesklassificering, registreringer af væsentlige cybertrusler, ledelseseskalering, opfølgning på rodårsager, leverandørbevismateriale, test og sporing af afhjælpning.

En GDPR-gennemgang vil spørge, om personoplysninger var involveret, om fortrolighed, integritet eller tilgængelighed kunne være påvirket, hvilke tekniske og organisatoriske foranstaltninger der var på plads, om underretning om brud blev vurderet, og om der findes bevismateriale for ansvarlighed.

En NIST CSF 2.0-vurderingspart kan bruge CSF Core og Profiles til at teste, om resultater for styring, identifikation, beskyttelse, detektion, respons og genopretning er defineret og målt. En praktisk målprofil kunne lyde: “Alle kendte udnyttede sårbarheder, der påvirker internetvendte kritiske aktiver, triageres inden for 24 timer, behandles inden for 72 timer eller undtages formelt med kompenserende kontroller og godkendelse fra risikoejer.”

En COBIT 19-revisor vil spørge, hvem der er ansvarlig, om styringsmål er defineret, om risikovillighed driver hastigheden, om resultatindikatorer gennemgås, om undtagelser overvåges, og om assurance-funktioner tester processen uafhængigt.

Den samme bevisregistrering skal kunne besvare dem alle. Det er værdien af tværgående compliance-engineering.

Metrikker bestyrelsen skal se

Bestyrelser har ikke behov for en liste over alle CVE’er. De har behov for beslutningsegnede metrikker, der viser eksponering, reaktionsevne og restrisiko. For styring af kendte udnyttede sårbarheder anbefaler Clarysec en kortfattet ledelsesrapport med:

Disse metrikker understøtter ISO 27001 ledelsens gennemgang, NIS2-ledelsesansvar, DORA IKT-risikorapportering og NIST CSF-styringskommunikation. De hjælper også forretningsejere med at forstå, hvorfor patchkapacitet, kvaliteten af aktivfortegnelsen, leverandørkontrakter og vedligeholdelsesvinduer ikke er “IT-detaljer”. De er beslutninger om robusthed.

Almindelige fejlmønstre, der skal fjernes

I Clarysecs vurderinger fejler styring af kendte udnyttede sårbarheder typisk på forudsigelige måder.

For det første er intelligenskilderne uformelle. Én sikkerhedsingeniør følger CISA KEV, en anden følger leverandørbulletiner, og en tredje baserer sig på scanneroutput. Der findes ikke et dokumenteret register over trusselsintelligens, ingen valideringsregel og intet ejerskab.

For det andet er aktivkorrelationen svag. Organisationen ved, at en CVE findes, men kan ikke hurtigt identificere, hvor produktet kører, om det er internetvendt, hvem der ejer det, hvilke data det behandler, eller hvilken leverandør der administrerer det.

For det tredje er nødændring enten for langsom eller for ukontrolleret. Teams venter i dagevis på godkendelse, eller de patcher produktionsmiljøet uden tilbagerulningsnotater, validering eller retrospektiv gennemgang.

For det fjerde er undtagelser uklare. “Kan ikke patche på grund af forretningspåvirkning” er ikke en risikoaccept. En korrekt undtagelse skal definere begrænsningen, berørte aktiver, kompenserende kontroller, restrisiko, godkender, udløbsdato og gennemgangsfrekvens.

For det femte er bevismaterialet spredt. Scannerskærmbilleder, chatgodkendelser, leverandørmails, SIEM-forespørgsler og ændringsregistreringer ligger forskellige steder. Under en revision eller regulatorisk forespørgsel kan organisationen ikke rekonstruere beslutningens tidslinje.

Løsningen er ikke mere støj. Det er én samlet styringsarbejdsgang baseret på aktiv udnyttelse, der integrerer processer for intelligens, risiko, ændring, hændelser, leverandører og bevismateriale.

Byg din bevismotor til aktivt udnyttede sårbarheder

Kendte udnyttede sårbarheder vil fortsat være et driftsmæssigt problem med høj volumen i 2026. CISA KEV og ENISA EUVD gør intelligens om udnyttelse mere synlig, men synlighed alene opfylder ikke forventningerne til bevismateriale i ISO 27001:2022, NIS2, DORA eller GDPR. Du har brug for en styret proces, der omsætter intelligens til handling og handling til dokumentation.

Start med fire tiltag:

1. Opbyg et register over trusselsintelligens med Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, fasen Controls in Action, Step 22.
2. Afstem politikregler med Clarysecs Politik for sårbarheds- og patchstyring Politik for sårbarheds- og patchstyring eller Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME.
3. Brug Zenith Controls: The Cross-Compliance Guide Zenith Controls til at kortlægge 5.7 Trusselsintelligens, 8.8 Styring af tekniske sårbarheder og 8.32 Ændringsstyring til bevisbehov for ISO, NIS2, DORA, GDPR, NIST og COBIT.
4. Test én reel KEV- eller EUVD-sag fra ende til anden, fra modtagelse til afhjælpning, undtagelseshåndtering, nødændring, validering og ledelsesrapportering.

Clarysec kan hjælpe dig med at omsætte dette til en fungerende, revisionsklar driftsmodel: politikker, registre, skabeloner til bevismateriale, tværgående efterlevelseskortlægninger og rapportering til bestyrelsesniveau, der gør afhjælpning baseret på aktiv udnyttelse forsvarlig over for revisoren, tilsynsmyndigheden og dine kunder.

Download Zenith Blueprint, udforsk Zenith Controls, eller anmod om en Clarysec-parathedsvurdering for at opbygge din arbejdsgang for styring af CISA KEV og ENISA EUVD, før den næste fredagssårbarhed bliver et bestyrelsesanliggende.