Я долгое время читал интерпретации регламента GDPR. Почему-то я был уверен, что из-за сильно сложного юридического языка читать оригинальный регламент я не смогу. Что люди, умнее меня, давно все прочитали и сделали выжимки. Но, начитавшись этих «выжимок», я набросал в свою голову столько хлама, что стало тошно. Продолжая читать такие тексты, я, вместо того, чтобы хоть что-то понять, переставал понимать вообще, о чем идет речь. Особенно много разногласий в вопросе, что считать персональными данными в рамках GDPR. Тут кто на что горазд. У кого-то X (подставить IP, IDFA, Google Advertising ID, email, etc.) — персональные данные, у кого-то нет.

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

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

Читать рекомендую тут. Это не оригинал, но там читать намного удобней.

Определение персональных данных


Art. 4 (1):
‘personal data’ means (1) any information relating to (2) an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as (3) a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person
Что из этого можно понять:

  1. Персональными данными являются вообще любые данные (1), которые можно связать с физическим лицом. Нет смысла рассуждать, являются ли отдельно взятые данные персональными или нет. Если все данные, имеющиеся у вас на пользователя, можно связать с физическим лицом, то все они — персональные данные. Списки заказов, устройств, покупок, заметки, комментарии, адреса, в общем, все то, что пользователь может оставить у вас, пользуясь вашим продуктом — потенциально персональные данные.
  2. Данные могут быть уже прямо связаны с физическим лицом (“an identified natural person”), т.е. явно прописаны, чьи они (скажем, к ним привязаны ФИО, год рождения), или их можно потенциально связать (“an identifiable natural person”) посредством доступных способов (подробнее об этом ниже).
  3. Идентификаторы пользователей, такие как логины, IDFA и AAID, какие-то идентификаторы в куках, уникальные номера в системе — могут быть у вас в системе ссылками на какие-то физические лица. Однако, эти идентификаторы (а также все связанные с ними данные) становятся персональными (и подпадают под GDPR) только тогда, когда физические лица, представленные этими идентификаторами, могут быть потенциально идентифицированы в реальном мире (“an identifiable natural person”).

Что такое «identifiable»


Выдержка из Recital 26:
To determine whether a natural person is identifiable, account should be taken of all the means reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identify the natural person, account should be taken of all objective factors, such as the costs of and the amount of time required for identification, taking into consideration the available technology at the time of the processing and technological developments.
Это о том, что под понятием “an identifiable natural person” нужно понимать физическое лицо, которые можно определить любыми доступными вам способами с разумной вероятностью и с разумными тратами ресурсов. «Разумность» вы оцениваете сами и готовитесь оспаривать в суде, если вдруг придется.

Recital 30:
Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.
Это снова про то, что, собирая много разных данных про пользователя, мы в конечном итоге можем идентифицировать физическое лицо в реальном мире. И тогда все, что мы собрали, становится персональными данными.

Анонимные данные


Еще одна выдержка из Recital 26:
The principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable.
Итак, если по имеющимся у вас данным нельзя идентифицировать физическое лицо (в разумных пределах, см. выше), то все данные на пользователя вашей системы являются анонимными и не подпадают под действие GDPR.

Вместо заключения


Часто можно встретить вопросы типа «Является ли IP-адрес пользователя персональными данными?» Если вы вдруг ловите себя на мысли, что задаетесь таким или похожими вопросами, то скорее всего вы не понимаете, что такое персональные данные в рамках GDPR.

В отрыве от контекста такой вопрос не имеет смысла. Давайте разберем случай с IP-адресами. Тут два аспекта.

Во-первых, IP-адрес можно рассматривать просто как часть данных, которые вы собираете на пользователя. Если можно потенциально определить реальное физическое лицо, которое стоит за этим пользователем (не через этот IP-адрес, а вообще, используя все доступные средства и данные), то все данные, которые вы собрали (и IP-адрес среди них) — персональные данные.

Во-вторых, IP-адрес можно рассматривать как данные, с помощью которых можно определить физическое лицо. Тут все зависит от того, что еще вы собираете, кроме IP-адреса. Если вы запомнили только IP-адрес посетителя кафе, который воспользовался общей точкой доступа в интернет, то вряд ли этот адрес можно рассматривать как персональные данные (за IP-адреса в логах сильно не переживайте). Но если вы, помимо IP-адреса, собираете еще что-то, что, вместе с этим IP-адресом, сделает возможным идентификацию конкретного посетителя, например, время и частоту посещения кафе и/или заказы посетителей, то все, что вы собрали (и IP-адрес тоже) — персональные данные.

Комментарии (30)


  1. ibKpoxa
    28.05.2018 14:46
    +1

    Юристы говорят, что выполнить все требования этого закона будет не проще, чем требования закона Яровой.


    1. NewStahl
      28.05.2018 16:47

      90% ресурсов могли бы решить этот вопрос упростив жизнь и себе и пользователям: переставши собирать данные, которые им нужны только для рассылки спама, слежки и продажи БД другим спамерам.


      1. Kwisatz
        28.05.2018 20:39

        Почта, ник, ip. Почта как логин, айпи для безопасности. Никакого спама, только самое необходимое.


        1. andreishe
          28.05.2018 23:36

          Логи, связанные сервисы… Нам пришлось отказаться от почтового провайдера потому что его, как оказалось, GDPR не беспокоит так, как нас.


          1. Kwisatz
            29.05.2018 03:05

            А кого собственно беспокоить должно? У меня сервер в европе но сервисы пока непубличные. А даже если и будут то строго на рф расчитаны. Мне бегать кругами?


    1. shifttstas
      29.05.2018 06:41
      +1

      теплое с мягким сравниваете, GDPR — добро, которое позволит удалять свои данные из сервиса и всячески заставляет собирать меньше данных


      1. ibKpoxa
        29.05.2018 19:30

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


  1. Foggy4
    28.05.2018 15:22

    Для меня пока не очень понятным осталось каким образом можно реализовать право на забвение относительно информации сохраненной в бекапах? Обязательно ли необходимо в течении какого-либо срока удалять ее оттуда (это довольно-таки затруднительно с технической точки зрения), либо же можно просто «на словах» гарантировать пользователю, что в случае восстановления информации из бекапа, все его персональные данные будут оттуда удалены?


    1. ibKpoxa
      28.05.2018 15:49

      Бэкапы еще не самый сложный случай, а если рассматривать blockchain биткоина и кто-то скажет, что не хочет «палить» свои транзакции?


      1. besitzeruf
        29.05.2018 02:02
        -1

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


        1. Alozar
          29.05.2018 10:19
          +1

          Порой сам факт наличия транзакции указывает на определённый круг субъектов. Кто угодно не купит Ролекс за 100500 денег, а посмотрев хроники с светских мероприятий и отследив новый ролекс, можно примерно (а иногда и точно) определить владельца счёта.


      1. geisha
        29.05.2018 02:29

        Прежде чем придумывать такие задачки, укажите на оператора данных, к которому вывалите свои претензии. Также, существует некий конфликт ваших личных интересоов и интересов общественных в доступности ваших данных = валидности блокчейна.

        копипаста
        Right to be Forgotten
        Also known as Data Erasure, the right to be forgotten entitles the data subject to have the data controller erase his/her personal data, cease further dissemination of the data, and potentially have third parties halt processing of the data. The conditions for erasure, as outlined in article 17, include the data no longer being relevant to original purposes for processing, or a data subjects withdrawing consent. It should also be noted that this right requires controllers to compare the subjects' rights to «the public interest in the availability of the data» when considering such requests.


    1. Protos
      28.05.2018 15:50

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


      1. Alozar
        28.05.2018 15:57

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


        1. AbstractGaze
          28.05.2018 16:20
          +1

          Что мешает удаление заменить изменением? Измените Вася Пупкин на Удаленный Пользователь0001.
          А вообще довольно странно что транзакции привязаны к персональным данным, а не к какому то ключу основанном на этих данных. Может просто надо схему бд нормально делать?


          1. Protos
            28.05.2018 16:22

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


        1. Protos
          28.05.2018 16:21

          Остатки же финансовая информация и ее например у нас 5 лет надо хранить, если это виртуальные фантики, то хз, видимо по честному в соглашении пописать что пару месяцев не удалены для закрытия недостач и сведения баланса.
          Если это банк на аутсорсинге или ДБО на аутсорсинге, то выгружать архив в банк, пускай сами хранят


          1. shuron
            28.05.2018 17:16

            Первоночално надо определить причину сбора. Это обязательно.
            Art. 6 GDPR Lawfulness of processing
            1)b) processing is necessary for the performance of a contract


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


            Art. 17 GDPR 3) б)
            говорит что если есть правовая причина/обязаность хранить эти данные то она перевешивает.
            Например немецкая Налоговая требует хоранить счета до 11 лет. На счетах могут быть в полне конкретные личные данные… Пофиг будем 11 лет хранить.


        1. T-362
          28.05.2018 16:22

          Допускается как деперсонализация данных так и сохранение данных если это требуется законом — трем информацию о том что «Вася Пупкин» и оставляем абстрактного «клиента #65745».


        1. clicky
          28.05.2018 19:56

          Данные обезличиваются, а не удаляются. Куча anonymize-скриптов под все подряд уже на гитхабе.


        1. alashkov83
          28.05.2018 19:56

          Можно же ID с финансами хранить отдельно, а привязку ПД к ID в отдельной таблице например?


    1. Kanut79
      29.05.2018 09:09

      Обязательно ли необходимо в течении какого-либо срока удалять ее оттуда (это довольно-таки затруднительно с технической точки зрения), либо же можно просто «на словах» гарантировать пользователю, что в случае восстановления информации из бекапа, все его персональные данные будут оттуда удалены?

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


    1. teecat
      29.05.2018 09:49

      В момент извлечения удалять или превращать в неперсональную информацию путем удаления части данных. Ну и видимо предусмотреть меры по защите мест хранения от утечек


  1. Radziuk
    28.05.2018 19:56

    Есть задачка, над разгадкой которой бьюсь последние 5 дней. Уверен, лидогенерация знакома каждому пользователю Хабра, и в её рамках имем следующее: у нас есть мэил контактного лица (возможно, я бы даже сказал точно, его имя). Понимаю, что это личные данные и необходимо их хранить и обрабатывать согласно закону, который также регулирует срок хранения этих данных. Из этого выходит, что я обязан через n дней удалить информацию о лиде, как бы мне этого сильно не хотелось делать. Как быть? Если необходимость держать у себя контакт лида (само собой и его имя, должность и т.д.), гораздо больший самого большого допустимого периода, по GDPR?


    1. Kanut79
      29.05.2018 09:16
      +2

      Из этого выходит, что я обязан через n дней удалить информацию о лиде, как бы мне этого сильно не хотелось делать. Как быть? Если необходимость держать у себя контакт лида (само собой и его имя, должность и т.д.), гораздо больший самого большого допустимого периода, по GDPR?

      Самый простой, да пожалуй и единственный, вариант это взять у человека реазрешение хранить данные дольше. Если он с этим не согласен, то тогда вам не повезло и придётся удалить.

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


      1. lavmax
        29.05.2018 09:36

        Конкретного срока хранения не указано, но сказано, что можно хранить, только если есть реальная потребность. Т.е. нельзя хранить «на всякий случай».


        1. Kanut79
          29.05.2018 09:39

          Это да, но если человек дал свои данные для лидогенерации, не отозвал их и они всё ещё нужны для этой самой лидогенерации, то их по идее можно хранить.


          1. lavmax
            29.05.2018 09:43

            Это скользкая дорожка. Если на эти данные получено согласие и вы их реально используете в рекламной кампании — можно хранить. Но. Когда кампания закончилась похоже лучше их удалить. Данные тухнут. Профили людей меняются. И реальная необходимость хранения таких данных может быть поставлена под большой вопрос.


            1. Kanut79
              29.05.2018 09:48

              Если брали под конкретную рекламную кампанию, то тогда да. Если человек согласен что данная «кампания» неограничена во времени, то почему бы и нет.

              Я например подписан на ресурсе, который присылает мне рекламу если где-то появились хорошие скидки на интересующие меня продукты или категории продуктов. И это очень удобно и я в общем-то не против если они и дальше будут мне их присылать условно неограниченное время. То есть пока я сам от них не отпишусь.


        1. Radziuk
          29.05.2018 09:46

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