NDA dla wykonawcy IT: kompletny przewodnik z darmowym szablonem

Oto scenariusz, który powtarza się bez przerwy: firma programistyczna zatrudnia wykonawcę do budowy kluczowej funkcjonalności. Dzieli się architekturą API, schematami bazy danych i specyfikacjami danych klientów. Sześć miesięcy później ten sam wykonawca pracuje dla konkurencji — razem z kodem.

NDA dla wykonawcy nie gwarantowałby idealnej ochrony. Ale dałby podstawę prawną do działania, dochodzenia odszkodowania i powstrzymania dalszego ujawnienia. Bez niego liczysz na to, że wykonawca po prostu jest uczciwy.

Ten przewodnik obejmuje wszystko, co firma programistyczna powinna wiedzieć o NDA dla wykonawców: klauzule, które naprawdę mają znaczenie, rodzaje dopasowane do różnych relacji, czerwone flagi, przy których powinieneś się sprzeciwić, oraz jak szybko je podpisywać. Na końcu znajdziesz też darmowy szablon.

Jeśli chcesz szerszego spojrzenia na to, jak rozróżnienia między umową a porozumieniem mają zastosowanie do Twoich relacji z wykonawcami, warto przeczytać to najpierw.

NDA dla wykonawcy (umowa o zachowaniu poufności) to prawnie wiążący kontrakt, który zobowiązuje niezależnego wykonawcę — czy to freelance developera, podwykonawcę, czy firmę programistyczną offshore — do zachowania w tajemnicy Twoich poufnych informacji. Określa, co uznaje się za poufne, jak długo trwa to zobowiązanie i co się dzieje, gdy wykonawca je naruszy.

Dla firm programistycznych poufne informacje to nie tylko plany biznesowe czy dane finansowe. To kod źródłowy, architektura systemu, dane dostępowe do repozytoriów, dane klientów, integracje API, własne algorytmy i nieopublikowane roadmapy produktowe. To szerszy i bardziej techniczny zakres niż ten, który obejmuje ogólny szablon NDA.

NDA dla wykonawcy różni się od umowy o poufności dla pracownika na istotny sposób: pracownicy zazwyczaj podpisują klauzulę poufności zawartą w umowie o pracę, podczas gdy wykonawcy podpisują samodzielne NDA przed rozpoczęciem pracy. Ta samodzielna struktura ma znaczenie. Tworzy odrębne, wyraźnie określone zobowiązanie, które nie jest splątane ze sporami o wynagrodzenie czy prawem pracy.

Krótka odpowiedź na temat wykonalności: dobrze sporządzony NDA dla wykonawcy jest egzekwowalny we wszystkich głównych jurysdykcjach na podstawie zasad prawa umów. W USA tajemnice handlowe są chronione również przez Defend Trade Secrets Act (DTSA) na poziomie federalnym oraz Uniform Trade Secrets Act (UTSA) na poziomie stanowym — co daje Ci dwa niezależne tory prawne, jeśli wykonawca niewłaściwie wykorzysta Twój kod.

Krótka odpowiedź: wykonawcy nie są pracownikami, a ta luka ma znaczenie prawne.

Pracownicy mają szereg domniemanych i ustawowych obowiązków w zakresie poufności, które nie mają automatycznego zastosowania do niezależnych wykonawców. Wykonawca może domyślnie wykorzystywać wiedzę zdobytą podczas współpracy z Tobą na korzyść konkurenta — chyba że wyraźnie umówisz się inaczej. NDA zamyka tę lukę.

Konkretne ryzyka dla firm programistycznych są wyższe niż w większości branż:

• Ujawnienie kodu źródłowego — Wykonawca, który otrzymał dostęp do repozytorium, widzi całą implementację techniczną. Jeśli odejdzie bez NDA, może swobodnie replikować lub sprzedawać tę wiedzę.
• Dostęp do danych klientów — Wielu wykonawców ma kontakt z bazami danych klientów, rekordami CRM lub endpointami API, które ujawniają informacje o klientach. Naruszenie tutaj to nie tylko strata konkurencyjna; to odpowiedzialność wynikająca z GDPR lub CCPA.
• Tajemnice handlowe w architekturze — Projekt systemu, sposób strukturyzacji pipeline'ów danych, własne algorytmy — to tajemnice handlowe tylko wtedy, gdy traktuje się je jako tajne. NDA jest częścią tego traktowania.
• Ryzyko przepływu przez podwykonawców — Jeśli Twój wykonawca zatrudnia własnych podwykonawców (powszechne w outsourcingu offshore), a ci podwykonawcy nie są związani zobowiązaniami poufności, Twoje tajemnice przepływają przez lukę w Twoim frameworku prawnym.

Dla zespołów zarządzających wieloma wykonawcami jednocześnie, administracyjne obciążenie związane z monitorowaniem statusu NDA jest realne. To jeden z powodów, dla których dedykowane narzędzia do zarządzania dokumentami dla firm IT stają się przydatne w skali — musisz wiedzieć, którzy wykonawcy podpisali, kiedy i gdzie znajdują się wykonane umowy.

Uczciwe ostrzeżenie: NDA samo w sobie nie jest kompletną strategią bezpieczeństwa. Nadal potrzebujesz kontroli dostępu, procedur offboardingu i zarządzania uprawnieniami do repozytoriów. NDA jest Twoim prawnym zabezpieczeniem na wypadek, gdy te kontrole techniczne zawiodą lub gdy wykonawca działa w sposób nieuczciwy mimo posiadania dostępu, do którego był upoważniony.

Nie każda współpraca z wykonawcą wymaga tej samej struktury NDA. Wybór niewłaściwego typu marnuje kapitał negocjacyjny i może nawet sugerować, że nie rozumiesz relacji.

NDA jednostronne

To standardowa forma dla większości współprac z wykonawcami. Tylko jedna strona — zazwyczaj firma programistyczna — ujawnia poufne informacje, a tylko wykonawca jest związany poufnością. Zatrudniasz kogoś do zbudowania czegoś. Dzielisz się specyfikacjami, architekturą, kontekstem klienta. Oni nie dzielą się z Tobą niczym własnym.

Użyj NDA jednostronnego, gdy: zatrudniasz freelance developera, angażujesz wykonawcę QA lub współpracujesz z indywidualnym specjalistą przy ograniczonym projekcie.

NDA wzajemne (dwustronne)

Obie strony dzielą się poufnymi informacjami i obie są związane. To odpowiednie, gdy oceniasz firmę outsourcingową, która zaprezentuje Ci swoją własną metodologię, procesy lub IP — i ma uzasadniony interes w ochronie tych informacji.

W praktyce firmy offshore często żądają NDA wzajemnych. To uzasadnione. Upewnij się tylko, że definicje "poufnych informacji" po ich stronie nie są tak szerokie, że normalna komunikacja projektowa staje się ograniczona.

NDA wielostronne

Obejmuje trzy lub więcej stron w jednej umowie — przydatne, gdy projekt obejmuje Twoją firmę, głównego wykonawcę i wyspecjalizowanego podwykonawcę, którzy wszyscy muszą dzielić się informacjami. Jeden dokument zamiast trzech dwustronnych. Trudniejszy do sporządzenia, ale prostszy w zarządzaniu.

Te dwa dokumenty są często mylone, a to zamieszanie powoduje realne problemy. Chronią różne rzeczy i najlepiej działają razem.

NDA dla wykonawcy chroni poufne informacje, którymi dzielisz się z wykonawcą. Określa, czego nie może ujawniać. Nic nie mówi o tym, kto jest właścicielem pracy, którą wykonuje.

Umowa o przeniesienie praw IP działa odwrotnie: określa, kto jest właścicielem rezultatu pracy stworzonego podczas współpracy. W większości jurysdykcji niezależny wykonawca jest właścicielem praw autorskich do napisanego kodu, chyba że istnieje pisemna umowa przenosząca te prawa na Ciebie.

Oto dlaczego to ma znaczenie: jeśli masz NDA, ale nie masz umowy o przeniesienie praw IP, wykonawca nie może ujawniać Twoich tajemnic — ale może być właścicielem kodu, który dla Ciebie napisał. To znacząca luka.

Dla firmy programistycznej zazwyczaj potrzebujesz obu:

1. 1.
   NDA chroni poufne informacje, którymi dzielisz się podczas współpracy
2. 2.
   Umowa o przeniesienie praw IP przenosi własność rezultatu pracy na Ciebie

Niektóre umowy łączą obie w jeden dokument (powszechne w umowach konsultingowych), ale utrzymywanie ich osobno sprawia, że zakres każdego zobowiązania jest jaśniejszy i łatwiejszy do egzekwowania indywidualnie.

Blog Chaindoc ma dedykowany przewodnik o tym, jak stworzyć bezpieczne NDA, który szczegółowo omawia ogólną strukturę NDA — warto przeczytać obok tego przewodnika dla wykonawców.

Klauzula konkurencji ogranicza wykonawcy możliwość pracy dla konkurentów lub zakładania konkurencyjnego biznesu przez określony czas po zakończeniu współpracy. NDA ogranicza to, co może ujawniać, ale nie powstrzymuje go przed pracą dla Twojego konkurenta — tylko przed zabieraniem Twoich tajemnic.

W praktyce: jeśli starszy developer zna całą architekturę techniczną, nawet idealnie egzekwowane NDA nie zapobiega odtworzeniu jej z pamięci dla konkurenta. Klauzula konkurencji adresuje to ryzyko bezpośrednio.

Mimo to klauzule konkurencji dla niezależnych wykonawców są egzekwowalne tylko w niektórych jurysdykcjach, a sądy poddają je kontroli pod kątem rozsądności — konkretnie zakresu (jakie branże lub role są ograniczone), geografii (jaki region) i czasu trwania (jak długo). Kalifornia na przykład w dużej mierze odmawia egzekwowania klauzul konkurencji dla wykonawców. Wiele krajów UE ma podobne ograniczenia.

Dla większości firm programistycznych współpracujących z wykonawcami:

• Zawsze używaj NDA — egzekwowalne prawie wszędzie, niezbędna ochrona
• Używaj klauzuli konkurencji wybiórczo — dla starszych wykonawców z głębokim dostępem do kluczowego IP, w jurysdykcjach, gdzie egzekwowanie jest realistyczne, z wąskim i rozsądnym zakresem
• Nie umieszczaj klauzul konkurencji w NDA — trzymaj je w głównej umowie o usługach lub jako odrębną klauzulę, aby spory dotyczące jednej nie unieważniły drugiej

Ogólne szablony NDA często pomijają specyficzny dla oprogramowania zakres, który sprawia, że te umowy są faktycznie ochronne. To 10 klauzuli, które każdy NDA dla wykonawcy w firmie programistycznej powinien zawierać.

1. Definicja poufnych informacji (specyficzna dla oprogramowania)

Wymień wyraźne kategorie, nie polegaj na ogólnym języku catch-all. Dla firm programistycznych oznacza to: kod źródłowy i skompilowane binaria, architekturę systemu i specyfikacje techniczne, schematy baz danych, klucze API i dane uwierzytelniające, dane klientów i listy klientów, roadmapy produktowe i nieopublikowane funkcje oraz wewnętrzne narzędzia lub własne workflow.

2. Polityka dostępu do repozytorium

Określ, do jakich repozytoriów kodu wykonawca ma dostęp, jaki poziom uprawnień otrzymał (odczyt, zapis, admin) oraz obowiązek niezatrzymywania kopii po zakończeniu współpracy. Ta klauzula jest specyficzna dla oprogramowania i większość ogólnych szablonów jej nie zawiera.

3. Obsługa danych klientów

Jeśli wykonawca będzie mieć dostęp do jakichkolwiek danych klientów — nawet w środowisku testowym lub staging — określ dozwolone zastosowania, zakaz zatrzymywania kopii i obowiązek powiadomienia, jeśli podejrzewa naruszenie danych dotyczących tych informacji.

4. Odniesienie do umowy o przeniesienie praw IP

Zaznacz, że to NDA działa obok odrębnej umowy o przeniesienie praw IP, a zobowiązania wykonawcy w zakresie poufności są niezależne od umowy o przeniesienie praw IP — naruszenie jednego dokumentu nie wpływa na wykonalność drugiego.

5. Zwrot lub zniszczenie materiałów

Po zakończeniu współpracy wykonawca musi zwrócić lub poświadczyć zniszczenie wszystkich kopii poufnych informacji — w tym kodu pobranego lokalnie, dokumentacji przechowywanej w osobistych dyskach chmurowych i danych dostępowych API. Wymagaj pisemnego potwierdzenia.

6. Przepływ zobowiązań na podwykonawców

Jeśli wykonawca korzysta z podwykonawców, ci podwykonawcy muszą być związani równoważnymi zobowiązaniami poufności przed otrzymaniem jakichkolwiek poufnych informacji. Wykonawca pozostaje odpowiedzialny za naruszenia swoich podwykonawców.

7. Okres trwania i przetrwanie

Zobowiązania w zakresie poufności dla tajemnic handlowych (kod źródłowy, kluczowe algorytmy) powinny przetrwać na czas nieokreślony po zakończeniu współpracy. Dla innych poufnych informacji standardem są trzy do pięciu lat. Wyraźnie zaznacz, że NDA przetrwa rozwiązanie głównej umowy o usługi.

8. Wyłączenia z poufności

Standardowe wyłączenia: informacje już publicznie znane, informacje niezależnie opracowane bez odwoływania się do Twoich ujawnień, informacje otrzymane od strony trzeciej bez ograniczeń poufności. Bądź konkretny — zbyt szerokie wyłączenia tworzą luki.

9. Prawo właściwe i jurysdykcja

Wymień właściwą jurysdykcję wyraźnie. Dla transgranicznych współprac z wykonawcami rozważ określenie arbitrażu jako mechanizmu rozwiązywania sporów — jest zazwyczaj szybszy i bardziej przewidywalny przez granicami niż postępowanie sądowe.

10. Środki zaradcze i zabezpieczenie

Wyraźnie zaznacz, że naruszenie spowoduje nieodwracalną szkodę uzasadniającą zabezpieczenie bez konieczności udowadniania konkretnych strat pieniężnych. To standardowe sformułowanie NDA, ale krytyczne — bez niego musiałbyś skwantyfikować straty, zanim sąd zadziała, co jest trudne w przypadku naruszeń IP.

Ten sam szablon NDA nie pasuje jednakowo do każdej relacji z wykonawcą. Oto jak profil ryzyka — a zatem wymagania w zakresie NDA — różni się w zależności od typu wykonawcy.

Freelance Developer

Freelancer pracujący nad pojedynczą funkcjonalnością lub modułem ma ograniczone ryzyko: widzi to, co dotyczy jego zadania, i tyle. Twój NDA może być tu stosunkowo standardowy — jednostronny, z definicją poufnych informacji specyficzną dla oprogramowania i klauzulą dostępu do repozytorium. Proces podpisywania powinien być prosty i szybki: wyślij, podpisz, jedź dalej. Tarcie w tym miejscu traci Ci dobrych wykonawców.

Podwykonawca (przez agencję główną)

To bardziej ryzykowny układ, niż się wydaje. Gdy zatrudniasz agencję, a ona zleca pracę indywidualnym developerom, często nie wiesz, kim są ci developerzy ani do czego mają dostęp. Twój NDA z agencją powinien zawierać klauzulę przepływu zobowiązań na podwykonawców (klauzula 6 powyżej) i wymagać powiadamiania Cię o wszystkich podwykonawcach, którzy będą mieli dostęp do Twoich systemów. Rozważ wymaganie bezpośrednich NDA z kluczowymi podwykonawcami, jeśli będą mieli dostęp do repozytorium.

Firma offshore

To tutaj NDA wymagają najwięcej uwagi. Firma offshore może mieć własne standardowe umowy, które wyglądają kompleksowo, ale są regulowane przez prawo obce z ograniczoną wykonalnością w Twojej jurysdykcji. Kluczowe dodatki dla współprac offshore:

• Klauzula prawa właściwego i jurysdykcji określająca Twoją jurysdykcję dla sporów
• Wyraźne postanowienia o zgodności z GDPR/CCPA, jeśli dotyczą dane klientów
• NDA wzajemne, jeśli firma podzieli się własną metodologią — ale upewnij się, że zakres Twoich poufnych informacji jest co najmniej tak szeroki jak ich
• Międzynarodowy arbitraż (reguły ICC lub AAA) jako sposób rozwiązywania sporów

Dla zespołów zarządzających wykonawcami różnych typów, oprogramowanie do zarządzania umowami dla firm IT może śledzić, który wykonawca ma którą umowę, kiedy została podpisana i kiedy wymaga odnowienia lub przeglądu — zamiast polegać na współdzielonym arkuszu kalkulacyjnym, który nieuchronnie jest nieaktualny.

Najczęstszy błąd, jaki popełniają firmy programistyczne, to nie źle napisany NDA — ale podpisanie go za późno.

NDA musi być na miejscu przed udostępnieniem jakichkolwiek poufnych informacji. To brzmi oczywiście, ale w praktyce jest pomijane podczas pierwszych rozmów, discovery calls i sesji określania zakresu technicznego, w których dzielisz się kontekstem systemowym, aby pomóc wykonawcy zrozumieć projekt.

Oto prawidłowa kolejność podpisywania dla typowej współpracy z wykonawcą:

1. 1.
   NDA — Podpisz pierwsze, przed jakimkolwiek discovery call, w którym omówisz architekturę techniczną, dane klientów lub specyfikę systemu
2. 2.
   Umowa o przeniesienie praw IP — Podpisz przed rozpoczęciem jakiejkolwiek pracy (najlepiej razem z NDA lub bezpośrednio po nim)
3. 3.
   Statement of Work (SOW) — Definiuje zakres, deliverables, harmonogram i płatność; podpisz przed rozpoczęciem pracy. Zobacz nasz przewodnik o umowach SOW, co powinny zawierać.
4. 4.
   Master Services Agreement (MSA) lub umowa o tworzenie oprogramowania — Ramy regulujące trwającą relację

Przydatna zasada: jeśli zamierzasz powiedzieć potencjalnemu wykonawcy coś, czego nie chciałbyś upublicznić, NDA powinno być już podpisane.

Dla wczesnych rozmów, zanim wybierzesz wykonawcę — rozmów eksploracyjnych, procesów RFP — możesz albo dzielić się tylko ogólnym, niepoufnym kontekstem, albo użyć lekkiego NDA wzajemnego, które obie strony szybko podpiszą. Druga opcja jest czystsza.

Dla zespołów, które prowadzą częste cykle onboardingu wykonawców, automatyzacja procesu onboardingu NDA i wykonawców eliminuje błąd w zakresie czasu — system uruchamia wysyłkę NDA, zanim pierwszy dostęp zostanie przyznany.

W większości przypadków to Ty wysyłasz NDA wykonawcom. Ale wykonawcy — zwłaszcza uznane agencje — czasami przedstawiają własne. Oto co powinno Cię zatrzymać.

Zbyt szeroka definicja "poufnych informacji" po ich stronie

Jeśli NDA wykonawcy definiuje ich poufne informacje jako "wszelkie informacje dzielone podczas współpracy" bez sensownych ograniczeń, możesz skończyć ograniczony w dzieleniu się tym, czego się nauczyłeś — własnej architektury, własnego kontekstu klienta — z przyszłymi wykonawcami, którzy wykonują podobną pracę. NDA wzajemne powinno mieć wyraźnie określone i dopasowane definicje po obu stronach.

Nieokreślony okres dla informacji niebędących tajemnicą handlową

Nieokreślony okres poufności dla ogólnych informacji biznesowych (nie konkretnych tajemnic handlowych) jest często niewykonalny i jest czerwoną flagą, że umowa nie została starannie sporządzona. W niektórych jurysdykcjach sądy unieważniają nieokreślone zobowiązania poufności dla zwykłych informacji biznesowych jako nierozsądne ograniczenie handlu. Sprzeciw się i określ konkretny okres.

Jednostronna klauzula arbitrażowa

Jeśli NDA określa arbitraż tylko w jurysdykcji wykonawcy, z wybranymi przez niego arbitrów, to asymetryczny mechanizm egzekwowania. Musiałbyś podróżować, aby egzekwować własne prawa do poufności. Albo ustal neutralną jurysdykcję, albo określ reguły arbitrażu uznanej instytucji (ICC, AAA) bez uprzywilejowanego miejsca.

Brak wyłączenia IP

Niektóre NDA przedstawiane przez wykonawców zawierają język, który można odczytać jako przyznanie wykonawcy pewnych praw do tego, czego dowie się o Twoim IP — szczególnie jeśli "poufne informacje" są zdefiniowane tak szeroko, że obejmują każdą wiedzę, którą zdobędzie. Jeśli NDA nie wyklucza wyraźnie Twojego istniejącego IP z jakichkolwiek ograniczeń w zakresie użytkowania, doprecyzuj to.

Brak klauzuli zwrotu lub zniszczenia

NDA dla wykonawcy bez wyraźnego obowiązku zwrotu lub zniszczenia pozwala wykonawcy zatrzymać kopie Twojego kodu i dokumentacji po zakończeniu współpracy. To nie jest do zaakceptowania. Uczyń to wymogiem.

Stawki nie są hipotetyczne. Te przypadki pokazują, ile kosztuje faktyczne niewłaściwe wykorzystanie tajemnic handlowych.

Cadence Design Systems v. Avanti Corporation (265 mln USD)

Avanti, konkurencyjna firma EDA, została uznana winną wykorzystania kodu źródłowego Cadence — rzekomo przeniesionego przez byłych pracowników Cadence, którzy dołączyli do Avanti. Sprawa zakończyła się wyrokiem przekraczającym 265 milionów dolarów i wyrokami karnymi dla kilku osób. Podstawowy mechanizm to odejście pracownika, ale to samo ryzyko dotyczy wykonawców: wykonawca pracujący dla wielu firm jest wektorem transferu kodu, celowo lub nie.

Lekcja: nawet dobrze zasobone firmy programistyczne z ustalonymi zabezpieczeniami IP stoją przed tym ryzykiem. Umowy o poufności z każdym, kto ma dostęp do kodu własnościowego, są częścią podstawowej higieny IP — nie opcjonalnym dodatkiem.

Waymo v. Uber (245 mln USD)

Waymo, spółka zależna Alphabet zajmująca się samochodami autonomicznymi, pozwała Ubera po tym, jak były inżynier Google rzekomo zabrał poufne pliki techniczne do startupu, który później został przejęty przez Ubera. Ugoda sięgnęła około 245 milionów dolarów w akcjach. Co istotne, inżynier podpisał NDA i umowy IP z Google — co oznaczało, że Waymo miało legitymację prawną do agresywnego prowadzenia sprawy.

Równie ważny jest kontrapunkt: NDA i umowy o przeniesienie praw IP nie zapobiegły naruszeniu. Ale dały Waymo podstawę prawną do działania. Bez nich Waymo nie miałoby egzekwowalnego mechanizmu do osiągnięcia ugody tej wielkości. To właśnie rzeczywista wartość dobrze sporządzonego NDA dla wykonawcy: nie zapobieganie, ale egzekwowalność, gdy zapobieganie zawiedzie.

Oba przypadki dotyczyły tajemnic handlowych znacznie bardziej zaawansowanych niż większość współprac z wykonawcami. Ale wzorzec jest powszechny w branży programistycznej: poufny kod przemieszcza się wraz z ludźmi, którzy go piszą. Twój NDA dla wykonawcy to mechanizm prawny, który sprawia, że to przemieszczenie jest poddawane działaniu.

Szybkie podpisanie NDA ma znaczenie. Uciążliwy proces podpisywania oznacza, że wykonawcy albo go pomijają, albo podpisują za późno — oba to porażki. Oto jak zrobić to prawidłowo i szybko.

Krok 1: Przygotuj dokument NDA

Użyj poniższego szablonu lub własnej dostosowanej wersji. Upewnij się, że wszystkie klauzule specyficzne dla oprogramowania są na miejscu, zanim wyślesz. Dodatek w ostatniej chwili, gdy wykonawca już przeglądnął dokument, niepotrzebnie wydłuża czas.

Krok 2: Wyślij do podpisu elektronicznego

Prześlij NDA na platformę do podpisu elektronicznego, która zapewnia ślad audytowy chroniący przed ingerencją. To nie biurokratyczny kaprys — to dowód. Jeśli kiedykolwiek będziesz musiał egzekwować NDA, potrzebujesz dowodu, że konkretna osoba podpisała konkretny dokument w konkretnym czasie i że dokument nie został później zmodyfikowany.

Chaindoc wykorzystuje weryfikację blockchain do rejestrowania każdego zdarzenia podpisu na niezmiennym rejestrze. W przeciwieństwie do prostego logu audytowego PDF, który znajduje się na serwerach jednej firmy, zapis blockchain nie może być retrospektywnie zmieniony przez żadną ze stron. To ma znaczenie w sporach, gdy adwokat wykonawcy kwestionuje, czy dokument, na który patrzy, to ten, który podpisał jego klient.

Krok 3: Zweryfikuj tożsamość przed podpisem

Podpis od "user at gmail.com" nie dowodzi, że osoba, z którą podpisałeś umowę, faktycznie podpisała. Użyj co najmniej weryfikacji OTP e-mail; dla wysokowartościowych współprac weryfikacja SMS lub dokumentu tożsamości zapewnia silniejszą niezaprzeczalność.

Krok 4: Przechowuj z kontrolą dostępu

Podpisane NDA powinno znajdować się w systemie zarządzania dokumentami z dostępem opartym na rolach — dostępnym dla Twojego zespołu prawnego i kadry kierowniczej, a nie przechowywanym w wspólnym folderze e-mail. Oznacz je nazwą wykonawcy, datami współpracy i referencją projektu, aby było możliwe do odnalezienia pod presją.

Krok 5: Śledź wygaśnięcie i odnowienie

Jeśli Twój NDA ma określony okres, śledź datę wygaśnięcia. NDA, które wygasło sześć miesięcy temu, nie chroni Cię dzisiaj.

Dla firm programistycznych zarządzających obiegiem dokumentów dla zespołów IT, zautomatyzowanie tego procesu — wysyłka NDA po dodaniu wykonawcy, automatyczne przypomnienie przed przyznaniem dostępu, alerty o wygaśnięciu — eliminuje ręczne obciążenie, które powoduje błędy w zakresie czasu. Zobacz cennik Chaindoc dla planów zespołowych obejmujących obieg dokumentów dla wykonawców.

Dla głębszego spojrzenia na stronę zgodności prawnej podpisów elektronicznych, ESIGN Act (USA) i eIDAS (UE) potwierdzają, że elektronicznie podpisane NDA mają tę samą wagę prawną co papier.

Poniższy szablon to punkt wyjścia — jednostronny NDA dla wykonawcy z wbudowanymi klauzulami specyficznymi dla oprogramowania. Obejmuje wszystkie 10 klauzuli wymienionych w tym przewodniku i zawiera domyślne dla jurysdykcji USA (regulowane przez prawo stanu, który określisz, z ochroną tajemnic handlowych DTSA).

Pobierz szablon NDA dla wykonawcy Chaindoc:

• Pobierz PDF
• Pobierz DOCX

Co zawiera szablon:

• Definicja poufnych informacji specyficzna dla oprogramowania (kod źródłowy, architektura, dane dostępowe, dane klientów, roadmapy)
• Klauzula polityki dostępu do repozytorium
• Obowiązek przepływu zobowiązań na podwykonawców
• Klauzula zwrotu lub zniszczenia z wymogiem poświadczenia
• Klauzula odniesienia do umowy o przeniesienie praw IP
• Klauzula zabezpieczenia
• Miejsce na prawo właściwe (wpisz swój stan lub jurysdykcję)
• 3-letni okres dla ogólnych poufnych informacji / nieokreślony dla tajemnic handlowych

Ważna informacja: Ten szablon jest dostarczany w celach informacyjnych i nie stanowi porady prawnej. Wykonalność zależy od jurysdykcji i konkretnych okoliczności. Dla wysokowartościowych współprac, nowych relacji z wykonawcami lub sytuacji transgranicznych, daj umowę do przeglądu przez wykwalifikowanego prawnika przed użyciem.

Dla pełniejszego stosu dokumentów onboardingu wykonawcy — NDA, SOW i warunki płatności — narzędzia do zarządzania umowami dla firm IT Chaindoc pozwalają budować szablony raz i wysyłać je konsekwentnie każdemu nowemu wykonawcy.