Разъяснения > Руководство по 25 статье GDPR (Защита персональных данных: проектируемая и по умолчанию) в соответствии с Регламентом 2016/679

Руководство по 25 статье GDPR (Защита персональных данных: проектируемая и по умолчанию) в соответствии с Регламентом 2016/679

Guidelines 4/2019 on Article 25 Data Protection by Design and by Default Version 2.0.

Перевод на русский язык с английского языка выполнили П. Беседина, Н. Вербанович и В. Литвинко. Общая редакция: Сергей Воронкевич CIPP/E, CIPM, MBA. © Перевод на русский ООО "Дата Прайваси Офис".
Adopted on 20 October 2020: Data Protection by Design and by Default

Европейский совет по защите данных

The European Data Protection Board

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

Having regard to Article 70 (1e) of the Regulation 2016/679/EU of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC], (hereinafter «GDPR»),

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

Having regard to the EEA Agreement and in particular to Annex XI and Protocol 37 thereof, as amended by the Decision of the EEA joint Committee No 154/2018 of 6 July 2018

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

Having regard to Article 12 and Article 22 of its Rules of Procedure,

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

HAS ADOPTED THE FOLLOWING GUIDELINES

Резюме

Executive summary

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

In an increasingly digital world, adherence to Data Protection by Design and by Default requirements plays a crucial part in promoting privacy and data protection in society. It is therefore essential that controllers take this responsibility seriously and implement the GDPR obligations when designing processing operations.

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

These Guidelines give general guidance on the obligation of Data Protection by Design and by Default (henceforth «DPbDD») set forth in Article 25 in the GDPR. DPbDD is an obligation for all controllers, irrespective of size and varying complexity of processing. To be able to implement the requirements of DPbDD, it is crucial that the controller understands the data protection principles and the data subject’s rights and freedoms.

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

The core obligation is the implementation of appropriate measures and necessary safeguards that provide effective implementation of the data protection principles and, consequentially, data subjects’ rights and freedoms by design and by default. Article 25 prescribes both design and default elements that should be taken into account. Those elements, will be further elaborated in these Guidelines.

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

Article 25(1) stipulates that controllers should consider DPbDD early on when they plan a new processing operation. Controllers shall implement DPbDD before processing, and also continually at the time of processing, by regularly reviewing the effectiveness of the chosen measures and safeguards. DPbDD also applies to existing systems that are processing personal data.

Furthermore, Article 25 requires data protection by default, meaning that by default, only personal data which are necessary for each specific purpose of the processing is processed. Thus, the default settings must be designed with data protection in mind. Default settings include both parameters that can be set by controllers and data subjects.

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

The Guidelines also contain guidance on how to effectively implement the data protection principles in Article 5, listing key design and default elements as well as practical cases for illustration. The controller should consider the appropriateness of the suggested measures in the context of the particular processing in question.

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

The EDPB provides recommendations on how controllers, processors and producers can cooperate to achieve DPbDD. It encourages the controllers in industry, processors, and producers to use DPbDD as a means to achieve a competitive advantage when marketing their products towards controllers and data subjects. It also encourages all controllers to make use of certifications and codes of conduct.

1. СФЕРА ДЕЙСТВИЯ

1. SCOPE

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

1. The Guidelines focus on controllers’ implementation of DPbDD based on the obligation in Article 25 of the GDPR.[1] Other actors, such as processors and producers of products, services and applications (henceforth «producers»), who are not directly addressed in Article 25, may also find these Guidelines useful in creating GDPR compliant products and services that enable controllers to fulfil their data protection obligations.[2] Recital 78 of the GDPR adds that DPbDD should be taken into consideration in the context of public tenders. Despite all controllers having the duty to integrate DPbDD into their processing activities, this provision fosters the adoption of the data protection principles, where public administrations should lead by example. The controller is responsible for the fulfilment of the DPbDD obligations for the processing carried out by their processors and sub-processors, they should therefore take this into account when contracting with these parties.

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

[1] The interpretations provided herein equally apply to Article 20 of Directive (EU) 2016/680, and Article 27 of Regulation 2018/1725.

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

[2] Recital 78 GDPR clearly states this need : «When developing, designing, selecting and using applications, services and products that are based on the processing of personal data or process personal data to fulfil their task, producers of the products, services and applications should be encouraged to take into account the right to data protection when developing and designing such products, services and applications and, with due regard to the «state of the art», to make sure that controllers and processors are able to fulfil their data protection obligations».

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

2. The requirement described in Article 25 is for controllers to have data protection designed into the processing of personal data and as a default setting and this applies throughout the processing lifecycle. DPbDD is also a requirement for processing systems pre-existing before the GDPR entered into force. Controllers must have the processing consistently updated in line with the GDPR. For more information on how to maintain an existing system in line with DPbDD, see subchapter 2.1.4 of these Guidelines. The core of the provision is to ensure appropriate and effective data protection both by design and by default, which means that controllers should be able to demonstrate that they have the appropriate measures and safeguards in the processing to ensure that the data protection principles and the rights and freedoms of data subjects are effective.

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

3. Chapter 2 of the Guidelines focuses on an interpretation of the requirements set forth by Article 25 and explores the legal obligations introduced by the provision. Examples on how to apply DPbDD in the context of specific data protection principles are provided in Chapter 3.

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

4. The Guidelines address the possibility to establish a certification mechanism to demonstrate compliance with Article 25 in Chapter 4, as well as how the Article may be enforced by supervisory authorities in Chapter 5. Finally, the Guidelines provide stakeholders with further recommendations on how to successfully implement DPbDD. The EDPB recognizes the challenges for small and medium enterprises (henceforth «SMEs») to fully comply with the obligations of DPbDD, and provides additional recommendations specifically to SMEs in Chapter 6.

2. АНАЛИЗ СТАТЬИ 25(1) И (2) СПРОЕКТИРОВАННАЯ ЗАЩИТА ПЕРСОНАЛЬНЫХ ДАННЫХ И ПО УМОЛЧАНИЮ

2. ANALYSIS OF ARTICLE 25 (1) AND (2) DATA PROTECTION BY DESIGN AND BY DEFAULT

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

5. The aim of this Chapter is to explore and provide guidance on the requirements to data protection by design in Article 25(1) and to data protection by default in Article 25(2) respectively. Data protection by design and data protection by default are complementary concepts, which mutually reinforce each other. Data subjects will benefit more from data protection by default if data protection by design is concurrently implemented – and vice versa.

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

6. DPbDD is a requirement for all controllers, including small businesses and multinational companies alike. That being the case, the complexity of implementing DPbDD may vary based on the individual processing operation. Regardless of the size however, in all cases, positive benefits for controller and data subject can be achieved by implementing DPbDD.

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

2.1.1. Controller’s obligation to implement appropriate technical and organisational measures and necessary safeguards into the processing

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

7. In line with Article 25(1) the controller shall implement appropriate technical and organisational measures which are designed to implement the data protection principles and to integrate the necessary safeguards into the processing in order to meet the requirements and protect the rights and freedoms of data subjects. Both appropriate measures and necessary safeguards are meant to serve the same purpose of protecting the rights of data subjects and ensuring that the protection of their personal data is built into the processing.

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

8. Technical and organizational measures and necessary safeguards can be understood in a broad sense as any method or means that a controller may employ in the processing. Being appropriate means that the measures and necessary safeguards should be suited to achieve the intended purpose, i.e. they must implement the data protection principles effectively.[3] The requirement to appropriateness is thus closely related to the requirement of effectiveness.

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

[3] «Effectiveness» is addressed below in subchapter 2.1.2

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

9. A technical or organisational measure and safeguard can be anything from the use of advanced technical solutions to the basic training of personnel. Examples that may be suitable, depending on the context and risks associated with the processing in question, includes pseudonymization of personal data [4]; storing personal data available in a structured, commonly machine readable format; enabling data subjects to intervene in the processing; providing information about the storage of personal data; having malware detection systems; training employees about basic «cyber hygiene»; establishing privacy and information security management systems, obligating processors contractually to implement specific data minimisation practices, etc.

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

[4] Defined in Article 4(5) GDPR

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

10. Standards, best practices and codes of conduct that are recognized by associations and other bodies representing categories of controllers can be helpful in determining appropriate measures. However, the controller must verify the appropriateness of the measures for the particular processing in question.

11. An example of a technical measure or safeguard is pseudonymization of personal data [4]. Such a measure may be used to implement a number of principles, such as the integrity and confidentiality and data minimisation.

[4] Defined in Article 4(5) GDPR, examples of which are hashing or encryption

2.1.2. Приватность, спроектированная для эффективной реализации принципов защиты персональных данных и защиты прав и свобод субъектов данных

2.1.2. Designed to implement the data protection principles in an effective manner and protecting data subjects’ rights and freedoms

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

11. The data protection principles are in Article 5 (henceforth «the principles»), the data subjects’ rights and freedoms are the fundamental rights and freedoms of natural persons, and in particular their right to the protection of personal data, whose protection is named in Article 1(2) as the objective of the GDPR (henceforth «the rights»).[5] Their precise formulation can be found in the EU Charter of Fundamental Rights. It is essential for the controller to have an understanding of the meaning of the principles and the rights as the basis for the protection offered by the GDPR, specifically by the DPbDD obligation.

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

[5] See Recital 4 of the GDPR.

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

12. When implementing the appropriate technical and organisational measures, it is with respect to the effective implementation of each of the aforementioned principles and the ensuing protection of rights that the measures and safeguards should be designed.

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

Addressing effectiveness

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

13. Effectiveness is at the heart of the concept of data protection by design. The requirement to implement the principles in an effective manner means that controllers must implement the necessary measures and safeguards to protect these principles, in order to secure the rights of data subjects. Each implemented measure should produce the intended results for the processing foreseen by the controller. This observation has two consequences.

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

14. First, it means that Article 25 does not require the implementation of any specific technical and organizational measures, rather that the chosen measures and safeguards should be specific to the implementation of data protection principles into the particular processing in question. In doing so, the measures and safeguards should be designed to be robust and the controller should be able to implement further measures in order to scale to any increase in risk.[6] Whether or not measures are effective will therefore depend on the context of the processing in question and an assessment of certain elements that should be taken into account when determining the means of processing. The aforementioned elements will be addressed below in subchapter 2.1.3.

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

[6] «Fundamental principles applicable to the controllers (i.e. legitimacy, data minimisation, purpose limitation, transparency, data integrity, data accuracy) should remain the same, whatever the processing and the risks for the data subjects. However, due regard to the nature and scope of such processing have always been an integral part of the application of those principles, so that they are inherently scalable.» Article 29 Working Party. «Statement on the role of a risk-based approach in data protection legal frameworks». WP 218, 30 May 2014, p. 3. ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp218_en.pdf

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

15. Second, controllers should be able to demonstrate that the principles have been maintained.

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

16. The implemented measures and safeguards should achieve the desired effect in terms of data protection, and the controller should have documentation of the implemented technical and organizational measures.[7] To do so, the controller may determine appropriate key performance indicators (KPI) to demonstrate the effectiveness. A KPI is a measurable value chosen by the controller that demonstrates how effectively the controller achieves their data protection objective. KPIs may be quantitative, such as the percentage of false positives or false negatives, reduction of complaints, reduction of response time when data subjects exercise their rights; or qualitative, such as evaluations of performance, use of grading scales, or expert assessments. Alternatively to KPIs, controllers may be able to demonstrate the effective implementation of the principles by providing the rationale behind their assessment of the effectiveness of the chosen measures and safeguards.

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

[7] See Recitals 74 and 78.

2.1.3. Элементы, которые должны быть приняты во внимание

2.1.3. Elements to be taken into account

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

17. Article 25 (1) lists elements that the controller has to take into account when determining the measures of a specific processing operation. In the following, we will provide guidance on how to apply these elements in the design process, which includes design of the default settings. These elements all contribute to determine whether a measure is appropriate to effectively implement the principles. Thus, each of these elements is not a goal in and of themselves, but are factors to be considered together to reach the objective.

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

2.1.3.1 «state of the art»

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

18. The concept of «state of the art» is present in various EU acquis, e.g. environmental protection and product safety. In the GDPR, reference to the «state of the art» [8] is made not only in Article 32, for security measures,[9][10] but also in Article 25, thus extending this benchmark to all technical and organisational measures embedded in the processing.

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

[8] See German Federal Constitutional Court’s «Kalkar» decision in 1978: https://germanlawarchive.iuscomp.org/?p=67 may provide the foundation for a methodology for an objective definition of the concept. On that basis, the «state of the art» technology level would be identified between the «existing scientific knowledge and research» technology level and the more established «generally accepted rules of technology». The «state of the art» can hence be identified as the technology level of a service or technology or product that exists in the market and is most effective in achieving the objectives identified.

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

[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/

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

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

19. In the context of Article 25, the reference to «state of the art» imposes an obligation on controllers, when determining the appropriate technical and organisational measures, to take account of the current progress in technology that is available in the market. The requirement is for controllers to have knowledge of, and stay up to date on technological advances; how technology can present data protection risks or opportunities to the processing operation; and how to implement and update the measures and safeguards that secure effective implementation of the principles and rights of data subjects taking into account the evolving technological landscape.

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

20. The «state of the art» is a dynamic concept that cannot be statically defined at a fixed point in time, but should be assessed continuously in the context of technological progress. In the face of technological advancements, a controller could find that a measure that once provided an adequate level of protection no longer does. Neglecting to keep up to date with technological changes could therefore result in a lack of compliance with Article 25.

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

21. The «state of the art» criterion does not only apply to technological measures, but also to organisational ones. Lack of appropriate organisational measures can lower or even completely undermine the effectiveness of a chosen technology. Examples of organisational measures can be adoption of internal policies; up-to date training on technology, security and data protection; and IT security governance and management policies.

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

22. Existing and recognized frameworks, standards, certifications, codes of conduct, etc. in different fields may play a role in indicating the current «state of the art» within the given field of use. Where such standards exist and provide a high level of protection for the data subject in compliance with – or go beyond – legal requirements, controllers should take them into account in the design and implementation of data protection measures.

2.1.3.2 «затраты на внедрение»

2.1.3.2 «cost of implementation»

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

23. The controller may take the cost of implementation into account when choosing and applying appropriate technical and organisational measures and necessary safeguards that effectively implement the principles in order to protect the rights of data subjects. The cost refers to resources in general, including time and human resources.

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

24. The cost element does not require the controller to spend a disproportionate amount of resources when alternative, less resource demanding, yet effective measures exist. However, the cost of implementation is a factor to be considered to implement data protection by design rather than a ground to not implement it.

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

25. Thus, the chosen measures shall ensure that the processing activity foreseen by the controller does not process personal data in violation of the principles, independent of cost. Controllers should be able to manage the overall costs to be able to effectively implement all of the principles and, consequentially, protect the rights.

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

2.1.3.3 «nature, scope, context and purpose of processing»

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

26. Controllers must take into consideration the nature, scope, context and purpose of processing when determining needed measures.

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

27. These factors should be interpreted consistently with their role in other provisions of the GDPR, such as Articles 24, 32 and 35, with the aim of designing data protection principles into the processing.

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

28. In short, the concept of nature can be understood as the inherent[11] characteristics of the processing. The scope refers to the size and range of the processing. The context relates to the circumstances of the processing, which may influence the expectations of the data subject, while the purpose pertains to the aims of the processing.

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

[11] Examples are special categories personal data, automatic decision-making, skewed power relations, unpredictable processing, difficulties for the data subject to exercise the rights, etc.

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

2.1.3.4 «risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing»

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

29. The GDPR adopts a coherent risk based approach in many of its provisions, in Articles 24, 25, 32 and 35, with a view to identifying appropriate technical and organisational measures to protect individuals, their personal data and complying with the requirements of the GDPR. The assets to protect are always the same (the individuals, via the protection of their personal data), against the same risks (to individuals’ rights), taking into account the same conditions (nature, scope, context and purposes of processing).

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

30. When performing the risk analysis for compliance with Articles 25, the controller has to identify the risks to the rights of data subjects that a violation of the principles presents, and determine their likelihood and severity in order to implement measures to effectively mitigate the identified risks. A systematic and thorough evaluation of the processing is crucial when doing risk assessments. For example, a controller assesses the particular risks associated with a lack of freely given consent, which constitutes a violation of the lawfulness principle, in the course of the processing of personal data of children and young people under 18 as a vulnerable group, in a case where no other legal ground exists, and implements appropriate measures to address and effectively mitigate the identified risks associated with this group of data subjects.

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

31. The «EDPB Guidelines on Data Protection Impact Assessment (DPIA)», [12] which focus on determining whether a processing operation is likely to result in a high risk to the data subject or not, also provide guidance on how to assess data protection risks and how to carry out a data protection risk assessment. These Guidelines may also be useful during the risk assessment in all the articles mentioned above, including Article 25.

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

[12] Article 29 Working Party «Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is «likely to result in a high risk» for the purposes of Regulation 2016/679″. WP 248 rev.01, 4 October 2017. ec.europa.eu/newsroom/document.cfm?doc_id=47711 — endorsed by the EDPB.

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

32. The risk based approach does not exclude the use of baselines, best practices and standards. These might provide a useful toolbox for controllers to tackle similar risks in similar situations (nature, scope, context and purpose of processing). Nevertheless, the obligation in Article 25 (as well as Articles 24, 32 and 35(7)(c)) to take into account «risks of varying likelihood and severity for rights and freedoms of natural persons posed by the processing» remains. Therefore, controllers, although supported by such tools, must always carry out a data protection risk assessment on a case by case basis for the processing activity at hand and verify the effectiveness of the appropriate measures and safeguards proposed. A DPIA, or an update to an existing DPIA, may then additionally be required.

2.1.4. Временной аспект

2.1.4. Time aspect

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

33. Data protection by design shall be implemented «at the time of determination of the means for processing».

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

2.1.4.1 At the time of the determination of the means for processing

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

34. The «means for processing» range from the general to the detailed design elements of the processing, including the architecture, procedures, protocols, layout and appearance.

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

35. The «time of determination of the means for processing» refers to the period of time when the controller is deciding how the processing will be conducted and the manner in which the processing will occur and the mechanisms which will be used to conduct such processing. It’s in the process of making such decisions that the controller must assess the appropriate measures and safeguards to effectively implement the principles and rights of data subjects into the processing, and take into account elements such as the state of the art, cost of implementation, nature, scope, context and purpose, and risks. This includes the time of procuring and implementing data processing software, hardware, and services.

35. Controllers must be able to demonstrate that such assessments have been made for all of the means that are part of the processing.

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

36. Early consideration of DPbDD is crucial for a successful implementation of the principles and protection of the rights of the data subjects. Moreover, from a cost-benefit perspective, it is also in controllers’ interest to take DPbDD into account sooner rather than later, as it could be challenging and costly to make later changes to plans that have already been made and processing operations that have already been designed.

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

2.1.4.2 At the time of the processing itself (maintenance and review of data protection requirements)

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

37. Once the processing has started the controller has a continued obligation to maintain DPbDD, i.e. the continued effective implementation of the principles in order to protect the rights, staying up to date on the state of the art, reassessing the level of risk, etc. The nature, scope and context of processing operations, as well as the risk may change over the course of processing, which means that the controller must re-evaluate their processing operations through regular reviews and assessments of the effectiveness of their chosen measures and safeguards.

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

38. The obligation to maintain, review and update, as necessary, the processing operation also applies to pre-existing systems. This means that legacy systems designed before the GDPR entered into force are required to undergo reviews and maintenance to ensure the implementation of measures and safeguards that implement the principles and rights of data subjects in an effective manner, as outlined in these Guidelines.

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

39. This obligation also extends to any processing carried out by means of data processors. Processors’ operations should be regularly reviewed and assessed by the controllers to ensure that they enable continuous compliance with the principles and allow the data controller to fulfil its obligations in this respect.

2.2.1 Cтатья 25 (2): защита данных по умолчанию

2.2.1 Article 25(2): Data protection by default

По умолчанию

By default, only personal data which are necessary for each specific purpose of the processing are processed

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

40. A «default», as commonly defined in computer science, refers to the pre-existing or preselected value of a configurable setting that is assigned to a software application, computer program or device. Such settings are also called «presets» or «factory presets», especially for electronic devices.

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

41. Hence, the term «by default» when processing personal data, refers to making choices regarding configuration values or processing options that are set or prescribed in a processing system, such as a software application, service or device, or a manual processing procedure that affect the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility.

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

42. The controller should choose and be accountable for implementing default processing settings and options in a way that only processing that is strictly necessary to achieve the set, lawful purpose is carried out by default. Here, controllers should rely on their assessment of the necessity of the processing with regards to the legal grounds of Article 6(1). This means that by default, the controller shall not collect more data than is necessary, they shall not process the data collected more than is necessary for their purposes, nor shall they store the data for longer than necessary. The basic requirement is that data protection is built into the processing by default.

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

43. The controller is required to predetermine for which specified, explicit and legitimate purposes the personal data is collected and processed.[13] The measures must by default be appropriate to ensure that only personal data which are necessary for each specific purpose of processing are being processed. The EDPS «Guidelines to assess necessity and proportionality of measures that limit the right to data protection of personal data» can be useful also to decide which data is necessary to process in order to achieve a specific purpose.[14] [15] [16]

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

[13] Art. 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

[14] EDPS. «Guidelines on assessing the necessity and proportionality of measures that limit the right to data protection». 25 February 2019. edps.europa.eu/sites/edp/files/publication/19-02- 25_proportionality_guidelines_en.pdf

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

[15] See also EDPS. «Assessing the necessity of measures that limit the fundamental right to the protection of personal data: A Toolkit» https://edps.europa.eu/data-protection/our-work/publications/papers/necessity- toolkit_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

[16] For more information on necessity, see Article 29 Working Party. «Opinion 06/2014 on the notion of legitimate interests of the data controller under Article 7 of Directive 95/46/EC». WP 217, 9 April 2014. ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp217_en.pdf

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

44. If the controller uses third party software or off-the-shelf software, the controller should carry out a risk assessment of the product and make sure that functions that do not have a legal basis or are not compatible with the intended purposes of processing are switched off.

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

45. The same considerations apply to organisational measures supporting processing operations. They should be designed to process, at the outset, only the minimum amount of personal data necessary for the specific operations. This should be particularly considered when allocating data access to staff with different roles and different access needs.

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

46. Appropriate «technical and organisational measures» in the context of data protection by default is thus understood in the same way as discussed above in subchapter 2.1.1, but applied specifically to implementing the principle of data minimisation.

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

47. The aforementioned obligation to only process personal data which are necessary for each specific purpose applies to the following elements.

2.2.2. Объем обязательства по минимизации данных

2.2.2. Dimensions of the data minimisation obligation

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

48. Article 25 (2) lists the dimensions of the data minimisation obligation for default processing, by stating that the obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility.

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

2.2.2.1 «amount of personal data collected»

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

49. Controllers should consider both the volume of personal data, as well as the types, categories and level of detail of personal data required for the processing purposes. Their design choices should take into account the increased risks to the principles of integrity and confidentiality, data minimisation and storage limitation when collecting large amounts of detailed personal data, and compare it to the reduction in risks when collecting smaller amounts and/or less detailed information about data subjects. In any case, the default setting shall not include collection of personal data that is not necessary for the specific processing purpose. In other words, if certain categories of personal data are unnecessary or if detailed data isn’t needed because less granular data is sufficient, then any surplus personal data shall not be collected.

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

50. The same default requirements apply to services independent of what platform or device in use, only the necessary personal data for the given purpose can be collected.

2.2.2.2 «степень их обработки»

2.2.2.2 «the extent of their processing»

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

51. Processing [17] operations performed on personal data shall be limited to what is necessary. As noted above, many processing operations may contribute to a processing purpose, but just because personal data is needed to fulfil a purpose does not mean that all types of, and frequencies of, processing operations may be carried out on the data. Controllers should also be careful not to extend the boundaries of «compatible purposes», and have in mind what processing will be within the reasonable expectations of data subjects.

2.2.2.3 «срок их хранения»

2.2.2.3 «the period of their storage»

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

52. Personal data collected shall not be stored if it is not necessary for the purpose of the processing and there is no other compatible purpose and legal ground according to Article 6(4). Any retention should be objectively justifiable as necessary by the data controller in accordance with the accountability principle.

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

53. The controller shall limit the retention period to what is necessary for the purpose. If personal data is no longer necessary for the purpose of the processing, then it shall by default be deleted or anonymized. The length of the period of retention will therefore depend on the purpose of the processing in question. This obligation is directly related to the principle of storage limitation in Article 5(1)(e), and shall be implemented by default, i.e. the controller should have systematic procedures for data deletion or anonymization embedded in the processing.

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

54. Anonymization[18] of personal data is an alternative to deletion, provided that all the relevant contextual elements are taken into account and the likelihood and severity of the risk, including the risk of re-identification, are regularly assessed.[19]

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

[18] Article 29 Working Party. «Opinion 05/2014 on Anonymisation Techniques». WP 216, 10 April 2014. ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf

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

[19] Please see Art. 4(1) GDPR, Recital 26 GDPR, Article 29 Working Party «Opinion 05/2014 on Anonymisation Techniques». Please also see the subsection on «storage limitation» in section 3 of this document, referring to the need for the controller to ensure the effectiveness of the implemented anonymisation technique(s).

2.2.2.2 «the extent of their processing»

2.2.2.4 «their accessibility»

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

55. The controller should limit who has access and which types of access to personal data based on an assessment of necessity, and also make sure that personal data is in fact accessible to those who need it when necessary, for example in critical situations. Access controls should be observed for the whole data flow during the processing.

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

56. Article 25(2) further states that personal data shall not be made accessible, without the individual’s intervention, to an indefinite number of natural persons. The controller shall by default limit accessibility and give the data subject the possibility to intervene before publishing or otherwise making available personal data about the data subject to an indefinite number of natural persons.

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

57. Making personal data available to an indefinite number of persons may result in even further dissemination of the data than initially intended. This is particularly relevant in the context of the Internet and search engines. This means that controllers should by default give data subjects an opportunity to intervene before personal data is made available on the open Internet. This is particularly important when it comes to children and vulnerable groups.

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

58. Depending on the legal grounds for processing, the opportunity to intervene could vary based on the context of the processing. For example, to ask for consent to make the personal data publicly accessible, or to have privacy settings so that data subjects themselves can control public access.

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

59. Even in the event that personal data is made available publicly with the permission and understanding of a data subject, it does not mean that any other controller with access to the personal data may freely process it themselves for their own purposes – they must have their own legal basis.[20]

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

[20] See Case of Satakunnan Markkinapörssi Oy and Satamedia Oy v. Finland no. 931/13.

3. ВНЕДРЕНИЕ ПРИНЦИПОВ ЗАЩИТЫ ПЕРСОНАЛЬНЫХ ДАННЫХ В ОБРАБОТКУ ПЕРСОНАЛЬНЫХ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ СПРОЕКТИРОВАННОЙ ЗАЩИТЫ ПЕРСОНАЛЬНЫХ ДАННЫХ И ПО УМОЛЧАНИЮ

3. IMPLEMENTING DATA PROTECTION PRINCIPLES IN THE PROCESSING OF PERSONAL DATA USING DATA PROTECTION BY DESIGN AND BY DEFAULT

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

60. In all stages of design of the processing activities, including procurement, tenders, outsourcing, development, support, maintenance, testing, storage, deletion, etc., the controller should take into account and consider the various elements of DPbDD which will be illustrated by examples in this chapter in the context of implementation of the principles.[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

[21] More examples can be found in Norwegian Data Protection Authority. «Software Development with Data Protection by Design and by Default». 28 November 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

[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

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

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

61. Controllers need to implement the principles to achieve DPbDD. These principles include: transparency, lawfulness, fairness, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, and accountability. These principles are outlined in Article 5 and Recital 39 of the GDPR. To have a complete understanding of how to implement DPbDD, the importance of understanding the meaning of each of the principles is emphasised.

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

62. When presenting examples of how to operationalize DPbDD we have made lists of key DPbDD elements for each of the principles. The examples, while highlighting the specific data protection principle in question, may overlap with other closely related principles as well. The EDPB underlines that the key elements and the examples presented hereunder are neither exhaustive nor binding, but are meant as guiding elements for each of the principles. Controllers need to assess how to guarantee compliance with the principles in the context of the concrete processing operation in question.

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

63. While this section focuses on the implementation of the principles, the controller should also implement appropriate and effective ways to protect data subjects’ rights, also according to Chapter III in the GDPR where this is not already mandated by the principles themselves.

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

64. The accountability principle is overarching: it requires the controller to be responsible choosing the necessary technical and organisational measures.

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

65. The controller must be clear and open with the data subject about how they will collect, use and share personal data. Transparency is about enabling data subjects to understand, and if necessary, make use of their rights in Articles 15 to 22. The principle is embedded in Articles 12, 13, 14 and 34. Measures and safeguards put in place to support the principle of transparency should also support the implementation of these Articles.

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

3.1 Transparency [24]

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

[24]Elaboration on how to understand the concept of transparency can be found in Article 29 Working Party. «Guidelines on transparency under Regulation 2016/679». WP 260 rev.01, 11 April 2018. ec.europa.eu/newsroom/article29/document.cfm?action=display&doc_id=51025 — endorsed by the EDPB

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

66. Key design and default elements for the principle of transparency may include:

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

•Clarity – Information shall be in clear and plain language, concise and intelligible.

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

•Semantics – Communication should have a clear meaning to the audience in question.

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

•Accessibility — Information shall be easily accessible for the data subject.

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

•Contextual – Information should be provided at the relevant time and in the appropriate form.

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

•Relevance – Information should be relevant and applicable to the specific data subject.

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

•Universal design – Information shall be accessible to all data subjects, include use of machine readable languages to facilitate and automate readability and clarity.

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

•Comprehensible – Data subjects should have a fair understanding of what they can expect with regards to the processing of their personal data, particularly when the data subjects are children or other vulnerable groups.

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

• Multi-channel – Information should be provided in different channels and media, not only the textual, to increase the probability for the information to effectively reach the data subject.

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

• Layered – The information should be layered in a manner that resolves the tension between completeness and understanding, while accounting for data subjects’ reasonable expectations.

Пример [25]

Example [25]

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

[25] The French Data Protection Authority has published several examples illustrating best practices in informing users as well as other transparency principles: https://design.cnil.fr/en/.

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

A controller is designing a privacy policy on their website in order to comply with the requirements of transparency. The privacy policy should not contain a lengthy bulk of information that is difficult for the average data subject to penetrate and understand. It shall be written in clear and concise language and make it easy for the user of the website to understand how their personal data is processed. The controller therefore provides information in a layered manner, where the most important points are highlighted. More detailed information is made easily available. Drop-down menus and links to other pages are provided to further explain the various items, and concepts used in the policy. The controller also makes sure that the information is provided in a multi-channel manner, providing video clips to explain the most important points of the written information. Synergy between the various pages is vital to ensure that the layered approach does not heighten confusion, rather reduce it.

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

The privacy policy should not be difficult for data subjects to access. The privacy policy is thus made available and visible on all web-pages of the site in question, so that the data subject is always only one click away from accessing the information. The information provided is also designed in accordance with the best practices and standards of universal design to make it accessible to all.

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

Moreover, necessary information should also be provided in the right context, at the appropriate time. Since the controller carries out many processing operations using the data collected on the website, a general privacy policy on the website alone is not sufficient for the controller to meet the requirements of transparency. The controller therefore designs an information flow, presenting the data subject with relevant information within the appropriate contexts using e.g. informational snippets or pop-ups. For example, when asking the data subject to enter personal data, the controller informs the data subject of how the personal data will be processed and why that personal data is necessary for the processing.

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

67. The controller must identify a valid legal basis for the processing of personal data. Measures and safeguards should support the requirement to make sure that the whole processing lifecycle is in line with the relevant legal grounds of processing.

3.2 Законность

3.2 Lawfulness

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

68. Key design and default elements for lawfulness may include:

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

• Relevance – The correct legal basis shall be applied to the processing.

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

• Differentiation [26] – The legal basis used for each processing activity shall be differentiated.

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

[26] EDPB. «Guidelines 2/2019 on the processing of personal data under Article 6(1)(b) GDPR in the context of the provision of online services to data subjects». Version 2.0, 8 October 2019. edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines-art_6-1-b- adopted_after_public_consultation_en.pdf

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

• Specified purpose – The appropriate legal basis must be clearly connected to the specific purpose of processing.[27]

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

[27] See section on purpose limitation below.

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

• Necessity– Processing must be necessary and unconditional for the purpose to be lawful.

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

• Autonomy – The data subject should be granted the highest degree of autonomy as possible with respect to control over personal data within the frames of the legal basis.

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

• Gaining consent – consent must be freely given, specific, informed and unambiguous.[28] Particular consideration should be given to the capacity of children and young people to provide informed consent.

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

[28] See Guidelines 05/2020 on consent under Regulation 2016/679. https://edpb.europa.eu/our-work- tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en

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

• Consent withdrawal – Where consent is the legal basis, the processing should facilitate withdrawal of consent. Withdrawal shall be as easy as giving consent. If not, then the consent mechanism of the controller does not comply with the GDPR.[29]

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

[29] See Guidelines 05/2020 on consent under Regulation 2016/679, p. 24. https://edpb.europa.eu/our-work- tools/our-documents/guidelines/guidelines-052020-consent-under-regulation-2016679_en

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

• Balancing of interests – Where legitimate interests is the legal basis, the controller must carry out a weighted balancing of interest, giving particular consideration to the power imbalance, specifically children under the age of 18 and other vulnerable groups. There shall be measures and safeguards to mitigate the negative impact on the data subjects.

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

• Predetermination – The legal basis shall be established before the processing takes place.

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

• Cessation – If the legal basis ceases to apply, the processing shall cease accordingly.

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

• Adjust – If there is a valid change of legal basis for the processing, the actual processing must be adjusted in accordance with the new legal basis.[30]

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

[30] If the original legal basis is consent, see Guidelines 05/2020 on consent under Regulation 2016/679. https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-052020-consent-under- regulation-2016679_en

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

• Allocation of responsibility – Whenever joint controllership is envisaged, the parties must apportion in a clear and transparent way their respective responsibilities vis-à-vis the data subject, and design the measures of the processing in accordance with this allocation.

Пример

Example

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

A bank plans to offer a service to improve efficiency in the management of loan applications. The idea behind the service is that the bank, by requesting permission from the customer, is able to retrieve data about the customer directly from the public tax authorities. This example does not consider processing of personal data from other sources.

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

Obtaining personal data about the data subject’s financial situation is necessary in order to take steps at the request of the data subject prior to entering into a loan contract.[31] However, gathering personal data directly from the tax administration is not considered necessary, because the customer is able to enter into a contract by providing the information from the tax administration him or herself. Although the bank may have a legitimate interest in acquiring the documentation from the tax authorities directly, for example to ensure efficiency in the loan processing, giving banks such direct access to the personal data of applicants presents a risks related to the use or potential misuse of access rights

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

[31] See Article 6(1)(b) GDPR.

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

When implementing the principle of lawfulness, the controller realizes that in this context, they cannot use the «necessary for contract» basis for the part of the processing that involves gathering personal data directly from the tax authorities. The fact that this specific processing presents a risk of the data subject becoming less involved in the processing of their data is also a relevant factor in assessing the lawfulness of the processing itself. The bank concludes that this part of the processing has to rely on another legal basis of processing. In the particular Member State where the controller is located, there are national laws that permits the bank to gather information from the public tax authorities directly, where the data subject consents to this beforehand.

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

The bank therefore presents information about the processing on the online application platform in such a manner that makes it easy for data subjects to understand what processing is mandatory and what is optional. The processing options, by default, do not allow retrieval of data directly from other sources than the data subject herself, and the option for direct information retrieval is presented in a manner that does not deter the data subject from abstaining. Any consent given to collect data directly from other controllers is a temporary right of access to a specific set of information.

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

Any given consent is processed electronically in a documentable manner, and data subjects are presented with an easy way of controlling what they have consented to and to withdraw their consent.

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

The controller has assessed these DPbDD requirements beforehand and includes all of these criteria in their requirements specification for the tender to procure the platform. The controller is aware that if they do not include the DPbDD requirements in the tender, it may either be too late or a very costly process to implement data protection afterwards.

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

3.3 Fairness

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

69. Fairness is an overarching principle which requires that personal data should not be processed in a way that is unjustifiably detrimental, unlawfully discriminatory, unexpected or misleading to the data subject. Measures and safeguards implementing the principle of fairness also support the rights and freedoms of data subjects, specifically the right to information (transparency), the right to intervene (access, erasure, data portability, rectify) and the right to limit the processing (right not to be subject to automated individual decision-making and non-discrimination of data subjects in such processes).

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

70. Key design and default elements may include:

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

• Autonomy – Data subjects should be granted the highest degree of autonomy possible to determine the use made of their personal data, as well as over the scope and conditions of that use or processing.

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

• Interaction – Data subjects must be able to communicate and exercise their rights in respect of the personal data processed by the controller.

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

• Expectation – Processing should correspond with data subjects’ reasonable expectations.

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

• Non-discrimination – The controller shall not unfairly discriminate against data subjects.

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

• Non-exploitation – The controller shall not exploit the needs or vulnerabilities of data subjects.

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

• Consumer choice – The controller should not «lock in» their users in an unfair manner. Whenever a service processing personal data is proprietary, it may create a lock-in to the service, which may not be fair, if it impairs the data subjects’ possibility to exercise their right of data portability in accordance with Article 20.

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

• Power balance – Power balance should be a key objective of the controller-data subject relationship. Power imbalances should be avoided. When this is not possible, they should be recognised and accounted for with suitable countermeasures.

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

• No risk transfer – Controllers should not transfer the risks of the enterprise to the data subjects.

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

• No deception – Data processing information and options should be provided in an objective and neutral way, avoiding any deceptive or manipulative language or design.

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

• Respect rights – The controller must respect the fundamental rights of data subjects and implement appropriate measures and safeguards and not impinge on those rights unless expressly justified by law.

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

• Ethical – The controller should see the processing’s wider impact on individuals’ rights and dignity.

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

• Truthful – The controller must make available information about how they process personal data, they should act as they declare they will and not mislead the data subjects.

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

• Human intervention – The controller must incorporate qualified human intervention that is capable of uncovering biases that machines may create in accordance with the right to not be subject to automated individual decision making in Article 22.[32]

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

[32] See Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679. https://ec.europa.eu/newsroom/article29/document.cfm?action=display&doc_id=49826

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

• Fair algorithms – Regularly assess whether algorithms are functioning in line with the purposes and adjust the algorithms to mitigate uncovered biases and ensure fairness in the processing. Data subjects should be informed about the functioning of the processing of personal data based on algorithms that analyse or make predictions about them, such as work performance, economic situation, health, personal preferences, reliability or behaviour, location or movements.[33]

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

[33] See recital 71 GDPR

Пример 1

Example 1

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

A controller operates a search engine that processes mostly user-generated personal data. The controller benefits from having large amounts of personal data and being able to use that personal data for targeted advertisements. The controller therefore wishes to influence data subjects to allow more extensive collection and use of their personal data. Consent is to be collected by presenting processing options to the data subject.

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

When implementing the fairness principle, taking into account the nature, scope, context and purpose of the processing, the controller realizes that they cannot present the options in a way that nudges the data subject in the direction of allowing the controller to collect more personal data than if the options were presented in an equal and neutral way. This means that they cannot present the processing options in such a manner that makes it difficult for data subjects to abstain from sharing their data, or make it difficult for the data subjects to adjust their privacy settings and limit the processing. These are examples of dark patterns, which are contrary to the spirit of Article 25. The default options for the processing should not be invasive, and the choice for further processing should be presented in a manner that does not pressure the data subject to give consent. Therefore, the controller presents the options to consent or abstain as two equally visible choices, accurately representing the ramifications of each choice to the data subject.

Пример 2

Example 2

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

Another controller processes personal data for the provision of a streaming service where users may choose between a regular subscription of standard quality and a premium subscription with higher quality. As part of the premium subscription, subscribers get prioritized customer service.

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

With regard to the fairness principle, the prioritized customer service granted to premium subscribers cannot discriminate the regular subscribers’ access to exercise their rights according to the GDPR Article 12. This means that although the premium subscribers get prioritized service, such prioritization cannot result in a lack of appropriate measures to respond to request from regular subscribers without undue delay and in any event within one month of receipt of the requests.

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

Prioritized customers may pay to get better service, but all data subjects shall have equal and indiscriminate access to enforce their rights and freedoms as required under Article 12.

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

3.4 Purpose Limitation [34]

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

[34] The Article 29 Working Party provided guidance for the understanding of the principle of purpose limitation under Directive 95/46/EC. Although the Opinion is not adopted by the EDBP, it may still be relevant as the wording of the principle is the same under the GDPR. Article 29 Working Party. «Opinion 03/2013 on purpose limitation». WP 203, 2 April 2013. ec.europa.eu/justice/article-29/documentation/opinion- recommendation/files/2013/wp203_en.pdf

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

71. The controller must collect data for specified, explicit, and legitimate purposes, and not further process the data in a manner that is incompatible with the purposes for which they were collected.[35] The design of the processing should therefore be shaped by what is necessary to achieve the purposes. If any further processing is to take place, the controller must first make sure that this processing has purposes compatible with the original ones and design such processing accordingly. Whether a new purpose is compatible or not, shall be assessed according to the criteria in Article 6(4).

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

72. Key design and default elements may include:

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

• Predetermination – The legitimate purposes shall be determined before the design of the processing.

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

• Specificity – The purposes shall be specified and explicit as to why personal data is being processed.

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

• Purpose orientation – The purpose of processing should guide the design of the processing and set processing boundaries.

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

• Necessity – The purpose determines what personal data is necessary for the processing.

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

• Compatibility – Any new purpose must be compatible with the original purpose for which the data was collected and guide relevant changes in design.

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

• Limit further processing – The controller should not connect datasets or perform any further processing for new incompatible purposes.

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

• Limitations of reuse – The controller should use technical measures, including hashing and encryption, to limit the possibility of repurposing personal data. The controller should also have organisational measures, such as policies and contractual obligations, which limit reuse of personal data.

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

• Review – The controller should regularly review whether the processing is necessary for the purposes for which the data was collected and test the design against purpose limitation.

• Technical limitations of reuse – The controller should use technical measures, including hashing and cryptography, to limit the possibility of repurposing personal data.

Пример

Example

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

The controller processes personal data about its customers. The purpose of the processing is to fulfil a contract, i.e. to be able to deliver goods to the correct address and obtain payment. The personal data stored is the purchase history, name, address, e-mail address and telephone number.

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

The controller is considering buying a Customer Relationship Management (CRM) product that gathers all the customer data about sales, marketing and customer service in one place. The product gives the opportunity of storing all phone calls, activities, documents, emails and marketing campaigns to get a 360-degree view of the customer. Moreover, the CRM is capable of automatically analysing the customers’ purchasing power by using public information. The purpose of the analysis is to better target advertising activities. Those activities do not form part of the original lawful purpose of the processing.

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

To be in line with the principle of purpose limitation, the controller requires the provider of the product to map the different processing activities that use personal data to the purposes relevant for the controller.

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

After receiving the results of the mapping, the controller assesses whether the new marketing purpose and the targeted advertisement purpose are compatible with the original purposes defined when the data was collected, and whether there is a sufficient legal basis for the respective processing. If the assessment does not return a positive answer, the controller shall not proceed to use the respective functionalities. Alternatively, the controller could choose to forego the assessment and simply not make use of the described functionalities of the product.

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

3.5 Data Minimisation

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

73. Only personal data that is adequate, relevant and limited to what is necessary for the purpose shall be processed. [36] As a result, the controller has to predetermine which features and parameters of processing systems and their supporting functions are permissible. Data minimisation substantiates and operationalises the principle of necessity. In the further processing, the controller should periodically consider whether processed personal data is still adequate, relevant and necessary, or if the data shall be deleted or anonymized.

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

[36] Art. 5(1)(c) GDPR

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

74. Controllers should first of all determine whether they even need to process personal data for their relevant purposes. The controller should verify whether the relevant purposes can be achieved by processing less personal data, or having less detailed or aggregated personal data or without having to process personal data at all.[37] Such verification should take place before any processing takes place, but could also be carried out at any point during the processing lifecycle. This is also consistent with Article 11.

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

[37] Recital 39 GDPR so states: «…Personal data should be processed only if the purpose of the processing could not reasonably be fulfilled by other means.»

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

75. Minimising can also refer to the degree of identification. If the purpose of the processing does not require the final set of data to refer to an identified or identifiable individual (such as in statistics), but the initial processing does (e.g. before data aggregation), then the controller shall delete or anonymize personal data as soon as identification is no longer needed. Or, if continued identification is needed for other processing activities, personal data should be pseudonymized to mitigate risks for the data subjects’ rights.

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

76. Key design and default data minimisation elements may include:

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

• Data avoidance — Avoid processing personal data altogether when this is possible for the relevant purpose.

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

• Limitation – Limit the amount of personal data collected to what is necessary for the purpose

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

• Access limitation – Shape the data processing in a way that a minimal number of people need access to personal data to perform their duties, and limit access accordingly.

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

• Relevance – Personal data should be relevant to the processing in question, and the controller should be able to demonstrate this relevance.

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

• Necessity – Each personal data category shall be necessary for the specified purposes and should only be processed if it is not possible to fulfil the purpose by other means.

• Limitation – Limit the amount of personal data collected to what is necessary for the purpose

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

• Aggregation – Use aggregated data when possible.

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

• Pseudonymization – Pseudonymize personal data as soon as it is no longer necessary to have directly identifiable personal data, and store identification keys separately.

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

• Anonymization and deletion – Where personal data is not, or no longer necessary for the purpose, personal data shall be anonymized or deleted.

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

• Data flow – The data flow should be made efficient enough to not create more copies than necessary.

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

• «State of the art» – The controller should apply up to date and appropriate technologies for data avoidance and minimisation.

Пример 1

Example 1

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

A bookshop wants to add to their revenue by selling their books online. The bookshop owner wants to set up a standardised form for the ordering process. To ensure customers fill out all the wanted information the bookshop owner makes all of the fields in the form mandatory (if you don’t fill out all the fields the customer can’t place the order). The webshop owner initially uses a standard contact form, which asks information including the customer’s date of birth, phone number and home address. However, not all the fields in the form are necessary for the purpose of buying and delivering the books. In this particular case, if the data subject pays for the product up front, the data subject’s date of birth and phone number are not necessary for the purchase of the product. This means that these cannot be required fields in the web form to order the product, unless the controller can clearly demonstrate that it is otherwise necessary, and why the fields are necessary. Moreover, there are situations where an address will not be necessary. For example, when ordering an eBook the customer can download the product directly to their device.

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

The webshop owner therefore decides to make two web forms: one for ordering books, with a field for the customer’s address and one web form for ordering eBooks without a field for the customer’s address.

Пример 2

Example 2

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

A public transportation company wishes to gather statistical information based on travellers’ routes. This is useful for the purposes of making proper choices on changes in public transport schedules and proper routings of the trains. The passengers have to pass their ticket through a reader every time they enter or exit a means of transport. Having carried out a risk assessment related to the rights and freedoms of passengers’ regarding the collection of passengers’ travel routes, the controller establishes that it is possible to identify the passengers in circumstances where they live or work in scarcely populated areas, based on single route identification thanks to the ticket identifier. Therefore, since it is not necessary for the purpose of optimizing the public transport schedules and routings of the trains, the controller does not store the ticket identifier. Once the trip is over, the controller only stores the individual travel routes so as to not be able to identify trips connected to a single ticket, but only retains information about separate travel routes.

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

In cases where there can be a risk of identifying a person solely by their travel route (this might be the case in remote areas) the controller implements measures to aggregate the travel route, such as cutting the beginning and the end of the route.

Пример 3

Example 3

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

A courier aims at assessing the effectiveness of its deliveries in terms of delivery times, workload scheduling and fuel consumption. In order to reach this goal, the courier has to process a number of personal data relating to both employees (drivers) and customers (addresses, items to be delivered, etc.). This processing operation entails risks of both monitoring employees, which requires specific legal safeguards, and tracking customers’ habits through the knowledge of the delivered items over time. These risks can be significantly reduced with appropriate pseudonymization of employees and customers. In particular if pseudonymization keys are frequently rotated and macro areas are considered instead of detailed addresses, an effective data minimisation is pursued, and the controller can solely focus on the delivery process and on the purpose of resource optimization, without crossing the threshold of monitoring individuals’ (customers’ or employees’) behaviours.

Пример 4

Example 4

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

A hospital is collecting data about its patients in a hospital information system (electronic health record). Hospital staff needs to access patient files to inform their decisions regarding care for and treatment of the patients, and for the documentation of all diagnostic, care and treatment actions taken. By default, access is granted to only those members of the medical staff who are assigned to the treatment of the respective patient in the speciality department she or he is assigned to. The group of people with access to a patient’s file is enlarged if other departments or diagnostic units are involved in the treatment. After the patient is discharged, and billing is completed, access is reduced to a small group of employees per speciality department who answer requests for medical information or a consultation made or asked for by other medical service providers upon authorization by the respective patient.

3.6 Точность

3.6 Accuracy

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

77. Personal data shall be accurate and kept up to date, and every reasonable step shall be taken to ensure that personal data that is inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay. [38]

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

[38] Art. 5(1)(d) GDPR

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

78. The requirements should be seen in relation to the risks and consequences of the concrete use of data. Inaccurate personal data could be a risk to the data subjects’ rights and freedoms, for example when leading to a faulty diagnosis or wrongful treatment of a health protocol, or an incorrect image of a person can lead to decisions being made on the wrong basis either manually, using automated decision-making, or through artificial intelligence.

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

79. Key design and default accuracy elements may include:

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

• Data source – Sources of personal data should be reliable in terms of data accuracy.

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

• Degree of accuracy – Each personal data element should be as accurate as necessary for the specified purposes.

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

• Measurably accurate — Reduce the number of false positives/negatives, for example biases in automated decisions and artificial intelligence.

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

• Verification – Depending on the nature of the data, in relation to how often it may change, the controller should verify the correctness of personal data with the data subject before and at different stages of the processing (e.g. to age requirements).

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

• Erasure/rectification – The controller shall erase or rectify inaccurate data without delay. The controller shall in particular facilitate this where the data subjects are or were children and later want to remove such personal data.[39]

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

[39] Cf. Recital 65.

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

• Error propagation avoidance – Controllers should mitigate the effect of an accumulated error in the processing chain.

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

• Access – Data subjects should be given information about and effective access to personal data in accordance with the GDPR articles 12 to 15 in order to control accuracy and rectify as needed.

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

• Continued accuracy – Personal data should be accurate at all stages of the processing, tests of accuracy should be carried out at critical steps.

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

• Up to date – Personal data shall be updated if necessary for the purpose.

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

• Data design — Use of technological and organisational design features to decrease inaccuracy, for example present concise predetermined choices instead of free text fields.

Пример 1

Example 1

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

An insurance company wishes to use artificial intelligence (AI) to profile customers buying insurance as a basis for their decision making when calculating the insurance risk. When determining how their AI solutions should be developed, they are determining the means of processing and shall consider data protection by design when choosing an AI application from a vendor and when deciding on how to train the AI.

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

When determining how to train the AI, the controller should have accurate data to achieve precise results. Therefore, the controller should ensure that the data used to train the AI is accurate.

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

Granted that they have a valid legal basis to train the AI using personal data from a large subset of their existing customers, the controller chooses a pool of customers that is representative of the population to also avoid bias.

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

The customer data is then collected from the respective data handling system, including data on the type of insurance, for example health insurance, home insurance, travel insurance, etc. as well as data from public registries they have lawful access to. All data are pseudonymized prior to transfer to the system dedicated to the training of the AI model.

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

To ensure that the data used for AI training is as accurate as possible, the controller only collects data from data sources with correct and up-to date information.

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

The insurance company tests whether the AI is reliable and provides non-discriminatory results both during its development and finally before the product is released. When the AI is fully trained and operative, the insurance company uses the results to support the insurance risk assessments, yet without solely relying on the AI to decide whether to grant insurance, unless the decision is made in accordance with the exceptions in Article 22 (2) GDPR.

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

The insurance company will also regularly review the results from the AI, to maintain the reliability and when necessary adjust the algorithm.

Пример 2

Example 2

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

The controller is a health institution looking to find methods to ensure the integrity and accuracy of personal data in their client registers.

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

In situations where two persons arrive at the institution at the same time and receive the same treatment, there is a risk of mistaking them if the only parameter to distinguish them is by name. To ensure accuracy, the controller needs a unique identifier for each person, and therefore more information than just the name of the client.

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

The institution uses several systems containing personal information of clients, and needs to ensure that the information related to the client is correct, accurate and consistent in all the systems at any point in time. The institution has identified several risks that may arise if information is changed in one system but not in the others.

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

The controller decides to mitigate the risk by using a hashing technique that can be used to ensure integrity of data in the treatment journal. Immutable cryptographic time stamps are created for treatment journal records and the client associated with them so that any changes can be recognized, correlated and traced if required.

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

3.7 Storage limitation

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

80. The controller must ensure that personal data is kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data is processed.[40] It is vital that the controller knows exactly what personal data the company processes and why. The purpose of the processing shall be the main criterion to decide in how long personal data shall be stored.

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

[40] Art. 5(1)(c) GDPR

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

81. Measures and safeguards that implement the principle of storage limitation shall complement the rights and freedoms of the data subjects, specifically, the right to erasure and the right to object.

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

82. Key design and default storage limitation elements may include:

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

• Deletion and anonymization – The controller should have clear internal procedures and functionalities for deletion and/or anonymization.

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

• Effectiveness of anonymization/deletion – The controller shall make sure that it is not possible to re-identify anonymized data or recover deleted data, and should test whether this is possible.

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

• Automation – Deletion of certain personal data should be automated.

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

• Storage criteria – The controller shall determine what data and length of storage is necessary for the purpose.

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

• Justification – The controller shall be able to justify why the period of storage is necessary for the purpose and the personal data in question, and be able to disclose the rationale behind, and legal grounds for the retention period.

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

• Enforcement of retention policies – The controller should enforce internal retention policies and conduct tests of whether the organization practices its policies.

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

• Backups/logs – Controllers shall determine what personal data and length of storage is necessary for back-ups and logs.

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

• Data flow – Controllers should beware of the flow of personal data, and the storage of any copies thereof, and seek to limit their «temporary» storage.

Пример

Example

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

The controller collects personal data where the purpose of the processing is to administer a membership of the data subject. The personal data shall be deleted when the membership is terminated and there is no legal basis for further storage of the data.

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

The controller first draws up an internal procedure for data retention and deletion. According to this, employees shall manually delete personal data after the retention period ends. The employee follows the procedure to regularly delete and correct data from any devices, from backups, logs, e-mails and other relevant storage media.

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

To make deletion more effective, and less error-prone, the controller then implements an automatic system instead, in order to delete data automatically, reliably and more regularly. The system is configured to follow the given procedure for data deletion which then occurs at a predefined regular interval to remove personal data from all of the company’s storage media. The controller reviews and tests the retention procedure regularly and ensures that it concurs with the up-to-date retention policy.

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

83. The principle of integrity and confidentiality includes protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures. The security of personal data requires appropriate measures designed to prevent and manage data breach incidents; to guarantee the proper execution of data processing tasks, and compliance with the other principles; and to facilitate the effective exercise of individuals’ rights.

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

3.8 Integrity and confidentiality

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

84. Recital 78 states that one of the DPbDD measures could consist of enabling the controller to «create and improve security features». Along with other DPbDD measures, Recital 78 suggests a responsibility on the controllers to continually assess whether it is using the appropriate means of processing at all times and to assess whether the chosen measures actually counter the existing vulnerabilities. Furthermore, controllers should conduct regular reviews of the information security measures that surround and protect personal data, and the procedure for handling data breaches.

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

85. Key design and default integrity and confidentiality elements may include:

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

• Information security management system (ISMS) – Have an operative means of managing policies and procedures for information security.

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

• Risk analysis – Assess the risks against the security of personal data by considering the impact on individuals’ rights and counter identified risks. For use in risk assessment; develop and maintain a comprehensive, systematic and realistic «threat modelling» and an attack surface analysis of the designed software to reduce attack vectors and opportunities to exploit weak points and vulnerabilities.

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

• Security by design – Consider security requirements as early as possible in the system design and development and continuously integrate and perform relevant tests.

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

• Maintenance – Regular review and test software, hardware, systems and services, etc. to uncover vulnerabilities of the systems supporting the processing.

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

• Access control management – Only the authorized personnel who need to should have access to the personal data necessary for their processing tasks, and the controller should differentiate between access privileges of authorized personnel.

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

o Access limitation(agents) – Shape the data processing in a way that a minimal number of people need access to personal data to perform their duties, and limit access accordingly.

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

o Access limitation(content) – In the context of each processing operation, limit access to only those attributes per data set that are needed to perform that operation. Moreover, limit access to data pertaining to those data subjects who are in the remit of the respective employee.

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

o Access segregation – Shape the data processing in a way that no individual needs comprehensive access to all data collected about a data subject, much less all personal data of a particular category of data subjects.

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

• Secure transfers – Transfers shall be secured against unauthorized and accidental access and changes

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

• Secure storage – Data storage shall be secure from unauthorized access and changes. There should be procedures to assess the risk of centralized or decentralized storage, and what categories of personal data this applies to. Some data may need additional security measures than others or isolation from others.

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

• Pseudonymization – Personal data and back-ups/logs should be pseudonymized as a security measure to minimise risks of potential data breaches, for example using hashing or encryption.

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

• Backups/logs – Keep back-ups and logs to the extent necessary for information security, use audit trails and event monitoring as a routine security control. These shall be protected from unauthorised and accidental access and change and reviewed regularly and incidents should be handled promptly.

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

• Disaster recovery/ business continuity – Address information system disaster recovery and business continuity requirements to restore the availability of personal data following up major incidents.

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

• Protection according to risk – All categories of personal data should be protected with measures adequate with respect to the risk of a security breach. Data presenting special risks should, when possible, be kept separated from the rest of the personal data.

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

• Security incident response management – Have in place routines, procedures and resources to detect, contain, handle, report and learn from data breaches.

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

• Incident management – Controller should have processes in place to handle breaches and incidents, in order to make the processing system more robust. This includes notification procedures, such as management of notification (to the supervisory authority) and information (to data subjects).

• Maintenance and development – Regular review and test software to uncover vulnerabilities of the systems supporting the processing

Пример

Example

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

A controller wants to extract large quantities of personal data from a medical database containing electronic (patient) health records to a dedicated database server in the company in order to process the extracted data for quality assurance purposes. The company has assessed the risk for routing the extracts to a server that is accessible to all of the company’s employees as likely to be high for data subjects’ rights and freedoms. Since there is only one department in the company who needs to process the patient data extracts, the controller decides to restrict access to the dedicated server to employees in that department. Moreover, to further reduce risk, the data will be pseudonymized before they are transferred.

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

To regulate access and mitigate possible damage from malware, the company decides to segregate the network, and establish access controls to the server. In addition, they put up security monitoring and an intrusion detection and prevention system and isolates it from routine use. An automated auditing system is put in place to monitor access and changes. Reporting and automated alerts are generated from this when certain events related to usage are configured. The controller will ensure that users only have access on a need to know basis and with the appropriate access level. Inappropriate use can be quickly and easily detected.

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

Some of the extracts have to be compared with new extracts, and therefore are required to be stored for three months. The controller decides to put them into separate databases on the same server, and use both transparent and column-level encryption to store them. Keys for column data decryption are stored in dedicated security modules that can only be used by authorized personnel, but not extracted.

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

Handling upcoming incidents makes the system more robust, and reliable. The data controller understands that preventative and effective measures and safeguards should be built into all personal data processing it undertakes now and in the future, and that doing so may help prevent future such data breach incidents.

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

The controller establishes these security measures both to ensure accuracy, integrity and confidentiality, but also to prevent malware spread by cyber-attacks and to make the solution robust. Having robust security measures contributes to build trust with the data subjects.

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

3.9 Accountability [41]

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

[41] See Recital 74, where controllers are required to demonstrate the effectiveness of their measures.

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

86. The principle of accountability states that the controller shall be responsible for, and be able to demonstrate compliance with all of the abovementioned principles.

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

87. The controller needs to be able to demonstrate compliance with the principles. In doing so, the controller may demonstrate the effects of the measures taken to protect the data subjects’ rights, and why the measures are considered to be appropriate and effective. For example, demonstrating why a measure is appropriate to ensure the principle of storage limitation in an effective manner.

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

88. To be able to process personal data responsibly, the controller should have both the knowledge of and the ability to implement data protection. This entails that the controller should understand their data protection obligations of the GDPR and be able to comply with these obligations.

4. СЕРТИФИКАЦИЯ

4. ARTICLE 25(3) CERTIFICATION

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

89. According to Article 25(3), certification pursuant to Article 42 may be used as an element to demonstrate compliance with DPbDD. Conversely, documents demonstrating compliance with DPbDD may also be useful in a certification process. This means that where a processing operation by a controller or a processor has been certified as per Article 42, supervisory authorities shall take this into account in their assessment of compliance with the GDPR, specifically with regards to DPbDD.

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

90. When a processing operation by a controller or processor is certified according to Article 42, the elements that contribute to demonstrating compliance with Article 25(1) and (2) are the design processes, i.e. the process of determining the means of processing, the governance and the technical and organizational measures to implement the data protection principles The data protection certification criteria are determined by the certification bodies or certification scheme owners and then approved by the competent supervisory authority or by the EDPB. For further information about certification mechanisms, we refer the reader to the EDPB Guideline on Certification[42] and other relevant guidance, as published on the EDPB website.

[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.

[42] EDPB. «Guidelines 1/2018 on certification and identifying certification criteria in accordance with Articles 42 and 43 of the Regulation». Version 3.0, 4 June 2019. edpb.europa.eu/sites/edpb/files/files/file1/edpb_guidelines_201801_v3.0_certificationcriteria_annex2_en.pdf

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

91. Even where a processing operation is awarded a certification in accordance with Article 42, the controller still has the responsibility to continuously monitor and improve compliance with the DPbDD- criteria of Article 25.

5. ПРИВЕДЕНИЕ В ИСПОЛНЕНИЕ СТАТЬИ 25 И ПОСЛЕДСТВИЯ

5. ENFORCEMENT OF ARTICLE 25 AND CONSEQUENCES

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

92. Supervisory authorities may assess compliance with Article 25 according to the procedures listed in Article 58. The corrective powers are specified in Article 58(2) and include the issuance of warnings, reprimands, orders to comply with data subjects’ rights, limitations on or ban of processing, administrative fines, etc.

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

93. DPbDD is further a factor in determining the level of monetary sanctions for breaches of the GDPR, see Article 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.

[44] More information on fines can be found in Article 29 Working Party. «Guidelines on application and setting of administrative fines for the purposes of the Regulation 2016/679». WP 253, 3 October 2017. ec.europa.eu/newsroom/just/document.cfm?doc_id=47889 — endorsed by the EDPB.

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

[43] Article 83(2)(d) GDPR stipulates that in determining the imposition of fines for breach of the GDPR «due regard» shall be taken of «the degree of responsibility of the controller or processor taking into account technical and organisational measures implemented by them pursuant to Articles 25 and 32».

6. ВЫВОДЫ И РЕКОМЕНДАЦИИ

6. RECOMMENDATIONS

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

94. Although not directly addressed in Article 25, processors and producers are also recognized as key enablers for DPbDD, they should be aware that controllers are required to only process personal data with systems and technologies that have built-in data protection.

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

95. When processing on behalf of controllers, or providing solutions to controllers, processors and producers should use their expertise to build trust and guide their customers, including SMEs, in designing /procuring solutions that embed data protection into the processing. This means in turn that the design of products and services should facilitate controllers’ needs.

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

96. It should be kept in mind when implementing Article 25 that the main design objective is the the effective implementation of the principles and protection of the rights of data subjects into the appropriate measures of the processing. In order to facilitate and enhance the adoption of DPbDD, we make the following recommendations to controllers as well as producers and processors:

Recommendations

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

• Controllers should think of data protection from the initial stages of planning a processing operation, even before the time of determination of the means of processing.

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

• Where the controller has a Data Protection Officer (DPO), the EDPB encourages the active involvement of the DPO to integrate DPbDD in the procurement and development procedures, as well as in the whole processing life-cycle.

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

• A processing operation may be certified. The ability to get a processing operation certified provides an added value to a controller when choosing between different processing software, hardware, services and/or systems from producers or processors. Therefore, producers should strive to demonstrate DPbDD in the life-cycle of their development of a processing solution. A certification seal may also guide data subjects in their choice between different goods and services. Having the ability to get a processing certified can serve as a competitive advantage for producers, processors and controllers, and even enhances data subjects’ trust in the processing of their personal data. If no certification is offered, controllers should seek to have other guarantees that producers or processors comply with the requirements of DPbDD.

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

• Controllers, processors and producers, should consider their obligations to provide children under 18 and other vulnerable groups with specific protection in complying with DPbDD.

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

• Producers and processors should seek to facilitate DPbDD implementation in order to support the controller’s ability to comply with Article 25 obligations. Controllers, on the other hand, should not choose producers or processors who do not offer systems enabling or supporting the controller to comply with Article 25, because controllers will be held accountable for the lack of implementation thereof.

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

• Producers and processors should play an active role in ensuring that the criteria for the «state of the art» are met, and notify controllers of any changes to the «state of the art» that may affect the effectiveness of the measures they have in place. Controllers should include this requirement as a contractual clause to make sure they are kept up to date.

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

• The EDPB recommends controllers to require that producers and processors demonstrate how their hardware, software, services or systems enable the controller to comply with the requirements to accountability in accordance with DPbDD, for example by using key performance indicators to demonstrate the effectiveness of the measures and safeguards at implementing the principles and rights.

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

• The EDPB emphasizes the need for a harmonized approach to implement principles and rights in an effective manner and encourages associations or bodies preparing codes of conduct in accordance with Article 40 to also incorporate sector-specific guidance on DPbDD.

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

• Controllers should be fair to data subjects and transparent on how they assess and demonstrate effective DPbDD implementation, in the same manner as controllers demonstrate compliance with the GDPR under the principle of accountability.

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

• Privacy-enhancing technologies (PETs) that have reached the state-of-the-art maturity can be employed as a measure in accordance with the DPbDD requirements if appropriate in a risk based approach. PETs in themselves do not necessarily cover the obligations of Article 25. Controllers shall assess whether the measure is appropriate and effective in implementing the data protection principles and the rights of data subjects.

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

• Existing legacy systems are under the same DPbDD-obligations as new systems. If legacy systems do not already comply with DPbDD, and changes cannot be made to comply with the obligations, then the legacy system simply does not meet GDPR-obligations and cannot be used to process personal data.

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

• Article 25 does not lower the threshold of requirements for SMEs. The following points may facilitate SMEs’ compliance with Article 25: o Do Early Risk Assessments o Start with small processing – then scale its scope sophistication later o Look for producer and processor guarantees of DPbDD, such as certification and adherence to code of conducts o Use Partners With A Good Track Record o Talk with DPAs o Read guidance from DPAs and the EDPB o Adhere to codes of conduct where available o Get Professional Help And Advice