Персональные данные в ресторане: где бизнес собирает их незаметно и как не потерять деньги

Ресторанный бизнес редко воспринимает персональные данные как одну из своих ключевых зон риска.

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

Но современный ресторан — это уже не только зал, кухня и касса.

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

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

На совместном вебинаре юридической компании "Зарцын и партнеры"  и платформы для обучения ресторанных команд Service Guru  мы разобрали основные зоны риска и способы привести процессы в порядок без разрушения клиентского пути.

Если вы хотите разобраться с ПДн в вашем ресторане или компании - напишите нам.

Где ресторан получает персональные данные

Самый очевидный пример — форма бронирования столика.

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

Данные могут появляться при:

1. заказе доставки;

1. регистрации в программе лояльности;

1. выпуске виртуальной карты;

1. подключении к гостевому Wi-Fi;

1. подписке на новости и акции;

1. общении с рестораном через мессенджеры;

1. оформлении заказа в мобильном приложении;

1. обращении в службу поддержки;

1. участии в розыгрыше;

1. заполнении анкеты гостя;

1. использовании чат-бота.

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

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

Маркетолог подключил рассылку. Управляющий выбрал сервис бронирования. HR начал пользоваться новой системой обучения. IT-подрядчик добавил аналитику. Бухгалтерия перенесла документы в облачное хранилище.

Никто при этом не видит единой картины движения данных.

Почему политика на сайте не решает задачу

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

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

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

1. в CRM;

1. сервис рассылок;

1. систему аналитики;

1. программу лояльности;

1. внешний колл-центр;

1. облачное хранилище;

1. сервис доставки.

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

Внешний контур — то, что видит гость:

1. политика обработки персональных данных;
2. формы сбора информации;
3. согласия;
4. cookie-уведомления;
5. оферта или пользовательское соглашение;
6. правила программы лояльности.

Внутренний контур — то, что происходит внутри бизнеса:

1. перечень информационных систем;
2. права доступа сотрудников;
3. работа подрядчиков;
4. хранение и удаление данных;
5. внутренние регламенты;
6. действия при обращении гостя;
7. порядок реагирования на утечку.

Проверка только сайта не позволяет увидеть все риски. Но именно с сайта удобно начать самодиагностику.

Не каждое действие гостя требует отдельной галочки

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

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

Но законная обработка данных не всегда требует отдельного чек-бокса.

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

Иная ситуация — рекламная рассылка.

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

Практическая задача состоит не в том, чтобы поставить максимальное количество галочек, а в том, чтобы разделить цели:

1. какие данные необходимы для оказания услуги;

1. какие используются для работы программы лояльности;

1. какие нужны для аналитики;

1. какие собираются для маркетинга;

1. какие передаются партнерам.

После этого часть процессов можно обосновать договором, а для остальных настроить отдельные согласия.

Три опасных сценария сбора данных

Автоматически проставленная галочка

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

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

Купленная или полученная от партнера база

Сам факт получения контактов не дает права использовать их для рекламы.

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

Скрытая аналитика

Сайт может собирать cookie, сведения об устройстве, браузере, поведении пользователя и источнике перехода.

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

Формула «мы собираем только телефон» нередко не соответствует действительности: одновременно сайт автоматически фиксирует намного больше сведений.

Главное — не только получить согласие, но и сохранить доказательство

При споре недостаточно сказать, что на сайте была галочка.

Ресторан должен иметь возможность подтвердить:

1. кто совершил действие;

1. когда оно было совершено;

1. из какой точки сбора поступили данные;

1. какую версию согласия видел пользователь;

1. с какой политикой или офертой он ознакомился;

1. какой IP-адрес и устройство использовались.

Для этого применяется логирование.

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

Другой вариант — подтверждение через код, направленный по номеру телефона или электронной почте.

Такой механизм решает сразу несколько задач:

1. подтверждает контакт;

1. фиксирует действие пользователя;

1. упрощает восстановление аккаунта;

1. помогает доказать оформление заказа или бронирования;

1. снижает риск спора о том, кто совершил действие.

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

Программа лояльности — отдельная зона риска

Программа лояльности редко работает внутри самого ресторана.

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

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

Внешняя платформа получает данные для оказания ресторану технической услуги и выступает обработчиком.

Это означает, что ресторану нужно:

1. указать сервис в своих документах;

1. определить законное основание передачи данных;

1. заключить с подрядчиком поручение на обработку;

1. проверить условия хранения и защиты информации;

1. установить порядок действий при инциденте.

Фраза подрядчика «мы данные не видим» не отменяет обработки.

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

Кому ресторан фактически передает данные

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

В контур могут входить:

1. сервисы бронирования;

1. агрегаторы доставки;

1. CRM;

1. платформы лояльности;

1. сервисы email- и SMS-рассылок;

1. колл-центры;

1. внешняя бухгалтерия;

1. кадровые сервисы;

1. системы обучения персонала;

1. облачные хранилища;

1. хостинг-провайдеры;

1. разработчики и техническая поддержка;

1. сервисы аналитики;

1. операторы чаевых;

1. чат-боты и мессенджеры.

По каждому подрядчику нужно понять его роль.

Он самостоятельно определяет, зачем использует данные? Или только выполняет поручение ресторана? Может ли привлекать других поставщиков? Где находятся серверы? Как сообщает об инциденте? Что происходит с данными после прекращения договора?

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

Почему ответственность нельзя полностью переложить на сервис

Собственники часто считают: если данные находятся в приложении или системе подрядчика, отвечать за их безопасность должен разработчик сервиса.

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

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

В нем важно определить:

1. цели и перечень операций с данными;

1. требования к безопасности;

1. порядок привлечения субподрядчиков;

1. сроки уведомления об инциденте;

1. помощь при запросах пользователей;

1. возврат или удаление информации;

1. ответственность сторон.

Отказ подписывать поручение на обработку не защищает ресторан. Наоборот, при утечке бизнесу будет сложнее доказать, что подрядчик принял на себя обязанности по обеспечению безопасности.

Локализация: где физически хранятся данные

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

Необходимо проверять:

1. с каким юридическим лицом заключен договор;

1. где происходит первичный сбор данных;

1. где расположена основная база;

1. куда направляются резервные копии;

1. используется ли иностранная аналитика;

1. есть ли трансграничная передача;

1. какие сторонние сервисы подключил подрядчик.

Риск может возникнуть не только из-за основной CRM.

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

Поэтому вопрос «где находится сервер?» нужно задавать не только своему IT-специалисту, но и каждому значимому поставщику.

Утечка может произойти не в ресторане

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

Для гостя это все равно будет утечка из конкретного ресторана или сети: именно этому бренду он передавал номер телефона, адрес и сведения о заказах.

С этого момента начинается проверка всей цепочки:

1. как ресторан собирал данные;

1. были ли законные основания;

1. кому они передавались;

1. был ли оформлен договор;

1. какие требования предъявлялись к безопасности;

1. как компания отреагировала на инцидент.

Поэтому комплаенс нужен не только для плановой проверки. Его реальная ценность проявляется в момент утечки.

Что делать при утечке

Главная ошибка — начинать разрабатывать порядок реагирования после обнаружения инцидента.

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

К этому моменту у компании уже должны быть:

1. ответственный за координацию;

1. шаблоны уведомлений;

1. перечень систем и подрядчиков;

1. контакты технических специалистов;

1. регламент внутреннего расследования;

1. порядок фиксации обстоятельств;

1. процедура рассмотрения обращений гостей;

1. заранее распределенные роли между подразделениями.

Не менее важно обучить сотрудников.

Жалоба на утечку может поступить не генеральному директору или юристу, а на общий адрес ресторана, в службу поддержки, отдел продаж или сообщения социальной сети.

Если сотрудник не понимает важность обращения, письмо может пролежать без ответа несколько дней или недель.

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

Как уменьшить риски без лишней бюрократии

Первый принцип — минимизация.

Если для бронирования достаточно имени и телефона, не нужно собирать дату рождения, фамилию и электронную почту «на будущее».

Чем меньше данных получает ресторан, тем:

1. проще объяснить цель обработки;

1. меньше документов требуется;

1. ниже последствия утечки;

1. легче поддерживать информацию в актуальном состоянии;

1. проще отвечать на запросы гостей.

Второй принцип — сокращение точек сбора.

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

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

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

Пятый — инвентаризация подрядчиков. Нельзя управлять передачей данных, не понимая, кто их получает.

Чек-лист для собственника ресторана

Начать можно с десяти вопросов:

1. Какие данные мы собираем у гостей и сотрудников?

1. В каких точках они поступают в компанию?

1. Для какой цели нужен каждый вид информации?

1. Где данные хранятся?

1. Какие сервисы и подрядчики получают доступ?

1. Оформлена ли передача данных этим компаниям?

1. Можем ли мы доказать получение согласия?

1. Нужны ли нам все данные, которые мы сейчас собираем?

1. Что сделает сотрудник, если гость сообщит об утечке?

1. Кто координирует действия компании при инциденте?

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

Главный вывод

Персональные данные в ресторане — это не только согласие под формой бронирования.

Это вся цепочка взаимодействия с гостем: от первого посещения сайта до доставки, программы лояльности, рассылки и хранения истории заказов.

Задача собственника — не превратиться в специалиста по персональным данным. Но он должен видеть карту процессов и понимать, где компания может потерять деньги.

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

Юридическая компания  "Зарцын и партнеры" совместно с Service Guru  провела вебинар о работе ресторанов с персональными данными. Эксперты разобрали сайты, доставку, программы лояльности, рекламные рассылки, подрядчиков и порядок действий при утечке.