Drücke „Enter”, um zum Inhalt zu springen.
Hinweis zu diesem Datenschutz-Blog:
Anscheinend verwenden Sie einen Werbeblocker wie uBlock Origin oder Ghostery, oder einen Browser, der bestimmte Dienste blockiert.
Leider wird dadurch auch der Dienst von VG Wort blockiert. Online-Autoren haben einen gesetzlichen Anspruch auf eine Vergütung, wenn ihre Beiträge oft genug aufgerufen wurden. Um dies zu messen, muss vom Autor ein Dienst der VG Wort eingebunden werden. Ohne diesen Dienst geht der gesetzliche Anspruch für den Autor verloren.

Ich wäre Ihnen sehr verbunden, wenn Sie sich bei der VG Wort darüber beschweren, dass deren Dienst anscheinend so ausgeprägt ist, dass er von manchen als blockierungswürdig eingestuft wird. Dies führt ggf. dazu, dass ich Beiträge kostenpflichtig gestalten muss.

Durch Klick auf folgenden Button wird eine Mailvorlage geladen, die Sie inhaltlich gerne anpassen und an die VG Wort abschicken können.

Nachricht an VG WortMailtext anzeigen

Betreff: Datenschutzprobleme mit dem VG Wort Dienst(METIS)
Guten Tag,

als Besucher des Datenschutz-Blogs Dr. DSGVO ist mir aufgefallen, dass der VG Wort Dienst durch datenschutzfreundliche Browser (Brave, Mullvad...) sowie Werbeblocker (uBlock, Ghostery...) blockiert wird.
Damit gehen dem Autor der Online-Texte Einnahmen verloren, die ihm aber gesetzlich zustehen.

Bitte beheben Sie dieses Problem!

Diese Nachricht wurde von mir persönlich abgeschickt und lediglich aus einer Vorlage generiert.
Wenn der Klick auf den Button keine Mail öffnet, schreiben Sie bitte eine Mail an info@vgwort.de und weisen darauf hin, dass der VG Wort Dienst von datenschutzfreundlichen Browser blockiert wird und dass Online Autoren daher die gesetzlich garantierten Einnahmen verloren gehen.
Vielen Dank,

Ihr Klaus Meffert - Dr. DSGVO Datenschutz-Blog.

PS: Wenn Sie meine Beiträge oder meinen Online Website-Check gut finden, freue ich mich auch über Ihre Spende.
Ausprobieren Online Webseiten-Check sofort das Ergebnis sehen

Що означає збір даних у контексті ДЗП? Один із найважливіших термінів обробки даних

0
Dr. DSGVO Newsletter detected: Extended functionality available
More articles · Website-Checks · Live Offline-AI
📄 Стаття у форматі PDF (тільки для передплатників новин)
🔒 Premium-Funktion
Der aktuelle Beitrag kann in PDF-Form angesehen und heruntergeladen werden

📊 Download freischalten
Der Download ist nur für Abonnenten des Dr. DSGVO-Newsletters möglich

Обробка даних починається вже з моменту збору персональних даних. Збір даних є найранішою можливою діяльністю обробки даних. З цього можна вже виникнути відповідальність згідно із ДЗПВ разом із численними обов'язками. Лише той, хто зберігає дані, може бути відповідальний. Але що означає збір даних?

Чому збір даних є важливим поняттям?

Збирання даних є рівнозначним до Обробки даних. Тільки хто обробляє особисті дані або організовує обробку інших, може бути відповідальним за це (і часто саме так відбувається, коли визначаються мета та засоби).

Хто є відповідальним згідно з ДЗГ, повинен дотримуватися вимог ДЗГ. Тому дуже важливо знати, що означає . Згідно зі законодавчим актом про захист даних, нічого не визначено щодо цього.

Нижченаведені терміни будуть використовуватися мною для пояснення того, що саме під час збору даних має бути розуміто:

  • Adresse
  • Контейнер (у сенсі листівки або буфер)
  • Збирати
  • Представлення

Сьогодні ви, можливо, здивовані деякими з цих термінів у контексті збірки даних. У першу чергу термін Контейнер, який я тут ввожу, повинен бути новим для багатьох фахівців із захисту даних, якщо не вважати знищення документів. Інші терміни також не згадуються в законодавчому тексті ДSGVO (або лише дуже обмежено). Можливо, термін Корпус листування краще зрозуміти, хоча він є занадто конкретним і тому не зовсім ясний.

Цей матеріал спрямований на інформацію, яка була надана керівнику, а не на таку, яку він отримав самостійно.

Охорона кордонів.

В подальшому між Datenerhebung та Verantwortlichkeit відрізняється. Збір даних сам по собі ще не є критичним питань щодо захисту даних, але це стане так лише тоді, коли виникає відповідальність. Відповідальність знову ж таки може бути тільки наявна, якщо відбувся збір даних. Для жодного збору даних відповідати за нього нічого не означає, як відсутність відповідальності.

Вступ

У статті Чин 4 Пункт 2 ДЗПВ визначено обробка даних як

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

Визначення поняття обробки даних відповідно до ч. 2 ст. 4 Регламенту ЄС про захист особистих даних (DSGVO).

У англійському законодавчому тексті слово Збірка (від to collect) використовується для збору.

У законодавчому тексті відсутня визначення поняття "збирання". Тому мені довелося написати цей статтю, щоб забезпечити ясність.

У цьому матеріалі розглядаються лише збірки особистих даних у неурядовому секторі, які відбуваються автоматизовано або частково автоматизовано, зберігаються в файловій системі чи повинні зберігатися. Це відповідає області застосування Закону про захист даних, передбаченому в ст. 2 ДЗГВ, окрім винятків, згаданих у розділі 2.

Збір даних є першою оброблювальною діяльністю

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

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

Вищі діяльність, яка передбачає обробку даних згідно з ст. 4 пп. 2, здійснюється відповідно до часу зростання, тобто в порядку, вказаному у законодавчому тексті:

  1. Піднімати, потім вже можна
  2. Збирати потім, а потім вже є
  3. Організація можлива, а також це
  4. Сортування, потім (або навіть без організації чи сортування) є
  5. Зберігання можливе, потім (або замість цього перед збереженням)
  6. Зміна, але тільки після збереження того
  7. Вивчення або те
  8. Питання. З або без зберігання слід можливість
  9. Використання або те
  10. Відкриття шляхом передачі, розповсюдження або іншої форми надання, а також
  11. Сходження або поєднання.

Ця послідовність не випадкова і не може бути випадковою, оскільки існує 11! (11 факторіал) можливостей для створення цієї списку. 11! = 11 * 10 * 9 * 8 * 7 * 6 * 5 * 4 * 3 * 2 * 1 = 39.916.800, тобто близько 40 мільйонів. Якщо навіть вважати два з одинадця пар слів рівними, кількість можливостей буде більше ніж 300 тисяч. Висновок такий: вірогідність того, що список випадково виник, була б 1/362.880 = 0,0000028.

Також Article 29 Working Party, Opinion 3/2013 підкреслило, що збор даних є першою діяльністю обробки даних.

В законодавці було цілком чітко і без жодних сумнівів встановлено початок обробки даних. Це також видно з назви статті 13 ДЗП: "Обов'язок повідомляти про збір особистих даних щодо особи, яка стосується цієї особи".

Хто збирає дані, той обробляє дані. Збір даних є найранішим процесом обробки даних!

Висновок за ч. 4 ст. 2 ДЗП.

Збір даних відбувається до збору даних, як вказує закон. Зібрати означає за Дуденом збирати або збираючи, що також можна вивести зі словника англійською мовою (to collect).

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

Збирання даних вимагає наявності адреси одержувача.

Мої спостереження щодо визначення поняття збору даних.

Збір даних може відбуватися лише тоді, коли вказана адреса, на яку людина може відправити повідомлення. З адреси несподівано можна вивести термін збору! Як показано далі, адресою не обов'язково бути справжнім одержувачем, але будь-яким можливим одержувачем.

Збирання даних відбувається після отримання та перед записуванням (recording).

Адреса передбачає Сховник. Це здається ще більш дивним. Мені ця пізнання заповнює певну задоволеність, особливо ця виділення ніде не знаходиться.

Є контейнер, який називається в англійській мові та у галузі інформатики як Контейнер або Collection. Програмування мова Java знає концепцію Collection і Containers теж.

Наприклад, адреси із вказанням належного контейнера такі:

  • Поштова адреса: поштове ящик
  • Адреса електронної пошти: поштовий ящик (точніше, сервер поштового ящика)
  • Адрес IP при зверненні до вебсторінки: основна пам'ять сервера
  • Персональна розвага: Мозок адресованого (Пам'ять)
  • Номер телефону/телефонний зв'язок: той же
  • Номер телефону/автозвонок: "Рекорд" – запис (зараз вже здебільшого цифровий)

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

Моя визначення адреси у контексті ДЗПВ.

Тупий листовчий, який (навіщо саме так) об'єктивно ні з ким не можна звільнити, не є адресою в цьому сенсі. Власність інформації про повідомлення тут немає. У галузі інформатики існує Нульовий пристрій як «віртуальне виведення пристрою», «яке знищує все, що написано до нього» (Джерело: Wikipedia, щодо якої заяви я як інформатик підтверджую). Нульовий пристрій також називається NUL-Метою і не є адресою в сенсі GDPR, оскільки майже неможливо отримати інформацію про прийняті повідомлення.

В окремому випадку є адреса з контейнером, який може приймати лише одну повідомлення одночасно. Якщо контейнер не звільнити вчасно, повідомлення втрачаються. Це саме стосується кожного контейнера із вищою здатністю до зберігання повідомлень. З досвіду добре відоме проблему повного поштового ящика електронної пошти, який не може приймати жодних нових повідомлень, поки він не звільнений. Відправлення додаткових повідомлень таким чином неможливо, оскільки навіть отримання повідомлень було можливим.

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

Збір даних — це можливе отримання повідомлення від отримувача, яке було надіслано на адресу.

Моя визначення поняття збору даних. Стаття 2, абз. 1 ДЗП має бути застосована.

Збір даних означає можливу знавання повідомлення, яке було відправлене на адресу. Реальне знавання може відбуватися автоматизовано (це також вказано в Статті 4 п. 2 ДЗП), наприклад, через сервер, який забезпечує вебсторінку. Знавання відбувається шляхом отримувача даних. Обробка даних повинна відбуватися відповідно до Статті 2 розділу 1 ДЗП.

Видалення можливої інформації регулюється ДЗНП з поняттям Реципієнт, який визначений у Статті 4, п. 9. Реципієнтом є фізична або юридична особа, якій надаються дані особистого характеру.

Різниця від отримання даних

Збирання даних є пізнішим процесом ніж отримання даних. Синонім для empfangen це erhalten (bekommen). Надсилання у поштовому сенсі відбувається тоді, коли повідомлення було отримано правильно на вірній адресі, тобто спеціально отримане.

Бriefкasten отримує повідомлення. Вони вважаються отриманими або прийнятими в цей момент та піднятими у цей момент, коли вони будуть видалені з Briefkasten згідно призначеної дії. Якщо Briefkasten повний, то ні прийняття, ні підняття повідомлення не можливі (залишивши зауваження про те, що поштовий працівник міг би особисто передати листа тощо). Коли лист потрапляє до неправильної адреси, наприклад, через помилку поштового працівника, власник Briefkasten отримав повідомлення, але не підняв його.

Є поштовий ящик, вміст якого обробляється лише вручну та не зберігається у файловій системі чи ні бажаємо зберігати його, який знаходиться поза обміром розгляду. Див. Стаття 2 Пункт 1 ДЗНП. Багато підприємств використовують сканери для автоматизації обробки всієї пошти. У цьому випадку вміст поштового ящика цих підприємств потрапляє до області застосування ДЗНП. Також використання даних у електронній листі чи відправлення даних через електронну листу відповідає зберіганню в автоматизованій файловій системі.

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

За допомогою заяви про надсилання стає очевидною обов'язковість, якої повинен дотримуватися призначений одержувач. Такий одержувач фактично зобов’язаний регулярно очищати свій поштовий ящик (якщо це прийнятно, я б сказав). Кимось, хто отримує попередження, можна звернутися до суду після закінчення терміну дії заяви на те, що він не зміг відкрити свій поштовий ящик протягом сімох днів тому, що погане погода. Ця обов’язковість не випливає з GDPR, а лише може бути передбачена іншими законодавчими актами, які я поки не міг знайти і яких, здається, немає навіть. Судові рішення та публічні заяви юристів можуть вказувати на цю обов'язковість.

Знання повідомлення

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

Контейнер призначений для збору об'єктів.

Моя власна інтерпретація поняття "об'єкт" у контексті захисту даних – дані є об'єктами

При контейнерах (технічною: Container) як головному зберігачі даних одного Сервера вебсайту відбувається процес отримання повідомлення для непрофесіонала відбувається імпліцитно, але з технічної точки зору експліцитно відбувається (сервер був відповідним чином програмований). Сервер із однією входною мережевою лінією може обробляти лише одне сигнал одночасно. Обробка триває звичайно довше ніж передача даних. З тим щоб жодного сигналу (= повідомлення або запитання) не втрачалося, пухне сервер входження сигналів, поки він зможе їх обробити. Пухир – це контейнер.

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

Хто відповідає за дотримання вимог ДЗП згідно з GDPR?

Виборка даних ще нічого не робить. Ви повинні також відповідати за збір даних, щоб з цього виникли обов'язки.

Відповідальний у розумінні ДЗП (Ст. 4 пп. 7) — це той, хто "один чи разом з іншими приймає рішення щодо цілей та засобів обробки персональних даних". Хто-небудь збирає персональні дані для певного призначення та за встановленими засобами, є особливо відповідальним відповідно до ДЗП і повинен надавати інформацію згідно зі ст. 13 ДЗП особі, щодо якої зберігаються дані.

Даний термін Зміст можна було б також визначити терміном Представлення. Значення цього терміну слід розуміти у широкому сенсі, і я вибрав його саме тому, що зміст є досить абстрактним терміном. Представлення може бути інформаційне представлення, послуга тощо.

Відповідальність виникає лише на підставі пропозиції.

Мої висновки (для справжньої відповідальності повинні виникнути додаткові умови)

Без пропозиції відповідальності немає. Якщо вам хто-небудь без запрошення відправить свої медичні документи, які потрапляють у ваші руки, то при вас відбувається збір даних (вже ймовірно), але ви не відповідальні за це.

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

Якщо б відповідальність була можливою навіть без пропозиції, кожен міг би зробити третього людину відповідальним проти його волі.

Відповідальність за зібрані, але не отримані дані

Хтось-н зібрав дані та ще не отримав знання щодо даних, виникає питання фактичної відповідальності. Хтось-н запропонував послугу та отримав повідомлення в своєму поштовому ящику і цей лист без того, щоб він отримав знання щодо вмісту листа дійшов до інших осіб, чи він відповідає за це? На це потрібно звернути увагу. Я підозрюю, що тут грають роль обов'язки з дотримання безпеки та інші правові зобов'язання. Якщо людина не закриває свій поштовий ящик, згідно зі моїм поглядом вона відповідальна за порушення законодавства про захист даних, якщо треті особи незаконно захоплюють вміст свого поштового ящика.

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

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

Хто наказує третього передавати дані, які сам собі не відомі, відповідає за це.

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

Приклад збору даних: вебсайт

Вебсторінка є пропозицією, яка визначає свій зміст шляхом призначення цілей. Вона надається за допомогою засобів Інтернету та інших технічних умов (HTML тощо). У ст. 8 абз. 1 ДЗП згадується термін пропозиція, але вже стосовно надання електронних послуг, що відноситься до вебсторінок.

Як вебсайт розуміється тут публічно доступна інтернет-презентація. Інша ситуація – зашифрована сторінка, яку захищає пароль. Але захист паролем повинен відбуватися прямо на рівні сервера, щоб це не було однією з публічних сторінок вебсайту. Це можна здійснити шляхом вказівки директиви у так званій .htaccess файлі.

Відповідь тексту: Дадреса IP є особистими даними. При кожному зверненні вебсторінки згідно зі стандартами Інтернету TCP (Transmission Control Protocol) передаває адресу IP користувача на сервер, який забезпечує доступ до сторінки. Відповідно до цього принципу застосовується ДЗК для будь-якої публічної вебсторінки.

З цього виникає згідно з Стаття 4 Номер 7 РГДПВ відповідальність, бо

  1. Збір даних відбувається (дивіться вище)
  2. Персональні дані збираються (тобто мінімум IP-адреси)
  3. Нав'язуваний призначений зміст (оферта щодо вмісту вебсторінки)
  4. Середні роки визначаються (інтернет тощо)

Кожна публічна вебсторінка, яка має певну мету, потребує декларації про захист даних

Основа: Для таких вебсайтів існує відповідальність згідно зі ст. 4, п. 7 ДЗВП

Внаслідок цього кожна публічно доступна вебсторінка повинна мати Декларацію про захист даних. Єдина можливий виняток міг бути вебсторінкою, яка не представляє пропозиції, тобто наприклад повністю без будь-якого вмісту. Але навіть Лендинг сторінка адреси доступної вебсторінки, яка часто містить кілька слів щодо пропозиції відвідуваної сторінки на продаж, явно є пропозицією. Також веб-відвідкarta є пропозицією. Якщо вона не була б такою, чому тоді вона там знаходиться? Особливо стосовно порожньої вебсторінки з інформацією про власника вважається пропозицією, окрім того випадку, коли інформація про власника була розміщена через надмірну обережність. Either інформація про власника була розміщена згідно із § 5 TMG, тоді перед нами стоїть бізнесова пропозиція. Or інформація про власника була розміщена згідно із §18 MStV, тоді перед нами стоїть пропозиція щодо інформації. Or обидва випадки (це найчастіше відбувається).

Наприклад, збір даних за допомогою електронної пошти

В цьому випадку треба розрізняти кілька випадків, наприклад:

  1. Вказування електронної адреси в інформаційній сторінці вебсайту: Ви пропонуєте, щоб люди писали вам (у цьому випадку тому, що згідно з § 5 TMG або § 18 MStV ви зобов'язані цим). Кимось користується цим для загальної запиту по електронній пошті, а не з юридичних підстав
  2. Загальне контактне формулярі: Ви пропонуєте таке на своїй вебсторінці. Кимось використовується це для загальної звернення. У тлі відправляється електронна пошта до вас
  3. Електронна пошта як можливість зв'язку при виникненні потреби в консультаціях: Ви пропонуєте написати собі листа. Кимось користується цим, оскільки він хоче отримати ваше пропозицію щодо консультування
  4. Формуляр контактів при необхідності консультації: Ви пропонуєте такий на своїй вебсторінці. Кимось він використовується, бо людина хоче отримати ваше консультативне послуги. У тлі відбувається відправлення листа електронної пошти до вас
  5. Колишній співрозмовник просить від нього щось надіслати на вказану адресу електронної пошти, наприклад свої контактні дані, щоб ви могли йому надіслати пропозицію за допомогою електронної пошти

У всіх випадках здійснюється збір даних. Випадки 1 та 2 не є (відчутним) пропозицією, оскільки немає певної мети (у правових суперечках, які виникли через контакт із інформацією про видавця, це може бути інше). Випадки 3-5 є пропозицією з певною метою.

Зібрані дані не створюють жодної обов'язковості!

Обов'язок виникає лише тоді, коли додаткові умови виконуються

Зібрані дані самі по собі не створюють жодної обов'язковості. Натомість ви повинні відповідати за збір даних, щоб виникнути зобов'язання згідно з GDPR щодо вас.

Згідно з вищезазначеними випадками електронної поштової комунікації це означає конкретно:

  • Осінь 1, надання адреси електронної пошти для загальної контакта не має певного призначення. З отриманої без попереднього повідомлення листа виникне ніякої відповідальності. Аналогічно було б, якби людина взяв вашу адресу електронної пошти (або адресу на місці) з реєстру або телефонного довідника і звернувся до вас
  • Осінь 2, загальний контактний формуляр (без вибору або попередньої домовленості щодо питання), не має певного призначення. З повідомленням, отриманим без запрошення через пошту чи інший спосіб, не виникає відповідальності
  • Осінь 3, надання адреси електронної пошти з метою пропозиції послуги консультування (оферта послуг), означає виникнення відповідальності
  • Осінь 4, надання контактної форми для пропозиції консультацій означає виникнення відповідальності
  • Осінь 5, запрошення, щоб людина надсилала вам особисту інформацію, означає виникнення відповідальності. Ви тут пропонуєте послуги щодо чогось.

У випадках 1 та 2 визначайте засоби, але не мету. У випадках 3–5 визначте засоби і мету, тому відповідальні за це. Для контактної форми регулярно потрібна індивідуальна оцінка, щоб встановити, чи насправді існує пропозиція або еквівалент надання адреси електронної пошти для загальної спілкування (найкраще без явних торгівельних інтересів). Але це не питання захисту даних, а інше.

Якщо людина без попередження отримує особисту інформацію, вона повинна виключити можливість відповідальності шляхом знищення цієї інформації. Наприклад, помилка даних може спричинити додаткові проблеми (хай би яким воно було потрібно перевірити окремо).

Відповідальний був або є одержувачем

Тільки хто є або був одержувачем даних, або спричинив отримання даних від третього боку, може стати відповідальним особою. У параграфіх 31, 61 та 68 ДЗНВ[7] а також у статті 14, абз. 3, п. с ДЗНВ[8] містяться логічні наслідки для цих доказів.

Тільки хто був або є одержувачем даних чи пізніше спричинив отримання даних іншими, може стати відповідальним.

Логічна висновкова дія згідно із законодавчим текстом ДЗПВ

В наявності ролі одержувача при відповідальному або на прохання від відповідального можна пояснити тим, що збирання даних (to collect) можливе лише тоді, коли дані для збирання існують. Ці дані не падають з неба і не отримуються під час збірки шляхом поєднання інших даних, як вказує перелік в Art. 4 Nr. 2 DSGVO щодо обробки даних. Також висловлення щодо передачі особистих даних до третіх країн без достатнього рівня захисту даних показують, що передача необхідна для початку процесу обробки даних та виникнення відповідальності. Передача знову ж таки передбачає наявність одержувача.

Європейський суд у своєму рішенні від 16 липня 2020 року (Справа C-311/18, розділ 83) визначив, що «пересилання особистих даних з однієї держави-члена до третього є обробкою особистих даних згідно зі статтею 4, п. 2 ДЗП».

Викликання прийому за ініціативою відповідальної особи

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

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

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

Спільна відповідальність

Отримує людина дані, тому що інший їй передав їх, може виникнути спільна відповідальність. Це випливає зокрема з рішень ЄСПЛ від 29 липня 2019 року – C-40/17 ("Fashion ID"). Рішення ЄСПЛ стосується Facebook-плагіна. Вмістити плагін на вебсторінці означає технічним чином, що (з початку) як власник сторінки так і Facebook отримують ті ж дані від користувачів (можуть). Тільки тоді, коли користувач клікає по посилу або кнопці, яку надав плагін та веде до Facebook, може Facebook додатково зібрати дані, які мають стосунок до початкової збору даних.

Які наслідки знання керівника щодо обробки даних у третій стороні, якій керівник передає дані, було розглянуто Єгерським судом у рішенні Fashion-ID (див. нижче, RN. 77). Мав на увазі: коли хто-небудь встановлює плагін на своїй вебсторінці та знає, що дані про відвідувача вебсторінки (в будь-якому разі IP-адресу) будуть оброблені власником плагіна, він відповідатиме за це. Це особливо вірно тоді, коли отримувач даних є інтернет-компанією, бізнес-модель якої ґрунтується на експлуатації даних.

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

Перед цим Facebook може порівняти дані, які раніше отримала від користувача, з новими даними. Цей порівняльний процес відбувається згідно рішення ЄСПЛ лише у відповідальності Facebook (оскільки Facebook отримує тільки частину порівняних даних). Такий тип обробки даних, який здійснюється лише Facebook і без прямого розпорядження власника вебсторінки, також належить лише Facebook, як вказав ЄСПЛ (наприклад, розділ 85 рішення). Однак це може бути правдою лише тоді, коли власник вебсторінки не завжди користується цим порівняльним процесом.

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

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

Виходить відповідальність при використанні зовнішніх зображень?

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

Власник вебсторінки (або відповідальний за неї, який часто є однією людиною) відповідає за інтеграцію зовнішнього зображення. У цьому випадку мова йде лише про звичайні, статичні зображення третього боку, а не про знімки відвідувачів тощо. Третій у цьому прикладі навіть нічого не знає про своє щастя та не надає ніякої послуги при інтеграції зображення.

Відповідальний за інтеграцію зовнішнього зображення повинен either показати AVV щодо третього сторони або відповідатиме згідно Article 5, paragraph 1 c DSGVO (Принцип мінімізації даних). Для зовнішньої інтеграції статичного зображення немає жодної підстави, за якою місцеву інтеграцію неможлива чи не прийнятна.

Фотографії повинні завжди бути локалізовані. У будь-якому випадку слід перевірити авторське право.

Виходить відповідальність при встановленні зовнішніх посилань?

Є людина, яка на своїй вебсторінці розміщує посилання на третю вебсторінку, відповідає вона за цей лінк згідно з законодавством про захист даних?

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

Донор посилання отримує, проте, в своєму контейнері (поштовому ящику) не ті ж дані, які виникають при кліку на посилання. Він збирає дані не через кліки на посилання. Відокремлюється випадок, коли донор посилання міг би мати можливість слідкувати за кліками на посиланнях, наприклад, за допомогою Google Analytics або власних JavaScript-логіків. Цей випадок підніс би інші питання, які менше стосуються зовнішніх посилань а більше стосувалися слідкування за користувачами (див. наприклад Стаття 5 Пункт 1 c DSGVO або Пункт 15 Пункт 3 TMG).

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

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

Цільова сторінка відповідає за збір даних щодо себе самого. За попередніми припущеннями немає спільної відповідальності. Це підтверджено також ЄСПЛ у згаданому вище рішенні щодо Fashion ID.

Джерело посилання відповідальне, але насправді ні за чим не відповідає. Нуль, множений на відповідальність, рівний нулю. Відповідальність у теорії існує (у більшості випадків), але в практиці немає.

І Anders може вважати, що на сторінках з лівої навігації адреси виглядають так, як ніби вони здійснюють передачу даних в країну, яка не надійна. Тут грає роль Стаття 44 GDPR, яка особливо стала актуальною після рішення щодо Privacy Shield ("Schrems II"). Я припускаю, що користувач, натискаючи на зовнішній посилання, дав згоду на можливі ризики, якщо раніше мав можливість про них дізнатися. Без цього повідомлення від відповідального особи виникла б більша відповідальність, яку я тут не можу далі обговорювати.

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

Встановлення посилань на незаконні матеріали або матеріали, які можуть призвести до проблем при візовому контролю в США, є більше змістовним питання (§ 7 TMG?).

Коли виникає взаємна відповідальність?

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

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

Кимсь відправляє вам у вашій якості приватної особи неприймані листи електронною поштою. Ви відповідаєте. У відповіді міститься ваша особиста адреса, якої ви не просили (навіть більше того, що ваша особиста адреса в формі автоматично доданої підписки є частиною кожного вашого листа).

Завданням не є те, що вам хто-небудь без попереднього повідомлення відправляє листа. Ви лише отримали дані, але жодного пропозиції щодо того, щоб їм було надіслано повідомлення, не зробили.

Реципієнт вашої відповіді зберігає дані. Він відповідає за особисту інформацію, яку він запитав. Він не відповідає за дані, які ви йому без запиту та без зв'язку зі своїм запитанням відправили. Чи частини відповіді можуть бути пов’язані з запитанням, навіть якщо ні до цього не було звернення, необхідно перевірити окремо. Наприклад, підпис електронної пошти може бути обов’язковим (наприклад, при професійній кореспонденції), через що відповідальність може виникнути у реципієнта.

Чи дозволена розповсюдження даних, отриманих без запрошення?

Так, якщо є правова підстава для цього. Наприклад, слідчі можуть бути повідомлені про вміст, який ви вважаєте порушенням законодавства або яким ви відчуваєте загрозу. недавно було випадок покупця на eBay . Купець виявив, що флешка містить дані попереднього власника, які відрізняються від власника, який продав її. Купець звернувся до попереднього власника як власнику даних і передав дані власнику даних назад. Коли власник даних повертає свої дані людині, яка їх випадково отримала, це майже ніколи не викликає проблем. Проблема може виникнути лише тоді, коли надсилач вибере дуже небезпечний спосіб пересилання. А навіть безкоштовна допомога від сусідів (з інших причин ніж захист даних) створює значні зобов'язання для тієї людини, яка допомагає!

Правові підстави обробки даних згідно з ДЗНВ визначені у статті 6 ДЗНВ. У згаданому вище прикладі щодо слідчої діяльності може бути така ситуація, що правові підстави виходять із інших законодавчих актів, оскільки при загрозі головне питання не стосується захисту даних. Також згідно з ДЗНВ «адміністрації, яка здійснює певний розслідувальний обов'язок відповідно до права ЄС або законодавства держави-члена», не вважаються одержувачами даних. Якщо ж передача даних адміністрації є законною, то адміністрація не несет відповідальності згідно з ДЗНВ, оскільки без одержувачів дані не збираються.

Чи можуть дані зберігатися безмежно довго?

Здесь під "даними" розуміються особові дані, які було зібрано відповідальним особою. Якщо людина отримала право на видалення згідно зі ст. 17 ДЗНП, тоді дані мають бути видалені відповідно.

Інші законодавчі акти поза рамками ДЗЗ можуть вимагати більш тривалої зберігання, наприклад, у справах про податки.

Дані можуть бути використані лише для певних цілей та лише згідно з правовими підставами з Статті 6 РГПДО. Переробка даних для інших цілей не дозволена відповідно до Статті 5, абз. 1 б РГПДО. Збереження даних не є переробкою даних, тому ця законодавча норма не застосовується.

Якщо збережені дані не будуть оброблені далі, то довгострокова зберігання моїм уявленням дозволена, якщо власник даних цього не бажає заперечувати тощо. naturally також з обов'язкової зберігання зобов’язань вийде. Я це глибше вивчати не мав час і радію myself повідомленнями.

Висновок

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

Вище вказано, що лише теоретична можливість отримання даних не достатньо для того, щоб дані були зібрані. Натомість повинна бути справжня можливість отримання даних. Перегляньте приклад повного ящика електронної пошти або листа, який спалений прямо після доставки.

Хто з власної ініціативи та за свої кошти збирає дані про окремих осіб, відповідає за ці дані та зобов'язаний обробляти їх лише згідно із вимогами ДЗП.

Вказання, що Відповідальний має бути одержувачем або повинен організувати отримання даних третім особам, відсутнє у законодавчому тексті ДЗП з моїми відомостями (якщо я помиляюся, просимо повідомити). Моя припущення така: це пов'язано із складністю ДЗП чи вважалося, що роль одержувача буде очевидною зі словом Передача. Без попереднього отримання даних інші дані не можуть бути наявні.

Відповідальність припадає також лише тоді, коли людина надає оферту, що в ДЗГВ називається метою.

Я вважаю це блискучим, визначення збірки даних або збору даних (Collection) відповідно до GDPR як можливий перший етап обробки даних та звернення увагу на концепцію збору даних. Дуже мало хто подумає про те, що відбувається збір даних після отримання даних для адреси та їх відкриття отримувачеві.

About the author on dr-dsgvo.de
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.

Система розподілу вмісту Cloudflare: використання та захист даних