Ubezpieczenie cyber dla firmy IT i software house
Jak odróżnić własny cyberincydent od odpowiedzialności za usługę IT?
Software house powinien rozdzielić naruszenie własnego środowiska, dostęp do systemów klientów i błąd w dostarczanym oprogramowaniu. To różne źródła szkody oraz możliwe zakresy cyber i OC zawodowego. Szczególnej analizy wymagają repozytoria, proces wydawania aplikacji, sekrety i odpowiedzialność kontraktowa.
Repozytorium nie jest jedynym zasobem do ochrony
Lista krytycznych usług powinna obejmować repozytoria, system CI/CD, rejestr paczek, dokumentację, zgłoszenia i środowiska produkcyjne. Dostęp do kodu nie musi oznaczać prawa do wdrożenia, lecz źle rozdzielone uprawnienia mogą połączyć oba obszary. Zidentyfikuj też tokeny działające bez logowania interaktywnego.
Kopie kodu na komputerach programistów nie zastępują kontrolowanego odtworzenia organizacji. Brak konfiguracji pipeline, historii zgłoszeń, kluczy i infrastruktury jako kodu może opóźnić powrót. Plan powinien wskazywać, jak odbudować zaufane środowisko, a nie tylko jak ponownie sklonować repozytorium.
| Sytuacja | Pytanie o odpowiedzialność | Dokument do sprawdzenia |
|---|---|---|
| Przejęcie własnego CI/CD | Koszty reakcji i odtworzenia | Cyberpolisa i definicja zdarzenia |
| Błąd w aplikacji klienta | Jakość wykonania usługi | OC zawodowe i kontrakt |
| Dostęp do danych klienta | Role i obowiązki zgłoszeniowe | Umowa powierzenia oraz zakres cyber |
Kontrakt może przyjmować więcej niż pokrywa polisa
Przygotuj informacje o usługach: tworzenie kodu, utrzymanie, hosting, zarządzanie bezpieczeństwem albo dostarczanie produktu SaaS. Zakres odpowiedzialności różni się także zależnie od tego, kto administruje produkcją. Opis „programowanie” jest niewystarczający, jeżeli firma ma stały uprzywilejowany dostęp do klientów.
Przeanalizuj kraje klientów, klauzule odszkodowawcze, ograniczenia odpowiedzialności i zobowiązania do określonej dostępności. Nie należy obiecywać, że cyberubezpieczenie pokryje przyjęte kontraktowo kary, zwrot wynagrodzenia lub koszt usunięcia każdego błędu. Ważniejsze od sumy na certyfikacie są definicje objętych roszczeń.
Dowody gotowości i dane do underwritingu
Warto znać zakres MFA, zasady rotacji sekretów, przegląd uprawnień oraz reakcję na podatność w używanej bibliotece. Przed ofertą opisz proces zatwierdzania wydań i separację środowisk. Nie przedstawiaj zaleceń technicznych jako uniwersalnej listy wymogów PZU; właściwe wymagania wynikają z wniosku i oferty.
W incydencie utrwal historię wdrożeń, logi dostępu i decyzje o odwołaniu tokenów. Przywrócenie zaufanego stanu może wymagać ponownej budowy artefaktów i sprawdzenia, czy złośliwa zmiana nie trafiła do klientów. Tę zależność trzeba uwzględnić w scenariuszu kosztów i planie komunikacji.
Odwołanie dostępu klienta jako część planu
Przed incydentem ustal z klientami kanał awaryjny oraz osoby uprawnione do zablokowania dostępu dostawcy. Jeśli własna poczta firmy IT jest przejęta, standardowa wiadomość z prośbą o reset może być niewiarygodna. Procedura powinna pozwalać obu stronom potwierdzić tożsamość.
W rejestrze zachowaj identyfikatory dotkniętych wydań i potwierdzenia wykonanych działań. Nie twierdź, że wszystkie instalacje klienta są bezpieczne wyłącznie dlatego, że usunięto podejrzany commit. Potrzebna jest weryfikacja zakresu oraz komunikacja o niepewności. Tak przygotowany materiał wspiera analizę techniczną i prawną, ale nie jest automatycznym dowodem odpowiedzialności lub wypłaty.
Najczęstsze pytania
Czy cyberpolisa zastępuje OC software house?
Nie należy traktować ich zamiennie. Trzeba dopasować własne koszty incydentu i roszczenia za usługę do właściwych warunków.
Czy prywatny Git to wystarczający backup?
Prywatność repozytorium nie potwierdza odtworzenia konfiguracji, uprawnień, sekretów ani pozostałych usług potrzebnych do wydawania aplikacji.
Na czym opieramy informacje
- PZU: OWU od ryzyk cybernetycznych UZ/162/2023Punkty 1–4, 2.29, 2.30; dokument sprawdzony 2026-11-06. Zakres zależy także od polisy.
- ENISA: Good Practices for Supply Chain CybersecurityPodstawa do analizy zależności od dostawców; publikacja 2023, dostęp 2026-11-06.
- ENISA Threat Landscape 2026Publikacja 22.09.2026; okres obserwacji 2025. Kontekst zagrożeń, nie prawdopodobieństwo szkody konkretnej firmy.
Opisy scenariuszy mają charakter hipotetyczny. Daty źródeł podano przy poszczególnych dokumentach, gdy były dostępne.