Často se ptáte

Nexentis pomáhá organizacím především s řízením kybernetické bezpečnosti a souvisejícími požadavky NIS2 a zákona o kybernetické bezpečnosti, s IT a projektovým managementem, dotačním financováním a vybranými projekty v oblasti AI.

U kybernetické bezpečnosti se zaměřujeme na praktické zavedení systému řízení: od posouzení současného stavu přes dokumentaci a stanovení priorit až po průběžnou odbornou podporu. Více o kybernetické bezpečnosti.

Pracujeme především s organizacemi, které potřebují systematicky řídit bezpečnost, regulatorní požadavky nebo složitější IT změny a nemají pro všechny potřebné role dostatečnou interní kapacitu.

Mezi relevantní sektory patří zdravotnictví, výrobní podniky, digitální infrastruktura, energetika, vodní hospodářství, finanční sektor, potravinářství a veřejná správa.

Ne nutně. Rozsah spolupráce lze nastavit podle toho, jaké kapacity organizace již má.

Pokud vlastní IT existuje, Nexentis s ním spolupracuje při zjišťování technického stavu a realizaci opatření. Bezpečnostní řízení ale může být vedeno nezávisle na každodenním provozu IT.

Nejčastěji úvodním posouzením současné situace, rozsahu požadavků a hlavních priorit.

Výstupem má být srozumitelný pohled pro vedení organizace: co je již zajištěno, kde jsou hlavní nedostatky a jaký postup dává smysl v dalších měsících.

Ano. Úvodní posouzení může fungovat jako samostatný projekt.

Podle výsledků se následně může organizace rozhodnout, zda chce pokračovat průběžným řízením bezpečnosti, odbornými konzultacemi, podporou implementace nebo jinou formou spolupráce.

Ano. Spolupráci lze nastavit jako jednorázové vstupní posouzení i jako průběžnou službu podle rozsahu, potřebné kapacity a požadované dostupnosti.

Je potřeba posoudit konkrétní typ poskytované služby, velikost organizace a další relevantní charakteristiky.

Samotné zařazení firmy do určitého oboru nestačí. Regulatorní dopad musí být u konkrétní organizace ověřen podle její skutečné situace. Více o kybernetické bezpečnosti.

Nejprve je vhodné určit, jaké povinnosti se organizace skutečně týkají, co již splňuje a kde jsou zásadní mezery.

Teprve poté má smysl vytvářet dokumentaci, zadávat technické projekty nebo nakupovat nové nástroje.

Ne. Dokumentace je pouze jedna část systému.

Fungující bezpečnostní řízení zahrnuje také odpovědnosti, řízení rizik, technická a organizační opatření, dodavatelské vztahy, postupy při incidentech, školení a průběžný dohled.

Ano. Ve většině organizací je realistické pracovat s prioritizovaným plánem.

Smyslem úvodního posouzení není vytvořit seznam všeho, co firma nemá, ale určit pořadí kroků podle rizika, regulatorní důležitosti, kapacit a návazností.

Záleží na současném stavu, velikosti a složitosti organizace.

Jiný rozsah bude mít firma, která již provozuje funkční systém řízení bezpečnosti, a jiný organizace, která musí teprve vytvořit role, evidenci aktiv, procesy a dokumentaci.

IT je zásadní pro realizaci technických opatření, ale kybernetická bezpečnost zahrnuje i řízení rizik, odpovědnosti vedení, dodavatele, dokumentaci, investiční priority a kontrolu plnění.

Proto dává smysl oddělit technickou realizaci od role, která požadavky stanovuje a nezávisle hodnotí jejich splnění. Více o kybernetické bezpečnosti.

Typicky koordinuje řízení bezpečnostních rizik, stanovuje a sleduje požadavky, připravuje podklady pro vedení, koordinuje dokumentaci, vyhodnocuje stav opatření a propojuje management, IT a další relevantní útvary.

Ne vždy. Podle velikosti organizace, potřebné kapacity a rozsahu agendy může být vhodný interní, externí nebo hybridní model.

IT podpora se soustředí primárně na provoz a technologie.

Externí bezpečnostní funkce má řídit bezpečnostní požadavky a rizika z nezávislé perspektivy a poskytovat managementu podklady pro rozhodování.

Rozsah lze nastavit podle potřeb organizace. Model spolupráce může zahrnovat konkrétního manažera kybernetické bezpečnosti, zastupitelnost a přístup k dalším specialistům.

Konkrétní rozsah závisí na regulatorním režimu a situaci organizace.

Může zahrnovat například bezpečnostní politiku, přehled opatření, pravidla pro technická aktiva, metodiku posuzování incidentů, evidenci školení a další podklady odpovídající konkrétním povinnostem.

Mohou pomoci jako výchozí struktura.

Samy o sobě ale nestačí. Dokumentace má odpovídat skutečnému fungování organizace, rolím, technologiím a procesům.

Záleží na konkrétním typu dokumentu a governance organizace.

U klíčových politik a pravidel má být jednoznačně určena odpovědnost a schvalovací mechanismus.

Při významných změnách a zároveň pravidelně podle nastaveného systému řízení. Dokumentace má odpovídat reálnému stavu organizace.

Audit obecně směřuje k nezávislému ověření stavu vůči předem stanoveným kritériím.

Gap analýza se více zaměřuje na rozdíl mezi současným a požadovaným stavem a zpravidla přímo podporuje plánování nápravy.

Ne pouze seznam nedostatků.

Výstup by měl dát vedení srozumitelný přehled stavu, priorit, hlavních rizik a doporučeného dalšího postupu.

Každá významná iniciativa by měla mít jasný cíl, prioritu, vlastníka, termín, závislosti a odhad potřebných zdrojů.

Roadmapa by měla být realistická vzhledem k finančním a personálním možnostem organizace.

Pak je potřeba priority rozdělit v čase.

Součástí řízení je i vědomé rozhodnutí, které riziko bude organizace řešit okamžitě, které později a kde lze dočasně využít náhradní opatření.

Především jaká jsou nejvýznamnější rizika, jak se vyvíjejí, která klíčová opatření jsou opožděná a kde je potřeba rozhodnutí nebo dodatečný rozpočet.

Pouze pokud jsou převedeny do kontextu, který umožňuje rozhodování.

Počet zranitelností nebo bezpečnostních událostí bez informace o jejich dopadu může být pro vedení zavádějící.

Frekvence má odpovídat významu a rizikovosti organizace.

Vedle pravidelného reportingu by měl existovat způsob okamžité eskalace významných událostí.

Protože významné části infrastruktury, aplikací nebo provozních služeb jsou často provozovány externě.

Incident u dodavatele tak může ovlivnit i organizaci, která má vlastní infrastrukturu dobře zabezpečenou.

Ne.

Hloubka posouzení má odpovídat tomu, jak významnou službu dodavatel zajišťuje, k jakým datům nebo systémům má přístup a jaký dopad by mělo jeho selhání.

Ideálně ještě před uzavřením smlouvy a dále při významných změnách spolupráce, incidentech nebo pravidelném přezkumu kritických partnerů.

Například dostupnost služby, pravidla přístupů, oznamování incidentů, součinnost při jejich řešení, zacházení s daty, subdodavatele a podmínky ukončení spolupráce.

Bezpečnostní opatření často vyžadují technologické nebo organizační projekty.

IT a projektový management pomáhá určit současný stav, priority, zadání, dodavatele a způsob realizace. Bezpečnostní řízení potom sleduje, zda výsledná opatření odpovídají požadavkům. Více o IT a projektovém managementu.

Ano, spolupráce může zahrnovat orientaci v dostupných řešeních, prověření dodavatelů a přípravu podkladů pro rozhodnutí nebo výběr vhodné varianty.

Ne vždy formální audit.

Je ale vhodné znát současný stav, požadovaný výsledek a hlavní rizika ještě před tím, než organizace začne vybírat konkrétní produkt.

Rozsah IT a projektového managementu lze nastavit podle konkrétního zadání. Technické implementace mohou mít samostatný rozsah a rozpočet oddělený od průběžného bezpečnostního řízení.

U vybraných programů a nákladů to možné být může.

Konkrétní způsobilost je vždy nutné ověřit podle aktuálních podmínek dané výzvy. Více o dotačním financování.

Nejprve by měla vzniknout reálná potřeba a smysluplný projekt.

Dotační financování je vhodné chápat jako možný zdroj financování již odůvodněné investice, nikoli jako důvod k nákupu technologie, kterou organizace nepotřebuje.

Ano. U investic souvisejících s kybernetickou bezpečností nebo IT lze podle aktuální situace prověřit možnosti spolufinancování.

Ne. Podmínky a otevřenost dotačních programů se v čase mění.

Aktuálnost konkrétní výzvy je proto potřeba vždy ověřit v okamžiku přípravy projektu.

Business-first.

Smyslem není nasazovat AI proto, že je technologicky zajímavá, ale hledat situace, kde lze definovat konkrétní přínos pro organizaci. Více o AI konzultacích.

Je potřeba hodnotit například hodnotu pro organizaci, dostupnost a kvalitu dat, opakovatelnost procesu, náklady na implementaci, integrační náročnost a rizika.

Ne nutně.

Nejdříve je vhodné definovat problém, cílový výsledek a způsob měření přínosu. Technologické řešení má přijít až potom.

Podle konkrétního use case například časovou úsporou, snížením chybovosti, rychlostí zpracování, kvalitou výsledku nebo zkrácením rozhodovacího procesu.

Ne automaticky.

U menší organizace může dávat smysl užší, dobře definovaný use case s jasnou ekonomikou.

Výrobní technologie přímo ovlivňují fyzický provoz.

Bezpečnostní opatření proto musí respektovat dostupnost výrobních linek, technologická omezení, servisní režimy a riziko odstávky.

Je potřeba vyhodnotit riziko a navrhnout kompenzační opatření.

Může jít například o segmentaci, omezení komunikace, řízení vzdáleného přístupu, monitoring nebo jiný způsob snížení expozice.

Neměla by být izolovanou agendou pouze IT nebo pouze výroby. Potřebuje spolupráci provozu, technických specialistů, bezpečnostního řízení a managementu.

Základní principy mohou být podobné, ale priority se liší.

Ve výrobě je zásadní kontinuita linek a OT. U digitální infrastruktury odolnost a SLA. Ve finančním sektoru návaznost na existující compliance. Ve veřejné správě bývá významným tématem omezená personální a rozpočtová kapacita.

Ano. Konkrétní postup má vycházet z provozního kontextu, regulatorních požadavků, rizik a dostupných kapacit dané organizace.

Cena závisí na rozsahu, režimu povinností, potřebné kapacitě, složitosti prostředí a požadované dostupnosti. Konkrétní rozsah a cena se stanovují podle situace organizace a zvolené varianty spolupráce.

Typicky rozsah organizace, požadovaný režim spolupráce, počet a složitost systémů, potřebné odborné role, intenzita konzultací a případné požadavky na pohotovost nebo další specializované služby.

Nemusí být.

Průběžné bezpečnostní řízení lze oddělit od samostatně zadávaných technických realizací, například nasazení monitoringu, změn infrastruktury nebo jiných implementačních projektů.