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

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

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

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

Почему оператором осталась сеть

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

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

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

Отсюда первое следствие, которое обычно пропускают. Договор создаёт обязанность подрядчика перед сетью, а не перед клиентами сети. Клиент не может прийти к студии и потребовать объяснений, потому что он с ней не договаривался и, скорее всего, впервые слышит её название. Его контрагент — магазин, и именно магазин отвечает за то, что произошло с его данными.

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

Здесь легко возразить: «но мы же не контролировали их сервер». Верно, и никто не требует владеть чужой инфраструктурой. Контроль не означает доступ к каждому файлу подрядчика; он означает, что оператор выбрал этого подрядчика, определил объём доступа и проверил, что требования выполняются. Если этих решений не было, ответственность всё равно остаётся, просто становится неудобной.

Что договор может и чего не может

Типовой договор на услуги описывает предмет, срок, цену и порядок сдачи-приёмки. Данные в нём упоминаются в лучшем случае как «материалы заказчика», а безопасность — общей фразой о соблюдении законодательства. Такой документ позволяет заплатить за работу, но не позволяет управлять риском.

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

Второе — требования к защите. Не «обеспечить безопасность», а какие меры применяются, кто отвечает за доступ, где хранятся данные, что происходит при увольнении сотрудника подрядчика. Третье — порядок действий при инциденте: в какой срок подрядчик сообщает о случившемся, кому именно, какие сведения передаёт. Без этого сеть узнаёт об утечке от клиентов, а не от того, кто первым её заметил.

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

Полезный сигнал появляется ещё до подписания. Подрядчик, который отказывается принимать приложение о защите данных со ссылкой на «у нас всё стандартно», уже дал первый ответ о том, как у него устроена работа. Отказ обсуждать доступы и сроки уведомления говорит о том же, о чём молчание в момент инцидента.

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

Почему требования к защите нельзя свести к одной фразе

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

Сеть должна была определить по постановлению Правительства № 1119 уровень защищённости системы, где хранится клиентская база, и состав мер по приказу ФСТЭК № 21. С 1 сентября 2026 года действует новый приказ, который смещает акцент с формального набора мер на риск-ориентированный подход и оценку зрелости защиты. Из этого и вырастают требования к подрядчику: не «защищайте хорошо», а какие меры применяются, кто их администрирует, как выдаётся доступ, где хранятся журналы, как ставятся обновления.

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

Отдельно стоит про зрелость. Набор мер отвечает на вопрос «что установлено», а зрелость — на вопрос «работает ли это, когда никто не смотрит». Зрелая практика видна по скучным вещам: доступ выдаётся по заявке, обновления ставятся по расписанию, журналы кто-то действительно открывает. Проверить это проще всего вопросом «покажите, как это происходило в прошлом месяце»: политика покажет, что правило существует, а журнал и переписка — что оно работает. У небольшого подрядчика почти всё держится на одном человеке: он знает пароли, он обновляет сайт, он же уходит в отпуск. Это не приговор, но требует компенсации — меньшего объёма данных, короткого срока доступа, ручной проверки того, что нельзя автоматизировать.

Как проверить подрядчика, у которого нет службы безопасности

Проверка подрядчика пугает компании, которым кажется, что для неё нужен отдел из нескольких человек и неделя аудита. На практике речь идёт о разговоре по списку вопросов, на каждый из которых должен найтись ответ, подтверждённый чем-то, кроме слов. Такой разговор занимает меньше времени, чем настройка одной рассылки, и его вполне можно провести до подписания договора.

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

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

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

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

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

Что делать, когда данные уже ушли

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

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

Обязанность уведомить регулятора лежит на операторе. О факте утечки нужно сообщить в течение 24 часов, а результаты внутреннего расследования передать в течение 72 часов. Молчание в этой ситуации считается отдельным нарушением, поэтому ожидание, пока подрядчик «разберётся и всё расскажет», — худшая из возможных тактик.

Отдельно нужно договориться, кто сохраняет доказательства. Журналы подрядчика, история выгрузок и переписка о доступах — это не мелочи для отчёта, а основание для оценки масштаба. Если подрядчик удаляет журналы «для порядка», восстановить картину будет нечем, и сеть останется с догадками вместо фактов.

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

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

Почему «это их зона ответственности» не работает

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

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

Репутационный уровень самый неприятный. Клиент не различает оператора и обработчика, он знает только, что оставлял данные магазину. Для него «мы передали это подрядчику» звучит не как объяснение, а как признание, что внутри компании никто не отвечал за данные.

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

Подрядчику передаётся работа и обязанность отчитываться — но не ответственность. А у оператора остаются выбор подрядчика, объём доступа, требования к защите, проверка и план на случай инцидента. Это не бюрократия, а ровно те решения, которые определяют, случится ли утечка и насколько дорого она обойдётся.

Ответственность не исчезает при передаче обработки — она распределяется. Подрядчик отвечает за то, что делает по поручению; оператор отвечает за то, что поручил, кому поручил и как проверил. Передача обработки — это способ сделать ответственность управляемой, а не выйти из-под неё.

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

Разобраться глубже поможет разбор 152-ФЗ простыми словами — там подробнее про статус оператора и обязанности при инциденте. Реквизиты закона и ссылка на официальный текст есть в карточке. Незнакомые термины, включая оператора и обработчика, разобраны в словаре.