«Многие думают, что задача защитить персональные данные ложится на плечи айтишника. Но когда регулятор стучится в дверь, одних технических аргументов недостаточно. Вам придётся доказывать свою правоту языком, который понимают юристы, — языком документов. Расскажу, как это сделать.»
Кто виноват? Главный вопрос регулятора и как на него ответить
Любое расследование начинается с вопроса: кто является оператором персональных данных и, следовательно, несёт ответственность за их безопасность? В российском правовом поле это ключевой момент. Если утечка произошла в системе, которой вы не управляли, но ваши данные в ней оказались, — вы не автоматически становитесь виновным.
Регулятор (ФСТЭК, Роскомнадзор) запрашивает объяснения у организации, на которую указывают первичные данные об утечке. Например, если в утекшей базе найден ваш корпоративный email, расследование начнётся с вашей компании. Ваша задача — не начать оправдываться, а доказать, что вы не были оператором данных для этой конкретной базы.
Для этого нужно определить круг ваших обязанностей. Если вы не заключали договор на обработку данных с фигурантами утечки, не собирали эти данные через свои формы и не хранили их в своих системах, вы находитесь в сильной позиции. Но позицию нужно подтвердить.
Первый документ: Инвентаризация информационных активов
Это не просто список серверов. Инвентаризация, это официально утверждённый и регулярно актуализируемый реестр всех систем, где обрабатываются персональные данные. Именно он становится вашей первой линией обороны.
Когда приходит запрос, вы не тратите недели на сбор информации. Вы открываете актуальный документ и проверяете: фигурирует ли в нём система, из которой произошла утечка? Если её там нет, это прямое свидетельство того, что данные в ней не обрабатывались под вашим управлением.
Что должно быть в инвентаризации для целей доказывания:
- Название и описание системы. Не просто «CRM», а «CRM-система «МегаПлан», версия X.Y, используемая отделом продаж для ведения клиентской базы».
- Класс защищённости (КЗ). Определённый по модели угроз и 152-ФЗ. Демонстрирует, что вы провели оценку рисков для этой системы.
- Модель угроз. Ссылка на утверждённую модель угроз для этой системы. Показывает, что вы понимали риски и выстроили защиту.
- Список ответственных лиц. Кто из сотрудников отвечает за администрирование и безопасность этой конкретной системы.
- Журнал изменений. Когда система была внесена в реестр, когда последний раз проверялась. Это доказывает актуальность данных.
Такой документ, это не формальность, а материальное доказательство системного подхода. Он переводит спор из области предположений («мы вроде бы этого не используем») в область фактов («эта система отсутствует в нашем утверждённом реестре активов от такого-то числа»).
Второй документ: Договор оказания услуг или акт передачи данных
Если данные утекли не из вашей системы, а из системы вашего подрядчика или партнёра, ключевым становится документ, регулирующий эти отношения. Вы должны были передать ему данные для обработки на законных основаниях.
В таком случае вы выступаете как оператор, передавший данные другому оператору. Согласно 152-ФЗ, это разрешено при соблюдении определённых условий, главное из которых — договор, где прямо указана цель передачи и зафиксирована обязанность принимающей стороны обеспечить безопасность данных.
Что должно быть в документе для защиты:
- Чёткое указание на передачу ПДн. В договоре или дополнительном соглашении должен быть пункт, где сказано, что одна сторона передаёт, а другая принимает на обработку определённый объём персональных данных.
- Цель обработки. Например, «для проведения рассылки уведомлений клиентам» или «для интеграции систем лояльности».
- Ссылка на обязанность соблюдать 152-ФЗ. Прямая формулировка о том, что принимающая сторона обязуется обеспечить защиту переданных данных в соответствии с требованиями российского законодательства.
- Акт передачи. Если данные передавались физически (файлом) или логически (набором API-ключей), должен быть подписанный акт с перечнем переданных данных. Это доказывает, что на момент передачи данные находились у вас в сохранности, и вы передали их легально.
Этот документ переводит стрелки ответственности. Вы показываете регулятору, что действовали в правовом поле, передали данные контрагенту, который, в свою очередь, взял на себя обязательства по их защите. Утечка произошла уже на его стороне.
Третий документ: Акт проверки или аудита системы безопасности
Это самый сильный, но и самый редкий козырь. Предположим, утечка произошла в системе, которую вы используете, но не администрируете напрямую (например, облачный сервис). Как доказать, что вы приняли все зависящие от вас меры?
Ответ — результаты независимой проверки. Если вы регулярно (хотя бы раз в год) проводите аудит безопасности своих ключевых систем, включая проверку подрядчиков, у вас на руках оказывается экспертное заключение.
Что даёт такой акт:
- Фиксация состояния на момент проверки. Акт фиксирует, что на определённую дату система контрагента соответствовала заявленным требованиям безопасности (или выявил нарушения, которые были устранены).
- Доказательство due diligence. Вы демонстрируете, что не просто доверились подрядчику, а проявили должную осмотрительность: проверили его.
- Смягчающее обстоятельство. Даже если утечка произошла, вы можете аргументировать, что сделали всё разумное для её предотвращения, основываясь на позитивном заключении аудиторов.
В акте важно наличие подписей как вашего представителя, так и представителя проверяемой организации, а также перечень проверенных мер (настройка МФД, шифрование, разграничение доступа и т.д.).
Собираем доказательную базу: практические шаги
Когда приходит письмо от регулятора, время на подготовку ограничено. Действовать нужно быстро и системно.
- Немедленно изолируйте инцидент. Убедитесь, что утечка остановлена в вашей экосистеме. Это покажет вашу оперативную реакцию.
- Соберите рабочую группу. В неё должны войти юрист, ответственный за compliance, системный администратор и руководитель направления, чьи данные могли быть затронуты.
- Запросите полную информацию об утечке. Узнайте точное название сервиса/базы данных, примеры утекших данных, дату обнаружения инцидента. Без этого вы не сможете соотнести инцидент со своими активами.
- Сопоставьте с инвентаризацией. Проверьте, есть ли система-источник в вашем реестре. Если нет — готовьте выписку из этого реестра как Приложение 1 к вашему ответу.
- Найдите договорную базу. Если система принадлежит контрагенту, найдите все договоры, допсоглашения и акты приёма-передачи данных, связанные с этим контрагентом. Подготовьте их копии (Приложение 2).
- Привлеките аудиторские отчёты. Если проводили проверку безопасности этого контрагента, найдите последний акт (Приложение 3).
- Составьте официальное письмо-ответ. Структура ответа должна быть ясной: факты (что произошло), ваши выводы (на основании каких документов вы установили непричастность), приложения (те самые три документа). Избегайте технического жаргона, пишите на языке, понятном проверяющему.
Что нельзя делать ни в коем случае
Некоторые действия могут свести на всю вашу доказательную базу или усугубить ситуацию.
- Игнорировать запрос или затягивать ответ. Это трактуется как препятствование проведению проверки.
- Удалять или вносить правки в документы постфактум. Даты создания и подписания легко проверяются. Фальсификация — прямой путь к дисквалификации всех ваших доказательств и серьёзным штрафам.
- Придумывать несуществующие документы. Если у вас нет акта аудита, не нужно его сочинять. Лучше сделать ставку на первые два документа и честно указать, что проверка не проводилась.
- Обвинять контрагента в открытой переписке с регулятором. Формулируйте позицию через факты: «Данные были переданы на основании договора №…, в котором контрагент принял на себя обязательства по обеспечению безопасности. Соответственно, инцидент произошёл в зоне его ответственности».
- Предоставлять неполные или нечитаемые копии. Все приложения должны быть четко отсканированы, с видимыми подписями и печатями.
Вывод: документация, это не бюрократия, это страховка
В эпоху постоянных утечек наличие чёткой, актуальной и юридически грамотной документации перестаёт быть формальным требованием стандартов. Это практический инструмент, который защищает вашу организацию от финансовых и репутационных потерь.
Три описанных документа работают как единая система. Инвентаризация доказывает, что у вас есть контроль над своими активами. Договор показывает, что вы действовали законно. Акт аудита подтверждает вашу осмотрительность. Вместе они создают неразрывную цепочку доказательств вашей добросовестности.
Начинать строить эту защиту нужно не когда пришло письмо из Роскомнадзора, а сейчас. Проверьте, есть ли у вас утверждённая инвентаризация. Приведите в порядок договоры с подрядчиками на обработку данных. Запланируйте внутренний аудит ключевых систем. В следующий раз, когда в сети появится очередная «слитая база», вы будете спокойны — ваши документы уже готовы.