Принимая во внимание статью 70 (1e) Регламента 2016/679 / ЕС Европейского парламента и Европейского Совета от 27 апреля 2016 года по защите физических лиц в отношении обработки персональных данных и о свободном перемещении таких данных, и отменяя Директиву 95/46 / EC], (далее- «GDPR»),

Принимая во внимание Соглашение ЕЭЗ и, в частности, Приложение XI и Протокол к нему с поправками, внесенными Решением Объединенного комитета ЕЭЗ № 154/2018 от 6 июля 2018 года,

Принимая во внимание статью 12 и статью 22 Процедурных норм от 25 мая 2018 года с последними поправками, внесенными 12 ноября 2019 года.

ПРИНЯЛ СЛЕДУЮЩЕЕ РУКОВОДСТВО

Резюме

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

В настоящем Руководстве даны общие указания по обязательству спроектированной защиты персональных данных и по умолчанию (далее «DPbDD»), изложенных в ст. 25 GDPR. DPbDD является обязательством для всех контролеров, независимо от размеров и сложности обработки. Чтобы реализовать требования DPbDD, очень важно, чтобы контроллер понимал принципы защиты данных и права и свободы субъекта данных.

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

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

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

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

1. В Руководстве основное внимание уделяется реализации контролером принципов спроектированной защиты персональных данных и по умолчанию(DPbDD) на основе обязательства, предусмотренного в статье 25 GDPR.[1] Другие участники, такие как процессоры и производители продуктов, услуг и приложений (далее – производители), которые напрямую не рассматриваются в статье 25, также могут найти эти Руководящие принципы полезными при создании продуктов и услуг, соответствующих GDPR, которые позволяют контроллерам выполнять их обязательства по защите данных.[2] Преамбула 78 GDPR указывает на то, что DPbDD следует учитывать при проведении публичных торгов. Несмотря на то, что все контролеры обязаны интегрировать DPbDD в свою деятельность по обработке персональных данных, это положение способствует принятию принципов, где органы государственного управления должны подавать пример. Контроллер отвечает за выполнение обязательств DPbDD по обработке данных, выполняемых его процессорами и субпроцессорами, поэтому он должен учитывать это при заключении договоров с этими сторонами.

_{[1] Толкования, приведенные в данном документе, в равной степени относятся к статье 20 директивы (ЕС) 2016/680 и статье 27 Регламента 2018/1725.}

_{[2] Преамбула 78 GDPR четко заявляет об этой необходимости: “При разработке, проектировании, выборе и использовании приложений, услуг и товаров, которые основаны на обработке персональных данных либо осуществляют обработку персональных данных для выполнения своих задач, производители таких товаров, услуг и приложений должны мотивировано учитывать право на защиту данных при разработке и проектировании таких товаров, услуг и приложений, и, с учетом текущего уровня научно-технического прогресса, делать все необходимое для того, чтобы контролёры и процессоры были в состоянии исполнять свои обязанности по защите данных”.}

2. Требование, изложенное в Статье 25, заключается в том, что контролеры должны предусмотреть спроектированную систему защиты персональных данных, а также настройки по умолчанию на протяжении всего жизненного цикла обработки данных. DPbDD является также требованием для систем обработки, существовавших до вступления в силу GDPR. Контроллеры должны постоянно обновлять обработку в соответствии с GDPR. Подробнее о том, как поддерживать существующую систему в соответствии с DPbDD, см. в подразделе 2.1.4 настоящего Руководства. Суть этого положения заключается в обеспечении эффективной защиты персональных данных как спроектированной, так и по умолчанию, что означает, что контроллеры должны демонстрировать тот факт, что они применяют соответствующие меры безопасности, обеспечивающие применение принципов защиты персональных данных и соблюдение прав,свобод субъектов данных.

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

4. В Руководстве рассматривается возможность создания механизма сертификации для демонстрации соблюдения статьи 25 – в Четвертой главе, а также о том, как эта статья может применяться в надзорном органами власти – в главе пятой. В конце, Руководство дает заинтересованным сторонам дальнейшие рекомендации о том, как успешно внедрить DPbDD. EDPB осознает трудности, с которыми сталкиваются малые и средние предприятия ( далее – “МСП”) при выполнении обязательств DPbDD в полном объеме, и представляет дополнительные рекомендации конкретно для МСП в Главе 6.

5. Цель этой главы – изучить и дать рекомендации по требованиям к спроектированной защите персональных данных, изложенным в статье 25 (1) GDPR, и защите данных по умолчанию, изложенных в статье 25 (2) GDPR соответственно. Спроектированная защита данных и защита данных по умолчанию являются взаимодополняющими концепциями, которые оказывают друг на друга взаимное усиливающее воздействие. Субъекты данных получат больше преимуществ от защиты данных по умолчанию, если одновременно будет обеспечиваться спроектированная защита данных – и наоборот.

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

7. В соответствии со ст. 25 (1) контролер должен принять соответствующие технические и организационные меры, разработанные для реализации принципов защиты персональных данных и интегрировать необходимые меры защиты в обработку с целью удовлетворения требований и защиты прав субъектов данных. Как надлежащие меры, так и необходимые меры защиты призваны служить одной и той же цели – защите прав субъектов данных и обеспечению защиты их персональных данных при обработке.

8. Термин “технические и организационные меры и необходимые меры защиты” понимается в широком смысле как любые методы и средства, которые контролер может использовать в обработке. Эти меры должны быть соответствующими, что означает, что эти меры, а также меры защиты должны подходить достижению намеченной цели, то есть они должны эффективно внедрять принципы защиты персональных данных.[3] Таким образом требование “соответствия” тесно связано с требованием “эффективности”.

_{[3] «Эффективность» рассматривается ниже в подразделе 2.1.2.}

9. Технической или организационной мерой, а также необходимой мерой защиты может быть что угодно, начиная от использования передовых технических решений и заканчивая базовым обучением персонала. Примеры, которые могут быть подходящими, в зависимости от контекста и рисков, связанных с рассматриваемой обработкой, включают псевдонимизацию персональных данных;[4] хранение доступных персональных данных в структурированном, обычно машиночитаемом формате; предоставление возможности субъектам данных вмешиваться в обработку; предоставление информации о хранении персональных данных; наличие систем обнаружения вредоносных программ; обучение сотрудников основам «кибергигиены»; создание систем управления приватностью и информационной безопасностью, обязательство процессоров по контракту применять определенные методы минимизации данных и т. д.

_{[4] Определяется в статье 4(5) GDPR}

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

11. Принципы защиты персональных данных приведены в статье 5 GDPR (далее – принципы), права и свободы субъектов данных – это основные права и свободы физических лиц, в частности, их право на защиту персональных данных, защита которого определена в ст.1(2) в качестве цели GDPR (далее – “права”).[5] Точная формулировка содержится в Хартии ЕС об Основных Правах. Важно, чтобы контролер имел представление о значении принципов и прав как об основе защиты, обеспечиваемой GDPR, в частности, в рамках обязательства DPbDD.

_{[5] См. Преамбулу 4 GDPR.}

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

Эффективность решения

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

15. Во-первых, это означает, что статья 25 не требует осуществления каких-либо конкретных технических и организационных мер, а скорее указывает, что избранные меры и гарантии должны быть конкретно направлены на внедрение принципов защиты данных в конкретную обработку. При этом меры и гарантии должны быть разработаны таким образом, чтобы они были надежными, а контролер должен иметь возможность осуществлять дальнейшие меры в целях масштабирования с учетом любого увеличения риска.[6] Поэтому эффективность мер будет зависеть от контекста обработки и оценки определенных элементов, которые должны учитываться при определении средств обработки. Вышеупомянутые элементы будут рассмотрены ниже в подразделе 2.1.3.

_{[6] «Основные принципы, применимые к контролерам (то есть легитимность, минимизация данных, ограничение целей, прозрачность, целостность данных, точность данных) должны оставаться неизменными, независимо от обработки и рисков для субъекты данных. Однако должное внимание к характеру и объему такой обработки всегда было часть применения этих принципов, так что они по своей природе масштабируемы». Статья 29 Рабочая группа. «Заявление о роли подхода, основанного на оценке риска, в правовых рамках защиты данных». РГ 218, 30 мая 2014 года, p3.}

15. Во-вторых, контролеры должны быть в состоянии продемонстрировать, что принципы были соблюдены.

16. Реализуемые меры и гарантии должны достигать ожидаемого результата с точки зрения защиты данных, а контроллер должен иметь документацию о реализованных технических и организационных мерах.[7] Для этого контролер может определить соответствующие ключевые показатели эффективности (KPI) для демонстрации результативности. KPI – это измеряемая величина, выбранная контроллером, которая демонстрирует, насколько эффективно контроллер достигает поставленной цели защиты персональных данных. KPI могут быть количественными, такими как процент ложноположительных или ложноотрицательных результатов, сокращение количества жалоб, сокращение времени реагирования при осуществлении субъектами данных своих прав; или качественными, такими как оценка эффективности, использование шкал оценок или экспертные оценки. В качестве альтернативы контролеры могут представить обоснование своей оценки эффективности выбранных мер и гарантий.

_{[7] См. Преамбулы 74 и 78.}.

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

2.1.3.1 текущий уровень научно-технического прогресса

18. Понятие “уровень научно-технического прогресса” присутствует в различных актах ЕС, например, в области охраны окружающей среды и безопасности продукции. В GDPR ссылка на “уровень научно-технического прогресса” [8] содержится не только в статье 32, касающейся мер безопасности, [9][10] но и в статье 25, что позволяет распространить этот критерий на все технические и организационные меры, встроенные в обработку.

_{[8] См. Решение Федерального конституционного суда Германии «Калкар» в 1978 году. Оно может послужить основой для методологией для определение понятия. Исходя из этого «уровень научно-технического прогресса » будет определяться между технологическим уровнем «существующих научных знаний и исследований» и более устоявшихся «общепринятых правил». «Уровень научно-технического прогресса », следовательно, может быть идентифицирован как технологический уровень услуги и технологии или продукта, который существует на рынке и является наиболее эффективным для достижения поставленных целей.}

_{[9] https://www.enisa.europa.eu/news/enisa-news/what-is-state-of-the-art-in-it-security}

_{[10] www.teletrust.de/en/publikationen/broschueren/state-of-the-art-in-it-security/}

19. В контексте статьи 25 ссылка на «уровень научно-технического прогресса» обязывает контролеров, при определении соответствующих технических и организационных мер принять во внимание текущий прогресса в технологиях, доступных на рынке. Требование заключается в том, что контролеры должны знать о технологических достижениях, о том, как технологии могут представлять опасность или создавать возможности в области защиты персональных данных при обработке, а также о том, как реализовать меры и гарантии, которые обеспечивают эффективную реализацию принципов и прав субъектов данных с учетом развивающейся технологической среды.

20. «Уровень научно-технического прогресса» – это динамическая концепция, которая не может быть статически определена в определенный момент времени, но должна оцениваться постоянно в контексте технического прогресса. Перед лицом технологических достижений, контролер может обнаружить, что мера, которая ранее обеспечивала адекватный уровень защиты, больше этого не делает. Поэтому пренебрежение технологическими изменениями может впоследствии привести к несоблюдению статьи 25.

21. Критерий “уровень научно-технического прогресса” применим не только к технологическим мерам, но и к организационным. Отсутствие соответствующих организационных мер может снизить или даже полностью подорвать эффективность выбранной технологии. Примерами организационных мер могут быть принятие внутренних политик; современное обучение в области технологий, безопасности и защиты персональных данных; а также политики управления и менеджмента информационной безопасностью.

22. Существующие и признанные стандарты, сертификации, кодексы поведения и т.д. в различных областях могут сыграть роль в определении текущего «уровня научно-технического прогресс» в рамках данной области. Там, где такие стандарты существуют и обеспечивают высокий уровень защиты субъекта данных в соответствии с правовыми требованиями или превосходят их, контролеры должны учитывать их при разработке и реализации мер по защите данных.

2.1.3.2 “затраты на внедрение”

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

24. Элемент затрат не требует от контроллера расходования непропорционально большого объема ресурсов, когда существуют альтернативные, менее ресурсозатратные, но при этом эффективные меры. Тем не менее, затраты на внедрение являются фактором, который следует рассматривать для реализации спроектированной защиты персональных, а не как основание для ее невыполнения.

25. Таким образом, выбранные меры должны обеспечить, чтобы деятельность по обработке, предусмотренная контролером, не обрабатывала персональные данные в нарушение принципов, независимо от затрат. Контролеры должны быть в состоянии управлять общими затратами, чтобы иметь возможность эффективно реализовывать все принципы и, соответственно, защищать права субъектов данных.

2.1.3.3 “характер, масштаб, контекст и цели обработки”

26. При определении необходимых мер контролеры должны принимать во внимание характер, масштаб, контекст и цель обработки.

27. Эти факторы должны интерпретироваться в соответствии с их значением в других положениях GDPR, например, в статьях 24, 32 и 35, с целью проектирования принципов защиты данных при обработке.

27. Иными словами, характер можно понимать как неотъемлемую[11] характеристику обработки. “Сфера действия” относится к размеру и направлению обработки. “Контекст” относится к обстоятельствам обработки, которые могут влиять на ожидания субъекта данных, в то время как “цель” относится к целям обработки.

_{[11] Примерами являются специальные категории персональных данных, автоматизированное принятие решений, дисбаланс властных отношений, непредсказуемая обработка, трудности для субъекта данных в осуществлении прав и т.д.}

2.1.3.4 “вероятность и серьезность риска для прав и свобод субъекта данных, вызванная обработкой”

29. Во многих положениях GDPR, а именно в статьях 24, 25, 32 и 35, применяется последовательный подход, основанный на оценке рисков, с целью определения соответствующих технических и организационных мер по защите физических лиц, их персональных данных и соблюдения требований GDPR. Объекты защиты всегда одни и те же (физические лица, путем защиты их персональных данных), от одних и тех же рисков (для прав физических лиц), с учетом одних и тех же условий (характер, масштаб, контекст и цели обработки).

30. При проведении анализа рисков на соответствие требованиям статьи 25, контролер должен выявить риски для прав субъектов данных, которые представляют собой нарушение принципов, а также определить их вероятность и серьезность для принятия мер по эффективному снижению выявленных рисков. Систематическая и тщательная проверка обработки данных имеет решающее значение при проведении оценки рисков. Например, контролер оценивает конкретные риски, связанные с отсутствием свободного согласия, что является нарушением принципа законности, в процессе обработки персональных данных детей и подростков до 18 лет, как уязвимой группы, в случае отсутствия других правовых оснований, и внедряет соответствующие меры по устранению и эффективному снижению выявленных рисков, связанных с этой группой субъектов данных.

31. «Руководство EDPB по оценке воздействия на защиту данных (DPIA)»,[12] которое уделяет особое внимание возможности операций обработки привести к высокому риску для субъекта данных, а также даёт указания о том, как оценивать риски защиты данных и способы проведения оценки рисков защиты данных. Эти руководящие принципы могут также быть полезны при оценке риска во всех упомянутых выше статьях, включая статью 25.

_{[12] Статья 29 рабочей группы “Руководство по оценки воздействия на защиту данных (DPIA) и определения того, может ли обработка данных привести к высокому риску” для целей регламента 2016/679″. WP 248 REV. 01, 4 Октябрь 2017 года.}

32. Подход, основанный на оценке риска, не исключает использования исходных условий, передовой практики и стандартов. Они могут предоставить контроллерам полезный инструментарий для решения аналогичных рисков в аналогичных ситуациях (характер, объем, контекст и цель обработки). Тем не менее, обязательство в статье 25 (а также в статьях 24, 32 и 35(7)(c)) учитывать “риски различной вероятности и серьезности для прав и свобод физических лиц, связанные с обработкой”, остается неизменным. Таким образом, контролеры, хотя и поддерживаемые такими инструментами, должны всегда проводить оценку рисков в области защиты данных в каждом отдельном случае в отношении рассматриваемой деятельности по обработке и проверять эффективность предлагаемых соответствующих мер и гарантий. В этом случае может потребоваться проведение дополнительной оценки воздействия на защиту персональных данных или обновление существующей оценки воздействия на защиту персональных данных (DPIA).

33. Спроектированная защита персональных данных должна осуществляться «во время определения средств для обработки».

2.1.4.1 Во время определения средства для обработки

34. «Средства обработки» варьируются от абстрактных до конкретных проектируемых элементов обработки, таких, как архитектура, процедуры, протоколы, макет и внешний вид.

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

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

2.1.4.2 Во время самой обработки

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

38. Обязанность поддерживать, пересматривать и обновлять, по мере необходимости, процесс обработки также распространяется на ранее существовавшие системы. Это означает, что прежние системы, разработанные до вступления в силу GDPR, должны проходить проверку и обновление, чтобы обеспечить реализацию мер и гарантий, которые реализуют принципы и права субъектов данных эффективным образом, как это указано в настоящем Руководстве.

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

По умолчанию

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

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

42. Контроллер должен выбирать и быть ответственным за реализацию настроек и параметров обработки по умолчанию таким образом, чтобы по умолчанию выполнялась только та обработка, которая строго необходима для достижения поставленной, законной цели. В данном случае, контроллеры должны полагаться на свою оценку необходимости обработки с точки зрения правовых оснований, указанных в Статье 6(1). Это означает, что по умолчанию контролер не должен собирать больше данных, чем необходимо, он не должен обрабатывать собранные данные дольше, чем это необходимо для его целей, а также не должен хранить данные дольше, чем это необходимо. Основным требованием является то, что защита данных встроена в процесс обработки по умолчанию.

43. Контролер обязан заранее определить, конкретно для каких явных и легитимных целей персональные данные собираются и обрабатываются.[13] Средства, применяемые по умолчанию должны быть подходящими для того, чтобы обеспечить обработку только тех персональные данных, которые необходимы для каждой конкретной цели обработки. Руководство EDPS по оценке необходимости и соразмерности применяемых мер, ограничивающих право на защиту персональных данных, может быть полезно также для того, чтобы решить, какие персональные данные необходимо обработать для достижения определенной цели.[14] [15] [16]

_{[13] Ст. 5(1)(b), (c), (d), (e) GDPR}

_{[14] EDPS. “Руководящие принципы оценки необходимости и соразмерности мер, ограничивающих право на защиту данных”. 25 февраля 2019 г. edps.europa.eu/sites/edp/files/publications/19-02-. 15 _proportionality_guidelines_en.pdf}

_{[15] См. также EDPS. “Оценка необходимости мер, ограничивающих основное право на защиту персональных данных: Инструментарий” https://edps.europa.eu/data-protection/our- work/publications/papers/necessitytoolkit_en}

_{[16] Более подробную информацию о необходимости см. в статье 29 Рабочей группы. “Мнение 06/2014 о понятии легитимных интересов владельца данных в соответствии со статьей 7 Директивы 95/46/ЕС”. WP 217, 9 апреля 2014 года. ec.europa.eu/justice/article-29/documentation/opinion-recкомендации/files/2014/wp217_en.pdf}

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

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

46. Соответствующие “технические и организационные меры” в контексте защиты данных по умолчанию, таким образом, понимаются так же, как это обсуждалось выше в подразделе 2.1.1, но применяются специально для реализации принципа минимизации данных.

47. Вышеупомянутое обязательство обрабатывать только те персональные данные, которые необходимы для определенной цели, распространяется на следующие элементы.

48. В ст. 25 (2) уточняется объем обязательства по минимизации обработки данных по умолчанию, и указывается, что это обязательство распространяется на объем собранных персональных данных, степень их обработки, период их хранения и их доступность.

2.2.2.1 “объем собранных персональных данных”

49. Контроллеры должны учитывать как объем персональных данных, так и виды, категории и уровень детализации персональных данных, требуемых для целей обработки. При их выборе должны учитываться повышенные риски, связанные с принципами целостности и конфиденциальности, минимизации данных и ограничения их хранения при сборе больших объемов детализированных персональных данных; а также должно осуществляться сравнение их с уменьшением рисков при сборе меньших объемов и/или менее детализированной информации о субъектах данных. В любом случае, параметры по умолчанию не должны включать сбор персональных данных, который не являются необходимыми для конкретной цели обработки. Другими словами, если определенные категории персональных данные не нужны или если детализированные данные не нужны потому, что достаточно менее детализированных данных, тогда никакие дополнительные персональные данные не должны собираться.

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

2.2.2.2 “степень их обработки”

51. Операции обработки,[17] выполняемые над персональными данными должны быть ограничены лишь тем, что необходимо. Многие операции обработки способствуют достижению целей обработки. Тем не менее, тот факт, что персональные данные необходимы для выполнения определенной цели, не означает, что все виды обработок, а также любая частота обработки данных допустимы. Контроллеры также должны быть осторожны, чтобы не пересечь границы “совместимых целей” (ст. 6 (4)), и иметь в виду, что обработка будет осуществляться в пределах разумного ожидания субъектов данных.

2.2.2.3 “срок их хранения”

52. Собранные персональные данные не подлежат хранению, если они не являются необходимыми для цели обработки и нет другой совместимой цели и правового основания в соответствии со статьей 6 (4). Любое хранение должно быть объективно оправдано, по мере необходимости, контролером данных в соответствии с принципом подотчетности.

53. Контроллер должен ограничить срок хранения до срока, необходимого для этой цели. Если персональные данные больше не являются необходимыми для целей обработки, то они по умолчанию удаляются или анонимизируются. Таким образом, длительность срока хранения будет зависеть от цели обработки. Это обязательство напрямую связано с принципом ограничения хранения в соответствии со статьей 5(1)(e), и должно выполняться по умолчанию, т.е. контролер должен иметь систематические процедуры удаления или анонимизации данных, встроенные в процесс обработки.

54. Анонимизация [18] персональных данных является альтернативой удалению при условии учета всех соответствующих контекстуальных элементов и регулярной оценки вероятности и серьезности риска, включая риск повторной идентификации [19].

_{[18] Статья 29 Рабочей Группы. “Opinion 05/2014 on Anonymisation Techniques”.}

_{[19] См. статью 19. 4(1) GDPR, Recital 26 GDPR, статья 29 Рабочая группа “Мнение 05/2014 о методах анонимизации”. См. также подраздел “Ограничения хранения” в разделе 3 настоящего документа, где говорится о необходимости того, чтобы контролер обеспечивал эффективность применяемых методов анонимизации}

2.2.2.2 “the extent of their processing”

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

56. Статья 25 (2) далее определяет, что персональные данные не могут быть доступны без вмешательства физического лица, направленного на неопределенное число физических лиц. Контроллер должен по умолчанию ограничивать их доступность и предоставить субъекту данных возможность вмешаться перед публикацией или иным образом предоставлением доступа к персональным данным неопределенному кругу физических лиц.

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

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

59. Даже в том случае, если персональные данные предоставляются публично с разрешения и согласия субъекта данных, это не означает, что любой другой контролер, имеющий доступ к персональным данным, может свободно обрабатывать их самостоятельно для своих целей -должно быть отдельное правовое основание [20].

_{[20] См. дело Satakunnan Markkinapörssi Oy and Satamedia Oy v. Finland no. 931/13.}

60. На всех этапах проектирования процесс обработки, включая закупки, тендеры, аутсорсинг, разработку, поддержку, обслуживание, тестирование, хранение, удаление и т. д., контролер должен учитывать и рассматривать различные элементы DPbDD, которые будут проиллюстрированы с помощью примеров из этой главы, а именно: в контексте реализации этих принципов. [21] [22] [23]

_{[21] Дополнительные примеры можно найти в документе Норвежского управления по защите данных. “Разработка программного обеспечения с данными Защита по конструкции и по умолчанию”. 28 ноября 2017 года. www.datatilsynet.no/en/about- privacy/virksomhetenes-plikter/innebygd-personvern/data-protection-by-design-and-by-default/?id=7729}

_{[22] https://www.cnil.fr/en/cnil-publishes-gdpr-guide-developers}

_{[23] https://www.aepd.es/sites/default/files/2019-12/guia-privacidad-desde-diseno_en.pdf}

61. Контроллеры должны реализовать принципы достижения DPbDD. Эти принципы включают в себя: прозрачность, законность, справедливость, ограничение целью, минимизацию данных, точность, ограничение хранения, целостность и конфиденциальность, а также подотчетность. Эти принципы изложены в Статье 5 и Преамбуле 39 GDPR. Для полного понимания того, как осуществлять DPbDD, подчеркивается важность понимания значения каждого из принципов.

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

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

64. Принцип подотчетности является всеобъемлющим: он требует, чтобы контролер был ответственным за выбор необходимых технических и организационных мер.

65. Контроллер должен быть ясным и открытым для субъектов данных в отношении того, как он будет собирать, использовать и распространять персональные данные. Прозрачность – это то, что позволяет субъектам данных понять и, если необходимо, использовать их права, закрепленные в статьях 15-22. Этот принцип закреплен в статьях 12, 13, 14 и 34 GDPR. Следует также принять меры и гарантии в поддержку принципа прозрачности для поддержания осуществления положений этих статей

3.1 Прозрачность [24]

_{[24] Более подробно о том, как понимать концепцию прозрачности, можно прочитать в документе Рабочей группы по статье 29 “Руководящие принципы прозрачности согласно Регламенту 2016/679”. WP 260 rev.01, 11 апреля 2018 года: ec.europa.eu/newsroom/article29/document.cfm?action=display&doc_id=51025 – одобрено EDPB}

65. Ключевые элементы спроектированной приватности по умолчанию в соответствии с принципом прозрачности могут включать в себя:

•Ясность – информация должна быть изложена ясным и понятным языком, должна быть краткой и понятной.

•Семантика – коммуникация должна быть понятной для аудитории.

•Доступность – информация должна быть легкодоступной для субъекта данных.

•Контекстуальная – информация должна предоставляться в соответствующее время и в надлежащее форме.

•Релевантность– информация должна быть релевантной и применимой к конкретному субъекту данных.

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

•Понятность – субъекты данных должны иметь разумное понимание того, что они могут ожидать от обработки их персональных данных, особенно в тех случаях, когда субъекты данных являются детьми или другими уязвимыми группами населения.

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

• Многоуровневая – Информация должна быть многоуровневой, чтобы устранить противоречие между целостностью и пониманием, учитывая при этом обоснованные ожидания субъектов данных.

Пример [25]

_{[18] Французское управление по защите данных опубликовало несколько примеров, иллюстрирующих передовой опыт в информировании пользователей, а также другие принципы прозрачности: https://design.cnil.fr/en/.}

Контролер разрабатывает политику конфиденциальности на своем веб-сайте для того, чтобы соответствовать требованиям прозрачности. Политика конфиденциальности не должна содержать большой объем информации, которая является сложной для восприятия среднестатистическим субъектом данных. Она должны быть написана простым и лаконичным языком, чтобы пользователь сайта понимал, как обрабатываются его персональные данные. Для этих целей контроллер предоставляет информацию в многоуровневом виде, где наиболее важные моменты выделяются. Более детальная информация легко доступна. Раскрывающиеся меню и ссылки на другие страницы предоставляются для дальнейшего разъяснения этих понятий в политике конфиденциальности. Контроллер также следит за тем, чтобы информация предоставлялась в многоканальном режиме, представляющем собой видеоклипы для объяснения наиболее важных моментов написанной информации. Связь между различными страницами крайне важна для того, чтобы многоуровневый подход не усиливал путаницу, а скорее уменьшал ее.

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

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

67. Контролер должен определить действительное правовое основание для обработки персональных данных. Меры и гарантии должны подкреплять требование соответствия цикла хранения и обработки данных (processing lifecycle) надлежащему правовому основанию обработки.

3.2 Законность

68. Ключевые элементы спроектированной приватности и параметров по умолчанию в соответствии с принципом законности:

• Релевантность – к обработке должно быть применено верное правовое основание

• Дифференциация [26] – контролер должен разграничивать правовое основания, используемые для каждого отдельного вида обработки.

_{[26] EDPB. «Руководство 2/2019 по обработке персональных данных в соответствии со статьей 6 (1) (b) GDPR в контексте предоставление онлайн-услуг субъектам данных ». Версия 2.0, 8 октября 2019 г.}

• Конкретная цель – соответствующее правовое основание должно быть четко связано с определенной целью обработки. [27]

_{[27] Смотрите раздел об ограничении целей ниже}

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

• Автономность – субъекту данных должна быть предоставлена наиболее возможная автономия в отношении контроля над личными данными в рамках правового основания.

• Получение согласия – согласие должно даваться свободно, конкретно, осознанно и недвусмысленно [28]. Особое внимание следует уделять способности детей и подростков давать информированное согласие.

_{[28] См. руководящие принципы 05/2020 о согласии на основании Регламента 2016/679. https://edpb.europa.eu/our-worktools/our- documents/guidelines/guidelines-052020 consent-under-regulation-2016679_en}

• Отзыв согласия – в тех случаях, когда согласие является правовым основанием, обработка должна предоставлять субъекту возможность отзывать согласие. Отзыв согласия должен быть таким же простым, как и само согласие. В противном случае механизм согласия контролера не соответствует GDPR [29].

_{[29] См. Руководящие принципы 05/2020 об изъявлении согласия на основании Регламента 2016/679, стр. 24. https://edpb.europa.eu/our- worktools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en}

• Сочетание интересов. В тех случаях, когда легитимнеык интересы являются правовым основанием, контролер должен оценивать сочетание интересов, уделяя особое внимание дисбалансу сил, в частности, детям в возрасте до 18 лет и другим уязвимым группам. Должны быть приняты меры и гарантии для уменьшения негативного воздействия на субъекта данных.

• Предопределение – правовое основание должно быть установлена до начала обработки.

• Прекращение – если правовое основание больше не применяется, обработка должна быть прекращена.

•Корректировка – при изменении правовых оснований обработка должна быть скорректирована в соответствии с новыми правилами.

_{[30] Если первоначальным правовым основанием является согласие, см. руководящие принципы 05/2020 о согласии в соответствии с Регламентом 2016/679. https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent- underregulation-2016679_ru}

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

Пример

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

Получение персональных данных о финансовом положении субъекта данных необходимо для принятия мер по запросу субъекта данных до заключения кредитного договора.[31] Однако сбор персональных данных напрямую от государственных налоговых органов не является необходимым, поскольку клиент имеет возможность заключить договор, предоставив информацию из налоговой администрации самостоятельно. Несмотря на то, что банк может иметь легитимный интерес к получению документации непосредственно от налоговых органов, например, для обеспечения эффективности обработки кредита, предоставление банкам такого прямого доступа к персональным данным заявителей представляет собой риск, связанный с использованием или потенциальным злоупотреблением правами доступа.

_{[31] Cмотрите статью 6(1) GDPR}

При реализации принципа законности контролер осознает, что он не может использовать «необходимое для договора» основание для той части обработки, которая включает сбор персональных данных напрямую из налоговых органов. Такой вид обработки дает вероятность того, что субъект данных станет меньше вовлекаться в обработку своих данных. Это является важным фактором при оценке законности самой обработки. Банк приходит к выводу, что эта часть обработки должна опираться на другое правовое основание обработки. В конкретном государстве-члене ЕС, в котором находится контролер, существуют национальные законы, которые позволяют банку собирать информацию непосредственно у государственных налоговых органов, если субъект данных предварительно дает на это свое согласие.

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

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

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

3.3 Справедливость

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

70. Ключевые элементы спроектированной приватности и параметров по умолчанию в соответствии с принципом справедливости:

• Автономия – Субъектам данных должна быть предоставлена максимально возможная степень автономии для определения того, как используются их персональные данные, а также в отношении объема и условий их использования или обработки.

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

• Ожидание – обработка должна соответствовать разумным ожиданиям субъектов данных.

• Недискриминация – контролер не должен несправедливо дискриминировать субъектов данных.

• Неиспользование – контролер не должен использовать в своих целях потребности или уязвимости субъектов данных.

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

• Баланс полномочий – Баланс полномочий должен быть ключевой задачей в отношениях контроллер-субъект данных. Следует избегать дисбаланса полномочий . Когда это невозможно, такие ситуации следует распознавать и учитывать с помощью соответствующих контрмер.

• Запрет передачи риска – Контроллеры не должны переносить риски предприятия на субъектов данных.

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

• Уважение прав – Контролер должен уважать основные права субъектов данных и применять соответствующие меры и гарантии, а также и не посягать на эти права, если это прямо не обосновано законом.

• Этичность – контролер должен внимательно рассматривать влияние обработки на права человека и его достоинство.

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

• Человеческое вмешательство – контролер должен внедрять в систему квалифицированного человека, способного выявить искажения, которые могут быть созданы системой в связи с правом не подвергаться автоматизированному принятию решений в индивидуальных случаях в статье 22 GDPR.[32]

_{[32] Руководство по автоматизированному индивидуальному принятию решений и профилированию для целей Регламента 2016/679. https://ec.europa.eu/newsroom/article29/document.cfm?action=display&doc_id=49826}

• Справедливые алгоритмы – Регулярно оценивать, функционируют ли алгоритмы в соответствии с поставленными целями, и корректировать алгоритмы для смягчения выявленных предубеждений и обеспечения справедливости при обработке. Субъекты данных должны быть проинформированы о функционировании обработки персональных данных на основе алгоритмов, которые анализируют или делают прогнозы о них, такие как производительность труда, экономическое положение, здоровье, личные предпочтения, надежность или поведение, местоположение или перемещения. [33]

_{[33] Cмотрите Преамбулу 71 к GDPR}

Пример 1

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

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

Пример 2

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

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

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

3.4 Ограничение целью [34]

_{[34] Рабочая группа по Статье 29 даёт руководство для понимания принципа ограничения целью в соответствии с Директивой 95/46 / ЕС. Несмотря на то, что это мнение не принято EDBP, оно все еще может быть актуальным, поскольку формулировка этого принципа остается такой же, как и в GDPR. Article 29 Working Party. “Opinion 03/2013 on purpose limitation”. WP 203, 2 April 2013.}

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

72. Ключевые элементы спроектированной приватности и параметров по умолчанию в соответствии с принципом справедливости:

• Предопределение – легитимные цели должны быть определены до проектирования обработки.

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

• Ориентация на цель – структура и границы обработки должны определяться целью обработки.

• Необходимость – цель определяет, какие персональные данные необходимы для обработки.

• Совместимость – любая новая цель должна быть совместима с первоначальной целью, для которой были собраны данные, и вносить соответствующие изменения в проектирование.

• Ограничение дальнейшей обработки – Контролер не должен подключать наборы данных или выполнять какую-либо дальнейшую обработку для новых целей, не совместимых с первоначальными.

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

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

Пример

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

Контролер рассматривает возможность покупки регулирования отношений с клиентурой (CRM). Это программа, которая собирает все клиентские данные о продажах, маркетинге и обслуживании клиентов в одном месте. Программа дает возможность хранить все телефонные звонки, действия, документы, электронные письма и маркетинговые кампании, чтобы получить полное представление о клиенте. Более того, РОК автоматически анализирует покупательную способность клиентов, используя общедоступную информацию. Целью анализа является более целенаправленная рекламная деятельность. Эта деятельность не является частью первоначальной законной цели обработки.

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

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

3.5 Минимизация данных

73. Должны быть обработаны только те персональные данные, которые являются адекватными, релевантными и ограниченными необходимой целью обработки.[36] В результате контролер должен заранее определить, какие основные свойства, параметры систем обработки и их вспомогательные функции допустимы. Минимизация данных обосновывает и осуществляет принцип необходимости. При дальнейшей обработке контролер должен периодически анализировать, являются ли обработанные персональные данные по-прежнему адекватными, релевантными необходимыми, или данные должны быть удалены или анонимизированы.

_{[36] Статья 5(1)(с) GDPR}

74. Контролеры должны в первую очередь определить, нужно ли им вообще обрабатывать персональные данные для соответствующих целей. Контроллер должен проверить, могут ли соответствующие цели быть достигнуты путем обработки меньшего количества персональных данных, или путем менее детальной или агрегированной обработки персональных данных, или вообще без необходимости обработки персональных данных [37]. Такая проверка должна проводиться до начала любой обработки, но также может быть осуществлена в любой момент в течение жизненного цикла обработки. Это также отвечает требованиям Статьи 11.

_{[39] В Преамбуле 39 GDPR указано: “…Персональные данные должны обрабатываться только в том случае, если цель обработки не может быть обоснованно выполнена другими способами”}

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

76. Ключевые элементы спроектированной приватности и параметров по умолчанию в соответствии с принципом минимизации:

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

• Ограничение – Ограничить объем собираемых персональных данных тем, что необходимо для этой цели.

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

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

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

• Агрегирование – используйте агрегированные данные, когда это возможно.

• Псевдонимизация – псевдонимизируйте персональные данные, как только больше нет необходимости иметь персональных данные, позволяющие установить личность, и хранить идентификационные ключи отдельно.

• Анонимизация и удаление – если персональные данные не необходимы или больше не требуются для данной цели, они должны быть анонимизированы или удалены.

• Поток данных – поток данных должен быть достаточно целесообразным, чтобы не создавать больше копий или точек входа для сбора данных, чем это необходимо.

• «Уровень техники» – контролер должен применять современные и подходящие технологии для предотвращения и минимизации данных.

Пример 1

Книжный магазин хочет увеличить свою прибыль, продавая свои книги в Интернете. Владелец книжного магазина хочет установить стандартизированную форму для процесса заказа. Чтобы клиенты заполнили всю необходимую информацию, владелец книжного магазина делает все поля формы обязательными (если не заполнить все поля, то клиент не может разместить заказ). Владелец интернет-магазина изначально использует стандартную контактную форму, в которой запрашивается информация, в том числе дата рождения клиента, номер телефона и домашний адрес. Однако не все поля в форме строго необходимы для покупки и доставки книг. В этом конкретном случае, если субъект данных оплачивает товар заранее, дата рождения субъекта данных и номер телефона не являются необходимыми для покупки продукта, Это означает, что в веб-форме эти поля не могут быть обязательными для заказа товара, если только контролер не может ясно продемонстрировать, что это необходимо и зачем нужны эти поля. Более того, бывают ситуации, когда адрес не нужен. Например, заказывая электронную книгу, клиент может загрузить товар сразу на свое электронное устройство.

Поэтому владелец интернет-магазина решает сделать две веб-формы: одну для заказа книг с полем для адреса покупателя и одну веб-форму для заказа электронных книг без поля для адреса покупателя.

Пример 2

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

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

Пример 3

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

Пример 4

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

3.6 Точность

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

_{[38]Статья 5(1)(d) GDPR}

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

79. Ключевые элементы спроектированной приватности и параметров по умолчанию в соответствии с принципом точности:

• Источники персональных данных должны быть надежными с точки зрения точности данных.

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

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

• Проверка – в зависимости от характера данных, в зависимости от того, как часто они могут изменяться, контролер должен проверять правильность персональных данных с субъектом данных до и на разных этапах обработки (например, к возрастным требованиям).

• Стирание / исправление – контроллер должен без промедления стирать или исправлять неточные данные. Контролер должен, в частности, содействовать этому в тех случаях, когда субъекты данных являются или были детьми и впоследствии хотят удалить такие персональные данные [39].

_{[39] См. Преамбулу 65}

• Предотвращение распространения ошибок – Контроллеры должны смягчать влияние накопленной ошибки в цепочке обработки.

• Доступ – субъектам данных должна быть предоставлена информации и быстрый доступ к персональным данным в соответствии со ст. 12 и 15 GDPR в целях того, чтобы контролировать точность данных и исправлять ошибки при необходимости.

• Постоянная точность – персональные данные должны быть точными на всех этапах обработки, тесты на точность должны проводиться на критических этапах.

• В актуальном состоянии – персональные данные должны быть обновлены, если это необходимо для этой цели.

• Проектирование данных – использование технологических и организационных особенностей проектирования для уменьшения погрешности, например, вместо свободных текстовых полей представьте краткие предопределенные варианты.

Пример 1

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

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

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

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

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

Страховая компания проверяет, является ли ИИ надежным и дает ли он недискриминационные результаты как во время его разработки, так и перед выпуском продукта. Когда ИИ полностью обучен и работоспособен, страховая компания использует результаты для поддержки оценки страхового риска, но не полагаясь исключительно на ИИ при принятии решения о предоставлении страхования, если только решение не принимается в соответствии с исключениями, предусмотренными в статье 22 (2) GDPR.

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

Пример 2

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

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

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

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

3.7 Ограничение хранения

80. Контролер должен гарантировать, что персональные данные хранятся в форме, позволяющей идентифицировать субъекты данных не более, чем это необходимо для целей, для которых обрабатываются персональные данные. [27] Очень важно, чтобы диспетчер точно знал, какие персональные данные обрабатывает компания и почему. Целью обработки является определение критериев продолжительности хранения персональных данных.

_{[40] Статья 5(1)(c) GDPR}

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

82. Ключевые элементы спроектированной приватности и параметров по умолчанию в соответствии с принципом ограничения хранения:

• Удаление и анонимизация – контролер должен иметь ясные внутренние процедуры и функциональные возможности для удаления данных и/или анонимизации.

• Эффективность анонимизации / удаления – Контролер должен убедиться, что невозможно повторно идентифицировать анонимные данные или восстановить удаленные данные, и должен проверить, возможно ли это.

• Автоматизация – Удаление определенных персональных данных должно быть автоматизировано.

• Критерии хранения – Контролер должен определить, какие данные и какая продолжительность хранения необходимы для этой цели.

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

• Внедрение политики хранения – Контролер должен внедрять политику внутреннего хранения и проводить проверку того, реализует ли организация свою политику.

• Резервные копии / журналы – контролеры должны определить, какие персональные данные и объем хранилища необходимы для резервного копирования и журналов.

•Поток данных – Контролеры должны быть осторожны с потоком персональных данных, а также с хранением любых их копий, и стремиться ограничить их “временное” хранение.

Пример

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

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

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

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

3.8 Целостность и конфиденциальность

84. В преамбуле 78 сказано, что одна из мер DPbDD может состоять в том, чтобы позволить контролеру «создавать и совершенствовать средства защиты». Наряду с другими мерами DPbDD, преамбула 78 предлагает контролерам постоянно анализировать, использует ли он все время соответствующие средства обработки, и оценивать, действительно ли выбранные меры противостоят существующим уязвимостям. Кроме того, контролеры должны проводить регулярные проверки средств защиты, которые окружают и защищают персональные данные, а также процедуры обработки утечек данных.

85. Ключевые элементы спроектированной приватности и параметров по умолчанию в соответствии с принципом целостности:

• Система менеджмента информационной безопасности (СМИБ) – оперативные средства управления политиками и процедурами информационной безопасности.

• Анализ рисков – Оценка рисков в отношении безопасности персональных данных с учетом воздействия на права физических лиц и противодействие выявленным рискам. Для использования при оценке рисков; разработка и сопровождение комплексного, систематического и реалистичного “моделирования угроз” и анализа атаки разработанного программного обеспечения с целью уменьшения векторов атак и возможностей использования слабых элементов и уязвимостей.

• Спроектированная безопасность – Учитывайте требования безопасности как можно раньше при проектировании и разработке системы, а также постоянно интегрируйте и выполняйте соответствующие проверки.

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

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

o Ограничение доступа (агенты) – Формирование процесса обработки данных таким образом, чтобы минимальное количество людей нуждалось в доступе к персональным данным для выполнения своих обязанностей, и соответствующее ограничение доступа.

o Ограничение доступа (контента) – в контексте каждой операции по обработке ограничивать доступ только теми атрибутами из набора данных, которые необходимы для выполнения этой операции.

o Сегрегация доступа – Формирование процесса обработки данных таким образом, чтобы ни одно лицо не нуждалось в комплексном доступе ко всем данным, собранным о субъекте данных, и тем более ко всем персональным данным определенной категории субъектов данных.

•Защищенная передача данных – передача данных должна быть защищена от несанкционированного и случайного доступа и изменений.

• Безопасное хранение. Хранение данных должно быть защищено от несанкционированного доступа и изменений. Должны существовать процедуры оценки риска централизованного или децентрализованного хранения, а также к каким категориям персональных данных это относится. Некоторые данные могут нуждаться в дополнительных мерах безопасности по сравнению с другими или в изоляции от других.

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

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

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

• Защита в соответствии с риском – Все категории персональных данных должны быть защищены мерами, адекватными по отношению к риску нарушения безопасности. Данные, представляющие особый риск, должны, по возможности, храниться отдельно от остальных персональных данных.

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

• Управление инцидентами – Контроллер должен располагать процессами обработки нарушений и инцидентов, чтобы сделать систему обработки более надежной. Это включает в себя процедуры уведомления, такие как управление уведомлениями (для контролирующего органа) и информацией (для субъектов данных).

Пример

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

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

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

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

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

3.9 Подотчетность [41]

_{[41] См. Преамбулу 74, в соответствии с которой контроллеры обязываются продемонстрировать эффективность своих мер.}

86. Принцип подотчетности гласит, что контролер должен нести ответственность и быть в состоянии продемонстрировать соблюдение всех вышеперечисленных принципов.

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

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

89. Согласно статье 25(3), сертификация в соответствии со статьей 42 может использоваться в качестве элемента, доказывающего соблюдение DPbDD. И наоборот, документы, подтверждающие соблюдение DPbDD, могут быть также полезны в процессе сертификации. Это означает, что в тех случаях, когда операция по обработке, осуществляемая контролером или процессором, сертифицирована согласно Статье 42, надзорные органы должны принимать это во внимание в своей оценке соответствия GDPR, особенно в отношении DPbDD.

90. Когда операция по обработке, выполняемая контроллером или процессором, сертифицирована в соответствии со Статьей 42, элементами, которые способствуют демонстрации соблюдения требований Статьи 25(1) и (2), являются процессы проектирования, т.е. процесс определения средств обработки, управление и технические и организационные меры по реализации принципов защиты данных. Критерии сертификации по защите персональных данных определяются сертификационными органами или владельцами сертификационных схем и затем утверждаются компетентным надзорным органом или EDPB. Для получения дополнительной информации о механизмах сертификации мы обращаемся к Руководству по сертификации [42] EDPB и другим соответствующим руководствам, опубликованным на веб-сайте EDPB.

_{[42] EDPB. “Руководящие принципы 1/2018 по сертификации и определению критериев сертификации в соответствии со статьями 42 и 43 Регламента”. Версия 3.0, 4 июня 2019 г. edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_201801_v3.0_certificationcriteria_annex2_en.pdf.}

91. Даже в тех случаях, когда операция по обработке данных сертифицирована в соответствии со Статьей 42, контроллер все равно несет ответственность за постоянный контроль и улучшение соблюдения DPbDD – критериев Статьи 25.

92. Надзорные органы могут оценивать соответствие Статье 25 в соответствии с процедурами, перечисленными в Статье 58. Корректирующие полномочия определены в Статье 58 (2) и включают в себя выдачу предупреждений, замечаний, распоряжений о соблюдении прав субъектов данных, ограничений или запретов на обработку, административные штрафы и т. д.

93. DPbDD также является фактором, определяющим уровень денежных санкций за нарушение GDPR, см. Статью 83 (4). [43] [44]

_{[44]Более подробную информацию о штрафах можно найти в статье 29 Рабочей группы. “Guidelines on application and setting of administrative fines for the purposes of the Regulation 2016/679”. WP 253, 3 October 2017.}

_{[43]Статья 83(2) (d) GDPR предусматривает то, что при определении наложения штрафов за нарушение GDPR “должным образом учитывается” степень ответственности контролера или процессора с учетом технических и организационных мер, осуществляемых ими в соответствии со статьями 25 и 32″.}

94. Хотя процессоры и производители не рассматриваются непосредственно в Статье 25, они также признаны в качестве ключевых сторон, способствующих DPbDD, они должны знать, что контролеры обязаны обрабатывать персональные данные только с помощью систем и технологий, которые имеют встроенную защиту данных.

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

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

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

• В тех случаях, когда у контроллера есть сотрудник по защите данных (DPO), EDPB поощряет активное участие DPO для интеграции DPbDD в процедуры закупки и разработки, а также в течение всего жизненного цикла обработки.

• Операция по обработке может быть сертифицирована. Возможность сертификации операции обработки дает дополнительную ценность контроллеру при выборе между различными программными, аппаратными средствами, услугами и/или системами обработки от производителей или процессоров. Поэтому производители должны стремиться демонстрировать DPbDD в жизненном цикле разработки процессингового решения. Сертификационная печать может также служить ориентиром для субъектов данных при выборе между различными товарами и услугами. Возможность получения сертификации обработки может служить конкурентным преимуществом для производителей, процессоров и контролеров, и даже повышает доверие субъектов данных к обработке их персональных данных. В случае, если сертификация не предлагается, контролеры должны стремиться иметь другие гарантии того, что производители или процессоры соблюдают требования DPbDD.

• Контролеры, процессоры и производители должны учитывать свои обязательства по обеспечению особой защиты детей в возрасте до 18 лет и других уязвимых групп при соблюдении требований DPbDD.

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

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

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

• EDPB подчеркивает необходимость согласованного подхода к эффективному осуществлению принципов и прав и призывает ассоциации или органы, готовящие кодексы поведения в соответствии со Статьей 40, также включать в них отраслевые руководящие указания по DPbDD.

• Контролеры должны быть справедливыми по отношению к субъектам данных и транспарентными в отношении того, как они оценивают и демонстрируют эффективное осуществление DPbDD, точно так же, как контролеры демонстрируют соблюдение GDPR в соответствии с принципом подотчетности.

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

• Существующие системы находятся под теми же обязательствами DPbDD, что и новые системы. Если унаследованные системы не соответствуют DPbDD, а изменения в соответствии с обязательствами не могут быть внесены, то унаследованная система просто не соответствует GDPR-обязательствам и не может быть использована для обработки персональных данных.

Статья 25 не снижает порог требований для МСП. Нижеследующие пункты могут способствовать соблюдению МСП положений статьи 25: o Проводить ранние оценки рисков o Начните с малой обработки, а затем увеличивайте ее масштабы. o Ищите гарантии производителя и процессора DPbDD, такие как сертификация и соблюдение кодекса поведения. o Используйте партнеров с хорошей репутацией o Поговорите с DPA o Ознакомьтесь с указаниями DPA и EDPB o Придерживаться кодексов поведения, где это возможно o Получить профессиональную помощь и совет