GDPR и Privacy Shield по-русски (для SaaS)

Не так давно Гугл сделал рассылку владельцам G Suite: [ACTION REQUIRED] Rollout of Data Processing Amendment version 2.0 to reflect the GDPR, и это подтолкнуло меня на то, чтобы написать о том, что это такое, и что делать разработчикам SaaS-приложений, так как, кажется, началось. Я не юрист, и наверняка где-нибудь ошибся, но эта статья поможет вам начать (и избежать для компании, в которой вы работаете, штрафов по в £183'000'000, как это случилось у British Airways).

GDPR

General Data Protection Regulation — это новый европейский закон о персональных данных (речь идёт обо всех данных, которые можно связать с конкретным человеком: имя, IP, имейл и т.д.). При этом речь идёт о данных хранимых как в онлайне, так и в оффлайне.

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

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

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

*Лазейка заключается в следующем. Вы можете собирать и хранить данные, которые нам нужны в интересах бизнеса («legitimate interests»), если вы подумали об интересах пользователя («after considering the interests of the individuals involved»). Если она понадобится, см. #5.

Что нужно делать, чтобы быть GDPR compliant? Выделяют 12 основных шагов для комплайенса:

1. Awareness — всем сотрудникам рассказать о данной инициативе.
2. Information you hold — провести инвентаризацию всех потоков информации с персональными данными: убедиться, что не собираем лишнее, не нужное для оказания услуг. Разобраться с теми данными, которые не на месте или уже не нужны, особенно когда они валяются в переписке или в древних бэкапах. Убедиться, что все 3rd party собираются быть compliant (у AWS и прочих крупных сервисов с этим проблем нет).
3. Communicating privacy information — обновить прайваси полиси, написав её простыми словами.
4. Individuals’ rights — сделать так, чтобы права пользователей по просмотру (в машинно-читаемом формате), модификации и удалению данных навсегда были реализованы (автоматически или через саппорт). При удалении удалять и из 3rd party, куда вы послали и откуда можете удалить.
5. Subject access requests — механизм реагирования на запросы пользователей по реализации их прав (отвечать в поддержку на запросы о реализации индивидуальных прав в течение месяца).
6. Lawful basis for processing personal data — обосновать в прайваси, зачем нам каждые конкретные данные, и что вы с ними делаете.
7. Consent — получать прямое согласие пользователя (а не «это было упомянуто в тёрмсах») на сбор персональной информации (например в рассылках: «enter your email address here if you want to receive new product information from us» — ок, «I agree for all shit» — не ок). Давать возможность взять свой консент обратно (например, отписаться от рассылки). Если вдруг будут чувствительные данные (судимость, сексуальность, етц), то там вообще надо чуть ли не попап выводить, мол «согласны ли вы» (как это делают мобильные ОС, выдавая плашки на согласие шаринга гео-данных и т.д.). Логгировать, когда и при каких обстоятельствах былополучено согласие.
8. Children — не пускать европейских детей младше 16 (ряд членов Евросоюза могут понизить ограничение до 13 лет, но это не от нас зависит).
9. Data breaches — необходимо понимать, что такое дата брич в вашем случае, как вы будете оповещать пользователей (немедленно) и как (и куда) европейские органы; но так как у многих обычно нет данных, утечка которых покушается на права и свободы пользователей, то и проблемы нет.
10. Data Protection by Design and Data Protection Impact Assessments — технически соответствовать требованиям безопасности на случаи, чтобы защитить данные, утечка которых приводит к нарушению прав и свобод пользователей.
11. Data Protection Officers — назначить ответственного (почти всем организациям надо, так что проще назначить), при этом у DPO не должно быть конфликта интересов («must not carry out any other tasks that could results in a conflict of interest»), но так как SaaS’ы часто маленькие, ты выбора обычно нет.
12. International — многим неактуально, так как «controllers without any establishment in the EU must deal with local supervisory authorities in every Member State they are active in, through their local representative».

А пока вы это всё реализуете, вы можете повесить на сайт заглушку о том, что к 25 мая 2018 года вы собираетесь быть комплайент. См. пример — https://uploadcare.com/about/gdpr/.

Privacy Shield Framework

Если ваша компания зарегистрирована в США, то вам стоит пройти сертификацию Privacy Shield Framework. Заодно это, по сути, один из методов реализации GDPR.

PSF регулирует правила, по которым данные из Европейского союза (и Швейцарии) могут храниться и обрабатываться в США. Разобраться в PSF намного легче, там на сайте есть правила, как пройти сертификацию.

Что нужно сделать для сертификации EU-US Privacy Shield:

1. Understand Data Flows — описать data flow пользовательских персональных данных в нашей системе

Вам необходимо понять, какие персональные данные вы собираете и храните (или планируете хранить в будущем). От регистрационных данных и данных оплат кредиткой, до полученных от пользователя данных и данных о его поведении на сайте. Всё это необходимо понимать в увязке с 3rd parties сервисами, которые вы используете. В общем, весь путь персональных данных.

2. Update Privacy Policies — создать Privacy Shield Notice и обновить Privacy Policy

Нужно сделать отдельную страницу Privacy Shield Notice, и сослаться на неё из нашей Privacy Policy. Опубликовать изменения надо до подачи на сертификацию.

Privacy Shield Notice должно освещать пункты, описанные в https://www.privacyshield.gov/article?id=1-NOTICE. Если подытожить, то там говорится о:

• должна быть ссылка на эту страницу
• должны быть описаны типы персональных данных, которые вы собираете
• список аффилированных с вами организаций, которые тоже следуют этим принципам
• то, что вы собираетесь всячески следовать Privacy Shield, собирать только нужную для дела информацию
• куда жаловаться, если что-то не устраивает, что дальше делать
• на какую третью сторону вы передаете собранную информацию
• что пользователь может получить доступ к своим данным, и что если вы собираетесь их использовать как-то иначе чем запланировано, то вы дадите ему выбор

Пример: https://uploadcare.com/about/privacy_shield_notice/ и https://uploadcare.com/about/privacy_policy/ соответственно.

3. Revise 3rd party contracts — убедиться, что все сторонние сервисы, которым вы отдаёте данные, также сертифицированы

Вы должны убедиться, что 3rd party, с кем вы работаете, либо сертифицированы, либо по договору должны предоставить всё что требуется по Privacy Shield. Начать следует со списка, который вы получили в 1-м пункте. Скорее всего, вам тут ничего и не понадобится делать.

4. Sign up to independent recourse mechanism — заключить договор с независимой организацией, решающие конфликты, если вы сами не сможете с пользователем договориться

Нужно выбрать и заключить договор с независимой организацией, которая будет независимо разрешать конфликты, если вы сами не сможете с пользователем договориться. Можно использовать европейские организации — http://ec.europa.eu/justice/data-protection/article-29/structure/data-protection-authorities/index_en.htm. Это дешевле всего, стоит $50 — http://privacyshield.uscib.org/. Их сайт глючит принимая оплату, но, думаю, справитесь.

5. Draft internal policies — создать внутреннюю инструкцию и/или механизмы, как вы ведёте себя в случае запроса данных, запроса на удаление данных, отказа от передачи данных третьим лицам и т.д.

От вас ожидают, что вы знаете, что делать, если нам кто-то предъявит, и что у нас это будет зафиксировано.

• Ваши сотрудники должны понимать, когда речь идёт о персональных данных, и знать, куда обратиться внутри организации, чтобы решать проблемы на этот счёт.
• Понятно и предсказуемо реагировать за заявки по поводу персональных данных, отвечая на них в течении 45 дней. Должен быть выделен конкретный человек на это дело, который в том числе не растеряется, если ему напишут внешние органы.
• Обеспечить безопасность данных, иметь Security Policy, контролировать доступ к ним, и иметь ответ на случай взлома.
• Уметь редактировать, изменять или удалять персональные данные по запросу.

Так же вы должны реализовать Choice Principle:

• Opt-out: если вы делитесь с 3rd party персональными данными или используем их не для заранее заявленных целей, вы должны дать пользователю явную возможность отказаться. Это может быть ссылка в Privacy Policy на то, как opt out, или кнопка в настройках профиля пользователя.
• Opt-in: если вы собираетесь делать что-то с чувствительными данными (финансы, секс, здоровье и т.д.), то вы должны получить от пользователя прямое разрешение на это.

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

6. Prepare to Self-Certification — подготовить базовую информацию о своей организации, выбрать крайнего по приватности, податься на само-сертификацию

При подаче заявки необходимо заполнить следующие данные — https://www.privacyshield.gov/article?id=Self-Certification-Information:

• Там надо будет описать, что вы делаете, с акцентом на персональных данных.
• При выборе, затрагиваете ли вы HR данные или нет, выбрать, что нет (хотя в вашем случае может и да).
• Нужно будет дать ссылку на Privacy Statement на сайте и обновить Privacy Policy до подачи заявки.
• Уточнить, не участвуете ли вы в других программах приватности (Privacy Programs).
• Сослаться на внешнюю независимую организацию для разрешения конфликтов.
• Подпись крайнего по приватности (Corporate Officer).

7. Conduct annual compliance assessments — не забывать раз в год проводить внутренний аудит и обновлять сертификацию

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

8. Leaving Privacy Shield or Organization ceased to exist — что делать при выходе из соглашения, или при прекращении деятельности компании

Если организация прекращает своё существование, то необходимо об этом сообщить. При этом если вас, допустим, купят кто-нибудь, кто не в Privacy Shield, то все приватные данные, защищаемые им, необходимо будет удалить. Ну и если вы решите покинуть Privacy Shield, вы должны будете удалить упоминание о нём.

Начните с сертификации в Privacy Shield, повесьте заглушку о планах на GDPR, измените ваш продукт, после чего обновите Privacy Policy ещё раз и оповестите ваших пользователей об изменении Privacy Policy. Удачи. :-)