Політика конфіденційності для додатку та сайту. Як об’єднати і зробити ефективною?
Якщо у вашого бізнесу є і сайт, і додаток, питання “одна чи дві політики конфіденційності?” рано чи пізно постане перед вами. Досить часто сайт і додаток сприймаються як окремі продукти, і політики конфіденційності для них готуються окремо. На перший погляд у цьому немає нічого проблемного.
Проте на практиці такий підхід не завжди відповідає реальній моделі обробки персональних даних. У результаті з’являються документи, які формально існують, але не дають цілісного уявлення про те, як працює сервіс і що саме відбувається з даними користувача в сукупності. Саме з цього моменту зазвичай і починаються проблеми з privacy-документацією.
Чому окремі політики це майже завжди погана ідея?
Ідея мати окрему політику конфіденційності для сайту і окрему для додатку виглядає досить логічною. Сайт і додаток виглядають як різні продукти, над ними часто працюють різні команди, а документи готуються в різний час. У результаті з’являються дві політики конфіденційності, які формально описують одне й те саме, але з різними акцентами і рівнем деталізації.
Проблема в тому, що з точки зору захисту персональних даних сайт і додаток рідко є окремими системами. У більшості випадків це два інтерфейси доступу до одного сервісу з єдиною бізнес-логікою, спільною інфраструктурою і спільними цілями обробки даних. Поділ на окремі політики в такій ситуації не відображає реальну картину того, як працює обробка персональних даних.
Саме тут і з’являється перший суттєвий ризик. Коли обробка даних одна, а її опис поділений на два документи, між ними часто виникають розбіжності. В одній політиці згадуються одні категорії даних, в іншій – інші. Наприклад, на сайті детально описані cookies, а в політиці для додатку взагалі може не згадуватися використання SDK або рекламних ідентифікаторів. Кожен документ окремо виглядає прийнятно, але разом вони створюють фрагментоване уявлення про сервіс.
Для користувача це означає відсутність цілісної інформації про те, що саме відбувається з його даними. Для регулятора це відсутність послідовності та прозорості. І саме ця неузгодженість, а не сам факт наявності двох політик, найчастіше стає предметом зауважень під час перевірок, аудитів або розгляду скарг.
Позиція регуляторів у цьому питанні доволі проста. Вимога прозорості це не про обсяг тексту і не про кількість документів, а про те, чи може людина швидко і зрозуміло скласти загальну картину обробки персональних даних. Ірландський регулятор (DPC), наприклад, прямо формулює очікування як “інформація має бути легко доступною, зрозумілою, з можливістю використання візуалізації там, де це доречно”.
| Case study: Google (CNIL, €50 млн) Французький регулятор (CNIL) у справі Google прямо вказав, що ключова інформація про обробку персональних даних була надмірно розпорошена між різними документами та екранами.Щоб зрозуміти цілі обробки, строки зберігання або використання інформації для персоналізації реклами, користувачеві потрібно було виконати кілька послідовних кроків, інколи до п’яти чи шести дій. У результаті користувач фактично не міг скласти цілісне уявлення про те, що відбувається з його персональними даними. |
Читайте також: Як ми розробляємо політику конфіденційності та політику приватності?
Коли об’єднання політик must have, а не nice to have
Є кілька сценаріїв, коли єдина політика конфіденційності є необхідністю. Якщо сайт і мобільний додаток є частинами одного сервісу, працюють під одним брендом і управляються однією юридичною особою, наявність єдиної політики виглядає логічною і обґрунтованою з точки зору захисту персональних даних.
Таке об’єднання зазвичай потрібне, коли:
- користувач має один обліковий запис для сайту і додатку;
- персональні дані обробляються в межах спільної бекенд-інфраструктури;
- цілі обробки не залежать від того, з якої платформи користувач взаємодіє із сервісом;
- аналітика, маркетинг або підтримка будуються із зведеними даними з різних каналів.
У таких ситуаціях окремі політики не додають прозорості. Навпаки, вони ускладнюють розуміння того, як саме використовуються персональні дані, і створюють ризик внутрішніх суперечностей у документації. З точки зору практики захисту персональних даних значно простіше і безпечніше мати один документ, який комплексно описує всю обробку, ніж підтримувати кілька паралельних версій.
Якщо ж ви перебуваєте лише на етапі оцінки того, які privacy-документи загалом потрібні вашому бізнесу, рекомендуємо прочитати також статтю “Так чи потрібні для мого бізнесу Privacy Policy та Cookie Policy?”, яка допоможе зорієнтуватися у ключових вимогах.
А що якщо щось забудемо?
Побоювання щось не врахувати це одна з найпоширеніших причин, чому бізнес відкладає об’єднання політик або відмовляється від нього взагалі. Часто здається, що єдина політика буде надто загальною і не зможе коректно відобразити специфіку кожної платформи.
Насправді ризик виникає не через об’єднання, а через неправильну структуру документа. Єдина політика не означає однаковий опис усіх процесів. Вона означає один документ, у межах якого різні сценарії обробки чітко розмежовані та логічно пов’язані між собою.
Коли вся обробка зібрана в одному тексті, значно простіше побачити, які дані збираються через сайт, а які через мобільний додаток, де використовуються різні інструменти і які процеси є спільними. Це, як правило, зменшує кількість прогалин і робить політику зрозумілішою як для користувачів, так і для самої команди, яка з нею працює.
Тобто, це історія не про “ми збираємо дані”, а:
- ми збираємо дані через сайт;
- ми збираємо дані через мобільний додаток;
- ось що спільного;
- а ось що відрізняється.
До речі, цей підхід добре лягає у концепцію “layered notice”. Британський регулятор (ICO), зокрема, прямо описує, як працює багаторівневе інформування і чому воно може бути практичним рішенням за умови, що всі рівні узгоджені між собою і не суперечать один одному.
Як побудувати єдину політику
Рішення об’єднати політики конфіденційності саме по собі ще нічого не вирішує. Найбільша помилка на цьому етапі це спробувати механічно “зшити” два тексти в один. Такий підхід зазвичай не усуває проблем, а лише переносить старі протиріччя в новий документ.
Єдина політика починає працювати лише тоді, коли вона відображає реальну модель обробки персональних даних. Тобто відповідає не на питання про те, де користувач залишає дані, а про те, як і для чого ці дані використовуються в межах сервісу. Саме з цієї логіки і варто починати побудову документа.
| Спробуйте подивитися на політику очима стороннього користувача або аудитора. Ви відкриваєте документ і намагаєтеся швидко відповісти на три базові питання: які персональні дані збираються, з якою метою і кому вони можуть передаватися. Якщо для цього потрібно постійно переходити між двома документами і звіряти абзаци, прозорість втрачається. Це та сама логіка, через яку CNIL критикував “розпорошену” інформацію у справі Google. |
Алгоритм об’єднання політики конфіденційності
Як ви вже зрозуміли, об’єднання політик конфіденційності не починається з редагування тексту. Воно починається з перевірки того, чи коректно бізнес сам для себе розуміє власну модель обробки персональних даних. Саме на цьому етапі зазвичай і виникають проблеми, які згодом проявляються вже на рівні документації.
Політика конфіденційності це user-facing відображення того, як насправді побудована обробка персональних даних. Якщо ця внутрішня логіка нечітка, неповна або суперечлива, жоден, навіть добре написаний текст, не зможе це компенсувати.
Хто ви і чому це одна політика
Перший і ключовий крок це чітко визначити, хто саме є контролером персональних даних і чи справді сайт і мобільний додаток існують у межах однієї моделі контролю над даними. Формально це питання виглядає простим, але на практиці саме тут виникають приховані складнощі.
Якщо сайт і додаток управляються однією юридичною особою, використовують спільну інфраструктуру і обслуговують одну і ту саму базу користувачів, з точки зору захисту персональних даних вони майже завжди є частинами одного сервісу.
Типовий фейл на цьому етапі це формально задекларувати одну політику, але фактично залишити різні підходи всередині документа. Наприклад, коли в загальному розділі описується один контролер, а далі з’являються фрагменти, які створюють враження, ніби за окремі процеси відповідають різні суб’єкти. Для регулятора це сигнал про відсутність чіткого контролю над обробкою персональних даних.
Які дані ви збираєте
Наступний крок це системно описати персональні дані, які обробляються в межах сервісу. Тут важливо не просто перелічити категорії даних, а показати, які з них є спільними для сайту і мобільного додатку, а які характерні для кожної платформи окремо.
На практиці більшість базових даних користувача є спільними: облікові дані, контактна інформація, історія взаємодії із сервісом, платіжна інформація. Водночас мобільний додаток часто передбачає додаткові категорії даних, зокрема, технічні ідентифікатори, інформацію про пристрій, журнали активності, аналітичні події.
Правильна єдина політика не ігнорує ці відмінності, але й не розносить їх по різних документах. Вона описує їх у межах одного контексту, чітко показуючи, де, за яких умов і для чого такі дані обробляються.
Хорошою практикою є поділ цього розділу на підблоки:
- дані, які збираються через сайт;
- дані, які збираються через додаток;
- дані, спільні для обох платформ.
Цілі обробки
Під час опису цілей обробки найчастіше виникають розбіжності між окремими політиками для сайту і додатку. Причина зазвичай проста – такі цілі часто формулюються не з точки зору сервісу, а з точки зору конкретної платформи.
У межах єдиної політики логіка має бути зворотною. Цілі визначаються функціонуванням сервісу загалом. Реєстрація користувачів, надання послуг, підтримка, аналітика чи безпека зазвичай не залежать від того, чи користувач взаємодіє із сайтом, чи з мобільним додатком. Платформа лише впливає на спосіб досягнення цих цілей, але не створює їх самостійно.
Правові підстави
На цьому етапі бізнес найчастіше стикається з найбільшим опором. Бажання спростити документ і послатися на згоду користувача для всіх процесів виглядає привабливо, але на практиці майже завжди створює додаткові ризики.
Єдина політика дає можливість коректно розмежувати правові підстави залежно від конкретних операцій обробки. Частина процесів може ґрунтуватися на виконанні договору, частина – на законних інтересах бізнесу, а згода застосовуватися лише там, де це дійсно необхідно. Розмежування цих підстав у межах одного документа робить модель обробки більш прозорою та зрозумілою.
Типовою помилкою є також використання різних підстав для однакових процесів у різних політиках конфіденційності. Після об’єднання такі суперечності стають очевидними і потребують негайного вирішення.
Права користувачів
Формально права суб’єктів персональних даних є однаковими незалежно від платформи. На практиці ж саме різниця в механізмах реалізації цих прав часто стає джерелом проблем.
Єдина політика дозволяє описати права користувачів послідовно, але з урахуванням того, що доступ до налаштувань, видалення даних або управління згодами може реалізовуватися по-різному на сайті і в додатку. Тут важливо не просто перелічити права, а показати, як саме вони реалізуютьчя через у конкретний продукт.
Регулятори звертають увагу саме на цю практичну реалізацію. Формальний перелік прав без зрозумілих механізмів їх реалізації часто сприймається як декларативний. У цьому контексті варто орієнтуватися на підхід ICO до “right to be informed” і практичних способів інформування користувачів.
Передача даних третім особам
Передача персональних даних третім особам це ще один блок, де розбіжності між політиками виникають дуже часто. Аналітичні сервіси, хмарні провайдери, маркетингові інструменти можуть використовуватися одночасно і на сайті, і в додатку, але описуються по-різному або з різним рівнем деталізації.
У єдиній політиці ці отримувачі даних мають бути описані централізовано, з чітким розумінням їх ролі в обробці, що зменшить ризик того, що одна і та сама передача даних виглядатиме по-різному залежно від того, з якого документа на неї дивляться.
Міжнародна передача даних
Якщо сервіс використовує інфраструктуру або постачальників, обробка персональних даних у межах яких передбачається доступ до даних поза межами Європейського Союзу або Європейської економічної зони, міжнародна передача даних має бути логічно інтегрована в загальний опис обробки.
Тут важливо не обмежуватись загальною фразою “дані можуть передаватися за кордон”. Вона майже нічого не пояснює. Краще коротко, але конкретно вказати, до яких країн або регіонів передаються дані, на яких правових підставах і з використанням яких механізмів, а також чому така передача є необхідною для роботи сервісу.
Типові помилки, які псують навіть хорошу політику
Навіть добре структурована і акуратно написана політика конфіденційності не гарантує відсутності ризиків. На практиці проблеми виникають там, де документ формально виглядає коректно, але не збігається з реальною моделлю обробки персональних даних.
У більшості випадків питання не обмежується лише політикою конфіденційності. Ризики з’являються і тоді, коли privacy-документація в цілому не відповідає вимогам GDPR або побудована фрагментарно. Ми детально описували, які документи є критично важливими для комплаєнсу, у статті “Необхідні документи для відповідності GDPR”.
У випадку об’єднання політик для сайту і мобільного додатку такі розбіжності стають особливо помітними.
Основна помилка бізнесу: об’єднати текст, але не логіку обробки
Найпоширеніший сценарій виглядає приблизно так: дві окремі політики беруться за основу, з них прибираються очевидні дублювання, формулювання трохи уніфікуються і в результаті з’являється один документ.
Проблема полягає в тому, що такий підхід не усуває ключових суперечностей. Якщо сайт і додаток історично розвивалися окремо, у них часто різні підходи до аналітики, різні набори інтеграцій і різне розуміння того, для чого саме використовуються дані користувачів. Просте зведення цих описів в один текст лише приховує ці відмінності, але не вирішує їх.
Ще один типовий фейл це намагатися зробити політику максимально універсальною, прибравши специфічні деталі платформи, коли все виглядає настільки абстрактним, що вже неможливо зрозуміти, де саме мова йде про сайт, а де про додаток. Така політика перестає виконувати свою ключову функцію: пояснювати користувачеві, що насправді відбувається з його персональними даними.
Саме на цьому етапі найчастіше виникають питання під час аудитів і перевірок – коли політика говорить одне, а технічна документація або фактична поведінка сервісу інше.
Правильне об’єднання завжди передбачає роботу з логікою обробки, а не лише з формулюваннями. Це означає перегляд цілей обробки, правових підстав, ролей третіх осіб і механізмів реалізації прав користувачів у контексті сервісу в цілому.
Кілька слів на завершення
Питання об’єднання політик конфіденційності для сайту і мобільного додатку насправді значно ширше, ніж вибір між одним чи двома документами. Воно показує, наскільки бізнес усвідомлює власну модель обробки персональних даних і чи здатен пояснити її послідовно та прозоро. Саме тому формально правильні, але роз’єднані політики часто створюють більше ризиків, ніж здається на перший погляд.
Єдина політика працює лише тоді, коли за нею стоїть реальне розуміння процесів, а не спроба уніфікувати формулювання.
Якщо у вас є сайт і додаток, і ви хочете бути впевненими, що політика конфіденційності та інша privacy-документація дійсно відповідають тому, як працює ваш сервіс, Legal IT Group може допомогти вам з цим. Ми маємо значну практичну експертизу у сфері захисту персональних даних і супроводжували компанії з різних індустрій у побудові та перегляді політик конфіденційності, cookie-документації та інших privacy-процесів. У таких питаннях правильно вибудувана логіка на старті зазвичай економить значно більше часу, ресурсів і ризиків у майбутньому.
