NIS2 pre vývojárov: bezpečnostný baseline pre SaaS, ERP a HR systémy

Štvrtok popoludní. CEO desaťčlennej softvérovej firmy v Bratislave otvorí email od najväčšieho klienta. Banka. V prílohe je 47-stranový dotazník o kybernetickej bezpečnosti. Termín na vyplnenie: 3 týždne. Otázky na šifrovanie dát, incident response plán, penetračné testovanie, správu prístupov, zálohovanie a obnovu po havárii.

Firma má skvelý produkt. Mzdový SaaS systém, ktorý používa 200 klientov. Ale nemá ISO 27001, nemá formalizovaný incident response, a posledný penetračný test robili pred rokom a pol. Dotazník nemá ako vyplniť tak, aby banka bola spokojná.

Toto sa deje čoraz častejšie. A dôvod sa volá NIS2.

NIS2 a supply chain efekt

NIS2 (Network and Information Security Directive 2) je smernica EÚ, ktorú Slovensko transponovalo do zákona v roku 2025. Priamo reguluje firmy v odvetviach, ktoré EÚ považuje za dôležité: energetika, doprava, zdravotníctvo, finančný sektor, vodné hospodárstvo, digitálna infraštruktúra a ďalšie.

Vaša softvérová firma tam pravdepodobne nie je. Ale vaši klienti tam sú.

NIS2 ukladá regulovaným subjektom povinnosť riadiť bezpečnostné riziká v celom dodávateľskom reťazci. Článok 21 smernice výslovne hovorí o „bezpečnosti dodávateľského reťazca vrátane bezpečnostných aspektov týkajúcich sa vzťahov medzi každým subjektom a jeho priamymi dodávateľmi alebo poskytovateľmi služieb". Preložené do praxe: banka, ktorá používa váš mzdový systém, je zodpovedná za to, že vy ako dodávateľ spĺňate určitú úroveň bezpečnosti.

Komisia 20. januára 2026 navrhla cielené úpravy NIS2 na zjednodušenie compliance a zvýšenie právnej jasnosti. Smer ale zostáva rovnaký: regulované firmy budú od dodávateľov vyžadovať viac, nie menej.

Výsledok: aj keď NIS2 priamo nereguluje vašu firmu, vaši klienti vám začnú klásť otázky, na ktoré budete musieť vedieť odpovedať. Ak neodpoviete, hľadajú náhradu.

Bezpečnostný baseline pre SaaS

Čo teda enterprise klient od SaaS dodávateľa očakáva? Na základe dotazníkov, ktoré vidíme u klientov, sa opakuje niekoľko oblastí.

Riadenie prístupov. Kto má prístup k produkčným dátam? Ako sa prístupy prideľujú a odoberajú? Máte MFA pre administrátorov? Máte princíp najmenších oprávnení? Ak vývojár odíde z firmy, koľko trvá, kým stratí prístup k infraštruktúre?

Väčšina malých softvérových firiem má prístupy riešené ad hoc. Admin heslo k databáze pozná polovica tímu. SSH kľúče sa nerotujú. Odchádzajúci zamestnanec má ešte týždeň prístup k produkcii, lebo „nestihli sme revokovať". Pre enterprise klienta je toto neprijateľné.

Šifrovanie. Dáta musia byť šifrované pri prenose (TLS 1.2+) aj v pokoji (AES-256 alebo ekvivalent). Šifrovanie v pokoji sa týka databáz, záloh a logov. Ak máte zálohy na S3 buckete bez šifrovania, máte problém. Ak sa k logom dá dostať bez autentifikácie, máte väčší problém.

Správa zraniteľností. Skenujete závislosti? Ako často? Čo sa stane, keď sa objaví kritická CVE v knižnici, ktorú používate? Máte definovaný SLA na patch? Firmy, ktoré dodávajú softvér bankám, zdravotným poisťovniam alebo energetickým spoločnostiam, budú musieť preukázať, že majú proces na sledovanie a riešenie zraniteľností. SBOM (Software Bill of Materials) sa z voliteľného doplnku stáva štandardnou požiadavkou.

Bezpečný vývojový cyklus. Code review, statická analýza, bezpečnostné testovanie pred releaseom. Ak robíte code review len niekedy a automatizované bezpečnostné skeny nemáte, toto je prvé miesto na zlepšenie. Klienti sa budú pýtať na váš SDLC (Secure Development Lifecycle) proces. Ak ho nemáte zdokumentovaný, odpoveď „robíme code review" nestačí.

Incident response pre desaťčlennú firmu

NIS2 vyžaduje od regulovaných subjektov hlásiť bezpečnostné incidenty. Do 24 hodín od zistenia: včasné varovanie. Do 72 hodín: podrobnejšia notifikácia. Do mesiaca: záverečná správa.

Vás ako dodávateľa sa to týka nepriamo. Ak dôjde k úniku dát vo vašom SaaS systéme, váš klient (banka, poisťovňa) musí hlásiť incident regulátorovi. A bude potrebovať od vás informácie: čo sa stalo, kedy, aký bol rozsah, aké dáta boli dotknuté, čo ste urobili.

Ak nemáte incident response plán, tieto informácie nebudete vedieť poskytnúť včas. „Dáme vedieť, keď to preskúmame" nie je odpoveď, ktorú banka akceptuje, keď má 24 hodín na hlásenie regulátorovi.

Incident response plán pre malú firmu nemusí byť 50-stranový dokument. Potrebujete vedieť: kto je kontaktná osoba, aký je komunikačný kanál, kto má právomoc rozhodnúť o odpojení systému, kde sú logy, kto ich vie analyzovať. A musíte to mať napísané a odskúšané. Simulácia incidentu raz za pol roka je minimum.

Audit trail: kde sa stretávajú tri regulácie

Zaujímavý detail: požiadavky na logging a audit trail sa objavujú v troch reguláciách súčasne.

NIS2 vyžaduje zaznamenávanie bezpečnostných udalostí a schopnosť vyšetriť incident. AI Act vyžaduje logging pre vysokorizikové AI systémy. Smernica o transparentnosti odmeňovania vyžaduje audit trail pre mzdové rozhodnutia.

Ak váš SaaS systém spracúva mzdy a má AI komponent (napríklad odporúčanie zaradenia do platového pásma), podlieha požiadavkám všetkých troch regulácií na logging. To nie je tri rôznych logovacích systémov. Je to jeden, ktorý musí pokrývať bezpečnostné udalosti, AI rozhodnutia aj zmeny v mzdových dátach.

Prakticky to znamená: štruktúrované logy s timestampom, identitou aktéra, typom akcie, vstupom a výstupom. Retenčná doba minimálne 6 mesiacov (AI Act), ale v praxi skôr rok a viac. Logy musia byť chránené pred manipuláciou. A musia byť prístupné pre audit bez toho, aby ste museli dva dni hľadať v nečitateľných textových súboroch.

Keď ste vy dodávateľ

Supply chain security pod NIS2 znamená, že regulovaný klient od vás bude chcieť dôkazy. Nie sľuby. Dôkazy.

Bezpečnostné dotazníky. Štandardizované formuláre (často založené na CAIQ od Cloud Security Alliance alebo vlastné od klienta), kde odpovedáte na otázky o šifrovaní, prístupoch, testovaní, zálohovacích politikách. Ak nemáte odpovede pripravené, každý dotazník vás bude stáť dni práce.

Certifikácie. ISO 27001 je de facto štandard. SOC 2 Type II je bežný v americkom kontexte, ale aj európski klienti ho akceptujú. Ak nemáte certifikáciu a neplánujete ju, budete musieť každému klientovi individuálne dokazovať, že máte procesy na úrovni. To je drahšie a pomalšie.

Penetračné testovanie. Minimálne raz ročne, ideálne externým testerom. Klient bude chcieť vidieť výstupnú správu a dôkaz, že nájdené zraniteľnosti boli opravené. Stará správa spred dvoch rokov nepomôže.

SLA na patching. Kritická zraniteľnosť = patch do 48 hodín. Vysoká = do 7 dní. Stredná = do 30 dní. Toto sú typické očakávania enterprise klientov. Ak máte release cyklus raz za mesiac a objavíte kritickú CVE, musíte vedieť spraviť hotfix mimo štandardného cyklu.

Segregácia dát v multi-tenant SaaS

Ak prevádzkujete multi-tenant SaaS, kde dáta viacerých klientov bežia na spoločnej infraštruktúre, NIS2 pridáva ďalšiu vrstvu požiadaviek.

Tenant izolácia. Klient A nesmie za žiadnych okolností vidieť dáta klienta B. Ani pri chybe v aplikácii, ani pri nesprávne nastavenej query, ani pri úniku cez logy. Ak používate zdieľanú databázu s tenant_id stĺpcom, máte logickú izoláciu. Niektorí enterprise klienti budú vyžadovať fyzickú izoláciu (samostatná databáza alebo schéma). Zvážte, či je vaša architektúra pripravená to ponúknuť.

Zálohy. Ak zálohujete celú databázu naraz, obnova jedného tenanta znamená obnovu všetkých. To je problém pri incidente, kde bol kompromitovaný len jeden klient. Granulárne zálohy a obnova po tenantoch sú technicky náročnejšie, ale pre regulovaných klientov sa stávajú požiadavkou.

GDPR a NIS2 sa tu stretávajú. Ak klient požiada o výmaz dát (právo byť zabudnutý pod GDPR), musíte vedieť preukázať, že dáta boli vymazané aj zo záloh. To pri zdieľaných zálohách nie je triviálne.

Čo robiť teraz

Ak ste softvérová firma, ktorá dodáva produkt regulovaným klientom, začnite tu:

Zmapujte, kto sú vaši regulovaní klienti (banky, poisťovne, zdravotnícke zariadenia, energetické firmy) a aké bezpečnostné požiadavky od vás budú mať. Ak to neviete, opýtajte sa ich priamo. Lepšie je pripraviť sa šesť mesiacov dopredu ako riešiť dotazník pod tlakom.

Formalizujte incident response plán. Nemusí byť dlhý, ale musí existovať, byť aktuálny a odskúšaný.

Zavedzte automatizované skenovanie závislostí a definujte SLA na patching. Toto je najrýchlejší spôsob, ako zlepšiť bezpečnostnú úroveň bez veľkých investícií.

Zvážte ISO 27001 certifikáciu. Proces trvá 6 až 12 mesiacov, ale výsledok je universal proof, ktorý akceptuje väčšina enterprise klientov. Na financovanie prípravy sa dajú využiť granty na digitalizáciu, kde program Digital Europe pokrýva aj projekty v oblasti kybernetickej bezpečnosti.

Ak neviete, kde začať, ozvite sa nám. Robíme bezpečnostné posúdenia a návrhy architektúry pre firmy, ktoré chcú splniť bezpečnostné požiadavky enterprise klientov bez toho, aby museli najímať interný bezpečnostný tím. Viac o národnej kybernetickej stratégii a jej dopadoch na IT dodávateľov sme písali tu.