Короткий ответ: ресторан не обязан удалять данные гостя мгновенно и целиком по одному письму. Сначала запрос нужно проверить (кто просит и о каких данных), затем сверить его с действующими целями обработки — незакрытый счёт, будущая бронь, обязательные записи учёта — и только после этого вносить изменения во все системы, где данные хранятся: CRM, система бронирования, программа лояльности, рассылки, резервные копии. Процесс должен быть письменно зафиксирован и повторяем, а не решаться каждый раз "на глаз".
Почему это не разовая задача, а процесс
Данные одного гостя в ресторане редко лежат в одном месте. Имя, номер телефона и история визитов могут одновременно храниться в системе онлайн-бронирования, в POS-терминале, в CRM для рассылок, в таблице для программы лояльности и в переписке с менеджером зала. Когда гость просит удалить свои данные, ответ "мы всё удалили" без проверки каждой системы обычно означает, что что-то осталось — в экспортированном файле, в резервной копии или в закрытой брони прошлого месяца.
Именно поэтому имеет смысл описать не разовое действие, а повторяемый рабочий процесс с чёткими шагами, ответственными и сроками. Это снижает риск как избыточного хранения данных, так и случайного удаления записей, которые ресторан обязан хранить по другим причинам — например, для налогового учёта.
Принципы, на которые стоит опираться
Европейская комиссия описывает несколько принципов защиты данных, два из которых напрямую касаются работы с бронями и профилями гостей:
- Ограничение цели. Персональные данные собираются и используются только для той цели, которая была заявлена при сборе. Если гость оставил телефон для подтверждения брони, это не автоматическое согласие на маркетинговые рассылки — для них, как правило, нужно отдельное основание.
- Ограничение хранения. Данные не должны храниться дольше, чем необходимо для цели их сбора. Это не значит "удалить через 30 дней" для всех подряд — срок зависит от конкретной цели, применимого законодательства и правил учёта, действующих в конкретной стране и сегменте бизнеса.
Оба принципа сформулированы общими словами именно потому, что применимый срок и объём хранения различаются в зависимости от юрисдикции, типа данных и назначения. Это не пошаговая инструкция для ресторана — это ориентир, который нужно перевести в конкретный внутренний регламент вместе с юристом.
Протокол ПУД: Проверка — Удержание — Действие
Ниже — практический каркас, который можно адаптировать под размер ресторана и используемые системы. Он не заменяет юридическую консультацию, но задаёт последовательность, которую легко воспроизвести любому сотруднику, отвечающему за такие запросы.
Шаг 1. Приём и проверка запроса
- Зафиксировать дату получения запроса и способ обращения (email, форма на сайте, устно в зале).
- Убедиться, что запрос действительно исходит от самого гостя или его уполномоченного представителя — например, подтвердить через тот же email или телефон, что указаны в профиле.
- Уточнить у гостя, о каком именно объёме данных идёт речь: полное удаление профиля или, например, только отписка от рассылок.
Шаг 2. Проверка оснований для удержания данных
- Проверить, есть ли у гостя незакрытые обязательства — неоплаченный счёт, открытый депозит, предстоящая бронь.
- Проверить, подпадают ли какие-либо записи под обязательные сроки хранения (бухгалтерские документы, данные для налоговой отчётности, записи, связанные с безопасностью питания, если применимо в конкретной юрисдикции).
- При наличии сомнений — направить конкретный кейс на согласование юристу или ответственному за защиту данных, а не принимать решение самостоятельно.
Шаг 3. Действие во всех системах
- Составить список всех мест хранения данных гостя: система бронирования, CRM, POS, платформа рассылок, программа лояльности, файлы экспорта, резервные копии.
- Удалить или анонимизировать данные в каждой системе по отдельности, отмечая дату и ответственного за каждое действие.
- Сохранить минимальную запись о самом факте обработки запроса (без содержания удалённых данных) — это нужно, чтобы подтвердить исполнение, если вопрос возникнет повторно.
- Сообщить гостю о результате: что удалено полностью, что сохранено и на каком основании, в какой срок.
Ограничения этого протокола. Он описывает организационную последовательность действий, а не юридическое заключение. Конкретные сроки ответа, перечень обязательных исключений и форма уведомления гостя зависят от применимого законодательства в стране работы ресторана и должны быть согласованы с юристом до внедрения процесса в постоянную практику.
Явные исключения, которые нужно проверять каждый раз
Прежде чем закрывать запрос как выполненный, стоит убедиться, что ни одно из следующих оснований не применимо к конкретному гостю:
| Ситуация | Что это может означать для запроса |
|---|---|
| Неоплаченный счёт или спорный платёж | Данные, связанные с транзакцией, могут требовать сохранения до разрешения спора или по правилам финансового учёта |
| Предстоящая или незавершённая бронь | Цель обработки ещё не исчерпана — удаление может помешать выполнить саму бронь |
| Обязательные записи по бухгалтерии или налогам | Срок хранения может быть установлен национальным законодательством, а не решением ресторана |
| Данные в резервных копиях | Полное немедленное удаление из бэкапов технически может быть невозможно — стоит зафиксировать реальный срок ротации копий |
Каждую из этих ситуаций стоит рассматривать индивидуально, а не как общее правило "мы никогда не удаляем данные, если есть хоть один открытый счёт". Общий подход к исключениям должен быть закреплён во внутреннем регламенте и проверен юристом.
Как измерять, что процесс работает
Чтобы протокол не оставался только документом на бумаге, стоит отслеживать несколько операционных показателей — без привязки к каким-либо внешним нормативам, которые не заявлены явно в вашей юрисдикции:
- Количество полученных запросов на удаление за период и способ их поступления (форма, email, устно).
- Среднее время от получения запроса до финального ответа гостю.
- Доля запросов, закрытых во всех системах хранения данных (а не только в одной из них, например, в CRM без учёта системы бронирования).
- Количество случаев, когда запрос был частично отклонён из-за законных оснований для хранения, и было ли это зафиксировано письменно.
Эти метрики полезны не для сравнения с "рынком" — данных о типичных сроках или объёмах по индустрии здесь не приводится, — а для внутреннего контроля: видно ли, что процесс замедляется, теряются ли запросы между системами, и достаточно ли обучен персонал, принимающий такие обращения.
Где здесь может быть полезен ChefNet
ChefNet разрабатывает продукты для ресторанного поиска и операционной работы, в том числе связанные с бронированием и профилями гостей. Если ресторан использует или рассматривает такие инструменты, стоит уточнять у поставщика — включая ChefNet — какие именно функции для обработки запросов на удаление данных, экспорта профиля или разграничения доступа к записям о бронировании реально доступны на текущий момент, поскольку возможности продуктов меняются и не все из них можно считать само собой разумеющимися без прямой проверки в актуальной документации или у службы поддержки.
Внедрение: кто отвечает и что фиксируется
Назначение ответственного
Прежде чем протокол ПУД заработает на практике, стоит закрепить письменно, кто в ресторане принимает такие запросы первым — администратор зала, менеджер или отдельный контакт для обращений по данным — и кто выступает резервным исполнителем на случай отпуска или увольнения основного ответственного. Без явного назначения запрос легко потеряется между сменами.
Журнал запросов
Помимо действий по каждому конкретному гостю, полезно вести отдельный внутренний журнал всех поступивших запросов на удаление — с датой поступления, способом обращения и статусом ("в проверке", "частично исполнен", "закрыт"). Такой журнал отличается от записи о самом факте обработки конкретного запроса (упомянутой в шаге 3 протокола): он нужен не для подтверждения перед гостем, а для внутреннего контроля нагрузки и сроков.
Пограничные случаи, которые стоит явно прописать в регламенте
| Ситуация | Что важно уточнить перед действием |
|---|---|
| Запрос поступил не от самого гостя, а от родственника или знакомого, оформлявшего бронь | Есть ли у обратившегося полномочия действовать от имени гостя; при сомнении — запросить подтверждение у самого гостя напрямую |
| Гость — участник программы лояльности с накопленными баллами или бонусами | Удаление профиля может затрагивать не только персональные данные, но и учётные записи бонусной системы — стоит уточнить у гостя, понимает ли он это последствие |
| Данные гостя входят в групповую бронь (банкет, корпоратив) | Удаление записи одного участника не должно ломать бронь остальных — потребуется выделить и обработать только относящиеся к нему поля |
| Данные переданы внешнему подрядчику (платформа рассылок, агрегатор бронирования) | Ресторан может не иметь прямого технического доступа к удалению у подрядчика — нужен отдельный запрос к этому подрядчику, и срок его исполнения может отличаться от внутреннего |
| Сеть из нескольких точек с общей CRM | Проверить, реплицируются ли данные гостя в системы других точек сети, и включить это в список мест хранения из шага 3 |
Каждый из этих случаев требует индивидуального решения, а не автоматического применения общего правила — сомнительные ситуации, как и в основном протоколе, лучше направлять на согласование юристу или ответственному за защиту данных.
Чек-лист внутренних сроков (для контроля, не как юридическая норма)
| Этап | Целевой внутренний срок | Комментарий |
|---|---|---|
| Подтверждение получения запроса гостю | Устанавливается внутренним регламентом ресторана | Не описывается в источнике как обязательный юридический срок — это операционный ориентир, который ресторан задаёт сам |
| Проверка личности обратившегося | До начала работы с самими данными | Без подтверждения личности действие не начинается |
| Проверка оснований для удержания (шаг 2 протокола) | До удаления в любой системе | Пропуск этого шага — основная причина случайного удаления данных, которые нужно было сохранить |
| Финальный ответ гостю с результатом | Фиксируется внутренним регламентом | Точный обязательный срок ответа зависит от применимого законодательства и должен быть согласован с юристом отдельно |
Что этот процесс не решает
Протокол описывает организационную последовательность внутри ресторана, но не отвечает на несколько вопросов, которые выходят за его рамки: какой именно юридический срок ответа применим в конкретной стране, как передавать запрос сторонним обработчикам данных (платформам рассылок, агрегаторам бронирования, платёжным провайдерам) и как технически подтвердить полное удаление из резервных копий с учётом их цикла ротации. Эти вопросы требуют либо отдельной юридической консультации, либо уточнения у конкретного поставщика систем, которые использует ресторан.
Первичные источники
FAQ
Обязан ли ресторан удалить данные гостя сразу после запроса?
Не всегда сразу и не всегда полностью. Часть данных может быть привязана к незакрытой цели — например, неоплаченному счёту или предстоящей брони, а требования к финансовому или бухгалтерскому учёту могут обязывать хранить отдельные записи определённый срок. Прежде чем закрывать запрос, оператору стоит уточнить исключения у юриста.
Что означает принцип ограничения цели применительно к записи о брони?
Согласно принципам защиты данных Европейской комиссии, персональные данные должны собираться и использоваться только для той конкретной цели, ради которой они были получены. Для записи о брони эта цель — как правило, организация визита гостя, а не бессрочное использование данных в маркетинге, если гость отдельно не согласился на это.
Сколько ресторан может хранить историю бронирований удалённого гостя?
Принципы Европейской комиссии описывают ограничение хранения как требование не держать персональные данные дольше, чем это необходимо для цели их сбора, но не устанавливают единый срок для всех ресторанов. Конкретный срок зависит от цели обработки, применимого национального законодательства и правил учёта (финансового или санитарного), поэтому точные сроки нужно уточнять с юристом.
Редакционное раскрытие: ChefNet публикует это руководство и разрабатывает продукты для поиска ресторанов и ресторанных операций. Общие рекомендации отделены от заявлений о продукте. Возможности могут меняться по мере развития пилотных проектов. Опубликовано 2026-08-12.