The GDPR articles explained: Chapter 4 - Controller and processor

Chapter 4 of the General Data Protection Regulation (GDPR) primarily addresses the obligations of data controllers and processors concerning the protection and handling of personal data. It sets out specific requirements for both parties to ensure they process data securely. Controllers, who determine the purposes and means of processing personal data, must implement measures that comply with the GDPR. Meanwhile, processors, who handle data on behalf of controllers, are required to follow the controller’s instructions and also take security measures.

This chapter is pivotal in ensuring that data protection principles are integrated into the processing activities and organizational practices of these entities. It is divided into five key sections, each addressing a specific aspect of data protection:

Section 1: General obligations: This section, consisting of eight articles (Articles 24 to 31), focuses on the roles and responsibilities of the controllers related to data processing. It defines the roles of a data controller, the organization determining the purpose and means of processing, and a data processor, who processes data on behalf of the controller. Article 25 of this section elaborates how organizations should consider data protection throughout the lifecycle of data processing, from initial collection to storage and usage. This section also covers situations where multiple entities share control or responsibility for ensuring GDPR compliance throughout (joint controllers) and how organizations outside the European Union (EU),the representatives, can fulfill their obligations.

Section 2: Security of personal data: This section emphasizes the importance of safeguarding personal information. It mandates controllers and processors to implement appropriate security measures to protect data from breaches and unauthorized access. This section also outlines the procedures for notifying authorities and data subjects in case of a personal data breach.

Section 3: Data protection impact assessment and prior consultation : It requires controllers to conduct a Data Protection Impact Assessment (DPIA) for certain types of processing activities that pose a high risk to individuals' privacy. Additionally, it covers scenarios where the supervisory authority needs to be consulted before processing commences.

Section 4: Data Protection Officer: This section outlines the process for designating a Data Protection Officer (DPO), their position within the organization, and the key tasks they are responsible for, such as data protection awareness and training.

Section 5: Codes of conduct and certification: It explores additional compliance mechanisms. It allows organizations to adhere to approved codes of conduct or pursue certification from accredited bodies to demonstrate their commitment to data protection best practices.

Section 1: General obligations

Article 24: Responsibility of the controller

Implement measures: Choose appropriate security measures and organizational tactics based on the type of personal data you manage, taking into account the sensitivity of the data and the possible risks to individuals' privacy. For instance, data controllers can implement encryption technologies to secure both data at rest and in transmission. They can also adopt multi-factor authentication (MFA) to ensure that only authorized people can access personal data and tighten the access permissions.

Data protection policies: Depending on the scale of their data processing activities, organizations might need to adopt specific data protection policies (for example consent and contractual necessity) to further ensure compliance.

Codes of conduct and certifications: Follow approved codes of conduct as referred in Article 40, or obtain the GDPR compliance certifications as mentioned in Article 42, as it will help demonstrate the organization's commitment to compliance.

Article 25: Data protection by design and by default

Article 25 of the GDPR mandates that data protection principles must be integrated into the design of data processing systems and technologies, as well as implemented by default when processing personal data.

• Even before data processing begins, the systems and processes should be designed in a specific way to securely handle personal data. The design must consider the latest security technologies and should take into account the cost of implementation when integrating data protection measures into their systems, but without compromising the security of data. This means organizationsmust incorporate privacy measures from the beginning of the data processing cycle and not as an additional option once the system becomes operational.
• Only the personal data that is required for a specific purpose should be processed. This applies to the quantity of data collected, the extent of its processing, how long the data is stored, and who has access to it. By default, personal data should not be made accessible to an unlimited number of people without the individual's consent.
• Data controllers can use approved certification mechanisms (Article 42) that can help demonstrate that the above requirements are being met, assuring compliance with the GDPR’s expectations for data protection by design and by default.

Implications:

Pseudonymization: It involves altering personal data so it can't be linked to a particular individual without extra information (stored separately). For example, replacing names with unique identifiers in databases.

Minimizing data collection: The goal is to design software or systems that only collect the data necessary for the specified purpose. For example, an application requiring a user's location for its functionality will only collect that specific information and will not access the user's contacts or media. This practice is known as data collection minimization.

Automatic privacy settings: This involves ensuring the default privacy settings of software products reflect the most private option available. For example, a social media app might set user profiles to "private" by default, requiring users to actively choose to make their profiles public.

Data access controls: This means to implement systems where data accessibility is tightly controlled and limited. For example, ensuring that personal data is not accessible by default to all employees within an organization, but only to those who need it to perform their job.

Secure data storage and deletion: This involves automatically encrypting stored data and setting automatic deletion dates for data that no longer serves the original purpose for which it was collected.

ManageEngine's SIEM and IAM solutions help enterprises implement robust data access controls and access monitoring systems. While AD360, the IAM solution of ManageEngine, helps you securely implement Zero Trust and principle of least privileges to users accessing personal data. Log360, the SIEM solution from ManageEngine, delivers ML-based user behavior monitoring and access auditing mechanisms to ensure no unauthorized access happens. Log360 provides logon reports that help check who has access to the systems and applications that store and process personal data. Establishing groups that report, for example, permission and security configuration changes, helps validate access to personal data. It also helps you monitor privileged users and provides you with detailed audit trails and reports.

With AD360 Workflow, organizations can establish automated workflows that ensure adherence to GDPR principles. For instance, workflows can be configured to automatically enforce data access controls, detect and respond to security incidents promptly, and manage user consent preferences effectively. By embedding these privacy-enhancing features directly into their Active Directory management practices, organizations can proactively protect personal data and demonstrate compliance with GDPR's requirements for privacy by design and by default.

Article 26: Joint controllers

Article 26 of the GDPR deals with situations where two or more entities jointly decide how personal data will be processed. It emphasizes the need for transparent arrangements between these controllers to set out their respective responsibilities for complying with GDPR obligations, especially regarding data subjects' rights and information provision.

This arrangement should reflect their roles and relationships accurately and designate a contact point for data subjects. While the detailed arrangement might not be directly accessible to data subjects, they should be informed about its essence. Importantly, data subjects retain the right to enforce their GDPR rights against each controller individually, irrespective of the terms of the arrangement

Example: Cloud service providers

Imagine a scenario where a company uses multiple cloud service providers to store and process its customer data. In this case:

• The company and each cloud service provider are considered joint controllers because they jointly determine how the customer data will be processed (for examplestored and analyzed).
• They must establish a transparent agreement outlining each party's responsibilities. For instance, the company might be responsible for ensuring data security measures are in place, while the cloud service providers are responsible for maintaining the infrastructure.
• They should designate a contact point, maybe a dedicated email address, for data subjects to reach out to with inquiries or requests related to their personal data.
• Even though the detailed agreement between the company and each cloud service provider might not be shared with data subjects, they should still be informed about the basics of how their data is handled, such as knowing it's stored securely on cloud servers.
• Data subjects have the right to exercise their GDPR rights (like requesting access to their data) against both the company and each cloud service provider individually. This means they can contact each party separately to enforce their rights.

Article 27: Representatives of controllers or processors not established in the Union

Article 27 of the GDPR outlines the requirement for controllers or processors not established within the EU but conducting activities falling under the scope of the GDPR, to appoint a representative within the EU. This representative will be a point of contact for supervisory authorities and data subjects in matters related to data processing, ensuring compliance with the GDPR.

• An exemption occurs when processing activities are occasional, including those that do not involve large-scale processing of sensitive data or data relating to criminal convictions, and that pose no significant risk to the individuals' rights and freedoms.
• Public authorities or bodies are exempt from this requirement.

The appointed representative must be located in a Member State where the data subjects affected by the processing activities are located. Despite designating a representative, legal actions can still be initiated against the controller or processor themselves.

Example: A non-EU cloud service provider offering services to EU customers would need to appoint a representative in the EU to ensure compliance with GDPR requirements regarding data protection and representation within the EU jurisdiction.

Article 28: Processor

Article 28 mainly focuses on the responsibilities of the processors, which are entities that process personal data on behalf of a controller. The following conditions must be met by the processors and the controller to adhere to Article 28:

• Choosing a reliable processor: Controllers must ensure that the processors they work with provide sufficient guarantees to implement appropriate technical and organizational measures to protect personal data and comply with the GDPR.
• Authorization for sub-processors: Processors cannot engagewith another processor without the controller's prior written authorization. If given general authorization, processors must inform the controller of any intended changes, giving the controller the chance to object.
• Contractual agreements: Processing by a processor must be governed by a contract or legal act that outlines the processing details, including instructions from the controller, confidentiality commitments, security measures, and data subject rights. This contract ensures that processors follow the controller's instructions and adhere to the GDPR requirements.
• Assisting the controller: Processors must assist controllers in fulfilling their obligations under the GDPR, including responding to data subject requests, ensuring compliance with security measures, and providing necessary information for audits.
• Sub-processor obligations: If a processor engages with another processor, the same data protection obligations must be imposed on the sub-processor through a contract or legal act, ensuring that all parties involved comply with the GDPR requirements.
• Approved codes of conduct and certification mechanisms: Adherence to approved codes of conduct (Article 40) or certification mechanisms (Article 42) can demonstrate that processors provide sufficient guarantees for GDPR compliance.
• Standard contractual clauses: The contract between the controller and processor can be based on standard contractual clauses (Article 63) provided by the European Commission or supervisory authorities.
• Liability : If a processor infringes the GDPR by determining the purposes and means of processing, it will be considered a controller and bear the associated liability.

Assume if a company uses a cloud-based customer relationship management (CRM) system, the cloud provider must follow the GDPR requirements outlined in Article 28 to ensure the security and legality of processing the company's customer data.

Article 29: Processing under the authority of the controller or processor

Article 29 specifies that both processors and individuals acting under the authority of the controller or processor, who have access to personal data, are only allowed to process that data according to instructions from the controller. This means they cannot use or handle personal data for any purpose other than what the controller has explicitly instructed, unless there is a legal obligation to do so under Union or Member State law.

To understand it in a better way, imagine an IT administrator managing a customer database that should only access and process the data for tasks related to maintaining the database or resolving technical issues. The IT admin should not use the data for personal purposes or share it with others unless instructed to do so by the controller or as required by law. This helps ensure the privacy and security of individuals' personal data.

Article 30: Records of processing activities

Article 30 of the GDPR focuses on the importance for controllers and processors to keep records on how personal data is being handled and maintained within an organization.

Who maintains records?

Controllers (those who determine the purposes and means of processing personal data) and processors (those who process data on behalf of controllers) must keep records.

What information should be included?

For controllers:

• Name and contact details of the controller, joint controller (if applicable), representative, and the DPO.
• Purpose of processing the data.
• Categories of data subjects and personal data, what kind of data is being processed, and to whom the data concerns.
• Who will receive the data, including any third-world countries or international organizations.
• Any transfers of data to third-world countries or international organizations, including safeguards in place.
• How long different categories of data will be kept.
• A general description of the security measures that took place.

For processors:

• Name and contact details of the processor, controller(s) on whose behalf processing is done, representative (if applicable), and the DPO.
• Categories of processing carried out for each controller.
• Data transfers, same as for controllers.
• Security measures, same as for controllers.

Controllers and processors must make records available to supervisory authorities upon request. The records should be in writing, including electronic form.

Small businesses (less than 250 employees) are exempt unless their processing poses risks to data subjects' rights and freedoms, is not occasional, or involves special categories of data (like health or ethnicity) or data related to criminal convictions.

Example: A company maintains a record that includes its contact details, the purposes of processing (like software development and customer support), the categories of data subjects (like customers and employees), and the types of personal data collected (such as names, email addresses, and IP addresses). It also documents any third parties they share data with, like cloud service providers for hosting customer data.

If it transfers data to a non-EU country, it needs to document this and ensure there are appropriate safeguards in place, like encryption. It also needs to outline its data retention policies, stating it will keep customer data for five years after the end of the contract. Finally, it needs to describe their security measures, such as encryption protocols and access controls, to protect the data it processes.

Article 31: Cooperation with the supervisory authority

Article 31 of the GDPR emphasizes the importance of cooperation between data controllers, processors, and their representatives with supervisory authorities. This cooperation is essential for the supervisory authority to effectively perform its duties related to enforcing GDPR compliance.

How does this help the organization?

Ensuring compliance: By cooperating with the supervisory authority, organizations can ensure they are compliant with the GDPR. This is because the authority can provide guidance and feedback on whether the organization's data processing activities meet legal standards.

Preventing penalties: Cooperation can help prevent potential penalties and fines. By working with the supervisory authority, organizations can address issues proactively before they escalate into serious compliance violations.

Implications of non-cooperation

Legal consequences: Non-cooperation with the supervisory authority can lead to significant consequences under the GDPR. Article 83 outlines that non-compliance with an order or an investigation by the supervisory authority can result in administrative fines. These fines can be up to 10 million Euros or up to 2% of the total worldwide annual turnover of the preceding financial year, whichever is higher.

Reputational damage: Failing to cooperate can also lead to reputational damage. If the public becomes aware that an organization is uncooperative with regulatory bodies, it might lead to a loss of trust among consumers and partners.

Operational impact: Non-cooperation might trigger more stringent scrutiny from the supervisory authority, potentially leading to disruptions in the organization’s operations. This can include audits, orders to stop processing activities, or other corrective actions that could affect the organization’s ability to operate effectively.

Section 2: Security of personal data

Article 32: Security of processing

Article 32 outlines the requirements for ensuring the security of personal data processing. It sets forth specific standards that controllers and processors must meet to manage and protect personal data adequately against risks.

Controllers and processors must consider several factors to determine appropriate security measures, including the state of the current technological advancements, the nature, scope, context, and purposes of data processing. Additionally, they must assess the potential risks to the rights and freedoms of data subjects, taking into account the likelihood and severity of various risks.

Key highlights of this article include:

1) Implementation of security measures: Organizations, both controllers and data processors should implement appropriate technical and organizational measures to protect personal data. The organizational measures might include, but not limited to:

• Access controls: Establishing clear policies on who has access to personal data and what level of access they have (read-only, edit, etc.). This might involve implementing a system that can provide users with different roles and permissions.
• Data minimization: Companies should collect and store only the minimum amount of personal data necessary for their business purposes. This reduces the amount of data at risk in case of a breach.
• Data protection training and awareness: Conducting regular training programs to increase awareness. Employees who handle personal data should be trained on GDPR regulations and best practices for data security. This can prevent accidental breaches.
• Data breach response plans: Having a clear plan in place for how to respond to a data breach is critical. This plan should outline steps for identifying, containing, and reporting the breach, as well as notifying affected individuals.
• Data Protection Officer (DPO): For companies processing high-risk data or large volumes of personal data, appointing a DPO is recommended. The DPO acts as an internal expert on data protection and ensures compliance with the GDPR.
• Organizational culture of data protection: Companies should foster a culture where data protection is valued and prioritized. This can be achieved through leadership commitment, clear communication of data protection policies, and encouraging employees to report any suspected breaches.

Technical measures include, but not limited to:

• Encryption: Encrypting data at rest (stored on servers) and in transit (being transferred) renders it unreadable by unauthorized individuals even if intercepted. This is especially important for sensitive data like financial information or health records.
• Pseudonymization: This involves replacing personal identifiers (like names or social security numbers) with aliases or codes. While it doesn't guarantee complete anonymity, it makes it significantly harder to identify individuals if a data breach occurs.
• Strong password policies and multi-factor authentication: Enforcing complex password requirements and implementing MFAadds an extra layer of security to access control. MFA requires a second verification step beyond just a password, like a code sent to a phone or fingerprint scan.

With help of ManageEngine ADSelfService Plus, employ MFA to secure endpoint logins, cloud application logins, and self-service password reset and account unlock.

• Firewalls and intrusion detection systems: Firewalls act as gateways that filter incoming and outgoing traffic, while intrusion detection systems monitor for suspicious activity on a network that might indicate a security breach. Therefore, implementation of these perimeter security systems helps keep malicious sources at bay.
• Regular patching and updates: Keeping software and systems updated with the latest security patches is crucial to address known vulnerabilities that hackers might exploit.
• Data backups and disaster recovery plans: Having a robust backup system and a disaster recovery plan ensures that data can be restored in case of accidental loss, hardware failure, or a cyberattack.

ManageEngine RecoveryManager Plus is a web-based enterprise backup solution providing you with the ability to easily backup and restore your Active Directory, Azure Active Directory (Microsoft Entra ID) , Microsoft 365 (Exchange Online, SharePoint Online, OneDrive for Business), Google Workspace, on-premises Exchange, and Zoho WorkDrive environments.

2) Risk-Based approach to security: Article 32 also specifies that the level of security must be assessed based on the specific risks associated with the processing of personal data. This means that organizations must evaluate the likelihood and potential severity of risks to the rights and freedoms of individuals whose data they process. This evaluation should guide the selection and implementation of security measures.

Types of risks to consider

The clause particularly highlights several risks that need to be considered when assessing the appropriate level of security:

• Accidental destruction: This refers to unintentional damage to data, which could happen due to a variety of factors such as hardware failures, software malfunctions, or human errors.
• Unlawful destruction: This involves deliberate harm to data, possibly for malicious reasons, such as cyberattacks aimed at erasing data.
• Loss: The risk of data being lost, which could occur through mishandling, misplacement, or due to technical issues like a failed backup.
• Alteration: Unauthorized changes to data, which could compromise data accuracy and reliability. This could be the result of hacking or internal misuse.
• Unauthorized disclosure: This could happen through breaches of data security leading to exposure of personal information without consent from the data subjects or lawful justification.

Log360 addresses these requirements through its comprehensive auditing and alerting functionalities. It provides detailed, predefined reports for auditing changes in MS SQL and Oracle databases, capturing who made changes, when, and from where. This helps track and document database modifications, unauthorized login attempts, permission changes, and other critical changes. Real-time alerts further enhance security by notifying administrators of unauthorized or unlawful activities, such as unauthorized database modifications or file permission changes.

3) Adherence to standards: Following an approved code of conduct (Article 40) or an approved certification mechanism (Article 42) can demonstrate compliance with these security requirements.

4) Data processing oversight: Any individual acting under the authority of the data controller or processor and who has access to personal data must not process this data unless instructed by the controller or required by law.

Log360 collects log data from a wide range of devices and systems. By aggregating and analyzing these logs, Log360 can identify patterns and anomalies that might indicate a security threat or vulnerability. This capability is vital for ongoing testing and assessing the effectiveness of current security measures. The solution provides detailed reports on a variety of security-related events, such as firewall configuration changes, unauthorized access to servers, and critical changes in Active Directory.

Log360 also tracks and alerts on anomalous user activities, including unusual logon/logoff activities during non-business hours and multiple logon failures. Monitoring these activities helps in detecting potential insider threats or compromised accounts, further enabling organizations to evaluate and refine their security strategies.

Article 33: Notification of a personal data breach to the supervisory authority

Article 33 is crucial as it mandates the procedures that must be followed in the event of a personal data breach. This article outlines the obligations of data controllers to notify the appropriate supervisory authority of breaches within a specific timeframe and provides guidelines on the content of such notifications.

1) Notification timing and criteria:

• Immediate notification: If there is a personal data breach, the data controller is required to notify the relevant supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of it.
• Exception to notification: Notification is not required if the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. This means if the breach doesn’t pose a significant harm or impact to individuals, notification might not be necessary.
• Delayed notification: If the notification isn't made within 72 hours, it must include reasons for the delay. This clause ensures that controllers take immediate action or provide justifications for any delays, promoting accountability.

2) Processor’s obligation:

Notification by processors: Processors, when they discover a breach, must notify the controllers without undue delay. This ensures that controllers can comply with their notification obligations in a timely manner.

3) Contents on notification:

• Details of the breach: The notification must describe the nature of the personal data breach, including, where possible, the categories and approximate number of data subjects and personal data records concerned.
• Contact information: It must include contact details of the DPO or another contact point for more information.
• Consequences and measures: The notification should describe the likely consequences of the breach and detail the measures taken or proposed to address it, including steps to mitigate its adverse effects.

4) Staged information provision:

If it is not possible to provide all the required information at once, it can be provided in phases without undue further delay.

5) Documentation of breaches:

Controllers are required to document any personal data breaches, detailing the facts, effects, and remedial actions taken. This documentation must be sufficient to enable the supervisory authority to verify compliance with this article.

Example: An online retailer discovers that a configuration error in its database has exposed customer data online. Although the error is fixed within 48 hours, the retailer still notifies the supervisory authority because the personal data of all the customers was accessible, explaining the breach, its potential impact, and preventive actions taken.

The Log360 tool provides real-time monitoring and alerting capabilities that enable quick detection of data breaches within a network. Its predefined alert profiles and correlation rules are specifically tailored to identify common attack patterns such as DoS, DDoS, SQL injections, and ransomware attacks, which are pertinent to personal data security. Additionally, Log360's custom rule builder enables organizations to develop new correlation rules for detecting and responding to previously unknown attack patterns, thus enhancing data protection measures.

Article 34: Communication of a personal data breach to the data subject

Article 34 of the GDPR outlines the requirements for communicating a personal data breach to the data subject.

Communication requirement: When a personal data breach is likely to result in a high risk to the rights and freedoms of individuals, the controller must inform the data subject without undue delay.

Content of communication: The communication to the data subject must be clear and easy to understand. It should describe the nature of the breach and include at least the information and measures specified in Article 33(3) of the GDPR. These measures typically involve steps taken to mitigate the impact of the breach and protect affected individuals' rights.

Exceptions to communication requirement:

Implementation of adequate protection measures: If the controller has implemented appropriate technical and organizational measures, such as encryption, to safeguard the affected personal data, communication to the data subject might not be necessary.

Subsequent measures: If the controller takes subsequent measures to mitigate the risk to individuals' rights and freedoms, communication might not be required.

Disproportionate effort: If communicating with affected individuals would involve disproportionate effort, alternative measures such as public communication might be considered, provided they are equally effective in informing data subjects.

Supervisory authority intervention: If the controller has not already informed the data subject of the breach, the supervisory authority (the independent public authority responsible for monitoring compliance with the GDPR) might require the controller to do so. The supervisory authority can also assess whether any of the conditions for exemption from communication apply.

Example: Suppose a data breach occurs in an online retail platform, exposing customers' names, email addresses, and credit card information. If the breach is likely to result in a high risk to customers' rights and freedoms, the platform must notify affected individuals promptly, providing clear information about the breach and the measures taken to mitigate its impact.

Section 3: Data protection impact assessment and prior consultation

Article 35: Data protection impact assessment

Article 35 of the GDPR outlines the requirements for conducting a Data Protection Impact Assessment (DPIA) when processing activities are likely to result in a high risk to the rights and freedoms of data subjects. Let's break down the details of this article and provide an example:

Requirement for DPIA: Controllers must conduct a DPIA before processing activities, particularly those involving new technologies, which are likely to result in a high risk to the rights and freedoms of data subjects. This assessment considers the nature, scope, context, and purposes of the processing.

Single assessment for similar operations: Controllers can perform a single assessment for a set of similar processing operations that present similar high risks.

Involvement of DPO: The controller must involve the DPO, if designated, in carrying out the DPIA.

Mandatory DPIA situations: DPIAs are particularly required in specific cases, including:

• Systematic and extensive evaluation of personal aspects based on automated processing, leading to decisions with legal or similarly significant effects.
• Large-scale processing of special categories of data (sensitive data) or data relating to criminal convictions and offenses.
• Large-scale systematic monitoring of publicly accessible areas.

Lists by supervisory authority: Supervisory authorities establish and publish lists of processing operations subject to mandatory DPIAs, as well as those not requiring DPIAs.

Content on DPIA: The DPIA must include:

• Description of the processing operations and purposes, including legitimate interests.
• Assessment of the necessity and proportionality of the processing.
• Evaluation of risks to data subjects' rights and freedoms.
• Measures to address risks, including safeguards and security measures.

Consideration of codes of conduct: Compliance with approved codes of conduct is taken into account when assessing the impact of processing operations.

Involvement of data subjects: Controllers may seek the views of data subjects or their representatives on intended processing, while ensuring the protection of commercial or public interests and the security of processing operations.

Legal basis and prior DPIAs: If processing has a legal basis in Union law or Member State law, and a DPIA has already been conducted, additional DPIAs mighty not be necessary unless deemed necessary by Member States.

Review of processing: Controllers must review processing to ensure compliance with the DPIA, especially when there are changes in the risk represented by processing operations.

Example: A technology company is developing a new AI system for automated decision-making in recruitment processes. This AI system analyzes resumes and profiles candidates to identify suitable candidates for job positions. Given the nature of the processing involving automated decision-making and its potential impact on individuals' employment opportunities, the technology company must conduct a DPIA before implementing the AI system.

Article 36: Prior consultation

Article 36 mentions the requirement for controllers to consult the supervisory authority prior to processing if a DPIA indicates that the processing would result in a high risk to data subjects' rights and freedoms without adequate mitigation measures.

Consultation requirement: Controllers must consult the supervisory authority before processing if a DPIA indicates that the processing poses a high risk to data subjects' rights and freedoms.

Supervisory authority's opinion: If the supervisory authority believes that the intended processing would breach the GDPR, especially if risks have not been adequately identified or mitigated, it must provide written advice to the controller within eight weeks of receiving the consultation request. This advice may include the use of supervisory authority powers as outlined in Article 58. The deadline for providing advice might be extended by six weeks, considering the complexity of the processing, and the supervisory authority must inform the controller of any extension.

Information to provide to the supervisory authority: When consulting the supervisory authority, the controller must provide:

• Responsibilities of involved parties (controller, joint controllers, processors).
• Purposes and means of the intended processing.
• Measures and safeguards to protect data subjects' rights and freedoms.
• Contact details of the DPO.
• DPIA conducted according to Article 35.
• Any other information requested by the supervisory authority.

Consultation during legislative measures: Member States must consult the supervisory authority during the preparation of legislative or regulatory measures related to processing.

Exceptions: Member State law might require controllers to consult with and obtain prior authorization from the supervisory authority for processing carried out in the public interest, such as processing related to social protection and public health.

Example: A software company plans to deploy a new system for automated decision-making in credit scoring. Before implementing this system, the company conducts a DPIA and determines that the processing might result in a high risk to data subject's rights and freedoms due to the potential for discriminatory outcomes. Consequently, the company consults the supervisory authority to seek guidance on mitigating these risks and ensuring compliance with the GDPR.

Section 4: Data protection officer

Article 37: Designation of the data protection officer

Article 37 of the GDPR outlines the requirements for the designation of a DPO by controllers and processors.

Mandatory designation of DPO:

Public authorities: Public authorities or bodies, excluding courts acting in their judicial capacity, must designate a DPO.

1. Core activities: Controllers or processors whose core activities involve:
   • Regular and systematic monitoring of data subjects on a large scale.
   • Large-scale processing of special categories of data (sensitive data) or data relating to criminal convictions and offenses.
2. Group of undertakings: A group of undertakings may appoint a single DPO, provided that the DPO is easily accessible from each establishment.
3. Public authorities or bodies: When the controller or processor is a public authority or body, a single DPO may be designated for several such authorities or bodies, considering their organizational structure and size.
4. Voluntary designation: In cases other than those mandated in paragraph one, controllers, processors, or associations representing categories of controllers or processors may voluntarily designate a DPO. The DPO may act for such associations or bodies representing controllers or processors.
5. Qualifications of DPO: The DPO must possess professional qualities, including expert knowledge of data protection law and practices, and the ability to fulfill tasks as outlined in Article 39.
6. Appointment options: The DPO can be a staff member of the controller or processor, or fulfill the tasks based on a service contract.
7. Publication of contact details: The controller or processor must publish the contact details of the DPO and communicate them to the supervisory authority.

Example: A multinational IT company that specializes in cloud services processes large volumes of personal data, including sensitive information such as health records, for various clients. Given the nature and scope of its activities involving the processing of sensitive data on a large scale, the company is required to designate a DPO to ensure compliance with the GDPR.

Implications:

Enhanced compliance: Designating a DPO ensures that organizations adhere to data protection laws and regulations, thereby minimizing the risk of non-compliance and potential penalties.

Expert guidance: DPOs provide expert guidance on data protection matters, helping organizations navigate complex legal requirements and ensuring that data processing activities are conducted in accordance with the GDPR.

Improved data governance: The presence of a DPO promotes a culture of accountability and transparency regarding data protection practices within organizations, leading to improved data governance and risk management.

Enhanced trust: By appointing a DPO and publishing their contact details, organizations demonstrate their commitment to protecting individuals' privacy rights, which can enhance trust among stakeholders, including customers, partners, and regulatory authorities.

Article 38: Position of the data protection officer

Article 38 focuses on the role and position of the DPO within an organization. It outlines key aspects to ensure the DPO's independence and effectiveness in protecting personal data. Here's a breakdown of the key points:

Involvement and support:

The controller (organization deciding data use) and processor (organization handling data) must actively involve the DPO in all data protection matters.

They are responsible for providing the DPO with the necessary resources:

• Access to personal data and processing operations for proper oversight.
• Financial and technical support to maintain their expertise in data protection.

Independence and reporting:

The DPO must be free from influence when performing their duties. This means they cannot receive instructions on how to handle specific data protection issues. They cannot be penalized or dismissed for carrying out their tasks as outlined in Article 39 (which details specific DPO responsibilities). The DPO reports directly to the highest management level, ensuring their voice is heard at the decision-making table.

Interaction with data subjects:

Data subjects (individuals whose data is processed) have the right to contact the DPO directly. This allows them to raise concerns about their data processing and exercise their rights under the GDPR (for example access, rectification, and erasure).

Confidentiality:

The DPO is bound by confidentiality regarding the information they handle while performing their duties. However, this doesn't prevent them from seeking guidance from supervisory authorities if needed. National laws might further define the scope and limitations of confidentiality for DPOs.

The DPO can take on other tasks, but the controller and processor must ensure these tasks don't create a conflict of interest with their data protection responsibilities.

Assume a company developing a new CRM system. Here's how Article 38 applies:

• The DPO is involved in discussions about data collection, storage, and access within the CRM.
• The company provides the DPO with access to the CRM system and relevant data protection documentation.
• The DPO identifies potential risks and recommends data security measures to be implemented.
• Customers and data subjects can contact the DPO with questions about their data stored in the CRM.
• The DPO maintains confidentiality about specific customer data but can raise concerns with management if they suspect a data breach.

Article 39: Tasks of the data protection officer

Article 39 of the GDPR delineates the tasks of the DPO within an organization. Let's clarify the details of this article:

Informing and advising:

The DPO is responsible for informing and advising the controller or processor, as well as employees involved in processing, about their obligations under the GDPR and other relevant data protection laws.

Monitoring compliance:

The DPO must monitor compliance with the GDPR, other data protection laws, and the organization's internal policies regarding the protection of personal data. This includes ensuring that responsibilities are clearly assigned, conducting awareness-raising and training sessions for staff, and conducting audits related to data processing activities.

Providing advice on DPIA:

The DPO is tasked with providing advice on DPIAs when requested and monitoring their performance in accordance with Article 35 of the GDPR. DPIAs assess the potential risks to individuals' rights and freedoms arising from data processing activities.

Cooperation with the supervisory authority:

The DPO must cooperate with the supervisory authority, which is responsible for enforcing data protection laws. This includes acting as the contact point for the supervisory authority on processing-related issues, facilitating prior consultations as required by Article 36, and consulting with the authority on other matters as appropriate.

Risk assessment:

In performing their tasks, the DPO must consider the risks associated with processing operations, taking into account factors such as the nature, scope, context, and purposes of processing.

Section 5: Codes of conduct and certification

Article 40: Codes of conduct

Article 40 of the GDPR focuses on encouraging the development and use of codes of conduct (CoCs) to facilitate the proper application of the regulation. Here's a breakdown of the key points:

Encouragement for development: EU member states, supervisory authorities, the European Data Protection Board (EDPB), and the European Commission are all obligated to encourage the creation of CoCs. These codes should consider the specificities of different processing sectors (for example healthcare versus finance) and the needs of small and medium-sized businesses (SMBs).

Who can develop CoCs: Associations representing data controllers (organizations deciding data use) or processors (organizations handling data) can create, amend, or extend CoCs. These codes can provide practical guidance on applying the GDPR in areas like:

• Fair and transparent data processing
• Legitimate interests for data collection
• Methods for data collection and pseudonymization (using non-identifiable data)
• Information provided to data subjects and the public
• Exercising data subject rights (access, rectification, erasure)
• Data security measures
• Data breach notification procedures
• Transferring data to third countries
• Dispute resolution mechanisms

Adherence beyond the GDPR: While CoCs are primarily intended for organizations subject to the GDPR, non-GDPR organizations can also adhere to them for data transfers to third countries. This demonstrates commitment to data protection during the transfer.

Monitoring and enforcement: CoCs should have mechanisms for the body overseeing the code (as outlined in Article 41) to monitor compliance by adhering organizations. This is without prejudice to the supervisory authorities' enforcement powers.

Approval process:

• Draft CoCs, amendments, or extensions require approval from the relevant supervisory authority.
• For activities in multiple member states, the EDPB provides an opinion before approval.
• The Commission can then decide if an approved CoC has general validity throughout the EU.
• All approved CoCs are published in a register for public access.

Article 41: Monitoring approved Codes of Conduct

Article 41 delves into the monitoring of compliance with Codes of Conduct (CoCs) established under Article 40 of the GDPR. It outlines the process for accrediting independent bodies to monitor adherence to these codes.

Role of supervisory authorities: The core responsibility for enforcing the GDPR lies with the supervisory authorities in each EU member state. Their powers and tasks remain unaffected by Article 41.

Accredited monitoring bodies: Supervisory authorities can accredit independent bodies to monitor compliance with approved CoCs.

These bodies must possess:

• Relevant expertise in the subject matter covered by the CoC.
• Proven independence from potential conflicts of interest.
• Established procedures for:
  • Assessing suitability of controllers and processors for the CoC.
  • Monitoring compliance with the CoC's provisions.
  • Regularly reviewing the CoC's effectiveness.
  • Handling complaints regarding CoC infringements or implementation.
  • Ensuring transparency of these procedures for data subjects and the public.

Accreditation process: The supervisory authority drafts requirements for accreditation and submits them to the EDPB for consistency checks across the EU.

Enforcement by monitoring body: An accredited body can take appropriate action, with safeguards, against controllers and processors who violate the CoC. This could include suspension or exclusion from the CoC. They must inform the supervisory authority of such actions and their justifications.

Revocation of accreditation: The supervisory authority can revoke accreditation if the body fails to meet or maintain accreditation requirements or takes actions violating the GDPR.

Exclusion: This article doesn't apply to data processing by public authorities and bodies.

Imagine a CoC for cloud service providers focusing on data security and privacy. An accredited monitoring body could:

• Review the security practices of cloud providers seeking to join the CoC.
• Regularly audit cloud providers to ensure they adhere to the CoC's security and privacy standards.
• Investigate complaints from data subjects regarding potential CoC violations by cloud providers.
• Publish reports on the overall effectiveness of the CoC and suggest improvements.

Article 42: Certification

Article 42 of the GDPR focuses on voluntary certification mechanisms for demonstrating compliance with the regulation. It outlines the framework for establishing data protection certifications and seals.

Encouragement for certification:

• The EU and member states are encouraged to promote data protection certification mechanisms and seals.
• These tools should be accessible to micro, small, and medium-sized enterprises (SMEs) with their specific needs considered.
• Certification can also be used by non-GDPR organizations to demonstrate appropriate safeguards for data transferred to third countries.

Voluntary and transparent process:

Certification is voluntary and should be obtainable through a clear and transparent process.

Limited Impact on responsibility:

• Certification doesn't absolve controllers (organizations deciding data use) or processors (organizations handling data) from their GDPR compliance obligations.
• Supervisory authorities retain their full enforcement powers.

Issuing certification: Certification can be issued by:

• Accredited certification bodies (as outlined in Article 43).
• The competent supervisory authority in each member state.

The criteria for certification are approved by either the supervisory authority or the EDPB. The EDPB can create a common "European Data Protection Seal.

Information sharing and renewal:

• Organizations seeking certification must provide all necessary information and access to their data processing activities for evaluation.
• Certifications are valid for a maximum of three years and can be renewed if criteria are still met.
• Certifications can be withdrawn if criteria are no longer fulfilled.

Public register: The EDPB maintains a public register of all certification mechanisms and data protection seals.

Implications:

Demonstrating compliance: Certification offers a valuable tool for organizations to publicly showcase their commitment to data protection. This can be particularly beneficial when dealing with clients or partners concerned about data privacy.

Streamlining data transfers: Certification can potentially simplify data transfers to non-EU countries by demonstrating the existence of appropriate safeguards.

Increased trust: Data subjects and partners may place greater trust in organizations with valid data protection certifications.

Article 43: Certification bodies

Article 43 delves into the establishment and accreditation of certification bodies that can issue data protection certifications under Article 42 of the GDPR.

Role of supervisory authorities: Supervisory authorities maintain their core responsibility for GDPR enforcement, even with certification bodies in place.

Accreditation process: EU member states are responsible for ensuring certification bodies are accredited by:

• The competent supervisory authority in their country.
• The national accreditation body following specific standards (EN-ISO/IEC 17065) and additional requirements set by the supervisory authority.

Requirements for certification bodies: To be accredited, bodies must demonstrate:

• Independence and expertise in data protection.
• Commitment to approved certification criteria.
• Established procedures for issuing, reviewing, and withdrawing certifications.
• Transparent complaint handling procedures for data subjects and the public.
• Absence of conflicts of interest.

Accreditation requirements: The requirements for accreditation are approved by either the supervisory authority or the EDPB, with additional considerations for national accreditation bodies.

Responsibilities and duration: Accredited certification bodies are responsible for proper assessment leading to certification or withdrawal (without absolving controllers and processors from their GDPR obligations). Accreditation lasts for a maximum of five years with the possibility of renewal upon meeting the requirements.

Transparency and communication: Supervisory authorities must make public the requirements for certification bodies and the criteria for certification. They must also share these with the EDPB.

Revocation of accreditation: Supervisory authorities or national accreditation bodies can revoke accreditation if the body fails to meet requirements or acts in violation of the GDPR.

Commission role: The European Commission can adopt specific requirements for data protection certification mechanisms. They can also establish technical standards and promotion mechanisms for certification seals and marks.

Implications:

Ensuring qualified certifiers: By establishing accreditation requirements, Article 43 helps ensure certification bodies possess the necessary expertise to accurately assess an organization's GDPR compliance.

Maintaining supervisory authority oversight: The supervisory authorities retain ultimate control over the certification process, ensuring its effectiveness and alignment with the GDPR.