NDA для підрядника в IT: повний посібник із безкоштовним шаблоном

Ось типова ситуація: IT-компанія наймає підрядника для розробки критично важливого функціоналу. Ви ділитеся архітектурою API, схемами баз даних і специфікаціями клієнтських даних. Через шість місяців цей підрядник працює для конкурента — і ваш код разом із ним.

NDA для підрядника не гарантує абсолютний захист. Але він дає вам юридичні підстави для дій, відшкодування збитків і зупинки подальшого розголошення. Без нього ви просто сподіваєтеся на чесність підрядника.

Цей посібник охоплює все, що потрібно знати IT-компанії про NDA для підрядників: пункти, які дійсно мають значення, типи угод для різних відносин, червоні прапорці, через які варто настоювати на змінах, і як швидко отримати підпис. Наприкінці — безкоштовний шаблон.

Якщо ви хочете ширше зрозуміти, як відмінності між контрактом та угодою застосовуються до ваших відносин із підрядниками, радимо прочитати це спочатку.

NDA для підрядника (угода про нерозголошення) — це юридично обов'язковий договір, який зобов'язує незалежного підрядника — будь то фрілансер, субпідрядник чи аутсорсингова компанія — зберігати вашу конфіденційну інформацію в таємниці. Він визначає, що вважається конфіденційним, як довго триває зобов'язання і що станеться, якщо підрядник його порушить.

Для IT-компаній конфіденційна інформація — це не лише бізнес-плани чи фінансові дані. Це вихідний код, системна архітектура, облікові дані до репозиторіїв, дані клієнтів, API-інтеграції, пропрієтарні алгоритми та дорожні карти продукту, які ще не вийшли. Це набагато ширший і технічно специфічніший обсяг, ніж охоплює типовий NDA.

NDA для підрядника відрізняється від угоди про конфіденційність працівника важливим чином: працівники зазвичай підписують пункт про конфіденційність у трудовому договорі, тоді як підрядники підписують окремий NDA перед початком роботи. Ця окрема структура має значення. Вона створює чітко окреслене зобов'язання, яке не заплутане в оплаті чи трудовому праві.

Коротка відповідь щодо виконуваності: добре складений NDA для підрядника є виконуваним у всіх основних юрисдикціях на засадах договірного права. У США комерційні таємниці також захищені на федеральному рівні Defend Trade Secrets Act (DTSA) і на рівні штатів — Uniform Trade Secrets Act (UTSA). Це дає вам два незалежних юридичних шляхи, якщо підрядник незаконно використає ваш код.

Коротка відповідь: підрядники — не працівники, і ця різниця має юридичне значення.

Працівники мають кілька імпліцитних і статутних зобов'язань щодо конфіденційності, які автоматично не поширюються на незалежних підрядників. За замовчуванням підрядник може використовувати знання, отримані під час роботи з вами, на користь конкурента — якщо ви явно не домовилися про інше. NDA закриває цю прогалину.

Конкретні ризики для IT-компаній вищі, ніж у більшості галузей:

• Витік вихідного коду — Підряднику, якому надали доступ до репозиторію, видно всю вашу технічну реалізацію. Якщо він іде без NDA, він може вільно відтворити чи продати ці знання.
• Доступ до даних клієнтів — Багато підрядників працюють із базами даних клієнтів, записами CRM або API-ендпоінтами, які розкривають інформацію про клієнтів. Витік тут — це не лише конкурентна втрата, а й відповідальність за GDPR або CCPA.
• Комерційні таємниці в архітектурі — Ваше системне проєктування, структура data pipeline, ваші пропрієтарні алгоритми — це комерційні таємниці лише якщо їх трактують як таємні. NDA є частиною цього трактування.
• Ризик передачі через субпідрядників — Якщо ваш підрядник наймає власних субпідрядників (типово для офшорного аутсорсингу), і ті субпідрядники не пов'язані зобов'язаннями щодо конфіденційності, ваші таємниці витікають через прогалину в юридичній базі.

Для команд, які одночасно керують кількома підрядниками, адміністративне навантаження з відстеження статусу NDA є реальним. Саме тому спеціалізоване управління документами для IT-компаній стає корисним у масштабі — вам потрібно знати, які підрядники підписали, коли і де зберігаються виконані угоди.

Справедливе попередження: NDA сам по собі — не повна стратегія безпеки. Вам також потрібні контроль доступу, процедури офбордингу та управління дозволами репозиторію. NDA — це ваш юридичний запасний варіант, коли технічні заходи контролю дають збій або підрядник діє обманним шляхом попри наявний доступ.

Не кожній співпраці з підрядником потрібна одна й та сама структура NDA. Вибір неправильного типу марнує переговорний капітал і може навіть сигналізувати, що ви не розумієте суті відносин.

Односторонній NDA

Це стандартна форма для більшості співпраць із підрядниками. Лише одна сторона — зазвичай IT-компанія — розкриває конфіденційну інформацію, і лише підрядник зобов'язаний її зберігати в таємниці. Ви наймаєте когось щось зробити. Ви ділитеся своїми специфікаціями, архітектурою, контекстом клієнта. Вони нічого пропрієтарного вам не розкривають.

Використовуйте односторонній NDA, коли: наймаєте фрілансера, залучаєте QA-підрядника або працюєте з індивідуальним спеціалістом для обмеженого проєкту.

Взаємний (двосторонній) NDA

Обидві сторони обмінюються конфіденційною інформацією та обидві зобов'язані її зберігати. Це доречно, коли ви оцінюєте аутсорсингову фірму, яка презентуватиме вам власну пропрієтарну методологію, процеси чи ІВ — і вона має законний інтерес захистити цю інформацію.

На практиці офшорні dev-компанії часто просять взаємні NDA. Це розумно. Просто переконайтеся, що визначення "конфіденційної інформації" з їхнього боку не є настільки широким, що нормальне проєктне спілкування стає обмеженим.

Багатосторонній NDA

Охоплює три чи більше сторін в одній угоді — корисно, коли проєкт передбачає вашу компанію, основного підрядника та спеціалізованого субпідрядника, яким усім потрібно обмінюватися інформацією. Один документ замість трьох двосторонніх. Складніше складати, але простіше керувати.

Ці два документи часто плутають, і ця плутанина спричиняє реальні проблеми. Вони захищають різні речі та найкраще працюють разом.

NDA для підрядника захищає конфіденційну інформацію, яку ви ділитеся з підрядником. Він регулює, що вони не можуть розголошувати. Він нічого не каже про те, кому належить робота, яку вони створюють.

Договір про передачу ІВ робить навпаки: він визначає, кому належить робочий продукт, створений під час співпраці. У більшості юрисдикцій незалежний підрядник є власником авторських прав на код, який він пише, якщо немає письмової угоди про передачу цього права власності вам.

Ось чому це важливо: якщо у вас є NDA, але немає договору про передачу ІВ, підрядник не може розголошувати ваші таємниці — але він може володіти кодом, який написав для вас. Це суттєва прогалина.

Для IT-компанії зазвичай потрібні обидва документи:

1. 1.
   NDA захищає конфіденційну інформацію, якою ви ділитеся під час співпраці
2. 2.
   Договір про передачу ІВ передає право власності на робочий продукт вам

Деякі контракти об'єднують обидва в один документ (типово для консалтингових угод), але збереження їх окремо робить обсяг кожного зобов'язання чіткішим і легшим для окремого виконання.

У блозі Chaindoc є окремий посібник про як створити безпечний NDA, який детальніше розкриває загальну структуру NDA — варто прочитати разом із цим посібником для підрядників.

Пункт про неконкуренцію обмежує підрядника від роботи на конкурентів або створення конкуруючого бізнесу протягом визначеного періоду після завершення співпраці. NDA обмежує, що він може розголошувати, але не заважає йому працювати на вашого конкурента — лише приносити ваші таємниці з собою.

На практиці: якщо старший розробник знає всю вашу технічну архітектуру, навіть ідеально виконуваний NDA не заважає йому відтворити її з пам'яті для конкурента. Пункт про неконкуренцію безпосередньо адресує цей ризик.

Проте пункти про неконкуренцію для незалежних підрядників є виконуваними лише в деяких юрисдикціях, і суди ретельно перевіряють їх на розумність — зокрема обсяг (які галузі чи ролі обмежені), географію (який регіон) і тривалість (як довго). Наприклад, Каліфорнія в цілому відмовляється виконувати неконкуренцію для підрядників. Багато країн ЄС мають подібні обмеження.

Для більшості IT-компаній, що працюють із підрядниками:

• Завжди використовуйте NDA — виконуваний майже всюди, необхідний захист
• Використовуйте неконкуренцію вибірково — для старших підрядників із глибоким доступом до основного ІВ, у юрисдикціях, де виконання реалістичне, з вузьким і розумним обсягом
• Не вбудовуйте неконкуренцію в NDA — тримайте її в основній угоді про послуги або окремому пункті, щоб суперечки про один не анулювали інший

Універсальні шаблони NDA часто пропускають специфічний для софта обсяг, який робить ці угоди дійсно захисними. Ось 10 пунктів, які має містити кожен NDA для IT-підрядника.

1. Визначення конфіденційної інформації (специфічне для софта)

Перелічіть явні категорії, не покладайтеся на загальні формулювання. Для IT-компаній це означає: вихідний код і скомпільовані бінарники, системна архітектура та технічні специфікації, схеми баз даних, API-ключі та облікові дані автентифікації, дані клієнтів і списки клієнтів, дорожні карти продукту та невипущені функції, а також внутрішні інструменти або пропрієтарні робочі процеси.

2. Політика доступу до репозиторію

Вкажіть, до яких кодових репозиторіїв підрядник має доступ, рівень дозволу (читання, запис, адміністратор) та зобов'язання не зберігати копії після завершення співпраці. Цей пункт специфічний для софта і більшість універсальних шаблонів його не містять.

3. Обробка даних клієнтів

Якщо підрядник матиме доступ до будь-яких даних клієнтів — навіть у тестовому або staging-середовищі — вкажіть дозволені способи використання, заборону на зберігання копій та зобов'язання повідомити, якщо вони підозрюють витік даних.

4. Посилання на договір про передачу ІВ

Зазначте, що цей NDA працює разом із окремим договором про передачу ІВ, і що зобов'язання підрядника щодо конфіденційності незалежні від договору про передачу ІВ — порушення одного документа не впливає на виконуваність іншого.

5. Повернення або знищення матеріалів

Після припинення співпраці підрядник має повернути або засвідчено знищити всі копії конфіденційної інформації — включно з кодом, завантаженим локально, документацією, збереженою в особистих хмарних сховищах, та API-обліковими даними. Вимагайте письмового підтвердження.

6. Передача зобов'язань субпідрядникам

Якщо підрядник використовує субпідрядників, ці субпідрядники мають бути пов'язані еквівалентними зобов'язаннями щодо конфіденційності перед отриманням будь-якої конфіденційної інформації.

Один і той самий шаблон NDA не однаково добре підходить для кожного типу співпраці з підрядником. Ось як профіль ризику — а отже й вимоги до NDA — відрізняються за типом підрядника.

Фрілансер-розробник

Фрілансер, який працює над окремою функцією або модулем, має обмежений обсяг доступу: він бачить лише те, що стосується його завдання. Ваш NDA тут може бути відносно стандартним — односторонній, із специфічним для софта визначенням конфіденційної інформації та пунктом про доступ до репозиторію. Процес підписання має бути простим і швидким: надіслати, підписати, продовжувати. Тертя тут втрачає вам хороших підрядників.

Субпідрядник (через основну агенцію)

Це ризикованіша установка, ніж здається. Коли ви наймаєте агенцію, а вона делегує роботу окремим розробникам, ви часто не знаєте, хто ці розробники і до чого вони мають доступ. Ваш NDA з агенцією має містити пункт про передачу зобов'язань субпідрядникам (пункт 6 вище) і вимагати, щоб вас повідомляли про всіх субпідрядників, які матимуть доступ до ваших систем. Розгляньте можливість вимагати прямих NDA з ключовими субпідрядниками, якщо вони матимуть доступ до репозиторію.

Офшорна компанія-розробник

Тут NDA потребують найбільшої ретельності. Офшорна фірма може мати власні стандартні угоди, які виглядають вичерпними, але регулюються іноземним правом із обмеженою виконуваністю у вашій юрисдикції. Ключові доповнення для офшорних співпраць:

• Пункт про право та юрисдикцію, який визначає вашу юрисдикцію для вирішення спорів
• Явні положення про відповідність GDPR/CCPA, якщо стосуються дані клієнтів
• Взаємний NDA, якщо фірма ділитиметься пропрієтарною методологією — але переконайтеся, що обсяг вашої конфіденційної інформації принаймні такий самий широкий, як їхній
• Міжнародний арбітраж (за правилами ICC або AAA) для вирішення спорів

Для команд, які керують підрядниками різних типів, програмне забезпечення для управління контрактами для IT-компаній може відстежувати, який підрядник має яку угоду, коли вона була підписана і коли належить продовження чи перегляд — замість...

Найпоширеніша помилка IT-компаній полягає не в тому, що вони складають поганий NDA, — а в тому, що підписують його занадто пізно.

NDA має бути укладений перед тим, як будь-яка конфіденційна інформація буде розкрита. Це звучить очевидно, але на практиці його пропускають під час початкових розмов, дзвінків-знайомств і технічних сесій зі визначення обсягу, де ви ділитеся системним контекстом, щоб допомогти підряднику зрозуміти проєкт.

Ось правильний порядок підписання для типової співпраці з підрядником:

1. 1.
   NDA — Підписати першим, перед будь-яким дзвінком-знайомством, де ви обговорюватимете технічну архітектуру, дані клієнтів або системні специфіки
2. 2.
   Договір про передачу ІВ — Підписати перед початком будь-якої роботи (ідеально — одночасно з NDA або відразу після нього)
3. 3.
   Statement of Work (SOW) — Визначає обсяг, результати, терміни та оплату; підписати перед початком роботи. Дивіться наш посібник із SOW-контрактів, що мають містити.
4. 4.
   Master Services Agreement (MSA) або контракт на розробку софта — Керівна рамка для постійних відносин

Корисне правило: якщо ви збираєтеся сказати потенційному підряднику щось, що не хотіли б оприлюднити, NDA вже має бути підписаний.

Для ранніх розмов перед вибором підрядника — розвідувальні дзвінки, процеси RFP — ви можете або ділитися лише загальним неконфіденційним контекстом, або використовувати легкий взаємний NDA, який обидві сторони швидко підписують. Другий варіант чистіший.

Для команд, які часто проводять онбординг підрядників, автоматизація робочого процесу онбордингу та NDA для підрядників усуває помилки з термінами — система ініціює надсилання NDA перед наданням першого доступу.

Зазвичай ви надсилатимете NDA підрядникам. Але підрядники — особливо встановлені агенції — іноді пропонують свої. Ось що має вас насторожити.

Занадто широке визначення "конфіденційної інформації" з їхнього боку

Якщо NDA підрядника визначає їхню конфіденційну інформацію як "будь-яка інформація, поділена під час співпраці" без осмислених меж, ви можете опинитися в ситуації, коли не зможете ділитися тим, що дізналися, — вашою власною архітектурою, вашим власним контекстом клієнтів — із майбутніми підрядниками, які виконуватимуть подібну роботу. Взаємний NDA має мати чітко окреслені та збалансовані визначення з обох боків.

Невизначений термін для інформації, що не є комерційною таємницею

Невизначений термін конфіденційності для загальної бізнес-інформації (не конкретних комерційних таємниць) часто є невиконуваним і є червоним прапорцем, що угоду складали недбало. У деяких юрисдикціях суди визнають недійсними невизначені зобов'язання щодо конфіденційності звичайної бізнес-інформації як нерозумне обмеження комерції. Настоюйте на конкретному терміні.

Односторонній арбітражний пункт

Якщо NDA передбачає арбітраж лише в юрисдикції підрядника, із обраними ним арбітрами, це асиметричний механізм виконання. Вам доведеться їхати, щоб захищати власні права на конфіденційність. Або встановіть нейтральну юрисдикцію, або визначіть правила арбітражу від визнаної організації (ICC, AAA) без упередженого місця проведення.

Відсутність виключення для наявного ІВ

Деякі NDA, запропоновані підрядниками, містять формулювання, які можна трактувати як надання підряднику певних прав на те, що він дізнається про ваш ІВ — особливо якщо "конфіденційна інформація" визначена настільки широко, що охоплює будь-який інсайт, який він отримує. Якщо NDA не явно виключає ваш наявний ІВ з будь-яких обмежень на ваше використання, вимагайте уточнення.

Відсутність пункту про повернення або знищення

NDA для підрядника без явного зобов'язання повернути або знищити дозволяє підряднику зб...

Ставки не є гіпотетичними. Ці кейси ілюструють, чого насправді коштує незаконне використання комерційних таємниць.

Cadence Design Systems v. Avanti Corporation ($265 млн)

Avanti, конкуруюча компанія з розробки EDA-софта, була визнана винною у використанні пропрієтарного вихідного коду Cadence — нібито принесеного колишніми співробітниками Cadence, які перейшли до Avanti. Суд присудив понад $265 мільйонів і кримінальні вироки кільком особам. Основний механізм полягав у звільненні працівників, але той самий ризик стосується підрядників: підрядник, який працює в кількох компаніях, є вектором передачі коду — навмисно чи ні.

Урок: навіть добре забезпечені IT-компанії з встановленим захистом ІВ стикаються з цим ризиком. Угоди про конфіденційність із будь-ким, хто має доступ до пропрієтарного коду, є частиною базової ІВ-гігієни — а не необов'язковим додатком.

Waymo v. Uber ($245 млн)

Waymo, дочірня компанія Alphabet з розробки безпілотних автомобілів, подала позов проти Uber після того, як колишній інженер Google нібито забрав конфіденційні технічні файли до стартапу, який згодом придбав Uber. Врегулювання досягло приблизно $245 мільйонів акціями. Варто зазначити, що інженер підписав NDA та угоди про ІВ із Google — що означало, Waymo мала юридичне підстави агресивно переслідувати справу.

Зворотний бік теж важливий: NDA та угоди про передачу ІВ не запобігли витоку. Але вони дали Waymo юридичну підставу діяти. Без них Waymo не мала б виконуваного механізму для домовленості про врегулювання такого масштабу. Саме в цьому полягає реальна цінність добре складеного NDA для підрядника: не в запобіганні, а в можливості виконання, коли запобігання дає збій.

Обидва кейси стосувалися комерційних таємниць набагато складніших, ніж у більшості співпраць із підрядниками. Але патерн універсальний для софта: конфіденційний код рухається разом із людьми, які його пишуть. Ваш NDA для підрядника — це юридичний механізм, який робить цей рух піддається судовому переслідуванню.

Швидке підписання NDA має значення. Громіздкий процес означає, що підрядники або пропускають його, або підписують пізно — обидва варіанти є провалом. Ось як зробити це правильно і швидко.

Крок 1: Підготуйте документ NDA

Використовуйте шаблон нижче або власну кастомізовану версію. Переконайтеся, що всі специфічні для софта пункти на місці перед надсиланням. Останньохвилинне доповнення після того, як підрядник переглянув документ, необґрунтовано подовжує терміни.

Крок 2: Надішліть на електронний підпис

Завантажте NDA на платформу електронного підпису, яка забезпечує захист від несанкціонованих змін із аудиторським слідом. Це не бюрократична примха — це доказова база. Якщо вам колись знадобиться виконати NDA, вам потрібен доказ, що конкретна людина підписала конкретний документ у конкретний час і що документ не був змінений після цього.

Chaindoc використовує блокчейн-верифікацію для запису кожної події підписання в незмінний реєстр. На відміну від простого PDF-аудиторського журналу, який живе на серверах однієї компанії, блокчейн-запис не може бути ретроактивно змінений жодною зі сторін. Це має значення в суперечках, коли адвокат підрядника ставить під сумнів, чи документ, який він бачить, — це той, який підписав його клієнт.

Крок 3: Верифікуйте особу перед підписанням

Підпис від "user@gmail.com" не доводить, що людина, з якою ви домовилися, дійсно підписала. Використовуйте як мінімум OTP-верифікацію електронної пошти; для високовартісних співпраць SMS або верифікація за державним ID забезпечує сильніше заперечення відмови.

Крок 4: Зберігайте з контролем доступу

Підписаний NDA має зберігатися в системі управління документами з керуванням доступом на основі ролей — доступний для вашої юридичної команди та керівництва, а не в спільній email-папці. Позначте його ім'ям підрядника, датами співпраці та посиланням на проєкт, щоб його можна було знайти в стресовій ситуації.

Крок 5: Відстежуйте термін дії та поновлення

Якщо ваш NDA має визначений термін, відстежуйте дату закінчення. NDA, який закінчився шість місяців тому, не захищає вас сьогодні.

Для IT-компаній, які керують...

Шаблон нижче є відправною точкою — односторонній NDA для підрядника зі вбудованими специфічними для софта пунктами. Він охоплює всі 10 пунктів, перелічених у цьому посібнику, і включає налаштування за замовчуванням для юрисдикції США (регулюється законами штату, який ви вкажете, із зазначенням захисту комерційних таємниць за DTSA).

Завантажте шаблон NDA для підрядника від Chaindoc:

• Завантажити PDF
• Завантажити DOCX

Що включено в шаблон:

• Специфічне для софта визначення конфіденційної інформації (вихідний код, архітектура, облікові дані, дані клієнтів, дорожні карти)
• Пункт про політику доступу до репозиторію
• Зобов'язання щодо передачі субпідрядникам
• Пункт про повернення або знищення з вимогою засвідчення
• Пункт-посилання на договір про передачу ІВ
• Пункт про судову заборону
• Заповнювач права та юрисдикції (вкажіть свій штат або юрисдикцію)
• 3-річний термін для загальної конфіденційної інформації / невизначений для комерційних таємниць

Важливе застереження: Цей шаблон надається в інформаційних цілях і не є юридичною консультацією. Виконуваність залежить від юрисдикції та конкретних обставин. Для високовартісних співпраць, нових відносин із підрядниками або транскордонних ситуацій майте угоду переглянуту кваліфікованим адвокатом перед використанням.

Для повного стеку документів онбордингу підрядника — NDA, SOW і платіжні умови — інструменти управління контрактами для IT-компаній від Chaindoc дозволяють створити шаблони один раз і надсилати їх послідовно кожному новому підряднику.