(EN) Example of lawful processing:

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, can be able to retrieve data from public authorities about the customer. This may be, for example, tax data from the tax administration.

Initially, this personal data is necessary in order to take steps at the request of the data subject prior to entering into a contract. However, this specific way of processing the personal data is not necessary for entering into a contract, because a loan may be granted without obtaining data directly from public authorities. The customer is able to enter into a contract by providing the information from the tax administration herself.

When implementing the principle of lawfulness, the controller realizes that 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 must rely on consent.

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.

The controller has assessed these Data protection by design and default (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.

Source: EDPB, Guidelines 4/2019 on Article 25 – Data Protection by Design and by Default (Version for public consultation) (2019).

(EN) Example of transparency measures:

A controller is designing a privacy policy in order to comply with the requirements of transparency. The privacy policy cannot contain a lengthy bulk of information that is difficult for the average data subject to penetrate and understand, it must 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 multi-layered manner, where the most important points are highlighted. Drop-down menus and links to other pages are provided to further explain the concepts 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 information.

The privacy policy cannot be difficult for data subjects to access. The privacy policy is thus made available and visible on all internal 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 must also be provided in the right context, at the appropriate time. This means, that generally a 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.

Source: EDPB, Guidelines 4/2019 on Article 25 – Data Protection by Design and by Default (Version for public consultation) (2019).

(EN) Examples of fairness considerations:

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 extensive collection and use of their personal data.

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. The default options for the processing must be the least invasive, and the choice for further processing must be presented in a manner that does not deter the data subject from abstaining.

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. With regard to the fairness principle, the prioritized customer service granted to premium subscribers cannot discriminate other data subjects’ 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.

Prioritized customers may pay to get better service, but all data subjects shall have equal and indiscriminate access to enforce their rights and freedoms according to the GDPR.

Source: EDPB, Guidelines 4/2019 on Article 25 – Data Protection by Design and by Default (Version for public consultation) (2019).

(EN) ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII controllers.

Here is the relevant paragraph to article 5(1)(a) GDPR:

7.2.2 Identify lawful basis

Control

The organization should determine, document and comply with the relevant lawful basis for the processing of PII for the identified purposes.

Implementation guidance

Some jurisdictions require the organization to be able to demonstrate that the lawfulness of processing was duly established before the processing.

The legal basis for the processing of PII can include:

— consent from PII principals;

— performance of a contract;

— compliance with a legal obligation;

— protection of the vital interests of PII principals;

— performance of a task carried out in the public interest;

— legitimate interests of the PII controller.

The organization should document this basis for each PII processing activity (see 7.2.8).

The legitimate interests of the organization can include, for instance, information security objectives, which should be balanced against the obligations to PII principals with regards to privacy protection.

Whenever special categories of PII are defined, either by the nature of the PII (e.g. health information) or by the PII principals concerned (e.g. PII relating to children) the organization should include those categories of PII in its classification schemes.

The classification of PII that falls into these categories can vary from one jurisdiction to another and can vary between different regulatory regimes that apply to different kinds of business, so the organization needs to be aware of the classification(s) that apply to the PII processing being performed.

The use of special categories of PII can also be subject to more stringent controls.
Changing or extending the purposes for the processing of PII can require updating and/or revision of the legal basis. It can also require additional consent to be obtained from the PII principal.

ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII processors.

Here is the relevant paragraph to article 5(1)(a) GDPR:

8.2.2 Organization’s purposes

Control

The organization should ensure that PII processed on behalf of a customer are only processed for the purposes expressed in the documented instructions of the customer.

Implementation guidance

The contract between the organization and the customer should include, but not be limited to, the objective and time frame to be achieved by the service.

In order to achieve the customer’s purpose, there can be technical reasons why it is appropriate for the organization to determine the method for processing PII, consistent with the general instructions of the customer but without the customer’s express instruction. For example, in order to efficiently utilize network or processing capacity it can be necessary to allocate specific processing resources depending on certain characteristics of the PII principal.

The organization should allow the customer to verify their compliance with the purpose specification and limitation principles. This also ensures that no PII is processed by the organization or any of its subcontractors for other purposes than those expressed in the documented instructions of the customer.

(EN) Examples of purpose limitation

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.

The controller is considering buying a Customer Relationship Management (CRM) product that gathers all the customer data such as 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. Ultimately the CRM automatically analyses the customers’ purchasing power by using public information. The purpose of the analysis is to target the advertising better but is not a 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 using personal data with the purposes relevant for the controller. Another requirement is that the product shall be able to flag which kind of processing activities using personal data that is not in line with the legitimate purposes of the controller.

After receiving the results of the mapping, the controller assesses whether the new marketing purpose and the targeted advertisement purpose are within the contractual purposes or if they need another legal ground for this processing. Alternatively the controller could choose to not make use of this functionality in the product.

Source: EDPB, Guidelines 4/2019 on Article 25 – Data Protection by Design and by Default (Version for public consultation) (2019).

(EN) ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII controllers.

Here is the relevant paragraphs to article 5(1)(b) GDPR:

7.2.1 Identify and document purpose

Control

The organization should identify and document the specific purposes for which the PII will be processed.

Implementation guidance

The organization should ensure that PII principals understand the purpose for which their PII is processed. It is the responsibility of the organization to clearly document and communicate this to PII principals. Without a clear statement of the purpose for processing, consent and choice cannot be adequately given.

Documentation of the purpose(s) for processing PII should be sufficiently clear and detailed to be usable in the required information to be provided to PII principals (see 7.3.2). This includes information necessary to obtain consent (see 7.2.3), as well as records of policies and procedures (see 7.2.8).

7.4.1 Limit collection

Control

The organization should limit the collection of PII to the minimum that is relevant, proportional and necessary for the identified purposes.

Implementation guidance

The organization should limit the collection of PII to what is adequate, relevant and necessary in relation to the identified purposes. This includes limiting the amount of PII that the organization collects indirectly (e.g. through web logs, system logs, etc.).

Privacy by default implies that, where any optionality in the collection and processing of PII exists, each option should be disabled by default and only enabled by explicit choice of the PII principal.

ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII processors.

Here is the relevant paragraph to article 5(1)(b) GDPR:

8.2.2 Organization’s purposes

Control

The organization should ensure that PII processed on behalf of a customer are only processed for the purposes expressed in the documented instructions of the customer.

Implementation guidance

The contract between the organization and the customer should include, but not be limited to, the objective and time frame to be achieved by the service.

In order to achieve the customer’s purpose, there can be technical reasons why it is appropriate for the organization to determine the method for processing PII, consistent with the general instructions of the customer but without the customer’s express instruction. For example, in order to efficiently utilize network or processing capacity it can be necessary to allocate specific processing resources depending on certain characteristics of the PII principal.

The organization should allow the customer to verify their compliance with the purpose specification and limitation principles. This also ensures that no PII is processed by the organization or any of its subcontractors for other purposes than those expressed in the documented instructions of the customer.

(EN) Examples of data minimisation

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 prevent that customers don’t fill out all the necessary information the bookshop owner makes all of the fields in the form a required field (if you don’t fill out all the fields the customer can’t place the order) using a standard contact form. The webshop owner initially uses a standard contact form, which asks the customer’s date of birth, phone number and home address. However, not all the fields in the form are strictly necessary for the purpose of buying and delivering the books. 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. Moreover, there are situations where an address will not be necessary. For example, when ordering an eBook the customer can download the product and his or her address does not need to be processed by the webshop.

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.

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 must 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 based on 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.

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

Source: EDPB, Guidelines 4/2019 on Article 25 – Data Protection by Design and by Default (Version for public consultation) (2019).

(EN) ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII controllers.

Here is the relevant paragraphs to article 5(1)(c) GDPR:

7.4.1 Limit collection

Control

The organization should limit the collection of PII to the minimum that is relevant, proportional and necessary for the identified purposes.

Implementation guidance

The organization should limit the collection of PII to what is adequate, relevant and necessary in relation to the identified purposes. This includes limiting the amount of PII that the organization collects indirectly (e.g. through web logs, system logs, etc.).

Privacy by default implies that, where any optionality in the collection and processing of PII exists, each option should be disabled by default and only enabled by explicit choice of the PII principal.

7.4.4 PII minimization objectives

Control

The organization should define and document data minimization objectives and what mechanisms (such as de-identification) are used to meet those objectives.

Implementation guidance

Organizations should identify how the specific PII and amount of PII collected and processed is limited relative to the identified purposes. This can include the use of de-identification or other data minimization techniques.

The identified purpose (see 7.2.1) can require the processing of PII that has not been de-identified, in which case the organization should be able to describe such processing.

In other cases, the identified purpose does not require the processing of the original PII, and the processing of PII which has been de-identified can suffice to achieve the identified purpose. In these cases, the organization should define and document the extent to which the PII needs to be associated with the PII principal, as well as the mechanisms and techniques designed to process PII, such that the de-identification and/or PII minimization objectives are achieved.

Mechanisms used to minimize PII vary depending on the type of processing and the systems used for the processing. The organization should document any mechanisms (technical system configurations, etc.) used to implement data minimization.

In cases where processing of de-identified data is sufficient for the purposes, the organization should document any mechanisms (technical system configurations, etc.) designed to implement de-identification objectives set by the organization in a timely manner. For instance, the removal of attributes associated with PII principals can be sufficient to allow the organization to achieve its identified purpose. In other cases, other de-identification techniques, such as generalization (e.g. rounding) or randomization techniques (e.g. noise addition) can be used to achieve an adequate level of de-identification.
NOTE 1 For further information on de-identification techniques, refer to ISO/IEC 20889.

NOTE 2 For Cloud computing, ISO/IEC 19944 provides a definition of data identification qualifiers that can be used to classify the degree to which the data can identify a PII principal or associate a PII principal with a set of characteristics in the PII.

7.4.4 PII minimization objectives

Control

The organization should define and document data minimization objectives and what mechanisms (such as de-identification) are used to meet those objectives.

Implementation guidance

Organizations should identify how the specific PII and amount of PII collected and processed is limited relative to the identified purposes. This can include the use of de-identification or other data minimization techniques.

The identified purpose (see 7.2.1) can require the processing of PII that has not been de-identified, in which case the organization should be able to describe such processing.

In other cases, the identified purpose does not require the processing of the original PII, and the processing of PII which has been de-identified can suffice to achieve the identified purpose. In these cases, the organization should define and document the extent to which the PII needs to be associated with the PII principal, as well as the mechanisms and techniques designed to process PII, such that the de-identification and/or PII minimization objectives are achieved.

Mechanisms used to minimize PII vary depending on the type of processing and the systems used for the processing. The organization should document any mechanisms (technical system configurations, etc.) used to implement data minimization.

In cases where processing of de-identified data is sufficient for the purposes, the organization should document any mechanisms (technical system configurations, etc.) designed to implement de-identification objectives set by the organization in a timely manner. For instance, the removal of attributes associated with PII principals can be sufficient to allow the organization to achieve its identified purpose. In other cases, other de-identification techniques, such as generalization (e.g. rounding) or randomization techniques (e.g. noise addition) can be used to achieve an adequate level of de-identification.
NOTE 1 For further information on de-identification techniques, refer to ISO/IEC 20889.

NOTE 2 For Cloud computing, ISO/IEC 19944 provides a definition of data identification qualifiers that can be used to classify the degree to which the data can identify a PII principal or associate a PII principal with a set of characteristics in the PII.

7.4.5 PII de-identification and deletion at the end of processing

Control

The organization should either delete PII or render it in a form which does not permit identification or re-identification of PII principals, as soon as the original PII is no longer necessary for the identified purpose(s).

Implementation guidance

The organization should have mechanisms to erase the PII when no further processing is anticipated. Alternatively, some de-identification techniques can be used as long as the resulting de-identified data cannot reasonably permit re-identification of PII principals.

7.4.6 Temporary files

Control

The organization should ensure that temporary files created as a result of the processing of PII are disposed of (e.g. erased or destroyed) following documented procedures within a specified, documented period.

Implementation guidance

The organization should perform periodic checks that unused temporary files are deleted within the identified time period.

Other information

Information systems can create temporary files in the normal course of their operation. Such files are specific to the system or application, but can include file system roll-back journals and temporary files associated with the updating of databases and the operation of other application software. Temporary files are not needed after the related information processing task has completed but there are circumstances in which they cannot be deleted. The length of time for which these files remain in use is not always deterministic but a “garbage collection” procedure should identify the relevant files and determine how long it has been since they were last used.

ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII processors.

Here is the relevant paragraph to article 5(1)(c) GDPR:

8.4.1 Temporary files

Control

The organization should ensure that temporary files created as a result of the processing of PII are disposed of (e.g. erased or destroyed) following documented procedures within a specified, documented period.

Implementation guidance

The organization should conduct periodic verification that unused temporary files are deleted within the identified time period.

Other information

Information systems can create temporary files in the normal course of their operation. Such files are specific to the system or application, but can include file system roll-back journals and temporary files associated with the updating of databases and the operation of other application software. Temporary files are not needed after the related information processing task has completed but there are circumstances in which they cannot be deleted. The length of time for which these files remain in use is not always deterministic but a “garbage collection” procedure should identify the relevant files and determine how long it has been since they were last used.

(EN) Examples of the measures ensuring data accuracy

Example 1

A bank wishes to use artificial intelligence (AI) to profile customers applying for bank loans as a basis for their decision making. When determining how their AI solutions should be developed, they are determining the means of processing and must consider data protection by design when choosing an AI from a vendor and when deciding on how to train the AI.

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

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

Customer data is gathered from their own systems, gathering data about the existing loan customers’ payment history, bank transactions, credit card debt, they conduct new credit checks, and they gather data from public registries that they have legal access to use.

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.

Finally, the bank tests whether the AI is reliable and provides non-discriminatory results. When the AI is fully trained and operative, the bank uses the results as a part of the loan assessments, and will never rely solely on the AI to decide whether to grant loans.

The bank will also review the reliability of the results from the AI at regular intervals.

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 separate 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 need 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 another.

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 hash signatures are created for treatment journal records and the employee associated with them so that any changes can be recognized, correlated and traced if required.

Source: EDPB, Guidelines 4/2019 on Article 25 – Data Protection by Design and by Default (Version for public consultation) (2019).

(EN) ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII controllers.

Here is the relevant paragraphs to article 5(1)(d) GDPR:

7.3.6 Access, correction and/or erasure

Control

The organization should implement policies, procedures and/or mechanisms to meet their obligations to PII principals to access, correct and/or erase their PII.

Implementation guidance

The organization should implement policies, procedures and/or mechanisms for enabling PII principals to obtain access to, correct and erase of their PII, if requested and without undue delay.

The organization should define a response time and requests should be handled according to it.

Any corrections or erasures should be disseminated through the system and/or to authorized users, and should be passed to third parties (see 7.3.7) to whom the PII has been transferred.

NOTE Records generated by the control specified in 7.5.3 can help in this regard.
The organization should implement policies, procedures and/or mechanisms for use when there can be a dispute about the accuracy or correction of the data by the PII principal. These policies, procedures and/or mechanisms should include informing the PII principal of what changes were made, and of reasons why corrections cannot be made (where this is the case).

Some jurisdictions impose restrictions on when and how a PII principal can request correction or erasure of their PII. The organization should determine these restrictions as applicable and keep itself up-to-date about them.

7.4.3 Accuracy and quality

Control

The organization should ensure and document that PII is as accurate, complete and up-to-date as is necessary for the purposes for which it is processed, throughout the life-cycle of the PII.

Implementation guidance

The organization should implement policies, procedures and/or mechanisms to minimize inaccuracies in the PII it processes. There should also be policies, procedures and/or mechanisms to respond to instances of inaccurate PII. These policies, procedures and/or mechanisms should be included in the documented information (e.g. through technical system configurations, etc.) and should apply throughout the PII lifecycle.

Additional information

For further information on the PII processing life-cycle, see ISO/IEC 29101:2018, 6.2.

(EN) Example of storage limitation

The controller collects personal data where the purpose of the processing is to administer a membership with the data subject, the personal data shall be deleted when the membership is terminated.

The controller makes an internal procedure for data retention and deletion. According to this, employees must 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, the controller instead implements an automatic system to delete data automatically 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 policy regularly.

Source: EDPB, Guidelines 4/2019 on Article 25 – Data Protection by Design and by Default (Version for public consultation) (2019).

(EN) ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII controllers.

Here is the relevant paragraphs to article 5(1)(e) GDPR:

7.4.4 PII minimization objectives

Control

The organization should define and document data minimization objectives and what mechanisms (such as de-identification) are used to meet those objectives.

Implementation guidance

Organizations should identify how the specific PII and amount of PII collected and processed is limited relative to the identified purposes. This can include the use of de-identification or other data minimization techniques.

The identified purpose (see 7.2.1) can require the processing of PII that has not been de-identified, in which case the organization should be able to describe such processing.

In other cases, the identified purpose does not require the processing of the original PII, and the processing of PII which has been de-identified can suffice to achieve the identified purpose. In these cases, the organization should define and document the extent to which the PII needs to be associated with the PII principal, as well as the mechanisms and techniques designed to process PII, such that the de-identification and/or PII minimization objectives are achieved.

Mechanisms used to minimize PII vary depending on the type of processing and the systems used for the processing. The organization should document any mechanisms (technical system configurations, etc.) used to implement data minimization.

In cases where processing of de-identified data is sufficient for the purposes, the organization should document any mechanisms (technical system configurations, etc.) designed to implement de-identification objectives set by the organization in a timely manner. For instance, the removal of attributes associated with PII principals can be sufficient to allow the organization to achieve its identified purpose. In other cases, other de-identification techniques, such as generalization (e.g. rounding) or randomization techniques (e.g. noise addition) can be used to achieve an adequate level of de-identification.
NOTE 1 For further information on de-identification techniques, refer to ISO/IEC 20889.

NOTE 2 For Cloud computing, ISO/IEC 19944 provides a definition of data identification qualifiers that can be used to classify the degree to which the data can identify a PII principal or associate a PII principal with a set of characteristics in the PII.

7.4.5 PII de-identification and deletion at the end of processing

Control

The organization should either delete PII or render it in a form which does not permit identification or re-identification of PII principals, as soon as the original PII is no longer necessary for the identified purpose(s).

Implementation guidance

The organization should have mechanisms to erase the PII when no further processing is anticipated. Alternatively, some de-identification techniques can be used as long as the resulting de-identified data cannot reasonably permit re-identification of PII principals.

(EN) Example of integrity and confidentiality measures

A controller wants to extract personal data from a medical database to a server in the company. 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. There is only one department in the company who needs to process these patient data. The extracts will also have a high value to the company.

To regulate access and mitigate possible damage from malware, the company decides to segregate the network, and establish access controls to the server and the directory. In addition, they put up security monitoring and an intrusion detection and prevention system. The controller activates access control on the server 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. This security measure will ensure that all users have access on a need to know basis and with the appropriate access level. Inappropriate use can be quickly and easily recognised.

Some of the extracts have to be compared with new extracts, and must therefore be stored for three months. The controller decides to put them into separate directories and encrypt the stored extracts.

Handling the incident makes the system more robust, and reliable, both for the controller and the data subjects. The data controller understands that preventative and effective measures and safeguards should be built into all personal data processing 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 to make the solution robust.

Source: EDPB, Guidelines 4/2019 on Article 25 – Data Protection by Design and by Default (Version for public consultation) (2019).

(EN) ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 6.2.1.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.3.2.1 Mobile device policy

Implementation guidance

The organization should ensure that the use of mobile devices does not lead to a compromise of PII.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 8.2.1.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.5.2.1 Classification of information

Implementation guidance

The organization’s information classification system should explicitly consider PII as part of the scheme it implements. Considering PII within the overall classification system is integral to understanding what PII the organization processes (e.g. type, special categories), where such PII is stored and the systems through which it can flow.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 8.2.2.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.5.2.2 Labelling of information

Implementation guidance

The organization should ensure that people under its control are made aware of the definition of PII and how to recognize information that is PII.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 8.3.1.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.5.3.1 Management of removable media

Implementation guidance

The organization should document any use of removable media and/or devices for the storage of PII. Wherever feasible, the organization should use removable physical media and/or devices that permit encryption when storing PII. Unencrypted media should only be used where unavoidable, and in instances where unencrypted media and/or devices are used, the organization should implement procedures and compensating controls (e.g. tamper-evident packaging) to mitigate risks to the PII.

Other information

Removable media which is taken outside the physical confines of the organization is prone to loss, damage and inappropriate access. Encrypting removable media adds a level of protection for PII which reduces security and privacy risks should the removable media be compromised.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 8.3.2.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.5.3.2 Disposal of media

Implementation guidance

Where removable media on which PII is stored is disposed of, secure disposal procedures should be included in the documented information and implemented to ensure that previously stored PII will not be accessible.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 8.3.3.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.5.3.3 Physical media transfer

Implementation guidance

If physical media is used for information transfer, a system should be put in place to record incoming and outgoing physical media containing PII, including the type of physical media, the authorized sender/ recipients, the date and time, and the number of physical media. Where possible, additional measures such as encryption should be implemented to ensure that the data can only be accessed at the point of destination and not in transit.

The organization should subject physical media containing PII before leaving its premises to an authorization procedure and ensure the PII is not accessible to anyone other than authorized personnel.

NOTE One possible measure to ensure PII on physical media leaving the organization’s premises is not generally accessible is to encrypt the PII concerned and restrict decryption capabilities to authorized personnel.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 9.2.1.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.6.2.1 User registration and de-registration

Implementation guidance

Procedures for registration and de-registration of users who administer or operate systems and services that process PII should address the situation where user access control for those users is compromised, such as the corruption or compromise of passwords or other user registration data (e.g. as a result of inadvertent disclosure).

The organization should not reissue to users any de-activated or expired user IDs for systems and services that process PII.

In the case where the organization is providing PII processing as a service, the customer can be responsible for some or all aspects of user ID management. Such cases should be included in the documented information.

Some jurisdictions impose specific requirements regarding the frequency of checks for unused authentication credentials related to systems that process PII. Organizations operating in these jurisdictions should take compliance with these requirements into account.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 9.2.2.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.6.2.2 User access provisioning

Implementation guidance

The organization should maintain an accurate, up-to-date record of the user profiles created for users who have been authorized access to the information system and the PII contained therein. This profile comprises the set of data about that user, including user ID, necessary to implement the identified technical controls providing authorized access.

Implementing individual user access IDs enables appropriately configured systems to identify who accessed PII and what additions, deletions or changes they made. As well as protecting the organization, users are also protected as they can identify what they have processed and what they have not processed.

In the case where the organization is providing PII processing as a service, the customer can be responsible for some or all aspects of access management. Where appropriate, the organization should provide the customer the means to perform access management, such as by providing administrative rights to manage or terminate access. Such cases should be included in the documented information.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 9.4.2.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.6.4.2 Secure log-on procedures

Implementation guidance

Where required by the customer, the organization should provide the capability for secure log-on procedures for any user accounts under the customer’s control.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 11.2.7.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.8.2.7 Secure disposal or re-use of equipment

Implementation guidance

The organization should ensure that, whenever storage space is re-assigned, any PII previously residing on that storage space is not accessible.

On deletion of PII held in an information system, performance issues can mean that explicit erasure of that PII is impractical. This creates the risk that another user can access the PII. Such risk should be avoided by specific technical measures.

For secure disposal or re-use, equipment containing storage media that can possibly contain PII should be treated as though it does contain PII.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 11.2.9.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.8.2.9 Clear desk and clear screen policy

Implementation guidance

The organization should restrict the creation of hardcopy material including PII to the minimum needed to fulfil the identified processing purpose.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 12.3.1.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.9.3.1 Information backup

Implementation guidance

The organization should have a policy which addresses the requirements for backup, recovery and restoration of PII (which can be part of an overall information backup policy) and any further requirements (e.g. contractual and/or legal requirements) for the erasure of PII contained in information held for backup requirements.

PII-specific responsibilities in this respect can depend on the customer. The organization should ensure that the customer has been informed of the limits of the service regarding backup.

Where the organization explicitly provides backup and restore services to customers, the organization should provide them with clear information about their capabilities with respect to backup and restoration of PII.

Some jurisdictions impose specific requirements regarding the frequency of backups of PII, the frequency of reviews and tests of backup, or regarding the recovery procedures for PII. Organizations operating in these jurisdictions should demonstrate compliance with these requirements.

There can be occasions where PII needs to be restored, perhaps due to a system malfunction, attack or disaster. When PII is restored (typically from backup media), processes need to be in place to ensure that the PII is restored into a state where the integrity of PII can be assured, and/or where PII inaccuracy and/or incompleteness is identified and processes put in place to resolve them (which can involve the PII principal).

The organization should have a procedure for, and a log of, PII restoration efforts. At a minimum, the log of the PII restoration efforts should contain:

— the name of the person responsible for the restoration;

— a description of the restored PII.

Some jurisdictions prescribe the content of the logs of PII restoration efforts. Organizations should be able to document compliance with any applicable jurisdiction-specific requirements for restoration log content. The conclusions of such deliberations should be included in documented information.

The use of subcontractors to store replicated or backup copies of PII processed is covered by the controls in this document applying to subcontracted PII processing (see 6.5.3.3, 6.12.1.2). Where physical media transfers take place related to backups and restoration, this is also covered by controls in this document (6.10.2.1).

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 12.4.1.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.9.4.1 Event logging

Implementation guidance

A process should be put in place to review event logs using continuous, automated monitoring and alerting processes, or else manually where such review should be performed with a specified, documented periodicity, to identify irregularities and propose remediation efforts.

Where possible, event logs should record access to PII, including by whom, when, which PII principal’s PII was accessed, and what (if any) changes were made (additions, modifications or deletions) as a result of the event.

Where multiple service providers are involved in providing services, there can be varied or shared roles in implementing this guidance. These roles should be clearly defined and included in the documented information, and agreement on any log access between providers should be addressed.

Implementation guidance for PII processors:

The organization should define criteria regarding if, when and how log information can be made available to or usable by the customer. These criteria should be made available to the customer.

Where the organization permits its customers to access log records controlled by the organization, the organization should implement appropriate controls to ensure that the customer can only access records that relate to that customer’s activities, cannot access any log records which relate to the activities of other customers, and cannot amend the logs in any way.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 12.4.2.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.9.4.2 Protection of log information

Implementation guidance

Log information recorded for, for example, security monitoring and operational diagnostics, can contain PII. Measures such as controlling access (see ISO/IEC 27002:2013, 9.2.3) should be put in place to ensure that logged information is only used as intended.

A procedure, preferably automatic, should be put in place to ensure that logged information is either deleted or de-identified as specified in the retention schedule (see 7.4.7).

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 13.2.1.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.10.2.1 Information transfer policies and procedures

Implementation guidance

The organization should consider procedures for ensuring that rules related to the processing of PII are enforced throughout and outside of the system, where applicable.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 13.2.4.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.10.2.4 Confidentiality or non-disclosure agreements

Implementation guidance

The organization should ensure that individuals operating under its control with access to PII are subject to a confidentiality obligation. The confidentiality agreement, whether part of a contract or separate, should specify the length of time the obligations should be adhered to.

When the organization is a PII processor, a confidentiality agreement, in whatever form, between the organization, its employees and its agents should ensure that employees and agents comply with the policy and procedures concerning data handling and protection.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 14.1.2.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.11.1.2 Securing application services on public networks

Implementation guidance

The organization should ensure that PII that is transmitted over untrusted data transmission networks is encrypted for transmission.

Untrusted networks can include the public internet and other facilities outside of the operational control of the organization.

NOTE In some cases (e.g. the exchange of e-mail) the inherent characteristics of untrusted data transmission network systems can require that some header or traffic data be exposed for effective transmission.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 14.3.1.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

6.11.3.1 Protection of test data

Implementation guidance

PII should not be used for testing purposes; false or synthetic PII should be used. Where the use of PII for testing purposes cannot be avoided, technical and organizational measures equivalent to those used in the production environment should be implemented to minimize the risks. Where such equivalent measures are not feasible, a risk-assessment should be undertaken and used to inform the selection of appropriate mitigating controls.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 15.1.2.

Here is the relevant paragraph to article 5(1)(f) GDPR:

6.12.1.2 Addressing security within supplier agreements

Implementation guidance

The organization should specify in agreements with suppliers whether PII is processed and the minimum technical and organizational measures that the supplier needs to meet in order for the organization to meet its information security and PII protection obligations (see 7.2.6 and 8.2.1).

Supplier agreements should clearly allocate responsibilities between the organization, its partners, its suppliers and its applicable third parties (customers, suppliers, etc.) taking into account the type of PII processed.

The agreements between the organization and its suppliers should provide a mechanism for ensuring the organization supports and manages compliance with all applicable legislation and/or regulation. The agreements should call for independently audited compliance, acceptable to the customer.

NOTE For such audit purposes, compliance with relevant and applicable security and privacy standards such as ISO/IEC 27001 or this document can be considered.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 16.1.1.

Here is the relevant paragraph to article 5(1)(f) GDPR:

6.13.1.1 Responsibilities and procedures

Implementation guidance

As part of the overall information security incident management process, the organization should establish responsibilities and procedures for the identification and recording of breaches of PII. Additionally, the organization should establish responsibilities and procedures related to notification to required parties of PII breaches (including the timing of such notifications) and the disclosure to authorities, taking into account the applicable legislation and/or regulation.

Some jurisdictions impose specific regulations regarding breach responses, including notification. Organizations operating in these jurisdictions should ensure that they can demonstrate compliance with these regulations.

ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 18.1.1.

Here is the relevant paragraph to article 5(1)(f) GDPR:

6.15.1.1 Identification of applicable legislation and contractual requirements

Other information

The organization should identify any potential legal sanctions (which can result from some obligations being missed) related to the processing of PII, including substantial fines directly from the local supervisory authority. In some jurisdictions, International Standards such as this document can be used to form the basis for a contract between the organization and the customer, outlining their respective security, privacy and PII protection responsibilities. The terms of the contract can provide a basis for contractual sanctions in the event of a breach of those responsibilities.

ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII controllers.

Here is the relevant paragraphs to article 5(1)(f) GDPR:

7.4.8 Disposal

Control

The organization should have documented policies, procedures and/or mechanisms for the disposal of PII.

Implementation guidance

The choice of PII disposal techniques depends on a number of factors, as disposal techniques differ in their properties and outcomes (for example in the granularity of the resultant physical media, or the ability to recover deleted information on electronic media). Factors to consider when choosing an appropriate disposal technique include, but are not limited to, the nature and extent of the PII to be disposed of, whether or not there is metadata associated with the PII, and the physical characteristics of the media on which the PII is stored.

7.4.9 PII transmission controls

Control

The organization should subject PII transmitted (e.g. sent to another organization) over a data- transmission network to appropriate controls designed to ensure that the data reaches its intended destination.

Implementation guidance

Transmission of PII needs to be controlled, typically by ensuring that only authorized individuals have access to transmission systems, and by following the appropriate processes (including the retention of audit logs) to ensure that PII is transmitted without compromise to the correct recipients.

ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII processors.

Here is the relevant paragraph to article 5(1)(f) GDPR:

8.4.3 PII transmission controls

Control

The organization should subject PII transmitted over a data-transmission network to appropriate controls designed to ensure that the data reaches its intended destination.

Implementation guidance

Transmission of PII needs to be controlled, typically by ensuring that only authorized individuals have access to transmission systems, and by following the appropriate processes (including the retention of audit data) to ensure that PII is transmitted without compromise to the correct recipients. Requirements for transmission controls can be included in the PII processor — customer contract.

Where no contractual requirements related to transmission are in place, it can be appropriate to take advice from the customer prior to transmission.

(EN) ISO/IEC 27701, adopted in 2019, added a requirement additional to ISO/IEC 27002, section 18.1.3.

Here is the relevant paragraphs to article 5(2) GDPR:

6.15.1.3 Protection of records

Implementation guidance

Review of current and historical policies and procedures can be required (e.g. in the cases of customer dispute resolution and investigation by a supervisory authority).

The organization should retain copies of its privacy policies and associated procedures for a period as specified in its retention schedule (see 7.4.7). This includes retention of previous versions of these documents when they are updated.

ISO/IEC 27701, adopted in 2019, added additional ISO/IEC 27002 guidance for PII controllers.

Here is the relevant paragraphs to article 5(2) GDPR:

7.2.6 Contracts with PII processors

Control

The organization should have a written contract with any PII processor that it uses, and should ensure that their contracts with PII processors address the implementation of the appropriate controls in Annex B.

Implementation guidance

The contract between the organization and any PII processor processing PII on its behalf should require the PII processor to implement the appropriate controls specified in Annex B, taking account of the information security risk assessment process (see 5.4.1.2) and the scope of the processing of PII performed by the PII processor (see 6.12). By default, all controls specified in Annex B should be assumed as relevant. If the organization decides to not require the PII processor to implement a control from Annex B, it should justify its exclusion (see 5.4.1.3).

A contract can define the responsibilities of each party differently but, to be consistent with this document, all controls should be considered and included in the documented information.

7.2.8 Records related to processing PII

Control

The organization should determine and securely maintain the necessary records in support of its obligations for the processing of PII.

Implementation guidance

A way to maintain records of the processing of PII is to have an inventory or list of the PII processing activities that the organization performs. Such an inventory can include:

— the type of processing;

— the purposes for the processing;

— a description of the categories of PII and PII principals (e.g. children);

— the categories of recipients to whom PII has been or will be disclosed, including recipients in third
countries or international organizations;

— a general description of the technical and organizational security measures; and

— a Privacy Impact Assessment report.

Such an inventory should have an owner who is responsible for its accuracy and completeness.