SIST EN 17529:2022

Data protection and privacy by design and by default

This document provides requirements for manufacturers and/or service providers to implement Data protection and Privacy by Design and by Default (DPbDD) early in their development of their products and services, i.e. before (or independently of) any specific application integration, to make sure that they are as privacy ready as possible. The document will be applicable to all business sectors, including the security industry.

Datenschutz by Design und als Grundeinstellung

Dieses Dokument legt Anforderungen an Hersteller und/oder Diensterbringer fest, Datenschutz und Schutz der Privatsphäre durch Technikgestaltung und datenschutzfreundliche Voreinstellungen (DSTV) frühzeitig in der Entwicklung ihrer Produkte und Dienste umzusetzen, d. h. vor (oder unabhängig von) einer bestimmten Anwendungsintegration, um sicherzustellen, dass sie so datenschutzfähig wie möglich sind. Dieses Dokument ist anwendbar für alle Wirtschaftszweige, einschließlich der Sicherheitsindustrie.

Protection des données et de la vie privée dès la conception et par défaut

Le présent document spécifie les exigences auxquelles doivent se conformer les fabricants et/ou les fournisseurs de services pour mettre en oeuvre la protection des données et de la vie privée dès la conception et par défaut (DPPbDD) dès le début du développement de leurs produits et services, c'est-à-dire avant (ou indépendamment de) toute intégration dans une application spécifique, afin de s'assurer qu'ils sont aussi prêts que possible à respecter la vie privée. Le document s'applique à l'ensemble des secteurs d'activité, y compris à celui de la sécurité.

Varstvo podatkov in zasebnosti z načrtovanjem in kot privzeto

Ta dokument določa zahteve za proizvajalce in/ali ponudnike storitev za izvajanje varstva podatkov in zasebnosti z načrtovanjem in kot privzeto (DPbDD) na zgodnji stopnji razvoja svojih izdelkov in storitev, tj. pred vključevanjem posebnih aplikacij (ali neodvisno od njega), da se zagotovi njihova čim boljša pripravljenost na varstvo zasebnosti. Dokument se bo uporabljal za vse poslovne sektorje, vključno z varnostnim sektorjem.

General Information

• Status: Published
• Public Enquiry End Date: 06-Sep-2020
• Publication Date: 16-Aug-2022
• ICS: 35.030 - IT Security
• Technical Committee: ITC - Information technology
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 23-Jun-2022
• Due Date: 28-Aug-2022
• Completion Date: 17-Aug-2022
• Directive: 2016/679 - REGULATION (EU) 2016/679 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 (General Data Protection Regulation)
• Directive: 95/46/EC - Protection of individuals with regard to the processing of personal data and on the free movement of such data
• Mandate: M/530 - [C(2015)102] Standardization request on privacy and personal data protection management in the design and development and in the production and service provision and process in the security technologies
• Ref Project: EN 17529:2022 - Data protection and privacy by design and by default

Overview

SIST EN 17529:2022 - Data protection and privacy by design and by default is the European standard that specifies requirements for implementing Data Protection by Design and by Default (DPbDD) early in the lifecycle of products and services. Approved by CEN, this standard is intended for manufacturers, suppliers and service providers across all sectors (including the security industry) to make their offerings “privacy‑ready” before specific system integration or deployment. It aligns DPbDD considerations with product development processes and supports compliance with GDPR Article 25 where applicable.

Key topics and technical requirements

The standard provides structured, actionable requirements and guidance, including:

• Privacy‑aware development lifecycle: leadership, preparation, design, development, production/service provision, release, performance evaluation and improvement.
• Data protection capability requirements across many domains:
  • Access and copies of data
  • Accountability and record keeping
  • Accuracy and correction
  • Data de‑identification and anonymization
  • Data minimization and storage limitation
  • Data portability
  • Confidentiality, erasure (right to be forgotten) and restriction of processing
  • Consent management and special rules for children
  • Information security (unauthorized processing, data loss, restore)
  • Lawfulness, objection to processing, automated decision‑making, transparency
• Self‑declaration mechanism: a format and process for suppliers to declare the privacy capabilities and levels of achievement of components or services to system integrators.
• Guidance on DPIA interaction: when a Data Protection Impact Assessment (EN ISO/IEC 29134) is required and how DPIA treatment plans relate to product requirements.
• Compatibility with management systems: guidance on mapping DPbDD into quality management frameworks such as EN ISO 9001 (informative Annex C).

Practical applications - who uses this standard

• Component manufacturers and firmware/software developers: design components with documented privacy capabilities that system integrators can rely on.
• Service providers and cloud vendors: pre‑configure services with privacy‑friendly defaults and clearly declare limitations.
• System integrators and OEMs: use supplier self‑declarations to select components that help meet data controller obligations under GDPR.
• Procurement teams and compliance officers: evaluate vendor claims, support DPIAs, and include DPbDD criteria in contracts and specifications.

Related standards and references

• Regulation (EU) 2016/679 (GDPR) - Article 25 relationship is addressed (informative Annex ZA).
• EN ISO/IEC 29134 - DPIA methodology.
• EN ISO 9001 - quality management alignment (Annex C).
• Developed by CEN/CENELEC JTC 13 (Cybersecurity & Data Protection).

Keywords: SIST EN 17529:2022, Data protection by design, Privacy by default, DPbDD, privacy‑aware development, self‑declaration, GDPR compliance, DPIA, EN ISO 9001.

Standards Content (Sample)

SLOVENSKI STANDARD
01-september-2022
Varstvo podatkov in zasebnosti z načrtovanjem in kot privzeto
Data protection and privacy by design and by default
Datenschutz by Design und als Grundeinstellung
Protection des données et de la vie privée dès la conception et par défaut
Ta slovenski standard je istoveten z: EN 17529:2022
ICS:
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 17529
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2022
ICS 35.030
English version
Data protection and privacy by design and by default
Protection des données et de la vie privée dès la Datenschutz by Design und als Grundeinstellung
conception et par défaut
This European Standard was approved by CEN on 5 December 2021.

CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for
giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical
references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to
any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium,
Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Rue de la Science 23, B-1040 Brussels
© 2022 CEN/CENELEC All rights of exploitation in any form and by any means
Ref. No. EN 17529:2022 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms, definitions and abbreviations . 6
3.1 Terms and definitions . 6
3.2 Abbreviated terms . 7
4 General. 7
4.1 Preparing the grounds for data protection and privacy by design and by default . 7
4.2 Structure for disassembling product and service into applicable categories . 8
4.2.1 Introduction . 8
4.2.2 Product perspectives . 9
4.2.3 Service elements . 9
4.3 Self-declaration and levels of achievement . 10
5 Privacy-aware development of products and services . 12
5.1 Leadership and market intelligence . 12
5.2 Preparation . 13
5.3 Design . 13
5.3.1 Determination of DPPbDD requirements . 13
5.3.2 Development . 14
5.3.3 Production and service provision . 15
5.3.4 Release of products and services . 15
5.4 Performance evaluation . 15
5.5 Improvement . 15
6 Data protection capability requirements on the design of products and services . 15
6.1 Access . 15
6.1.1 Access to data . 15
6.1.2 Copy of data . 16
6.2 Accountability . 16
6.3 Accuracy . 17
6.4 Data de-identification . 18
6.5 Data minimization . 19
6.6 Data portability . 20
6.7 Confidentiality . 21
6.8 Erasure. 23
6.9 Consent and Children . 24
6.9.1 Determination of user age . 24
6.9.2 Configurable children age threshold . 24
6.10 Information security . 25
6.10.1 Unauthorized or unlawful processing . 25
6.10.2 Data loss . 28
6.10.3 Information protection targets . 29
6.10.4 Restore . 29
6.11 Lawfulness . 30
6.11.1 Data disclosure . 30
6.11.2 Consent . 30
6.12 Objection to processing . 31
6.13 Automated decision making . 32
6.14 Restriction of processing . 32
6.15 Storage limitation . 33
6.16 Transparency . 34
6.16.1 Information . 34
6.16.2 Record of processing activities . 37
7 Requirements to the self-declaration of privacy-aware design . 38
7.1 Process requirements . 38
7.1.1 Preparation based on the product perspective and service element requirements . 38
7.1.2 Additional considerations related to DPIAs . 38
7.1.3 Determination of the level of achievement . 38
7.2 Self-declaration statement . 39
Annex A (informative) Applicability mapping between Clause 6 requirements and
perspectives or elements . 41
Annex B (informative) Approach for a specification . 53
Annex C (informative) Guidelines related to EN ISO 9001 . 55
Annex ZA (informative) Relationship between this European Standard and the data
protection by design and by default requirements of Regulation EU 2016/679 aimed
to be covered . 60
Bibliography . 62

European foreword
This document (EN 17529:2022) has been prepared by WG 5 “Data Protection, Privacy and Identity
Management” of the CEN/CENELEC JTC 13 “Cybersecurity and Data Protection”, the secretariat of which
is held by DIN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by November 2022, and conflicting national standards shall
be withdrawn at the latest by November 2022.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document has been prepared as part of CEN/CLC JTC 13 work programme, not only as the first
deliverable called by mandate M/530 given to CEN and CENELEC by the European Commission, but also
to be generic enough to be applicable to a variety of domains other than the security industry, which was
in focus of the mandate.
For relationship with EU Regulation(s), see informative Annex ZA, which is an integral part of this
document.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia,
Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland,
Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of North
Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
0.1 General
This document provides the component and subsystems developers with an early formalized process for
identification of privacy objectives and requirements, as well as the necessary guidance on associated
assessment. It further provides support for understanding the cascaded liability and obligation of
manufacturers and service providers (Reference to GDPR and as applicable reference to Article 25, as
well as to rules applicable to governmental applications).
The General Data Protection Regulation, in its Art. Twenty-five charges data controllers, and implicitly
manufacturers, with implementing Data Protection by design and by default.
The aim of this document is to give requirements to manufacturers and/or service providers to
implement Data protection and Privacy by Design and by Default (DPPbDD) early in the development of
their products and services, i.e. before (or independently of) any specific application integration, to make
sure that they are as privacy ready as possible with regard to the anticipated markets.
The quality management system of EN ISO 9001 provides a process framework through which products
and services can incorporate Data protection and privacy by design. Annex C shows how EN ISO 9001 can
be interpreted and extended for use in this domain where necessary. Control objectives and requirements
have been derived from the General Data Protection Regulation, which the component manufacturer or
software sub-systems or sub-service provider may choose to address. These clauses are applicable to the
B2B market, since manufacturers composing these sub-components in larger systems will need to
understand the limits and capabilities of each component, as part of their system design. Finally, a self-
declaration mechanism is specified which can be used by component manufacturers and service
providers as part of their attestation to system integrators of the capabilities, protections and limitations
of that component or service.
For some purposes of processing and for some categories of personal data, a data protection impact
assessment (DPIA) according to EN ISO/IEC 29134 needs to be conducted and in addition to the
requirements given in this document, the treatment plan resulting from the DPIA needs to be fulfilled as
well.
This document is intended to be used by manufacturers, suppliers, hard- and software developers
providing products and services to system integrators who themselves intend to offer products and
services to be used by data controllers and data processors. It allows system integrators to select and
correctly use the offerings of sub-system and component suppliers and manufacturers when developing
systems that may have data protection requirements.
0.2 Compatibility with management system standards
This document applies the framework developed by CEN/CENELEC and ISO to improve alignment among
its Management System Standards. However, this document itself does not represent a Management
System standard.
This document supports an organization to align or integrate its development considerations on data
protection with the requirements of Management System standards.
1 Scope
This document specifies requirements for manufacturers and/or service providers to implement Data
protection and Privacy by Design and by Default (DPPbDD) early in their development of their products
and services, i.e. before (or independently of) any specific application integration, to make sure that they
are as privacy ready as possible. This document is applicable to all business sectors, including the security
industry.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following term and definitions apply.
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1.1
data protection by design
technical and organizational measures designed to implement data protection principles
Note 1 to entry: The measures shall be implemented in an effective manner and to integrate the necessary
safeguards into the processing.
3.1.2
data protection by default
technical and organizational measures for ensuring that only personal data which are necessary for each
specific purpose of the processing are processed
Note 1 to entry: Such measures should cover at least the amount of personal data collected, the extent of their
processing, the period of their storage and their accessibility.
3.1.3
data protection impact assessment
DPIA
overall process of identifying, analysing, evaluating, consulting, communicating and planning the
treatment of potential privacy impacts with regard to the processing of personal data, framed within an
organization’s broader risk management framework
Note 1 to entry: Adapted from ISO/IEC 29134:2017, 3.7.
3.1.4
privacy-aware
attribute of a product or service for the processing of personal data, meaning that data protection
requirements were considered in the design and pre-configuration and that privacy adverse functional
requirements were only made as far as necessary for the intended purpose of the product or service
3.1.5
special categories of personal data
data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union
membership, genetic data, biometric data for the purpose of uniquely identifying a natural person, data
concerning health or data concerning a natural person's sex life or sexual orientation
[SOURCE: GDPR Article 9, Clause 1]
3.2 Abbreviated terms
DPPbDD Data protection and Privacy by Design and by Default
DPIA Data protection impact assessment
GDPR EU General Data Protection Regulation 679/2016
GSMA Global system of mobile communication association
ISACA Information Systems Audit and Control Association
LoA Level of Achievement
4 General
4.1 Preparing the grounds for data protection and privacy by design and by default
Alongside the broadly formulated expectations in terms of protecting personal data during data
processing procedures, data protection and privacy by design and by default relate to the ability of the
intended technical systems and components to be able to support this protection. Reference is made to
consideration reason 78, sentence 4 for adopting of the GDPR. Yet, manufacturers do not have an
obligation under the GDPR. Other instruments are therefore required to guide them in a process through
which their products or services are designed to be data protection and privacy by design and default
friendly for a maximum of use cases, as per the anticipated market. An underlying set of requirements
consistent with the company’s quality process is detailed hereafter. Anticipated benefits are for the end-
users (customers/data controllers) ease to implement their privacy duties and for the manufacturer a
competitive edge.
The GDPR contains many legal provisions for consideration by data controllers and processors; such
provisions rely largely on the diverse functional and operational conditions in which it is anticipated that
the product or service will be used. In this context and to support the providers of products and services
in their assessment, the obligations of data controllers were generically analysed to determine whether
they contain, explicitly or implicitly, the need for functional capabilities in support of data controllers’
obligations.
The following principles are expected for data protection and privacy by design and by default:
1) DPPbDD should be proactive and preventative, not reactive and remedial.
2) Default settings and configuration should be secure and privacy-aware.
3) Data protection and privacy should be incorporated into design.
4) DPPbDD seeks full functionality in accommodation of legitimate interests and objectives, no trade-
offs.
5) DPPbDD should concern the entire data lifecycle.
6) DPPbDD should be visible and transparent and subject to independent verification.
7) The interests of the individual should be kept uppermost by offering strong defaults, appropriate
notice and be kept user-centric by offering user-friendly options, even if such provisions appear as
less privacy-friendly.
8) DPPbDD controls should be effective.
9) DPPbDD measures should be designed to be robust and be able to scale up in accordance with
increases in risk of breach of the data protection principles.
10) DPPdDD measures should be regularly assessed.
When understanding data protection by design in the utmost possible way, consideration needs to be
given not only to the moment of supplying and providing. The whole lifecycle of both, the personal data
and the product and/or service needs to be considered as well.
Special attention should be drawn to maintenance activities as well as to the general conditions, under
which a reuse of products could happen. Furthermore, the service includes the operation of processing
as a processor on data controllers behalf. Some requirements of this document will draw attention to this
scenarios.
If the service provider needs to be seen as a data controller, additional organizational and technical
measures should be put into place and be governed by an appropriated Management system, e.g.
EN ISO/IEC 27701. These organizational and technical measures will be out of scope for this document.
This document provides in 4.2 a structure for splitting up integrated products and services into layers,
which may be used to modulate them into building blocks that need to fulfil the same set of requirements.
Any reasonable approach may be taken to describing the system architecture, provided it allows a
mapping of the data protection concerns onto the architecture. When designing a major component from
sub-systems and services, it may be necessary for the overarching system architecture decomposition to
leverage the descriptions of the included components. Such approaches may draw on opaque or
transparent models for the component elements. In 4.3 the conformity scheme for a self-declaration is
provided.
In Clause 5, the requirements for an exemplar process of privacy-aware development of products and
services are provided.
In Clause 6, there are basic requirements on the design of products and services provided. Application is
specified to the respective product perspectives and service elements specified in 4.2 and control
objectives give reference to the GDPR.
Clause 7 provides guidelines to the process of self-declaration and the requirements to determine the
level of achievement.
In the Annexes A, B and C, detailed information is given on the mapping of basic requirements to product
perspectives or service elements on the definition of privacy by design and on guidance for applying
EN ISO 9001 as a management system to the development. Additionally, the Annex ZA contains the
conformity statement for EU Mandate M/530.
4.2 Structure for disassembling product and service into applicable categories
4.2.1 Introduction
As it does not seem practical to build requirements directly for products and for services, that can highly
differ in submodule assembly, architecture and bundling, a set of module categories is specified in the
next two clauses. Any complex product or service under this document can be decomposed into
component parts or layers. These can be used to represent products and services. The structural
decomposition is divided into product and service issues for ease of description.
4.2.2 Product perspectives
The module categories, of which a product can consist, are specified as follows:
1) Component perspective — mainly physical submodules like microprocessors and microcontrollers,
DRAM-Modules, Interface controllers, media drives, physical storage media, sensors, actuators or
power supply. This perspective can include connectivity drivers and small programs as e.g. for
upgrading or dynamic connection.
2) Device perspective — bare bone with chassis, shielding, display, keyboards and casing. The device
perspective integrates components from the component perspective and is adding programs for
BIOS and boot capabilities.
3) Operating system perspective — software perspective with programs supporting the configuration
of the device, the basic interaction with the user, like keyboard input and output via display or
printer, the support of user authentication, the administration of the device itself and its
interconnectivity with networks and with tools supporting local activities on the device.
4) Communication perspective — Connectivity components emulating physical links (wired or
wireless) for the purpose of information transmission. This perspective is similar to the component
perspective, but differs regarding specific concerns related with the aspect of the network it builds.
5) Storage perspective — logical perspective for the management of storage locations on connected
physical storage media via the component perspective. This includes locally or remotely connected
media, raid or cluster architectures, NAS or SAN concepts as well as fileservers and cloud storage.
6) User Interface perspective — logical perspective for the management of user interaction with a
device or service, which is not on Operating system perspective. This perspective also includes
portals and, up to a certain degree, content management systems.
7) Integrated system perspective — this perspective applies, when a product is an integration of more
than one device. It requires a communication model between the devices with specified protocols
and transmission management. Integrated systems are expected to demonstrate the capabilities and
default settings for an appropriate network security.
8) Application perspective — software perspective providing the expected functionality of a device or
an integrated system.
9) Business process perspective — logical perspective above the application perspective that is
managing information exchange between many devices, integrated systems or even organizations.
10) System management perspective — logical perspective for the management of Operation and
information security regarding the devices, integrated systems, applications, Storages and/or
communication flows.
4.2.3 Service elements
The module categories, of which a service can consist, are specified as follows:
1) Service management element — human based service of configuration, operation control and
incident response.
2) Self-service element — application service to provide the customer or the user with tools to configure
other product or service elements.
3) Integration service element — customer specific service of making subsystems interoperable,
normally organized within a dedicated project under a customer specified management framework.
4) Transmission service element — service that interconnects transmission lines via organizational
boarders.
5) Update service element — Program code updates, these may be provided, for example, proactively
by humans, reactively through an automated system, or published for downloading.
6) Cloud service element — service providing operation facilities either on infrastructure level,
platform level or on application level.
7) Content service element — service providing additional data (e.g.: news, scoring figures, addresses),
sometimes with the possibility to enhance collected personal data.
8) Outsourced business process element — functional data processing either customer specific or as a
normalized offer to similar clients.
9) Output service element — services receiving customer data for the purpose of producing output
media (e.g.: photo calendars or marketing mails).
10) Maintenance service element — service reacting on demand of users and/or customers in order to
keep products and services usable over lifetime, including collect or bring-in services and device
swaps.
11) Security as a service element —services evaluating systems, traffic and log entries in order to detect,
prevent or react on vulnerabilities and security breaches.
12) Media recovery services element — service on customer owned physical storage media for the
purpose of recovering the information contained in them.
13) Media destruction service element — physical destruction of storage media in a way that is unable
for recovery of data, normally applied at the end of lifecycle.
14) System remarketing service element — service on products by cleaning, reconstruction and re-
licensing in order to give the product a second life with another customer.
4.3 Self-declaration and levels of achievement
Although the consideration of data protection and privacy by design within an organization’s quality
management system could be seen as a prerequisite to deliver DPPbDD, it would not be sufficient to
conform with the respective processes in order to build privacy-aware products and services. It is also
indispensable for the product or service to conform with the specific requirements applicable to any of
the perspectives the product or elements the service is built of in order to fulfil the data protection and
privacy by design and by default principles.
In practice, it would be reasonable sometimes to find a trade-off between market needs or customer
expressed requirements and the principles and requirements. This will lower the level of safeguarding
for the data subject but will not result in a product or service that is privacy-unaware. As another example,
an organization could plan to provide a product or service for the processing of special categories of data
under lawful circumstances, and it applies additional measures or functions retrieved from a data
protection impact assessment. One state of being privacy-aware will not reflect the enhanced level of
safeguarding needed and demonstrated by additional effort.
Suppliers of sub-components, and providers of services to system integrators, may wish to address
specific data protection needs, while ignoring others. For example, a data storage component might
provide guarantees w.r.t the completeness and timeliness of deletion but be intended only to hold
encrypted data with no on-device decryption. As such, this device could not allow for correction of
personal data, since it would be holding blocks of bits – a higher level privacy-aware service would need
to replace the stored content. The self-declaration mechanism allows a component manufacturer to
identify those facets of data protection that are the market focus for their product.”
In order to reflect the potential for incomplete addressing of data protection concerns, the practise of
trade-offs and the need for adequacy in special processing conditions, six levels of achievement have been
specified in Table 1 below.
Table 1 — Definitions of achievement levels
Sub-level Level of
Achievement Prerequisites
achievement achievement
The requirements are
fully applied. No trade-offs
Special categories of
were made. Special Data protection impact
personal data
categories of personal assessment was conducted and
protection and privacy A
data are about to be appropriate design concerns were
are considered by
processed and additional applied.
design and by default.
design concerns were
made accordingly.
The requirements are Data protection and The requirements are fully
fully applied. No trade-offs privacy are considered applied. No trade-offs were made.
B
were made. Purpose fits to by design and by Uppermost consideration of data
protection level. default. subject interests is confirmed.
Sub-level Level of
Achievement Prerequisites
achievement achievement
The design is privacy- Requirement fulfilment rate is
C
aware 95 % ≤ x < 100 %
Trade-offs were made The design is mostly Requirement fulfilment rate is
D
when applying the privacy-aware 80 % ≤ x < 95 %
requirements
Considerations to a
Requirement fulfilment rate is
privacy-aware design E
50 % ≤ x < 80 %
were made in general
The application of requirements is Requirement fulfilment rate is
Z
underperforming lower than 50 %
Achievements need to be demonstrated by conformance to the selected data protection capability
requirements in Clause 6 and their mapping onto an architectural model of the component, service or
sub-system. One approach to this is demonstrated using the example of product perspectives and/or
service elements throughout this document. An equivalent mapping of data protection requirements to
architectural components could be used to develop an equivalent system for sub-systems that are
composed from multiple parts, or from base level components for which a non-layered (e.g. service-
oriented architecture) approach is prefered. In case of some particular processing likely to result in a high
risk to the rights and freedoms of the data subjects, a data protection impact assessment (DPIA) shall be
conducted and the outcome shall be considered within the design as well. This DPIA shall be conducted
and recorded. An example of a DPIA is provided by EN ISO/IEC 29134.
Component suppliers and sub-system service providers will be permitted to label their product or service
by self-declaration as privacy-aware together with the level of achievement, to inform potential system
integrators, as long as they are able to demonstrate conformance to the requirements as provided in
Clause 7.
Where a component or sub-system or service is offered to system integrators with a self-declaration at
achievement level C, D, E or Z, there should be accompanying documentation to assist the system
integrator in understanding which data protection controls are, and are not, offered by this component.
This document focuses on B2B activity, supporting the component and subsystems developers in
addressing specific data protection issues. Products and services achieving level A or B should satisfy all
of the requirements laid out in Clause 6. However, those requirements do not represent all of the data
protection baseline embodied by the GDPR in full detail. It should not therefore, be assumed that a level
A or B self-declaration represents full satisfaction of the GDPR requirements. Further analysis would be
needed, based on the actual product, before such an assessment could be justified.
5 Privacy-aware development of products and services
5.1 Leadership and market intelligence
5.1.1 The organization shall establish and maintain an understanding that data protection and privacy
by design and by default are an imperative to the development and provision of any of its products and
services that may potentially have privacy implications.
NOTE This means that data protection and privacy by design and by default is reflected in the senior
management commitment, expressed in written policies and the respective responsibilities and accountability is
allocated to the appropriate organizational roles.
5.1.2 To ensure a proper match between the variety of use cases implied by the targeted market and
their implication in the activation of the GDPR provisions, the organization shall select, train and fully
inform staff in charge of the process below on the GDPR, ensuring they have a comprehensive view of all
the usage conditions relative to the different segments covered by the marketing plans.
NOTE This comprehensive functional view applies to all the process described in present Clause 5, keeping in
mind that the privacy analysis relative to the specific procurement of a product or a system is outside the scope of
this document.
5.2 Preparation
5.2.1 The organization shall determine if the product and/or service to be provided includes an active
role in the processing of personal data.
NOTE An active role is to be considered, if the personal data are processed on products or services where the
customer and/or user does not have the full and only control of collecting, storing, sharing and deletion of this
personal data.
5.2.2 In order to address the impact of products and services on the privacy of a data subject, the
organization shall specify an appropriate methodology and the structure of the impact assessment report.
NOTE EN ISO/IEC 29134 provides guidance on the privacy impact assessment
5.2.3 The organization shall provide the development units with access to sufficient human resources
of the appropriate competence in legal and technical expertise in the field of privacy.
NOTE If there is appointed one for the organization, the data protection officer is expected to get involved in
the design process. It is to be ensured that no conflicts of interest arise. Another option could be to have a dedicated
privacy engineer role in the development unit.
5.2.4 The organization shall assess, and where necessary amend, its existing development process for
the fit to the requirements of this document.
5.3 Design
5.3.1 Determination of DPPbDD requirements
5.3.1.1 Basic design requirements
5.3.1.1.1 The person responsible for the product and/or service design shall logically disassemble the
intended market offer into the perspectives and elements it is composed of.
NOTE The perspectives and elements are specified in Clause 4.2.
5.3.1.1.2 For each perspective and element identified as being part of the intended market offer, all the
basic requirements from Clause 6 applying to this perspective or element shall be identified.
NOTE Annex A, Tables A.1 and A.2 provides mapping tables for the applicable basic requirements to a specific
product perspective or service element.
5.3.1.2 Enhanced design requirements when processing of personal data are included
5.3.1.2.1 In case the organization has confirmed to take an active role in the processing of personal
data for the intended market offer, the person responsible for the product and/or service design shall
consider implementing appropriate technical and organizational measures.
NOTE 1 EN ISO/IEC 27701 provides respective requirements and guidelines.
NOTE 2 If there is one, the data protection officer of the organization needs to get informed and consulted for
the appropriate measures to implement on the processing.
NOTE 3 Reference is made to GDPR Article 32.
5.3.1.3 Impact driven design requirements
5.3.1.3.1 The person responsible for the product and/or service design shall determine if the data
collected, processed and/or transmitted include so called “special categories of personal data” as defined
in GDPR Article 9, or personal data relating to criminal convictions and offences, or involves high risk
data processing.
NOTE Reference is made to GDPR Articles 9 and 10.
5.3.1.3.2 In case of the event that high risk or special categories of personal data are confirmed, the
person responsible for the product and/or service design shall conduct a data protection impact
assessment (DPIA) in accordance to the provisions made in 5.2.2.
NOTE Reference is made to GDPR Article 35. There could be further cases when a DPIA needs to be conducted
as well.
5.3.1.3.3 If the DPIA comes to the conclusion that additional requirements shall be raised against the
design and the default setting of the product and/or service, the person responsible for the product
and/or service design shall ensure that these requirements will be considered under the development as
well.
5.3.1.4 Specific branches or consumer related design requirements
5.3.1.4.1 If a product and/or service is intended to be provided to specific categories of data subjects,
the person responsible for the product and/or service design shall determine if there are specific
expectations for the privacy-aware design and default configuration.
5.3.1.4.2 Any of these expectations shall be covered by either an existing or a new requirement to the
design and the default setting of the product and/or service. The person responsible for the product
and/or service design shall ensure that these requirements will be considered under the development as
well.
NOTE In a certain branch, use case or environment, customer and/or consumer expectation of the privacy-
aware design and default could be far more detailed than the legal expectation from GDPR.
5.3.2 Development
5.3.2.1 The person responsible for the product and/or service development shall ensure that all the
design requirements identified 5.3.1 will be considered in the development phase of the product or
service.
5.3.2.2 The person responsible for the product and/or service development shall ensure that best
effort is made to implement adequate functions, measures and controls in the respective product and/or
service in order to fulfil the requirements mentioned in 5.3.2.1.
5.3.2.3 The person responsible for the product and/or service development shall oversee the
definition of appropriately privacy-respectful default settings for any configurable function coming with
the product and/or service under development.
NOTE As a guiding principle, data minimization is to be considered amongst others.
5.3.2.4 The person responsible for the product and/or service development shall ensure that the
default settings of the product and/or service are equal to the ones specified in 5.3.2.3.
5.3.3 Production and service provision
5.3.3.1 The organization shall conduct appropriate testing and
...