DORA je tu: Čo to znamená pre IT dodávateľov bánk a poisťovní
Európske nariadenie DORA mení spôsob, akým finančné inštitúcie vyberajú a riadia IT dodávateľov. Ak vyvíjate softvér pre banky alebo poisťovne, toto musíte vedieť.
Štvrtok popoludní. Riaditeľ desaťčlennej softvérovej firmy v Bratislave otvorí e-mail od najväčšieho klienta. Banka. V prílohe je dlhý dotazník o kybernetickej bezpečnosti. Pýta sa na šifrovanie dát, plán riešenia incidentov, penetračné testovanie, správu prístupov, zálohovanie a obnovu po havárii.
Firma má dobrý produkt. Mzdový SaaS systém, ktorý používajú stovky klientov. Nemá však formalizovaný postup pri incidente a výsledky posledného penetračného testu už nezodpovedajú aktuálnej verzii systému. Dotazník nevie vyplniť tak, aby banka dostala overiteľné odpovede.
Toto sa deje čoraz častejšie. A dôvod sa volá NIS2.
NIS2 (Network and Information Security Directive 2) je smernica EÚ. Slovensko ju prevzalo novelou zákona č. 69/2018 Z. z. o kybernetickej bezpečnosti, ktorá nadobudla účinnosť 1. januára 2025. Pravidlá sa týkajú subjektov v odvetviach ako energetika, doprava, zdravotníctvo, digitálna infraštruktúra či vybrané digitálne služby. Konkrétny rozsah treba overiť podľa slovenského zákona, nie iba podľa veľkosti firmy.
Vaša softvérová firma medzi regulované subjekty patriť nemusí. Niektorí z Vašich klientov tam však patria.
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". V praxi to znamená, že banka, ktorá používa Váš mzdový systém, zodpovedá za to, že Vy ako dodávateľ spĺňate určitú úroveň bezpečnosti.
NIS2 teda Vašu firmu priamo nereguluje a aj tak sa Vás dotkne. Vaši klienti Vám začnú klásť otázky, na ktoré budete musieť vedieť odpovedať. Ak neodpoviete, hľadajú náhradu.
Čo teda firemný klient od SaaS dodávateľa očakáva? V bezpečnostných dotazníkoch sa opakuje niekoľko oblastí.
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?
Riziko vzniká, keď administrátorské heslo k databáze pozná polovica tímu, SSH kľúče sa pravidelne neobmieňajú alebo odchádzajúci zamestnanec nestratí prístup k produkcii v deň odchodu. Pre regulovaného klienta je takýto stav neprijateľný.
Pri prenose používajte aktuálne podporované TLS a dáta v pokoji chráňte silným šifrovaním so spravovanými kľúčmi. Týka sa to databáz, záloh aj logov. Nešifrovaná záloha alebo logy bez riadneho overenia prístupu sú vážne riziko.
Skenujete závislosti? Ako často? Čo sa stane, keď sa objaví kritická CVE v knižnici, ktorú používate? Máte dohodnuté lehoty na opravu podľa rizika? Dodávateľ musí vedieť preukázať, že zraniteľnosti sleduje, vyhodnocuje a opravuje. Zoznam softvérových komponentov (SBOM) môže klientovi pomôcť rýchlejšie posúdiť dosah novej zraniteľnosti.
Kontrola kódu, statická analýza a bezpečnostné testovanie pred vydaním. Ak kontrolujete kód iba občas a nemáte automatizované bezpečnostné skeny, toto je prvé miesto na zlepšenie. Klienti sa budú pýtať na bezpečný vývojový cyklus. Odpoveď „kód si pozeráme navzájom“ bez zdokumentovaného postupu nestačí.
NIS2 vyžaduje od regulovaných subjektov hlásiť bezpečnostné incidenty. Do 24 hodín od zistenia musí prísť včasné varovanie, do 72 hodín podrobnejšia notifikácia a 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 od Vás potrebovať informácie. Čo sa stalo, kedy, aký bol rozsah, aké dáta boli dotknuté a čo ste urobili.
Ak nemáte plán riešenia incidentov, tieto informácie nebudete vedieť poskytnúť včas. „Dáme vedieť, keď to preskúmame" nie je odpoveď, ktorú banka akceptuje, keď má krátku zákonnú lehotu na prvé hlásenie.
Plán pre malú firmu nemusí byť 50-stranový dokument. Potrebujete vedieť, kto je kontaktná osoba, aký je komunikačný kanál, kto môže rozhodnúť o odpojení systému, kde sú logy a kto ich vie analyzovať. Postup má byť napísaný, pravidelne odskúšaný a po každej zmene systému aktualizovaný.
Zaznamenávanie udalostí pomáha pri bezpečnostnom vyšetrovaní a pri ďalších povinnostiach, napríklad ak systém používa vysokorizikové AI podľa AI Actu. Netreba budovať osobitný logovací systém pre každú reguláciu. Treba mať jednu premyslenú auditnú stopu, ktorá pokryje bezpečnostné udalosti, rozhodnutia AI aj dôležité zmeny údajov.
Prakticky to znamená štruktúrované logy s časom, identitou aktéra, typom akcie a výsledkom. Doba uchovávania sa má určiť podľa účelu, rizika, zmluvy a príslušných pravidiel. Neexistuje jedna univerzálna lehota pre každý systém. Logy musia byť chránené pred manipuláciou a dostupné na audit bez dvojdňového hľadania v nečitateľných súboroch.
Bezpečnosť dodávateľského reťazca podľa NIS2 znamená, že regulovaný klient od Vás bude chcieť dôkazy, nie iba sľuby.
Š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.
Klient môže žiadať ISO 27001 alebo iný nezávislý dôkaz. Certifikácia však nenahrádza funkčné technické kontroly. Ak ju nemáte, musíte procesy a ich účinnosť preukázať iným dohodnutým spôsobom.
Rozsah a frekvenciu určite podľa rizika a zmluvy, pri dôležitých systémoch s nezávislým testerom. Klient bude chcieť vidieť správu a dôkaz, že nájdené zraniteľnosti boli opravené. Stará správa k neaktuálnej verzii systému nepomôže.
Dohodnite si lehoty podľa závažnosti a reálneho rizika zneužitia. Ak vydávate novú verziu raz za mesiac a objaví sa aktívne zneužívaná kritická chyba, musíte vedieť pripraviť opravu mimo bežného cyklu.
Ak prevádzkujete viacnájomný (multi-tenant) SaaS, kde dáta viacerých klientov bežia na spoločnej infraštruktúre, potrebujete preukázateľné oddelenie dát.
Klient A nesmie vidieť dáta klienta B ani pri chybe v aplikácii, nesprávne zostavenom databázovom dopyte či úniku cez logy. Zdieľaná databáza s identifikátorom klienta poskytuje logické oddelenie. Niektorí regulovaní klienti môžu žiadať samostatnú databázu alebo schému. Architektúra má vedieť zrozumiteľne doložiť, ako izoláciu vynucuje a testuje.
Ak zálohujete celú databázu naraz, obnova jedného klienta môže znamenať prácu s dátami všetkých. Preto treba vopred overiť, ako sa dá bezpečne obnoviť konkrétny klient bez zásahu do ostatných a bez úniku ich dát.
GDPR a NIS2 sa tu stretávajú. Pri žiadosti o výmaz musíte mať zdokumentované, ako sa údaje zneprístupnia v aktívnych systémoch a ako sa s nimi naloží v zálohách podľa doby uchovávania. Pri zdieľaných zálohách to nie je triviálne.
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 plán riešenia incidentov. Nemusí byť dlhý, ale musí existovať, byť aktuálny a odskúšaný.
Zaveďte automatizované skenovanie závislostí a určite lehoty na opravy podľa rizika. Je to jeden z najrýchlejších spôsobov, ako zlepšiť bezpečnostnú úroveň bez veľkej investície.
Certifikáciu ISO 27001 zvážte vtedy, keď ju vyžadujú Vaši zákazníci alebo cieľový segment. Najprv však musia fungovať samotné opatrenia. Certifikát ich nenahradí.
Ak neviete, kde začať, ozvite sa nám. Robíme bezpečnostné posúdenia a návrhy architektúry pre firmy, ktoré potrebujú splniť požiadavky regulovaných klientov.
Európske nariadenie DORA mení spôsob, akým finančné inštitúcie vyberajú a riadia IT dodávateľov. Ak vyvíjate softvér pre banky alebo poisťovne, toto musíte vedieť.
AI Act platí v plnom rozsahu od 2. augusta 2026. AI na pracovné inzeráty, triedenie CV a hodnotenie kandidátov spadá pod vysokorizikové pravidlá.
Transpozičný deadline smernice o transparentnosti odmeňovania je 7. júna 2026. Prvý reporting pre firmy 250+ do júna 2027. Čo musí zvládnuť Váš mzdový systém.