NIS2 pro dodavatele softwaru: 30denní plán

NIS2 pro dodavatele softwaru není jen téma pro banky, energetiku nebo kritickou infrastrukturu. Pokud firma dodává web, klientský portál, rezervační systém, integraci nebo interní aplikaci většímu klientovi, může se bezpečnost objevit v dotazníku, smlouvě nebo výběrovém řízení dřív, než čekala. Neznamená to automaticky, že se na takovou firmu přímo vztahuje celý zákonný režim. Znamená to ale, že odběratel bude chtít vědět, jak dodavatel pracuje s přístupy, incidenty, zálohami, monitoringem a předáváním odpovědností.

Tento článek není právní návod ani slib souladu se zákonem. Je to praktický obchodní pohled: co si připravit během 30 dní, aby webové a softwarové dodávky nepůsobily jako riziko, ale jako promyšlená součást provozu klienta.

Proč má menší dodavatel řešit NIS2, i když není regulovaný subjekt?

Protože větší klient často neřeší jen vlastní systémy, ale celý řetězec dodavatelů. NIS2 a navazující česká úprava posilují důraz na řízení rizik, hlášení incidentů a bezpečnost dodavatelských vztahů. V praxi se to propíše do nákupních procesů: více otázek před podpisem smlouvy, více požadavků na evidenci a méně prostoru pro odpověď typu „to má na starosti ajťák“.

Dodavatel webu nebo portálu nemusí tvrdit, že „zajišťuje NIS2“. To by bylo zavádějící bez jasného právního scope. Může ale doložit, že má základní provozní disciplínu: ví, kdo má přístup do administrace, kde běží produkce, jak se zálohuje, co se sleduje a jak se eskaluje problém. To je rozdíl mezi improvizací a dodávkou, která se dá obhájit před interním bezpečnostním týmem klienta.

U projektů typu klientský portál, rezervační systém nebo registrační web pro eventy nejde jen o technologii. Jde o důvěru. Pokud portál zpracovává poptávky, rezervace, platby, dokumenty nebo stav případu, bezpečnostní otázky jsou přirozené. LucidMark k podobným systémům přistupuje productově: nejdřív se mapuje workflow, odpovědnosti a provozní rizika, až potom design a vývoj. Více o tom, jak firma uvažuje o práci a vlastnictví dat, popisuje článek Jak funguje LucidMark a na čem si zakládáme.

Jaké otázky se objeví v bezpečnostním dotazníku?

Nejčastěji půjde o otázky, které mají ověřit základní kontrolu nad systémem. Kdo spravuje hosting a doménu? Kdo má administrátorská práva? Jak se přístupy odebírají po odchodu člověka z projektu? Existují zálohy a ví někdo, jak obnovu vyzkoušet? Jak se pozná, že formulář, platba nebo integrace přestala fungovat?

Druhá skupina otázek se týká incidentů. Klient může chtít vědět, kdo je kontaktní osoba, jak rychle se problém předává, jak se dokumentuje dopad a jak se odlišuje technická chyba od bezpečnostního incidentu. Není nutné slibovat nepřetržitý dohled, pokud není smluvně sjednaný. Je ale fér popsat konkrétní mechanismus: monitoring dostupnosti, sledování chybovosti, logy důležitých akcí a domluvený eskalační kontakt.

Třetí část bývá procesní. Klient se ptá, zda dodavatel používá subdodavatele, jak eviduje změny, jestli má oddělený přístup do produkce a vývoje, jak řeší záplaty a kdo schvaluje zásahy do dat. U automatizací a AI agentů dává smysl popsat read-first režim, lidské potvrzení akcí měnících data, role a audit logy. Takové vysvětlení je konkrétnější než obecné tvrzení, že je systém bezpečný.

Co si připravit do evidence dodavatelů a smluv?

Začněte jednoduchým evidenčním listem systému. U každého webu, portálu nebo interní aplikace by mělo být jasné, kdo je vlastník služby, jaký je účel, kde jsou uložena data, kdo má administrátorský přístup, jaké externí služby systém používá a jak se řeší incident. Takový dokument nemusí mít desítky stran. Důležité je, aby existoval a šel aktualizovat po změně dodavatele, hostingu nebo integrace.

U větších klientů pomůže i stručná mapa odpovědností. Dodavatel může držet technický provoz, klient vlastní obsah, doménu a účty, účetní systém spravuje třetí strana a platební bránu další partner. Bez mapy vzniká problém ve chvíli, kdy se něco pokazí. Nikdo neví, komu volat a kdo může provést změnu.

Právě tady se bezpečnost stává obchodní výhodou. Ve výběrovém řízení nerozhoduje jen vzhled webu nebo cena vývoje. Rozhoduje i dojem, že dodavatel rozumí provozu po spuštění. Studio, které umí ukázat evidenci, monitoring, zálohy, správu přístupů a srozumitelné předání, snižuje tření na straně klientova IT, právního oddělení i nákupu.

Jak má vypadat 30denní plán pro web a interní systémy?

Prvních 30 dní nemá být audit všech detailů. Cílem je dostat základní pořádek do věcí, které klient pozná v dotazníku a tým pozná při incidentu. NIS2 pro dodavatele softwaru se v praxi nejlépe uchopí jako krátký provozní sprint.

• Dny 1 až 7: sepište systémy, domény, účty, přístupy a externí služby. U každé položky určete vlastníka a kontaktní osobu. Odeberte přístupy lidem, kteří je už nepotřebují.
• Dny 8 až 14: zkontrolujte zálohy a obnovu. Nestačí vědět, že záloha existuje. Je potřeba vědět, co obnovuje, kam se ukládá a kdo má právo obnovu spustit.
• Dny 15 až 21: nastavte monitoring dostupnosti, chybovosti a klíčových obchodních procesů. U webu to může být formulář, objednávka nebo rezervace. U portálu přihlášení, nahrání dokumentu nebo změna stavu.
• Dny 22 až 30: připravte odpovědi do bezpečnostního dotazníku, jednoduchý incidentní postup a krátký provozní report pro klienta. Vyhněte se slibům, které nemáte smluvně kryté. Popište skutečný mechanismus.

Podobný přístup dává smysl i u obchodních procesů, které nejsou na první pohled bezpečnostní. Pokud přestane fungovat kontaktní formulář, rezervace nebo platba, firma ztrácí poptávky a důvěru. Praktické rozšíření tématu popisuje článek Monitoring obchodních procesů: formuláře a platby.

Kdy se z bezpečnosti stává výhoda ve výběrovém řízení?

Ve chvíli, kdy ji dodavatel umí vysvětlit bez přehánění. Silná odpověď nezní „splňujeme všechno“. Silná odpověď zní: tady je evidence systému, tady jsou role, tady jsou zálohy, tady je monitoring, tady je postup při incidentu a tady jsou hranice naší odpovědnosti. Pro nákupčího je to důkaz, že po podpisu smlouvy nezačne provozní mlha.

U prémiového webu nebo custom portálu se tím mění debata. Neprodává se jen obrazovka, ale systém, který má vlastníka, provozní režim a péči po spuštění. LucidMark staví weby a custom systémy právě pro firmy, kterým už nestačí šablona, Excel a ruční administrativa. Bezpečnostní připravenost do toho patří stejně jako design, obsah a integrace.

Co si z toho odnést?

NIS2 pro dodavatele softwaru není důvod k panice. Je to signál, že větší klienti budou častěji chtít vidět pořádek v dodavatelském řetězci. Menší firma nemusí předstírat roli právního poradce ani bezpečnostního korporátu. Může ale udělat konkrétní kroky: sepsat systémy, vyčistit přístupy, ověřit zálohy, nastavit monitoring a připravit srozumitelné odpovědi.

Výsledek je praktický. Klient dostane jistotu, že dodávka má hlavu a patu. Dodavatel se lépe obhájí ve výběrovém řízení. A tým má v ruce plán, podle kterého se dá při problému jednat, ne hádat.