# Odpowiedzialność zarządu za luki w bezpieczeństwie IT

> Odpowiedzialność zarządu za luki w bezpieczeństwie IT: obowiązek staranności, NIS2 i jak rzetelnie dokumentować decyzje. Ogólne wyjaśnienie, nie porada prawna.

Źródło: https://phpsos.de/pl/compliance/geschaeftsfuehrer-haftung/  
Stan: 25.10.2026  
Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6

**Krótko:** Bezpieczeństwo IT należy do zadań kierownictwa. Odpowiedzialność zarządu za luki w bezpieczeństwie IT omawia się przede wszystkim wtedy, gdy znane ryzyka nie były odpowiednio traktowane, nie uregulowano odpowiedzialności lub decyzje podjęto w sposób niemożliwy do prześledzenia. W sytuacjach takich jak PHP2Shell pomaga jasna, udokumentowana decyzja oparta na dostępnych faktach. Ta strona to ogólna informacja, a nie porada prawna.

> **Ważne:**
> Brak porady prawnej: kwestie odpowiedzialności zależą silnie od konkretnego przypadku, formy prawnej i regulacji umownych. Konkretne pytania proszę zlecić do oceny adwokatowi lub radcy prawnemu od prawa spółek.

## Odpowiedzialność zarządu a bezpieczeństwo IT: ogólne ramy

Dla członków zarządu spółki z o.o. § 43 GmbHG (niemiecka ustawa o spółkach z ograniczoną odpowiedzialnością) wymaga staranności rzetelnego przedsiębiorcy. Dla członków zarządu spółki akcyjnej § 93 AktG (niemiecka ustawa o spółkach akcyjnych) zawiera porównywalną regułę; § 91 ust. 2 AktG wymaga ponadto odpowiednich środków do wczesnego rozpoznawania zjawisk zagrażających istnieniu spółki. Z tych ogólnych obowiązków wywodzi się w dyskusji fachowej, że także ryzykami IT trzeba odpowiednio zarządzać.

Dla decyzji przedsiębiorczych istnieje margines oceny. Kto decyduje na podstawie odpowiednich informacji i dla dobra spółki, działa według tak zwanej Business Judgment Rule zasadniczo należycie, nawet jeśli decyzja później okaże się niekorzystna. Wynika z tego praktyczna nauka: rozstrzygający jest często mniej wynik, a bardziej pytanie, czy decyzję podjęto świadomie i w sposób czytelny.

## Co dodaje NIS2

Dla firm podlegających NIS2 odpowiedzialność kierownictwa została uregulowana wprost. Kierownictwo musi zatwierdzać środki zarządzania ryzykiem, nadzorować ich wdrożenie i szkolić się w cyberbezpieczeństwie. W Niemczech wdrożenie następuje przez NIS2UmsuCG (niemiecka ustawa wdrażająca NIS2). Czy Państwa firma jest objęta i jakie obowiązki obowiązują w szczególności, proszę przyjąć z informacji BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej). Ogólny przegląd daje artykuł [NIS2 a bezpieczeństwo serwerów WWW](https://phpsos.de/pl/compliance/nis2/).

Dochodzą obowiązki z ochrony danych. Według RODO firma musi stosować odpowiednie środki techniczne i organizacyjne oraz oceniać naruszenia ochrony danych osobowych według art. 33, dokumentować je i w razie potrzeby zgłaszać.

## Czego sytuacja taka jak PHP2Shell wymaga od kierownictwa

PHP2Shell obejmuje dwie krytyczne luki w samym PHP (CVE-2026-109618 i CVE-2026-109619, każda CVSS v4.0 9.2). BSI ogłosiło stopień ostrzeżenia 3 (pomarańczowy) i zaleca natychmiastową aktualizację, a jeśli to niemożliwe, czasowe odłączenie serwerów WWW od sieci. Dla kierownictwa powstaje typowe rozważenie: przychód i dostępność wobec wysokiego, publicznie znanego ryzyka.

Nikt nie wymaga, aby członkowie zarządu sami łatali serwery. Można jednak oczekiwać, że przyjmą sytuację do wiadomości, wyjaśnią odpowiedzialności, zażądają raportu i podejmą decyzję. Pytania, które powinno sobie zadać kierownictwo:

- Które z naszych systemów używają PHP i kto za nie odpowiada, wewnętrznie czy u usługodawcy?
- Czy aktualizacje są zainstalowane, a procesy zrestartowane i czy jest na to dowód?
- Jeśli nie: dlaczego nie, jakie środki przejściowe działają i czy odłączamy system od sieci?
- Czy są przesłanki włamania i kto ocenia możliwe obowiązki zgłoszeniowe?

## Dokumentowanie decyzji

Proszę zapisać krótko obraz sytuacji, opcje, decyzję i uzasadnienie, z datą i godziną. Taki protokół nie musi być długi. Pokazuje później, że kierownictwo było poinformowane i rozważyło sprawę. Dotyczy to wyraźnie także decyzji o dalszym prowadzeniu systemu przez ograniczony czas mimo ryzyka.

| Treść | Przykład |
|---|---|
| Obraz sytuacji | BSI stopień ostrzeżenia 3, poprawki dostępne od 21.10.2026 |
| Dotknięte systemy | Sklep, portal klientów, wewnętrzna instalacja wiki |
| Opcje | załatać natychmiast, środki przejściowe, odłączyć od sieci |
| Decyzja | Sklep załatany, wiki offline do czasu aktualizacji |
| Uzasadnienie i odpowiedzialni | Dowód od usługodawcy, kontrola przez kierownika IT |

Poprawka nie usuwa już wprowadzonego szkodliwego oprogramowania. Także decyzja, czy szuka się śladów, należy do protokołu.

## Zorganizować trwale zamiast improwizować w sytuacji kryzysowej

Najlepszą prewencją jest jasna organizacja: wyznaczona osoba odpowiedzialna za bezpieczeństwo informacji, procedura aktualizacji bezpieczeństwa, regularne raporty dla kierownictwa, przetestowany [plan awaryjny IT](https://phpsos.de/pl/compliance/notfallplan-erstellen/) i niezależna kontrola w rozsądnych odstępach. Ramą metodyczną jest IT-Grundschutz (podstawowa ochrona IT) wydany przez BSI.

Do organizacji należy także takie przygotowanie raportów, aby kierownictwo je rozumiało. Często wystarcza krótki, regularny raport z kilkoma danymi: ile systemów ma aktualny stan, gdzie są wyjątki i dlaczego, jakie były incydenty lub prawie-incydenty, jakie decyzje są do podjęcia. Kto przyjmuje takie raporty, zadaje pytania i zapisuje wyniki, może później wykazać, że nadzór faktycznie miał miejsce. Dotyczy to niezależnie od tego, czy technika leży wewnątrz firmy, czy u usługodawcy.

## Jak konkretnie pomaga PHP SOS?

- Sporządzamy zrozumiały obraz sytuacji Państwa serwerów WWW dla kierownictwa, z jasnymi opcjami.
- Wdrażamy wybraną opcję i dostarczamy pisemny dowód techniczny.
- Przez [audyt bezpieczeństwa lub test penetracyjny](https://phpsos.de/pl/leistungen/sicherheitsaudit-penetrationstest/) tworzymy niezależną podstawę Państwa decyzji.
- Dzięki [umowie serwisowej bezpieczeństwa](https://phpsos.de/pl/leistungen/security-wartungsvertrag/) trwale regulujemy aktualizacje i raporty.


## Częste pytania

**Czy członek zarządu odpowiada osobiście za atak hakerski?**  
Sam atak nie uzasadnia odpowiedzialności osobistej. Odpowiedzialność omawia się przede wszystkim wtedy, gdy naruszono obowiązki staranności, na przykład zignorowano znane ryzyka lub nie uregulowano odpowiedzialności. Czy tak jest w konkretnym przypadku, ocenia wyłącznie doradca prawny.

**Czy mogę całkowicie przekazać bezpieczeństwo IT działowi IT lub usługodawcy?**  
Zadania można delegować, ale odpowiedzialność za wybór, wyposażenie i nadzór pozostaje po stronie kierownictwa. Proszę regularnie przyjmować raporty i zapisywać, jakie decyzje podjęto na jakiej podstawie.

**Co NIS2 zmienia w odpowiedzialności kierownictwa?**  
NIS2 wymaga od kierownictwa objętych firm zatwierdzania środków zarządzania ryzykiem, nadzorowania ich wdrożenia i udziału w szkoleniach. Szczegóły wynikają z niemieckiej ustawy wdrażającej i z informacji BSI.

**Czy pomaga ubezpieczenie D&O?**  
Ubezpieczenie odpowiedzialności cywilnej członków organów (D&O) może pokrywać określone ryzyka odpowiedzialności kierownictwa, ale warunki bardzo się różnią. Zakres proszę wyjaśnić z brokerem lub ubezpieczycielem.

## Źródła

- [BSI](https://www.bsi.bund.de/)
- [BSI IT-Grundschutz (podstawowa ochrona IT)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [RODO art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)