SLA pro nápravu zranitelností podle NIS2 a DORA

V úterý ráno na začátku roku 2026, v 08:17, dostává Anna, ředitelka informační bezpečnosti rychle rostoucí fintech společnosti, první zprávu ještě dříve, než dopije kávu.

SOC zachytil komunikaci o aktivním zneužívání zranitelnosti v API bráně vystavené zákazníkům. Engineering uvádí, že záplata je dostupná, ale riziková, protože brána stojí před platebními procesy. Manažer compliance přeposílá formální žádost národního příslušného orgánu, který požaduje důkazy o „řešení a oznamování zranitelností“ a doklad, že proces byl v posledních 12 měsících účinný. Oddělení nákupu přidává třetí problém: bránu spravuje MSP a smlouva pouze uvádí, že poskytovatel bude aplikovat „bezpečnostní aktualizace včas“.

V 09:00 už nejde jen o záplatování. Jde o důkazy podle ISO/IEC 27001:2022, kybernetickou hygienu podle NIS2, řízení ICT rizik podle DORA, řízení dodavatelů a potenciálně také o hlášení incidentů, pokud zneužití ovlivní kontinuitu služby nebo osobní údaje.

Toto je praktická mezera v compliance, které bude v roce 2026 čelit mnoho organizací. Mají skenery, řídicí panely, tikety a nástroje pro záplatování, ale nedokážou jasně odpovědět na auditní otázky:

• Kdo schválil SLA pro nápravu?
• Jak je SLA založeno na rizicích?
• Co se stane, když kritická záplata překročí lhůtu?
• Jak jsou prioritizována internetově dostupná aktiva?
• Jak jsou dodavatelé vázáni stejnými lhůtami?
• Kde je záznam o akceptaci rizika u nezáplatovaného systému?
• Které důkazy prokazují, že opatření fungovalo, nikoli pouze existovalo?

Odpovědí není další tabulka s termíny splnění. SLA pro nápravu zranitelností musí být řízena jako živý systém opatření, který propojuje vlastnictví aktiv, skórování zranitelností, informace o hrozbách, řízení změn, SLA dodavatelů, řízení výjimek, monitorování, reakci na incidenty a přezkoumání vedením.

Právě zde pomáhají podniková Politika řízení zranitelností a záplat (VPMP) od Clarysec, Politika řízení zranitelností a záplat pro SME (VPMP-SME), Bezpečnostní politika pro dodavatele a poskytovatele služeb třetích stran pro SME (TPSSP-SME), Zenith Blueprint (ZB) a Zenith Controls (ZC). Společně převádějí požadavek „záplatovat rychleji“ na obhajitelný proces správy a řízení, který obstojí při auditním přezkumu ve stylu ISO, NIS2, DORA, GDPR, NIST a ISACA.

Proč se SLA pro nápravu zranitelností stala důkazem pro řídicí orgány

Náprava zranitelností se dříve vnímala jako metrika IT hygieny. V roce 2026 se blíží regulovanému závazku provozní odolnosti.

NIS2 činí z kybernetické bezpečnosti otázku odpovědnosti vedení. Základní a důležité subjekty musí zajistit, aby jejich řídicí orgány schvalovaly opatření k řízení kybernetických bezpečnostních rizik, dohlížely na jejich zavedení a absolvovaly školení, aby rozuměly rizikům a dopadu bezpečnostních postupů na služby. NIS2 Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, bezpečného pořizování a údržby, řešení a oznamování zranitelností, kybernetické hygieny, školení, řízení přístupu, správy aktiv a autentizace.

Pro finanční subjekty je DORA specializovaným režimem provozní odolnosti. Vyžaduje ujednání pro správu a řízení ICT rizik a kontrolní mechanismy, přičemž řídicí orgán definuje, schvaluje a dohlíží na řízení ICT rizik a zůstává za ně odpovědný. Vyžaduje také identifikaci ICT aktiv a závislostí, ochranná a preventivní opatření, jako je záplatování a řízení změn, řízení incidentů souvisejících s ICT, testování digitální provozní odolnosti a řízení ICT rizik třetích stran.

Praktický dopad je významný. Nedodržení lhůty pro záplatu může ukazovat na selhání v těchto oblastech:

• Správa a řízení, pokud vedení neschválilo SLA založená na rizicích
• Správa aktiv, pokud není znám vlastník dotčeného systému
• Řízení změn, pokud nouzové záplatování není řízeno
• Řízení dodavatelů, pokud jsou lhůty poskytovatele vágní
• Reakce na incidenty, pokud nejsou tříděny známky zneužití
• Správa důkazů, pokud tikety a logy nedokážou prokázat uzavření
• Ošetření rizik, pokud výjimky nejsou schváleny a přezkoumávány

ISO/IEC 27001:2022 poskytuje páteř systému řízení. Články 4.1 až 4.3 vyžadují, aby organizace rozuměly interním a externím otázkám, požadavkům zainteresovaných stran, právním a smluvním povinnostem a rozhraním s jinými organizacemi. Články 6.1.1 až 6.1.3 vyžadují posouzení rizik, ošetření rizik, Prohlášení o aplikovatelnosti a schválení zbytkového rizika vlastníkem rizika. Články 9.1, 9.2, 9.3, 10.1 a 10.2 vyžadují monitorování, interní audit, přezkoumání vedením, neustálé zlepšování, nápravná opatření a uchovávané důkazy.

Jednoduše řečeno: pokud mají být SLA pro nápravu zranitelností připravena na audit, musí být součástí ISMS, ne pouze metrikou DevOps.

Model SLA, který auditoři očekávají

SLA pro nápravu zranitelností má odpovědět na tři otázky:

1. Jak rychle musíme jednat?
2. Kdo nese odpovědnost?
3. Jaké důkazy prokazují výsledek?

Politika řízení zranitelností a záplat definuje praktický výchozí bod pro lhůty nápravy založené na rizicích:

Organizace musí klasifikovat všechny detekované zranitelnosti pomocí standardizované metodiky (např. CVSS v3.x) a uplatnit lhůty nápravy sladěné s kritičností pro podnikání: 5.2.1 Kritické (CVSS 9.0-10.0): okamžité posouzení; lhůta pro záplatování maximálně 72 hodin. 5.2.2 Vysoké (7.0-8.9): reakce do 48 hodin; lhůta pro záplatování 7 kalendářních dnů. 5.2.3 Střední (4.0-6.9): reakce do 5 dnů; lhůta pro záplatování 30 kalendářních dnů. 5.2.4 Nízké (<4.0): reakce do 10 dnů; lhůta pro záplatování 60 kalendářních dnů.

Toto ustanovení je silné, protože odděluje reakční dobu od lhůty pro záplatování. Zranitelnost s vysokou závažností nemá zůstat šest dnů bez povšimnutí a být záplatována sedmý den. Reakční lhůta potvrzuje triáž, vlastnictví, posouzení dopadu a plánování nápravy. Lhůta pro záplatování potvrzuje technické uzavření nebo schválenou výjimku.

Pro menší organizace používá Politika řízení zranitelností a záplat pro SME jednodušší, ale stále auditovatelné znění:

Kritické záplaty musí být aplikovány do 3 dnů od vydání, zejména u internetově dostupných systémů

A pro širší oblast záplat:

Všechny ostatní záplaty musí být aplikovány do 30 dnů, pokud není zdokumentována platná výjimka

Podstatou není to, že každá organizace musí používat totožné lhůty. ISO/IEC 27001:2022, NIS2 i DORA podporují proporcionalitu. Podstatou je, že SLA pro nápravu musí být definována, schválena, založena na rizicích, monitorována a doložena.

Právě zde mnoho společností selhává. Definují SLA, ale nedefinují důkazy. Z pohledu auditora je politika bez provozních záznamů slib, nikoli opatření.

Vlastnictví aktiv je skrytá závislost

Skener vám může sdělit, že na serveru existuje CVE. Nedokáže však říct, zda server podporuje kritický platební proces, ukládá zvláštní kategorie osobních údajů, připojuje se k poskytovateli vypořádání nebo je naplánován k vyřazení z provozu.

Tento kontext poskytuje správa aktiv, klasifikace dat, evidence dodavatelů a posouzení rizik.

ISO/IEC 27001:2022 příloha A, opatření 8.8 Řízení technických zranitelností, je ústřední, ale nefunguje samostatně. Silně závisí na řízení konfigurace, řízení změn, monitorování dodavatelů, správě cloudových služeb, protokolování, monitorování a ošetření rizik.

NIST CSF 2.0 vyjadřuje stejný problém jazykem výsledků. Funkce GOVERN očekává, že právní, regulatorní a smluvní požadavky na kybernetickou bezpečnost budou pochopeny a řízeny, rizikový apetit a tolerance rizika budou zdokumentovány, role a zdroje budou přiřazeny a politiky kybernetické bezpečnosti budou zavedeny, prosazovány, přezkoumávány a aktualizovány. Výsledky IDENTIFY zahrnují evidence hardwaru, softwaru, služeb, systémů, dat a životního cyklu spolu s identifikací zranitelností, analýzou rizik, řízením výjimek a procesy oznamování zranitelností.

V Annině úterním ranním scénáři zní první technická otázka: „kde je zranitelná komponenta?“ První otázka správy a řízení zní: „kterou službu a jaké riziko ovlivňuje?“

Zenith Blueprint, fáze řízení rizik, krok 13: Plánování ošetření rizik a Prohlášení o aplikovatelnosti, toto řeší propojením rizik s opatřeními, vlastníky a lhůtami:

Dále přiřaďte ke každé akci vlastníka a časový rámec (případně v samostatném sloupci nebo v komentářích). Např. „Vlastník: IT manažer, časový rámec: do Q3 2025.“ Tím se z něj stává skutečný plán.

Přesně to vyžaduje náprava zranitelností. Zjištění bez vlastníka se stává šumem v backlogu. Zjištění s vlastníkem, termínem, rozhodnutím o ošetření rizika a auditní stopou důkazů se stává auditovatelným opatřením.

Jak Zenith Controls mapuje vztahy mezi opatřeními

Zenith Controls považuje opatření ISO/IEC 27002:2022 8.8 Řízení technických zranitelností za preventivní opatření podporující důvěrnost, integritu a dostupnost. Propojuje jej s koncepty kybernetické bezpečnosti Identify a Protect, provozní schopností řízení hrozeb a zranitelností a bezpečnostními doménami správy a řízení, ekosystému, ochrany a obrany.

To je důležité, protože SLA pro nápravu nejsou pouze ochranným mechanismem. Jsou také mechanismem správy a řízení a ekosystémovým mechanismem. Vaši expozici utvářejí dodavatelé, cloudové platformy, řízené služby, open-source komponenty a internetově dostupné závislosti.

Zenith Controls mapuje 8.8 na několik podpůrných opatření:

Zenith Controls také propojuje řízení zranitelností s ISO/IEC 27005:2024, zejména s identifikací zranitelností a rizikovými scénáři zahrnujícími nezáplatované systémy. To posiluje argument, že lhůty pro záplatování mají být založeny na rizicích, nikoli libovolné. Dále propojuje monitorování dodavatelů s ISO/IEC 27036-4:2016 pro úrovně bezpečnosti smluv o cloudových službách a s ISO/IEC 20000-1:2018 pro plánování poskytování služby a řízení změn.

Tato struktura napříč normami je při auditu důležitá. Pokud organizace tvrdí, že „kritické zranitelnosti jsou záplatovány do 72 hodin“, auditor ověří, zda je toto tvrzení podloženo posouzením rizik, klasifikací aktiv, povinnostmi dodavatelů, záznamy o změnách a důkazy z monitorování.

Kybernetická hygiena podle NIS2: od řešení zranitelností k nápravným opatřením

NIS2 Article 21 vyžaduje přístup zohledňující všechna rizika vůči sítím a informačním systémům. Pro SLA nápravy zranitelností je přímo relevantních několik prvků Article 21:

• Analýza rizik a politiky bezpečnosti informačních systémů
• Zvládání incidentů
• Kontinuita činností a krizové řízení
• Zabezpečení dodavatelského řetězce
• Bezpečné pořizování, vývoj a údržba, včetně řešení a oznamování zranitelností
• Postupy pro posuzování účinnosti kybernetické bezpečnosti
• Základní kybernetická hygiena a školení
• Řízení přístupu a správa aktiv
• Vícefaktorová autentizace nebo průběžná autentizace, kde je to vhodné

NIS2 Article 20 činí řídicí orgány odpovědnými za schvalování opatření k řízení kybernetických bezpečnostních rizik a za dohled nad nimi. To znamená, že metriky nápravy zranitelností nemohou existovat pouze v engineeringovém řídicím panelu. Měly by být součástí reportingu vedení, podkladů pro výbor pro rizika nebo záznamů z přezkoumání ISMS vedením.

Article 21 také očekává, že subjekty, které zjistí nesoulad s požadovanými opatřeními, přijmou nápravná opatření bez zbytečného odkladu. Tato formulace je důležitá. Pokud váš řídicí panel ukazuje kritické zranitelnosti po lhůtě, důkazy o souladu nemají končit u „víme o tom“. Mají prokazovat eskalaci, přezkum rizik, viditelnost pro vedení, nápravné opatření a opětovné posouzení.

NIS2 Article 23 přidává další rozměr. Pokud zneužití nezáplatované zranitelnosti způsobí nebo může způsobit závažné provozní narušení, finanční ztrátu nebo újmu jiným osobám, může jít o významný incident. Životní cyklus hlášení zahrnuje včasné varování do 24 hodin od okamžiku, kdy se subjekt o významném incidentu dozví, oznámení incidentu do 72 hodin, průběžné zprávy na vyžádání a závěrečnou zprávu do jednoho měsíce po oznámení incidentu. Tato závěrečná zpráva má zahrnovat závažnost, dopad, pravděpodobnou kořenovou příčinu, zmírňující opatření a případný přeshraniční dopad.

Proces SLA se proto musí propojit s reakcí na incidenty. Kritická zranitelnost s důkazy o aktivním zneužívání má spustit bezpečnostní triáž, monitorování, uchování důkazů a posouzení oznamovací povinnosti, nikoli pouze běžný tiket pro záplatu.

ICT rizika podle DORA: lhůty nápravy jako důkazy odolnosti

Pro finanční subjekty se DORA uplatňuje od 17. ledna 2025 a vytváří jednotné požadavky napříč řízením ICT rizik, hlášením závažných incidentů souvisejících s ICT, testováním digitální provozní odolnosti, sdílením informací a řízením ICT rizik třetích stran. Pro zahrnuté finanční subjekty identifikované podle národních pravidel NIS2 je považována za odvětvově specifický právní akt EU.

Provozní model DORA se blíží integrovanému ISMS. Articles 5 a 6 vyžadují správu a řízení, politiky, postupy, nástroje, každoroční nebo pravidelný přezkum, audit, nápravu kritických zjištění auditu a strategii digitální provozní odolnosti. Article 8 vyžaduje identifikaci a evidenci podnikových funkcí podporovaných ICT, informačních aktiv, ICT aktiv, závislostí, procesů třetích stran a rizik starších ICT. Article 9 vyžaduje ochranná a preventivní opatření, včetně záplatování a řízení změn. Articles 11 a 12 vyžadují kontinuitu, reakci, obnovu, zálohování, obnovení a cíle obnovy.

DORA Articles 17 až 19 vyžadují proces řízení incidentů souvisejících s ICT, který detekuje, řídí, zaznamenává, klasifikuje, eskaluje, hlásí, komunikuje, analyzuje kořenovou příčinu a obnovuje bezpečný provoz. Articles 24 až 26 vyžadují testování digitální provozní odolnosti, včetně vhodného testování ICT nástrojů a systémů, hodnocení zranitelností, hodnocení zabezpečení sítí, analýz mezer, přezkumů zdrojového kódu tam, kde je to proveditelné, penetračního testování a testování na základě hrozeb u vybraných finančních subjektů. Articles 28 a 30 vyžadují řízení ICT rizik třetích stran, registry smluv o ICT službách, náležitou péči, práva na audit a inspekci, úrovně služeb, podporu poskytovatele během incidentů, práva na ukončení a výstupní ujednání.

Pro SLA nápravy mění DORA očekávání ohledně důkazů třemi způsoby.

Zaprvé, zjištění zranitelností z testování musí vstupovat do prioritizovaného procesu nápravy. Samotná zpráva ze skenu nestačí.

Zadruhé, náprava kritických zjištění musí být sledována prostřednictvím správy a řízení a auditu. DORA očekává formální nápravu kritických auditních zjištění u podniků, které nejsou mikropodniky.

Zatřetí, poskytovatelé ICT služeb třetích stran musí být vázáni měřitelnými povinnostmi. Pokud váš cloud, SaaS nebo MSP poskytovatel řídí okno pro záplatování, vaše smlouva a registr musí ukázat, jak jejich lhůty nápravy podporují vaše povinnosti v oblasti odolnosti.

Politika řízení zranitelností a záplat toto řeší přímo:

Záplatování třetích stran a dohled nad riziky SaaS 6.6.1 Všechny systémy třetích stran (SaaS, PaaS, spravované MSP) musí prokázat odpovídající opatření řízení zranitelností a záplat. 6.6.2 SLA dodavatelů musí zahrnovat lhůty nápravy rovnocenné interně definovaným prahovým hodnotám podle kritičnosti.

Toto ustanovení je často chybějícím mostem mezi interními důkazy podle ISO a dohledem nad dodavateli podle DORA.

GDPR: když prodlení se záplatami znamená selhání odpovědnosti za osobní údaje

GDPR není norma pro řízení zranitelností, ale mění důsledky selhání záplatování.

GDPR Article 5 vyžaduje, aby osobní údaje byly zpracovávány bezpečně, a požaduje, aby správce dokázal soulad doložit. Article 32 vyžaduje vhodná technická a organizační opatření k zajištění úrovně zabezpečení odpovídající riziku. Pokud nezáplatované systémy zpracovávají osobní údaje, zejména identifikační údaje, finanční údaje, biometrické údaje, zdravotní údaje, údaje o zaměstnání nebo informace KYC, stávají se SLA nápravy součástí odpovědnosti za zabezpečení zpracování.

Prodlení se záplatou může být obhajitelné, pokud bylo riziko posouzeno, byla uplatněna kompenzační opatření a zbytkové riziko akceptovala správná osoba. Obhajoba je podstatně obtížnější, pokud zranitelnost byla po lhůtě, internetově dostupná a bez vlastníka.

Zenith Controls mapuje řízení zranitelností na GDPR Articles 32 a 5(1)(f), protože včasné záplatování snižuje rizika pro důvěrnost a integritu osobních údajů. Mapuje také řízení změn na GDPR Article 24 a Article 32, protože změny systémů zpracovávajících osobní údaje mají být posouzeny z hlediska rizik, schváleny, zdokumentovány a přezkoumány.

Poučení pro compliance je jednoduché: pokud jde o osobní údaje, důkazy o záplatování mají zahrnovat datový kontext. Auditoři a regulační orgány se nebudou ptát jen „bylo to záplatováno?“, ale také „jaká data byla vystavena riziku, jak dlouho a která opatření toto riziko snížila?“

Praktický workflow Clarysec pro auditně připravené důkazy SLA

Vyspělý proces nápravy zranitelností nezačíná ve chvíli, kdy auditor požádá o záznamy. Je navržen tak, aby záznamy vytvářel každý měsíc.

Krok 1: Schvalte politiku SLA

Začněte s Politikou řízení zranitelností a záplat nebo Politikou řízení zranitelností a záplat pro SME podle svého provozního modelu. Přizpůsobte prahové hodnoty SLA svému rizikovému apetitu, regulatornímu rozsahu, kritičnosti služby, citlivosti dat a technickým omezením. Zajistěte schválení ze strany CISO, výboru pro rizika nebo řídicího orgánu.

Pro podniková prostředí používejte CVSS, kritičnost aktiva, zneužitelnost, internetovou expozici, citlivost dat a dopad na podnikání. U SME ponechte model jednoduchý, ale explicitní: kritické záplaty do tří dnů, ostatní záplaty do 30 dnů, pokud neexistuje platná výjimka.

Krok 2: Mapujte aktiva na vlastníky a kritické služby

Každé zjištění zranitelnosti by mělo být přiřaditelné k těmto údajům:

• Název aktiva a jedinečný identifikátor
• Podniková služba nebo aplikace
• Vlastník systému
• Technický vlastník
• Klasifikace dat
• Internetová expozice
• Závislost na dodavateli, pokud existuje
• Kritičnost podporované funkce

To podporuje vlastnictví rizik podle ISO/IEC 27001:2022, správu aktiv podle NIS2, evidenci ICT aktiv a závislostí podle DORA a výsledky IDENTIFY podle NIST CSF.

Krok 3: Proveďte triáž zranitelnosti

Vytvořte tiket pro každé zjištění nebo seskupenou sadu zjištění. Uveďte skóre CVSS, zdrojový skener, dotčené aktivum, stav zneužití, informace o hrozbách, kritičnost pro podnikání a požadované SLA. Pokud existuje podezření na zneužití, propojte tiket s posouzením incidentu.

Krok 4: Proveďte nápravu prostřednictvím řízení změn

Záplatování je změna. Pro rutinní aktualizace použijte standardní změnu a pro kritické zneužívané zranitelnosti nouzovou změnu. Zahrňte důkazy o testování, schválení, časové razítko implementace, plán vrácení změn a validaci po změně.

To odpovídá vztahu v Zenith Controls mezi 8.8 a 8.32, kde aplikace záplat probíhá prostřednictvím řízení změn tak, aby byla vyvážena naléhavost a provozní stabilita.

Krok 5: Validujte uzavření

Neuzavírejte tikety pouze na základě tvrzení „záplata nainstalována“. Vyžadujte validaci prostřednictvím opětovného skenování, potvrzení verze, ověření konfigurace nebo potvrzení kompenzačního opatření. Pokud záplatu nelze aplikovat, otevřete výjimku.

Krok 6: Zaznamenejte výjimky a zbytkové riziko

Politika řízení zranitelností a záplat definuje požadovaný obsah výjimky:

Žádosti o výjimku musí obsahovat: 7.2.1 Obchodní odůvodnění prodlení nebo neprovedení nápravy 7.2.2 Posouzení rizik (na základě CVSS, kritičnosti aktiva, informací o hrozbách) 7.2.3 Navrhovaná kompenzační opatření 7.2.4 Časový rámec nápravy nebo opětovného posouzení

Definuje také schválení a přezkum:

Výjimky musí být schváleny CISO nebo delegovaným výborem pro rizika a zaznamenány v registru výjimek ISMS, s intervalem přezkumu nepřesahujícím 90 dnů.

Tento registr výjimek se stává zásadním důkazem pro ISO/IEC 27001:2022 článek 6.1.3, ošetření rizik a akceptaci zbytkového rizika, stejně jako pro přezkoumání vedením.

Tento záznam prokazuje, že organizace zranitelnost neignorovala. Posoudila riziko, uplatnila kompenzační opatření, schválila zbytkové riziko a stanovila datum přezkumu.

Krok 7: Vytvořte měsíční balíček důkazů

Měsíční balíček důkazů pro nápravu zranitelností by měl zahrnovat:

U SME může být rozsah důkazů lehčí, ale musí zůstat konzistentní. Politika řízení zranitelností a záplat pro SME vyžaduje logy záplat s dohledatelností:

Logy musí obsahovat název zařízení, aplikovanou aktualizaci, datum záplatování a důvod jakéhokoli prodlení

Toto jediné ustanovení má vysokou auditní hodnotu. Převádí záplatování z tvrzení na záznam.

Záplatování u dodavatelů: smlouva musí odpovídat vašemu SLA

Pokud nasazení záplat řídí MSP, poskytovatel SaaS, poskytovatel PaaS nebo poskytovatel cloudových služeb, interní SLA jsou k ničemu, pokud jim neodpovídají povinnosti dodavatele.

Bezpečnostní politika pro dodavatele a poskytovatele služeb třetích stran pro SME zahrnuje povinnosti v oblasti bezpečnosti informací jako požadavek správy a řízení. Pro nápravu zranitelností by se tyto povinnosti měly promítnout do měřitelného smluvního jazyka:

• Oznamovací lhůty pro kritické zranitelnosti
• Lhůty nápravy pro kritické, vysoké, střední a nízké zranitelnosti
• Proces nouzové změny
• Požadavky na schválení odstávky zákazníkem
• Formát důkazů o dokončení záplaty
• Proces oznamování zranitelností
• Povinnosti podpory při incidentu
• Právo na audit nebo na obdržení ujišťovacích zpráv
• Povinnosti záplatování u dílčích zpracovatelů nebo subdodavatelů
• Podpora ukončení a přechodu u kritických služeb

Zenith Blueprint, fáze Controls in Action, krok 20, opatření 8.21 Bezpečnost síťových služeb, vyjadřuje princip jasně:

Pokud jsou služby poskytovány externě, včetně ISP, dodavatelů SD-WAN nebo poskytovatelů privátního cloudu, bezpečnostní požadavky musí být zahrnuty do smluv a SLA. Patří sem záruky dostupnosti, reakční doby pro incidenty, povinnosti záplatovat nebo zmírňovat zranitelnosti a jasné hranice nakládání s daty. Nikdy byste neměli předpokládat, že poskytovatel plní vaše očekávání, pokud to není písemné, měřitelné a auditovatelné.

DORA je v tomto ohledu obzvlášť důležitá pro finanční subjekty. Ujednání s ICT třetími stranami musí zahrnovat úrovně služeb, podporu poskytovatele během ICT incidentů, přístup k datům a jejich obnovu, spolupráci s orgány, práva na ukončení a přísnější ustanovení pro kritické nebo důležité funkce, včetně monitorování, auditních práv, plánů mimořádných situací a bezpečnostních opatření.

NIST CSF 2.0 říká totéž prostřednictvím výsledků rizik dodavatelského řetězce: dodavatelé mají být známi, prioritizováni podle kritičnosti, posouzeni před zapojením, řízeni smluvními požadavky, monitorováni po celou dobu vztahu, zahrnuti do plánování incidentů a řízeni při ukončení.

Na co se auditoři skutečně zeptají

Auditní rozhovor se mění podle odborného zaměření auditora.

Auditor ISO/IEC 27001:2022 začne u ISMS. Ověří, zda je řízení zranitelností zahrnuto v Prohlášení o aplikovatelnosti, zda posouzení rizik identifikuje nezáplatované systémy jako riziko, zda mají plány ošetření rizik vlastníky a lhůty, zda je implementováno opatření 8.8 přílohy A, zda jsou uchovávány důkazy a zda interní audit a přezkoumání vedením vyhodnocují výkonnost.

Zenith Blueprint, fáze Controls in Action, krok 19, výslovně uvádí auditní očekávání:

Toto je pro auditory vysoce prioritní opatření a obvykle půjdou do hloubky. Očekávejte otázky, jak často jsou systémy záplatovány, jaký postup používáte při oznámení zero-day zranitelnosti a které systémy se záplatují nejobtížněji.

Pokračuje praktickými očekáváními ohledně důkazů:

Auditoři si pravděpodobně vyžádají výsledky skenů zranitelností. Pokud používáte nástroje jako Nessus, OpenVAS nebo Qualys, exportujte zprávu ukazující nedávno detekované zranitelnosti a způsob jejich řešení. V ideálním případě má obsahovat hodnocení rizik (CVSS) a lhůty nápravy.

Auditor nebo příslušný orgán zaměřený na NIS2 bude hledat schválení řídicím orgánem, proporcionalitu, kybernetickou hygienu, řešení zranitelností, bezpečnost dodavatelů, zvládání incidentů, posouzení účinnosti, nápravná opatření bez zbytečného odkladu a záznamy rozhodnutí o hlášení, pokud zneužití způsobilo významný dopad.

Dohledový orgán DORA ověří, zda jsou zjištění zranitelností integrována do řízení ICT rizik, testování digitální provozní odolnosti, klasifikace incidentů, analýzy kořenové příčiny, registrů třetích stran, smluvních povinností, auditních práv a nápravy kritických zjištění.

Hodnotitel NIST CSF pravděpodobně uspořádá přezkum podle funkcí GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER. Zeptá se, zda jsou pochopeny právní a smluvní požadavky, zda je zdokumentována tolerance rizika, zda jsou zranitelnosti identifikovány a prioritizovány, zda jsou řízeny výjimky, zda monitorování detekuje zneužití a zda jsou koordinována opatření reakce a obnovy.

Auditor ve stylu COBIT 2019 nebo ISACA se zaměří na cíle správy a řízení, způsobilost procesů, řídicí postupy, metriky, vlastnictví, návrh opatření, fungování opatření a dostatečnost důkazů. Zeptá se, zda je náprava zranitelností opakovatelná, měřená, eskalovaná, zlepšovaná a sladěná s podnikovými cíli a rizikovým apetitem.

Eskalace a metriky: jak prokázat, že SLA je řízeno

SLA bez eskalace je jen cíl. Obhajitelný program nápravy zranitelností potřebuje eskalaci před porušením, při porušení i po opakovaném selhání.

Clarysec doporučuje čtyřúrovňový model eskalace:

1. Provozní eskalace, vlastník tiketu a technický vedoucí jsou upozorněni před porušením.
2. Eskalace rizika, vlastník aktiva a vlastník rizika posoudí dopad, pokud je porušení pravděpodobné.
3. Eskalace správy a řízení bezpečnosti, CISO nebo výbor pro rizika schvaluje výjimku nebo nouzové opatření.
4. Eskalace na vedení, opakovaná nebo kritická porušení SLA jsou hlášena do přezkoumání vedením spolu s nápravnými opatřeními.

Politika řízení zranitelností a záplat toto auditní očekávání posiluje:

Interní audit nebo nezávislá třetí strana musí provádět pravidelné audity za účelem ověření: 5.6.1 Souladu se SLA 5.6.2 Důkazů o prioritizaci založené na rizicích 5.6.3 Účinnosti nasazených záplat 5.6.4 Opatření nad nezáplatovanými systémy

Metriky mají podporovat rozhodování, nikoli zdobit řídicí panely. Nejsilnější metriky pro rok 2026 zahrnují:

• Procento souladu s kritickými SLA
• Procento souladu s vysokými SLA
• Průměrná doba do triáže
• Průměrná doba do nápravy podle třídy aktiv
• Počet kritických zranitelností po lhůtě
• Počet akceptovaných výjimek podle stáří
• Výjimky přesahující 90 dnů
• Počet kritických internetově dostupných expozic
• Porušení SLA dodavatelů
• Zranitelnosti znovu otevřené po validaci
• Nouzové změny způsobené zneužitými zranitelnostmi
• Selhání záplat podle platformy nebo podnikové jednotky

Propojte tyto metriky s ISO/IEC 27001:2022 článkem 9.3, přezkoumáním vedením, reportingem správy a řízení podle DORA a dohledem vedení podle NIS2. Pro NIST CSF 2.0 je použijte k aktualizaci aktuálních a cílových profilů, analýzy mezer a akčních plánů.

Kontrolní seznam Clarysec pro SLA nápravy

Použijte tento kontrolní seznam k vyhodnocení svého současného programu:

• Existuje schválená politika řízení zranitelností a záplat?
• Jsou SLA nápravy definována podle závažnosti a kritičnosti pro podnikání?
• Jsou internetově dostupné a zneužité zranitelnosti urychlovány?
• Jsou aktiva mapována na vlastníky, služby, data a dodavatele?
• Jsou zjištění skenerů převáděna na přiřazené tikety?
• Jsou záplaty prováděny prostřednictvím řízení změn?
• Jsou nouzové změny dokumentovány a přezkoumávány?
• Jsou výsledky nápravy validovány opětovnými skeny nebo kontrolami verzí?
• Jsou výjimky posouzeny z hlediska rizik, schváleny a přezkoumávány alespoň každých 90 dnů?
• Jsou pro nezáplatovatelné systémy zdokumentována kompenzační opatření?
• Jsou dodavatelské smlouvy sladěny s interními prahovými hodnotami nápravy?
• Jsou logy záplat dostatečně úplné, aby prokázaly, co se stalo a kdy?
• Jsou porušení SLA eskalována a napravována?
• Jsou metriky přezkoumávány vedením?
• Spouštějí se incidenty a posouzení porušení zabezpečení, pokud existuje podezření na zneužití?

Pokud je několik odpovědí „ne“, problém není v nástrojích. Jde o návrh opatření.

Další kroky: proměňte lhůty pro záplaty v auditně připravenou odolnost

SLA pro nápravu zranitelností v roce 2026 musí dělat víc než uspokojit řídicí panel skeneru. Musí prokazovat, že vaše organizace dokáže identifikovat expozici, prioritizovat riziko, jednat ve schválených lhůtách, řídit výjimky, spravovat dodavatele a dokládat rozhodnutí napříč auditními očekáváními ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.

Clarysec vám může pomoci přejít od roztříštěných tiketů na záplaty k integrovanému programu nápravy zranitelností řízenému důkazy pomocí:

• Politika řízení zranitelností a záplat
• Politika řízení zranitelností a záplat pro SME
• Bezpečnostní politika pro dodavatele a poskytovatele služeb třetích stran pro SME
• Zenith Blueprint: 30krokový plán auditora
• Zenith Controls: průvodce napříč požadavky compliance

Začněte jednou vysoce rizikovou službou. Zmapujte její aktiva, dodavatele, zranitelnosti, tikety, změny, výjimky a důkazy. Poté na ni aplikujte auditní otázky. Pokud nedokážete prokázat SLA od detekce po uzavření, jde o váš první projekt nápravy.

Cílem není dokonalé záplatování. Cílem je řízená, na rizicích založená, měřitelná a auditovatelná náprava. Stáhněte si šablony politik Clarysec, proveďte cílené posouzení mezer nebo si objednejte demo Clarysec a proměňte nápravu zranitelností z auditního tlaku v provozní odolnost.