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

Почему проблема начинается с лишнего поля
Компания создаёт форму заявки и просит имя, телефон, дату рождения, город, должность и ссылку на личную страницу. Для первого ответа нужны только контакт и суть вопроса, но остальные поля добавили «вдруг пригодятся».
Позже данные копируются в таблицу, пересылаются в чат и загружаются в несколько сервисов. Никто не может ответить:
- зачем собрали дату рождения;
- кто видит таблицу;
- на каком основании сведения передали подрядчику;
- где человек может отозвать согласие;
- когда копии будут удалены;
- какая версия политики действовала при сборе.
Защита начинается раньше шифрования — с отказа от ненужного сбора.
Что относится к персональным данным
Закон определяет персональные данные через связь с определённым или определяемым физическим лицом. Один и тот же элемент может оцениваться по-разному в зависимости от контекста и возможности идентификации.
В работе бизнеса встречаются:
- контактные данные;
- сведения аккаунта и обращения;
- договорная и платёжная информация;
- данные сотрудника или кандидата;
- технические идентификаторы и история действий;
- фотографии, голос и другие материалы;
- специальные категории и биометрические данные.
Для специальных и биометрических данных действуют дополнительные требования. Не пытайтесь классифицировать чувствительный набор только по общей статье — передайте его специалисту.
Начинайте с цели
Для каждого процесса сформулируйте одну конкретную цель. «Для работы компании» слишком широко. «Ответить на обращение о продукте» или «исполнить договор и вести обязательный учёт» дают возможность проверить состав данных.
Затем задайте вопросы:
- Без какого поля цель не достигается?
- Можно ли получить сведения позже, когда они действительно понадобятся?
- Каково правовое основание обработки?
- Совместима ли новая задача с первоначальной целью?
- Что произойдёт после достижения цели?
Если команда хочет использовать контакт из поддержки для рекламной рассылки, это уже отдельная цель и отдельная правовая проверка.
Практический инструмент: реестр жизненного цикла
| Поле реестра | Что записать |
|---|---|
| Процесс | где возникают данные |
| Цель | зачем они нужны |
| Категории людей | клиент, сотрудник, партнёр |
| Состав | конкретные поля |
| Основание | закон, договор, согласие или другое |
| Источник | откуда получены |
| Действия | сбор, хранение, использование, передача |
| Доступ | роли, которым это необходимо |
| Системы и получатели | где обрабатываются |
| Срок | событие или дата прекращения |
| Удаление | кто и как подтверждает |
| Владелец | ответственный за процесс |
Реестр не должен содержать сами персональные данные. Он описывает правила их обработки.
Минимизация и раздельное хранение
Минимизация означает, что состав соответствует заявленной цели и не является избыточным. Если для отправки ответа достаточно адреса электронной почты, необязательно одновременно требовать паспорт.
Роскомнадзор рекомендует разделять категории персональных данных, а также, где это уместно, хранить идентифицирующие сведения отдельно от истории взаимодействия. Связь можно организовать через внутренний идентификатор с отдельной защитой.
Практический эффект:
- меньше людей видят прямые идентификаторы;
- копии легче находить и удалять;
- утечка одного набора не всегда раскрывает весь контекст;
- права доступа проще объяснить и проверить.
Конкретную архитектуру выбирают специалисты по безопасности и персональным данным.
Доступ по роли, а не по привычке
Сотрудник должен видеть только те сведения и действия, которые нужны для его задачи. Менеджеру может понадобиться контакт клиента, но не все документы. Автору статьи нужен обезличенный вопрос, а не имя автора обращения. Подрядчику передают только согласованный объём.
Для каждой роли определите:
- какие поля доступны;
- можно ли выгружать и передавать;
- какие действия записываются;
- кто выдаёт и отзывает право;
- что происходит при смене роли или увольнении;
- как проверяется использование общего доступа.
Общие учётные записи размывают ответственность. Если невозможно восстановить, кто открыл или изменил данные, журнал теряет ценность.
Срок хранения должен завершаться событием
Фраза «храним бессрочно» редко отражает реальную цель. Срок может зависеть от исполнения договора, обязательного периода хранения, окончания спора, отзыва согласия или другого события.
Для каждого набора укажите:
- что запускает срок;
- что его завершает;
- есть ли законное основание продолжать хранение;
- где находятся копии и резервные версии;
- кто подтверждает удаление или обезличивание.
Удаление из основной таблицы не гарантирует исчезновения из выгрузки, личной переписки или резервной копии. Карта систем должна охватывать все фактические места.
Условный пример: заявка превратилась в пять копий
Допустим, клиент оставил имя, телефон и вопрос. Данные поступили в систему обращений. Сотрудник выгрузил строку в таблицу, переслал её в чат и создал задачу подрядчику.
После закрытия обращения основная запись обрабатывается по установленному сроку, но три копии остаются. Реестр выявляет лишние маршруты. Команда меняет процесс: подрядчик получает обезличенное задание, таблица больше не нужна, а в чате передаётся ссылка с ограниченным доступом.
Это условный пример. Правовое основание, сроки и допустимость конкретной передачи определяются специалистом.
Что делать при новом сервисе или подключении
До передачи данных задайте поставщику и внутренней команде вопросы:
- какие сведения необходимы;
- где и кем они обрабатываются;
- есть ли поручение обработки и договорные условия;
- как ограничивается доступ;
- как выполняются запросы человека;
- как сообщается об инциденте;
- как данные возвращаются или удаляются;
- можно ли работать с обезличенным набором.
Не перечисляйте подключения в статье как вечный список. Состав сервисов и условия меняются; актуальную архитектуру нужно проверять перед запуском.
Как Наставница АТС Офис помогает соблюдать утверждённые правила
Наставница АТС Офис может использовать утверждённую базу знаний, чтобы сотрудники получали одинаковый справочный маршрут: какие данные допустимо запросить, где находится форма, кому передать нестандартный случай и когда нельзя отвечать самостоятельно.
Полезный сценарий:
- владелец и специалист утверждают правила;
- документы загружаются с версиями и ролями доступа;
- сотрудник задаёт рабочий вопрос;
- Наставница отвечает только по доступной базе;
- отсутствие основания или конфликт отправляются человеку;
- новые повторяющиеся вопросы становятся пробелами базы;
- после изменения правила старая версия перестаёт использоваться.
Наставница не определяет законность обработки и не заменяет юриста. Она помогает применять уже подтверждённые инструкции последовательно и не искать их в старых переписках.
Как проверить процесс
Выберите один путь — например, форму обратной связи — и пройдите его от ввода до удаления.
Попросите показать:
- текст уведомления и основание;
- запись о цели и составе;
- все системы и получателей;
- роли доступа;
- срок;
- способ обработки запроса человека;
- подтверждение удаления тестовой записи.
Проверяйте фактический маршрут, а не только политику на сайте. Если документ говорит одно, а данные копируются иначе, исправлять нужно процесс.
Что можно сделать сегодня
Откройте самую длинную форму компании. Для каждого поля допишите цель и владельца. Поле без ясной необходимости временно пометьте для правовой проверки.
Не удаляйте действующие данные без утверждённого порядка. Сейчас задача — увидеть избыточный сбор и назначить решение.
Что в итоге
Персональные данные требуют управляемого жизненного цикла. Компания должна понимать, зачем собирает каждое поле, на каком основании, кто его видит, куда оно передаётся и когда удаляется.
Минимизация снижает риск раньше технических мер. Ролевой доступ и журнал действий делают процесс проверяемым. База знаний помогает сотрудникам следовать утверждённым правилам, но правовые решения и чувствительные случаи остаются у человека.
Частые вопросы
Это сведения, по которым человека можно установить прямо либо в сочетании с другой доступной информацией.
Обычно они могут относиться к человеку, но конкретная оценка зависит от контекста обработки и должна учитывать закон.
Нет, закон предусматривает разные основания. Выбор основания для конкретной цели следует подтвердить со специалистом.
Состав должен соответствовать заявленной цели и не быть избыточным. Неопределённая будущая польза — слабое обоснование.
Не дольше, чем требует цель или применимое законное основание. Срок и событие удаления фиксируются заранее.
Только в допустимых границах и при необходимых правовых, договорных и технических мерах.
Только в разрешённом контуре с минимизацией, доступами и контролем. Чувствительные данные нельзя отправлять произвольно.
Остановить автоматическое действие, сохранить контекст без лишнего распространения и передать вопрос ответственному специалисту.
Познакомьтесь с офисами АТС Офис
Готовые ИИ-офисы для контента, клиентов, аналитики и продаж — под контролем владельца.


