SLA na nápravu zraniteľností pre NIS2 a DORA

O 08:17 v utorok ráno začiatkom roka 2026 dostáva Anna, riaditeľka informačnej bezpečnosti (CISO) rýchlo rastúcej fintech spoločnosti, prvú správu ešte skôr, než dopije kávu.

SOC označilo aktívnu komunikáciu o zneužívaní zraniteľnosti v bráne API určenej pre zákazníkov. Vývojový tím uvádza, že záplata je dostupná, ale riziková, pretože brána stojí pred platobnými pracovnými tokmi. Manažér súladu preposiela formálnu žiadosť od národného príslušného orgánu, ktorý žiada dôkazy o „riešení a zverejňovaní zraniteľností“ a potvrdenie, že proces bol za posledných 12 mesiacov účinný. Obstarávanie pridáva tretí problém: bránu spravuje MSP a zmluva iba uvádza, že poskytovateľ aplikuje „bezpečnostné aktualizácie včas“.

O 09:00 už nejde iba o záplatovanie. Ide o problém dôkazov podľa ISO/IEC 27001:2022, otázku kybernetickej hygieny podľa NIS2, problém riadenia rizík IKT podľa DORA, otázku správy a riadenia dodávateľov a potenciálne aj otázku nahlasovania incidentov, ak zneužitie ovplyvní kontinuitu služby alebo osobné údaje.

Toto je praktická medzera v súlade, ktorej bude v roku 2026 čeliť mnoho organizácií. Majú skenery, panely, tikety a nástroje na záplatovanie, ale nedokážu jasne odpovedať na auditné otázky:

• Kto schválil SLA na nápravu?
• Ako je SLA založená na riziku?
• Čo sa stane, keď kritická záplata zmešká termín?
• Ako sa prioritizujú aktíva dostupné z internetu?
• Ako sa rovnaké lehoty vyžadujú od dodávateľov?
• Kde je záznam o akceptácii rizika pre nezaplátaný systém?
• Ktoré dôkazy preukazujú, že kontrola fungovala, a nielen existovala?

Odpoveďou nie je ďalšia tabuľka s termínmi. SLA na nápravu zraniteľností sa musia riadiť ako živý systém kontrol, ktorý prepája vlastníctvo aktív, skórovanie zraniteľností, spravodajské informácie o hrozbách, riadenie zmien, dodávateľské SLA, riadenie výnimiek, monitorovanie, reakciu na incidenty a preskúmanie manažmentom.

Práve tu pomáhajú podniková Politika riadenia zraniteľností a záplat (VPMP) od Clarysec, Politika riadenia zraniteľností a záplat pre SME (VPMP-SME), Politika bezpečnosti tretích strán a dodávateľov pre SME (TPSSP-SME), Zenith Blueprint (ZB) a Zenith Controls (ZC). Spoločne menia požiadavku „záplatujte rýchlejšie“ na obhájiteľný proces správy a riadenia, ktorý obstojí pri audítorskom preskúmaní podľa ISO, NIS2, DORA, GDPR, NIST a auditného prístupu ISACA.

Prečo sa SLA na nápravu zraniteľností stali dôkazom na úrovni predstavenstva

Náprava zraniteľností sa kedysi vnímala ako metrika IT hygieny. V roku 2026 má bližšie k regulovanému záväzku prevádzkovej odolnosti.

NIS2 robí z kybernetickej bezpečnosti otázku zodpovednosti manažmentu. Základné a dôležité subjekty musia zabezpečiť, aby riadiace orgány schvaľovali opatrenia riadenia kybernetických rizík, dohliadali na ich implementáciu a absolvovali školenie, aby rozumeli rizikám a dopadu bezpečnostných postupov na služby. NIS2 Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, bezpečného obstarávania a údržby, riešenia a zverejňovania zraniteľností, kybernetickej hygieny, školení, riadenia prístupu, správy aktív a autentifikácie.

Pre finančné subjekty je DORA špecializovaným režimom prevádzkovej odolnosti. Vyžaduje mechanizmy správy, riadenia a kontroly rizík IKT, pričom riadiaci orgán definuje, schvaľuje a dohliada na riadenie rizík IKT a zostáva zaň zodpovedný. Vyžaduje tiež identifikáciu aktív IKT a závislostí, kontroly ochrany a prevencie, ako je záplatovanie a riadenie zmien, riadenie incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti a riadenie rizík tretích strán v oblasti IKT.

Praktický dopad je významný. Zmeškaná lehota záplatovania môže indikovať zlyhanie:

• Správy a riadenia, ak manažment neschválil SLA založené na riziku
• Správy aktív, ak nie je známy vlastník dotknutého systému
• Riadenia zmien, ak núdzové záplatovanie nie je kontrolované
• Riadenia dodávateľov, ak sú lehoty poskytovateľa nejasné
• Reakcie na incidenty, ak sa príznaky zneužitia netriážujú
• Správy dôkazov, ak tikety a logy nedokážu preukázať uzavretie
• Ošetrenia rizík, ak výnimky nie sú schválené a preskúmavané

ISO/IEC 27001:2022 poskytuje základný rámec systému manažérstva. Kapitoly 4.1 až 4.3 vyžadujú, aby organizácie rozumeli interným a externým otázkam, požiadavkám zainteresovaných strán, zákonným a zmluvným povinnostiam a rozhraniam s inými organizáciami. Kapitoly 6.1.1 až 6.1.3 vyžadujú posúdenie rizík, ošetrenie rizík, vyhlásenie o aplikovateľnosti a schválenie zvyškového rizika vlastníkom rizika. Kapitoly 9.1, 9.2, 9.3, 10.1 a 10.2 vyžadujú monitorovanie, vnútorný audit, preskúmanie manažmentom, neustále zlepšovanie, nápravné opatrenia a uchovávané dôkazy.

Jednoducho povedané, ak chcete mať SLA na nápravu zraniteľností pripravené na audit, musia byť súčasťou ISMS, nielen metrikou DevOps.

Model SLA, ktorý audítori očakávajú

SLA na nápravu zraniteľností má odpovedať na tri otázky:

1. Ako rýchlo musíme konať?
2. Kto nesie preukázateľnú zodpovednosť?
3. Aké dôkazy preukazujú výsledok?

Politika riadenia zraniteľností a záplat definuje praktický výchiskový bod pre lehoty nápravy založené na riziku:

Organizácia musí klasifikovať všetky zistené zraniteľnosti pomocou štandardizovanej metodiky (napr. CVSS v3.x) a uplatňovať lehoty nápravy zosúladené s kritickosťou pre činnosť organizácie: 5.2.1 Kritická (CVSS 9.0-10.0): okamžité preskúmanie; lehota záplatovania maximálne 72 hodín. 5.2.2 Vysoká (7.0-8.9): reakcia do 48 hodín; lehota záplatovania 7 kalendárnych dní. 5.2.3 Stredná (4.0-6.9): reakcia do 5 dní; lehota záplatovania 30 kalendárnych dní. 5.2.4 Nízka (<4.0): reakcia do 10 dní; lehota záplatovania 60 kalendárnych dní.

Táto požiadavka je silná, pretože oddeľuje čas reakcie od lehoty záplatovania. Vysoká zraniteľnosť nemá zostať šesť dní nepovšimnutá a až na siedmy deň byť opravená. Čas reakcie potvrdzuje triáž, vlastníctvo, posúdenie dopadu a plánovanie nápravy. Lehota záplatovania potvrdzuje technické uzavretie alebo schválenú výnimku.

Pre menšie organizácie používa Politika riadenia zraniteľností a záplat pre SME jednoduchší, ale stále auditovateľný jazyk:

Kritické záplaty musia byť aplikované do 3 dní od vydania, najmä pri systémoch dostupných z internetu

A pre širšie portfólio záplat:

Všetky ostatné záplaty musia byť aplikované do 30 dní, pokiaľ nie je zdokumentovaná platná výnimka

Podstatou nie je, že každá organizácia musí používať identické lehoty. ISO/IEC 27001:2022, NIS2 aj DORA podporujú proporcionalitu. Podstatné je, že SLA na nápravu musia byť definované, schválené, založené na riziku, monitorované a doložené dôkazmi.

Práve tu mnohé spoločnosti zlyhávajú. Definujú SLA, ale nedefinujú dôkazy. Z pohľadu audítora je politika bez prevádzkových záznamov prísľub, nie kontrola.

Vlastníctvo aktív je skrytá závislosť

Skener vám povie, že na serveri existuje CVE. Nepovie vám však, či server podporuje kritický platobný proces, uchováva osobné údaje osobitnej kategórie, pripája sa na poskytovateľa vyrovnania alebo je naplánovaný na vyradenie.

Tento kontext pochádza zo správy aktív, klasifikácie údajov, evidencie dodávateľov a posúdenia rizík.

Kontrola 8.8 v prílohe A ISO/IEC 27001:2022, riadenie technických zraniteľností, je kľúčová, ale nefunguje izolovane. Silno závisí od riadenia konfigurácie, riadenia zmien, monitorovania dodávateľov, správy a riadenia cloudu, logovania, monitorovania a ošetrenia rizík.

NIST CSF 2.0 vyjadruje rovnaký problém jazykom výsledkov. Funkcia GOVERN očakáva, že právne, regulačné a zmluvné požiadavky na kybernetickú bezpečnosť budú pochopené a riadené, apetít na riziko a tolerancia rizika budú zdokumentované, roly a zdroje priradené a politiky kybernetickej bezpečnosti budú zavedené, uplatňované, preskúmavané a aktualizované. Výsledky IDENTIFY zahŕňajú inventáre hardvéru, softvéru, služieb, systémov, údajov a životného cyklu spolu s identifikáciou zraniteľností, analýzou rizík, riadením výnimiek a procesmi zverejňovania zraniteľností.

V Anninom utorkovom rannom scenári je prvá technická otázka: „kde je zraniteľný komponent?“ Prvá otázka správy a riadenia znie: „ktorú službu a aké riziko ovplyvňuje?“

Zenith Blueprint, fáza Riadenie rizík, krok 13: Plánovanie ošetrenia rizík a vyhlásenie o aplikovateľnosti, to rieši prepájaním rizík s kontrolami, vlastníkmi a termínmi:

Každej činnosti tiež priraďte vlastníka a termín (napríklad v samostatnom stĺpci alebo v komentároch). Napr. „Vlastník: IT manažér, termín: do Q3 2025.“ Tým sa z toho stáva skutočný plán.

Presne to náprava zraniteľností vyžaduje. Zistenie bez vlastníka sa stáva šumom v zozname nevybavených položiek. Zistenie s vlastníkom, termínom, rozhodnutím o ošetrení rizika a auditnou stopou dôkazov sa stáva auditovateľnou kontrolou.

Ako Zenith Controls mapuje väzby medzi kontrolami

Zenith Controls považuje kontrolu 8.8 ISO/IEC 27002:2022, riadenie technických zraniteľností, za preventívnu kontrolu podporujúcu dôvernosť, integritu a dostupnosť. Prepája ju s konceptmi kybernetickej bezpečnosti Identify a Protect, s prevádzkovou schopnosťou riadenia hrozieb a zraniteľností a s bezpečnostnými doménami správy a riadenia, ekosystému, ochrany a obrany.

Je to dôležité, pretože SLA na nápravu nie sú iba ochranným mechanizmom. Sú aj mechanizmom správy a riadenia a ekosystémovým mechanizmom. Vaša expozícia je formovaná dodávateľmi, cloudovými platformami, spravovanými službami, komponentmi s otvoreným zdrojovým kódom a závislosťami dostupnými z internetu.

Zenith Controls mapuje 8.8 na viaceré podporné kontroly:

Zenith Controls tiež prepája riadenie zraniteľností s ISO/IEC 27005:2024, najmä s identifikáciou zraniteľností a rizikovými scenármi zahŕňajúcimi nezaplátané systémy. Posilňuje to argument, že lehoty záplatovania majú byť založené na riziku, nie ľubovoľné. Zároveň prepája monitorovanie dodávateľov s ISO/IEC 27036-4:2016 pre bezpečnostné úrovne dohôd o cloudových službách a ISO/IEC 20000-1:2018 pre plánovanie dodávky služieb a riadenie zmien.

Táto medzinormová štruktúra je počas auditu dôležitá. Ak organizácia tvrdí, že „kritické zraniteľnosti sú zaplátané do 72 hodín“, audítor otestuje, či je toto tvrdenie podporené posúdením rizík, klasifikáciou aktív, povinnosťami dodávateľov, záznamami o zmenách a dôkazmi z monitorovania.

Kybernetická hygiena NIS2: od riešenia zraniteľností k nápravným opatreniam

NIS2 Article 21 vyžaduje prístup k sieťovým a informačným systémom založený na všetkých druhoch hrozieb. Pre SLA na nápravu zraniteľností sú priamo relevantné viaceré prvky Article 21:

• Analýza rizík a politiky bezpečnosti informačných systémov
• Riešenie incidentov
• Kontinuita činností a krízové riadenie
• Bezpečnosť dodávateľského reťazca
• Bezpečné obstarávanie, vývoj a údržba vrátane riešenia a zverejňovania zraniteľností
• Postupy na posudzovanie účinnosti kybernetickej bezpečnosti
• Základná kybernetická hygiena a školenie
• Riadenie prístupu a správa aktív
• Viacfaktorová autentifikácia alebo priebežná autentifikácia tam, kde je to vhodné

NIS2 Article 20 robí riadiace orgány zodpovednými za schvaľovanie a dohľad nad opatreniami riadenia kybernetických rizík. To znamená, že metriky nápravy zraniteľností nemôžu existovať iba v inžinierskom paneli. Majú byť zahrnuté v manažérskom reportingu, podkladoch pre rizikový výbor alebo záznamoch z preskúmania ISMS manažmentom.

Article 21 tiež očakáva, že subjekty, ktoré zistia nesúlad s požadovanými opatreniami, prijmú nápravné opatrenia bez zbytočného odkladu. Táto formulácia je dôležitá. Ak váš panel ukazuje kritické zraniteľnosti po lehote, dôkazy súladu sa nemajú skončiť pri „vieme o tom“. Majú preukázať eskaláciu, preskúmanie rizika, viditeľnosť pre manažment, nápravné opatrenia a prehodnotenie.

NIS2 Article 23 pridáva ďalší rozmer. Ak zneužitie nezaplátanej zraniteľnosti spôsobí alebo je spôsobilé spôsobiť závažné narušenie prevádzky, finančnú stratu alebo ujmu iným osobám, môže ísť o významný incident. Životný cyklus nahlasovania zahŕňa včasné varovanie do 24 hodín od nadobudnutia vedomosti o významnom incidente, oznámenie incidentu do 72 hodín, priebežné správy na požiadanie a záverečnú správu do jedného mesiaca po oznámení incidentu. Záverečná správa má obsahovať závažnosť, dopad, pravdepodobnú koreňovú príčinu, zmierňujúce opatrenia a prípadný cezhraničný dopad.

Proces SLA preto musí byť prepojený s reakciou na incidenty. Kritická zraniteľnosť s dôkazmi o aktívnom zneužívaní má spustiť bezpečnostnú triáž, monitorovanie, uchovanie dôkazov a posúdenie oznamovacej povinnosti, nie iba rutinný tiket na záplatu.

Riziko IKT podľa DORA: lehoty nápravy ako dôkaz odolnosti

Pre finančné subjekty sa DORA uplatňuje od 17. januára 2025 a vytvára jednotné požiadavky naprieč riadením rizík IKT, hlásením závažných incidentov súvisiacich s IKT, testovaním digitálnej prevádzkovej odolnosti, výmenou informácií a riadením rizík tretích strán v oblasti IKT. Pre kryté finančné subjekty identifikované podľa vnútroštátnych pravidiel NIS2 sa považuje za sektorovo špecifický právny akt EÚ.

Prevádzkový model DORA je blízky integrovanému ISMS. Articles 5 a 6 vyžadujú správu a riadenie, politiky, postupy, nástroje, ročné alebo pravidelné preskúmanie, audit, nápravu kritických auditných zistení a stratégiu digitálnej prevádzkovej odolnosti. Article 8 vyžaduje identifikáciu a inventarizáciu činností podporovaných IKT, informačných aktív, aktív IKT, závislostí, procesov tretích strán a rizík zastaraných IKT. Article 9 vyžaduje kontroly ochrany a prevencie vrátane záplatovania a riadenia zmien. Articles 11 a 12 vyžadujú kontinuitu, reakciu, obnovu, zálohovanie, rekonštrukciu a ciele obnovy.

DORA Articles 17 až 19 vyžadujú proces riadenia incidentov súvisiacich s IKT, ktorý deteguje, riadi, zaznamenáva, klasifikuje, eskaluje, oznamuje, komunikuje, analyzuje koreňovú príčinu a obnovuje bezpečnú prevádzku. Articles 24 až 26 vyžadujú testovanie digitálnej prevádzkovej odolnosti vrátane primeraného testovania nástrojov a systémov IKT, posúdení zraniteľností, posúdení bezpečnosti sietí, analýz medzier, preskúmaní zdrojového kódu tam, kde je to uskutočniteľné, penetračného testovania a penetračného testovania na základe hrozieb pre určité finančné subjekty. Articles 28 a 30 vyžadujú riadenie rizika tretích strán v oblasti IKT, registre zmlúv o službách IKT, due diligence, práva na audit a kontrolu, úrovne služieb, pomoc poskytovateľa počas incidentov, práva na ukončenie a výstupné mechanizmy.

Pri SLA na nápravu mení DORA očakávania týkajúce sa dôkazov tromi spôsobmi.

Po prvé, zistenia zraniteľností z testovania musia vstupovať do prioritizovaného procesu nápravy. Správa zo skenu nestačí.

Po druhé, náprava kritických zistení musí byť sledovaná cez správu a riadenie a audit. DORA očakáva formálnu nápravu kritických auditných zistení pri subjektoch, ktoré nie sú mikropodnikmi.

Po tretie, externí poskytovatelia IKT musia byť viazaní merateľnými povinnosťami. Ak váš poskytovateľ cloudu, SaaS alebo MSP kontroluje okno záplatovania, vaša zmluva a register musia ukazovať, ako ich lehoty nápravy podporujú vaše povinnosti v oblasti odolnosti.

Politika riadenia zraniteľností a záplat to rieši priamo:

Záplatovanie tretích strán a dohľad nad rizikom SaaS 6.6.1 Všetky systémy tretích strán (SaaS, PaaS, spravované MSP) musia preukázať primerané kontroly riadenia zraniteľností a záplat. 6.6.2 SLA dodávateľov musia obsahovať lehoty nápravy rovnocenné s interne definovanými prahovými hodnotami založenými na kritickosti.

Táto požiadavka je často chýbajúcim mostom medzi internými dôkazmi ISO a dohľadom nad dodávateľmi podľa DORA.

GDPR: keď oneskorené záplaty vedú k zlyhaniu zodpovednosti za osobné údaje

GDPR nie je norma riadenia zraniteľností, ale mení dôsledky zlyhania záplatovania.

GDPR Article 5 vyžaduje, aby sa osobné údaje spracúvali bezpečne, a vyžaduje, aby prevádzkovateľ vedel preukázať súlad. Article 32 vyžaduje primerané technické a organizačné opatrenia na zabezpečenie úrovne bezpečnosti primeranej riziku. Keď nezaplátané systémy spracúvajú osobné údaje, najmä údaje o identite, finančné údaje, biometrické údaje, zdravotné údaje, pracovnoprávne údaje alebo informácie KYC, SLA na nápravu sa stávajú súčasťou zodpovednosti za bezpečnosť spracúvania.

Oneskorená záplata môže byť obhájiteľná, ak bolo riziko posúdené, boli uplatnené kompenzačné kontroly a zvyškové riziko akceptovala správna osoba. Oveľa ťažšie sa obhajuje situácia, keď bola zraniteľnosť po lehote, dostupná z internetu a bez vlastníka.

Zenith Controls mapuje riadenie zraniteľností na GDPR Articles 32 a 5(1)(f), pretože včasné záplatovanie znižuje riziká pre dôvernosť a integritu osobných údajov. Mapuje tiež riadenie zmien na GDPR Article 24 a Article 32, pretože zmeny v systémoch spracúvajúcich osobné údaje majú byť posúdené z hľadiska rizika, schválené, zdokumentované a preskúmané.

Poučenie pre súlad je jednoduché: ak ide o osobné údaje, dôkazy o záplatovaní majú obsahovať aj dátový kontext. Audítori a regulátori sa nebudú pýtať iba „bolo to zaplátané?“, ale aj „aké údaje boli vystavené riziku, ako dlho a aké kontroly toto riziko znížili?“

Praktický pracovný tok Clarysec pre auditovateľné dôkazy o SLA

Zrelý proces nápravy zraniteľností nezačína vtedy, keď audítor požiada o záznamy. Je navrhnutý tak, aby záznamy vytváral každý mesiac.

Krok 1: Schváľte politiku SLA

Začnite s Politikou riadenia zraniteľností a záplat alebo Politikou riadenia zraniteľností a záplat pre SME podľa vášho prevádzkového modelu. Prispôsobte prahové hodnoty SLA vášmu apetítu na riziko, regulačnému rozsahu, kritickosti služieb, citlivosti údajov a technickým obmedzeniam. Zabezpečte schválenie CISO, rizikovým výborom alebo riadiacim orgánom.

Pre podnikové prostredia používajte CVSS, kritickosť aktív, zneužiteľnosť, dostupnosť z internetu, citlivosť údajov a dopad na podnikanie. Pre SME udržte model jednoduchý, ale explicitný: kritické záplaty do troch dní, ostatné záplaty do 30 dní, pokiaľ neexistuje platná výnimka.

Krok 2: Namapujte aktíva na vlastníkov a kritické služby

Každé zistenie zraniteľnosti sa má priradiť k týmto údajom:

• Názov aktíva a jedinečný identifikátor
• Služba alebo aplikácia organizácie
• Vlastník systému
• Technický vlastník
• Klasifikácia údajov
• Dostupnosť z internetu
• Závislosť od dodávateľa, ak je relevantná
• Kritickosť podporovanej funkcie

Podporuje to vlastníctvo rizika podľa ISO/IEC 27001:2022, správu aktív podľa NIS2, inventár aktív a závislostí IKT podľa DORA a výsledky IDENTIFY v NIST CSF.

Krok 3: Vykonajte triáž zraniteľnosti

Vytvorte tiket pre každé zistenie alebo zoskupenú množinu zistení. Uveďte skóre CVSS, zdrojový skener, dotknuté aktívum, stav zneužitia, spravodajské informácie o hrozbách, kritickosť pre organizáciu a požadovanú SLA. Ak existuje podozrenie na zneužitie, prepojte tiket s posúdením incidentu.

Krok 4: Vykonajte nápravu cez riadenie zmien

Záplatovanie je zmena. Pri rutinných aktualizáciách použite štandardnú zmenu a pri kritických zneužívaných zraniteľnostiach núdzovú zmenu. Zahrňte dôkazy o testovaní, schválenie, časovú pečiatku implementácie, plán vrátenia zmien a validáciu po zmene.

Zodpovedá to väzbe Zenith Controls medzi 8.8 a 8.32, kde sa aplikovanie záplat riadi cez riadenie zmien s cieľom vyvážiť naliehavosť a prevádzkovú stabilitu.

Krok 5: Validujte uzavretie

Neuzatvárajte tikety iba na základe tvrdenia „záplata nainštalovaná“. Vyžadujte validáciu opätovným skenovaním, potvrdením verzie, overením konfigurácie alebo potvrdením kompenzačnej kontroly. Ak záplatu nemožno aplikovať, otvorte výnimku.

Krok 6: Zaznamenajte výnimky a zvyškové riziko

Politika riadenia zraniteľností a záplat definuje požadovaný obsah výnimky:

Žiadosti o výnimku musia obsahovať: 7.2.1 Obchodné odôvodnenie oneskorenia alebo nevykonania nápravy 7.2.2 Posúdenie rizík (na základe CVSS, kritickosti aktíva, spravodajských informácií o hrozbách) 7.2.3 Navrhované kompenzačné kontroly 7.2.4 Časový plán nápravy alebo prehodnotenia

Definuje tiež schválenie a preskúmanie:

Výnimky musí schváliť CISO alebo delegovaný rizikový výbor a musia byť zaznamenané v registri výnimiek ISMS, s intervalom preskúmania nepresahujúcim 90 dní.

Tento register výnimiek sa stáva nevyhnutným dôkazom pre ošetrenie rizík a akceptáciu zvyškového rizika podľa kapitoly 6.1.3 ISO/IEC 27001:2022, ako aj pre preskúmanie manažmentom.

Tento záznam preukazuje, že organizácia zraniteľnosť neignorovala. Posúdila riziko, aplikovala kompenzačné kontroly, schválila zvyškové riziko a stanovila dátum preskúmania.

Krok 7: Vytvorte mesačný balík dôkazov

Váš mesačný balík dôkazov o náprave zraniteľností má obsahovať:

Pre SME môžu byť dôkazy ľahšie, ale musia byť konzistentné. Politika riadenia zraniteľností a záplat pre SME vyžaduje logy záplat so sledovateľnosťou:

Logy musia obsahovať názov zariadenia, aplikovanú aktualizáciu, dátum záplatovania a dôvod prípadného oneskorenia

Táto jediná požiadavka má vysokú auditnú hodnotu. Mení záplatovanie z tvrdenia na záznam.

Záplatovanie u dodávateľov: zmluva musí zodpovedať vašej SLA

Ak nasadenie záplat kontroluje MSP, poskytovateľ SaaS, poskytovateľ PaaS alebo poskytovateľ cloudových služieb, interné SLA sú bezcenné, pokiaľ im nezodpovedajú povinnosti dodávateľa.

Politika bezpečnosti tretích strán a dodávateľov pre SME zahŕňa povinnosti informačnej bezpečnosti ako požiadavku správy a riadenia. Pri náprave zraniteľností sa tieto povinnosti majú premietnuť do merateľného zmluvného jazyka:

• Lehoty oznámenia kritických zraniteľností
• Lehoty nápravy pre kritické, vysoké, stredné a nízke zraniteľnosti
• Proces núdzovej zmeny
• Požiadavky na schválenie odstávky zákazníkom
• Formát dôkazov o dokončení záplaty
• Proces zverejňovania zraniteľností
• Povinnosti pomoci pri incidente
• Právo na audit alebo prijímanie správ o uistení
• Povinnosti ďalších sprostredkovateľov alebo subdodávateľov pri záplatovaní
• Podpora pri ukončení a prechode pri kritických službách

Zenith Blueprint, fáza Kontroly v praxi, krok 20, kontrola 8.21 Bezpečnosť sieťových služieb, formuluje princíp jasne:

Ak služby poskytujú externé strany vrátane ISP, dodávateľov SD-WAN alebo poskytovateľov súkromného cloudu, bezpečnostné požiadavky musia byť zabudované do zmlúv a SLA. Zahŕňa to garancie dostupnosti, časy reakcie na incidenty, povinnosti záplatovať alebo zmierňovať zraniteľnosti a jasné hranice nakladania s údajmi. Nikdy nepredpokladajte, že poskytovateľ plní vaše očakávania, pokiaľ to nie je písomne stanovené, merateľné a auditovateľné.

DORA to robí obzvlášť dôležitým pre finančné subjekty. Dohody s tretími stranami v oblasti IKT musia obsahovať úrovne služieb, pomoc poskytovateľa počas incidentov IKT, prístup k údajom a ich obnovu, spoluprácu s orgánmi, práva na ukončenie a silnejšie ustanovenia pre kritické alebo dôležité funkcie vrátane monitorovania, práv na audit, plánov pre mimoriadne situácie a bezpečnostných opatrení.

NIST CSF 2.0 hovorí to isté prostredníctvom výsledkov rizika dodávateľského reťazca: dodávatelia majú byť známi, prioritizovaní podľa kritickosti, posúdení pred začatím spolupráce, riadení zmluvnými požiadavkami, monitorovaní počas celého vzťahu, zahrnutí do plánovania incidentov a riadení pri ukončení.

Na čo sa audítori skutočne opýtajú

Auditná diskusia sa mení podľa zamerania audítora.

Audítor ISO/IEC 27001:2022 začne pri ISMS. Overí, či je riadenie zraniteľností zahrnuté vo vyhlásení o aplikovateľnosti, či posúdenie rizík identifikuje nezaplátané systémy ako riziko, či plány ošetrenia rizík majú vlastníkov a termíny, či je implementovaná kontrola 8.8 prílohy A, či sa uchovávajú dôkazy a či vnútorný audit a preskúmanie manažmentom hodnotia výkonnosť.

Zenith Blueprint, fáza Kontroly v praxi, krok 19, explicitne uvádza auditné očakávanie:

Toto je pre audítorov kontrola s vysokou prioritou a zvyčajne pôjdu do hĺbky. Očakávajte otázky, ako často sa systémy záplatujú, aký proces používate pri oznámení zero-day a ktoré systémy sa záplatujú najťažšie.

Pokračuje praktickými očakávaniami týkajúcimi sa dôkazov:

Audítori si pravdepodobne vyžiadajú výsledky skenovania zraniteľností. Ak používate nástroje ako Nessus, OpenVAS alebo Qualys, exportujte správu zobrazujúcu nedávno zistené zraniteľnosti a spôsob ich riešenia. Ideálne má obsahovať hodnotenia rizík (CVSS) a lehoty nápravy.

Audítor alebo príslušný orgán zameraný na NIS2 bude hľadať schválenie predstavenstvom, proporcionalitu, kybernetickú hygienu, riešenie zraniteľností, bezpečnosť dodávateľov, riešenie incidentov, posúdenie účinnosti, nápravné opatrenia bez zbytočného odkladu a záznamy o rozhodnutí o nahlásení, ak zneužitie spôsobilo významný dopad.

Dohľadový orgán podľa DORA bude testovať, či sú zistenia zraniteľností integrované do riadenia rizík IKT, testovania digitálnej prevádzkovej odolnosti, klasifikácie incidentov, analýzy koreňovej príčiny, registrov tretích strán, zmluvných povinností, práv na audit a nápravy kritických zistení.

Posudzovateľ NIST CSF pravdepodobne usporiada preskúmanie podľa funkcií GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. Bude sa pýtať, či sú pochopené právne a zmluvné požiadavky, či je zdokumentovaná tolerancia rizika, či sa zraniteľnosti identifikujú a prioritizujú, či sa riadia výnimky, či monitorovanie deteguje zneužitie a či sú koordinované reakčné a obnovovacie činnosti.

Audítor podľa COBIT 2019 alebo prístupu ISACA sa zameria na ciele správy a riadenia, procesnú spôsobilosť, manažérske postupy, metriky, vlastníctvo, návrh kontrol, prevádzku kontrol a dostatočnosť dôkazov. Bude sa pýtať, či je náprava zraniteľností opakovateľná, meraná, eskalovaná, zlepšovaná a zosúladená s cieľmi podniku a apetítom na riziko.

Eskalácia a metriky: ako preukázať, že SLA je riadená

SLA bez eskalácie je iba cieľ. Obhájiteľný program nápravy zraniteľností potrebuje eskaláciu pred porušením lehoty, pri porušení lehoty a po opakovanom zlyhaní.

Clarysec odporúča štvorúrovňový model eskalácie:

1. Operatívna eskalácia, vlastník tiketu a technický vedúci sú upozornení pred porušením lehoty.
2. Eskalácia rizika, vlastník aktíva a vlastník rizika preskúmajú dopad, keď je porušenie lehoty pravdepodobné.
3. Eskalácia bezpečnostnej správy a riadenia, CISO alebo rizikový výbor schvaľuje výnimku alebo núdzové opatrenie.
4. Eskalácia na manažment, opakované alebo kritické porušenia SLA sa reportujú do preskúmania manažmentom spolu s nápravnými opatreniami.

Politika riadenia zraniteľností a záplat posilňuje toto auditné očakávanie:

Pravidelné audity musí vykonávať vnútorný audit alebo nezávislá tretia strana na overenie: 5.6.1 Súlad so SLA 5.6.2 Dôkazov o prioritizácii založenej na riziku 5.6.3 Účinnosti nasadených záplat 5.6.4 Kontrol nad nezaplátanými systémami

Metriky majú podporovať rozhodnutia, nie zdobiť panely. Medzi najsilnejšie metriky pre rok 2026 patria:

• Percento súladu s kritickými SLA
• Percento súladu s vysokými SLA
• Priemerný čas do triáže
• Priemerný čas nápravy podľa triedy aktív
• Počet kritických zraniteľností po lehote
• Počet akceptovaných výnimiek podľa veku
• Výnimky presahujúce 90 dní
• Počet kritických expozícií dostupných z internetu
• Porušenia SLA dodávateľov
• Zraniteľnosti znovu otvorené po validácii
• Núdzové zmeny spôsobené zneužívanými zraniteľnosťami
• Zlyhania záplat podľa platformy alebo obchodnej jednotky

Prepojte tieto metriky s preskúmaním manažmentom podľa kapitoly 9.3 ISO/IEC 27001:2022, reportingom správy a riadenia podľa DORA a dohľadom manažmentu podľa NIS2. Pre NIST CSF 2.0 ich použite na aktualizáciu aktuálnych a cieľových profilov, analýzu medzier a akčné plány.

Kontrolný zoznam Clarysec pre SLA nápravy

Použite tento kontrolný zoznam na vyhodnotenie vášho aktuálneho programu:

• Existuje schválená politika riadenia zraniteľností a záplat?
• Sú SLA na nápravu definované podľa závažnosti a kritickosti pre činnosť organizácie?
• Urýchľuje sa riešenie zraniteľností dostupných z internetu a zneužívaných zraniteľností?
• Sú aktíva namapované na vlastníkov, služby, údaje a dodávateľov?
• Premieňajú sa zistenia skenerov na priradené tikety?
• Vykonávajú sa záplaty cez riadenie zmien?
• Sú núdzové zmeny zdokumentované a preskúmané?
• Validujú sa výsledky nápravy opätovnými skenmi alebo kontrolami verzie?
• Sú výnimky posúdené z hľadiska rizika, schválené a preskúmavané aspoň každých 90 dní?
• Sú kompenzačné kontroly pre nezáplatovateľné systémy zdokumentované?
• Sú zmluvy s dodávateľmi zosúladené s internými prahmi nápravy?
• Sú logy záplat dostatočne úplné na preukázanie toho, čo sa stalo a kedy?
• Sú porušenia SLA eskalované a opravované?
• Preskúmava manažment metriky?
• Spúšťajú sa posúdenia incidentov a porušení ochrany údajov, keď existuje podozrenie na zneužitie?

Ak je viacero odpovedí „nie“, problémom nie sú nástroje. Problémom je návrh kontrol.

Ďalšie kroky: premeňte lehoty záplatovania na auditovateľnú odolnosť

SLA na nápravu zraniteľností v roku 2026 musia robiť viac než uspokojiť panel skenera. Musia preukázať, že vaša organizácia dokáže identifikovať expozíciu, prioritizovať riziko, konať v schválených lehotách, riadiť výnimky, spravovať dodávateľov a dokladovať rozhodnutia naprieč očakávaniami auditov podľa ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

Clarysec vám môže pomôcť prejsť od fragmentovaných tiketov záplatovania k integrovanému programu nápravy zraniteľností založenému na dôkazoch pomocou:

• Politika riadenia zraniteľností a záplat
• Politika riadenia zraniteľností a záplat pre SME
• Politika bezpečnosti tretích strán a dodávateľov pre SME
• Zenith Blueprint: 30-kroková cestovná mapa audítora
• Zenith Controls: príručka súladu naprieč rámcami

Začnite jednou vysoko rizikovou službou. Namapujte jej aktíva, dodávateľov, zraniteľnosti, tikety, zmeny, výnimky a dôkazy. Potom na ňu aplikujte auditné otázky. Ak nedokážete preukázať SLA od detekcie po uzavretie, je to váš prvý projekt nápravy.

Cieľom nie je dokonalé záplatovanie. Cieľom je riadená, na riziku založená, merateľná a auditovateľná náprava. Stiahnite si šablóny politík Clarysec, vykonajte cielené posúdenie medzier alebo si objednajte demo Clarysec a premeňte nápravu zraniteľností z auditného tlaku na prevádzkovú odolnosť.