Какие документы нужны по GDPR?

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

Содержание

Зачем нужны документы?

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

1) Это инструмент доказательства. В Европе действует принцип подотчетности: если компания не может показать, что соблюдает требования GDPR, надзорный орган считает, что она его нарушает. И наоборот: если в компании произошел инцидент с персональными данными, но у нее есть реестр и описанные процедуры реагирования, то надзорный орган ограничится более мягким наказанием или предупреждением.

Статья: Что такое GDPR?

Подробно разбираем Общий Регламент по защите персональных данных в Европе: история, требования, шаги для соответствия.
Читать статью

2) Документы помогают бизнесу самому понять, что происходит с данными. Некоторые компании обнаруживают неожиданные вещи уже на этапе составления RoPA: например, что доступ к пользовательской базе имеет стажёр маркетинга или что данные хранятся «временно» уже три года. После формализации процессов команда начинает быстрее отвечать на запросы пользователей, сокращает объем хранимых данных и экономит ресурсы.

3) Качественная политика приватности и понятные процедуры повышают доверие клиентов. Для нового продукта на европейском рынке это может стать реальным конкурентным преимуществом: прозрачность в обращении с данными воспринимается как признак зрелости и надежности бизнеса. Для клиентов в Европе это действительно важно: у них GDPR уже «прижился» и его выполнение уже считается базовым минимумом.

Наиболее важные документы

Когда компания или стартап решает выйти на европейский рынок, вопрос документации внезапно становится очень объемным. Кажется, что вокруг GDPR существует бесконечный список требований, и каждый источник добавляет что-то своё: «сделайте RoPA», «срочно нужна политика cookies», «проведите DPIA», «подпишите DPA со всеми подрядчиками». На этом этапе легко потеряться. Но если посмотреть глубже, становится ясно: несколько ключевых документов формируют основу всей системы защиты персональных данных и помогают компании работать безопасно, предсказуемо и законно.

Реестр обработок (RoPA)

Реестр обработок персональных данных по ст. 30 GDPR — это, по сути, карта того, что происходит с данными внутри организации. Именно во время составления реестра формируется понимание масштаба обработок в компании.

RoPA показывает:

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

GDPR требует не просто составить такой документ, но и поддерживать его в актуальном состоянии. Это важная особенность: RoPA — живой инструмент, к которому компания обращается при проверках, при ответах на запросы пользователей, при подготовке политики приватности и при анализе рисков. Если надзорный орган запрашивает сведения, а компания не может их оперативно представить, это воспринимается как отсутствие контроля.

Статья: Что такое RoPA и почему о нём так часто говорят?

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

Политика приватности (Privacy Policy)

Политика приватности — первый документ, который видит пользователь. Он отражает требования статей 12, 13 и 14 GDPR и определяет, насколько прозрачно компания объясняет:

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

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

Особенность политики приватности заключается в том, что она должна быть понятной для обычного пользователя. Это прямо указано в ст. 12 GDPR. Иногда для этого требуется визуализация, FAQ, сокращение юридических формулировок. Чем проще текст, тем выше доверие.

Статья: Мы можем просто скопировать политику приватности у конкурентов? — Увы, не можем.

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

Политика cookies (Cookie Policy)

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

Но иметь cookie-баннер недостаточно. Он должен позволять субъекту (то есть пользователю сайта) реализовать свои права. Баннер не должен содержать только кнопку «Принять» или делать ее более заметной по сравнению с другими: «Отказаться» или «Настроить предпочтения».

Политика видеонаблюдения

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

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

DPIA (Data Privacy Impact Assessment)

Data Privacy Impact Assessment, предусмотренный ст. 35 GDPR, — один из самых недооцененных инструментов. Он помогает выявить риски для прав и свобод людей, а не только для бизнеса.

Статья: Что такое DPIA?

Объясняем, что такое DPIA, когда нужно проводить эту процедуру и как ее организовать в соответствие с GDPR.
Читать статью

DPIA особенно важна, если:

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

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

Трансграничная передача данных: SCC и TIA

Если данные передаются за пределы ЕС, например в США, компании требуется механизм обеспечения адекватной защиты. Наиболее распространенный вариант — Standard Contractual Clauses (SCC), утвержденные Еврокомиссией.

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

После решения Schrems II стало обязательным проводить Transfer Impact Assessment (TIA), чтобы оценивать, обеспечивает ли страна-получатель уровень защиты, сопоставимый с европейским. Для компаний, использующих американские сервисы, это критически важно: европейский партнер вполне может приостановить обработку данных до предоставления оценки.

Оценка легитимности интереса (Legitimate Interest Assessment)

Если обработка основана на ст. 6 GDPR — «легитимный интерес», компания обязана документально подтвердить его наличие. Legitimate Interest Assessment помогает показать:

  • — зачем компании нужна обработка,
  • — является ли она необходимой,
  • — не нарушает ли она права субъекта данных.

Например, рассылка пользователям обновлений продукта может быть оправдана легитимным интересом, но маркетинговая рассылка без согласия — уже нет. LIA позволяет провести баланс интересов и определить меры защиты: возможность отписки, ограничение объема данных, прозрачное информирование.

Соглашение об обработке данных (Data Processing Agreement)

Если компания передает данные подрядчику — разработчику, маркетинговому агентству, провайдеру хостинга — ст. 28 GDPR требует заключения Data Processing Agreement. В нем прописываются обязанности процессора:

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

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

Процедуры безопасности: data breach, доступы и запросы субъектов данных

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

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

Ст. 15–21 GDPR закрепляют права субъектов, а компании должны уметь отвечать на запросы в течение одного месяца. Без документированных процедур бизнес рискует пропустить сроки или предоставить неполную информацию. И это уже нарушение.

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

В итоге именно эти документы формируют ядро GDPR-комплаенса. Они позволяют компании понимать свои процессы, демонстрировать соответствие, снижать риски и строить доверительные отношения с пользователями и партнерами. И хотя работа над ними может казаться трудоемкой, практический эффект часто проявляется уже в первые месяцы: процессы становятся четче, данные более структурированными, а бизнес устойчивее.

Другие документы по GDPR

Когда компания уже прошла первый этап внедрения GDPR — создала базовые документы вроде RoPA, политики приватности, DPA — появляется ощущение, что самое сложное позади. Но на практике именно следующие документы определяют, насколько система защиты персональных данных будет работать ежедневно, а не только на бумаге.

Важно понимать: большинство из них не названы в GDPR напрямую. Однако они вырастают из ключевых принципов — подотчетности, прозрачности, ограничения хранения и обеспечения безопасности (ст. 5 GDPR). И если надзорный орган придёт с проверкой, именно эти документы чаще всего станут доказательством, что компания действительно управляет обработкой данных, а не просто декларирует намерения.

Разберём каждый из них отдельно.

Соглашение об обмене данными (Data Sharing Agreement)

Этот документ нужен, когда компания передаёт данные независимому контролеру — то есть стороне, которая сама определяет, зачем и как будет использовать данные. Пример: маркетплейс передаёт информацию о продавце банку для подтверждения личности. Банк не выполняет поручение маркетплейса, он действует как независимый контролер.

DSA помогает описать:

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

Он связан с требованиями прозрачности (ст. 13–14 GDPR) и подотчетности (ст. 5(2) GDPR). Представим ситуацию: компания передала данные партнёру без оформления соглашения, а потом не смогла выполнить запрос на удаление, потому что партнёр отказался удалять записи. DSA как раз предотвращает такие кейсы.

Соглашение о совместном контроле (Joint Controllership Agreement)

 Совместный контроль возникает чаще, чем кажется. Например, если компания и её партнёр совместно определяют цели обработки данных — как это бывает при совместном маркетинге или работе платформы и продавцов.

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

Условия использования продукта (Terms of Use)

Этот документ знают все пользователи, но мало кто понимает его роль в GDPR. Если обработка данных основана на договоре (ст. 6 GDPR), условия использования помогают определить рамки обязательств.

Например, SaaS-сервис обязан предоставить доступ к продукту, а пользователь — предоставить данные, необходимые для регистрации. Если условия сформулированы нечётко, компания рискует выйти за пределы «контракта» и оказаться в зоне требований согласия.

Политика хранения и удаления персональных данных (Retention Policy)

Принцип ограничения хранения (ст. 5(1)(e) GDPR) требует не хранить данные «на всякий случай». Но без формального документа компании редко понимают:

  • — какие данные у них есть,
  • — сколько они хранятся,
  • — когда и как их удалять.

В нашей практике есть кейс, когда подобное излишнее хранение данных было невыгодно компании даже с точки зрения расходов. Она хранила список e-mail подписчиков пять лет, хотя половина адресов была неактивной. После внедрения Retention Policy база сократилась вдвое, а расходы на хранение данных на сервере и рассылки значительно уменьшились.

Политика информационной безопасности

Это фундамент всех технических и организационных мер. Она описывает:

  • — кто отвечает за безопасность,
  • — как предоставляется доступ,
  • — какие устройства разрешены,
  • — как предотвращаются и обрабатываются инциденты.

Регуляторы часто запрашивают именно этот документ при проверке выполнения принципа целостности и конфиденциальности (ст. 5(1)(f)). Без него компания не может доказать системный подход к защите данных.

Правила использования мобильных устройств

Когда сотрудники используют личные телефоны или ноутбуки для работы (модель BYOD), риски возрастают в разы. Потерянный телефон с доступом к корпоративной почте может стать источником утечки.

Этот документ описывает:

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

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

Правила обработки персональных данных при удаленной работе

Удалённая работа стала стандартом, но далеко не все компании адаптировали процессы. Этот документ помогает внедрить:

  • — VPN,
  • — двухфакторную аутентификацию,
  • — требования к домашним Wi-Fi сетям,
  • — запрет на использование публичных сетей.

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

Документ о внутренних аудитах со стороны DPO

GDPR требует демонстрировать соответствие, а не просто утверждать его. Поэтому регулярные проверки становятся обязательным элементом подотчетности (ст. 5(2)).

Статья: Как проводить внутренние аудиты на соответствие требованиям защиты персональных данных

Даем пошаговый план проведения внутреннего аудита своими силами.
Читать статью

Документ устанавливает:

  • — как часто проводится аудит,
  • — кто участвует,
  • — как оформляются результаты.

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

Порядок ведения и актуализации RoPA

Ст. 30 GDPR требует актуальный реестр обработок. Но в реальности RoPA часто создают один раз — и забывают.

Этот документ закрепляет:

  • — кто отвечает за обновление,
  • — как фиксируются изменения,
  • — как вносятся новые обработки.

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

Порядок обучения и проверки знаний сотрудников

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

Этот документ определяет:

  • — как проводится обучение,
  • — как фиксируется участие,
  • — как проверяются знания.

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

Порядок утилизации носителей информации

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

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

Он связан с принципом ограничения хранения и конфиденциальности (ст. 5(1)(e),(f)). Если компания продает ноутбуки бывшим сотрудникам, не очистив диски, данные клиентов оказываются в открытом доступе. Документ о порядке утилизации как раз предотвращает такие инциденты.

Эти документы формируют «операционное ядро» GDPR. Они доказывают, что компания не просто написала политику приватности, а действительно управляет обработкой данных: контролирует доступы, обучает сотрудников, удаляет устаревшие данные и регулирует отношения с партнёрами. Именно наличие таких процедур чаще всего убеждает регуляторов и клиентов, что бизнес зрелый, ответственный и заслуживает доверия.

Как создавать документы для соблюдения Регламента: 6 советов

1) Начинайте не с текста, а с процессов

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

Хорошая практика — начинать с инвентаризации данных и бизнес-процессов. Пока вы сами не знаете, какие процессы происходят внутри, невозможно создать корректные документы.

Полезным инструментом становится карта движения данных (Data Flow Mapping) — схема, показывающая, как данные проходят через системы. На ее основе формируются RoPA, политика хранения, DPA и процессы безопасности.

2) Ориентируйтесь на риск

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

Компании, которые пытаются «сделать всё сразу», часто тратят ресурсы на второстепенные документы, забывая про критичные процессы. Гораздо эффективнее задать вопросы:

  • — где у нас самые чувствительные данные?
  • — кто имеет к ним доступ?
  • — какие риски наиболее вероятны?

И уже исходя из этого определять очередность разработки.

3) Делайте документы понятными

Статья 12 GDPR требует, чтобы публичные документы были понятны обычному человеку. Это звучит просто, но на практике многие политики выглядят как сухие юридические тексты: длинные предложения, сложные конструкции, термины без объяснений.

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

Поэтому важно:

  • — писать простым «человеческим» языком,
  • — структурировать информацию,
  • — использовать визуальные элементы, подсказки,
  • — адаптировать документ под аудиторию.

Если документ понятен, это знак зрелости системы защиты персональных данных.

4) Делайте документы уникальными и поддерживайте их актуальность

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

Документы должны отражать:

  • — реальные процессы,
  • — конкретные системы,
  • — конкретные риски.

И они должны постоянно обновляться. Процесс обновления RoPA, политик или процедур должен быть формализован. Если компания внедряет новую CRM или начинает работать с новым подрядчиком, документы должны измениться.

Регуляторы очень быстро замечают несоответствие между документами и реальностью. И это чаще всего приводит к претензиям.

5) Описывайте реальные меры безопасности, которые есть в компании

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

Поэтому при разработке документов важно задавать конкретные вопросы:

  • — где физически хранятся данные?
  • — кто имеет доступ к серверам?
  • — где работают разработчики и поддержка?
  • — какая инфраструктура используется?

Документы должны описывать реальные меры, иначе они превращаются в риски.

6) Вовлекайте сотрудников

GDPR невозможен усилиями одного DPO или юриста. Если сотрудники не понимают зачем это делается, возникают задержки, саботаж, ошибки. Поэтому часть документации должна быть направлена на обучение и информирование: инструкции, правила, процессы реагирования.

Компании, которые объясняют цели приватности, обычно быстрее внедряют изменения и реже сталкиваются с инцидентами.

Как работает профессиональная разработка документов?

Наша команда Data Privacy Office, начинает работу не с шаблонов, а с анализа процессов: мы берем интервью у владельцев процессов, проводим аудит существующих практик и оцениваем реальные риски. После этого создаётся стратегия внедрения и уже затем — документы.

Такой подход:

  • — сокращает сроки комплаенса,
  • — снижает расходы,
  • — делает документы реалистичными,
  • — помогает пройти проверку регулятора.

Хотите узнать, каких документов не хватает компании для комплаенса?

Запишитесь на бесплатную консультацию с экспертом Data Privacy Office. Мы проведем экспресс-анализ ваших процессов и подскажем, с каких документов начать.

Разработка документов по GDPR действительно похожа на создание архитектурного проекта. Нельзя просто взять чужой чертёж и надеяться, что он подойдёт. Сначала нужно изучить «местность» — процессы и риски, затем разработать стратегию, и только после этого создавать документацию, которая будет работать в реальности. Такой подход не только помогает соблюдать закон, но и делает бизнес устойчивее, безопаснее и привлекательнее для клиентов и партнеров.

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

Готовы углубить свои знания в сфере защиты данных?

обучение по защите данных

Заполните форму, и наши менеджеры свяжутся с вами в ближайшее время.