Implementácia ISMS podľa ISO 27001 nebýva problém preto, že by bola technicky zložitá. Problém je, že organizácie pri nej opakujú tie isté chyby – a väčšina z nich nesúvisí s technológiou. Súvisia s prístupom, očakávaniami a organizáciou práce.
Tento článok vychádza z reálnych skúseností s implementáciami a auditmi. Ak ste v procese zavádzania ISMS alebo sa naň chystáte, tieto body vám pomôžu vyhnúť sa najdrahším omylom.
Ak ste ešte nečítali predchádzajúce články v sérii, odporúčame začať tu: ISO 27001 bez omáčky: čo je ISMS a čo musí mať firma nastavené a Implementácia ISMS krok za krokom.
Chyba 1 – ISMS ako papierové cvičenie
Najrozšírenejšia chyba. Organizácia vytvorí dokumentáciu, ktorá vyzerá dobre na papieri, ale nemá reálny vzťah k tomu, čo sa vo firme deje. Politiky sú skopírované zo šablón, analýza rizík je formálna, SoA je odškrtnutý zoznam bez reálneho posúdenia.
Prečo sa to deje: tlak na rýchlu certifikáciu, nedostatok internej kapacity, konzultant, ktorý dodá „balík dokumentov“ bez pochopenia fungovania organizácie.
Prečo je to problém: audítor na Stage 2 testuje zhodu medzi dokumentáciou a praxou. Ak zamestnanec v rozhovore popíše iný proces, než je zdokumentovaný, vzniká nezhoda. A aj keď organizácia audit prejde, formálny ISMS neposkytuje reálnu ochranu – pri incidente zistíte, že procesy, na ktoré ste sa spoliehali, nikto nedodržiava.
Ako sa tomu vyhnúť: Dokumentáciu píšte podľa toho, čo sa reálne robí – nie podľa toho, čo by sa malo robiť v ideálnom svete. Ak niečo ešte nemáte zavedené, zapíšte to ako medzeru a naplánujte implementáciu. Rozpor medzi dokumentáciou a realitou je vždy horšie zistenie než priznaná medzera s plánom nápravy.
Chyba 2 – Príliš široký scope na začiatku
Organizácia sa rozhodne, že ISMS bude pokrývať úplne všetko – všetky služby, všetky lokality, všetkých dodávateľov. Výsledok: implementácia sa ťahá, dokumentácia narastá do nezvládnuteľného rozsahu a nikto nedokáže udržať prehľad.
Prečo sa to deje: obava, že úzky scope bude vyzerať slabo, alebo nesprávny predpoklad, že certifikát musí pokrývať celú firmu.
Prečo je to problém: ISO 27001 umožňuje definovať scope flexibilne. Certifikát na jednu službu alebo divíziu je rovnako platný ako certifikát na celú organizáciu. Široký scope, ktorý organizácia nedokáže udržať, je horšia vizitka ako úzky scope, ktorý funguje bezchybne. Najhorší scope je taký, ktorý vyzerá ambiciózne, ale organizácia ho nevie riadiť ani obhájiť pri audite.
Ako sa tomu vyhnúť: Začnite s najkritickejšou službou alebo produktom. Overte si, že scope pokrýva to, čo od vás vyžadujú klienti alebo regulátor. Rozšíriť scope sa dá pri recertifikácii – zmenšiť ho je ťažšie.
Pre organizácie spadajúce pod zákon o kybernetickej bezpečnosti je dôležité overiť, či scope pokrýva všetky regulované služby. Viac o vzťahu medzi ISO 27001 a zákonom v článku ISO 27001 a NIS2 na Slovensku – čo majú spoločné a kde sa rozchádzajú.
Chyba 3 – Podceňovanie zapojenia vedenia
ISMS je delegovaný na IT oddelenie. Vedenie podpíše politiku, ale ďalej sa nezúčastňuje na manažérskom review, neschvaľuje rizikové rozhodnutia a nevie, aký je scope ani aké riziká organizácia prijala.
Prečo sa to deje: bezpečnosť je tradične vnímaná ako „IT záležitosť“. Vedenie ju považuje za operatívnu tému, nie za strategickú.
Prečo je to problém: ISO 27001 explicitne vyžaduje zapojenie top manažmentu (Clause 5.1). Audítor bude chcieť vidieť, že vedenie rozhoduje o rizikách, prideľuje zdroje a preveruje výkonnosť ISMS. Navyše – zákon o kybernetickej bezpečnosti výrazne posilňuje osobnú zodpovednosť štatutárov. ISMS, za ktoré vedenie reálne nepreberá zodpovednosť, je z pohľadu normy aj zákona nedostatočný.
Ako sa tomu vyhnúť: Manažérsky review nie je formálna porada. Je to rozhodovací bod, kde vedenie schvaľuje stav rizík, výsledky auditov a alokáciu zdrojov. Zahrňte ho do existujúcich reportovacích štruktúr – nemusíte vytvárať nový meeting, ale bezpečnosť musí byť na agende vedenia pravidelne.
Chyba 4 – Formálny Statement of Applicability
SoA je dokument, v ktorom organizácia uvedie, ktoré z 93 kontrol Annex A aplikuje a ktoré nie. Častá chyba: všetky kontroly sú označené ako „aplikované“ bez reálneho posúdenia, alebo naopak – kontroly sú vylúčené bez odôvodnenia.
Prečo sa to deje: SoA sa vníma ako formulár na odškrtnutie, nie ako analytický nástroj. Organizácia chce vyzerať komplexne, a tak označí všetko ako aplikované, aj keď niektoré kontroly reálne neimplementuje.
Prečo je to problém: audítor na Stage 2 porovnáva SoA s realitou. Ak je kontrola označená ako aplikovaná, ale dôkazy neexistujú, je to nezhoda. Ak je kontrola vylúčená bez odôvodnenia, audítor bude chcieť vysvetlenie.
Ako sa tomu vyhnúť: SoA musí byť prepojený s analýzou rizík. Každá kontrola, ktorá je aplikovaná, musí mať dôkaz o implementácii. Každá kontrola, ktorá nie je aplikovaná, musí mať zdokumentované odôvodnenie naviazané na kontext organizácie. Prakticky: ak v SoA tvrdíte, že kontrola platí, musíte vedieť ukázať, kde je zavedená, kto za ňu zodpovedá a aký dôkaz o nej existuje.
Chyba 5 – Jednorazový projekt namiesto kontinuálneho procesu
Organizácia investuje energiu do získania certifikátu. Po úspešnom audite sa ISMS odloží. Dokumentácia sa neaktualizuje, interné audity sa nerobia, analýza rizík sa nereviduje, nové systémy a dodávatelia sa pridávajú bez posúdenia.
Prečo sa to deje: certifikácia sa vníma ako cieľ, nie ako začiatok. Tím, ktorý bol vyčlenený na implementáciu, sa vráti k bežnej práci.
Prečo je to problém: na dozorovom audite (rok 1 a 2 po certifikácii) audítor kontroluje kontinuálne zlepšovanie. Ak sa nič nezmenilo, nové riziká neboli posúdené a interný audit sa nekonal, je to signál, že ISMS nefunguje. V krajnom prípade môže organizácia stratiť certifikát. A v kontexte zákona o kybernetickej bezpečnosti – povinnosť udržiavať bezpečnostné opatrenia je priebežná, nie jednorazová.
Ako sa tomu vyhnúť: Zabudujte ISMS do bežných procesov organizácie. Analýzu rizík revidujte pri každej významnej zmene (nový systém, nový dodávateľ, zmena infraštruktúry). Interný audit plánujte raz ročne. Manažérsky review zaraďte do pravidelného reportingu vedenia. ISMS nie je projekt s koncom – je to prevádzkový proces.
Chyba 6 – Ignorovanie dodávateľského reťazca
Organizácia implementuje ISMS pre interné procesy, ale ignoruje dodávateľov, ktorí majú prístupy do systémov, spracúvajú dáta alebo prevádzkujú časť služby. Cloudový provider, externý vývojár, outsourcovaný helpdesk – všetci predstavujú riziko, ktoré ISMS musí pokryť.
Prečo sa to deje: riadenie dodávateľov je organizačne náročné, vyžaduje zmluvné úpravy a spoluprácu s nákupom a právnym oddelením.
Prečo je to problém: ISO 27001 vyžaduje riadenie rizík tretích strán. Zákon o kybernetickej bezpečnosti ide ešte ďalej – § 19 ZoKB vyžaduje písomnú zmluvu s dodávateľmi, ktorých činnosti priamo súvisia s prevádzkou sietí a informačných systémov. Viac o dodávateľských povinnostiach v článku NIS2 a zákon o kybernetickej bezpečnosti na Slovensku v roku 2026.
Ako sa tomu vyhnúť: Zahrňte dodávateľov do analýzy rizík. Definujte bezpečnostné požiadavky v zmluvách. Pravidelne hodnoťte, či dodávatelia plnia dohodnuté opatrenia. Začnite s najkritickejšími – tými, ktorí majú prístup k vašim dátam alebo systémom.
Zhrnutie – čomu sa vyhnúť
Väčšina problémov pri implementácii ISMS nesúvisí s technológiou. Súvisia s tým, ako organizácia k ISMS pristúpi. Šesť najčastejších chýb v skratke:
- Dokumentácia, ktorá nezodpovedá realite
- Scope, ktorý je od začiatku príliš široký
- Vedenie, ktoré ISMS nevníma ako svoju tému
- SoA bez väzby na analýzu rizík
- Certifikácia chápaná ako koniec, nie začiatok
- Dodávatelia bez jasných bezpečnostných požiadaviek
Spoločný menovateľ úspešných implementácií je jednoduchý: ISMS má odrážať to, ako organizácia reálne funguje. Ak to tak je, certifikácia je len potvrdenie – nie prekvapenie.
Ďalšie články v sérii o ISO 27001
- ISO 27001 bez omáčky: čo je ISMS a čo musí mať firma nastavené
- ISO 27001 a NIS2 na Slovensku – čo majú spoločné a kde sa rozchádzajú
- Časté chyby pri zavádzaní ISMS – a ako sa im vyhnúť
