KMCO HOLLAND
TAX & FINANCE

GDPR в Нидерландах для бизнеса: обязанности, документы и практический минимум

Дисклеймер: материал носит информационный характер и не является индивидуальной юридической консультацией. Для оценки вашего случая нужны вводные данные (вид деятельности, каналы сбора данных, страны клиентов/сотрудников, подрядчики, ИТ-контур).

GDPR в Нидерландах: с чего начать и почему это важно бизнесу

Если ваша компания в Нидерландах собирает или использует персональные данные (клиенты, лиды с сайта, сотрудники, кандидаты, подписчики рассылок, посетители с cookies/аналитикой), то у вас, как правило, возникает набор обязанностей по GDPR (в Нидерландах часто используют термин AVG). Надзорным органом в Нидерландах является Autoriteit Persoonsgegevens (AP).

В практическом смысле GDPR — это не “один документ на сайте”, а комплект прозрачности + процессов + договоров с подрядчиками + мер безопасности, которые вместе снижают риски претензий, утечек и организационных потерь.

Кому GDPR актуален (типовые ситуации)

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

Сайт с формами (заявки, обратный звонок, регистрация, чат-виджет).
Маркетинг и аналитика (cookies, пиксели, трекинг, ремаркетинг, поведенческая реклама).
CRM / базы клиентов (контакты, сделки, история коммуникаций).
HR-контур (резюме, анкеты, документы сотрудников).
Подрядчики (хостинг, email-сервисы, коллтрекинг, бухгалтерия, HR-платформы, облака).

Роли и ответственность: кто вы — controller или processor

Одна из ключевых точек, с которой начинается порядок, — понять роли:

Controller (контролёр) — вы определяете “зачем и как” обрабатываются данные (цели и средства).
Processor (обработчик) — вы обрабатываете данные по поручению контролёра (обычно подрядчик/платформа).

Почти всегда бизнес одновременно является controller по данным клиентов/лидов/сотрудников и одновременно использует подрядчиков, которые выступают processors.

Это важно, потому что далее появляется обязанность корректно оформить отношения с подрядчиками (см. DPA ниже) и выстроить процессы.

Практический минимум: какие документы и артефакты должны быть у компании

.

Ниже — минимальный “рабочий набор”, который чаще всего ожидают увидеть при проверке/споре/инциденте.

1) Privacy notice / политика конфиденциальности

.

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

Минимум, который должен быть отражён:

категории данных (контактные, договорные, техданные, HR и т.п.)
цели обработки
категории получателей (подрядчики)
сроки хранения (логика retention)
права субъекта данных и канал обращения
контакт для вопросов/жалоб

2) Cookie notice + механика согласий (если есть трекинг/маркетинг)

.

Если вы используете cookie/пиксели/скрипты аналитики и маркетинга, важно обеспечить корректную механику уведомления и, где нужно, управление согласием (consent). Здесь часто “ломаются” даже хорошие сайты: баннер есть, но реального управления категориями нет, либо скрипты грузятся до согласия.

3) DPA / договор(ы) с обработчиками данных

.

Если у вас есть подрядчики, которые обрабатывают персональные данные по поручению (хостинг, CRM, рассылки, коллтрекинг), на практике нужен договорной контур (часто называют DPA). Он фиксирует роли, обязанности, меры защиты, порядок инцидентов и субподрядчиков.

4) Реестр обработок (RoPA) — Article 30

.

GDPR предусматривает документирование обработок (record of processing activities) по статье 30 — это один из центральных элементов accountability. gdpr-info.eu

На практике это таблица/реестр, где по каждому процессу фиксируются:

цель обработки
категории данных и субъектов
получатели/подрядчики
сроки хранения
общие меры безопасности

5) Процедуры: права субъектов данных и “как отвечаем”

.

GDPR предполагает, что человек может обратиться с запросом (доступ, исправление, удаление и т.д.). Нужна внутренняя процедура:

кто принимает запрос
как идентифицируем заявителя
где ищем данные (сайт/CRM/почта/облака)
как отвечаем и фиксируем результат

6) Информационная безопасность (минимум организационных мер)

.

GDPR — не только про “бумаги”. Важно показать разумные меры:

разграничение доступов (кто видит CRM/HR)
2FA и управление паролями
контроль устройств/почты
резервные копии
обучение сотрудников (минимальный инструктаж)

Инциденты и утечки: что важно знать бизнесу

.

GDPR содержит обязанность уведомлять надзорный орган о нарушении безопасности персональных данных без неоправданной задержки и, как правило, не позднее 72 часов с момента, когда организация “осознала” факт нарушения, если есть риск для прав и свобод людей. European Commission

Практический вывод для бизнеса:

заранее иметь план реагирования (кто отвечает, как фиксируем, какие данные собираем)
вести журнал инцидентов
иметь контакт подрядчиков (кто сообщает вам о проблемах)
Важно: не каждое ИТ-событие = “утечка GDPR”. Критично правильно квалифицировать инцидент и действовать процессно.

СРОЧНЫЙ РАЗБОР СИТУАЦИИ С GDPR

Заявка на аудит

Нужен ли DPO (Data Protection Officer)

.

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

Если вы не уверены, относится ли бизнес к таким категориям, обычно достаточно короткого комплаенс-скрининга по фактам: что именно вы трекаете, какие данные собираете, сколько субъектов, какие системы, какие подрядчики.

Топ-10 типовых ошибок компаний (и как их исправлять)

.

“Политика есть, но не соответствует фактическим процессам” → сверка текста с реальными формами/CRM/подрядчиками.
Трекинг включается до согласия → настройка загрузки скриптов по категориям.
Нет DPA с ключевыми подрядчиками → формирование договорного контура.
Нет реестра обработок (RoPA) → завести Article 30 реестр и обновлять при изменениях. gdpr-info.eu
Слишком широкий доступ к данным → роли и доступы, принцип “need-to-know”.
Нет процедуры по запросам субъектов → регламент + шаблоны ответов.
Сроки хранения нигде не определены → политика retention (логика по категориям).
Данные кандидатов/HR живут в почте годами → отдельный HR-контур и правила хранения.
Субподрядчики у processors не контролируются → условия по субпроцессорам в DPA.
Нет плана реагирования на инциденты → минимальный incident response plan + журнал.