Upravljanje CISA KEV-om za ISO 27001, NIS2 i DORA

Ranjivost petkom koja je postala pitanje za upravu

Petak je, 16:40. Voditelj SOC-a prosljeđuje upozorenje CISA KEV-a, skener ranjivosti potvrđuje izloženost na pristupniku dostupnom s interneta, a ENISA EUVD sadrži odgovarajući zapis o iskorištavanoj ranjivosti. Dobavljač je objavio zakrpu, ali vlasnik produkcijskog okruženja upozorava da bi njezina trenutačna primjena mogla poremetiti uslugu dostupnu klijentima. Pravni odjel pita mogu li biti pogođeni osobni podaci. Voditelj za DORA pita podržava li platforma kritičnu ili važnu funkciju. Koordinator za NIS2 pita može li to postati značajan incident.

CISO postavlja jedino pitanje koje je važno:

“Možemo li dokazati da smo donijeli ispravnu odluku, dovoljno brzo i uz odgovarajuća odobrenja?”

To je stvarni problem upravljanja poznatim iskorištavanim ranjivostima u 2026. Nije riječ samo o identificiranju CVE-ova ili bržem uvođenju zakrpa. Riječ je o pretvaranju obavještajnih podataka o iskorištavanju u dokaziv operativni model: zaprimanje, trijažu, prioritizaciju, hitnu promjenu, kompenzacijske kontrole, eskalaciju prema dobavljaču, odobrenje iznimke, čuvanje dokaza, izvješćivanje uprave i odluke o otklanjanju spremne za regulatorni nadzor.

Mnoge organizacije već imaju SLA-ove za ranjivosti. Neke imaju izvore obavještajnih podataka o prijetnjama. Manji broj provodi kontinuirano upravljanje izloženošću. No kada se ranjivost već iskorištava u stvarnom okruženju, kontekst rizika se mijenja. Poznata iskorištavana ranjivost navedena u CISA KEV-u ili ENISA EUVD-u ne smije stajati u istom redu čekanja kao redovni zaostatak zakrpa. Mora pokrenuti drukčiji upravljački put jer rizik više nije teorijski.

Stajalište Claryseca je jednostavno: otklanjanjem vođenim iskorištavanjem treba upravljati kao poslovnim procesom koji proizvodi dokaze, a ne kao neformalnom tehničkom improvizacijom. Taj se proces može izgraditi na ISO/IEC 27001:2022 ISO/IEC 27001:2022, ojačati standardom ISO/IEC 27002:2022 ISO/IEC 27002:2022 i mapirati na upravljačka očekivanja NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 19.

Od zakrpavanja do dokazivog upravljanja

Tradicionalno upravljanje ranjivostima često počinje ozbiljnošću: CVSS ocjenom, kritičnošću imovine, izloženošću i dostupnošću zakrpe. Upravljanje vođeno iskorištavanjem dodaje preciznije pitanje: iskorištavaju li napadači ovu ranjivost već sada i imamo li pogođenu imovinu, dobavljače, usluge u oblaku ili tokove podataka?

Taj pomak mijenja tijek rada. Poznata iskorištavana ranjivost mora pokrenuti:

1. Provjeru obavještajnih podataka o prijetnjama iz pouzdanih izvora kao što su CISA, ENISA, nacionalni CERT-ovi, dobavljači, ISAC-i i MSSP-ovi.
2. Korelaciju imovine, uključujući izloženost internetu, poslovnu funkciju, klasifikaciju podataka i ovisnosti o dobavljačima.
3. Hitno odlučivanje o riziku, uključujući trenutačno zakrpavanje, izolaciju, onemogućavanje funkcije, primjenu zaobilaznog rješenja, praćenje ili privremeno prihvaćanje preostalog rizika.
4. Odobrenje promjene uz sljedivost, čak i kada se promjena provodi ubrzano.
5. Prikupljanje dokaza, uključujući vremenske oznake, odobrenja, zapise dnevnika, snimke zaslona, rezultate skeniranja, izjave dobavljača i zapise o kompenzacijskim kontrolama.
6. Izvješćivanje uprave, osobito kada ranjivost utječe na kritične usluge, osobne podatke, regulirane financijske usluge ili ključne odnosno važne usluge prema NIS2.
7. Provjeru nakon otklanjanja i naučene lekcije.

ISO 27001:2022 ovom tijeku rada daje upravljačku osnovu. Točke 4.1 do 4.4 zahtijevaju da organizacija razumije interna i vanjska pitanja, zainteresirane strane, pravne i regulatorne zahtjeve, sučelja i ovisnosti te zatim definira i održava opseg ISMS-a. U upravljanju ranjivostima to znači da opseg mora obuhvatiti stvarne sustave, usluge u oblaku, treće strane i regulirane usluge u kojima izloženost iskorištavanoj ranjivosti može stvoriti poslovni učinak.

Točke 5.1 do 5.3 pomiču problem izvan IT operacija. Najviše rukovodstvo mora uskladiti ISMS sa strateškim smjerom, dodijeliti odgovornosti, osigurati resurse, komunicirati važnost usklađenosti i primati izvješća o učinkovitosti. U praksi, podudaranje s CISA KEV-om na kritičnoj usluzi nije samo tiket za zakrpu. To je događaj koji aktivira izvršnu odgovornost.

Točke 6.1.1 do 6.1.3 daju osnovu za rizik: kriterije rizika, vlasnike rizika, procjenu vjerojatnosti i posljedica, mogućnosti obrade, Izjavu o primjenjivosti, plan obrade i prihvaćanje preostalog rizika. To je mehanizam koji rečenicu “još nismo mogli primijeniti zakrpu” pretvara u dokumentiranu, odobrenu i vremenski ograničenu iznimku s kompenzacijskim kontrolama.

Točka 8.1 postaje važna kada tim prelazi s odluke na izvršenje. Ona zahtijeva operativno planiranje i kontrolu, uključujući kontrolu planiranih promjena i pregled nenamjernih promjena. U KEV događaju organizacija mora biti brza, ali ne smije izgubiti kontrolu.

Clarysecov trokut kontrola za iskorištavane ranjivosti

Clarysecov Zenith Controls: The Cross-Compliance Guide Zenith Controls upravljanje poznatim iskorištavanim ranjivostima promatra kao kombinaciju triju središnjih tema kontrola prema ISO/IEC 27002:2022. Navodi povezane kontrole kao “Obavještajni podaci o prijetnjama (5.7)”, “Upravljanje tehničkim ranjivostima (8.8)” i “Upravljanje promjenama (8.32)”.

Zajedno te kontrole čine praktičan trokut:

Ovaj trokut sprječava čest revizijski neuspjeh: tretiranje upravljanja ranjivostima kao izlaza skenera umjesto kao uređenog lanca odluka. Revizor, regulator ili tim za dokazivanje sigurnosti prema zahtjevima klijenata neće pitati samo je li zakrpa primijenjena. Pitat će kako je organizacija saznala za ranjivost, kako ju je prioritizirala, odobrila, provela i provjerila odluku.

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint to konkretizira u fazi Kontrole u praksi, korak 22, gdje timovima nalaže izradu registra obavještajnih podataka o prijetnjama:

Uspostavite dokumentirani popis izvora obavještajnih podataka o prijetnjama (5.7), od dobavljača, ISAC-a ili otvorenih izvora, te odredite kako se obavještajni podaci provjeravaju i integriraju u donošenje odluka. Definirajte tko prima ažuriranja o prijetnjama i kako se ona primjenjuju (npr. prioritizacija zakrpa, obuka za podizanje svijesti).

U koraku 19, Zenith Blueprint postavlja upravljanje ranjivostima kao suvremenu kibernetičku higijenu i naglašava ubrzano otklanjanje kritičnih ranjivosti:

Upravljanje ranjivostima jedno je od najkritičnijih područja suvremene kibernetičke higijene. Iako vatrozidi i antivirusni softver pružaju zaštitu, mogu biti dovedeni u pitanje ako nezakrpani sustavi ili pogrešno konfigurirane usluge ostanu izloženi.

Također upozorava da se nalazi skeniranja ne smiju pasivno arhivirati. Moraju se trijažirati, dodijeliti odgovornim osobama i pratiti do zatvaranja. Upravo je ta disciplina potrebna za upravljanje CISA KEV-om i ENISA EUVD-om.

Politika pretvara hitnost u pravila

Model upravljanja funkcionira samo kada je odražen u politici. Clarysecova Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy, koja se u kontekstu alata navodi i kao P19 Vulnerability and Patch Management Policy, jasno dodjeljuje zahtjev za praćenje i eskalaciju:

Pratiti obavijesti o prijetnjama i ranjivostima (npr. CVE, CISA KEV, biltene dobavljača) i eskalirati kritične ranjivosti.

Iz odjeljka “Uloge i odgovornosti”, točka politike 4.5.1.

Ista politika za velike organizacije definira strogo očekivanje otklanjanja kritičnih ranjivosti:

Kritično (CVSS 9.0-10.0): trenutačni pregled; krajnji rok zakrpavanja najviše 72 sata.

Iz odjeljka “Zahtjevi upravljanja”, točka politike 5.2.1.

Za MSP-ove, Clarysecova Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME, koja se navodi i kao P19S Vulnerability and Patch Management Policy-sme, isti koncept čini operativnim i izravnim:

Pouzdane obavijesti o prijetnjama i ranjivostima (npr. CISA, ENISA, upozorenja nacionalnih CERT-ova)

Iz odjeljka “Zahtjevi za provedbu politike”, točka politike 6.2.1.3.

Također postavlja praktični standard zakrpavanja:

Kritične zakrpe moraju se primijeniti u roku od 3 dana od objave, osobito za sustave izložene internetu

Iz odjeljka “Zahtjevi za provedbu politike”, točka politike 6.1.1.

Izraz “osobito za sustave izložene internetu” važan je. Upravljanje poznatim iskorištavanim ranjivostima mora dati prioritet izloženim sustavima, uslugama udaljenog pristupa, infrastrukturi identiteta, rubnim uređajima, administrativnim panelima SaaS-a i sustavima koji obrađuju osjetljive ili regulirane podatke.

No što se događa kada poslovanje ne može primijeniti zakrpu unutar SLA-a? Politika za velike organizacije zatvara krug:

Ako se ranjivost ne može otkloniti unutar definiranih SLA-ova zbog operativnih, tehničkih ili dobavljačkih ograničenja, mora se podnijeti formalni zahtjev za iznimkom.

Iz odjeljka “Obrada rizika i iznimke”, točka politike 7.1.

Verzija za MSP-ove zahtijeva zapise dnevnika o zakrpama koji podržavaju revizijsku provjerljivost:

Zapisi dnevnika moraju uključivati naziv uređaja, primijenjeno ažuriranje, datum zakrpavanja i razlog svakog kašnjenja

Iz odjeljka “Zahtjevi upravljanja”, točka politike 5.4.2.

Te točke politike stvaraju okosnicu dokaza. Omogućuju CISO-u da kaže: imamo pravila za zaprimanje obavještajnih podataka, prioritizaciju, rokove zakrpavanja, iznimke i razloge kašnjenja. To je razlika između reaktivnog zakrpavanja i uređenog otklanjanja.

Hitna promjena bez gubitka kontrole

Poznate iskorištavane ranjivosti često prisiljavaju na hitne promjene. Čekanje sljedećeg sastanka Savjetodavnog odbora za promjene može biti neodgovorno. Potpuno zaobilaženje upravljanja promjenama također može biti neodgovorno. Odgovor je ubrzana, sljediva kontrola promjena.

Clarysecova Enterprise Change Management Policy Change Management Policy, koja se navodi i kao P05 Change Management Policy, kaže:

Hitne promjene mogu se provesti uz ubrzano usmeno ili delegirano odobrenje ovlaštenih uloga.

Iz odjeljka “Zahtjevi za provedbu politike”, točka politike 6.5.1.

Za MSP-ove, Clarysecova Change Management Policy Change Management Policy - SME prepoznaje istu operativnu stvarnost:

Hitne ili neplanirane promjene mogu se provesti odmah kao odgovor na kritične prekide rada ili prijetnje. Međutim:

Iz odjeljka “Obrada rizika i iznimke”, točka politike 7.4.1.

Riječ “međutim” mjesto je gdje počinje upravljanje. Hitna promjena i dalje mora dokumentirati okidač, pogođene sustave, odluku o riziku, odobravatelja, vrijeme provedbe, rezultat provjere i naknadni pregled. Zenith Blueprint, faza Kontrole u praksi, korak 21, opisuje upravljanje promjenama kao ponovljiv tijek rada u kojem se promjene procjenjuju, odobravaju, provode i pregledavaju. Upozorava da mnoge incidente ne uzrokuju napadači, nego loše upravljane promjene: preširoko otvoreno pravilo vatrozida, debug postavka ostavljena uključenom ili zaboravljena ovisnost nakon migracije.

Za otklanjanje poznate iskorištavane ranjivosti, minimalni dokazi za hitnu promjenu trebaju uključivati:

To nije birokracija. To je minimalni održivi revizijski trag za odluku donesenu pod pritiskom protivnika.

Mapiranje CISA KEV-a i ENISA EUVD-a na dokaze za ISO 27001

ISO 27001:2022 ne zahtijeva konkretan izvor obavještajnih podataka o prijetnjama. Zahtijeva da organizacija utvrdi zahtjeve, upravlja rizikom, provede kontrole, zadrži dokumentirane informacije i poboljšava se. CISA KEV i ENISA EUVD mogu postati mjerodavni ulazi u taj sustav upravljanja.

Zenith Blueprint, faza Upravljanje rizicima, korak 13, preporučuje sljedivost između rizika, kontrola i točaka:

Unakrsno povežite propise: ako se određene kontrole provode posebno radi usklađivanja s GDPR, NIS2 ili DORA, to možete zabilježiti ili u Registru rizika (kao dio obrazloženja utjecaja rizika) ili u napomenama SoA.

Za poznatu iskorištavanu ranjivost, unos u registar rizika ne smije glasiti samo “Zakrpati CVE.” Treba identificirati izvor prijetnje, pogođenu uslugu, regulatornu relevantnost, vlasnika rizika, obradu, reference na kontrole i lokaciju dokaza.

Mapiranje međuregulatorne usklađenosti za NIS2, DORA, GDPR i izvješćivanje o upravljanju

Vrijednost upravljanja vođenog iskorištavanjem jest u tome što jedan kontrolirani tijek rada može odgovoriti na više regulatornih pitanja. Isti tiket, zapis o promjeni, obrazac iznimke, e-pošta dobavljača i provjera skeniranjem mogu podržati različite dokazne narative kada su namjerno mapirani.

NIS2 mijenja razgovor za ključne i važne subjekte jer Article 20 kibernetičku sigurnost čini pitanjem odgovornosti upravljačkog tijela. Article 21 zahtijeva primjerene i razmjerne tehničke, operativne i organizacijske mjere, uključujući postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, postupanje s ranjivostima i njihovu objavu, kibernetičku higijenu, kontrolu pristupa, upravljanje imovinom i autentifikaciju.

Article 23 dodaje fazno izvješćivanje za značajne incidente, uključujući rano upozorenje u roku od 24 sata, obavijest u roku od 72 sata i konačno izvješće u roku od jednog mjeseca nakon obavijesti o incidentu. Podudaranje s CISA KEV-om ili ENISA EUVD-om nije automatski prijavljivi incident. No mora pokrenuti dokumentiranu procjenu incidenta kada su iskorištavanje, prekid usluge, šteta za klijente ili učinak na podatke vjerojatni.

DORA dodaje sektorsku perspektivu za financijske subjekte. Primjenjuje se od 17. siječnja 2025. i zahtijeva upravljanje, dokumentirano upravljanje IKT rizicima, testiranje, otpornost, upravljanje incidentima i kontrolu IKT rizika trećih strana. Article 13 posebno je relevantan jer zahtijeva sposobnosti povezane s ranjivostima i obavještajnim podacima o kibernetičkim prijetnjama, naučenim lekcijama i praćenjem tehnološkog razvoja. Article 17 zahtijeva proces upravljanja incidentima povezanima s IKT-om koji evidentira incidente i značajne kibernetičke prijetnje, klasificira ih prema prioritetu i ozbiljnosti, eskalira, identificira temeljne uzroke i obnavlja sigurno poslovanje.

DORA Articles 28 i 30 također nameću disciplinu prema dobavljačima. Ako platna platforma ovisi o WAF-u u oblaku, upravljanoj bazi podataka, pružatelju identiteta ili SaaS mehanizmu tijeka rada koji je pogođen poznatom iskorištavanom ranjivošću, dokazi ne mogu stati na tvrdnji “dobavljač kaže da je zakrpano”. Trebaju uključivati obavijest dobavljača, procjenu kritičnosti, korištena ugovorna prava, kompenzacijske kontrole, procjenu učinka na klijente i provjeru nakon otklanjanja.

GDPR dodaje pitanje usmjereno na podatke. Article 32 zahtijeva sigurnost obrade, dok Article 5(2) uspostavlja odgovornost. Pregled privatnosti treba započeti prije potvrđene povrede, a ne nakon što je iznošenje podataka dokazano.

Praktičan zapis o otklanjanju prema KEV-u i EUVD-u

Razmotrite realan scenarij. ENISA EUVD i CISA KEV ukazuju na aktivno iskorištavanje ranjivosti koja utječe na uslugu prijenosa datoteka izloženu internetu. Usluga podržava uvođenje klijenata i pohranjuje ograničene osobne podatke. Zakrpa dobavljača postoji, ali vlasnik aplikacije traži termin održavanja, a jedna povezana SaaS komponenta ovisi o otklanjanju kod dobavljača.

Izradite jedan zapis u registru upravljanja ranjivostima sa sljedećim poljima:

Zatim primijenite Clarysecova pravila politike:

• Koristite Enterprise Vulnerability and Patch Management Policy ako upravljate većom organizacijom s formalnim ulogama, SLA-ovima i eskalacijom.
• Koristite SME Vulnerability and Patch Management Policy-sme ako trebate lagan, ali revizijski provjerljiv model.
• Koristite Enterprise Change Management Policy ili SME Change Management Policy za dokumentiranje hitnog odobrenja, testiranja, uvođenja i naknadnog pregleda.
• Povežite zapis s Registrom rizika i Izjavom o primjenjivosti, kako preporučuje Zenith Blueprint, korak 13.
• Označite kontrole u Zenith Controls kao 5.7, 8.8 i 8.32, zatim dodajte pripadajuće dokaze za upravljanje dobavljačima, upravljanje oblakom, zapisivanje događaja, upravljanje incidentima i neprekidnost poslovanja gdje je relevantno.

Na kraju sačuvajte revizijske dokaze. Clarysecova Enterprise Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy, koja se navodi i kao P33 Audit and Compliance Monitoring Policy, definira izričit cilj:

Generirati dokazive dokaze i revizijski trag kao potporu regulatornim upitima, pravnim postupcima ili zahtjevima klijenata za pružanje potvrda.

Iz odjeljka “Ciljevi”, točka politike 3.4.

To je svrha tijeka rada. Ne popravljate samo ranjivost. Proizvodite dokazive dokaze da je organizacija postupila razmjerno, pravodobno i pod kontrolom.

Kako će revizori testirati istu KEV odluku

Zreo proces za poznate iskorištavane ranjivosti mora izdržati različite revizijske perspektive.

Revizor za ISO 27001:2022 počet će od opsega ISMS-a, zainteresiranih strana, regulatornih obveza, metode procjene rizika, Izjave o primjenjivosti i dokumentiranih informacija. Pitat će jesu li obavještajni podaci o prijetnjama integrirani u procjenu rizika, je li upravljanje ranjivostima ponovljivo, jesu li hitne promjene kontrolirane, prihvaća li preostali rizik odgovarajući vlasnik rizika i čuvaju li se dokazi.

Procjenitelj usmjeren na NIS2 usredotočit će se na odgovornost uprave, mjere upravljanja rizicima iz Article 21, ranjivosti dobavljača, postupanje s incidentima, neprekidnost poslovanja i procjenu značajnog incidenta prema Article 23. Bit će mu važne vremenske oznake, eskalacija, zapisi odluka i jesu li upravljačka tijela obaviještena gdje je to primjereno.

Revizor za DORA ili nadležno tijelo pitat će je li okvir upravljanja IKT rizicima obuhvatio pogođenu imovinu, poslovnu funkciju, ovisnost i uslugu treće strane. Očekivat će klasifikaciju incidenta, zapise o značajnim kibernetičkim prijetnjama, eskalaciju upravi, praćenje temeljnog uzroka, dokaze dobavljača, testiranje i praćenje otklanjanja.

Pregledavatelj za GDPR pitat će jesu li osobni podaci bili uključeni, jesu li povjerljivost, cjelovitost ili dostupnost mogle biti pogođene, koje su tehničke i organizacijske mjere bile uspostavljene, je li procijenjena potreba za prijavom povrede i postoje li dokazi odgovornosti.

Procjenitelj za NIST CSF 2.0 može koristiti CSF Core i Profiles kako bi testirao jesu li ishodi upravljanja, identifikacije, zaštite, otkrivanja, odgovora i oporavka definirani i mjereni. Praktični Target Profile mogao bi glasiti: “Sve poznate iskorištavane ranjivosti koje utječu na kritičnu imovinu izloženu internetu trijažiraju se u roku od 24 sata, obrađuju u roku od 72 sata ili se formalno izuzimaju uz kompenzacijske kontrole i odobrenje vlasnika rizika.”

Revizor za COBIT 19 pitat će tko je odgovoran, jesu li ciljevi upravljanja definirani, određuje li apetit za rizik hitnost, pregledavaju li se pokazatelji uspješnosti, prate li se iznimke i testiraju li funkcije osiguranja proces neovisno.

Isti zapis dokaza treba odgovoriti svima njima. To je vrijednost inženjeringa međuregulatorne usklađenosti.

Metrike koje uprava treba vidjeti

Uprava ne treba popis svakog CVE-a. Treba metrike kvalitete odlučivanja koje pokazuju izloženost, odzivnost i preostali rizik. Za upravljanje poznatim iskorištavanim ranjivostima Clarysec preporučuje sažeto izvješće upravi s ovim stavkama:

Te metrike podržavaju preispitivanje uprave prema ISO 27001, odgovornost uprave prema NIS2, izvješćivanje o IKT riziku prema DORA i komunikaciju o upravljanju prema NIST CSF-u. Također pomažu vlasnicima poslovanja razumjeti zašto kapacitet zakrpavanja, kvaliteta popisa imovine, ugovori s dobavljačima i termini održavanja nisu “IT detalji”. To su odluke o otpornosti.

Uobičajeni obrasci neuspjeha koje treba ukloniti

U Clarysecovim procjenama upravljanje poznatim iskorištavanim ranjivostima obično zakazuje na predvidljive načine.

Prvo, izvori obavještajnih podataka su neformalni. Jedan sigurnosni inženjer prati CISA KEV, drugi prati biltene dobavljača, a treći se oslanja na izlaz skenera. Ne postoji dokumentirani registar obavještajnih podataka o prijetnjama, pravilo provjere ni vlasništvo.

Drugo, korelacija imovine je slaba. Organizacija zna da CVE postoji, ali ne može brzo utvrditi gdje se proizvod izvodi, je li izložen internetu, tko je vlasnik, koje podatke obrađuje ili koji dobavljač njime upravlja.

Treće, hitna promjena je ili prespora ili previše nekontrolirana. Timovi danima čekaju odobrenje ili zakrpavaju produkciju bez napomena o povratu, provjere ili naknadnog pregleda.

Četvrto, iznimke su neodređene. “Ne može se zakrpati zbog poslovnog učinka” nije prihvaćanje rizika. Ispravna iznimka mora definirati ograničenje, pogođenu imovinu, kompenzacijske kontrole, preostali rizik, odobravatelja, datum isteka i učestalost pregleda.

Peto, dokazi su raspršeni. Snimke zaslona skenera, odobrenja u chatu, e-pošta dobavljača, SIEM upiti i zapisi o promjenama nalaze se na različitim mjestima. Tijekom revizije ili regulatornog upita organizacija ne može rekonstruirati vremenski slijed odluke.

Rješenje nije više buke. Rješenje je jedinstven tijek upravljanja vođen iskorištavanjem koji integrira obavještajne podatke, rizik, promjene, incidente, dobavljače i dokazne procese.

Izgradite svoj dokazni mehanizam vođen iskorištavanjem

Poznate iskorištavane ranjivosti ostat će operativna briga velikog volumena u 2026. CISA KEV i ENISA EUVD čine obavještajne podatke o iskorištavanju vidljivijima, ali sama vidljivost ne ispunjava dokazna očekivanja prema ISO 27001:2022, NIS2, DORA ili GDPR. Potreban vam je uređen proces koji obavještajne podatke pretvara u radnju, a radnju u dokaz.

Počnite s četiri koraka:

1. Izradite registar obavještajnih podataka o prijetnjama koristeći Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, faza Kontrole u praksi, korak 22.
2. Uskladite pravila politike s Clarysecovom Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy ili Vulnerability and Patch Management Policy-sme Vulnerability and Patch Management Policy-sme - SME.
3. Koristite Zenith Controls: The Cross-Compliance Guide Zenith Controls za mapiranje 5.7 Obavještajnih podataka o prijetnjama, 8.8 Upravljanja tehničkim ranjivostima i 8.32 Upravljanja promjenama na potrebe dokaza za ISO, NIS2, DORA, GDPR, NIST i COBIT.
4. Testirajte jedan stvarni slučaj KEV-a ili EUVD-a od početka do kraja, od zaprimanja do otklanjanja, postupanja s iznimkom, hitne promjene, provjere i izvješćivanja uprave.

Clarysec vam može pomoći da to pretvorite u funkcionalan operativni model spreman za reviziju: politike, registre, predloške dokaza, mapiranja međuregulatorne usklađenosti i izvješćivanje na razini uprave koji otklanjanje vođeno iskorištavanjem čine dokazivim pred revizorom, regulatorom i vašim klijentima.

Preuzmite Zenith Blueprint, istražite Zenith Controls ili zatražite Clarysec procjenu spremnosti kako biste izgradili tijek upravljanja CISA KEV-om i ENISA EUVD-om prije nego sljedeća ranjivost petkom postane pitanje za upravu.