SLA-ovi za otklanjanje ranjivosti za NIS2 i DORA

U utorak ujutro početkom 2026., u 08:17, Anna, CISO brzorastuće fintech tvrtke, prima prvu poruku prije nego što je stigla popiti kavu.

SOC je označio aktivnu komunikaciju o iskorištavanju ranjivosti u API pristupniku dostupnom klijentima. Inženjering navodi da je zakrpa dostupna, ali rizična jer se pristupnik nalazi ispred tijekova plaćanja. Voditelj usklađenosti prosljeđuje formalni zahtjev nacionalnog nadležnog tijela koje traži dokaze o “postupanju s ranjivostima i njihovoj objavi” te dokaz da je proces bio učinkovit tijekom posljednjih 12 mjeseci. Nabava dodaje treći problem: pristupnikom upravlja pružatelj upravljanih usluga, a ugovor samo navodi da će pružatelj primjenjivati “sigurnosna ažuriranja pravodobno”.

Do 09:00 to više nije samo pitanje zakrpavanja. To je pitanje dokaza prema ISO/IEC 27001:2022, pitanje kibernetičke higijene prema NIS2, pitanje upravljanja IKT rizicima prema DORA, pitanje upravljanja dobavljačima i potencijalno pitanje prijavljivanja incidenata ako iskorištavanje utječe na neprekidnost usluge ili osobne podatke.

To je praktična praznina u usklađenosti s kojom će se mnoge organizacije suočiti u 2026. Imaju skenere, nadzorne ploče, radne naloge i alate za zakrpavanje, ali ne mogu jasno odgovoriti na revizijska pitanja:

• Tko je odobrio SLA za otklanjanje?
• Kako je SLA utemeljen na riziku?
• Što se događa kada se kritična zakrpa ne primijeni u roku?
• Kako se prioritiziraju imovina izložena internetu?
• Kako se dobavljači obvezuju na iste rokove?
• Gdje je zapis o prihvaćanju rizika za nezakrpani sustav?
• Koji dokaz potvrđuje da je kontrola stvarno djelovala, a ne samo postojala?

Odgovor nije još jedna proračunska tablica s rokovima. SLA-ovima za otklanjanje ranjivosti mora se upravljati kao živim sustavom kontrola koji povezuje vlasništvo nad imovinom, ocjenjivanje ranjivosti, obavještajne podatke o prijetnjama, upravljanje promjenama, SLA-ove dobavljača, postupanje s iznimkama, praćenje, odgovor na incidente i preispitivanje od strane uprave.

Tu postaju korisni Clarysecovi Enterprise Politika upravljanja ranjivostima i zakrpama (VPMP), Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća (VPMP-SME), Politika sigurnosti trećih strana i dobavljača za mala i srednja poduzeća (TPSSP-SME), Zenith Blueprint (ZB) i Zenith Controls (ZC). Zajedno pretvaraju “brže zakrpavanje” u dokaziv proces upravljanja koji može izdržati revizijsku provjeru prema ISO, NIS2, DORA, GDPR, NIST i ISACA pristupu.

Zašto su SLA-ovi za otklanjanje ranjivosti postali dokaz na razini uprave

Otklanjanje ranjivosti nekada se tretiralo kao metrika IT higijene. U 2026. ono je bliže reguliranoj obvezi operativne otpornosti.

NIS2 pretvara kibernetičku sigurnost u pitanje odgovornosti uprave. Ključni i važni subjekti moraju imati upravljačka tijela koja odobravaju mjere upravljanja rizicima kibernetičke sigurnosti, nadziru provedbu i prolaze obuku kako bi razumjela rizike i utjecaj sigurnosnih praksi na usluge. NIS2 Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost lanca opskrbe, sigurnu nabavu i održavanje, postupanje s ranjivostima i njihovu objavu, kibernetičku higijenu, obuku, kontrolu pristupa, upravljanje imovinom i autentifikaciju.

Za financijske subjekte DORA je specijalizirani režim operativne otpornosti. Zahtijeva aranžmane upravljanja i kontrola za IKT rizik, pri čemu upravljačko tijelo definira, odobrava, nadzire i ostaje odgovorno za upravljanje IKT rizicima. Također zahtijeva identifikaciju IKT imovine i ovisnosti, kontrole zaštite i prevencije kao što su zakrpavanje i upravljanje promjenama, upravljanje incidentima povezanima s IKT-om, testiranje digitalne operativne otpornosti i upravljanje IKT rizicima trećih strana.

Praktični učinak je značajan. Propušteni rok zakrpavanja može upućivati na neuspjeh u sljedećem:

• Upravljanje, ako uprava nije odobrila SLA-ove utemeljene na riziku
• Upravljanje imovinom, ako je vlasnik zahvaćenog sustava nepoznat
• Upravljanje promjenama, ako hitno zakrpavanje nije kontrolirano
• Upravljanje dobavljačima, ako su rokovi pružatelja nejasni
• Odgovor na incidente, ako se znakovi iskorištavanja ne trijažiraju
• Upravljanje dokazima, ako radni nalozi i zapisi dnevnika ne mogu dokazati zatvaranje
• Obrada rizika, ako iznimke nisu odobrene i pregledane

ISO/IEC 27001:2022 pruža okosnicu sustava upravljanja. Clauses 4.1 to 4.3 zahtijevaju da organizacije razumiju unutarnja i vanjska pitanja, zahtjeve zainteresiranih strana, pravne i ugovorne obveze te sučelja s drugim organizacijama. Clauses 6.1.1 to 6.1.3 zahtijevaju procjenu rizika, obradu rizika, Izjavu o primjenjivosti i odobrenje preostalog rizika od strane vlasnika rizika. Clauses 9.1, 9.2, 9.3, 10.1 i 10.2 zahtijevaju praćenje, internu reviziju, preispitivanje od strane uprave, kontinuirano poboljšanje, korektivne radnje i zadržane dokumentirane informacije.

Jednostavno rečeno, ako želite da SLA-ovi za otklanjanje ranjivosti budu spremni za reviziju, moraju biti dio ISMS-a, a ne samo DevOps metrika.

Model SLA-a koji revizori očekuju vidjeti

SLA za otklanjanje ranjivosti treba odgovoriti na tri pitanja:

1. Koliko brzo moramo djelovati?
2. Tko je odgovoran?
3. Koji dokaz potvrđuje ishod?

Politika upravljanja ranjivostima i zakrpama definira praktičnu polaznu točku za rokove otklanjanja utemeljene na riziku:

Organizacija mora klasificirati sve otkrivene ranjivosti primjenom standardizirane metodologije (npr. CVSS v3.x) i primjenjivati rokove otklanjanja usklađene s poslovnom kritičnošću: 5.2.1 Kritična (CVSS 9.0-10.0): trenutačni pregled; rok zakrpavanja najviše 72 sata. 5.2.2 Visoka (7.0-8.9): odgovor u roku od 48 sati; rok zakrpavanja 7 kalendarskih dana. 5.2.3 Srednja (4.0-6.9): odgovor u roku od 5 dana; rok zakrpavanja 30 kalendarskih dana. 5.2.4 Niska (<4.0): odgovor u roku od 10 dana; rok zakrpavanja 60 kalendarskih dana.

Ova je točka snažna jer razdvaja vrijeme odgovora od roka zakrpavanja. Visoka ranjivost ne bi smjela ostati neprimijećena šest dana i zatim biti zakrpana sedmog dana. Vrijeme odgovora potvrđuje trijažu, vlasništvo, procjenu utjecaja i planiranje otklanjanja. Rok zakrpavanja potvrđuje tehničko zatvaranje ili odobrenu iznimku.

Za manje organizacije Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća koristi jednostavniji, ali i dalje revizijski provjerljiv jezik:

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

A za šire okruženje zakrpa:

Sve ostale zakrpe moraju se primijeniti u roku od 30 dana, osim ako je dokumentirana valjana iznimka

Poanta nije u tome da svaka organizacija mora koristiti identične rokove. ISO/IEC 27001:2022, NIS2 i DORA podržavaju razmjernost. Poanta je da SLA-ovi za otklanjanje moraju biti definirani, odobreni, utemeljeni na riziku, praćeni i dokazani.

Tu mnoge tvrtke padaju. Definiraju SLA, ali ne definiraju dokaze. Iz perspektive revizora, politika bez operativnih zapisa obećanje je, a ne kontrola.

Vlasništvo nad imovinom skrivena je ovisnost

Skener vam može reći da CVE postoji na poslužitelju. Ne može vam reći podržava li taj poslužitelj kritični proces plaćanja, pohranjuje li posebne kategorije osobnih podataka, povezuje li se s pružateljem namire ili je planiran za stavljanje izvan uporabe.

Taj kontekst dolazi iz upravljanja imovinom, klasifikacije podataka, popisa dobavljača i procjene rizika.

ISO/IEC 27001:2022 Annex A kontrola 8.8, upravljanje tehničkim ranjivostima, središnja je, ali ne djeluje samostalno. Uvelike ovisi o upravljanju konfiguracijom, upravljanju promjenama, praćenju dobavljača, upravljanju uslugama u oblaku, zapisivanju događaja, praćenju i obradi rizika.

NIST CSF 2.0 izražava isti problem jezikom ishoda. Funkcija GOVERN očekuje da se pravni, regulatorni i ugovorni zahtjevi kibernetičke sigurnosti razumiju i upravljaju, da se apetit za rizik i tolerancija dokumentiraju, da se dodijele uloge i resursi te da se politike kibernetičke sigurnosti uspostave, primjenjuju, pregledavaju i ažuriraju. Ishodi IDENTIFY uključuju popise hardvera, softvera, usluga, sustava, podataka i životnog ciklusa, zajedno s identifikacijom ranjivosti, analizom rizika, upravljanjem iznimkama i procesima objave ranjivosti.

U Anninom scenariju od utorka ujutro prvo tehničko pitanje glasi: “gdje je ranjiva komponenta?” Prvo upravljačko pitanje glasi: “na koju uslugu i koji rizik utječe?”

Zenith Blueprint, faza upravljanja rizicima, korak 13: planiranje obrade rizika i Izjava o primjenjivosti, rješava to povezivanjem rizika s kontrolama, vlasnicima i rokovima:

Također dodijelite vlasnika i rok za svaku radnju (možda u zasebnom stupcu ili komentarima). Npr. “Vlasnik: IT Manager, rok: do Q3 2025.” Time to postaje stvarni plan.

Upravo je to ono što otklanjanje ranjivosti zahtijeva. Nalaz bez vlasnika postaje šum u zaostatku zadataka. Nalaz s vlasnikom, rokom, odlukom o obradi rizika i dokaznim tragom postaje revizijski provjerljiva kontrola.

Kako Zenith Controls mapira odnose kontrola

Zenith Controls tretira ISO/IEC 27002:2022 kontrolu 8.8, upravljanje tehničkim ranjivostima, kao preventivnu kontrolu koja podupire povjerljivost, cjelovitost i dostupnost. Povezuje je s konceptima kibernetičke sigurnosti Identify i Protect, operativnom sposobnošću upravljanja prijetnjama i ranjivostima te sigurnosnim domenama upravljanja, ekosustava, zaštite i obrane.

To je važno jer SLA-ovi za otklanjanje nisu samo mehanizam zaštite. Oni su i mehanizam upravljanja i mehanizam ekosustava. Vašu izloženost oblikuju dobavljači, platforme u oblaku, pružatelji upravljanih usluga, komponente otvorenog koda i ovisnosti izložene internetu.

Zenith Controls mapira 8.8 na nekoliko potpornih kontrola:

Zenith Controls također povezuje upravljanje ranjivostima s ISO/IEC 27005:2024, osobito s identifikacijom ranjivosti i scenarijima rizika koji uključuju nezakrpane sustave. Time se jača argument da rokovi zakrpavanja trebaju biti utemeljeni na riziku, a ne proizvoljni. Također povezuje praćenje dobavljača s ISO/IEC 27036-4:2016 za sigurnosne razine ugovora o uslugama u oblaku i ISO/IEC 20000-1:2018 za planiranje pružanja usluga i upravljanje promjenama.

Ta među-standardna struktura važna je tijekom revizije. Ako organizacija kaže “kritične ranjivosti zakrpavaju se u roku od 72 sata”, revizor će provjeriti je li ta izjava potkrijepljena procjenom rizika, klasifikacijom imovine, obvezama dobavljača, zapisima promjena i dokazima praćenja.

Kibernetička higijena prema NIS2: od postupanja s ranjivostima do korektivnih radnji

NIS2 Article 21 zahtijeva pristup svim prijetnjama za mrežne i informacijske sustave. Za SLA-ove za otklanjanje ranjivosti izravno je relevantno nekoliko elemenata Article 21:

• Analiza rizika i politike sigurnosti informacijskih sustava
• Postupanje s incidentima
• Neprekidnost poslovanja i krizno upravljanje
• Sigurnost lanca opskrbe
• Sigurna nabava, razvoj i održavanje, uključujući postupanje s ranjivostima i njihovu objavu
• Postupci za procjenu učinkovitosti kibernetičke sigurnosti
• Osnovna kibernetička higijena i obuka
• Kontrola pristupa i upravljanje imovinom
• Višefaktorska autentifikacija ili kontinuirana autentikacija gdje je primjereno

NIS2 Article 20 čini upravljačka tijela odgovornima za odobravanje i nadzor mjera upravljanja rizicima kibernetičke sigurnosti. To znači da metrike otklanjanja ranjivosti ne smiju živjeti samo u inženjerskoj nadzornoj ploči. Trebale bi se pojavljivati u izvješćima upravi, materijalima odbora za rizike ili zapisima preispitivanja ISMS-a od strane uprave.

Article 21 također očekuje da subjekti koji utvrde neusklađenost s potrebnim mjerama poduzmu korektivne radnje bez nepotrebnog odgađanja. Ta je formulacija važna. Ako vaša nadzorna ploča prikazuje prekoračene kritične ranjivosti, dokaz usklađenosti ne smije stati na “znamo”. Treba pokazati eskalaciju, pregled rizika, vidljivost za upravu, korektivnu radnju i preispitivanje.

NIS2 Article 23 dodaje još jednu dimenziju. Ako iskorištavanje nezakrpane ranjivosti uzrokuje ili može uzrokovati ozbiljan operativni poremećaj, financijski gubitak ili štetu drugim osobama, može postati značajan incident. Životni ciklus prijavljivanja uključuje rano upozorenje u roku od 24 sata od saznanja za značajan incident, obavijest o incidentu u roku od 72 sata, međurazdobna izvješća na zahtjev i završno izvješće u roku od mjesec dana nakon obavijesti o incidentu. Završno izvješće treba uključivati ozbiljnost, utjecaj, vjerojatni temeljni uzrok, mjere ublažavanja i prekogranični utjecaj gdje je primjenjivo.

Stoga se SLA proces mora povezati s odgovorom na incidente. Kritična ranjivost s dokazima aktivnog iskorištavanja treba pokrenuti sigurnosnu trijažu, praćenje, očuvanje dokaza i procjenu obveze prijavljivanja, a ne samo rutinski radni nalog za zakrpu.

DORA IKT rizik: rokovi otklanjanja kao dokaz otpornosti

Za financijske subjekte DORA se primjenjuje od 17. siječnja 2025. i uspostavlja jedinstvene zahtjeve u području upravljanja IKT rizicima, prijavljivanja većih incidenata povezanih s IKT-om, testiranja digitalne operativne otpornosti, razmjene informacija i upravljanja IKT rizicima trećih strana. Smatra se sektorskim pravnim aktom EU-a za obuhvaćene financijske subjekte utvrđene nacionalnim pravilima NIS2.

DORA-in operativni model blizak je integriranom ISMS-u. Articles 5 i 6 zahtijevaju upravljanje, politike, postupke, alate, godišnji ili periodični pregled, reviziju, otklanjanje kritičnih nalaza revizije i strategiju digitalne operativne otpornosti. Article 8 zahtijeva identifikaciju i popisivanje poslovnih funkcija podržanih IKT-om, informacijske imovine, IKT imovine, ovisnosti, procesa trećih strana i rizika naslijeđenih IKT sustava. Article 9 zahtijeva kontrole zaštite i prevencije, uključujući zakrpavanje i upravljanje promjenama. Articles 11 i 12 zahtijevaju kontinuitet, odgovor, oporavak, sigurnosno kopiranje, vraćanje podataka i ciljeve oporavka.

DORA Articles 17 to 19 zahtijevaju proces upravljanja incidentima povezanima s IKT-om koji otkriva, upravlja, bilježi, klasificira, eskalira, prijavljuje, komunicira, analizira temeljni uzrok i obnavlja sigurno poslovanje. Articles 24 to 26 zahtijevaju testiranje digitalne operativne otpornosti, uključujući odgovarajuće testiranje IKT alata i sustava, procjene ranjivosti, procjene sigurnosti mreže, analize praznina, preglede izvornog koda gdje je izvedivo, penetracijsko testiranje i penetracijsko testiranje vođeno prijetnjama za određene financijske subjekte. Articles 28 i 30 zahtijevaju upravljanje IKT rizicima trećih strana, registre ugovora o IKT uslugama, dubinsku analizu dobavljača, prava na reviziju i inspekciju, razine usluge, pomoć pružatelja tijekom incidenata, prava raskida i izlazne aranžmane.

Za SLA-ove za otklanjanje DORA mijenja očekivanja u pogledu dokaza na tri načina.

Prvo, nalazi ranjivosti iz testiranja moraju se uključiti u prioritizirani proces otklanjanja. Izvješće o skeniranju nije dovoljno.

Drugo, otklanjanje kritičnih nalaza mora se pratiti kroz upravljanje i reviziju. DORA očekuje formalno otklanjanje kritičnih nalaza revizije za subjekte koji nisu mikropoduzeća.

Treće, pružatelji IKT usluga trećih strana moraju imati mjerljive obveze. Ako vaš pružatelj usluge u oblaku, SaaS-a ili MSP-a kontrolira termin zakrpavanja, vaš ugovor i registar moraju pokazati kako njihovi rokovi otklanjanja podupiru vaše obveze otpornosti.

Politika upravljanja ranjivostima i zakrpama to izravno uređuje:

Zakrpavanje trećih strana i nadzor SaaS rizika 6.6.1 Svi sustavi trećih strana (SaaS, PaaS, kojima upravlja MSP) moraju dokazati odgovarajuće kontrole upravljanja ranjivostima i zakrpama. 6.6.2 SLA-ovi dobavljača moraju uključivati rokove otklanjanja ekvivalentne interno definiranim pragovima temeljenima na kritičnosti.

Ta je točka često karika koja nedostaje između internih ISO dokaza i DORA nadzora nad dobavljačima.

GDPR: kada kašnjenje zakrpa postaje neuspjeh odgovornosti za osobne podatke

GDPR nije standard za upravljanje ranjivostima, ali mijenja posljedice neuspjeha zakrpavanja.

GDPR Article 5 zahtijeva sigurnu obradu osobnih podataka i zahtijeva da voditelj obrade može dokazati usklađenost. Article 32 zahtijeva odgovarajuće tehničke i organizacijske mjere kako bi se osigurala razina sigurnosti primjerena riziku. Kada nezakrpani sustavi obrađuju osobne podatke, osobito podatke o identitetu, financijske podatke, biometrijske podatke, zdravstvene podatke, podatke o zaposlenju ili KYC informacije, SLA-ovi za otklanjanje postaju dio odgovornosti za sigurnost obrade.

Odgođena zakrpa može biti dokaziva ako je rizik procijenjen, ako su primijenjene kompenzacijske kontrole i ako je preostali rizik prihvatila odgovarajuća osoba. Mnogo ju je teže opravdati ako je ranjivost prekoračila rok, izložena je internetu i nema vlasnika.

Zenith Controls mapira upravljanje ranjivostima na GDPR Articles 32 i 5(1)(f), jer pravodobno zakrpavanje smanjuje rizike za povjerljivost i cjelovitost osobnih podataka. Također mapira upravljanje promjenama na GDPR Article 24 i Article 32, jer promjene na sustavima koji obrađuju osobne podatke trebaju biti procijenjene prema riziku, odobrene, dokumentirane i pregledane.

Pouka za usklađenost je jednostavna: ako su uključeni osobni podaci, dokaz o zakrpi treba uključivati kontekst podataka. Revizori i regulatori neće pitati samo “je li zakrpano?”, nego i “koji su podaci bili izloženi riziku, koliko dugo i koje su kontrole smanjile taj rizik?”

Praktični Clarysec tijek rada za SLA dokaze spremne za reviziju

Zreo proces otklanjanja ranjivosti ne počinje kada revizor zatraži zapise. Osmišljen je tako da svaki mjesec proizvodi zapise.

Korak 1: Odobrite SLA politiku

Započnite s Politikom upravljanja ranjivostima i zakrpama ili Politikom upravljanja ranjivostima i zakrpama za mala i srednja poduzeća, ovisno o vašem operativnom modelu. Prilagodite SLA pragove svojem apetitu za rizik, regulatornom okviru, kritičnosti usluga, osjetljivosti podataka i tehničkim ograničenjima. Osigurajte odobrenje CISO-a, odbora za rizike ili upravljačkog tijela.

Za poslovna okruženja koristite CVSS, kritičnost imovine, mogućnost iskorištavanja, izloženost internetu, osjetljivost podataka i utjecaj na poslovanje. Za mala i srednja poduzeća model treba biti jednostavan, ali izričit: kritične zakrpe u roku od tri dana, ostale zakrpe u roku od 30 dana, osim ako postoji valjana iznimka.

Korak 2: Mapirajte imovinu na vlasnike i kritične usluge

Svaki nalaz ranjivosti treba se povezati sa sljedećim:

• Naziv imovine i jedinstveni identifikator
• Poslovna usluga ili aplikacija
• Vlasnik sustava
• Tehnički vlasnik
• Klasifikacija podataka
• Izloženost internetu
• Ovisnost o dobavljaču, ako je primjenjivo
• Kritičnost podržane funkcije

To podupire vlasništvo nad rizikom prema ISO/IEC 27001:2022, upravljanje imovinom prema NIS2, popis IKT imovine i ovisnosti prema DORA te ishode NIST CSF IDENTIFY.

Korak 3: Trijažirajte ranjivost

Izradite radni nalog za svaki nalaz ili skup povezanih nalaza. Uključite CVSS ocjenu, izvorni skener, zahvaćenu imovinu, status iskorištavanja, obavještajne podatke o prijetnjama, poslovnu kritičnost i zahtijevani SLA. Ako se sumnja na iskorištavanje, povežite radni nalog s procjenom incidenta.

Korak 4: Provedite kroz upravljanje promjenama

Zakrpavanje je promjena. Koristite standardnu promjenu za rutinska ažuriranja i hitnu promjenu za kritične iskorištene ranjivosti. Uključite dokaze o testiranju, odobrenje, vremensku oznaku implementacije, plan povrata i provjeru nakon promjene.

To odgovara odnosu koji Zenith Controls uspostavlja između 8.8 i 8.32, gdje se primjena zakrpa uređuje kroz upravljanje promjenama radi uravnoteženja hitnosti i operativne stabilnosti.

Korak 5: Provjerite zatvaranje

Ne zatvarajte radne naloge samo na temelju tvrdnje “zakrpa instalirana”. Zahtijevajte provjeru ponovnim skeniranjem, potvrdom verzije, provjerom konfiguracije ili potvrdom kompenzacijskih kontrola. Ako se zakrpa ne može primijeniti, otvorite iznimku.

Korak 6: Evidentirajte iznimke i preostali rizik

Politika upravljanja ranjivostima i zakrpama definira obvezni sadržaj iznimke:

Zahtjevi za iznimku moraju uključivati: 7.2.1 Poslovno obrazloženje odgode ili neotklanjanja 7.2.2 Procjenu rizika (na temelju CVSS-a, kritičnosti imovine i obavještajnih podataka o prijetnjama) 7.2.3 Predložene kompenzacijske kontrole 7.2.4 Rok za otklanjanje ili preispitivanje

Također definira odobrenje i pregled:

Iznimke mora odobriti CISO ili delegirani odbor za rizike te se moraju evidentirati u registru iznimaka ISMS-a, uz interval pregleda koji ne prelazi 90 dana.

Taj registar iznimaka postaje ključan dokaz za ISO/IEC 27001:2022 Clause 6.1.3 obradu rizika i prihvaćanje preostalog rizika, kao i za preispitivanje od strane uprave.

Ovaj zapis pokazuje da organizacija nije zanemarila ranjivost. Procijenila je rizik, primijenila kompenzacijske kontrole, odobrila preostali rizik i odredila datum pregleda.

Korak 7: Izradite mjesečni paket dokaza

Vaš mjesečni paket dokaza za otklanjanje ranjivosti treba uključivati:

Za mala i srednja poduzeća dokazi mogu biti jednostavniji, ali i dalje moraju biti dosljedni. Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća zahtijeva zapise dnevnika zakrpa sa sljedivošću:

Zapisi dnevnika moraju uključivati naziv uređaja, primijenjeno ažuriranje, datum zakrpavanja i razlog svake odgode

Ta jedna točka revizijski je iznimno vrijedna. Pretvara zakrpavanje iz tvrdnje u zapis.

Zakrpavanje kod dobavljača: ugovor mora odgovarati vašem SLA-u

Ako MSP, pružatelj SaaS-a, pružatelj PaaS-a ili pružatelj usluga u oblaku kontrolira implementaciju zakrpa, interni SLA-ovi beskorisni su ako im ne odgovaraju obveze dobavljača.

Politika sigurnosti trećih strana i dobavljača za mala i srednja poduzeća uključuje obveze informacijske sigurnosti kao zahtjev upravljanja. Za otklanjanje ranjivosti te obveze trebaju postati mjerljiv ugovorni jezik:

• Rokovi obavješćivanja o kritičnim ranjivostima
• Rokovi otklanjanja za kritične, visoke, srednje i niske ranjivosti
• Proces hitnih promjena
• Zahtjevi za odobrenje klijenta za prekid rada
• Format dokaza o dovršetku zakrpavanja
• Proces objave ranjivosti
• Obveze pomoći kod incidenata
• Pravo na reviziju ili primanje izvješća o sigurnosnom uvjerenju
• Obveze zakrpavanja podizvršitelja obrade ili podugovaratelja
• Podrška za izlazak i prijelaz za kritične usluge

Zenith Blueprint, faza Kontrole u praksi, korak 20, kontrola 8.21 Sigurnost mrežnih usluga, jasno navodi načelo:

Kada se usluge pružaju eksterno, uključujući ISP-ove, SD-WAN dobavljače ili privatne pružatelje usluga u oblaku, sigurnosni zahtjevi moraju biti ugrađeni u ugovore i SLA-ove. To uključuje jamstva raspoloživosti, vremena odgovora za incidente, obveze zakrpavanja ili ublažavanja ranjivosti i jasne granice postupanja s podacima. Nikada ne biste smjeli pretpostaviti da pružatelj ispunjava vaša očekivanja ako to nije zapisano, mjerljivo i revizijski provjerljivo.

DORA to čini osobito važnim za financijske subjekte. Aranžmani s IKT trećim stranama moraju uključivati razine usluge, pomoć pružatelja tijekom IKT incidenata, pristup podacima i njihov oporavak, suradnju s nadležnim tijelima, prava raskida i snažnije odredbe za kritične ili važne funkcije, uključujući praćenje, prava na reviziju, planove kontinuiteta i sigurnosne mjere.

NIST CSF 2.0 isto govori kroz ishode rizika lanca opskrbe: dobavljači trebaju biti poznati, prioritizirani prema kritičnosti, procijenjeni prije angažmana, uređeni ugovornim zahtjevima, praćeni tijekom odnosa, uključeni u planiranje incidenata i upravljani pri prestanku odnosa.

Što će revizori doista pitati

Revizijski razgovor mijenja se ovisno o iskustvu revizora.

Revizor za ISO/IEC 27001:2022 počet će od ISMS-a. Provjerit će je li upravljanje ranjivostima uključeno u Izjavu o primjenjivosti, identificira li procjena rizika nezakrpane sustave kao rizik, imaju li planovi obrade rizika vlasnike i rokove, je li Annex A kontrola 8.8 implementirana, zadržavaju li se dokazi te vrednuju li interna revizija i preispitivanje od strane uprave učinkovitost.

Zenith Blueprint, faza Kontrole u praksi, korak 19, izričito navodi revizijsko očekivanje:

Ovo je kontrola visokog prioriteta za revizore i oni će se obično detaljno baviti njome. Očekujte pitanja o tome koliko se često sustavi zakrpavaju, koji postupak slijedite kada se objavi zero-day ranjivost i koje je sustave najteže zakrpati.

Nastavlja s praktičnim očekivanjima u pogledu dokaza:

Revizori će vjerojatno zatražiti rezultate skeniranja ranjivosti. Ako koristite alate kao što su Nessus, OpenVAS ili Qualys, izvezite izvješće koje prikazuje nedavno otkrivene ranjivosti i način na koji su obrađene. Idealno bi trebalo uključivati ocjene rizika (CVSS) i rokove otklanjanja.

Revizor ili nadležno tijelo usmjereno na NIS2 tražit će odobrenje uprave, razmjernost, kibernetičku higijenu, postupanje s ranjivostima, sigurnost dobavljača, postupanje s incidentima, procjenu učinkovitosti, korektivne radnje bez nepotrebnog odgađanja i zapise odluka o prijavljivanju ako je iskorištavanje uzrokovalo značajan utjecaj.

Nadzorno tijelo za DORA provjerit će jesu li nalazi ranjivosti integrirani u upravljanje IKT rizicima, testiranje digitalne operativne otpornosti, klasifikaciju incidenata, analizu temeljnog uzroka, registre trećih strana, ugovorne obveze, prava na reviziju i otklanjanje kritičnih nalaza.

Procjenitelj prema NIST CSF-u vjerojatno će organizirati pregled oko funkcija GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER. Pitat će razumiju li se pravni i ugovorni zahtjevi, je li tolerancija na rizik dokumentirana, identificiraju li se i prioritiziraju ranjivosti, upravlja li se iznimkama, otkriva li praćenje iskorištavanje te jesu li radnje odgovora i oporavka koordinirane.

Revizor prema COBIT 2019 ili ISACA stilu usredotočit će se na ciljeve upravljanja, sposobnost procesa, upravljačke prakse, metrike, vlasništvo, dizajn kontrola, djelovanje kontrola i dostatnost dokaza. Pitat će je li otklanjanje ranjivosti ponovljivo, mjereno, eskalirano, poboljšavano i usklađeno s ciljevima organizacije i apetitom za rizik.

Eskalacija i metrike: kako dokazati da se SLA-om upravlja

SLA bez eskalacije samo je cilj. Dokaziv program otklanjanja ranjivosti treba eskalaciju prije kršenja roka, u trenutku kršenja i nakon ponovljenog neuspjeha.

Clarysec preporučuje četverorazinski model eskalacije:

1. Operativna eskalacija, vlasnik radnog naloga i tehnički voditelj obavještavaju se prije kršenja roka.
2. Eskalacija rizika, vlasnik imovine i vlasnik rizika pregledavaju utjecaj kada je kršenje roka vjerojatno.
3. Eskalacija upravljanja sigurnošću, CISO ili odbor za rizike odobrava iznimku ili hitnu radnju.
4. Eskalacija prema upravi, ponovljena ili kritična kršenja SLA-a prijavljuju se na preispitivanje od strane uprave s korektivnim radnjama.

Politika upravljanja ranjivostima i zakrpama pojačava ovo revizijsko očekivanje:

Periodične revizije mora provoditi interna revizija ili neovisna treća strana radi provjere: 5.6.1 Usklađenosti sa SLA-ovima 5.6.2 Dokaza o prioritizaciji utemeljenoj na riziku 5.6.3 Učinkovitosti implementiranih zakrpa 5.6.4 Kontrola nad nezakrpanim sustavima

Metrike trebaju podupirati odluke, a ne ukrašavati nadzorne ploče. Najsnažnije metrike za 2026. uključuju:

• Postotak usklađenosti s kritičnim SLA-ovima
• Postotak usklađenosti s visokim SLA-ovima
• Prosječno vrijeme do trijaže
• Prosječno vrijeme do otklanjanja prema klasi imovine
• Broj prekoračenih kritičnih ranjivosti
• Broj prihvaćenih iznimaka prema starosti
• Iznimke starije od 90 dana
• Broj kritičnih izloženosti prema internetu
• Kršenja SLA-ova dobavljača
• Ranjivosti ponovno otvorene nakon provjere
• Hitne promjene uzrokovane iskorištenim ranjivostima
• Neuspjele zakrpe prema platformi ili poslovnoj jedinici

Povežite te metrike s ISO/IEC 27001:2022 Clause 9.3 preispitivanjem od strane uprave, DORA izvješćivanjem o upravljanju i NIS2 nadzorom uprave. Za NIST CSF 2.0 koristite ih za ažuriranje trenutačnih i ciljanih profila, analizu praznina i akcijske planove.

Clarysec kontrolni popis za SLA otklanjanja

Koristite ovaj kontrolni popis za procjenu svojeg trenutačnog programa:

• Postoji li odobrena politika upravljanja ranjivostima i zakrpama?
• Jesu li SLA-ovi za otklanjanje definirani prema ozbiljnosti i poslovnoj kritičnosti?
• Ubrzava li se postupanje s ranjivostima izloženima internetu i iskorištenim ranjivostima?
• Je li imovina mapirana na vlasnike, usluge, podatke i dobavljače?
• Pretvaraju li se nalazi skenera u dodijeljene radne naloge?
• Provode li se zakrpe kroz upravljanje promjenama?
• Jesu li hitne promjene dokumentirane i pregledane?
• Provjeravaju li se rezultati otklanjanja ponovnim skeniranjem ili provjerama verzije?
• Jesu li iznimke procijenjene prema riziku, odobrene i pregledane najmanje svakih 90 dana?
• Jesu li kompenzacijske kontrole dokumentirane za sustave koji se ne mogu zakrpati?
• Jesu li ugovori s dobavljačima usklađeni s internim pragovima otklanjanja?
• Jesu li zapisi dnevnika zakrpa dovoljno potpuni da dokažu što se dogodilo i kada?
• Eskaliraju li se i ispravljaju kršenja SLA-a?
• Pregledava li uprava metrike?
• Pokreću li se procjene incidenata i povreda kada se sumnja na iskorištavanje?

Ako je više odgovora “ne”, problem nije u alatima. Problem je u dizajnu kontrola.

Sljedeći koraci: pretvorite rokove zakrpavanja u otpornost spremnu za reviziju

SLA-ovi za otklanjanje ranjivosti u 2026. moraju činiti više od zadovoljavanja nadzorne ploče skenera. Moraju dokazati da vaša organizacija može identificirati izloženost, prioritizirati rizik, djelovati u odobrenim rokovima, kontrolirati iznimke, upravljati dobavljačima i dokazivati odluke u skladu s revizijskim očekivanjima ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.

Clarysec vam može pomoći prijeći s fragmentiranih radnih naloga za zakrpe na integrirani program otklanjanja ranjivosti vođen dokazima koristeći:

• Politika upravljanja ranjivostima i zakrpama
• Politika upravljanja ranjivostima i zakrpama za mala i srednja poduzeća
• Politika sigurnosti trećih strana i dobavljača za mala i srednja poduzeća
• Zenith Blueprint: revizorov plan u 30 koraka
• Zenith Controls: vodič za međuokvirnu usklađenost

Počnite s jednom uslugom visokog rizika. Mapirajte njezinu imovinu, dobavljače, ranjivosti, radne naloge, promjene, iznimke i dokaze. Zatim na njoj provedite revizijska pitanja. Ako ne možete dokazati SLA od otkrivanja do zatvaranja, to je vaš prvi projekt otklanjanja.

Cilj nije savršeno zakrpavanje. Cilj je upravljano, na riziku utemeljeno, mjerljivo i revizijski provjerljivo otklanjanje. Preuzmite Clarysec predloške politika, provedite ciljanu procjenu praznina ili rezervirajte Clarysec demo kako biste otklanjanje ranjivosti pretvorili iz revizijskog pritiska u operativnu otpornost.