Приходит вопрос: «у нас же есть NDA, зачем еще какое-то соглашение о конфиденциальности персональных данных?» Так рассуждает подрядчик, которому нужно передать доступ к базе клиентов, или заказчик, нанявший фрилансера для доработки сайта. Подписали NDA, обменялись сканами с печатями - вопрос вроде бы закрыт. На деле соглашение о конфиденциальности персональных данных и обычный NDA - разные по смыслу документы, и путаница между ними всплывает почти на каждой проверке, до которой доходит дело.
NDA (non-disclosure agreement, соглашение о неразглашении) регулирует отношения двух компаний и защищает коммерческую информацию: цены, технологии, клиентскую базу как актив бизнеса. Закон о персональных данных требует другого - поручения на обработку, оформленного по конкретным правилам, и отдельного обязательства конкретных сотрудников не раскрывать данные третьим лицам. Сам по себе NDA ни то, ни другое не заменяет, даже если слово «конфиденциальность» стоит прямо в его названии. Разница выглядит формальной ровно до первой проверки или жалобы клиента - тогда и выясняется, что нужного документа в природе не было.
NDA и соглашение о конфиденциальности персональных данных: откуда путаница
Путаница берется из терминологии. NDA - понятие из деловой практики, не из закона. Юристы и менеджеры используют один и тот же шаблон для любых ситуаций, где звучит слово «конфиденциальность»: для переговоров о слиянии, для работы с подрядчиком по разработке, для найма нового сотрудника. Шаблон переходит из проекта в проект, дополняется парой пунктов и в итоге называется универсальным решением.
Проблема в том, что типовой NDA не ссылается на закон «О персональных данных» от 27.07.2006 № 152-ФЗ, не определяет, кто в отношениях является оператором, а кто - лицом, обрабатывающим данные по поручению, и не перечисляет, какие именно персональные данные и для каких целей передаются. Он защищает информацию как актив компании - примерно так же, как защищает рецептуру или список поставщиков. Персональные данные закон рассматривает иначе: как сведения о конкретном человеке, в отношении которого у компании есть обязанности независимо от того, насколько эти данные секретны для конкурентов.
На практике это выглядит так: веб-студия подписывает с заказчиком «стандартный NDA» перед началом проекта. Через два месяца заказчик открывает разработчику доступ к базе клиентов для настройки интеграции с CRM. Обе стороны считают, что подписанный документ уже закрывает и это тоже. Формально это не так. NDA защищает от разглашения бизнес-информации заказчика. Обработку персональных данных клиентов он не регулирует вообще, и с точки зрения 152-ФЗ у разработчика в этот момент нет законного основания к этим данным прикасаться.
Разница не праздная. Если проверка Роскомнадзора запросит документ, на основании которого подрядчик обрабатывает персональные данные, ссылка на NDA инспектора не устроит - там просто нет ответа на вопрос, какие данные, зачем и на каких условиях передаются. Формально выглядит так, будто согласованного основания для обработки не было вовсе, даже если обе стороны были уверены в обратном.
Что реально закрывает NDA, а что нет
Чтобы не гадать на конкретном договоре, полезно развести пункты по двум спискам.
NDA обычно закрывает:
- защиту коммерческой информации - условий сделок, цен, технологий, ноу-хау - от разглашения конкурентам;
- ответственность за передачу секретов третьим лицам, включая неустойку или взыскание убытков;
- срок, в течение которого информация считается конфиденциальной, часто с привязкой к режиму коммерческой тайны;
- обязанность вернуть или уничтожить материалы после окончания сотрудничества.
NDA почти никогда не закрывает:
- основание для обработки персональных данных - какое из законных оснований применяется в конкретном случае;
- перечень разрешенных действий с данными: сбор, хранение, передачу, удаление;
- обязанность подрядчика обеспечить меры защиты, соответствующие уровню защищенности данных;
- ответственность оператора перед субъектом персональных данных и перед Роскомнадзором - она возникает по закону независимо от того, что написано в NDA.
На практике это означает, что при выборе, какой документ подписывать, стоит смотреть не на название, а на содержание. Если в тексте нет ссылки на 152-ФЗ и не описаны конкретные данные - какие, чьи, для какой цели, - документ регулирует что угодно, кроме персональных данных, как бы он ни назывался.
Есть и более формальная разница. Чтобы информация вообще считалась коммерческой тайной, компании нужно ввести ее режим: утвердить перечень сведений, ограничить доступ, поставить на документах гриф коммерческая тайна в соответствии с законом О коммерческой тайне от 29.07.2004 № 98-ФЗ. Без этого NDA юридически защищает не так много, как кажется сторонам на бумаге. Персональные данные признаются таковыми по факту - как только это сведения о конкретном человеке, а не потому, что компания решила их засекретить.
Разница принципиальная. Коммерческую тайну компания определяет сама. Персональные данные закон защищает независимо от воли компании, и обязанность здесь возникает не из соглашения сторон, а из статьи 7 152-ФЗ, которая прямо требует от оператора и от любого лица, получившего доступ к данным, не раскрывать их третьим лицам и не распространять без согласия субъекта.
Обязательство о неразглашении персональных данных для сотрудника
Отдельная история - сотрудники самой компании, не подрядчики. Кадровик видит паспортные данные соискателей, менеджер по продажам - телефоны и адреса клиентов, бухгалтер - банковские реквизиты. Все это персональные данные, доступ к которым у сотрудника есть по должности, а не по отдельному договору. Ни один из них никакого NDA не подписывал - просто получил доступ к базе или папке с документами в первый рабочий день, вместе с логином от почты.
Здесь тоже действует статья 7 152-ФЗ: любое лицо, получившее доступ к персональным данным, обязано не раскрывать их третьим лицам и не распространять без согласия субъекта. Чтобы это требование работало на практике, а не существовало только в тексте закона, обязательство стоит оформить письменно - либо отдельным пунктом в трудовом договоре (статья 57 ТК РФ допускает включать в него условие о неразглашении охраняемой законом тайны), либо отдельным документом при приеме на работу.
Частая ошибка - работодатель считает, что общий NDA о коммерческой тайне, который сотрудник подписывает при трудоустройстве, закрывает и вопрос персональных данных тоже. Предмет разный. Коммерческая тайна защищает бизнес-информацию как актив. Персональные данные защищают интересы конкретного человека, и это не зависит от того, ввела ли компания у себя режим коммерческой тайны вообще.
То же касается людей, которые формально не сотрудники компании, но фактически работают с данными: самозанятый бухгалтер на подряде, приходящий системный администратор, репетитор частной школы, которому передают контакты учеников и родителей. Трудового договора с ними нет, поэтому статья 57 ТК РФ не подходит - но обязательство о неразглашении оформляется тем же способом: отдельным пунктом в договоре оказания услуг или отдельным документом, который стороны подписывают до передачи доступа к данным.
У отдельного письменного обязательства есть и практическое значение помимо буквы закона. Если сотрудник унес базу клиентов на новое место работы, работодателю нужно основание для увольнения за разглашение персональных данных другого работника, ставших известными в связи с исполнением трудовых обязанностей - такое основание прямо предусмотрено Трудовым кодексом. Без письменного обязательства доказать, что сотрудник вообще был предупрежден о конфиденциальности этих данных, заметно сложнее.
Полный список документов, которые должны быть в компании помимо этого обязательства - от политики обработки до приказа о назначении ответственного, - подробно разобран в материале про локальные акты оператора персональных данных.
Поручение на обработку персональных данных - когда без него нельзя
Если подрядчик получает не просто доступ к переговорам и документам компании, а доступ к самим персональным данным - базе клиентов, CRM, серверу с резервными копиями, - разговор идет уже не про NDA, а про поручение на обработку персональных данных. Это отдельный институт, предусмотренный частью 3 статьи 6 152-ФЗ: оператор вправе поручить обработку данных другому лицу на основании договора, но этот договор должен содержать конкретный набор условий, а не общие слова о конфиденциальности.
В поручении должны быть указаны цели обработки, перечень действий (операций), которые подрядчик вправе совершать с данными, характер использования данных и обязанность подрядчика соблюдать конфиденциальность и обеспечивать безопасность данных при их обработке. Это не формальность для галочки - именно этот документ инспектор Роскомнадзора будет искать в первую очередь, если увидит, что данные компании обрабатывает кто-то за ее пределами.
Типовой NDA почти никогда не содержит этих элементов, потому что писался для другой задачи. Даже если добавить в него пункт стороны обязуются соблюдать конфиденциальность персональных данных, это не превращает документ в поручение - не хватает целей обработки, перечня действий и требований к защите. Подробнее о том, как правильно составить такой документ и в каких случаях он обязателен, - в статье про договор поручения на обработку персональных данных.
Если поручения нет вообще - ни в виде отдельного документа, ни в виде раздела в договоре с подрядчиком, - формально у оператора нет законного основания передавать подрядчику доступ к персональным данным клиентов. На практике договор чаще всего ограничивается общими фразами о конфиденциальности, а перечень действий с данными нигде не зафиксирован. Это не значит, что пробел останется незамеченным: именно такие места чаще всего всплывают при проверке или уже после утечки, когда что-то менять поздно.
Практический ориентир простой: если у подрядчика есть техническая возможность увидеть, скопировать или изменить персональные данные - разработчик сайта с доступом к базе, ИТ-компания на обслуживании сервера, бухгалтерия на аутсорсе, колл-центр, сервис email-рассылок, - нужен именно этот документ. NDA при этом можно оставить как есть: он продолжает защищать коммерческую часть отношений, но поручение заменить не может.
Три ситуации, где одного NDA точно не хватит
Разработчик дорабатывает сайт
Веб-студия, которая делает лендинг без личного кабинета и без интеграции с CRM, скорее всего к персональным данным клиентов вообще не прикасается - тогда достаточно и одного NDA о коммерческой информации проекта. Но как только в задаче появляется личный кабинет, форма с базой контактов или доступ к панели администратора интернет-магазина, ситуация меняется. Формально у разработчика в этот момент нет законного основания обрабатывать эти данные, если стороны ограничились NDA и не оформили поручение. Часто такой разработчик работает как самозанятый и подписывает с заказчиком типовой договор оказания услуг, где о персональных данных нет ни слова - раздел о конфиденциальности рассчитан на защиту макетов и исходного кода, а не базы клиентов. Вопрос, кто в такой связке отвечает за утечку и что для этого нужно прописать в договоре, подробнее разобран в статье про персональные данные подрядчика и аутсорсера.
Аутсорсинг бухгалтерии интернет-магазина
Бухгалтерская компания на аутсорсе обрабатывает ФИО, адреса доставки, а нередко и номера карт клиентов интернет-магазина - для оформления возвратов и сверки платежей. В типовом договоре на бухгалтерское обслуживание обычно есть пункт про конфиденциальность коммерческой информации клиента, скопированный из общего шаблона. Про персональные данные там, как правило, ни слова. Проще всего закрыть этот пробел не переписыванием всего договора, а отдельным приложением-поручением: двух-трех листов с целями обработки, перечнем действий и сроком хранения данных у подрядчика хватает, чтобы формально закрыть требование закона.
Совместная акция с партнером
Интернет-магазин делится частью базы клиентов с партнерским брендом для совместной рекламной рассылки. Ситуация отличается от первых двух: партнер использует данные не по заданию оператора, а в собственных интересах, поэтому это уже не поручение, а передача персональных данных третьему лицу. NDA между компаниями о неразглашении базы друг другу не создает законного основания для самой передачи - для этого нужно отдельное согласие субъекта с указанием конкретного получателя и цели либо иное законное основание. Подробнее - в материале о передаче персональных данных третьим лицам.
Что должно быть в соглашении о конфиденциальности персональных данных
Если помимо поручения компания все же хочет отдельное соглашение о конфиденциальности персональных данных - например, чтобы свести все обязательства подрядчика в одном документе, - у него должен быть свой набор обязательных пунктов. Ориентир - таблица ниже: что в документе должно быть и чего из этого обычно нет в типовом NDA.
| Пункт | Зачем нужен | Есть ли в типовом NDA |
|---|---|---|
| Цели обработки персональных данных | Определяет, для чего подрядчик получает доступ к данным и что считается превышением полномочий | Как правило, нет |
| Перечень действий с данными | Что именно можно делать: собирать, хранить, передавать, удалять | Нет |
| Категории и состав персональных данных | Какие данные передаются - ФИО, телефон, паспортные данные, платежные реквизиты | Нет |
| Требования к защите данных | Технические и организационные меры с учетом уровня защищенности | Редко, и без конкретики |
| Срок обработки и порядок уничтожения | Что происходит с данными после окончания договора и в какой срок | Иногда общая фраза без сроков |
| Порядок уведомления об инцидентах | В какой срок подрядчик обязан сообщить оператору об утечке или сбое | Практически никогда |
| Ответственность сторон по 152-ФЗ | Прямая ссылка на закон о персональных данных, а не только на убытки по договору | Нет |
Разница между строками не декоративная. Каждый пункт таблицы - то, что при проверке или при разборе инцидента спросят в первую очередь: какие данные, для чего, кто отвечает за их защиту и что происходит с ними дальше. Сам по себе NDA, даже подписанный с самыми строгими формулировками об ответственности, отвечает на эти вопросы косвенно или не отвечает вовсе.
Если в NDA этих пунктов нет, самое простое решение - не переписывать документ целиком, а добавить их отдельным приложением или включить в договор с подрядчиком как поручение на обработку. Дублировать один и тот же смысл в двух документах не обязательно, важно, чтобы он был хотя бы в одном из них.
Кто отвечает, если утечка произошла у подрядчика
Даже при подписанном NDA и оформленном поручении ответственность перед субъектом персональных данных и перед Роскомнадзором в первую очередь несет оператор - компания, которая изначально собрала данные и получила согласие на их обработку. У клиента или сотрудника есть правоотношения именно с оператором, а не с его подрядчиком, о существовании которого субъект данных чаще всего даже не знает. Клиника передает данные пациентов в лабораторию на аутсорсе - если утечка произойдет на стороне лаборатории, обращение пациента и внимание проверяющих придут в клинику, а не в лабораторию.
Поручение помогает разграничить ответственность между компаниями внутри их договора - оператор вправе взыскать с подрядчика убытки, если утечка произошла по его вине и это прямо прописано в договоре. Но это внутренний регресс, а не замена ответственности перед государством. Проверка Роскомнадзора и жалоба субъекта данных придут к оператору в любом случае, а дальше уже оператор разбирается с подрядчиком по договору. Без пункта об ответственности за нарушение именно 152-ФЗ в тексте поручения этот регресс будет сложно обосновать - общая фраза про убытки по договору такую ситуацию не покрывает.
Ставки в 2026 году выше, чем неустойка по обычному NDA. С 30 мая 2025 года применяются оборотные штрафы и статья 272.1 УК РФ, введенные Федеральным законом от 30.11.2024 № 420-ФЗ: утечка данных перестала быть вопросом репутации и договорных санкций, речь идет об ответственности вплоть до уголовной. Размер компании тут не имеет значения: небольшой интернет-магазин с одним подрядчиком на аутсорсе рискует тем же набором последствий, что и крупная сеть, - жалобой клиента, запросом Роскомнадзора и проверкой, есть ли документ, которым подтверждается законность передачи данных подрядчику. При таких рисках рассчитывать, что типовой NDA с подрядчиком закрывает вопрос персональных данных, - решение, которое не выдержит ни проверки, ни тем более разбирательства после реальной утечки.
Что делать: порядок действий
Если в компании уже есть NDA с подрядчиками и сотрудниками, но не понятно, закрывает ли он вопрос персональных данных, порядок проверки простой.
- Проверить, есть ли у подрядчика реальный доступ к персональным данным: к базе, CRM, серверу, выгрузкам файлов. Если доступа нет - NDA о коммерческой тайне достаточно.
- Если доступ есть - оформить поручение на обработку персональных данных отдельным документом или приложением к основному договору.
- Указать в поручении цели обработки, перечень действий, категории и состав данных, требования к защите и срок, в течение которого подрядчик вправе их обрабатывать.
- Прописать, что происходит с данными после окончания договора: удаляются, возвращаются оператору или обезличиваются, и в какой срок. Ориентиры по срокам - в статье о сроках хранения персональных данных.
- Взять отдельное письменное обязательство о неразглашении с конкретных сотрудников подрядчика и заказчика, у которых есть доступ к данным - не полагаться на общий NDA компании.
- Оставить прежний NDA как есть, если он действительно защищает коммерческую тайну - переписывать его в документ про персональные данные не нужно, нужен второй документ рядом с первым.
- Проверить, не идет ли речь о передаче данных стороннему получателю для его собственных целей - тогда нужно не поручение, а отдельное основание для передачи и, как правило, отдельное согласие субъекта.
- Зафиксировать дату и объем предоставленного подрядчику доступа - эта запись пригодится, если придется разбираться, кто и когда мог видеть данные.
Если в компании подписан NDA, но нет поручения на обработку персональных данных, или неясно, какой из документов нужен в конкретной ситуации с подрядчиком - привести бумаги в порядок перед проверкой РКН или перед подключением нового партнера можно на 152fzpro.ru: сайт занимается доработкой договоров и документов под требования 152-ФЗ. Обычно достаточно свести три документа в понятную схему: что регулирует NDA, что регулирует поручение и что закрывает обязательство сотрудника, - и не пытаться заменить все это одним универсальным текстом.
