Интранет и защита персональных данных: на что смотреть в данных сотрудников

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

Эта статья носит общий характер; по обязанностям, специфичным для вашей компании, обратитесь к своим юристам.

Начните с минимизации

Самая надёжная стратегия комплаенса — данные, которые вы не обрабатываете. Вопрос при внедрении простой: действительно ли нужно это поле? Если дата рождения нужна для поздравлений, достаточно дня и месяца без года. Личный мобильный номер не следует собирать, пока есть корпоративная линия.

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

Уведомления и версионирование

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

Запросы субъектов данных

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

Права доступа: спрятать недостаточно

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

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

Процессы, требующие анонимности

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

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

Сроки хранения и увольнение

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

Хостинг и субобработчики

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

Доказуемость: журнал аудита

Чаще всего упускают то измерение комплаенса, которое связано с доказуемостью работы. При проверке недостаточно сказать «мы опубликовали уведомление»; нужно показать, кто какую версию видел и когда, когда пришло обращение и за сколько дней на него ответили.

Поэтому важен охват журнала: изменения прав, доступ к чувствительным данным, выгрузки с персональными данными и удаления должны как минимум записываться. От самого журнала ожидается, что изменения в нём заметны; журнал, который можно отредактировать задним числом, доказательной силы не имеет.

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

Короткий чек-лист

• Есть ли обоснование у каждого собираемого поля?
• Версионировано ли уведомление и доступно ли оно?
• Есть ли отслеживаемый канал для запросов субъектов данных?
• Применяются ли ограничения на уровне данных?
• В анонимных процессах личность удаляется на сервере?
• Определены ли сроки хранения и процесс увольнения?

По вопросам комплаенса напишите нам.