OC ZAWODOWE / PROGRAMISTA
Błąd w logice, deployment, utrata danych, naruszenie licencji albo przestój mogą skończyć się roszczeniem, choć nic nie zostało fizycznie zniszczone. Dlatego OC programisty czytamy przez projekt i kontrakt, nie przez nazwę stanowiska.
MAPA RYZYKA
To nie jest lista funkcji w produkcie. To sześć obszarów, które sprawdzamy przed porównaniem ofert.
Nieprawidłowa logika biznesowa, obliczenia, integracja albo warunek brzegowy mogą wygenerować czystą stratę finansową bez uszkodzenia jakiejkolwiek rzeczy.
Wdrożenie, migracja, aktualizacja lub konfiguracja mogą doprowadzić do przestoju, utraty sprzedaży albo kosztów odtworzenia środowiska.
Usunięcie, uszkodzenie, ujawnienie albo niewłaściwe przetworzenie danych może uruchomić odpowiedzialność zawodową, prywatnościową i cyber. Zakresy trzeba rozdzielić.
Roszczenia mogą dotyczyć praw autorskich, znaków, licencji lub użycia komponentu niezgodnie z jego warunkami. Ochrona IP nie jest automatyczna w każdej polisie.
Przy freelancerach, podwykonawcach i outsourcingu sprawdzamy, czy ich działania są objęte ochroną oraz czy polisa zachowuje prawo regresu wobec wykonawcy.
Limit odpowiedzialności, SLA, obowiązek ubezpieczenia, prawo właściwe, jurysdykcja i odpowiedzialność za dane powinny być czytane razem z polisą.
TRZY WARSTWY
Kliknij warstwę. Dobra ochrona IT może łączyć je ze sobą, ale nie powinno się ich traktować jako synonimów.
To warstwa najbliższa pracy programisty: projektowanie, programowanie, wdrożenia, utrzymanie, dane i inne usługi technologiczne. Kluczowe są czyste straty finansowe oraz błędy i zaniechania zawodowe.
Zwykłe OC działalności może uzupełniać ochronę o szkody rzeczowe i osobowe związane z prowadzeniem firmy, ale samo w sobie nie powinno być traktowane jako zamiennik specjalistycznego OC IT.
Warstwa cyber może odpowiadać na incydent bezpieczeństwa, reakcję na naruszenie, odtworzenie działalności lub odpowiedzialność związaną z danymi. Zakres i wymagania techniczne trzeba sprawdzać osobno.
SCENARIUSZE
Scenariusze pokazują rodzaj ekspozycji. Odpowiedzialność i wypłata zawsze zależą od okoliczności i warunków konkretnej polisy.
Sprawdzamy ochronę czystych strat finansowych, definicję błędu zawodowego, limit oraz sposób liczenia szkody i kosztów obrony.
Znaczenie ma odpowiedzialność za wadliwe oprogramowanie i finansowy skutek błędu, nawet gdy system technicznie nadal działa.
Weryfikujemy zakres usług, czystą stratę finansową, odpowiedzialność za integracje i limity dla jednego zdarzenia.
Trzeba ustalić granicę pomiędzy OC zawodowym, odpowiedzialnością za prywatność i ubezpieczeniem cyber oraz sprawdzić wyłączenia dotyczące bezpieczeństwa.
Sprawdzamy, czy polisa obejmuje określone naruszenia własności intelektualnej i jakie wyłączenia dotyczą licencji, patentów lub świadomego naruszenia.
AUDYT KONTRAKTU
W IT bardzo często to umowa z klientem określa realną ekspozycję bardziej niż sam opis działalności.
Jeżeli umowa przewiduje wysoką odpowiedzialność wobec klienta, mała suma gwarancyjna może spełniać formalny wymóg polisy, ale nie odpowiadać realnej ekspozycji.
Terminy, SLA, service credits i kary trzeba czytać szczególnie uważnie. Polisy różnie traktują odpowiedzialność przyjętą wyłącznie umownie i konsekwencje opóźnienia.
Sprawdzamy terytorium, prawo właściwe i jurysdykcję. USA i Kanada często wymagają osobnej oceny lub rozszerzenia, ale konstrukcja zależy od konkretnego produktu.
Weryfikujemy, czy działania podwykonawców są w zakresie oraz jak działa regres, outsourcing i odpowiedzialność za pracę osób spoza Twojej firmy.
Open source, biblioteki, API, treści i komponenty osób trzecich wymagają analizy umowy licencyjnej oraz definicji naruszenia IP w polisie.
W polisach typu claims made znaczenie mają data retroaktywna, znane okoliczności, ciągłość ochrony i moment zgłoszenia roszczenia. Nie porównujemy więc tylko bieżącej składki.
TERYTORIUM I JURYSDYKCJA
Sam fakt, że pracujesz z Polski, nie odpowiada na pytanie, gdzie może zostać wniesione roszczenie.
Zakres terytorialny trzeba przeczytać w warunkach. Część rozwiązań IT obejmuje szerzej projekty europejskie, ale prawo właściwe i jurysdykcja nadal mają znaczenie.
Przy klientach z Wielkiej Brytanii sprawdzamy, czy kraj jest wprost objęty terytorium oraz czy polisa odpowiada na roszczenia rozpoznawane przez właściwy sąd.
Niektóre specjalistyczne programy IT oferują szeroki zakres światowy. Wyłączenia sankcyjne, jurysdykcja i kraje wysokiego ryzyka pozostają jednak odrębnymi punktami analizy.
Część polis standardowo wyłącza USA i Kanadę albo wymaga rozszerzenia. Przy takich kontraktach najpierw pokazujemy ubezpieczycielowi umowę i zakres usług.
PRZED WYBOREM
01Co dokładnie tworzysz: backend, frontend, mobile, embedded, gry, integracje czy systemy biznesowe?
02Czy wdrażasz kod na produkcję i odpowiadasz za utrzymanie lub dostępność?
03Jaki jest limit odpowiedzialności w Twojej najważniejszej umowie B2B?
04Jakie SLA, service credits, kary i terminy przyjąłeś w kontrakcie?
05Czy masz dostęp do danych osobowych, finansowych lub innych danych krytycznych klienta?
06Czy używasz bibliotek open source, kodu, grafik, API lub komponentów osób trzecich?
07Czy korzystasz z freelancerów, podwykonawców albo outsourcingu?
08Gdzie są klienci i jakie prawo oraz jurysdykcja obowiązują?
09Czy kontrakt wymaga osobnego Cyber lub OC działalności?
10Jak działa trigger, data retroaktywna i zgłaszanie okoliczności w wybranej polisie?
PYTANIA I ODPOWIEDZI
Zwykle nie powinno być traktowane jako zamiennik OC zawodowego IT. Typowe OC działalności skupia się na szkodach osobowych i rzeczowych, podczas gdy kluczowe ryzyko programisty to często czysta strata finansowa wynikająca z błędu w usłudze lub oprogramowaniu.
Nie istnieje jeden powszechny ustawowy obowiązek OC dla każdego programisty. Polisa bywa jednak wymagana przez kontrahenta lub wynikać z warunków umowy B2B.
Rdzeń ochrony może być podobny, ale profil ryzyka jest inny. Software house ma zwykle więcej osób, podwykonawców, projektów, danych i odpowiedzialności organizacyjnej.
Takie ryzyka obejmuje specjalistyczne OC IT — sprawdzamy definicję usług i wyłączenia.
W specjalistycznym OC zawodowym IT kluczową kategorią mogą być czyste straty finansowe, np. utracony zysk lub zwiększone koszty klienta. Sposób ich definiowania i udowodnienia zależy od warunków polisy.
Są rozszerzenia dotyczące własności intelektualnej, ale nie każde naruszenie jest objęte. Szczególnie ważne są wyłączenia dotyczące świadomego działania, patentów i konkretnych licencji.
W niektórych specjalistycznych programach tak, ale trzeba sprawdzić definicję podwykonawcy, zakres odpowiedzialności oraz ewentualny regres.
Nie. Mogą się częściowo stykać przy danych i bezpieczeństwie, ale odpowiadają na inne ryzyka. Dobra analiza pokazuje, gdzie kończy się odpowiedzialność zawodowa, a zaczyna własny incydent cyber.
Nie zawsze. Odpowiedzialność przyjęta wyłącznie umownie, kary, service credits i opóźnienia są obszarami, które trzeba sprawdzić wprost w warunkach konkretnej polisy.
W uproszczeniu istotny jest moment zgłoszenia roszczenia w okresie ochrony. Dlatego przy zmianie polisy sprawdzamy także datę retroaktywną, znane okoliczności i ciągłość ochrony.
Może, ale nie każdy produkt obejmuje USA i Kanadę standardowo. Często potrzebne jest rozszerzenie oraz osobna ocena kontraktu, prawa właściwego i jurysdykcji.
Patrzymy na limit odpowiedzialności w umowie, największą wartość projektu, możliwy przestój lub czystą stratę klienta, liczbę kontraktów, podwykonawców i terytorium działania — nie tylko na roczny przychód programisty.
PROGRAMISTA / FREELANCER / SOFTWARE HOUSE