Штрафов GDPR еще не было? Будут! Все, что нужно знать о защите персональных данных

эксклюзив
31.08.2020 | Автор: Козлов Сергей
Задать вопрос автору
Присоединяйтесь к нам в социальных сетях: telegram viber youtube
Штрафов GDPR еще не было? Будут!  Все, что нужно знать о защите персональных данных    - 69085f5f16cd7145c6ec204a8793b1e9_5f4cdf0d58f6a.jpg

Главный антагонист первого фильма о Терминаторе искусственный интеллект (ИИ) Скайнет не мог знать, как выглядит «правильная» Сара Коннор, только лишь потому, что его разработчики сразу прописали «безопасную» и правильную обработку персональных данных. Впрочем, эта шутка вряд ли произведет некое впечатление на фанатов фантастической саги, но заставит усмехнуться людей из сферы IT, ведь для них сегодня ИИ — это определенный уровень развития технологий, при котором только лишь уменьшается уровень привлечения людей к выполнению отдельных процессов.

И уж совсем не поймут иронии специалисты по GDPR (General Data Protection Regulation), для которых «право на забвение» носителя персональных данных (ПД) – одно из главных условий развития любых технологий, по крайней мере на территории Европейского Союза.

Оглавление:

Как бы там ни было, но на данном этапе развития лигатек-сферы не говорить о защите персональных данных (а для стран ЕС, в отличие от Украины, это не только изображение физического лица - пользователя веб-сайта или мобильных приложений, но и его адрес, почта, телефон) не получится, потому что в противном случае стартап не взлетит, а работающий бизнес – оштрафован. Скептики могут заметить, что пока что в Украине не было ни одного прецедента наложения штрафа за нарушение GDPR. Но это скорее «их» недоработка, чем наше преимущество. В конце-концов, регулятор GDPR просто оштрафует вашего партнера за рубежом, и вряд ли потом можно будет вести речь о надежном сотрудничестве. Так что, если еще несколько лет назад разработчики legaltech-проектов стремились поскорее продать продукт, и просто не думали ни о какой «приватности», то сегодня ситуация в корне иная. Инвестор не будет вкладываться в проект, у которого есть проблемы с защитой персональных данных, потому что через год-два это обязательно приведет к огромным штрафам или полному прекращению деятельности этого стартапа. Или придется инвестировать еще больше денег, чтобы выстроить необходимую инфраструктуру и систему безопасности.

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

Читайтте статью: Чатботы в LegalTech: монетизация проблематична, а перспективы туманны

Почему европейский GDPR изучают во всем мире?

Где-то с 2010-х годов общество осознало, что количество информации, которое производится, настолько велико (и столь стремительно увеличивается), что для того, чтобы эффективно обрабатывать и анализировать хоть какую-то весомую долю из этого массива данных, человеческих усилий уже недостаточно. Поэтому компании начали привлекать к этому различные технологические платформы. Использование искусственного интеллекта для обработки данных позволило ведущим компаниям оптимизировать значительное количество процессов и сделало их аналитику чрезвычайно эффективной. Но, конечно же, активное привлечение ИИ в различные процессы породило и новые проблемы. Ведь среди информации, которую начали активно передавать на обработку и анализ, появилась не только общая или техническая. Чаще всего это именно данные, которые мы называем персональными, то есть такие, которые касаются каких-то конкретных лиц и часто являются составляющей их частной жизни. А безопасность и «правильная» обработка этих данных очень важна, так как необходимы как технические, так и юридические меры для того, чтобы эти аспекты можно было гарантировать.

И именно на выполнение этих задач направлен Регламент GDPR (вступил в силу 25 мая 2018 года), который по мнению его создателей:

  • позволит людям контролировать использование их персональных данных третьими лицами и облегчит доступ к ним;
  • усилит защиту персональных данных от несанкционированного доступа и использования, независимо от того, происходит это на территории ЕС, либо за его пределами;
  • повысит доверие граждан ЕС к держателям их персональных данных, поскольку в результате проведения исследований выяснилось, что 9 из 10 граждан ЕС заявили, что обеспокоены тем, что мобильные приложения, которыми они пользуются, собирают персональные данные без их согласия, а 7 из 10 граждан ЕС считают, что компании используют их персональные данные без их согласия, в том числе в маркетинговых целях.

Кстати, сразу отметим, что деятельность компаний, зарегистрированных в США и которые стремятся осуществлять свою деятельность в пределах Европейского Союза, кроме требований GDPR также регулируется и таким документом как EU-US Privacy Shield, который был подписан между США и Европейским Союзом. Данный документ устанавливает определенные рамки для американских компаний, желающих работать на Европейский рынок, в частности, в контексте обработки персональных данных. Но в случае с США все несколько сложнее, поскольку 16 июля 2020 Европейский суд Европейского союза признал механизм Privacy Shield для передачи персональных данных с ЕС в США недействительным, а стандартные контрактные положения (SCC) поставил под вопрос. Во-первых, Суд установил, что программы слежки и наблюдения в США являются чрезмерными и не соответствуют требованиям ст. 52 Хартии Европейского союза по правам человека. Во-вторых, Суд установил, что субъекты данных ЕС не имеют эффективного средства правовой защиты в США, как того требует ст. 47 Хартии. Эксперты утверждают https://ain.ua/2020/07/30/xranenie-i-obrabotka-dannyx-v-ssha-evropejskij-soyuz-stavit-novye-ogranicheniya/ , что теперь для специалистов в области приватности добавилось работы. Пока Европейская Комиссия не разработает новых договорных положений для передачи данных, компаниям придется оценивать каждый случай хранения и передачи данных в США по отдельности, что создает целый ряд проблем для компаний, а компании, которые использовали Privacy Shield, должны принять альтернативное решение: 1) использовать Standard Contractual Clauses (контрактные положения, разработанные Европейским Союзом для легализации передачи данных в страны без достаточной защиты данных); 2) получить утверждение обязательных корпоративных правил, что не так-то и просто; 3) использовать отступления от правил, предусмотренные ст. 49 GDPR; 4) либо радикальное решение — сменить юрисдикцию для смены пункта назначения передачи данных.

Ситуация в США хоть и оказалась весьма внезапной, однако она четко описывает ситуацию с точки зрения Украины, поскольку наша страна также подпадает под определение «страны без достаточной защиты данных». В любом случае, надо понимать, что нормы GDPR сегодня влияют на legaltech-процессы не только в Европе. Ведь большинство ведущих компаний мира, занимающихся развитием технологий, сделали этот документ своей настольной книгой и используют закрепленные там принципы как best practice, независимо от того, обязаны они это делать или нет. Именно поэтому GDPR играет такую важную роль в определении направлений развития тек-направлений во всем мире.

Итак, GDPR должен обеспечить гражданам ЕС:

  1. Право быть забытым (“right to be forgotten”) — когда лицо более не желает, чтобы данные о нем/ней обрабатывались, и нет никаких оснований для продолжения их обработки контролером, оператором или посредником, персональные данные должны быть удалены. Цель этого права в защите приватности, а не в искажении фактов и событий прошлого или ограничении свободы прессы. Первый камень в разработке европейских норм, гарантирующих "право на забвение" в интернете, был заложен 13 мая 2014 года. Именно в этот день испанец Марио Костеха Гонзалес выиграл в Суде ЕС иск против компании Google Spain, концерна Google Inc. и издательницы газеты La Vanguardia и добился того, чтобы поисковик не выдавал в ответ на запрос, содержащий его имя, ссылки на страницы газеты с информацией о том, что земельный участок Гонзалеса был когда-то продан за долги. Когда же в силу вступил Общий регламент по защите данных, то каждый житель ЕС получил право требовать, чтобы не только поисковые машины, но и любые другие компании не выдавали ссылки на сайты с касающейся пользователя "устаревшей информацией личного характера, если она не имеет общественной значимости". Сегодня эта норма действует также в Швейцарии, Британии, Лихтенштейне, Норвегии и Исландии. Вместе с тем в ЕС разгорелись споры о том, в какой мере отдельно взятый человек может контролировать находящуюся в открытом доступе информацию о нем. В подобных случаях важно соблюдать равновесие между общественным интересом и правом на защиту личных данных. С точки зрения свободы прессы и информации, право на забвение в интернете, по сути, представляет собой "проблематичное изобретение". Ведь решение о том, где проходит граница между правом на свободный доступ к информации и правом на защиту личных данных, на сегодняшний день находится в руках частных компаний.
  2. Право на “портативность” персональных данных (right to data portability) — лица должны иметь больше информации о том, как именно обрабатываются их персональные данные в понятной и доступной манере; должна обеспечиваться возможность автоматической передачи данных от одного контролера к другому (data portability).
  3. Право немедленно знать о краже своих персональных данных в результате хакерского взлома — компании и организации должны немедленно уведомлять национальный контролирующий орган о взломах, которые ставят под угрозу защищенность персональных данных, а в случае повышенного риска немедленно уведомлять субъекта персональных данных, чтобы он/она могли принять соответствующие меры.
  4. Режим защиты персональных данных по умолчанию (Data protection by design and by default) — это ключевые принципы права ЕС о защите данных. Этот пункт наиболее важен для разработчиков любых лигалтех-продуктов, потому что весь процесс разработки мобильных и других приложений должен учитывать требования GDPR еще на самых ранних стадиях (Data protection by design); установки по умолчанию должны максимально обеспечивать право на приватность (privacy-friendly default settings), особенно в социальных сетях и мобильных приложениях (Data protection by default); защита сообщений пользователей должна обязательно сопровождаться шифрованием (encryption).

Субъектами GDPR являются все страны-члены ЕС (в том числе и Великобритания, не смотря на Брекзит) - Австрия, Бельгия, Болгария, Венгрия, Греция, Германия, Дания, Италия, Ирландия, Испания, Республика Кипр, Люксембург, Латвия, Литва, Мальта, Нидерланды, Португалия, Польша, Румыния, Словения, Словакия, Франция, Финляндия, Хорватия, Чехия, Швеция, Эстония, а также Норвегия, Исландия и Лихтенштейн, которые добровольно присоединились к Регламенту, хотя и не являются членами ЕС. Важной особенностью GDPR является также его экстерриториальный характер — в некоторых случаях он распространяется на юридических и физических лиц, а также организации за пределами ЕС, в не зависимости от их согласия.

Украинские компании, конечно же, интересует тот случай, когда требования по соблюдению GDPR распространяется за пределами ЕС, Британии, Норвегии, Исландии и Лихтенштейна, а именно:

  • на контролеров персональных данных (data controllers or administrators) и Операторов персональных данных (data processors), продающих товары и/или предоставляющих услуги (в т.ч. бесплатно) субъектам персональных данных ЕС, Норвегии, Исландии и Лихтенштейна и/или осуществляющих мониторинг персональных данных таких субъектов;
  • на организации, имеющие в ЕС «учреждения» (establishment) где персональные данные обрабатываются “в контексте деятельности” такого учреждения, то есть независимо от того, на территории ЕС, Норвегии, Исландии или Лихтенштейна или нет фактически происходит обработка данных.

Иными словами, признаки соответствия Регламенту можно условно поделить на «однозначные» и «косвенные».

К однозначным признакам относятся следующие:

  • на территории ЕС есть офис, представительство или филиал;
  • один из языков, на котором написан сайт, является государственным в одной из стран ЕС. Сейчас идёт речь не об английском, который признан международным, а о таких языках, как итальянский, испанский, голландский, шведский и так далее;
  • обратная связь с техподдержкой написана на языке одной из стран Европейского союза;
  • есть наличие сервисных центров на территории Европы;
  • есть наличие пунктов выдачи в одной или нескольких странах Евросоюза, либо на сайте компании указано, что доставляете продукцию в ЕС;
  • об услугах компании пишут местные СМИ, либо компания рекламирует свои услуги в Европе;
  • осуществляется мониторинг действий пользователей, например, в мобильном приложении.

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

Также возможны косвенные признаки, к ним относятся:

  • работа с юридическими лицами из ЕС, которые передают персональные данные европейцев и требуют соблюдения GDPR (сейчас это частый случай);
  • конкуренты показали, что соответствуют GDPR, и чтобы не потерять европейских клиентов, не стоит от них отставать.

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

Попробуем привести несколько примеров бизнеса в Украине, которым может быть интересно понимание действия GDPR.

Пример 1. Разработан стартап, который помогает найти юриста (адвоката) в случае, если ему оказали некачественные медицинские услуги. Юристы в базе данных только украинские, и касается споров только в отношении украинских медицинских учреждений. Учитывая, что отдельные виды медицинского туризма в Украине развиты среди иностранцев, то стартап позволяет пользоваться приложением (сайтом), например, на украинском, русском и английском языках.

Комментарий 1. Такой стартап не подпадает под действие GDPR по ни одному из критериев, поскольку он не имеет учреждения на территории ЕС, не нацеливает свои услуги на физических лиц, которые находятся на территории ЕС. Сам факт наличия английской версии сайта не имеет юридических последствий и не затягивает сайт (приложение) под действие GDPR. Но если сайт имеет локальную европейскую версию, например, польский язык, и предлагает полякам онлайн найти юристов в Украине, да еще и есть возможность оплатить «за услугу» в евро – то это однозначно GDPR.

Читайтте статью: Пандемия COVID-19 «встряхнула» рынок legalTech: тренды 2020 года и перспективы на ближайшее будущее

Пример 2. Юридический медиа-ресурс, который предлагает новости, блоги, консультации, в том числе онлайн для тех граждан, которые проживают (путешествуют) по Европе. Часто пользователи посещают ресурс во время своих путешествий, если им необходима консультация по правовым вопросам для Украинцев за рубежом. Веб-сайт, на котором публикуются материалы или происходит видеоконсультация, собирает информацию о посетителях, в частности, IP адреса, геолокацию, длительность посещения, количество переходов между страницами, и тому подобное.

Комментарий 2. Невзирая на то, что де-факто, сайт будет собирать персональные данные пользователей, которые находятся на территории ЕС, среди которых даже будет европейский IP адрес и место расположения пользователя на территории ЕС, GDPR не будет распространять свое действие на него, потому что обработка не связана с деятельностью ресурса в ЕС и не нацелена и прямо не предлагает свои услуги физическим лицам, которые находятся на территории стран Евросоюза. Более простыми словами, ресурс не обязан переживать, что кто-то из его пользователей читает консультацию, как обратиться в полицию в Лондоне, даже если он открыл и использует планшет в Сохо. И наоборот, если создан сайт, на котором потенциально любой житель стран ЕС сможет получить консультацию по этому же вопросу с полицией, то сайт подпадет под GDPR.

Пример 3. Специализированная юридическая компания занимается юридической поддержкой украинцев в Чехии. Веб-сайт компании доступен лишь на украинском языке и расположен на домене .ua. Сайт обрабатывает данные о своих клиентах, которые предоставляются ей во время сотрудничества относительно решения юридических вопросов украинцев в Чехии. Расчет проводится исключительно на банковский счет компании в Украине в гривнях.

Комментарий 3. Все вышеуказанные детали, даже то, что идет речь о данных украинцев, не имеют юридического значения для GDPR, поскольку сайт предлагают свои услуги физическим лицам на территории ЕС и обрабатывают их данные. Этого факта достаточно, чтобы GDPR переключил рубильник в позицию "Вкл" относительно конкретной деятельности украинской компании.

Пример 4. Украинский лигалтех-стартап расположен в Киеве. Стартап разрабатывает программное обеспечение для американских юристов, которое обрабатывает данные относительно торговли ценными бумагами на Нью-Йоркской фондовой бирже, строя разнообразную полезную графику и аналитику. Стартап арендует серверы у провайдера в Польше, где, среди прочего, хранит данные о пользователях.

Комментарий 4. Важным моментом в таком примере будет то, что провайдер в Польше подпадает под действие GDPR и обязан отвечать требованиям закона к процессору персональных данных. Однако, сам стартап из Украины автоматически не попадает под юрисдикцию GDPR, поскольку его деятельность не нацелена на рынок ЕС и он не имеет учреждения там (мы сейчас не говорим о том, что стартап все же будет вынужден учесть требования Калифорнийского акта по защите ПД, но это все же несколько иная проблема). И опять же таки, если бы этот же стартап был зарегистрирован в ЕС, то он однозначно должен и сам подчиняться GDPR.

А тогда причем здесь Privacy by design?

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

Скажем сразу, концепцию privacy by design часто критикуют за отсутствие четкости, поэтому до конца узнать, что вкладывается в нее нелегко. Но к ее пониманию можно приблизиться, проанализировав практику компаний, которые занимаются развитием технологий с соблюдением требований GDPR.

Чтобы обеспечить реализацию privacy by design, компании-разработчики во всем мире сегодня следуют таким принципам.

  1. Меньше автоматизированной обработки

Прежде всего, перед разработчиками встала задача создать условия для соблюдения требований статьи 22 GDPR — чтобы субъект данных имел возможность не подвергаться решению, основанному исключительно на автоматизированной обработке. То есть, чтобы реализовывать концепцию privacy by design компаниям пришлось отойти от понимания ИИ как использования только машинного интеллекта, и привлекать туда интеллект человеческий (то есть работать по системе human-in-the-loop). Для лучшего понимания как работает система human-in-the-loop, приведем такой пример. Представьте платформу, которая была создана для того, чтобы анализировать данные денежных переводов и других транзакций, которые совершают пользователи, и блокировать те, которые имеют признаки мошеннических. Как выгодно и удобно было бы, чтобы машинный интеллект делал все сам — сам проанализировал, сам нашел признаки мошенничества, сам заблокировал. Быстро и дешево! Однако, тогда требования статьи 22 GDPR соблюдены не будут. Тогда как эту систему можно организовать по-другому: машинный интеллект анализирует данные, выделяет признаки мошенничества, и в удобном виде это представляет человеку — вот у нас есть такая транзакция, и вот это действие считается подозрительным — блокировать или нет? И человек смотрит на картинку в целом, и делает вывод и принимает решение о блокировании средств.

  1. Обрабатывать данные без привязки к персоналиям

Организовывать работу любой технологии следует так, чтобы персональные, особенно, чувствительные данные были максимально деперсонифицированы и зашифрованы, где это возможно. Например, когда платформа для определенных целей занимается анализом размера гонорара адвокатов, то важно, чтобы лицо, получающее результат такого анализа, не могло проследить обратный путь и сопоставить данные о лицах и их гонорарах. Такой подход называется differential privacy (которую переводят как дифференциальная приватность). Деперсонификация также критически важна при утечке данных. Ущерб, наносимый утечкой данных, можно свести к минимуму, если информация будет храниться раздельно, и ее будет нелегко сопоставить в единый ряд, чтобы идентифицировать конкретного человека.

  1. Право на забвение? Обязательно!

И последнее, что очень важно при использовании технологий для анализа данных — это право на забвение, что закреплено в статье 17 GDPR. Возникает проблема — как обеспечить удаление персональной информации, если ИИ использует информацию, у него заложена, для того, чтобы учиться? И вообще полное удаление какой-либо информации из памяти машины возможно? А как доказывать, что такая информация была удалена, а не просто глубоко скрыта в памяти AI? Чтобы ответить на эти вопросы нужны отдельные глубинные исследования, поэтому в рамках данной статьи мы оставим их открытыми.

Но факт остается фактом — GDPR это не просто акт, который используют где-то в ЕС некоторые отдельные субъекты, это то, что меняет правила разработки и использования лигалтек во всем мире.

Несколько слов о штрафах

По итогам двухлетнего существования GDPR, уже определились самые популярные «виды» штрафов:

  • недостаточные технические и организационные меры по обеспечению информационной безопасности;
  • недостаточная правовая база для обработки данных;
  • несоблюдение принципов обработки данных;
  • недостаточное выполнение информационных обязательств.

Причем несоблюдение GDPR может иногда касаться просто-таки трагикомических ситуаций. Например, недавно Британский контролирующий орган — Information Commissioner (ICO) - оштрафовал одну из аптек за то, что она оставила около 500 000 документов в незапертых шкафах в своих подсобных помещениях. Впрочем, внимание СМИ привлекают многомиллионные штрафы. Тот же ICO решил побить все рекорды наказаний и на примере British Airways и Marriott International, Inc . продемонстрировать, что бывает в случае выявления проблем в информационной безопасности. Санкции за нарушения для этих компаний достигли € 204,600,000 и € 110,390,200 соответственно (впрочем, они еще могут быть оспорены, хотя и вряд ли).

А ведь нарушения для нашего уха уж больно незначительные. Так, British Airways обошли вниманием фишинговые сайты, которые имитировали связь с компанией и воровали данные пользователей, а Marriott International, Inc., при поглощении другой компании, не проверил законность собранных ею персональных данных. Интересен тот факт, что эти компании самостоятельно сообщили о кибер-инцидентах в системе защиты персональных данных и сотрудничали с контролирующим органом в ходе расследования, а также усовершенствовали свои механизмы безопасности, но все равно попали под раздачу.

Безусловно, что такие штрафы – редкость, и есть многочисленные примеры, где санкции составляют по 2-3 тыс евро всего, но в целом, если вы планируете работать с компаниеми в ЕС или зарегистрировать там свое представительство, то необходимо знать о штрафах следующее.

Читайтте статью: Legal Marketplace - место, где продают и покупают юристов - как работают интернет-магазины юридических услуг

Штрафы до 10 миллионов евро или до 2% от годового мирового оборота предусмотрены за нарушение правил о: получении согласия на обработку данных, относящихся к детям; внедрении технических и организационных мер для обеспечения защиты данных по проекту и по умолчанию; ведении учета операций по обработке персональных данных; сообщении о нарушениях персональных данных в случаях, установленных Регламентом и др.

Штрафы до 20 миллионов евро или до 4% мирового годового оборота предусмотрены за нарушение: основных принципов обработки, включая условия для согласия (статьи 5, 6, 7 и 9 Регламента); права субъектов данных (статьи 12–22 Регламента); правил трансграничной передачи (статьи 44–49 Регламента) и др.

И еще раз акцентируем внимание, штрафы GDPR имеют сложную градацию (по этой ссылке можно увидеть все их разнообразие по разным странам; «улыбнул» штраф в 48 евро, выписанный регулятором в Эстонии https://www.enforcementtracker.com/). То есть за нарушение GDPR стартапу не выставят штраф сразу в 20 млн €, который приведёт к закрытию компании, но он будет ощутим. Или даже это может быть и не штраф вовсе. Например, большую степень вероятности будут иметь и следующие последствия: пользователь вашего сайта увидел несоответствие GDPR и сообщил об этом «своему» регулирующему органу. Регулятор может опубликовать на своем веб-сайте информацию о вашем несоответствии Регламенту и, как следствие, вы потеряете клиентов.

Европейское законодательство устроено таким образом, что компанию, которая работает с контрагентами, не соблюдающими GDPR, штрафуют за работу с неблагонадёжными компаниями, и при этом возможен запрет со стороны регулятора ЕС европейским компаниям работать с вами. Такие последствия очень серьёзны для бизнеса, именно поэтому важно выполнение GDPR для любой компании. Не стоит самим себе закрывать «окно в Европу». В случае игнорирования требований регуляторов, штрафы могут быть переложены на владельца бизнеса. Оплатить штраф, вероятнее всего, попросят таможенные органы в момент пересечения границы одной из стран ЕС.

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

GDPR и законодательство Украины

В Украине полномочия по контролю за соблюдением законодательства о защите персональных данных возложена на Уполномоченного Верховной Рады Украины по правам человека, который руководствуется исключительно Законом Украины «О защите персональных данных». Впрочем, не следует забывать, что в нашей стране также ратифицирована Конвенция о защите частных лиц в отношении автоматизированной обработки данных личного характера №108. Ни директива 95/46/ЕС, ни собственно GDPR для украинских компаний, работающих только лишь на украинский рынок, влияния не имеют.

Безусловно, между GDPR и Законом Украины «О защите персональных данных» есть много общих черт. Например, что логично, оба акта касаются защиты персональных данный физических лиц. Рассматривая вопрос предметной юрисдикции, стоит отметить, что в Законе Украины «О защите ПД» (далее — Закон) указывается, что его действие распространяется на правовые отношения, связанные с защитой и обработкой персональных данных, в частности — на обработку, которая осуществляется полностью или частично с применением автоматизированных или неавтоматизированных средств. Аналогичную сферу действия имеет General Data Protection Regulation, вместе с тем детализируя такое положение и указывая перечень отношений, на которые действие GDPR не распространяется (например, касательно деятельности, выходящей за пределы действия права ЕС и т.д.).

Согласно украинскому Закону, персональными данными являются сведения или совокупность сведений о физическом лице, которое идентифицировано или может быть конкретно идентифицировано. В целом, такое определение персональных данных позаимствовано из текста GDPR и несколько трансформировано. И все же персональные данные согласно GDPR являются более широкой и детализированной категорией, потому что: 1) использует понятие «любая информация, касающаяся личности», а не сведения о лицах (например, название фирмы, в которой используется ФИО лица, будет информацией, касающейся лица, однако не будет сведением о личности); 2) дополнительно разъясняет, когда лицо может считаться таким, которое можно идентифицировать. Поэтому в Украине, никнеймы в Фейсбуке не будут являться персональными данными, а в Европе будут, но при условии, что именно этот никнейм позволит четко идентифицировать личность человека.

Еще более существенной становится разница между этими двумя актами, когда мы проанализируем ответственность за их нарушение. Причем, если мы говорим о штрафах, то здесь разнится даже их природа. В ЕС за нарушение GDPR предусмотрена административная природа наложения штрафа (выписывает контролирующий орган, в каждой стране свой). А в Украине за нарушение национальных норм о защите ПД - судебная. Штрафы за такие нарушения прописаны не в ЗУ “О защите персональных данных”, а в КУоАП и УК Украины. Максимальная сумма штрафа за утечку данных, согласно ст. 188-39 Административного кодекса Украины, — 34 тыс грн. Кроме того, ст.182 УК Украины устанавливает ответственность за распространение конфиденциальной информации о лице или незаконное изменение такой информации (вплоть до ограничения свободы на срок 3 года).

Впрочем, до штрафов в Украине дело доходит редко. Как свидетельствует судебная практика, распространенным способом судебной защиты от незаконного использования персональных данных является предъявление исков о запрете использования персональных данных; исков о понуждении уничтожить информацию, содержащую персональные данные из электронных баз данных. И то так легко бывает не всегда. В Едином государственном реестре судебных решений есть интересное решение Винницкого городского суда Винницкой области от 24 января 2020 года, которым частично удовлетворен коллективный иск в деле № 127/13877/19 к региональной дирекции АО «Укрпочта» об уничтожении данных истцов из электронных баз данных АО «Укрпочты», которые были внесены в них за время предоставления услуг (таких, как оплата коммунальных услуг, отправка писем) без согласия на то потребителей этих услуг, и запрете в будущем при предоставлении услуг вносить персональные данные в автоматизированные системы. Однако, решение это не устояло в апелляционной инстанции, а до кассации не было допущено в силу «малозначительности». http://reyestr.court.gov.ua/Review/91161361

В публичном пространстве наделало шума в ноябре 2019 года и проверка омбудсмена состояния защиты персональных данных в Высшей школе адвокатуры. http://www.ombudsman.gov.ua/ua/all-news/pr/viyavleno-grube-porushennya-prav/ Но такая проверка также не выдержала «испытания» национальным судом.

Читайтте статью: Судебный бизнес при помощи IT-технологий: золотое дно для продвинутых инвесторов!

В ЕС же, как мы отмечали выше, штраф применяется в зависимости от преступления, связанного с персональными данными субъекта, которое совершила компания. Если же вдруг, когда-либо, украинская компания подпадет под действие GDPR, то штраф ей будет выписывать не наш омбудсмен, а «национальный» регулятор по месту нахождения «пострадашего» - например, если будет незаконно обработаны данные гражданина Франции – то Национальной комиссией по информатизации и свободы Франции, если гражданина Финляндии – то их Deputy Data Protection Ombudsman и так далее. «Легализации» штрафа через украинский суд происходить не будет, но вот к сюрпризам на таможне нужно будет быть готовым всегда.

Итак, вы определились, что подпадаете под требования GDPR?

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

Чтобы не попасть на штрафы и не потерять клиентов, необходимо подготовить «минимальный пакет»:

  • уведомления об обработке персональных данных (Privacy Notice). Privacy Notice содержит информацию о том, как персональные данные будут использованы, что с ними будут делать и куда передаваться. Как правило, чтобы не создавать лишний документ, многие европейские коллеги объединяют его с Privacy Policy;
  • Privacy Policy, куда входит общая информация по обработке персональных данных, отношение к обработке данных детей и информация о том, как обрабатываются специальные категории персональных данных и в том числе биометрические данные. Важный момент: Privacy Policy должна быть написана на «понятном языке», а это означает, что её нужно написать в доступной форме на языках тех стран, с которыми вы работаете;
  • Cookie Policy - это политика в отношении сбора cookie-файлов, их обработки, средств обработки и целей использования;
  • политику защиты персональных данных;
  • согласия на обработку персональных данных (в идеале для каждой цели обработки cookie нужно отдельное согласие);
  • дисклеймер об обработке Cookie.

Необязательно создавать много отдельных документа, например, можно создать один Privacy Policy, где будет также отражена информация по Privacy Notice и Cookie Policy. GDPR не регулирует требования к языку, на котором должно быть написано DPA, поэтому будет достаточно прописать соглашение на английском языке. При этом к документу предъявляется ряд требований: об обеспечении безопасности персональных данных, возможности проведения внешнего аудита для проверки исполнения документа, предупреждении контроллера о смене субпроцессоров (ваших подрядчиков при исполнении основного договора) и уведомлении об инцидентах.

Данный перечень действий является практически обязательным для всех компаний, которые работают с ЕС через интернет.

Что необходимо сделать в первую очередь?

GDPR содержит несколько положений, непосредственно связанных с защитой персональных данных, используемых в мобильных приложениях.

Статья 25 устанавливает принцип «data protection by design». Он обязывает контролеров и операторов персональных данных обеспечивать приватность во время всего цикла разработки новых систем или процессов, которые используют персональные данные.

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

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

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

Читайтте статью: Плохие новости, друзья-стартаперы. Президент подписал законопроект 1210 о налоговой реформе

Кроме того, если приложение не только берет у пользователей персональные данные, но и использует их, GDPR обязывает указать в условиях использования (terms of service):

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

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

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

Практические кейсы по GDPR в помощь лигалтех-стартапам

Говоря о соблюдении GDPR как о гарантии успешного развития лигалтек-стартапа в будущем, всегда полезно обратиться к ряду практических рекомендаций.

  1. Разработчику приходится хранить персональные данные пользователей в приложении. Что необходимо сделать в этом случае, чтобы соблюдать требования GDPR? Согласно ст. 83 Регламента с целью обеспечения безопасности и предотвращения обработки персональных данных в нарушение данного Регламента, контролер и оператор должны проводить оценку рисков, присущих процессам обработки персональных данных и принимать меры для уменьшения этих рисков, в частности шифрование (encryption). Эти меры должны обеспечить соответствующий уровень безопасности, включая конфиденциальность, но необходимо брать во внимание современный уровень развития техники и пропорциональность затрат характеру персональных данных, которые необходимо защитить. При расчете рисков следует учитывать степень защищенности персональных данных от несанкционированного доступа третьих лиц и других правонарушений, утраты, изменения, несанкционированного разглашения, передачи, хранения и прочих форм использования персональных данных, которые могут привести к физическому, материальному или неимущественному ущербу.

Многие компании, занимающиеся защитой данных, советуют применять алгоритмы шифрования, в том числе рандомизацию (hashing). Наибольшей уязвимостью мобильных приложений является возможность подвергнуть их реверс-инжинирингу за очень коротких промежуток времени. Это позволяет хакерам проникнуть в структуру мобильного приложения, извлечь из него данные (ключи шифрования, API ключи, и т.д.), которые в последующем могут быть использованы для доступа к персональным данным или взлома с целью изъятия регистрационных данных пользователя (логина, пароля и пр. ).

Для избежания реверс-инжиниринга разработчики должны использовать двойной подход: исходный код мобильного приложения должен быть защищен при помощи мобильных обфускаторов (multiple obfuscation) и технологий шифрования (encryption techniques). Защита кода (сode hardening) мобильного приложения обеспечивает его нечитаемость для хакеров, и, следовательно, невозможность декомпиляции или дизассемблирования; интегрировать в мобильное приложение технологию безопасности «runtime application self-protection». С ее помощью можно защитить приложение от динамического анализа и атак с целью поиска уязвимостей, а также уязвимостей устройства, на котором его запускают.

  1. Обязаны ли разработчики (владельцы) иметь письменный контракт с каждым сторонним сервисом, который используют? Письменный контракт не обязателен. То есть, Регламент предоставляет определенную степень свободы в этом вопросе, употребляя термин «другой юридический документ» («another legal act»). Как понять, что контракт или «другой юридический документ» соответствует требованиям GDPR? Это просто. Проверьте, имеет ли сторонний сервис сертификат соответствия GDPR (certificate of compliance with GDPR). Сертификация является добровольной. К примеру, Firebase, часто используемая при разработке мобильных приложений, в своих правилах указывает, что она полностью соответствует требованиям GDPR. В частности, многие ее сервисы успешно прошли сертификацию ISO 27001, SOC 1, SOC 2, SOC 3, ISO 27017 и ISO 27018.
  2. Мобильное приложение использует только email и логин (без имени и фамилии). Считается ли это персональными данными? Да, считается. Несмотря на то, что не существует простого метода выяснить содержит ли адрес e-mail персональные данные или нет, человек может использовать его как ник или логин на многих сайтах, порталах или социальных сетях, что позволит его связать с другими персональными данными. Согласно GDPR, даже если приложение, в котором пользователь указывает свои персональные данные, не содержит никаких данных, позволяющих его идентифицировать, разработчики должны предусмотреть такую возможность.
  3. Авторизация в приложении происходит через Facebook, Google+, LinkedIn, Instagram и т.д. Приложение шлет token в backend, который автоматически читает ID пользователя (или e-mail), но не имя и фамилию. В течении валидности токена (30 минут) кто-то теоретически может использовать его для того, чтобы извлечь персональные данные вручную. Являются ли это нарушением GDPR? Ответить на этот вопрос однозначно очень сложно. Разработчики должны исходить из того, что, как и в первом кейсе, любая информация о пользователе, которая позволяет его идентифицировать, считается персональными данными, а значит, на нее распространяется режим GDPR, и извлечение этих данных будет нарушением Регламента. С другой стороны, согласно GDPR, для получения персональных данных необходимы обоснованные затраты и издержки, что немного смягчает тон вышеизложенного правила. На сегодняшний день, без сложившейся судебной практики, крайне сложно сказать, какое решение примет суд в подобной ситуации.
  4. В системе случилась утечка данных. Что делать? Об утечке данных необходимо сообщить контролирующему органу в течение 72 часов с момента, когда стало о ней известно, если только она не связана с утечкой персональных данных, нарушающих права и свободы физических лиц. Если сообщить контролирующему органу о такой утечке в течение 72 часов не удалось, необходимо объяснить причины задержки.

А на завершение предлагаем ознакомиться с чек-листом, как подготовить собственное приложение (или веб-сайт) к GDPR:

  • ознакомиться с требованиями Общего регламента по защите данных;
  • сформировать дорожную карту для работы с ПД в рамках приложения;
  • интегрировать интерфейсные элементы для сбора согласия;
  • подготовить инструкцию с описанием действий при утечке ПД;
  • ввести практику шифрования ПД и каналов связи;
  • провести ревизию партнёрских сервисов и SDK;
  • проверить надёжность системы авторизации пользователей;
  • убедиться в безопасности работы с данными о местоположении;
  • рассмотреть возможность перехода на виртуальную инфраструктуру;
  • проверить соответствие SLA облачного провайдера требованиям GDPR.

Источник: юридический ресурс Протокол

Читайтте статью: Legal Tech: Балансирование между технологиями и управлением правовыми проектами

930
Просмотров
0
Комментариев
Оставьте Ваш комментарий:

Пожалуйста, авторизуйтесь или зарегистрируйтесь для добавления комментария.


Популярные судебные решения
ЕСПЧ
1