Stručně: Smlouva s IT dodavatelem by neměla bezpečnost zmiňovat jen okrajově, ale upravit ji konkrétně: kdo aktualizuje které komponenty, v jaké lhůtě a s jakým dokladem, jak se informuje o kritických zranitelnostech, kdo se podílí na incidentu, jak se uchovávají logy a spravují přístupy a co se stane při ukončení. Tato stránka podává obecné pokyny a není právním poradenstvím; smlouvy kontroluje advokát.
Otázka, kterou položilo PHP2Shell: kdo je odpovědný?
Dne 21. 10. 2026 v 16 hodin německého času zveřejnil projekt PHP záplaty. BSI (německý Spolkový úřad pro informační bezpečnost) doporučil okamžitou aktualizaci nebo, kde to nebylo možné, webservery dočasně odpojit od sítě. V mnoha firmách pak nezačala práce, ale hledání odpovědnosti. Agentura odkazovala na poskytovatele hostingu, poskytovatel hostingu na smlouvu a ve smlouvě stálo „údržba podle pracnosti“.
Takové mezery ve smlouvách nejsou ojedinělé. Mnoho smluv s agenturami a dodavateli bylo uzavřeno v době, kdy šlo o výstavbu webu, ne o jeho bezpečný provoz po léta. Kritická zranitelnost v běhovém prostředí PHP, která se netýká ani CMS, ani kódu aplikace, pak snadno propadne mezi všemi.
Co by měla smlouva s IT dodavatelem upravit v oblasti bezpečnosti
Následující přehled uvádí body, které se v praxi ukázaly jako důležité. Nenahrazuje právní kontrolu, ale pomáhá rozpoznat mezery ve stávající smlouvě.
| Bod úpravy | Co by mělo být zachyceno | Vztah k PHP2Shell |
|---|---|---|
| Rozsah plnění | Které vrstvy jsou spravovány: operační systém, běhové prostředí PHP, webserver, CMS, pluginy, vlastní kód | Běhové prostředí PHP často ve výčtu chybělo |
| Lhůty aktualizací | odstupňované podle závažnosti, s výjimkou pro krizové situace | kritická zranitelnost s CVSS v4.0 9,2 |
| Restart a doklad | Aktualizace se považují za hotové až po restartu všech procesů, s písemným dokladem | nové soubory samy zranitelnost neuzavřou |
| Informování | aktivní upozornění při kritických zranitelnostech, s posouzením a plánem | mnoho zákazníků se muselo ptát samo |
| Součinnost při incidentech | podpora při analýze, zajištění, obnově, kontaktní osoba | hledání stop po záplatě |
| Logy | druh, uchovávání, vydání na požádání | odborný tisk radil zajistit logy od 20. 10. |
| Přístupy | osobní účty, dvoufázové ověření, seznam všech přístupů | kdo vlastně měl přístup? |
| Subdodavatelé | kdo je dále zapojen, informování při změně | hosting hostingu |
| Konec životnosti softwaru | upozornění s předstihem před koncem podpory, plán migrace | PHP 8.2 končí 31. 12. 2026 |
| Ukončení | vydání dat, dokumentace a přístupů, odebrání práv | změna po incidentu |
Lhůty a doklady: body, na kterých nejvíce záleží
Lhůty jsou jádrem. Formulace jako „bez zbytečného odkladu“ v krizovém případě nepomůže. Dohodněte lhůty odděleně podle závažnosti a stanovte, podle čeho se závažnost měří, například podle zařazení výrobcem nebo BSI. Pro mimořádné situace by měla platit krizová úprava: kdo je k zastižení, kdo rozhoduje, zda se systém dočasně odpojí od sítě, a jak se účtuje vícepráce.
Stejně důležitý je doklad. U PHP2Shell ukazovalo zobrazené číslo verze často málo, protože distribuce a hostingové firmy nasazují opravy jako backport. Spolehlivý doklad uvádí stav balíčku, okamžik instalace a restart všech procesů PHP. Které údaje přesně počítají, popisuje Jak se zeptat poskytovatele hostingu na stav záplat. Tyto údaje zařaďte do smlouvy jako povinný obsah.
Nechte si od dodavatele ke smlouvě dát matici úkolů: jeden řádek pro každou komponentu, jeden sloupec pro každý úkol, v každé buňce jméno. Mezery pak vyjdou najevo okamžitě, dlouho před dalším hlášením.
Přístupy, subdodavatelé a ukončení
Dodavatelé potřebují přístupy a právě ty jsou častou cestou útoku. Upravte, že každá osoba dostane vlastní účet, že dvoufázové ověření je povinné, kde to technika umožňuje, a že si můžete kdykoli vyžádat aktuální seznam všech přístupů. Pracovníci dodavatele, kteří odešli, se musí bez zbytečného odkladu odstranit ze všech systémů.
Pokud dodavatel sám spolupracuje s partnery, například s datovým centrem nebo specializovaným forenzním týmem, měli byste to vědět. Zpracovává-li některý z těchto partnerů osobní údaje, přibývají povinnosti z oblasti ochrany osobních údajů. Více v článku Zpracování osobních údajů, když dodavatelé přistupují na servery.
Ukončení se při uzavírání smlouvy zapomíná nejčastěji. Zachyťte, že se při konci smlouvy data, konfigurace, dokumentace a přístupové údaje předají úplně, všechny přístupy dodavatele se odeberou a písemně se to potvrdí. Právě po incidentu je jinak uspořádaná změna těžká.
Jak zkontrolovat stávající smlouvy
Nemusíte znovu vyjednávat všechny smlouvy. Pro začátek stačí pragmatický postup:
- Shromáždit všechny smlouvy s agenturami, poskytovateli hostingu a IT dodavateli, které se týkají webů nebo serverů.
- Každou smlouvu porovnat s tabulkou výše a označit otevřené body.
- Nejdůležitější mezery písemně nastolit u dodavatele, počínaje rozsahem plnění, lhůtami a dokladem.
- Výsledky zachytit v dodatku ke smlouvě a nechat je právně zkontrolovat.
- Matici úkolů převzít do krizového plánu.
Pro vedení firmy je tento krok také otázkou péče řádného hospodáře. Kdo jasně upraví odpovědnosti a zdokumentuje rozhodnutí, obstojí lépe, pokud se později objeví otázky. Souvislosti nabízí Odpovědnost vedení za bezpečnostní mezery v IT. Typické rozdělení úkolů u spravovaných serverů popisuje Managed server: vyjasnit odpovědnost.
Jak konkrétně pomáhá PHP SOS?
- Přečteme vaše stávající smlouvy a popisy plnění z technického hlediska a označíme, které komponenty a úkoly chybějí.
- Vytvoříme matici úkolů pro všechny weby a servery, kterou můžete odsouhlasit se svými dodavateli.
- Zformulujeme technické požadavky na lhůty, doklady a cesty hlášení, které může váš advokát převzít do smlouvy.
- Kde nikdo odpovědný není, převezmeme úkoly sami prostřednictvím smlouvy o bezpečnostní údržbě s jasně popsaným rozsahem.
Závěr: Dobrá smlouva zranitelnosti nezabrání, ale zabrání tomu, aby se v krizovém případě ztrácel čas otázkou odpovědnosti. Tato stránka je obecná informace a není právním poradenstvím.
Časté dotazy
Musí IT dodavatel nasazovat bezpečnostní aktualizace bez zakázky?
Záleží na smlouvě. Bez jasné úpravy je často sporné, zda aktualizace patří k dlužnému plnění. Smlouva by proto měla výslovně stanovit, kdo které komponenty aktualizuje a v jaké lhůtě. Za právní posouzení v jednotlivém případě odpovídá advokát.
Potřebuji navíc smlouvu o zpracování osobních údajů?
Pokud dodavatel jménem správce zpracovává osobní údaje nebo k nim může mít přístup, je zpravidla nutná smlouva o zpracování osobních údajů podle čl. 28 GDPR. Nenahrazuje smlouvu o plnění, ale doplňuje ji. Ujasněte to se svým pověřencem pro ochranu osobních údajů.
Jaké lhůty pro bezpečnostní aktualizace jsou běžné?
Pevné hodnoty neexistují. Smysluplné je odstupňování podle závažnosti, například samostatné lhůty pro kritické, vysoké a ostatní zranitelnosti. Důležité je, aby lhůty byly písemně a obsahovaly výjimku pro krizové situace jako PHP2Shell.
Co se stane s přístupy, když smlouva skončí?
To by měla upravit smlouva: vrácení nebo smazání dat, předání přístupových údajů a dokumentace, odebrání všech přístupů dodavatele a potvrzení o tom.