# Vytvoření IT nouzového plánu pro webové servery > Vytvořte IT nouzový plán pro webové servery: role, kontakty, inventář systémů, pravidla rozhodování a cesty oznamování, aby v krizi vše fungovalo. Zdroj: https://phpsos.de/cs/compliance/notfallplan-erstellen/ Stav: 25.10.2026 Poskytovatel: PHP SOS, Nouzová pomoc pro PHP a bezpečnost serverů. Okamžitá pomoc přes WhatsApp: https://wa.me/491736494914?text=Dobr%C3%BD%20den%2C%20PHP%20SOS%2C%20pot%C5%99ebujeme%20pomoc%20s%20na%C5%A1%C3%ADm%20PHP%20serverem.%20Firma%3A%20%E2%80%A6%20Web%3A%20%E2%80%A6 **Stručně:** IT nouzový plán pro webové servery předem stanoví, kdo v krizi rozhoduje, koho lze zastihnout, které systémy mohou být dotčeny a jaké kroky následují v jakém pořadí. Kdo chce vytvořit IT nouzový plán, nepotřebuje tlustou příručku, ale několik aktuálních stran, které jsou dostupné i bez fungujícího IT. Situace kolem PHP2Shell je dobrým důvodem to udělat nyní. ## Proč nouzový plán šetří čas a škody V krizi se první hodiny často ztratí hledáním: Kdo má přístup k poskytovateli hostingu? Kde jsou zálohy? Kdo rozhodne, zda e-shop půjde offline? Koho je třeba informovat? Nouzový plán na tyto otázky odpovídá předem, v klidu. PHP2Shell ukázal, jak krátký může být čas. Dne 20. 10. 2026 php.net oznámilo záplaty, 21. 10. v 16:00 německého času byly zveřejněny a BSI (německý Spolkový úřad pro informační bezpečnost) doporučil okamžitou aktualizaci nebo dočasné vypnutí. Firmy s plánem věděly, komu zavolat a které servery zkontrolovat. Jiné musely nejdřív zjistit, kde vůbec PHP běží. ## Vytvoření IT nouzového plánu: stavební kameny Praktický plán pro webové servery zahrnuje tyto části: **1. Role a rozhodování.** Kdo v krizi řídí, kdo zastupuje, kdo smí systémy vypnout, kdo mluví navenek? Zaznamenejte jména a zástupce. **2. Seznam kontaktů.** Interní kontaktní osoby, poskytovatel hostingu, agentura, IT poskytovatel, pověřenec pro ochranu osobních údajů, právní poradenství, kyberpojištění s číslem pojistné smlouvy, příslušný dozorový úřad pro ochranu osobních údajů, Zentrale Ansprechstelle Cybercrime (ústřední kontaktní místo pro kybernetickou kriminalitu) vaší spolkové země. Tento seznam musí být k dispozici vytištěný. **3. Inventář systémů.** Každý web, e-shop a portál se serverem, poskytovatelem hostingu, provozním režimem, verzí PHP, aplikací, odpovědnou osobou a druhem zpracovávaných dat. **4. Pravidla rozhodování.** Za jakých podmínek systém odpojíme od sítě? Kdo o tom smí rozhodnout? Co platí v noci a o víkendu? **5. Postupy.** Krátké sledy kroků pro typické případy: známá kritická zranitelnost, podezření na průnik, znehodnocený web, únik dat, vydírání. **6. Cesty oznamování.** Kdo posuzuje oznamovací povinnost podle čl. 33 GDPR, pokud možno do 72 hodin od zjištění? Kdo hlásí BSI při povinnosti podle NIS2? Kdo informuje pojišťovnu? **7. Obnova.** Kde leží zálohy, kdo je může obnovit, jak dlouho to trvá, kdy to bylo naposledy testováno? ## Příklad: postup „kritická zranitelnost PHP“ Takto může vypadat postup, jaký byl u PHP2Shell potřeba: | Krok | Kdo | Výsledek | |---|---|---| | Posoudit oznámení (php.net, BSI) | odpovědní za IT | dotčené systémy podle inventáře | | Nasadit aktualizaci, restartovat všechny workery | admin nebo poskytovatel | doklad se stavem balíčků a časem procesu | | Kde aktualizace nejde: přechodná opatření nebo odpojit od sítě | rozhoduje vedení | zdokumentované rozhodnutí | | Zajistit logy, zkontrolovat stopy | admin nebo forenzní analýza | nález nebo žádný nález | | Při nálezu: spustit postup pro incident | vedení krizového řízení | zkontrolovat cesty oznamování | Důležité přitom je: záplata zranitelnost uzavírá, ale neodstraní dříve zavlečený škodlivý software. Proto patří hledání stop pevně do postupu. > **Tip:** > Stanovte, jak dlouho se logy webového serveru uchovávají a kde leží mimo server. U PHP2Shell odborný tisk doporučoval uchovávat logy od 20. 10. 2026. Kdo logy drží jen několik dní, taková doporučení nemůže splnit. ## Příprava, která plán teprve zefektivní Plán je jen tak dobrý jako předpoklady za ním. Ověřte, zda existují a jsou otestovány zálohy podle pravidla 3-2-1, viz [Zálohy podle pravidla 3-2-1](https://phpsos.de/cs/ratgeber/backups-3-2-1/). S poskytovatelem hostingu a agenturou písemně vyjasněte, kdo při kritických zranitelnostech co přebírá. Přístupové údaje pro nouzové případy uchovávejte bezpečně, ale dosažitelně, například v chráněném trezoru hesel s nouzovým přístupem. Připravte také textové šablony: interní informaci, oznámení zákazníkům, upozornění na statické stránce o údržbě. Pokyny najdete na stránce [Krizová komunikace po útoku](https://phpsos.de/cs/compliance/krisenkommunikation/). ## Cvičit a udržovat aktuální Plán, který se nikdy necvičil, téměř vždy obsahuje mezery. Jednou ročně projděte jeden scénář, například „kritická zranitelnost PHP v pátek odpoledne“, a zaznamenejte, kde to drhne. Pro začátek stačí jednoduchý test: Dokáže druhá osoba bez pomoci první zastihnout poskytovatele hostingu, obnovit zálohu a přepnout web do režimu údržby? Pokud ne, v plánu něco chybí, většinou přístup, telefonní číslo nebo popis. Právě takové mezery mají cvičení zviditelnit dříve, než půjde do tuhého. Plán po každém cvičení a každé podstatné změně aktualizujte. Jako metodický rámec se hodí IT-Grundschutz (německý standard základní ochrany IT) od BSI a BSI-Standard 200-4 k řízení kontinuity činností. Právní otázky, například k oznamovacím povinnostem, plán nevyjasňuje konečně. Zajišťuje, aby byly správné osoby zapojeny včas. Tato stránka je obecná informace, nikoli právní poradenství. ## Jak konkrétně pomáhá PHP SOS? - S vámi vytvoříme inventář systémů vašich webových serverů, včetně provozního režimu a verze PHP. - Napíšeme technické postupy pro typické scénáře a odsouhlasíme je s poskytovatelem hostingu a agenturou. - Provedeme cvičení a poznatky zapracujeme do plánu. - V krizi převezmeme technickou stránku prostřednictvím [reakce na incidenty](https://phpsos.de/cs/leistungen/incident-response/), na přání zajištěnou [smlouvou o bezpečnostní údržbě](https://phpsos.de/cs/leistungen/security-wartungsvertrag/). ## Časté dotazy **Jak rozsáhlý musí IT nouzový plán být?** Co nejkratší, tak podrobný, jak je nutné. Pro webové servery často stačí několik stran s kontakty, seznamem systémů, pravidly rozhodování a postupy. Důležitější než rozsah je, aby byl aktuální a v krizi se našel. **Kde nouzový plán uchovávat?** Alespoň na jednom místě dostupném i bez fungujícího IT, například vytištěný nebo na odděleném zařízení. Plán, který leží jen na dotčeném serveru nebo v uzamčené firemní síti, v krizi nepomůže. **Jak často by se měl plán kontrolovat?** Alespoň jednou ročně a po každé podstatné změně, například při změně poskytovatele hostingu nebo novém softwaru. Smysl má krátké cvičení, při kterém se projde jeden scénář. **Existují vzory od BSI?** BSI se tématu nouzového řízení věnuje v rámci IT-Grundschutz a v BSI-Standardu 200-4 k řízení kontinuity činností (Business Continuity Management). Hodí se jako rámec; pro webové servery se vyplatí stručná, praktická verze. ## Zdroje - [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html) - [BSI](https://www.bsi.bund.de/) - [GDPR čl. 33](https://dsgvo-gesetz.de/art-33-dsgvo/) - [Policie: přehled ZAC](https://www.polizei.de/)