GDPR Top 10 Impacts

What are codes of conduct under the GDPR?

Preliminarily, the Regulation directs data protection regulators at all levels — Member States, supervisory authorities, the European Data Protection Board, and the Commission — to encourage development of codes of conduct to assist with the GDPR's "proper application." -These codes may be created by the regulators themselves, but the GDPR expressly authorizes "associations or other bodies representing controllers or processors" to draw up codes of conduct or amend existing ones to implement the GDPR's particular requirements. Such codes should address, among other things: • Fair and transparent processing. • The legitimate interests pursued by controllers in specific contexts. • The collection of personal data. • The pseudonymisation of personal data. • The information provided to the public and to data subjects. • The exercise of the rights of data subjects. • Information provided to and the protection of children and the manner in which the consent of the holders of parental responsibility over children is to be obtained. • General data protection obligations of data controllers, including privacy by design and measures to ensure security of processing. • Notification of personal data breaches to supervisory authorities and communication of such personal data breaches to data subjects. • Transfer of personal data to third countries or international organizations. • Out-of-court proceedings and other dispute resolution procedures for resolving disputes between controllers and data subjects with regard to the processing, without prejudice to the rights of data subjects. -When private associations prepare codes of conduct or amend existing ones for the purposes of allowing members to indicate GDPR compliance, Recital 99 encourages them to "consult relevant stakeholders, including data subjects where feasible, and have regard to submissions received and views expressed in response to such consultations." -A draft code must also be submitted to the appropriate supervisory authority to determine whether it provides "sufficient appropriate safeguards" (Article 40(5)). -When the draft code relates to processing activities in several Member States, the supervisory authority must, before approval, submit it to the European Data Protection Board for an opinion as to the code's compliance with the Regulation. Thereafter, the European Commission must review it. -Approved codes of conduct will receive publicity from the Commission, and be published in a register created and maintained by the Board. Up to this point, the procedures in the GDPR are relatively consistent with those of the Directive, which also encouraged preparation and approval of codes of conduct, although the Directive empowered the Article 29 Working Party to approve EU-wide codes.

Lower Fine Threshold

Fines in the lower tier are assessed on controllers, processors, certification bodies or monitoring bodies. Violations of most other provisions are subject to the lower fine tiers or penalties. There are some notable obligations that are specifically subject to the lower fines. Obligations of controllers and processors include: • Obtaining a child's consent according to the applicable conditions in relation to information society services (Article 8). • Notifying the supervisory authority of a personal data breach (Article 33). • Notifying the data subject of a personal data breach (Article 34). • Designating a data protection officer (and the data protection officer has related obligations to their position) (Articles 37-39). There are also obligations of certification bodies (Articles 42, 43), and obligations of monitoring bodies (for monitoring of approved codes of conduct) to take appropriate action to enforce code violations (Article 41(4)).

Codes of Conduct and Certifications

-Confirming each data controller's or processor's compliance with the GDPR's many protections for data subjects would exceed the capacity of any regulator. The GDPR therefore endorses the use of codes of conduct and certifications to provide guidance on the GDPR's requirements, signal to data subjects and regulators that an organization is in compliance with the Regulation, and offer third-party oversight as another check on controllers' and processors' data handling practices. -These tools are likely to feature prominently in company plans for legitimate cross-border data transfers. Should they prove effective, moreover, they may underlie global data transfer mechanisms — consistent with systems already used in the U.S. and under the Asia Pacific Economic Cooperative — and lower costs of privacy compliance worldwide. -Codes of conduct and certifications may both be used to demonstrate compliance, but there are subtle differences between them and how the GDPR envisions their deployment. Although codes of conduct were featured in the Directive, they played only a minor role compared to their prominence in the Regulation. -Certifications, moreover, are familiar to EU privacy and security regimes, but make their debut in the GDPR as a formal component of data protection regulation. -By officially recognizing these tools, the EU adopts a legal construct more familiar to U.S. privacy law, namely the notion that through regulatory enforcement mechanisms, companies may be held to keep binding promises made to non-governmental third parties. -Still, the GDPR maintains a heavy dose of regulatory oversight and guidance into these third-party managed programs, creating essentially a hybrid co-regulatory public/private system to develop a meaningful, binding and enforceable data protection regime that empowers data subjects, third-party administrators, and regulators alike.

Data breach harmonization

-Data breach notification law is possibly most mature in the U.S., relative to other nations and regions. There, "reasonable" security standards are still being defined and nearly every U.S. state has a different breach notification law, which has led to some consternation among privacy professionals. -The GDPR's uniform application across EU Member States should at least provide predictability and thus efficiencies to controllers and processors seeking to establish compliant data security regimes and breach notification procedures across the entirety of the 28 Member States. -Nonetheless, the GDPR's reference to a "competent supervisory authority" suggests notification may need to be made to more than one supervisory authority depending on the circumstances, and the ambiguity of a number of terms such as "undue delay," "likelihood of risk to rights and freedoms," and "disproportionate effort" all remain to be further clarified and defined in practice.

GDPR Fine Tiers

-The GDPR creates two tiers of maximum fines depending on whether the controller or processor committed any previous violations and the nature of violation. -The higher fine threshold is 4 percent of an undertaking's worldwide annual turnover or 20 million euros, whichever is higher. -The lower fine threshold fine is 2 percent of an undertaking's worldwide annual turnover or 10 million euros, whichever is higher. -These amounts are the maximum, meaning supervisory authorities are empowered to assess lower but not higher fines. Specifically, Recital 148 authorizes a DPA to issue a reprimand in place of a fine in cases of a minor infringement where the fine would constitute a disproportionate burden on a natural person. -Additionally, fines are not compounded for multiple violations arising from the same incident; the total fine cannot exceed the fine for the gravest violation. -When fines are imposed on a natural person, as opposed to a corporate controller or processor, their general income level and personal economic situation will inform the appropriate amount of fine.

What is pseudonymous data?

-The GDPR defines pseudonymization as "the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information." -To pseudonymize a data set, the "additional information" must be "kept separately and ... subject to technical and organizational measures to ensure that the personal data are not attributed to an identified or identifiable person." -In sum, it is a privacy-enhancing technique where directly identifying data is held separately and securely from processed data to ensure nonattribution. -Although Recital 28 recognizes that pseudonymization "can reduce risks to the data subjects," it is not alone a sufficient technique to exempt data from the scope of the Regulation. -Indeed, Recital 26 states that "[p]ersonal data which have undergone pseudonymization, which could be attributed to a natural person by the use of additional information, should be considered to be information on an identifiable natural person" (i.e., personal data). -Thus, pseudonymization is "not intended to preclude any other measures of data protection" (Recital 28).

Security of data processing standards

-The GDPR separates responsibilities and duties of data controllers and processors, obligating controllers to engage only those processors that provide "sufficient guarantees to implement appropriate technical and organizational measures" to meet the GDPR's requirements and protect data subjects' rights. -Processors must also take all measures required by Article 32, which delineates the GDPR's "security of processing" standards. -Under Article 32, similarly to the Directive's Article 17, controllers and processors are required to "implement appropriate technical and organizational measures" taking into account "the state of the art and the costs of implementation" and "the nature, scope, context, and purposes of the processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons." -Unlike the Directive, however, the GDPR provides specific suggestions for what kinds of security actions might be considered "appropriate to the risk," including: • 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 organizational measures for ensuring the security of the processing. -Controllers and processors that adhere to either an approved code of conduct or an approved certification mechanism — as described in Article 40 and Article 42, respectively — may use these tools to demonstrate compliance with the GDPR's security standards.

'Pseudonymization' of Personal Data

-The concept of personally identifying information lies at the core of the GDPR. -Any "personal data," which is defined as "information relating to an identified or identifiable natural person ('data subject')," falls within the scope of the Regulation. -The Regulation does not apply, however, to data that "does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable" (Recital 26). -The GDPR introduces a new concept in European data protection law - "pseudonymization" - for a process rendering data neither anonymous nor directly identifying. -Pseudonymization is the separation of data from direct identifiers so that linkage to an identity is not possible without additional information that is held separately. Pseudonymization, therefore, may significantly reduce the risks associated with data processing, while also maintaining the data's utility. -For this reason, the GDPR creates incentives for controllers to pseudonymize the data that they collect. -Although pseudonymous data is not exempt from the Regulation altogether, the GDPR relaxes several requirements on controllers that use the technique.

The GDPR acknowledges that re-identification must be "reasonably likely"

-Under the Directive, the Article 29 Working Party found that "pseudonymization is not a method of anonymization" because some risks of re-identification remained, even if those risks were very small. -Thus, even when controllers deleted all identifying information and could not themselves reidentify a data set, the Working Party found that the data was still covered by the Directive if any third party could conceivably re-identify the data sometime in the future. -A controller could escape regulation only by not collecting identifying information in the first place. -In contrast, by focusing on whether re-identification is "reasonably likely," the GDPR may provide greater flexibility than the Directive. -For example, where the controller deletes the identification key and the remaining indirect identifiers pose little risk of identifying an individual, the controller may be able to argue that there is no reasonable risk of re-identification. -Recital 57 addresses this situation in relation to the data subject's right to access personal data held by the controller. -In cases where "the personal data processed by the controller do not permit the controller to identify a natural person, the data controller should not be obliged to acquire additional information in order to identify the data subject for the sole purposes of complying with any provision of this Regulation."

Controllers do not need to provide data subjects with access, rectification, erasure or data portability if they can no longer identify a data subject.

Controllers may employ methods of pseudonymization that prevent it from being able to reidentify a data subject. -For example, if a controller deletes the directly identifying data rather than holding it separately, it may not be capable of re-identifying the data without collecting additional information. -Article 11 acknowledges this situation and provides an exemption from the rights to access, rectification, erasure and data portability outlined in Articles 15 through 20. -The exemption applies only if "the controller is able to demonstrate that it is not in a position to identify the data subject" and, if possible, it provides notice of these practices to data subjects. -The GDPR does not require a controller to hold additional information "for the sole purpose of complying with this Regulation." -If, however, a data subject provides the controller with additional information that allows her to be identified in the data set, she must be permitted to exercise her rights under Articles 15 through 20.

GDPR requires explicit consent for special categories of personal data

GDPR Article 9 requires a higher level of consent - "explicit" consent - for the processing of "special categories of personal data." -These special categories relate to personal data that are "particularly sensitive in relation to fundamental rights and freedoms" and, therefore, "merit specific protection." -They include data "revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade-union membership, and the processing of genetic data, biometric data for the purpose of uniquely identifying a natural person, data concerning health or data concerning a natural person's sex life or sexual orientation." -The standard for explicit consent likely remains the same as under Directive 95/46/EC, which also required controllers to obtain explicit consent for processing special categories of personal data. -Under the Directive, the Article 29 Working Party defined explicit consent as "all situations where individuals are presented with a proposal to agree or disagree to a particular use or disclosure of their personal information and they respond actively to the question, orally or in writing." Thus, a user's conduct or choice of browser settings probably will not be sufficient to meet this high bar. -The GDPR also allows Member States to enact laws that restrict the processing of some categories of data even if the data subject explicitly consents. -The only distinction between the Directive and the GDPR on this issue is that the GDPR expands the definition of sensitive data to include genetic data, biometric data (in some cases), and data concerning sexual orientation. -Genetic data is defined, under Article 4, as "personal data relating to the inherited or acquired genetic characteristics of a natural person which give unique information about the physiology or the health of that natural person and which result, in particular, from an analysis of a biological sample from the natural person in question." -Biometric data is personal data that identifies an individual based on the "specif c technical processing" of the individual's physical or behavioral characteristics. Recital 51 notes that photographs will qualify as biometric data only when they are processed "through a specific technical means allowing the unique identification or authentication of a natural person."

GDPR requires parental consent for processing children's personal data

In Article 8, the GDPR introduces specific protections for children by limiting their ability to consent to data processing without parental authorization. -Previous drafts of the Regulation set the age of consent at 13 years old, which would have been consistent with the age of consent set by the Children's Online Privacy Protection Act (COPPA) in the U.S. However, a last-minute proposal aimed to raise the age of consent to 16 years old. After the last round of trilogue negotiations, the final draft opted for the age of consent to be set at 16 years, but it allows Member States to set a lower age not below 13 years. Thus, unless otherwise provided by Member State law, controllers must obtain the consent of a parent or guardian when processing the personal data of a child under the age of 16. -They also must make "reasonable efforts" to verify that a parent or guardian has provided the appropriate consent. -Differing rules on the age of consent in EU Member States, as well as between the EU standard and the COPPA age 13 rule applicable in the U.S., could create significant challenges for companies that offer international services. -It is unclear whether Member States will act together on this issue. At this time, at least one Member State, the U.K., has vowed to lower its age of consent to 13.

In what situations are codes of conduct useful?

The GDPR more actively than the Directive incorporates codes of conduct into its compliance and enforcement mechanisms. -These codes seem particularly well suited to setting forth and then demonstrating compliance with security risks associated with data processing. -Recital 77 encourages use of approved codes of conduct by both controllers and processors. These codes may demonstrate that a controller or processor has identified any risk related to data processing; assessed the origin, nature, likelihood, and severity of the risk; and determined how best to mitigate the risk. -Article 32 expressly acknowledges adherence to an approved code of conduct as one means for demonstrating compliance with the Regulation's data security obligations. -Article 24, which sets forth the controller's primary responsibilities with regard to processing personal data, also encourages codes of conduct to demonstrate GDPR compliance. -Article 28 and Recital 81, moreover, expressly provide that a processor's adherence to an approved code of conduct is "an element to demonstrate compliance" with the controller's obligations. -Processors eager to keep controllers as clients will therefore soon be in the market to join associations maintaining a GDPR-approved code of conduct. -Adherence to these codes can create market efficiencies. The association creating them conducts extensive reviews of any applicant seeking membership or otherwise desiring to claim compliance with the code. This saves a controller, for example, from having to conduct its own review of a potential data processor's systems. The controller can simply shop for processors who are already deemed to satisfy the code's requirements, and rely on the association to police the processor's compliance.

Cross-border Data Transfers: Adequacy and Beyond

The GDPR permits personal data transfers outside of the EU subject to compliance with set conditions, including conditions for onward transfer. Similar to the framework set forth in the Directive, the GDPR allows for data transfers to countries whose legal regime is deemed by the European Commission to provide for an "adequate" level of personal data protection. In the absence of an adequacy decision, however, transfers are also allowed outside non-EU states under certain circumstances, such as by use of standard contractual clauses or binding corporate rules (BCRs). Derogations are also permitted under limited additional circumstances. Important distinctions between the GDPR and the Directive bear noting, however. In particular, the GDPR explicitly acknowledges as valid the current requirements for BCRs for controllers and processors, which will be helpful for data transfers involving those Member States that do not as yet recognize BCRs. Standard contractual clauses, which prior to the GDPR required prior notice to and approval by data protection authorities, may now be used without such prior approval. Further, a newly introduced scheme in Article 42 allows for transfers based upon certifications, provided that binding and enforceable commitments are made by the controller or processor to apply the appropriate safeguards. In addition to facilitating international data transfers through new mechanisms, the GDPR also makes clear that it is not lawful to transfer personal data out of the EU in response to a legal requirement from a third country. It also imposes hefty monetary fines for transfers in violation of the Regulation.

Pseudonymization may facilitate processing personal data beyond original collection purposes.

The GDPR requires controllers to collect data only for "specific, explicit and legitimate purposes." -Article 5 provides an exception to the purpose limitation principle, however, where data is further processed in a way that is "compatible" with the initial purposes for collection. -Whether further processing is compatible depends on several factors outlined in Article 6(4), including the link between the processing activities, the context of the collection, the nature of the data, and the possible consequences for the data subject. -An additional factor to consider is "the existence of appropriate safeguards, which may include encryption or pseudonymization" (Article 6(4)(e)). -Thus, the GDPR allows controllers who pseudonymize personal data more leeway to process the data for a different purpose than the one for which they were collected.

How is code of conduct compliance enforced and what are the consequences of non-compliance?

The GDPR's key breakthrough with regard to codes of conduct is the notion that they can be made binding and enforceable — rather than merely voluntary and self-regulatory. -This is somewhat analogous to how the Federal Trade Commission (FTC) has viewed third party codes of conduct in the United States, such as adherence by online advertisers to the Network Advertising Alliance (NAI) principles. The FTC, pursuant to its authority under Section 5 of the Federal Trade Commission Act, can bring a deception action against a company that self-certifies under the NAI code but fails to comply. -For example, the FTC pursued Google for allegedly misrepresenting its compliance with NAI's code in the "Google Safari Hack" case. The case ultimately resulted in a $22.5 million settlement. The NAI may also refer its members to the FTC if they are in noncompliance with the NAI's codes. -The GDPR similarly requires that approved codes of conduct must enable "the mandatory monitoring of compliance with its provisions." -The monitoring body must be accredited by the competent supervisory authority, after demonstrating "an appropriate level of expertise in relation to the subject-matter of the code." Accreditation is available if the body (a) demonstrates "its independence and expertise in relation to the subject-matter of the code to the satisfaction of the competent supervisory authority"; (b) "has established procedures which allow it to assess the eligibility of controllers and processors concerned to apply the code, to monitor their compliance with its provisions and to periodically review its operation"; (c) has "established procedures and structures to deal with complaints about infringements of the code or the manner in which the code has been, or is being, implemented by a controller or processor, and to make those procedures and structures transparent to data subjects and the public"; and (d) demonstrates "to the satisfaction of the competent supervisory authority that its tasks and duties do not result in a conflict of interests"(Article 41)(2). -The accredited body shall "take appropriate action" when a controller or processor "infringes" the code of conduct, including suspending or excluding the infringing party from the code. -Thereafter the supervising authority must be notified of the infringement proceeding. -Enforcement by the accredited body is "without prejudice to the tasks and powers of the supervisory authority." -When the accredited body or supervisory authority enforces code of conduct infringement, the enforcer's interpretation—and not the drafter's—will prevail. -Controllers and processors adhering to an association's code therefore face a risk that the association's approval doesn't guarantee regulatory compliance. NAI, for example, did not bring an enforcement action against Google for violating its standards even though the FTC did. -Membership in an association with an enforceable code of conduct may also generate a one-size-fits-all system not compatible with the GDPR's aims. For instance, the European Interactive Digital Advertising Alliance allows consumers to click on an icon used by EDAA members and manage their controls for all EDAA members at once. This may allow broader opt-in features than the GDPR approves. Then again it may conveniently suit a data subject's preferences and foster efficiency. -A supervisory authority can weigh code of conduct adherence in assessing the amount of an administrative fine. Article 83(2)(j) suggests compliance with a code of conduct is a mitigating factor, allowing for a lower penalty. Conceivably, however, non-compliance could be an aggravating one. -Pursuant to Article 83(4)(c), moreover, an accredited monitoring body faces fines up to 10,000,000 EUR for failing to "take appropriate action" when a controller or processor infringes a code of conduct.

GDPR incentives for controllers to pseudonymize data

The Regulation recognizes the ability of pseudonymization to help protect the rights of individuals while also enabling data utility. -Recital 29 emphasizes the GDPR's aim "to create incentives to apply pseudonymization when processing personal data" and finds that "measures of pseudonymization should, whilst allowing general analysis, be possible". -These incentives appear in five separate sections of the Regulation.

DPO's Tasks

The data protection officer's tasks are also delineated in Article 39 of the Regulation to include: • Informing and advising the controller or processor and its employees of their obligations to comply with the GDPR and other data protection laws. • Monitoring compliance with the GDPR and other data protection laws, including managing internal data protection activities, training data processing staff, and conducting internal audits. • Advising with regard to data protection impact assessments when required under Article 35. • Working and cooperating with the controller's or processor's designated supervisory authority and serving as the contact point for the supervisory authority on issues relating to the processing of personal data. • Being available for inquiries from data subjects on issues relating to data protection practices, withdrawal of consent, the right to be forgotten, and related rights.

DPO's Rights

Under the Regulation, moreover, data protection officers have many rights in addition to their responsibilities. -They may insist upon company resources to fulfill their job functions and for their own ongoing training. -They must have access to the company's data processing personnel and operations, significant independence in the performance of their roles, and a direct reporting line "to the highest management level" of the company. -Data protection officers are expressly granted significant independence in their job functions and may perform other tasks and duties provided these do not create conflicts of interest. -Job security is another perk; the GDPR expressly prevents dismissal or penalty of the data protection officer for performance of her tasks and places no limitation on the length of this tenure.

The Mandatory DPO

- Under Article 37, data protection officers must be appointed for all public authorities, and where the core activities of the controller or the processor involve "regular and systematic monitoring of data subjects on a large scale" or where the entity conducts large — scale processing of "special categories of data" (such as that revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, and the like, defined in Article 9). -Number of employees does not matter under GDPR -DPO must have "expert knowledge of data protection law and practices."

Data Subject Consent

-Consent remains a lawful basis to transfer personal data under the GDPR; however, the definition of consent is significantly restricted. -Where Directive 95/46/EC allowed controllers to rely on implicit and "opt-out" consent in some circumstances, the GDPR requires the data subject to signal agreement by "a statement or a clear affirmative action." -The new law maintains the distinct requirements for processing "special categories of personal data" that were present in the Directive, but it expands the range of what is included in those special categories. -Finally, the GDPR introduces restrictions on the ability of children to consent to data processing without parental authorization.

Pseudonymous data is not anonymous

Much debate surrounds the extent to which pseudonymized data can be reidentified. This issue is of critical importance because it determines whether a processing operation will be subject to the provisions of the Regulation. -The GDPR adopts a more flexible approach than the traditional binary of the Data Protection Directive, focusing on the risk that data will reveal identifiable individuals. -Thus, the key distinction between pseudonymous data, which is regulated by the GDPR, and anonymous data, which is not, is whether the data can be reidentified with reasonable effort. -To illustrate the concept of reidentification risk, it is important to distinguish between direct and indirect identifiers. -The International Organization for Standardization (ISO) defines direct identifiers as "data that can be used to identify a person without additional information or with cross-linking through other information that is in the public domain." They are data points that correspond directly to a person's identity, such as a name, national ID number or contact information. -Indirect identifiers are data that do not identify an individual in isolation but may reveal individual identities if combined with additional data points. -For example, one frequently cited study found that 87 percent of Americans can be uniquely identified by combining three indirect identifiers: date of birth, gender and postal code. In other words, while no individual can be singled out based on just a date of birth, when combined with gender and postal code, the lens focuses on a specific identity. - Pseudonymization involves removing or obscuring direct identifiers and, in some cases, certain indirect identifiers that could combine to reveal a person's identity. These data points are then held in a separate database that could be linked to the de-identified database through the use of a key, such as a random identification number or some other pseudonym. -As a result of this process, pseudonymized data, unlike anonymous data, faces the risk of reidentification in two ways. First, a data breach may permit an attacker to obtain the key or otherwise link the pseudonymized data set to individual identities. Alternatively, even if the key is not revealed, a malicious actor may be able to identify individuals by combining indirect identifiers in the pseudonymous database with other available information. -The GDPR addresses the first concern in Recital 75, which instructs controllers to implement appropriate safeguards to prevent the "unauthorized reversal of pseudonymization." -To mitigate the risk, controllers should have in place appropriate technical (e.g., encryption, hashing or tokenization) and organizational (e.g., agreements, policies, privacy by design) measures separating pseudonymous data from an identification key. -In Recital 26, the GDPR recognizes the second type of reidentification risk by considering whether a method of reidentification is "reasonably likely to be used, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly." -Such an analysis is necessarily contextual and "account should be taken of all objective factors, such as the costs of and the amount of time required for identifcation, taking into consideration the available technology at the time of the processing and technological developments."

Pseudonymization is an important safeguard for processing personal data for scientific, historical and statistical purposes.

The GDPR also provides an exception to the purpose limitation principle for data processing for scientific, historical and statistical research. -However, Article 89(1) requires controllers that process data for these purposes to implement "appropriate safeguards, in accordance with this Regulation, for the rights and freedoms of the data subject." -Specifically, controllers must adopt "technical and organizational measures" to adhere to the data minimization principle. -The only example the Regulation provides is for controllers to use pseudonymization so that the processing "does not permit or no longer permits the identification of data subjects."

Cross-border data transfers

-Approved codes of conduct will also facilitate cross-border data transfers. Controllers or processors that are not otherwise subject to the GDPR may demonstrate, by adhering to a code of conduct, that they provide appropriate safeguards for personal data transfers to third countries or international organizations. -Under Article 46(2)(e), appropriate safeguards for a controller or processor based outside the EU may include adhering to an approved code of conduct pursuant to Article 30 "together with" making a "binding and enforceable commitment" to comply with the GDPR and respect data subjects' rights. -The GDPR references the "binding and enforceable" nature of codes of conduct only regarding their use for cross-border transfers. The Regulation does not elaborate, but the analog to this situation is of course binding corporate rules. -Controllers adopting BCRs must demonstrate their "bindingness" by creating internal compliance obligations for subsidiaries and employees, establishing third-party beneficiary rights for data subjects, accepting liability and submitting to DPA jurisdiction, and confirming sufficient assets to pay damages for a breach.

In what situations are certifications useful?

-Certifications assist controllers and processors in all the situations codes of conduct do, but in addition certifications — but not codes of conduct — may also be used to demonstrate compliance with Article 25, which governs data protection by design and by default. -According to Article 25(1), data controllers are obliged to implement "appropriate technical and organisational measures, such as pseudonymisation" designed to "integrate the necessary safeguards into the processing in order to meet the requirements of this Regulation and protect the rights of data subjects." -Under Article 25(2), a controller "shall implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed." -Approved certification mechanisms may be used to demonstrate compliance with both of these provisions.

Other Consent Provisions

-Consent features in a variety of other sections of the Regulation. For example, under the right to erasure, in Article 17, the data subject has the right to have the controller erase her data if she withdraws consent and the processing had been based on her consent. -Under Article 18, where the data subject exercises her right to restrict data processing, the controller may only continue to process the data if it obtains the data subject's consent or if processing is necessary for a legal claim. -Article 20 grants the data subject the right to receive all the personal data about her in the controller's possession where the processing is based on her consent. In these circumstances, the required level of consent is "unambiguous" consent. -The GDPR requires the data subject's explicit consent in two other circumstances. -Under Article 22, controllers need to obtain explicit consent to make decisions about the data subject "based solely on automated processing, including profiling," when the processing produces legal effects or "similarly significantly affects" the data subject. -Controllers also must seek explicit consent, under Article 49, to authorize transfers of personal data to countries that do not provide an adequate level of protection, if no other transfer mechanism is in place.

Complex Administrative Procedures and Hefty Fines

-The GDPR empowers supervisory authorities to assess fines that are "effective, proportionate and dissuasive." It sets forth both mitigating and aggravating factors to help DPAs assess the amount of a fine. -For example, intentional violations are worse than negligent ones. -Mitigating factors include adherence to a code of conduct or certification mechanisms, minimizing the use of sensitive categories of data, and employing appropriate technical and organizational safeguards. -In the event of non-compliance, moreover, controllers and processors may limit their exposure by mitigating "the damaging nature, gravity and duration of the violation," reporting the violation as soon as possible, and cooperating with the supervisory authority. -Aggravating factors generally include the opposite actions — not seeking to mitigate harm or acting contrary to the mitigating factors.

The GDPR encourages controllers to adopt codes of conduct that promote pseudonymization.

The GDPR encourages controllers to adopt codes of conduct that are approved by the Member States, the supervisory authorities, the European Data Protection Board or the Commission. -Among other provisions outlined in Article 40, these codes of conduct should promote the use of pseudonymization as a way to comply with the Regulation (Article 40(2)(d)). -As further explored in Chapter 9, using codes of conduct allows controllers and processors to demonstrate adherence to the principles of the Regulation, and they may even be used as a mechanism for transferring personal data to third countries.

Affirmative consent for data processing

Under the GDPR, consent must be "freely given, specific, informed and unambiguous." There was uncertainty leading up to this final draft whether the EU would settle on "unambiguous" consent as required by the Directive, or the higher standard of "explicit" consent. The final draft has staked out a middle position, on the one hand opting for unambiguous consent, while on the other hand requiring such consent to be expressed "by a statement or by a clear affirmative action." -Recital 32 clarifies that an affirmative action signaling consent may include ticking a box on a website, "choosing technical settings for information society services," or "another statement or conduct" that clearly indicates assent to the processing. -"Silence, pre-ticked boxes or inactivity," however, is presumed inadequate to confer consent. -The GDPR, therefore, creates additional hurdles for consent over what was required by the Directive. -As interpreted by the Article 29 Working Party's Opinion 15/2011 on the definition of consent, the Directive required the controller to provide "accurate and full information on all relevant issues," including the nature of the data that will be processed, the purposes of processing, the identity of the controller, and the identity of any other recipients of the data. Consent had to be specific to the processing operations and the controller could not request open-ended or blanket consent to cover future processing. -Significantly, while consent could be satisfied by an express statement, it also could be inferred from an action or inaction in circumstances where the action or inaction clearly signified consent. Thus, the Directive left open the possibility of "opt-out" consent. -The GDPR removes that possibility by requiring the data subject to make a statement or clear affirmative action. -In particular, the GDPR includes three additional requirements: First, Article 7(3) of the GDPR gives data subjects the right to withdraw consent at any time and "it shall be as easy to withdraw consent as to give it." Controllers must inform data subjects of the right to withdraw before consent is given. Once consent is withdrawn, data subjects have the right to have their personal data erased and no longer used for processing. Second, in Recital 43, the GDPR adds a presumption that consent is not freely given if there is "a clear imbalance between the data subject and the controller, in particular where the controller is a public authority." Importantly, a controller may not make a service conditional upon consent, unless the processing is necessary for the service. Third, the GDPR adds that consent must be specific to each data processing operation. To meet the specificity requirement under Article 7, a request for consent to data processing must be "clearly distinguishable" from any other matters in a written document, and it must be provided "in an intelligible and easily accessible form, using clear and plain language." However, the law exempts controllers from obtaining consent for subsequent processing operations if the operations are "compatible." Recital 50 states that compatibility is determined by looking at factors including the link between the processing purposes, the reasonable expectations of the data subject, the nature and consequences of further processing, and the existence of appropriate safeguards for the data. Under Article 5(1)(b), additional processing for archiving in the public interest (as defined by the Member State), statistical purposes, or scientific and historical research generally will be considered compatible, and, therefore, exempt from specif c consent. These exceptions are potentially quite broad. Where they apply, under Article 89 controllers will not have to erase or rectify data after the data subject has withdrawn consent. The exceptions also impact restrictions on processing, data portability and the data subject's rights to object to and to be notified of processing operations. (The broader contours of these exceptions are discussed in an article on "How GDPR changes the rules for research.") -Although the GDPR removes the possibility of "opt-out" consent by forbidding silence, inactivity, and pre-ticked boxes as a means of providing consent, Recital 32 states that the data subject may consent by "choosing technical settings for information society services." It remains to be seen how this provision will be interpreted, but the language may leave intact the provisions of the e-Privacy Directive relating to cookies and other tracking technologies. Specifically, Article 5(3) of that Directive states that, generally, a data subject must provide specific, informed consent to the use of cookies or comparable tracking technology. However, Recital 66 provides an exception where cookies are "strictly necessary for the legitimate purpose of enabling the use of a specif c service requested by the subscriber or user." It also provides that "the user's consent to processing may be expressed by using the appropriate settings of a browser or other application." Under the Article 29 Working Party's interpretation of this provision, the browser settings exception applies only if the browser's default rejects the placement of cookies, thereby requiring the user to actively opt-in to receiving cookies. This interpretation may accord with the GDPR's language requiring "a clear affirmative action." -Whenever a controller relies on consent as a basis for processing, under Article 7(1), the controller bears the burden of demonstrating that consent was obtained lawfully according to the principles above.

What are certifications under the GDPR?

Certifications are a new feature of formal EU data protection law. -Unlike the Directive, the GDPR expressly recognizes certifications (as well as seals and marks) as acceptable mechanisms for demonstrating compliance. -For years, certification marks and seals have served as useful signals for consumers interested in engaging with commercial entities that adhere to certain desirable principles or follow particular manufacturing, harvesting, or sourcing practices. In the food and beverage sector, for example, certifications may indicate "fair trade" or "GMO-free." -In privacy, the EuroPriSe seal has been the principal European certification under the Directive. -It aims to foster consumer trust in information-technology tools and services. Manufacturers and vendors of IT products and services undergo independent evaluation of their data privacy and security practices, following which they are eligible to display the EuroPriSe seal for two years before they must re-apply. -In the United States, TRUSTe provides one example of enterprise-level certification. TRUSTe offers compliance assessments with not only U.S. law but also the Directive, and has provided assistance with "Safe Harbor" self-certification with the U.S. Department of Commerce. It also offers APEC certification. -The GDPR provides, in Article 42, that Member States, supervisory authorities, the Board, and the Commission shall all "encourage, in particular at Union level, the establishment of data protection certification mechanisms and of data protection seals and marks, for the purpose of demonstrating compliance with this Regulation of processing operations by controllers and processors." -Controllers and processors outside the EU engaging in international personal data transfers may also use such certifications, seals or marks to demonstrate GDPR compliance. -As with codes of conduct, non-EU controllers and processors must also make "binding and enforceable commitments, via contractual or other legally binding instruments, to apply those appropriate safeguards, including as regards data subjects' rights." -This is reinforced under Article 46(2)(f), which provides that compliant cross-border data transfers may involve an approved certification mechanism but must also involve binding and enforceable commitments "in the third country." -Certifications "shall be voluntary and available via a process that is transparent," and do not serve to "reduce the responsibility of the controller or the processor for compliance" with the GDPR. -Certifications may be issued by either an accredited certification body, "the competent supervisory authority" on the basis of criteria it establishes, or by the Board, which may create a "common certification — the European Data Protection Seal." -It will be interesting to see whether controllers and processors favor government-sponsored certifications over private ones. -Accreditation is available to a certification body under Article 43 only if it: (a) demonstrates its "independence and expertise in relation to the subject-matter of the certification to the satisfaction of the competent supervisory authority"; (b) undertakes "to respect the criteria referred to in Article 42(5) and approved by the supervisory authority which is competent pursuant to Article 55 or 56 or by the Board pursuant to Article 63"; (c) establishes "procedures for the issuing, periodic review and withdrawal of data protection certification, seals and marks"; (d) establishes "procedures and structures to handle complaints about infringements of the certification or the manner in which the certification has been, or is being, implemented by the controller or processor, and to make those procedures and structures transparent to data subjects and the public"; and (e) demonstrates "to the satisfaction of the competent supervisory authority that [its] tasks and duties do not result in a conflict of interests." -Accreditation is good for up to five years and may be renewed if the accrediting body maintains compliance with these standards. -Accrediting authority is granted at multiple regulatory levels. Supervisory authorities may create standards, and grant and withdraw accreditation, for certification bodies within their territories. -The Board is also empowered to accredit certification bodies and maintain a register of accredited bodies. -When a certification body, supervisory authority, or Board award certification, it lasts for no more than three years at which time it may be renewed if the conditions and requirements are still met. -Certification shall be withdrawn by the issuing body where the controller or processor no longer meets the requirements. -The GDPR directs the Board to "collect all certification mechanisms and data protection seals and marks in a register and ... make them publicly available through any appropriate means."

How is compliance with a certification enforced, and what are the consequences of non-compliance?

-An accredited certification body is responsible for "proper assessment" leading to granting certification, and likewise leading to its withdrawal in the event of noncompliance. -The body must inform the supervisory authority, and provide reasons, when it grants or withdraws certification from a controller or processor. -As with codes of conduct, award of certification by an accredited body is a factor to be considered in assessing an administrative fine. Article 83(2)(j) suggests certification adherence is a mitigating factor useful to limiting such fines. -Accredited certification bodies that violate their duties under the GDPR are subject to penalties up to 10,000,000 EUR.

Certifications - Looking forward

-The GDPR's adoption of codes of conduct and certification mechanisms is a welcome development for controllers and processors seeking efficient means for compliance. There are of course upfront administrative burdens of establishing and maintaining compliance with a code of conduct or earning certification status. But these costs are offset by the ease of funding compliant processors, for example, via screening for those adhering to a code or displaying a certification seal. -The codes and certifications also may serve as marketing tools, allowing data subjects to choose controllers signaling GDPR compliance via their membership in associations or their certified status. -They also will likely play a significant role in facilitating cross-border data transfers. -The GDPR's code of conduct and certification mechanisms create business opportunities for new third-party administrators to establish membership associations or become accredited certification or enforcement bodies. They also represent acknowledgment that such third-party programs can be effective means for establishing binding promises by controllers and processors that regulators can enforce, consistent with regimes familiar to those operating in the U.S. or under the APEC privacy framework. -Globally consistent and familiar privacy regimes could ultimately improve the ease of legal compliance and in so doing lower compliance costs.

Joint DPO's

A company with multiple subsidiaries (a "group of undertakings") may appoint a single data protection officer so long as she is "easily accessible from each establishment." The GDPR also allows the data protection officer functions to be performed by either an employee of the controller or processor or by a third-party service provider, creating opportunities for consulting and legal firms to offer outside DPO services.

Data Security and Breach Notification Standards

Compared to Directive 95/46/EC, the GDPR imposes stricter obligations on data processors and controllers with regard to data security while simultaneously offering more guidance on appropriate security standards. The GDPR also adopts for the first time specific breach notification guidelines.

Higher Fine Threshold

Fines in the higher threshold are assessed for more serious violations by controllers and processors, such as the violation of a data subject's rights. Specifically, higher fines are assessed for violating, • Basic principles for processing data, including consent (Articles 5-7, 9). • Data subjects' rights (Articles 12-22). • Data transfer provisions (Articles 44-49). • Obligations to Member State laws including the right to freedom of expression and information, collection and use of national identification numbers, employment processing, secrecy obligations, and data protection rules for churches and religious associations. (Chapter IX). • Non-compliance with an order or a temporary or definitive limitation on processing or suspension of data flows by a supervisory authority (Articles 58(1), 58(2)).

Pseudonymization is a central feature of "data protection by design."

The GDPR for the first time introduces the concept of "data protection by design" into formal legislation. -At the conceptual level, data protection by design means that privacy should be a feature of the development of a product, rather than something that is tacked on later. Thus, Article 25(1) requires controllers to implement appropriate safeguards "both at the time of the determination of the means for processing and at the time of the processing itself." -One way that controllers can do this is by pseudonymizing personal data.

Controllers can use pseudonymization to help meet the GDPR's data security requirements.

Under Article 32, controllers are required to implement risk-based measures for protecting data security. -One such measure is the "pseudonymization and encryption of personal data" (Article 32(1)(a)). -The use of pseudonymization potentially has profound implications under this provision. -Controllers are required to notify a data protection authority any time there is a security incident that presents "a risk to the rights and freedoms of natural persons" (Article 33(1)). -They must, moreover, notify the concerned individuals anytime that risk is "high" (Article 34(1)). -Since pseudonymization reduces the risk of harm to data subjects, controllers that use it may be able to avoid notification of security incidents.

"Personal data breach" notification standards

Unlike the Directive, which was silent on the issue of data breach, the GDPR contains a definition of "personal data breach," and notification requirements to both the supervisory authority and affected data subjects. -"Personal data" is defined in both the Directive and the GDPR as "any information relating to an identified or identifiable natural person ('data subject')." -Under the GDPR, a "personal data breach" is "a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed." -This broad definition differs from that of most U.S. state data breach laws, for example, which typically are triggered only upon exposure of information that can lead to fraud or identity theft, such as financial account information. -In the event of a personal data breach, data controllers must notify the supervisory authority "competent in accordance with Article 55," which is most likely (looking to Article 56(1)) the supervisory authority of the Member State where the controller has its main establishment or only establishment, although this is not entirely clear. -Notice must be provided "without undue delay and, where feasible, not later than 72 hours after having become aware of it." If notification is not made within 72 hours, the controller must provide a "reasoned justification" for the delay Article 33(1) contains a key exception to the supervisory authority notification requirement: Notice is not required if "the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons," a phrase that will no doubt offer data protection officers and their outside counsel opportunities to debate the necessity of notification. A notification to the authority must "at least": (1) describe the nature of the personal data breach, including the number and categories of data subjects and personal data records affected; (2) provide the data protection officer's contact information; (3) "describe the likely consequences of the personal data breach"; and (4) describe how the controller proposes to address the breach, including any mitigation efforts. If not all information is available at once, it may be provided in phases. -When a data processor experiences a personal data breach, it must notify the controller but otherwise has no other notification or reporting obligation under the GDPR. -If the controller has determined that the personal data breach "is likely to result in a high risk to the rights and freedoms of natural persons," it must also communicate information regarding the personal data breach to the affected data subjects. Under Article 34, this must be done "without undue delay." -The GDPR provides exceptions to this additional requirement to notify data subjects in the following circumstances: (1) the controller has "implemented appropriate technical and organizational protection measures" that "render the personal data unintelligible to any person who is not authorized to access it, such as encryption"; (2) the controller takes actions subsequent to the personal data breach to "ensure that the high risk to the rights and freedoms of data subjects" is unlikely to materialize; or (3) when notification to each data subject would "involve disproportionate effort," in which case alternative communication measures may be used. Assuming the controller has notified the appropriate supervisory authority (commonly known as a "data protection authority" or DPA) of a personal data breach, its discretion to notify data subjects is limited by the DPA's ability, under Article 34(4), to require notification or conversely to determine it is unnecessary under the circumstances.