ISO 27001 a penetrační testy: co po vás norma opravdu chce

Mezi opatřeními přílohy A žádné opatření nazvané penetrační test nenajdete. Příloha požaduje řízení technických zranitelností, bezpečnostní testování ve vývoji a akceptaci a nezávislý přezkum bezpečnosti informací, tedy cíle, ne konkrétní úkon. Penetrační testování se objevuje až v implementačním návodu ISO/IEC 27002:2022, a to jako jeden z možných způsobů, jak ta opatření naplnit.

Prakticky to znamená, že test je nejpřímější doklad o tom, že opatření fungují, a proto ho auditoři žádají, i když ho příloha A nejmenuje.

Tenhle rozdíl se vyplatí držet, protože mění argumentaci u auditu. Nedokládáte, že jste splnili předepsaný úkon. Dokládáte, že opatření, které jste si sami stanovili, jste ověřili nezávisle a v provozu. Firma, která místo testu předloží jen výstup ze skeneru, obvykle narazí právě tady.

Certifikace se navíc uděluje systému řízení, ne jednotlivé aplikaci. Auditor tedy nezkoumá závažnost jednoho nálezu, ale jestli má firma proces, který nálezy zachytí, vyhodnotí a doveze do opravy.

Penetrační test se v praxi používá jako doklad ke čtyřem oblastem opatření z přílohy A: k řízení technických zranitelností, k bezpečnostnímu testování ve vývoji a akceptaci, k bezpečnému vývoji a k nezávislému přezkumu bezpečnosti informací. Opatření uvádíme slovně, protože kódy se mezi revizemi normy měnily.

Poslední řádek je pro interní týmy nejcitlivější. Vlastní IT oddělení může sken spustit, ale nezávislost přezkumu tím nedoloží, protože kontroluje výsledek vlastní práce.

Auditor typicky nečte celý report. Hledá v něm šest věcí, které dohromady ukazují, že test byl skutečný a že na něj něco navázalo. Report, který má nálezy, ale neukazuje nápravu, projde technicky a u auditu neobstojí.

• Rozsah: co přesně se testovalo, jmenovitě aplikace, rozsahy IP nebo prostředí.
• Datum provedení a verzi testovaného systému.
• Metodiku, podle které se postupovalo, a kdo test prováděl.
• Seznam nálezů se závažností a s popisem dopadu.
• Doklad o nápravě u nálezů, které jste se rozhodli opravit.
• Retest s vlastním datem a stavem u každého opraveného nálezu.

U nálezů, které jste se rozhodli neopravit, chce auditor vidět akceptaci rizika s podpisem odpovědné osoby. Mlčení o nálezu je horší než jeho vědomé přijetí.

Žádný pevný interval z normy nevyplývá. Interval si firma určuje sama v analýze rizik a auditor pak kontroluje, jestli ho dodržuje. V praxi se u certifikovaných firem ustálil roční cyklus doplněný o test po významné změně, protože se kryje s dozorovými audity. Kdo spadá i pod zákon o kybernetické bezpečnosti, má to jinak: tam je interval daný předpisem.

Pozor na obrácené odvození. Když si do dokumentace napíšete pololetní testování, protože to zní důkladně, auditor bude kontrolovat pololetní testování. Interval, který nedodržíte, je horší než delší interval, který dodržíte.

Certifikace podle ISO 27001 a povinnosti podle zákona o kybernetické bezpečnosti se překrývají v technické rovině, ne v té formální. Jeden dobře udělaný test může posloužit oběma, protože obojí stojí na ověření, že opatření fungují v provozu. Automaticky se ale nezapočítá.

Rozdíl je v tom, kdo určuje pravidla. U certifikace si rozsah a frekvenci stanovujete sami a auditor kontroluje dodržení. U zákona jsou požadavky dané předpisem, včetně intervalu a evidence. Co konkrétně zákon č. 264/2025 Sb. žádá a do jakého režimu spadáte, rozebírá výklad NIS2 a nZKB pro firmy.

Test nemá smysl objednávat jako první krok. Nejdřív potřebujete vědět, co je v rozsahu systému řízení, protože právě podle toho se určuje, co se bude testovat. Pořadí kroků, které se před certifikací vyplatí dodržet, vypadá takhle.

• Vymezte rozsah systému řízení a vypište aktiva, která do něj spadají.
• Udělejte analýzu rizik a z ní odvoďte, která opatření zavedete.
• Naplánujte test na aktiva s nejvyšším rizikem, ne na všechna.
• Nechte si na opravy a retest čas před certifikačním auditem, ne po něm.

S vymezením rozsahu a s návazností na analýzu rizik pomáháme v rámci bezpečnostní konzultace. Samotné ověření pak běží jako penetrační test aplikací a infrastruktury, jehož výstup se dá přiložit k dokumentaci beze změn.