GDPR Articles With Commentary & EU Case Laws by Adv. Prashant Mali (red seas under red skies txt) 📕

The second one aimed at the assumption where the controller has designated a seconded data protection officer charged, on the one hand, to ensure the compliance of the data protection legislation and on the other hand, to maintain records of the processing activities.

Art. 31 GDPR Cooperation with the supervisory authority

The controller and the processor and, where applicable, their representatives, shall cooperate, on request, with the supervisory authority in the performance of its tasks.

Suitable Recitals

(82) Record of processing activities.

COMMENTARY:

In order to demonstrate compliance with this Regulation, the controller or processor should maintain records of processing activities under its responsibility. Each controller and processor should be obliged to cooperate with the supervisory authority and make those records, on request, available to it, so that it might serve for monitoring those processing operations.

Article 31 GDPR stipulates the general obligations to cooperate with supervisory authorities. This obligation applies to the controller, processor and if applicable their respective representatives. The important is corporation shall take place at the

request of the supervisory authority, the controller and the processor does not have to cooperate on its own.

Section 2: Security of personal data Art. 32 GDPR Security of processing

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:

The Pseudonymisation and encryption of personal data;

The ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;

The ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;

A process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.

Adherence to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate compliance with the requirements set out in paragraph 1 of this Article.

The controller and processor shall take steps to ensure that any natural person acting under the authority of the controller or the processor who has access to personal data does not process them except on instructions from the controller, unless he or she is required to do so by Union or Member State law.

Suitable Recitals

(75) Risks to the rights and freedoms of natural persons; (76) Risk assessment; (77) Risk assessment guidelines; (78) Appropriate technical and organisational measures; (79) Allocation of the responsibilities; (83) Security of processing.

COMMENTARY:

Article 32 of the General Data Protection Regulation (GDPR) requires Data Controllers and Data Processors to implement technical and organizational measures that ensure a level of data security appropriate for the level of risk presented by processing personal data. In addition, Article 32 specifies that the Data

Controller or Data Processor must take steps to ensure that any natural person with access to personal data does not process the data except on instruction of the controller, processor, European Union law, or member state law. Compliance with Article 32 requirements can be demonstrated by adherence to an approved code of conduct as specified in Article 40 or an approved certification as specified in Article 42.

Compliance Description

Data security measures should, at a minimum, allow:

Pseudonymisation or encrypting personal data.

Maintaining ongoing confidentiality, integrity, availability, access, and resilience of processing systems and services.

Restoring the availability of and access to personal data, in the event of a physical or technical security breach.

Testing and evaluating the effectiveness of technical and organization measures.

Although Pseudonymisation and encryption are required technical measures, Article 32 gives Data Controllers flexibility in determining which additional technical measures best ensure data security. However, when selecting a measure, the Data Controller must document an evaluation of the measure along four criteria:

State of the Art: An evaluation of the latest and most advanced data security and privacy enhancement tools available. For example, some newer technologies are behavior analytics that profile normal behavior patterns and trigger alerts when a divergence occurs, privileged user monitoring that checks user activities and blocks access to data if necessary, and Format Preserving Encryption (FPE) that

encrypts data employing the existing database format.

Processing Profile: An evaluation of the nature, scope, context, and purposes of the data processing.

Risk Profile: An evaluation of the likelihood and severity of risks to the rights and freedoms of natural person when processing personal data. Risks include “accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data transmitted, stored, or otherwise processes.” Conducting a risk assessment is best done with a Privacy Impact Assessment (PIA), as specified in Article 35 of the GPDR.

Cost: An evaluation of the cost of implementation relative to the risk profile.

Compliance Methods

Complying with Article 32 requires both organizational and technical strategies. Organizational strategies are similar to those specified for Article 25 compliance. Technical strategies include:

Change management: Monitors, logs, and reports on data structure changes. Shows compliance auditors that changes to the database can be traced to accepted change tickets.

Data discovery and classification: Discovers and provides visibility into the location, volume, and context of data on premises, in the cloud, and in legacy

databases. Classifies the discovered data according to its personal information data type (credit card number, email address, medical records, etc.) and its security risk level.

Data loss prevention: Monitors and protects data in motion on networks, at rest in data storage, or in use on endpoint devices. Blocks attacks, privilege abuse, unauthorized access, malicious web requests, and unusual activity to prevent

data theft.

Data masking: Anonymizes data via encryption/hashing, eneralization, perturbation, etc. Pseudonymizes data by replacing sensitive data with realistic fictional data that maintains operational and statistical accuracy.

Data protection: Ensures data integrity and confidentiality through change control reconciliation, data-across-borders controls, query whitelisting, etc.

Ethical walls: Maintains strict separation between business groups to comply with M&A requirements, government clearance, etc.

Privileged user monitoring: Monitors privileged user database access and activities. Blocks access or activity, if necessary.

Secure audit trail archiving: Secures the audit trail from tampering, modification, or deletion, and provides forensic visibility.

Sensitive data access auditing: Monitors access to and changes of data protected by law, compliance regulations, and contractual agreements. Triggers alarms

for unauthorized access or changes. Creates an audit trail for forensics.

User rights management: Identifies excessive, inappropriate, and unused privileges.

User tracking: Maps the web application end user to the shared application/database user to the final data accessed.

VIP data privacy: Maintains strict access control on highly sensitive data, including data stored in multi-tier enterprise applications such as SAP and PeopleSoft.

Using the Latest Available Tools and Software

According to Article 32 of the GDPR regulations, only the most recent technology will suffice when implementing appropriate technical and organizational measures. What this means is that you are required to use the newest tools and methods in order to secure customer data. Depending on the context, this can range from modern, up-to-date security tools, like web vulnerability scanners and tools for

logging and monitoring, to regular staff training and strong password policies. Databases servers, web servers and any other type of server software used in the organization have to be up-to-date and regularly patched in order to adhere to this part of the GDPR.

Handling and Processing Personal Data

The nature, scope and purpose of the data processing an organization performs also needs to be documented. Data must also be stored appropriately. For example, credit card data has to be handled one way, whereas email addresses will be handled a different way. Generally, the rule is that it's best to store the minimum amount data possible in order to perform a specified task.

Segregating Data

As an application of the above rule, organizations have to make sure they adjust their security measures to match the probability and severity of a breach against the potential impacts on rights and freedoms of data subjects. This means that a breach of websites that allow the exchange of sensitive data between journalists and sources, may have a higher impact on the rights and freedoms of the affected users than the breach of a site that allows people to share cooking recipes, for example. It's vital to separate and estimate these varying risks and then apply security measures appropriate to the risk.

Minimum Compliance Requirements in Article 32

Article 32 of the GDPR regulations state that the minimum consequences arising from regulations should include the following:

Personal data should be pseudonymised (for example, by replacing names with unique identifiers) and encrypted where possible.

Ongoing confidentiality, integrity, availability and resilience of processing systems and services must be ensured. In other words, all data should be readily available to users, and provisions should be made to ensure that it is not read

or tampered with by unauthorized persons, whether accidentally or on purpose.

In case of a detrimental physical or technical incident, access to personal data must be able to be restored quickly. This refers to offsite backups and emergency

strategies in case of unforeseen events.

Organizations must implement a process for regularly testing, assessing and evaluating the effectiveness of technical and organizational measures that are designed to ensure the security of processing. In other words, organizations shouldn't blindly rely on established security measures, but proactively test them in order to see whether or not they work as intended. In the case of web applications, this would include penetration testing and regular application vulnerability scanning.

Consider All the Risks of Processing Data

Article 32 further states that organizations must consider the risks that are presented by processing personal data. These risks might take the form of accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of personal data. It also includes how personal data is accessed, transmitted and stored. This GDPR section closes by reiterating that only authorized persons should process data when they are required or instructed to do so. In summary, organizations should make sure that all personal data is safely stored and only transmitted to trusted, authorized persons and third parties.

The Road to GDPR Compliance

Implementing the varying aspects of the GDPR regulations remains a challenge for many organizations. To help you get started we have written a white paper, The Road to GDPR Compliance – a high level overview of what organizations should do in order to become GDPR compliant.

Art. 33 GDPR Notification of a personal data breach to the supervisory authority

In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.

The processor shall notify the controller without undue delay after becoming aware of a personal data breach.

The notification referred to in paragraph 1 shall at least:

Describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;

Communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;

Describe the likely consequences of the personal data breach;

Describe the measures taken or propose to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

Where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay.

The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.

Suitable Recitals

Notification obligation of breaches to the supervisory authority; (87) Promptness of reporting / notification; (88) Format and procedures of the notification.

COMMENTARY:

Article 33 of the Regulation generalizes the obligation of notification of data breaches to the supervisory authority by specifying it (see also G29, Opinion 03/2014 of 25 March 2014, on the notification of personal data breaches). Pursuant to Article 33 (1), any personal data breach, as defined in Article 4 (12 of the Regulation, i.e., “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed” must be notified to the supervisory authority as a rule.

In the second proposed version of the Regulation, only data breach that are likely to expose individuals to risk in terms of their rights and freedoms were covered by the obligation of notification to the supervisory authority. Examples were contained in Article 33 (1): discrimination, identity theft or impersonation, financial loss, unauthorised reversal of the Pseudonymisation, loss of reputation, loss of confidentiality of data protected by the professional secrecy or any other significant economic or social damage.

In its latest version, the rule is reversed: any breach of data must be subject to a notification unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. The regulation also sets the time limits for notification, as the controller knows the breach. The notification must be made without unjustified delay and, if possible not later than 72 after the controller having become aware of the breach. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.

The processor shall notify the controller without undue delay after becoming aware of a personal data breach. The minimum content of the notification - part of which may be deferred (without undue delay, see Art. 33 (4) is also set by the provision:

Description of the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned (Art. 33 (3), a));

The name and contact details of the data protection officer or other contact point