Ликбез подрядчика: как юридически грамотно заставить партнера защищать вашу сеть

В 2026 году Верховный суд РФ окончательно запретил перекладывать ответственность за утечки данных на подрядчиков. Теперь, даже если взломали инфраструктуру партнера, регулятор штрафует компанию-заказчика. Отсутствие контроля над чужой сетью суд больше не признает смягчающим обстоятельством. В таких условиях типовые договоры об оказании ИТ-услуг превращаются во вполне реальную финансовую угрозу для бизнеса.

Исполнительный директор агентства белых хакеров Singleton Security Мартун Минасян в материале для читателей Кибер Медиа расскажет, как минимизировать эту угрозу и грамотно заставить партнера защищать сеть.

Почему стандартный НДА = решето для кибербезопасности

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

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

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

Есть и вторая проблема — доказательная

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

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

Российский рынок уже сталкивался с подобными сценариями, когда инцидент на стороне партнера превращался в проблему для компании-заказчика и ее клиентского периметра. Один из самых показательных — кейс «Ростелекома» в январе 2025 года, когда группировка Silent Crow выложила в открытый доступ 154 тысячи email-адресов пользователей. Корпорации тогда признала, что наиболее вероятно, что пробоина находилась именно в сети обслуживающего подрядчика.

Поэтому в контексте киберрисков стандартный НДА стоит рассматривать только как базовый правовой слой. Он нужен, но его недостаточно. Для заказчика принципиален другой вопрос: какими договорными и техническими механизмами будет обеспечено, что подрядчик не просто подписал обязательство о конфиденциальности, а действительно поддерживает такой уровень защиты, при котором риск инцидента остается управляемым.

Форс-мажор или как подрядчики уходят от удара

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

На практике многие договоры устроены так, что формально фиксируют обязательства исполнителя, но одновременно закладывают для него удобный механизм выхода из-под удара.

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

Первая линия защиты подрядчика обычно строится на договорном ограничении ответственности. Для этого используют общий механизм, заложенный в статье 15 ГК РФ: по общему правилу убытки возмещаются полностью, но закон или договор могут предусматривать меньший объём возмещения. В связке с общими правилами об ограниченной ответственности по статье 400 ГК РФ это позволяет сторонам включать в договоры на ИТ-услуги условия, по которым совокупная ответственность исполнителя ограничивается заранее согласованным лимитом — например, стоимостью услуг за последний месяц, квартал или иной расчётный период

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

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

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

Как договорная проблема превращается в доказательственную

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

Проблема в том, что стандартный договор обычно не дает заказчику ни достаточного доступа к этой информации, ни устойчивого механизма ее получения постфактум. Инфраструктура подрядчика остается для него закрытым контуром. В результате компания несет последствия инцидента, но не располагает собственным набором доказательств, который позволил бы показать в суде или в переговорах, что причиной стала критическая ошибка администрирования, а не абстрактное действие «третьих лиц».

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

Как лучше проверить партнера и не сорвать сделку

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

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

Выходом из этого тупика становится внедрение системы управления рисками подрядчиков (Third-Party Risk Management). Вместо разовых попыток просканировать сеть партнера внедряется непрерывный процесс оценки его защищенности, который начинается еще на самом раннем этапе сотрудничества.

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

Дополнительными маркерами надежности здесь выступают результаты независимых проверок. Наличие актуального сертификата ISO 27001 или заключения о соответствии государственному стандарту (ГОСТ Р 57580.1) доказывает, что безопасность партнера подтверждена профессиональными аудиторами. Так заказчик может опереться на готовые экспертные заключения, избавляя себя от необходимости проводить проверку самостоятельно.

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

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

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

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

Где в договоре заканчиваются общие формулировки и начинаются реальные обязательства

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

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

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

Тайминг инцидентов: фактор 24 часов

Согласно ч. 3.1 ст. 21 Закона № 152-ФЗ, у оператора персональных данных есть 24 часа на первичное уведомление Роскомнадзора об инциденте и 72 часа — на предоставление результатов внутреннего расследования. Если инцидент произошёл в инфраструктуре подрядчика, а тот своевременно не сообщил о нём заказчику, оператор рискует нарушить установленный срок уведомления регулятора и столкнуться с административной ответственностью.

Чтобы исключить этот сценарий, в контракт закладывается жесткое Соглашение об уровне сервиса (SLA) на уведомление: исполнитель обязан сообщить заказчику о любом подозрении на инцидент, включая компрометацию учетных записей или аномальную сетевую активность, в срок не более четырех часов с момента выявления. За срыв этого дедлайна устанавливается крупный фиксированный штраф, не привязанный к стоимости услуг. Основанием для взыскания становится сам факт сокрытия информации, независимо от наличия утечки.

Защита субподряда и экономика отношений

Отдельный риск возникает там, где цепочка исполнителей оказывается длиннее, чем заказчик видит на этапе тендера. Компания может подробно проверить основного подрядчика, но не контролировать тех лиц, которым он впоследствии передаст доступы, данные или часть работ. В такой конструкции управляемость быстро теряется, а вместе с ней исчезает и первоначальный объем контроля.

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

Здесь для заказчика особенно важна статья 403 ГК РФ, поскольку именно она позволяет связывать действия субподрядчиков с ответственностью основного исполнителя.

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

В заключении об архитектуре «нулевого доверия»

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

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

Что здесь решает договор

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

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

Что здесь решает архитектура доступа

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

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

Как эта логика работает на практике

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

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

Что это меняет для заказчика

В такой модели компрометация подрядчика уже не означает автоматическую компрометацию всего контура заказчика. Сам риск никуда не исчезает, но его последствия становятся изначально ограниченными.

Подрядчик не видит больше, чем требуется для работы. Он не может свободно перемещаться по инфраструктуре. Любое значимое отклонение от нормального сценария либо блокируется, либо становится заметным для контроля.

К какому выводу это подводит

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

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