NDA для подрядчика в IT: полное руководство с бесплатным шаблоном

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

NDA для подрядчика не гарантировал бы абсолютной защиты. Но он дал бы вам правовое основание действовать, требовать возмещения убытков и останавливать дальнейшее разглашение. Без него вы просто надеетесь, что подрядчик окажется честным.

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

Если вам нужен более широкий взгляд на то, как различия между контрактом и соглашением применяются к вашим отношениям с подрядчиками, стоит прочитать это в первую очередь.

NDA для подрядчика (соглашение о неразглашении) — это юридически обязательный контракт, который обязывает независимого подрядчика — будь то фриланс-разработчик, субподрядчик или офшорная компания — хранить вашу конфиденциальную информацию в секрете. Он определяет, что считается конфиденциальным, как долго действует обязательство и что произойдет, если подрядчик его нарушит.

Для IT-компаний конфиденциальная информация — это не только бизнес-планы или финансовые данные. Это исходный код, системная архитектура, учетные данные доступа к репозиториям, данные клиентов, API-интеграции, проприетарные алгоритмы и дорожные карты продуктов, которые еще не выпущены. Это более широкий и технически специфичный охват, чем покрывает универсальный NDA.

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

Краткий ответ о правоприменимости: хорошо составленный NDA для подрядчика применим во всех основных юрисдикциях на основании принципов договорного права. В США коммерческая тайна также защищается на федеральном уровне Законом о защите коммерческой тайны (DTSA) и на уровне штатов — Единообразным законом о коммерческой тайне (UTSA) — что дает вам два независимых правовых механизма, если подрядчик незаконно использует ваш код.

Краткий ответ: подрядчики — не сотрудники, и эта разница имеет юридическое значение.

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

Специфические риски для IT-компаний выше, чем в большинстве отраслей:

• Утечка исходного кода — Подрядчику, которому дан доступ к репозиторию, видна вся техническая реализация. Если он уходит без NDA, он может свободно воспроизвести или продать эти знания.
• Доступ к данным клиентов — Многие подрядчики работают с базами данных клиентов, записями CRM или API-эндпоинтами, которые раскрывают информацию о клиентах. Утечка здесь — это не только конкурентное поражение, но и ответственность по GDPR или CCPA.
• Коммерческая тайна в архитектуре — Ваш дизайн системы, то, как вы структурировали конвейеры данных, ваши проприетарные алгоритмы — это коммерческая тайна только в том случае, если она обрабатывается как тайна. NDA — это часть такого обращения.
• Риск передачи через субподрядчиков — Если ваш подрядчик нанимает собственных субподрядчиков (часто при офшорном аутсорсинге), и те не связаны обязательствами конфиденциальности, ваши секреты утекают через брешь в вашей правовой системе.

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

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

Не каждое взаимодействие с подрядчиком требует одинаковой структуры NDA. Выбор неправильного типа тратит переговорный капитал и может даже сигнализировать, что вы не понимаете суть отношений.

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

Это стандартная форма для большинства взаимодействий с подрядчиками. Только одна сторона — как правило, IT-компания — раскрывает конфиденциальную информацию, и только подрядчик связан обязательством конфиденциальности. Вы нанимаете кого-то, чтобы он что-то создал. Вы делитесь спецификациями, архитектурой, контекстом клиента. Они не раскрывают вам ничего проприетарного.

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

Двусторонний (взаимный) NDA

Обе стороны обмениваются конфиденциальной информацией и обе связаны обязательствами. Это уместно, когда вы оцениваете аутсорсинговую фирму, которая будет предлагать вам собственную проприетарную методологию, процессы или ИС — и у нее есть законный интерес в защите этой информации.

На практике офшорные компании часто запрашивают взаимный 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. Передача обязательств субподрядчикам

Если подрядчик использует субподрядчиков, эти субподрядчики должны быть связаны эквивалентными обязательствами конфиденциальности до получения любой конфиденциальной информации. Подрядчик несет ответственность за нарушения со стороны своих субподрядчиков.

7. Срок и сохранение обязательств

Обязательства по конфиденциальности в отношении коммерческих тайн (исходный код, ключевые алгоритмы) должны сохраняться бессрочно после окончания взаимодействия. Для иной конфиденциальной информации стандартом являются три-пять лет. Явно укажите, что NDA сохраняет силу после расторжения основного соглашения об услугах.

8. Исключения из конфиденциальности

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

9. Право и юрисдикция

Назовите управляющую юрисдикцию явно. Для международных взаимодействий с подрядчиками рассмотрите арбитраж как механизм разрешения споров — он обычно быстрее и предсказуемее через границы, чем судебное разбирательство.

10. Средства правовой защиты и судебный запрет

Явно укажите, что нарушение причинит непоправимый вред, оправдывающий судебный запрет без требования доказательства конкретного денежного ущерба. Это стандартная формулировка NDA, но критически важная — без нее вам пришлось бы квантифицировать убытки до того, как суд примет меры, что сложно при нарушениях ИС.

Один и тот же шаблон 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" не доказывает, что человек, с которым вы заключили договор, действительно подписал. Используйте как минимум email-подтверждение через OTP; для высокостоимостных взаимодействий SMS или верификация по удостоверению личности обеспечивают более сильную неотказуемость.

Шаг 4: Храните с контролем доступа

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

Шаг 5: Отслеживайте срок действия и продление

Если ваш NDA имеет определенный срок, отслеживайте дату окончания. NDA, который истек шесть месяцев назад, не защищает вас сегодня.

Для IT-компаний, управляющих документооборотом для IT-команд, автоматизация этого процесса — запуск отправки NDA при добавлении подрядчика, автонапоминание до предоставления доступа, оповещения об истечении срока — устраняет ручную нагрузку, которая вызывает ошибки сроков. См. тарифы Chaindoc для командных планов, включающих документооборот для подрядчиков.

Для более глубокого изучения правового соответствия электронных подписей Закон ESIGN (США) и eIDAS (ЕС) подтверждают, что электронно подписанные NDA имеют ту же юридическую силу, что и бумажные.

Шаблон ниже — это отправная точка: односторонний NDA для подрядчика со встроенными пунктами, специфичными для ПО. Он охватывает все 10 пунктов, перечисленных в этом руководстве, и включает настройки по умолчанию для юрисдикции США (регулируется законами штата, который вы укажете, со ссылкой на защиту коммерческой тайны по DTSA).

Скачайте шаблон NDA для подрядчика от Chaindoc:

• Скачать PDF
• Скачать DOCX

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

• Определение конфиденциальной информации, специфичное для ПО (исходный код, архитектура, учетные данные, данные клиентов, дорожные карты)
• Пункт о политике доступа к репозиторию
• Обязательство по передаче обязательств субподрядчикам
• Пункт о возврате или уничтожении с требованием сертификации
• Перекрестная ссылка на договор об отчуждении ИС
• Пункт о судебном запрете
• Заполнитель права и юрисдикции (укажите свой штат или юрисдикцию)
• Срок 3 года для общей конфиденциальной информации / бессрочно для коммерческих тайн

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

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