Чому регулятори більше не читають вашу політику конфіденційності

У більшості продуктів політика конфіденційності з’являється разом із першою версією сайту або сервісу. Є форма реєстрації, є чекбокс, є базовий опис того, як відбувається обробка даних. Це виглядає достатнім, щоб продукт міг працювати й розвиватися далі.

Зміни накопичуються поступово. Разом із розвитком функціональності з’являються нові інтеграції, змінюється логіка роботи з користувачем, ускладнюється структура обробки даних. У певний момент виникає необхідність пояснити, як саме працює вся ця система з погляду GDPR і захисту персональних даних. І тут виявляється, що документ уже не відповідає реальній моделі ‒ текст застарів, не охоплює всі нюанси та не дає чіткої картини того, що відбувається.

Політика конфіденційності втратила роль основного документа

Раніше перевірка, як правило, починалася з тексту, і формально коректна політика конфіденційності закривала більшість питань. Такий підхід більше не працює, оскільки регулятор оцінює не формулювання, а фактичну поведінку продукту.

Це означає, що текст документа перестав бути головним доказом відповідності, а відповідальність виникає за реальні процеси обробки даних. У результаті навіть добре підготовлений документ може не відповідати тому, що відбувається в системі.

Data flow як фактична модель обробки даних

У процесі розвитку продукт поступово обростає інструментами, які впливають на обробку даних. Спочатку додається аналітика, далі підключаються маркетингові сервіси, а потім інтеграції з іншими платформами.

На рівні команди це виглядає як логічний розвиток продукту:

• підключаються cookie для аналітики
• додається трекінг поведінки
• інтегруються сторонні сервіси

Кожен із цих елементів створює окремий потік даних. У сукупності вони формують data flow, який і є фактичною моделлю обробки даних у системі. Саме цей рівень аналізу стає ключовим для регулятора.

Розрив між задекларованим і фактичним використанням даних

У типовому сценарії продукт уже працює, команда регулярно додає нові функції та змінює логіку взаємодії з користувачем. Паралельно підключаються нові сервіси, які впливають на обробку даних, але це не завжди супроводжується оновленням документації.

У результаті:

• згода користувача залишається в початковому вигляді
• політика конфіденційності не оновлюється
• нові сценарії обробки не відображені в документі

Таким чином формується розрив, який майже не помітний всередині продукту, але добре помітний під час зовнішньої оцінки. Саме цей момент стає відправною точкою для перевірок.

Достатньо згадати справу Bundeskartellamt проти Facebook. У ній німецький регулятор звернув увагу на те, що компанія об’єднувала дані користувачів із різних джерел ‒ з самого Facebook, Instagram та сторонніх сайтів ‒ в єдиний профіль. При цьому користувач фактично не мав можливості окремо погодитися або відмовитися від такого об’єднання.

Формально політика конфіденційності існувала, але регулятор оцінив не її текст, а саму модель обробки: користувач не контролював, які саме дані об’єднуються і як вони використовуються. Саме тому таку практику було визнано порушенням, навіть попри наявність документа. Такий сценарій характерний для будь-якого динамічного продукту, де функціонал змінюється швидше, ніж політика.

Як це виявляється під час перевірок

Сьогодні перевірка, як правило, починається з аналізу продукту, а не документа. Регулятори спочатку оцінюють технічну сторону, після чого переходять до порівняння з описом у політиці.

Зазвичай аналіз включає:

• скрипти та cookie на сайті
• підключені сервіси та інтеграції
• поведінку системи після дій користувача

Після цього перевіряється, чи відповідає політика конфіденційності фактичній моделі обробки даних. Саме на цьому етапі найчастіше і з’являються невідповідності, які створюють ризики для компанії.

Що означає відповідність у сучасних продуктах

У сучасних умовах відповідність означає постійну синхронізацію між документами й продуктом. Це не одноразова дія, а процес, який супроводжує розвиток сервісу.

Щоб мінімізувати ризики, необхідно:

• узгоджувати всі потоки даних із текстом документа;
• оновлювати політику разом із розвитком продукту;
• контролювати інтеграції та трекінг.

Це оформлюється через політику конфіденційності для сайту, яка стає частиною системи захисту даних, а не формальним документом.

Висновок

Основна проблема сучасних продуктів полягає не у відсутності документів, а в їхньому відриві від фактичних процесів. Політика конфіденційності залишається важливим елементом, але вона працює лише тоді, коли відображає реальну модель обробки даних. Контроль над цією відповідністю визначає можливість масштабування продукту без юридичних ризиків.

Автор: Валерій Сталіров, CEO компанії IT-юристів Stalirov&Co

Правила коментування

Вітаємо Вас на сайті Pingvin Pro. Ми докладаємо всіх зусиль, аби переконатися, що коментарі наших статей вільні від тролінгу, спаму та образ. Саме тому, на нашому сайті включена премодерація коментарів. Будь ласка, ознайомтеся з кількома правилами коментування.

1. Перш за все, коментування відбувається через сторонній сервіс Disqus. Модератори сайту не несуть відповідальність за дії сервісу.
2. На сайті ввімкнена премодерація. Тому ваш коментар може з’явитися не одразу. Нам теж інколи треба спати.
3. Будьте ввічливими – ми не заохочуємо на сайті грубість та образи. Пам’ятайте, що слова мають вплив на людей! Саме тому, модератори сайту залишають за собою право не публікувати той чи інший коментар.
4. Будь-які образи, відкриті чи завуальовані, у бік команди сайту, конкретного автора чи інших коментаторів, одразу видаляються. Агресивний коментатор може бути забанений без попереджень і пояснень з боку адміністрації сайту.
5. Якщо вас забанили – на це були причини. Ми не пояснюємо причин ані тут, ані через інші канали зв’язку з редакторами сайту.
6. Коментарі, які містять посилання на сторонні сайти чи ресурси можуть бути видалені без попереджень. Ми не рекламний майданчик для інших ресурсів.
7. Якщо Ви виявили коментар, який порушує правила нашого сайту, обов’язково позначте його як спам – модератори цінують Вашу підтримку.