Як обговорювати відповідність GDPR англійською мовою

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

«Чи це відповідає GDPR?» рідко є питанням «так або ні», на яке інженер може відповісти сам, і цей посібник охоплює словник, який дозволяє технічній команді вести точну, корисну розмову з юридичними, а не вгадувати, що відповідність насправді вимагає.

Ключовий словник

** Правова основа ** - конкретне юридичне обґрунтування, наприклад, згода або законний інтерес, що дозволяє обробляти певну частину персональних даних, що вимагає чіткої ідентифікації для кожної категорії зібраних даних. “Ми не можемо просто зібрати це поле, тому що воно корисне — нам потрібна законна основа для цього. Якщо це не входить до нашого потоку згоди, юридичні потреби підтверджують, чи законний інтерес дійсно застосовується тут. ”

** Запит суб’єкта даних (DSR) ** - запит від особи на доступ, виправлення, видалення або експорт їх особистих даних, які система повинна бути в змозі виконати в законно необхідний термін, зазвичай місяць. “Це вилучення має бути каскадним через кожну систему, яка зберігає дані цього користувача, а не тільки первинну базу даних — якщо ми отримаємо запит суб’єкта даних на вилучення, ми зобов’язані законом вилучити його повсюди, а не тільки там, де це зручно.”

Мінімізація даних — принцип збору тільки тих персональних даних, які дійсно необхідні для певної, зазначеної мети, а не збирання їх у широкому масштабі на випадок, якщо вони будуть корисними пізніше. “Я б відкинув питання про додавання цього поля до форми реєстрації — ми ще не маємо реального використання для нього, а його збір без визначеної мети є саме тим, чого має запобігати мінімізація даних.”

** Договір про обробку даних (DPA) ** — договір між контролером даних і стороннім процесором, у якому вказано, як буде оброблятися персональна інформація, необхідна перед надсиланням даних користувача будь- якому зовнішньому постачальнику або службі. “Ми не можемо надіслати ці дані до нового постачальника аналітики ще — юридично підтверджено, що нам потрібно підписати угоду про обробку даних спочатку, оскільки вони обробляють персональні дані від нашого імені.”

** Період зберігання ** — визначений час зберігання персональних даних до їх вилучення або анонімізації, що має бути обґрунтоване фактичною бізнес- або юридичною потребою, а не зберігатися безкінечно за замовчуванням. “Зараз ми зберігаємо ці журнали назавжди, що не можна захистити за GDPR — нам потрібен реальний період зберігання, пов’язаний з зазначеною причиною, і процес, який фактично вилучає дані, як тільки закінчується цей період.”

Звичайні фрази

  • Яка законна основа для збору даних у цьому конкретному полі?
  • Чи може наша система дійсно виконати запит суб’єкта даних в необхідні терміни?
  • Чи це мінімізація даних, чи ми збираємо більше, ніж нам зараз потрібно?»
  • «Чи маємо ми угоду про обробку даних з цим постачальником, перш ніж ми відправляємо їм дані користувача?»
  • Який період зберігання даних, і чи насправді його застосовують?»

Приклади висловлювань

Повідомлення про проблему під час перегляду проекту: “Перед тим, як ми додамо це поле до потоку підключення, я хочу підтвердити законну основу з юридичними — збір його за нашим поточним мовленням згоди може не покрити цей випадок використання, і я краще перевірити зараз, ніж після того, як воно вже відправлено.”

Пояснення технічних вимог нетехнічним учасникам: “Запит суб’єкта даних на вилучення не просто вилучення рядка в нашій головній базі даних - дані цього користувача також живуть в нашому аналітичному конвеєрі і системі нашого постачальника електронної пошти, і ми зобов’язані вилучити його з усіх трьох протягом тридцяти днів.”

Відштовхування від похилення обсягу: “Я б не хотів збирати ці дані спекулятивно, на випадок, якщо вони будуть корисними для майбутньої функції — мінімізація даних означає, що ми повинні збирати тільки те, для чого ми маємо визначену мету зараз, а не будувати залік особистих даних, які ми можемо використовувати пізніше.”

Професійні поради

  • Запитуйте про ** законну основу ** явно і на ранньому етапі, коли функція вводить нові особисті дані збирання - перебудова законної основи після того, як дані вже збираються, є набагато складнішою розмовою з законом, ніж мати це спочатку.
  • Збудуйте системи з ** запитом суб’ єкта даних ** виконання в голові з самого початку - система, де дані користувача розкидані по багатьох магазинах без чіткого способу знаходження і вилучення їх всіх стає серйозною операційною проблемою, коли приходить справжній запит.
  • Застосувати ** мінімізацію даних ** як типовий інженерний звичай, а не просто як пункт відповідності — запитання « чи нам дійсно потрібно це поле » перед додаванням поля запобігає набагато складнішій розмові щодо очищення пізніше.
  • Перед надсиланням даних користувача будь- якому сторонньому постачальнику, переконайтеся, що укладено договір про обробку даних — це не лише технічний, але й юридичний ключ, і його промах є поширеним і серйозним порушенням правил відповідності.
  • Визначте і впроваджеть ** період зберігання ** для кожної категорії збережених персональних даних - невизначене зберігання без зазначеного виправдання є одним з найпоширеніших результатів аудиту GDPR.

Практичні вправи

  1. Пояснити, що означає законна основа і чому її потрібно визначити перед збиранням нових даних.
  2. Описує, що система повинна підтримувати, щоб виконати запит суб’ єкта даних.
  3. Напишіть речення, у якому поясните різницю між мінімізацією даних і випадковим збиранням меншої кількості даних.

Національні мови: мова ненаціональних меншин

Ефективне обговорення відповідності GDPR вимагає точності - не тільки в технічних деталях правил захисту даних, але також у мові, яку ми використовуємо. Для розробників, які будують свої професійні навички англійської мови, тонкощі юридичної і регуляторної термінології можуть бути особливо викликом. Легко впасти в надто формальну або жаргонну мову, яка затьмарює розуміння, а не прояснює його. Метою є не просто стверджувати факти; це для того, щоб створити консенсус і переконатися, що всі задіяні - від інженерів до юристів - знаходяться на одній сторінці щодо практики обробки даних. Ключовим елементом цього є активне вирішення потенційних непорозумінь, особливо щодо таких фраз, як «правова основа» або «права суб’єкта даних»

Розглянемо сценарій: Під час перегляду коду, Сара, старший інженер, коментує запит на витягування, надісланий Девідом, молодшим розробником. Девід реалізував нову функцію, яка включала в себе збір адрес електронної пошти користувачів для маркетингових цілей. Коментар Сари: «Це збирання даних має бути повністю відповідним GDPR. Ми абсолютно * повинні * переконатися, що ми маємо документовану згоду і законний інтерес. “Хоча технічно це вірно, ця фраза може здатися надто прецедентною або навіть трохи залякуваною для Девіда, який все ще розвиває свої знання англійської мови. Більш доступною альтернативою може бути: «Дейвід, щодо збору адрес електронної пошти — давайте підтвердимо, що ми чітко описали, як користувачі можуть відмовитися, і що у нас є суттєве обґрунтування для збору цих даних на основі нашої маркетингової стратегії. Чи могли б ви додати коротке пояснення «законної основи», на яку ми покладаємося?» Цей підхід використовує більш доступний словник («виправдання», «відмова») і обговорює дискусію як спільні зусилля, щоб забезпечити найкращі практики.

Іншою поширеною ситуацією є створення описів PR для нових функцій. Уявіть, що ви документуєте оновлення вашої системи профілів користувачів, яке тепер включає обробку даних про місцезнаходження. Типовим описом може бути: « Оновлена система відповідає всім відповідним вимогам GDPR щодо обробки персональних даних (PII) ». Знову ж таки, хоча це технічно правильно, це може здатися щільним і недоступним. Замість цього спробуйте щось на зразок: «Це видання включає в себе розширені засоби керування даними про місцезнаходження користувача, забезпечуючи відповідність вимогам GDPR щодо мінімізації даних і прозорості. Ми впровадили чіткий процес отримання згоди при зборі інформації про місцезнаходження і надаємо користувачам можливості оновлення або вилучення їх даних. “Ця версія зосереджена на впливі зміни - контролі користувача і мінімізації даних - що робить її більш зрозумілою.

Нарешті, пам’ятайте, що активне слухання так само важливо, як і використання точної мови. Під час спілкування з колегами, які можуть мати різні рівні володіння англійською, знайдіть час, щоб перевірити розуміння. Запитання прояснюючих питань, таких як «Чи можете ви пояснити, що ви маєте на увазі під «правами суб’єкта даних» в цьому контексті?» або «Чи можете ви розповісти мені, як це відповідає принципам GDPR?» демонструє повагу і сприяє більш продуктивному діалогу. Це про будівництво мостів комунікації, а не просто про передачу інформації.

Поширені запитання

Про що ця стаття "Як обговорювати відповідність GDPR англійською мовою"?

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

Чи безкоштовна ця стаття?

Так. Усі статті на CoderSlingo, включно з цією, доступні безкоштовно без реєстрації.

Скільки часу займає читання "Як обговорювати відповідність GDPR англійською мовою"?

Приблизно 8 min.