NDA dla programisty — na co uważać przy karach umownych?

Umowa o zachowaniu poufności jest jednym z najczęściej podpisywanych dokumentów w branży IT. Programista może otrzymać dostęp do kodu źródłowego, dokumentacji technicznej, infrastruktury, baz danych, informacji o zabezpieczeniach, planów rozwoju produktu, modeli biznesowych, danych klientów oraz niepublicznych warunków współpracy. Ujawnienie takich informacji może spowodować znaczne szkody, dlatego firmy próbują zabezpieczać poufność za pomocą rozbudowanych klauzul i wysokich kar umownych.

Z perspektywy software house’u lub klienta kara umowna ma przede wszystkim uprościć dochodzenie roszczeń. Wykazanie dokładnej wysokości szkody powstałej na skutek ujawnienia kodu, dokumentacji albo planu produktu bywa bardzo trudne. Firma może wiedzieć, że jej interes został naruszony, ale nie być w stanie precyzyjnie udowodnić, ilu klientów utraciła, jak spadła wartość produktu albo ile rzeczywiście kosztowało przejęcie przewagi konkurencyjnej.

Z perspektywy programisty kara umowna może jednak stanowić poważne zagrożenie. Dokumenty przygotowywane przez duże organizacje niekiedy przewidują kary wynoszące kilkaset tysięcy złotych za każde naruszenie, bez rozróżnienia pomiędzy celowym ujawnieniem kodu konkurentowi a przypadkowym przesłaniem niewłaściwego załącznika. Zdarza się również, że kara jest naliczana odrębnie za każde użycie, każdy plik, każdą osobę, która otrzymała wiadomość, oraz każdy dzień utrzymywania naruszenia.

Sama wysokość kary nie jest jedynym problemem. Ryzyko może wynikać z bardzo szerokiej definicji informacji poufnych, braku wyjątków, nieograniczonego czasu obowiązywania NDA, odpowiedzialności za osoby trzecie, możliwości kumulowania kilku kar i zastrzeżenia odszkodowania przekraczającego ich wysokość.

Przed podpisaniem NDA programista powinien zatem przeanalizować nie tylko kwotę wpisaną przy karze umownej, lecz cały mechanizm odpowiedzialności. Firma powinna natomiast zadbać, aby postanowienia były możliwe do zastosowania i odpowiadały rzeczywistemu ryzyku. Kara przesadnie wysoka, niejasna lub obejmująca każde techniczne uchybienie może zostać zakwestionowana albo zmniejszona przez sąd. Jednocześnie zbyt niska kara może nie spełnić funkcji ochronnej i w praktyce ograniczyć wysokość rekompensaty, jeżeli umowa nie przewiduje prawa dochodzenia odszkodowania uzupełniającego.

Czym jest NDA?

NDA, czyli non-disclosure agreement, jest umową albo częścią innego kontraktu, której celem jest ochrona informacji poufnych. W polskim prawie nie istnieje jeden odrębny typ umowy nazwany NDA. Strony kształtują jej treść zgodnie z zasadą swobody umów, z uwzględnieniem przepisów bezwzględnie obowiązujących, właściwości stosunku prawnego oraz zasad współżycia społecznego.

Obowiązek poufności może znajdować się w samodzielnej umowie podpisywanej jeszcze przed rozpoczęciem negocjacji. Może również stanowić rozdział kontraktu B2B, umowy o pracę, umowy zlecenia, umowy wdrożeniowej albo umowy o świadczenie usług programistycznych.

Samodzielne NDA jest szczególnie przydatne, gdy firma zamierza dopiero przedstawić kandydatowi albo potencjalnemu wykonawcy informacje o projekcie, ale nie zdecydowała jeszcze o zawarciu głównego kontraktu.

W branży IT obowiązek poufności może obejmować zarówno informacje przekazane programiście przez firmę, jak i dane klientów końcowych, partnerów technologicznych lub innych podmiotów uczestniczących w projekcie.

NDA nie powinno być jednak traktowane jako uniwersalny dokument rozwiązujący wszystkie problemy związane z ochroną informacji. Odrębnego uregulowania mogą wymagać dane osobowe, prawa autorskie, dostęp do infrastruktury, zakaz konkurencji, bezpieczeństwo systemów, zwrot sprzętu oraz zasady usuwania informacji po zakończeniu współpracy.

Tajemnica przedsiębiorstwa a informacja poufna

Pojęcia informacji poufnej i tajemnicy przedsiębiorstwa nie są tożsame. Informacją poufną może być każda informacja, którą strony objęły umownym obowiązkiem zachowania poufności, o ile takie zastrzeżenie jest zgodne z prawem. Zakres umownej ochrony może więc być szerszy niż ustawowa tajemnica przedsiębiorstwa. Tajemnica przedsiębiorstwa posiada natomiast określoną definicję wynikającą z ustawy o zwalczaniu nieuczciwej konkurencji. Obejmuje informacje techniczne, technologiczne, organizacyjne przedsiębiorstwa lub inne informacje posiadające wartość gospodarczą, które jako całość albo w szczególnym zestawieniu nie są powszechnie znane lub łatwo dostępne dla osób zwykle zajmujących się takim rodzajem informacji, o ile uprawniony podjął przy zachowaniu należytej staranności działania w celu utrzymania ich w poufności.

W projekcie informatycznym tajemnicą przedsiębiorstwa mogą być między innymi niepubliczny kod źródłowy, architektura systemu, dokumentacja bezpieczeństwa, algorytmy, baza klientów, polityka cenowa, wyniki testów, plan rozwoju produktu, analiza podatności albo szczegóły negocjowanego kontraktu.

Nie każda informacja przekazana programiście automatycznie staje się tajemnicą przedsiębiorstwa. Informacja powszechnie dostępna, łatwa do odtworzenia albo nieposiadająca wartości gospodarczej może nie spełniać ustawowych warunków.

Firma powinna również wykazać, że podejmowała działania w celu zachowania poufności. Samo późniejsze stwierdzenie, że określone dane były tajne, może okazać się niewystarczające, jeżeli informacje były dostępne dla wszystkich pracowników, przechowywane w publicznym repozytorium albo udostępniane bez jakichkolwiek ograniczeń.

NDA może stanowić jeden z dowodów podjęcia działań ochronnych, ale nie zastąpi właściwej organizacji bezpieczeństwa. Firma powinna ograniczać dostęp zgodnie z zasadą wiedzy koniecznej, stosować odpowiednie uprawnienia, oznaczać dokumenty, zabezpieczać repozytoria i odbierać dostęp po zakończeniu współpracy.

Co powinno być informacją poufną?

Jednym z podstawowych błędów w NDA jest uznanie za poufne wszystkich informacji dotyczących firmy, bez względu na ich źródło, charakter, wartość i sposób ujawnienia.

Taka definicja może wyglądać korzystnie dla przedsiębiorstwa, ale w praktyce powoduje problemy interpretacyjne. Programista może nie być w stanie ustalić, czy poufna jest nazwa używanej technologii, informacja o samym fakcie współpracy, publiczna oferta firmy albo wiedza zdobyta przez niego wcześniej.

Definicja powinna być szeroka na tyle, aby obejmować istotne informacje, ale jednocześnie możliwa do zrozumienia i stosowania. W NDA warto wskazać typowe kategorie danych, takie jak kod źródłowy, kod wynikowy, dokumentacja, dane dostępowe, konfiguracja infrastruktury, informacje o zabezpieczeniach, modele danych, plany produktowe, niepubliczne ceny, dane klientów oraz informacje przekazane przez partnerów. Nie oznacza to konieczności tworzenia zamkniętej listy. Umowa może wskazywać przykłady i obejmować również inne informacje posiadające poufny charakter.

Znaczenie ma sposób oznaczania. Firma może uznać za poufne wszystkie informacje oznaczone odpowiednią klauzulą, a także dane, których poufny charakter powinien być oczywisty ze względu na okoliczności.

Należy jednak unikać konstrukcji, zgodnie z którą absolutnie każda informacja przekazana ustnie, pisemnie, elektronicznie i w jakiejkolwiek innej formie jest objęta bezterminową tajemnicą, niezależnie od tego, czy odbiorca mógł rozpoznać jej charakter.

Jakie wyjątki powinny znaleźć się w NDA?

Prawidłowa umowa powinna wyłączać z ochrony informacje, które nie wymagają albo nie mogą podlegać poufności.

Najczęściej wyłącza się informacje publicznie dostępne, o ile nie stały się publiczne na skutek naruszenia umowy przez programistę. Poza zakresem poufności powinny znajdować się również informacje posiadane przez odbiorcę przed ich przekazaniem, otrzymane zgodnie z prawem od osoby trzeciej oraz opracowane samodzielnie bez wykorzystania informacji drugiej strony.

Warto uregulować ujawnienia wymagane przez prawo, sąd, organ administracji, organ podatkowy albo inny uprawniony podmiot. Programista nie powinien ponosić kary za wykonanie prawnego obowiązku.

Umowa może wymagać, aby w miarę prawnej i faktycznej możliwości wcześniej poinformował firmę o żądaniu ujawnienia i ograniczył zakres przekazywanych informacji do minimum.

NDA nie powinno także uniemożliwiać zgodnego z prawem zgłaszania naruszeń. Ustawa o zwalczaniu nieuczciwej konkurencji przewiduje sytuacje, w których ujawnienie informacji stanowiącej tajemnicę przedsiębiorstwa nie jest bezprawne, w szczególności gdy następuje dla ochrony interesu publicznego w celu ujawnienia nieprawidłowości lub działania z naruszeniem prawa. (ELI⁠)

Kara umowna nie powinna służyć do zastraszania sygnalistów, blokowania zawiadomień o przestępstwach albo uniemożliwiania współpracy z właściwymi organami.

Jak długo powinien obowiązywać obowiązek poufności?

NDA często przewiduje obowiązek poufności w czasie współpracy oraz przez kilka lat po jej zakończeniu. Spotyka się okresy dwuletnie, trzyletnie, pięcioletnie, dziesięcioletnie, a także zobowiązania bezterminowe.

Nie istnieje jeden właściwy okres dla każdej informacji.

Kod źródłowy niepublicznego systemu, klucze kryptograficzne i dane bezpieczeństwa mogą wymagać ochrony tak długo, jak zachowują poufny charakter. Informacja o planowanej kampanii marketingowej może natomiast utracić wartość po jej publicznym uruchomieniu.

Bezterminowy obowiązek nie musi być automatycznie nieważny. Powinien jednak odpowiadać charakterowi chronionych informacji i nie prowadzić do niemożliwego do wykonania obowiązku pamiętania przez całe życie o każdej informacji poznanej podczas projektu.

Rozsądnym rozwiązaniem może być ustalenie ogólnego okresu ochrony oraz odrębne wskazanie, że informacje stanowiące tajemnicę przedsiębiorstwa pozostają chronione tak długo, jak spełniają ustawowe warunki.

Kara umowna również powinna być powiązana z okresem obowiązywania NDA. Programista nie powinien pozostawać narażony na nieograniczoną odpowiedzialność za informacje, które dawno straciły poufny charakter.

Czym jest kara umowna?

Kara umowna jest zastrzeżoną w umowie kwotą albo sposobem ustalenia kwoty należnej w przypadku niewykonania lub nienależytego wykonania zobowiązania niepieniężnego.

Obowiązek zachowania poufności jest zobowiązaniem niepieniężnym, dlatego może zostać zabezpieczony karą umowną.

Kodeks cywilny pozwala stronom zastrzec, że naprawienie szkody wynikającej z niewykonania lub nienależytego wykonania zobowiązania niepieniężnego nastąpi przez zapłatę określonej sumy. Bez zgody wierzyciela dłużnik nie może uwolnić się od zobowiązania przez zapłatę kary.

Kara nie oznacza zatem, że programista może zapłacić wskazaną kwotę i legalnie ujawnić informacje. Podstawowym obowiązkiem nadal pozostaje zachowanie poufności.

Zastrzeżenie kary ma ułatwić firmie uzyskanie rekompensaty. Co do zasady nie musi ona wykazywać dokładnej wysokości szkody w takim zakresie, jak przy zwykłym roszczeniu odszkodowawczym.

Nie oznacza to jednak, że każda kara zostanie automatycznie zasądzona. Firma musi wykazać istnienie ważnego zobowiązania, jego naruszenie, podstawę odpowiedzialności kontraktowej oraz sposób obliczenia kary.

Czy firma musi wykazać szkodę?

Kara umowna jest należna w zastrzeżonej wysokości niezależnie od wysokości poniesionej szkody. Jest to jedna z jej najważniejszych funkcji. Firma nie musi udowadniać, że utraciła dokładnie kwotę odpowiadającą karze.

Brak obowiązku wykazania wysokości szkody nie oznacza jednak, że okoliczności dotyczące szkody są całkowicie pozbawione znaczenia. Mogą wpływać na ocenę, czy kara jest rażąco wygórowana i czy powinna zostać zmniejszona.

Jeżeli programista nieumyślnie przesłał niewłaściwy plik jednej uprawnionej osobie, a pomyłka została natychmiast naprawiona i nie wywołała żadnych konsekwencji, kara w wysokości miliona złotych może zostać oceniona inaczej niż przy celowym przekazaniu repozytorium konkurentowi.

W sporze istotne będzie również to, czy informacje rzeczywiście były poufne, czy odbiorca uzyskał do nich dostęp, czy naruszenie zostało usunięte oraz jaki był stopień winy programisty.

Kara za każde naruszenie

Największe ryzyko dla programisty często wynika nie z samej wysokości pojedynczej kary, lecz ze sposobu definiowania liczby naruszeń.

Umowa może przewidywać karę w wysokości 50 000 zł za każde naruszenie obowiązku poufności. Powstaje wówczas pytanie, czy wysłanie jednej wiadomości z dziesięcioma plikami jest jednym naruszeniem, dziesięcioma naruszeniami, czy może jedenastoma, jeżeli wiadomość trafiła do kilku odbiorców.

Jeszcze większe ryzyko występuje, gdy za odrębne naruszenie uznaje się każde ujawnienie, każde wykorzystanie, każdy dokument, każdego odbiorcę i każdy rozpoczęty dzień.

Firma może próbować naliczyć wiele kar z jednego zdarzenia, a łączna kwota może stać się wielokrotnie wyższa niż wynagrodzenie programisty za cały okres współpracy.

NDA powinno precyzyjnie określać jednostkę naruszenia. Można powiązać karę z jednym zdarzeniem, jednym ciągiem powiązanych zdarzeń, jedną kategorią ujawnionych informacji albo jednym odbiorcą.

Z perspektywy firmy zbyt ogólna klauzula również może być niekorzystna. Niejasność utrudni dochodzenie kary i otworzy spór o sposób jej naliczenia.

Kara za każdy dzień naruszenia

Kara naliczana za każdy dzień jest często stosowana przy naruszeniach o charakterze ciągłym, przykładowo przy braku usunięcia danych, nieoddaniu nośnika, utrzymywaniu poufnych plików w publicznym repozytorium albo niewykonaniu żądania zaprzestania publikacji.

Nie powinna być jednak automatycznie stosowana do każdego ujawnienia informacji.

Jeżeli programista jednorazowo wysłał wiadomość, samo zdarzenie miało charakter punktowy. Skutki mogą trwać dłużej, ale nie zawsze oznacza to, że każdego kolejnego dnia dochodzi do nowego naruszenia obowiązku.

Umowa powinna rozróżniać jednorazowe ujawnienie od trwającego stanu naruszenia. Kara dzienna może być uzasadniona od chwili, gdy programista otrzymał wezwanie do usunięcia informacji, a mimo to pozostawia je publicznie dostępne.

Warto także wprowadzić maksymalny limit kary dziennej. Brak górnej granicy może prowadzić do powstania zobowiązania rosnącego przez miesiące albo lata.

Jedna kara czy kilka kar?

NDA może przewidywać osobne kary za ujawnienie informacji, wykorzystanie ich we własnym interesie, brak zwrotu dokumentów, brak usunięcia danych, przekazanie informacji podwykonawcy oraz naruszenie zasad bezpieczeństwa.

Taka konstrukcja może być uzasadniona, jeżeli poszczególne obowiązki chronią różne interesy.

Problem pojawia się, gdy jedno zachowanie spełnia jednocześnie przesłanki kilku kar. Przykładowo programista kopiuje kod na prywatny dysk, następnie wykorzystuje fragment w innym projekcie i nie usuwa go po zakończeniu umowy.

Umowa powinna wyjaśniać, czy kary mogą być kumulowane. Brak jasnej regulacji może prowadzić do sporu, czy firma może naliczyć trzy niezależne kary.

Programista powinien szczególnie uważać na postanowienia pozwalające firmie według własnego uznania kwalifikować jedno zdarzenie jako nieograniczoną liczbę naruszeń.

Miarkowanie kary umownej

Kodeks cywilny pozwala dłużnikowi żądać zmniejszenia kary umownej, jeżeli zobowiązanie zostało w znacznej części wykonane albo kara jest rażąco wygórowana.

W NDA najważniejszą podstawą jest zazwyczaj rażące wygórowanie.

Nie istnieje prosty wzór pozwalający automatycznie ustalić, że kara przekraczająca określoną liczbę miesięcznych wynagrodzeń jest nieważna albo zawsze podlega redukcji. Sąd ocenia okoliczności konkretnej sprawy.

Znaczenie może mieć wartość chronionych informacji, rozmiar potencjalnej szkody, charakter naruszenia, stopień winy, wysokość wynagrodzenia, możliwość negocjowania umowy, działania podjęte po naruszeniu oraz relacja pomiędzy karą i interesem wierzyciela.

Miarkowanie nie następuje automatycznie. Programista powinien zgłosić odpowiedni zarzut i przedstawić argumenty przemawiające za redukcją.

Nie należy zatem podpisywać dowolnie wysokiej kary z założeniem, że sąd i tak ją obniży. Postępowanie może być kosztowne i długotrwałe, a do czasu rozstrzygnięcia firma może próbować potrącić karę z należnego wynagrodzenia lub dochodzić zabezpieczenia.

Czy rażąco wysoka kara jest nieważna?

Rażąco wygórowana kara nie staje się automatycznie nieważna w całości. Podstawowym mechanizmem jest jej miarkowanie, czyli zmniejszenie przez sąd.

Nieważność może pojawić się z innych przyczyn, przykładowo gdy postanowienie jest sprzeczne z ustawą, zasadami współżycia społecznego albo właściwością stosunku prawnego.

W praktyce bezpieczniej jest jednak zakładać, że podpisana kara może zostać dochodzona, a jej ewentualne zmniejszenie będzie wymagało obrony w sporze.

Programista powinien negocjować wysokość przed zawarciem umowy, a nie opierać bezpieczeństwa na przyszłej decyzji sądu.

Firma również nie powinna traktować ekstremalnej kwoty jako najlepszego zabezpieczenia. Kara całkowicie oderwana od wartości kontraktu i ryzyka może być łatwiejsza do podważenia niż racjonalna, odpowiednio skonstruowana sankcja.

Jaka wysokość kary jest rozsądna?

Nie istnieje ustawowa tabela kar za naruszenie NDA.

Wysokość powinna być ustalana z uwzględnieniem wartości informacji, możliwych skutków naruszenia, zakresu dostępu programisty, wartości kontraktu i jego sytuacji ekonomicznej.

Inna kara będzie odpowiednia dla junior developera, który otrzymuje dostęp jedynie do niewielkiej części projektu, a inna dla architekta mającego pełny dostęp do kodu, baz danych i informacji o bezpieczeństwie kluczowego systemu bankowego.

W umowach B2B spotyka się kwoty od kilku do kilkuset tysięcy złotych. Sam fakt, że kara przewyższa miesięczne wynagrodzenie, nie przesądza o jej nieprawidłowości. Informacja może mieć znacznie większą wartość niż wynagrodzenie za usługę.

Rozsądnym rozwiązaniem jest często zróżnicowanie kar. Celowe ujawnienie kodu konkurentowi może być objęte wyższą karą niż niezgłoszenie zagubienia nośnika albo opóźnienie w usunięciu plików.

Można również wprowadzić łączny limit odpowiedzialności z tytułu kar, z wyjątkiem działania umyślnego, oszustwa albo świadomego ujawnienia szczególnie chronionych danych.

Kara umowna a odszkodowanie uzupełniające

Kodeks cywilny stanowi, że żądanie odszkodowania przekraczającego wysokość zastrzeżonej kary nie jest dopuszczalne, chyba że strony postanowiły inaczej.

Oznacza to, że jeżeli NDA przewiduje karę 20 000 zł i nie zawiera prawa do odszkodowania uzupełniającego, firma może mieć problem z dochodzeniem wyższej kwoty za to samo naruszenie, nawet jeżeli rzeczywista szkoda wyniosła milion złotych.

Z perspektywy firmy ważne jest więc postanowienie pozwalające dochodzić odszkodowania ponad karę na zasadach ogólnych.

Z perspektywy programisty taka klauzula istotnie zwiększa ryzyko. Kara przestaje być maksymalnym kosztem naruszenia i staje się jedynie kwotą minimalną, do której może zostać dodane odszkodowanie.

Programista powinien sprawdzić, czy odszkodowanie uzupełniające dotyczy wszystkich naruszeń, czy tylko działania umyślnego albo szczególnie poważnych przypadków.

Dobrym kompromisem może być prawo do odszkodowania ponad karę wyłącznie w razie wykazania szkody wynikającej z winy umyślnej, rażącego niedbalstwa albo ujawnienia określonych kategorii informacji.

Potrącenie kary z wynagrodzenia

NDA lub główny kontrakt często pozwala firmie potrącić naliczoną karę z faktur programisty.

Z punktu widzenia firmy jest to skuteczny mechanizm zabezpieczenia. Z punktu widzenia wykonawcy oznacza jednak ryzyko natychmiastowej utraty wynagrodzenia jeszcze przed rozstrzygnięciem, czy rzeczywiście doszło do naruszenia.

Samo jednostronne wystawienie noty obciążeniowej nie oznacza automatycznie, że roszczenie istnieje. Potrącenie wymaga spełnienia przesłanek określonych w przepisach.

Umowa może jednak dodatkowo regulować sposób rozliczenia. Programista powinien uważać na postanowienia pozwalające firmie wstrzymać wszystkie płatności na podstawie samego podejrzenia naruszenia.

Bezpieczniejszym rozwiązaniem może być ograniczenie potrącenia do kar bezspornych, prawomocnie zasądzonych albo uznanych przez wykonawcę, choć duże firmy często nie akceptują takiego ograniczenia.

Odpowiedzialność niezależna od winy

W odpowiedzialności kontraktowej znaczenie ma to, czy naruszenie wynika z okoliczności, za które dłużnik ponosi odpowiedzialność. Strony mogą jednak rozszerzyć odpowiedzialność i objąć nią również określone zdarzenia niezależne od winy.

W NDA spotyka się postanowienia, zgodnie z którymi programista odpowiada za każde ujawnienie informacji, bez względu na przyczynę.

Może to oznaczać odpowiedzialność również wtedy, gdy do incydentu doszło na skutek zaawansowanego ataku, błędu dostawcy chmury, kradzieży prawidłowo zabezpieczonego urządzenia albo nieprawidłowości po stronie firmy.

Programista powinien sprawdzić, czy kara jest należna za samo wystąpienie zdarzenia, czy za naruszenie obowiązków, za które ponosi odpowiedzialność.

Firma może wymagać wysokiego standardu bezpieczeństwa, ale nie powinna automatycznie przerzucać na pojedynczego wykonawcę wszystkich ryzyk związanych z infrastrukturą, nad którą nie posiada on kontroli.

Odpowiedzialność za pracowników, podwykonawców i domowników

Programista prowadzący działalność gospodarczą może korzystać z podwykonawców albo pracowników. NDA często przewiduje jego pełną odpowiedzialność za wszystkie osoby, którym udostępni informacje.

Taka konstrukcja jest co do zasady zrozumiała. Firma zawiera umowę z głównym wykonawcą i nie chce dochodzić roszczeń od nieznanego podwykonawcy.

Programista powinien jednak uzyskać prawo legalnego udostępniania informacji osobom uczestniczącym w realizacji projektu. Powinien także zawrzeć z nimi odpowiednie zobowiązania do poufności.

Należy uważać na odpowiedzialność za osoby, którym programista nie przekazał danych i nad którymi nie sprawuje kontroli. Klauzula przewidująca karę za każde działanie domownika, osoby korzystającej z tej samej sieci albo byłego współpracownika może być nadmiernie szeroka.

W praktyce ważne są również zabezpieczenia organizacyjne. Praca przy poufnym kodzie na współdzielonym komputerze, pozostawianie dokumentów w ogólnodostępnym miejscu albo umożliwienie rodzinie korzystania z tego samego konta może stanowić naruszenie niezależnie od tego, czy doszło do celowego ujawnienia.

NDA w umowie o pracę

Sytuacja pracownika różni się od pozycji przedsiębiorcy B2B.

Pracownik ma obowiązek dbać o dobro zakładu pracy i zachowywać w tajemnicy informacje, których ujawnienie mogłoby narazić pracodawcę na szkodę. Może być także zobowiązany do ochrony tajemnicy przedsiębiorstwa na podstawie odrębnych przepisów.

Kary umowne w stosunku pracy wymagają jednak szczególnej ostrożności. Prawo pracy ogranicza możliwość kształtowania odpowiedzialności pracownika w sposób mniej korzystny niż wynikający z przepisów.

Nie należy automatycznie przenosić wzoru NDA przeznaczonego dla przedsiębiorcy do umowy z pracownikiem. Kara umowna za naruszenie obowiązków pracowniczych może zostać zakwestionowana ze względu na szczególny system odpowiedzialności materialnej pracowników.

Inaczej może być w odniesieniu do obowiązków obowiązujących po ustaniu zatrudnienia, ale również wtedy konieczna jest ostrożna analiza.

Firma zatrudniająca programistów na podstawie umów o pracę powinna oprzeć ochronę przede wszystkim na prawidłowym określeniu obowiązków, procedurach bezpieczeństwa, ustawowej odpowiedzialności i ochronie tajemnicy przedsiębiorstwa, zamiast mechanicznie stosować bardzo wysokie kary.

NDA w kontrakcie B2B

W relacji pomiędzy przedsiębiorcami strony posiadają znacznie większą swobodę ustalania odpowiedzialności.

Programista prowadzący JDG jest traktowany jako profesjonalny uczestnik obrotu. Sam fakt, że jest ekonomicznie słabszy od dużego klienta, nie powoduje automatycznego wyłączenia wynegocjowanych postanowień.

Dlatego kontrakt B2B może przewidywać wysokie kary, prawo do odszkodowania uzupełniającego, odpowiedzialność za podwykonawców i szerokie obowiązki bezpieczeństwa.

Programista powinien szczególnie uważać, jeżeli jego działalność jest jednoosobowa, nie posiada ubezpieczenia i odpowiada całym majątkiem.

Kara w wysokości 500 000 zł może prowadzić do wieloletniego sporu i realnego zagrożenia dla majątku prywatnego.

Przy wysokim ryzyku warto przeanalizować ubezpieczenie odpowiedzialności cywilnej zawodowej lub cyber. Należy jednak sprawdzić, czy polisa obejmuje kary umowne. Wiele ubezpieczeń wyłącza je albo pokrywa tylko w ograniczonym zakresie.

Informacje poufne klienta końcowego

Programista współpracujący z software house’em często otrzymuje informacje należące do klienta końcowego.

Kontrakt może wymagać przestrzegania NDA zawartego pomiędzy software house’em i jego klientem, mimo że programista nie zna jego pełnej treści. Takie rozwiązanie jest ryzykowne. Wykonawca nie powinien przyjmować odpowiedzialności za obowiązki wynikające z dokumentu, którego nie otrzymał. Jeżeli firma chce przenieść określone wymagania, powinna je przekazać albo zawrzeć w umowie programisty. Szczególnego znaczenia nabierają kary przewidziane w kontrakcie głównym. Software house może próbować obciążyć programistę każdą karą naliczoną przez klienta końcowego.

Programista powinien ustalić, czy odpowiada za pełną kwotę niezależnie od jej wysokości i zasadności, czy tylko za szkodę pozostającą w związku z jego zawinionym naruszeniem.

Nie powinien automatycznie odpowiadać za postanowienia, których nie mógł negocjować i które przewidują odpowiedzialność wielokrotnie przekraczającą wartość jego kontraktu.

NDA a zakaz konkurencji

Umowy o poufności bywają wykorzystywane jako ukryty zakaz konkurencji.

Klauzula może zabraniać programiście wykorzystywania jakiejkolwiek wiedzy zdobytej podczas współpracy, świadczenia usług dla podmiotów działających w podobnej branży albo tworzenia produktów posiadających zbliżone funkcje.

Nie każda wiedza zdobyta podczas projektu jest informacją poufną. Programista zachowuje ogólne umiejętności, doświadczenie, znajomość języka, frameworka, wzorców projektowych i metod pracy.

NDA nie powinno prowadzić do faktycznego zakazu wykonywania zawodu.

Jeżeli firma chce ograniczyć współpracę z konkurentami, powinna zastosować odrębny, precyzyjny zakaz konkurencji, określający zakres działalności, terytorium, okres i konsekwencje naruszenia.

Kara za naruszenie poufności nie powinna być naliczana tylko dlatego, że programista po zakończeniu kontraktu pracuje dla firmy z tej samej branży, jeżeli nie wykorzystuje chronionych informacji.

NDA a prawa autorskie

Poufność nie jest tym samym co własność intelektualna.

NDA może zakazywać ujawniania kodu, ale nie przenosi automatycznie praw autorskich. Kontrakt powinien odrębnie regulować, kto nabywa prawa do oprogramowania, dokumentacji, grafik, baz danych i innych rezultatów.

Firma może uznać każde wykorzystanie kodu w innym projekcie zarówno za naruszenie praw autorskich, jak i za naruszenie poufności.

W takim przypadku może próbować dochodzić kilku roszczeń na różnych podstawach. Umowa powinna wyjaśniać, czy kary mogą być kumulowane z odpowiedzialnością za naruszenie praw autorskich.

Programista powinien zwrócić uwagę na kod i komponenty stworzone przez niego przed rozpoczęciem współpracy. Jeżeli wykorzystuje własne biblioteki, narzędzia lub szablony, powinien wyłączyć je z zakresu informacji należących do klienta albo odpowiednio opisać zasady korzystania.

Kopie zapasowe i usunięcie danych

NDA często zobowiązuje programistę do natychmiastowego usunięcia wszystkich informacji po zakończeniu współpracy.

Wykonanie takiego obowiązku może być trudne ze względu na kopie zapasowe, historię poczty, automatyczne synchronizacje, cache, logi i kopie wykonywane przez system operacyjny. Umowa powinna rozróżniać aktywne dane od kopii technicznych, których selektywne usunięcie jest niemożliwe albo niewspółmiernie trudne. Kopie mogą pozostać do czasu ich nadpisania w zwykłym cyklu, pod warunkiem że nie są aktywnie wykorzystywane i pozostają objęte poufnością.

Programista powinien również zachować możliwość przechowywania dokumentów niezbędnych do rozliczeń, obrony roszczeń albo wykonania obowiązków prawnych.

Kara za nieusunięcie każdej technicznej kopii w ciągu 24 godzin może być niewykonalna.

Dowody naruszenia NDA

Firma dochodząca kary powinna wykazać, że doszło do konkretnego naruszenia.

Dowodami mogą być wiadomości e-mail, logi dostępu, historia repozytorium, kopie plików, dane z systemu DLP, zeznania świadków, wyniki audytu oraz materiały opublikowane przez konkurenta.

Samo podejrzenie, że programista posiadał dostęp i konkurent później stworzył podobną funkcję, może być niewystarczające. NDA nie powinno przyznawać firmie całkowicie swobodnego prawa uznania, że doszło do naruszenia, bez możliwości zakwestionowania tej oceny. Programista powinien uważać na domniemania umowne, zgodnie z którymi każde podobieństwo produktu albo każdy transfer pliku oznacza ujawnienie poufnych informacji.

Z drugiej strony wykonawca powinien pamiętać, że logi i historia systemów mogą dokładnie pokazywać pobieranie danych, kopiowanie repozytorium oraz logowanie po zakończeniu współpracy.

Procedura reagowania na naruszenie

Dobrze przygotowane NDA powinno określać nie tylko kary, lecz również procedurę działania po incydencie.

Programista powinien mieć obowiązek niezwłocznego poinformowania firmy o utracie urządzenia, błędnej wysyłce, uzyskaniu dostępu przez osobę trzecią lub podejrzeniu naruszenia. Szybkie zgłoszenie może pozwolić na zmianę kluczy, cofnięcie dostępu, zdalne usunięcie danych albo kontakt z błędnym odbiorcą. Umowa może uzależniać wysokość odpowiedzialności od tego, czy wykonawca prawidłowo zareagował.

Nie należy tworzyć mechanizmu, w którym zgłoszenie incydentu automatycznie prowadzi do naliczenia kary, niezależnie od przyczyny. Może to zniechęcać do szybkiego informowania.

Z perspektywy bezpieczeństwa korzystniejszy jest system premiujący natychmiastową współpracę i ograniczenie skutków.

Czy kara powinna zależeć od umyślności?

Nie ma obowiązku ograniczania kary wyłącznie do naruszeń umyślnych.

Poufność może zostać naruszona również przez niedbalstwo, przykładowo pozostawienie niezabezpieczonego laptopa albo przesłanie dokumentu niewłaściwej osobie. Całkowite wyłączenie odpowiedzialności za nieumyślne naruszenia byłoby dla firmy ryzykowne. Można jednak zróżnicować wysokość kary. Niższa sankcja może dotyczyć naruszeń nieumyślnych, a wyższa świadomego wykorzystania informacji lub przekazania ich konkurentowi.

Warto również uwzględnić stopień zaniedbania. Drobna pomyłka nie powinna być traktowana identycznie jak rażące lekceważenie podstawowych procedur bezpieczeństwa.

Limit odpowiedzialności

Kontrakty IT często zawierają ogólny limit odpowiedzialności, przykładowo równy wynagrodzeniu zapłaconemu w ciągu ostatnich dwunastu miesięcy.

Należy sprawdzić, czy limit obejmuje również kary za poufność. Umowa może wyłączać z limitu naruszenia NDA, danych osobowych, praw autorskich i bezpieczeństwa. W rezultacie programista może posiadać limit odpowiedzialności za zwykłe błędy kodu, ale nieograniczoną odpowiedzialność za każde naruszenie poufności. Nieograniczona odpowiedzialność może być uzasadniana wysoką wartością informacji. Dla jednoosobowego wykonawcy stanowi jednak bardzo poważne ryzyko.

Rozwiązaniem może być odrębny, podwyższony limit dla poufności, na przykład wielokrotność rocznego wynagrodzenia, z wyłączeniem limitu jedynie dla działania umyślnego.

Roszczenia niezależne od kary

Naruszenie poufności może prowadzić nie tylko do zapłaty kary.

Firma może żądać zaprzestania wykorzystywania informacji, usunięcia plików, zwrotu dokumentów, zniszczenia nośników, wydania korzyści, naprawienia szkody oraz podjęcia działań zmierzających do ograniczenia skutków. Jeżeli informacje stanowią tajemnicę przedsiębiorstwa, mogą mieć zastosowanie roszczenia wynikające z ustawy o zwalczaniu nieuczciwej konkurencji. Bezprawne pozyskanie, wykorzystanie lub ujawnienie tajemnicy przedsiębiorstwa stanowi czyn nieuczciwej konkurencji. Firma może więc posiadać roszczenia ustawowe nawet wtedy, gdy NDA nie przewiduje kary albo kara okaże się nieważna.

Z drugiej strony brak spełnienia ustawowych warunków tajemnicy przedsiębiorstwa nie zawsze wyłącza odpowiedzialność kontraktową za naruszenie szerszego obowiązku poufności.

Przedawnienie roszczenia o karę

Roszczenie o zapłatę kary umownej podlega przedawnieniu. Termin zależy między innymi od charakteru stosunku i tego, kiedy roszczenie stało się wymagalne.

W relacjach związanych z działalnością gospodarczą często będzie miał zastosowanie termin właściwy dla roszczeń gospodarczych, ale konieczna jest analiza konkretnej umowy i zdarzenia. Strony mogą również określić, kiedy kara staje się płatna, przykładowo po doręczeniu wezwania albo noty obciążeniowej. Nie mogą jednak dowolnie zmieniać ustawowych terminów przedawnienia w sposób sprzeczny z przepisami.

Firma powinna reagować szybko po wykryciu naruszenia, zabezpieczyć dowody i wezwać programistę do zaprzestania dalszych działań.

Prawo właściwe i sąd

Programista może otrzymać NDA podlegające prawu obcego państwa i przewidujące rozstrzyganie sporów przed zagranicznym sądem albo arbitrażem.

W takim przypadku polskie zasady dotyczące kary umownej, w tym miarkowania, mogą nie mieć zastosowania wprost. Należy sprawdzić, jak dane prawo traktuje liquidated damages, penalties, indemnification oraz ograniczenia odpowiedzialności. Kara określona w dolarach albo euro może wiązać się również z ryzykiem kursowym. Postępowanie za granicą lub arbitraż może być dla jednoosobowego programisty bardzo kosztowne, nawet gdy jego argumenty merytoryczne są dobre.

Nie należy traktować klauzuli prawa właściwego jako technicznego dodatku. Może ona całkowicie zmienić ocenę ryzyka NDA.

Jak negocjować NDA jako programista?

Programista powinien rozpocząć od ustalenia, jakie informacje rzeczywiście otrzyma i jakie ryzyko wiąże się z projektem.

Następnie należy przeanalizować definicję informacji poufnych, wyjątki, czas obowiązywania, zasady ujawniania podwykonawcom, procedurę zgłaszania incydentów i obowiązek usuwania danych.

Przy karach kluczowe jest ustalenie ich wysokości, jednostki naruszenia, możliwości kumulowania, kary dziennej, limitu łącznego, odpowiedzialności za osoby trzecie oraz prawa do odszkodowania uzupełniającego. Programista może zaproponować zróżnicowanie sankcji według rodzaju naruszenia, wprowadzenie łącznego limitu oraz wyłączenie odpowiedzialności za zdarzenia pozostające poza jego kontrolą. Warto także uzależnić karę od naruszenia zawinionego, przynajmniej w przypadku zdarzeń innych niż świadome ujawnienie.

Jeżeli firma nie zgadza się na obniżenie kwoty, można negocjować ograniczenie zakresu informacji, precyzyjną definicję jednego naruszenia, wyłączenie kumulacji albo rezygnację z odszkodowania ponad karę.

Jak przygotować NDA z perspektywy firmy?

Firma powinna najpierw określić, co rzeczywiście chce chronić.

NDA powinno odpowiadać modelowi dostępu programisty. Osoba otrzymująca dostęp do niewielkiego modułu nie musi przyjmować odpowiedzialności takiej samej jak administrator całej infrastruktury.

Definicja poufności powinna być konkretna, a wyjątki jasne. Firma powinna wskazać wymagane standardy bezpieczeństwa i procedurę zgłaszania incydentów. Kara powinna pozostawać adekwatna do interesu firmy i potencjalnych skutków naruszenia. Warto rozróżniać typy naruszeń i ustalić sposób naliczania.

Jeżeli firma chce zachować prawo do dochodzenia wyższej szkody, musi odpowiednio przewidzieć odszkodowanie uzupełniające. NDA powinno być spójne z głównym kontraktem, polityką bezpieczeństwa, umową powierzenia danych, zasadami korzystania z podwykonawców i postanowieniami o prawach autorskich.

Najważniejsze jest jednak rzeczywiste chronienie informacji. Umowa nie zastąpi kontroli dostępu, szyfrowania, bezpiecznych repozytoriów, szkoleń i procesu odbierania uprawnień.

Najczęstsze błędy w NDA dla programisty

Pierwszym błędem jest objęcie poufnością absolutnie każdej informacji bez wyłączeń. Prowadzi to do niepewności i utrudnia wykazanie naruszenia.

Drugim problemem jest jedna ekstremalnie wysoka kara za każde, nawet najdrobniejsze uchybienie.

Trzecim jest brak określenia, co oznacza jedno naruszenie. Pozwala to próbować naliczać wielokrotne kary za jedno zdarzenie.

Czwartym błędem jest nieograniczona kara dzienna, która może narastać bez końca.

Piątym jest automatyczne przerzucenie na programistę każdej kary naliczonej firmie przez klienta końcowego.

Kolejnym problemem jest jednoczesne przewidzenie kary, nieograniczonego odszkodowania, zwrotu wszystkich korzyści i odpowiedzialności za wszelkie szkody pośrednie bez żadnego limitu.

Błędem jest także traktowanie NDA jako ukrytego zakazu konkurencji i zakazywanie korzystania z ogólnych umiejętności zawodowych.

Z perspektywy firmy częstym błędem jest zastrzeżenie niskiej kary bez prawa do odszkodowania uzupełniającego. W przypadku poważnego ujawnienia kara może wówczas ograniczyć możliwą rekompensatę.

Co zrobić po otrzymaniu wezwania do zapłaty kary?

Programista nie powinien ignorować wezwania ani automatycznie uznawać roszczenia.

Należy ustalić, jakie konkretne zachowanie firma uznaje za naruszenie, jakie informacje zostały ujawnione, komu, kiedy i na jakiej podstawie obliczono kwotę. Trzeba sprawdzić, czy informacje były objęte NDA, czy nie należały do wyjątków oraz czy doszło do zdarzenia, za które programista odpowiada. Należy również zbadać możliwość kumulowania kar, zgodność noty z umową, prawo do potrącenia oraz argumenty za miarkowaniem. Programista powinien zabezpieczyć korespondencję, logi, urządzenia, potwierdzenia usunięcia danych i dowody zgłoszenia incydentu.

Nie powinien usuwać materiałów, które mogą mieć znaczenie dowodowe, chyba że jest to konieczne do przerwania naruszenia. W takim przypadku warto zachować bezpieczne potwierdzenie wykonanych działań.

Co zrobić po stwierdzeniu naruszenia przez programistę?

Firma powinna przede wszystkim ograniczyć skutki. Konieczna może być zmiana haseł, unieważnienie kluczy, zablokowanie kont, usunięcie publicznego repozytorium, zabezpieczenie logów i poinformowanie klienta końcowego.

Następnie należy ustalić zakres informacji, sposób ich ujawnienia, odbiorców i czas trwania. Dopiero po zabezpieczeniu dowodów warto naliczyć karę. Nota powinna wskazywać podstawę umowną, opis naruszenia, sposób ustalenia liczby kar i termin zapłaty.

Automatyczne naliczenie maksymalnej możliwej liczby kar może utrudnić ugodę i zwiększyć ryzyko ich zmniejszenia.

Jeżeli incydent dotyczy danych osobowych, konieczna jest równoległa analiza obowiązków wynikających z RODO. Jeżeli obejmuje tajemnicę przedsiębiorstwa, firma może rozważyć roszczenia ustawowe oraz zabezpieczenie sądowe.

Podsumowanie

NDA jest potrzebnym elementem współpracy z programistą, ale nie powinno sprowadzać się do jednej szerokiej definicji poufności i bardzo wysokiej kary umownej.

Prawidłowa umowa powinna jasno wskazywać, jakie informacje są chronione, jakie wyjątki mają zastosowanie, kto może otrzymać dostęp, jak długo obowiązuje tajemnica i co należy zrobić po zakończeniu projektu.

Kara umowna powinna odpowiadać realnemu ryzyku. Należy określić, czy jest naliczana za jedno zdarzenie, każdy dokument, każdego odbiorcę czy każdy dzień utrzymywania naruszenia. Brak precyzji może prowadzić do wielokrotnego naliczenia sankcji i sporu o jej wysokość.

Programista powinien sprawdzić, czy firma może dochodzić odszkodowania ponad karę, potrącać ją z faktur, przenosić na niego sankcje klienta końcowego oraz wyłączać naruszenia poufności z ogólnego limitu odpowiedzialności.

Firma powinna natomiast pamiętać, że zbyt niska kara bez prawa do odszkodowania uzupełniającego może ograniczyć możliwą rekompensatę, a kara rażąco wygórowana może zostać zmniejszona przez sąd.

Najlepszą ochronę zapewnia połączenie dobrze przygotowanego NDA z rzeczywistymi środkami bezpieczeństwa. Kontrola dostępów, szyfrowanie, ograniczenie uprawnień, procedura zgłaszania incydentów i odbieranie dostępów po zakończeniu współpracy mają często większe znaczenie niż sama wysokość kary.

Programista nie powinien podpisywać NDA bez analizy całego mechanizmu odpowiedzialności. Firma nie powinna natomiast zakładać, że maksymalnie surowa klauzula zawsze zapewni maksymalną ochronę. Skuteczne NDA powinno być przede wszystkim precyzyjne, proporcjonalne i dostosowane do konkretnego projektu.