Řízení rizik a implementace bezpečnosti

Kdy má smysl začít řízením rizik

Téměř vždy. Před tím, než se napíše první směrnice, se musí vědět, co chráníme a proč. Risk-based přístup je dnes požadavek prakticky všech regulací (NIS2, ZKB, DORA, ISO 27001, AI Act) — a zároveň je to jediný způsob, jak smysluplně prioritizovat omezené kapacity.

Bez řízení rizik vznikne organizace, která chrání všechno stejně, nebo nic — a v obou případech bývá výsledkem dokumentace bez vztahu k realitě a opatření bez vlastníka.

Analýzy rizik a rozdílové analýzy

Pracuji s mapovacími tabulkami hrozeb, zranitelností a typů aktiv. Výstupem je provozní risk register, který vedení může schválit a tým bezpečnosti používat při každodenním rozhodování. Ne akademická taxonomie — ale tabulka, ze které je jasné, kde jsou priority a co tomu řekne audit.

• identifikace klíčových aktiv a procesů,
• katalog relevantních hrozeb a zranitelností,
• oceňování rizik dle pravděpodobnosti a dopadu,
• rozdílová analýza vůči zvolenému rámci (NIS2, ISO 27001, DORA),
• návrh ošetření rizika včetně odpovědností,
• vazba na business continuity a krizový plán.

Implementace procesů a použitelná dokumentace

Bezpečnostní dokumentace je z 90 % dokumentace procesů, jen zarámovaná regulatorně. Pokud se píše dříve, než se procesy ustálí, je pravděpodobně k ničemu — buď ji nikdo nečte, nebo se neshoduje s tím, co se reálně dělá.

Můj přístup: nejdřív zmapovat reálný proces (ne ten zamýšlený), zachytit ho do dokumentu, který vidí jak provoz, tak audit, a teprve potom doplnit chybějící části. Výstupem jsou například:

• bezpečnostní politiky a směrnice,
• katalogy bezpečnostních požadavků s mapováním na rámce,
• RACI matice pro klíčové oblasti řízení,
• incident playbooky s konkrétními rolemi,
• kontrolní checklisty pro provoz a audit,
• roadmapa implementace s prioritami a termíny.

Školení a tabletop cvičení

Dokument, který nikdo nepozná, se v incidentu nepoužívá. Připravuji školení šitá na konkrétní role (vedení, IT, helpdesk, koncoví uživatelé) a vedu tabletop cvičení, ve kterých si tým v klidu projde, co by se stalo, kdyby dnes ráno vypadla kritická služba, kdyby přišel ransomware, kdyby se objevila kompromitace dodavatele.

Tabletop je nejlevnější způsob, jak zjistit, kde jsou skutečné mezery — než to ukáže reálný incident.

Hledání příčin incidentů a nápravná opatření

Po incidentu obvykle existují dvě verze událostí: ta, která obhajuje rozhodnutí udělaná pod tlakem, a ta, která ukazuje systémové příčiny. Root cause analysis (RCA) odděluje jedno od druhého.

• strukturovaná RCA dle 5-why, fishbone nebo logical tree,
• oddělení technické příčiny od organizační příčiny,
• doporučení nápravných opatření s vlastníkem a termínem,
• návaznost na změny v dokumentaci, procesech a školení,
• materiál pro statutární orgán a regulátora.