Право на защиту данных: чек-лист перед регистрацией в SaaS

Ситуация, которую мы проходили не раз

Когда команда впервые открывает страницу регистрации в новом SaaS-сервисе, у ответственного руководителя внутри обычно зреет не столько энтузиазм, сколько тревога: а что если через полгода окажется, что мы доверили клиентскую базу и часть финансовых документов площадке, которая не обеспечивает ни минимального шифрования, ни внятного SLA, ни понятной процедуры выгрузки данных? За последние годы мы провели десятки таких внедрений — от CRM и почтовых сервисов до узконишевых B2B-платформ, — и в каждом проекте болевой точкой становился именно этот момент: переход от переговоров с вендором к фактическому нажатию кнопки «создать аккаунт».

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

Юридический фундамент: на чём стоят ваши права

Любой разговор о безопасности SaaS начинается с понимания того, какие именно права есть у вас как у субъекта персональных данных. Без этого невозможно осмысленно проверить ни политику конфиденциальности, ни DPA, ни условия SLA. В российской практике оператором персональных данных выступает компания, которая определяет цели и состав обработки и собирает данные, а провайдер SaaS часто действует по её поручению — обеспечивает хранение, передачу и обработку информации в рамках согласованных операций.

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

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

Для практической проверки полезно разделять несколько разных ситуаций:

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

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

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

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

Для команды, которая ведёт проекты с зарубежными клиентами, важно помнить: механизмы реализации прав и сроки по GDPR и по 152-ФЗ различаются. Это не два одинаковых списка, которые можно механически свести в одну таблицу, а параллельные режимы с разными требованиями к уведомлениям, основаниям обработки, хранению и трансграничной передаче.

Типичная управленческая ловушка в этом блоке выглядит так: компания подписывает с провайдером DPA (Data Processing Agreement) и считает тему закрытой, не проверив, как именно вендор реагирует на реальные обращения субъектов данных. На этапе внедрения стоит задать прямой вопрос: «Опишите сценарий, при котором субъект персональных данных направляет запрос на удаление: кто принимает заявку, как подтверждается личность, какой срок обработки, каким каналом возвращается подтверждение и что происходит с резервными копиями?»

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

Технические меры защиты: что должен гарантировать провайдер

Юридические права бесполезны без технической реализации — это второй уровень проверки, который обычно занимает больше времени. Прежде чем подписаться на сервис, мы рекомендуем сформулировать для вендора короткий, но конкретный запрос о технических и организационных мерах защиты (Technical and Organizational Measures, TOMs). В ответе должны быть не общие слова про «высокие стандарты безопасности», а описание того, что именно защищается, от каких угроз и кто контролирует выполнение мер.

В базовый набор современного SaaS входят:

• шифрование данных при передаче с использованием TLS версии 1.2 и выше;
• шифрование данных при хранении и понятное описание того, какие хранилища им покрываются;
• многофакторная аутентификация (MFA) как минимум для административных аккаунтов;
• разграничение доступа по ролям и принципу наименьших привилегий;
• журналирование действий администраторов и других чувствительных операций;
• резервное копирование с описанием периодичности, сроков хранения и процедуры восстановления;
• регулярное тестирование восстановления, а не только наличие самих резервных копий;
• процесс управления уязвимостями и обновлениями;
• порядок отзыва доступа сотрудников провайдера после увольнения или смены роли.

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

Отдельного внимания заслуживает архитектура мультиарендности (multi-tenant), в которой работает большинство облачных платформ. Принцип простой: данные разных клиентов должны быть логически изолированы друг от друга, и эта изоляция не должна нарушаться при обычной работе, миграции, формировании отчётов или восстановлении из резервных копий. У провайдера стоит уточнить, на каком уровне реализовано разделение — через идентификаторы арендатора, отдельные схемы, базы или иной механизм, — и как оно проверяется.

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

Ни один сертификат, включая ISO 27001 или SOC 2, не отменяет необходимости собственной проверки: документ подтверждает, что процессы описаны и работают в рамках аудита, но не гарантирует отсутствие ошибок в будущем.

Ответственному за внедрение сотруднику полезно запросить как минимум три группы подтверждений:

1. Актуальное описание мер защиты и, если доступно, отчёт независимого аудита — например, SOC 2 Type II или эквивалентный документ.

2. Краткое описание архитектуры хранения, разделения арендаторов, резервного копирования и восстановления.

3. Перечень регионов размещения дата-центров и сведения о привлечённых субподрядчиках.

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

Анализ SLA и политики конфиденциальности: где скрыты ловушки

Юридический и технический блоки подкрепляются третьим, не менее важным слоем — коммерческим. SLA (Service Level Agreement) отвечает на ключевой для бизнес-процесса вопрос: что произойдёт, если сервис окажется недоступен в критический момент. Для корпоративного SaaS уровень доступности 99,9% может быть разумным ориентиром, но сама цифра ничего не говорит без методики расчёта. Нужно понять, входят ли в неё плановые работы, аварии у инфраструктурного партнёра, деградация отдельных функций и недоступность API.

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

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

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

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

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

На этапе коммерческого согласования полезно держать перед глазами перечень пунктов, которые проверяются по тексту договора:

1. Гарантированный уровень доступности и методика расчёта компенсации за простой.

2. Определение инцидента безопасности и срок уведомления о нём.

3. Перечень субобработчиков и процедура уведомления об их изменении.

4. Условия хранения данных после расторжения договора и процедура возврата.

5. Права на пользовательский контент и лицензионная модель сервиса.

6. Юрисдикция хранения данных и условия трансграничной передачи.

7. Условия проведения аудитов со стороны клиента.

8. Порядок предоставления сведений по запросам субъектов персональных данных.

9. Ответственность сторон при ошибке конфигурации, утечке или нарушении доступности.

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

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

Безопасность коммуникаций: роль SPF, DKIM и DMARC

Если ваш SaaS предполагает отправку писем от имени корпоративного домена — а это касается почти всех CRM, систем автоматизации маркетинга и сервисов рассылок, — без настроенных SPF, DKIM и DMARC под угрозой окажется не только репутация отправителя, но и доверие клиентов к домену.

SPF (Sender Policy Framework) определяет, какие серверы вправе отправлять письма от имени домена. DKIM (DomainKeys Identified Mail) добавляет к сообщению цифровую подпись, которую принимающая сторона проверяет по опубликованному ключу. DMARC (Domain-based Message Authentication, Reporting & Conformance) задаёт политику обработки писем, не прошедших проверки, и позволяет получать отчёты о попытках отправки.

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

Управленческий сценарий внедрения здесь выглядит просто: ИТ-отдел или внешний администратор домена добавляет DNS-записи, согласовывает с вендором способ подписи писем и включает отчётность. До изменения политики нужно составить список всех разрешённых отправителей: CRM, рассылки, службы поддержки, бухгалтерские и транзакционные системы. Иначе команда легко примет случайный сбой за атаку или, наоборот, не заметит, что неизвестный сервис отправляет письма от имени компании.

На этапе тестов мы рекомендуем запускать DMARC в режиме наблюдения (p=none), чтобы собрать данные о легитимной переписке. После проверки источников и исправления ошибок можно переходить к более строгой политике — карантину или отказу. Такой плавный онбординг снижает риск блокировки собственных писем и даёт время отладить процессы без потерь в доставляемости.

При этом SPF, DKIM и DMARC отвечают прежде всего за аутентификацию домена и защиту коммуникаций от подмены. Они не шифруют содержимое письма и не защищают данные внутри самого SaaS. Если CRM отправляет в письмах персональные данные, ссылки на документы или финансовую информацию, отдельно проверяйте настройки доступа, срок действия ссылок и возможность ограничить содержание уведомлений.

Управление жизненным циклом данных: экспорт и право на забвение

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

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

До регистрации стоит получить ответы на несколько вопросов:

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

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

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

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

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

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

Плавное внедрение: как встроить проверку в процесс команды

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

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

• создание и удаление пользователя;
• изменение роли и отзыв доступа;
• экспорт записи вместе с вложениями;
• восстановление после удаления;
• выгрузка журнала действий;
• настройка MFA;
• ограничение доступа к отдельным объектам;
• отправка письма от корпоративного домена;
• реакция поддержки на запрос об инциденте.

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

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

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

Перед регистрацией в SaaS полезно задать себе не вопрос «есть ли у сервиса сертификат», а более неприятный и практичный: «Что произойдёт с данными, если что-то пойдёт не по плану?» Если на него есть конкретный ответ — в договоре, архитектуре, процедуре поддержки и плане выхода, — сервис можно оценивать по эффективности и удобству. Если ответ состоит из маркетинговых обещаний, регистрация ещё не стала внедрением, а проверка только начинается.