This GDPR training is provided free for use. Haekka offers a fully integrated training platform in Slack, enabling customers to meet their compliance, privacy, and security training requirements using modern, relevant content delivered 100% in Slack.

Introduction to GDPR

GDPR is a newer regulation that went into effect in 2018. The regulations themselves were written in 2016 so companies had plenty of time to prepare. The goal of GDPR is to protect the personal data of European citizens.

GDPR stands for the General Data Protection Regulation. It governs the collection and use of personal data of EU citizens. It extends to all companies that collect and use EU citizen data, regardless of where those companies are from.

The regulation is extensive. 88% of companies reported having spent $1M to comply with GDPR. It has 99 articles, though most are not relevant to all employees of companies that comply with GDPR.

If we were to summarize GDPR, as a practical guide to thinking about GDPR, the following principles represent the very short version of the GDPR.

• Transparency in data practices. Companies need to be open and honest with the market, both in public documentation and readily available documentation when requested, about the collection and use of EU citizen data.
• Creation and maintenance of a privacy and security program (Security by Design and Default). Companies need to create a maintain a compliance program. If this is a new initiative for a company, it can be expensive and tedious.
• End user Data rights. GDPR grants all EU citizens the certain data rights, or data subject rights, including the right to data, right to be forgotten, right to change data.
• Breach notification. In order to comply with GDPR, organizations must notify users of breaches within 72 hours. This is not easy. It involves policies and workflows that have been tested and are ready to activate upon detection of a breach.
• Penalties. GDPR penalties can be up to 4% of global revenue for an organization. GDPR fines hit $63M in the first year after it went into effect.

Your users data is paramount (always but especially under GDPR) - understand how your company uses it and be responsive to user data requests

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Organizations Covered under GDPR

GDPR is strict in how it defines entity types. And those entity types determine how entities must comply with GDPR and interact with end users and their data.

GDPR defines two types of organizations:

1. Controller. This is an entity that engages directly with users and processes personal data of users.
2. Processor. This is an entity that processes personal data for a controller. This is inclusive of all the service and software companies that a Controller uses to carry out it's services.

Under GDPR, Controllers are the owners of end user data. When a Controller under GDPR works with a Processor, they extend obligations to the Processor through a data protection agreement. When a Processor works with another Processor, such as a cloud provider like Amazon, Google, or Microsoft, the Processor extends their own liability in a data protection agreement. Processors cannot use 3rd parties as Processors without express consent of the Controller.

As you can imagine, there are millions of Controllers. Most Controllers work with many different 3rd party organizations as Processors. Processors, increasingly reliant on technology partners, have many partners. Because of this chain of liability from Controllers to Processors to more Processors, it can become messy.

Know the entity type of your organization and the key 3rd parties to which your organization extends liability

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Agreements under GDPR - Data Protection Agreements (DPAs)

Now that we know there are two types of entities under GDPR, Controllers and their partner Processors, we can start to look at how GDPR mandates those relationships are governed. Article 28 in GDPR mandates agreements be put in place between Controllers and Processors. These agreements should have sufficient guarantees to implement appropriate technical and organisational measures to meet GDPR.

Article 28 highlights 8 necessary elements to be included in such agreements.

1. Explicit processing. Processor shall only process data in accordance with specific guidelines from the Controller. Any export or movement of data over sovereign boundaries by the Processor requires notification of the Controller.
2. Individual Responsibility. Individuals that process personal data need to be informed and commit to keeping data confidential.
3. Follow Article 32. Technical and organizational best practices for security need to be adopted and tested on a regular basis.
4. Partner Security. Extend commitments to privacy, availability, and security of data to all partners.
5. Assist in data subject requests. When and however possible, assist in data subject requests.
6. High risk DPIAs. When data protection impact assessment is deemed high risk, assist the controller to meet requirements of the supervising authority.
7. Deletion of data. Upon termination of services, delete data.
8. Audit assistance. Assist controller and auditors of controller with assessments.

If you are a Processors under GDPR, read and understand your DPAs to know what liability and commitments you have..

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Covered by GDPR

GDPR is concerned with the protection of personal data. Understanding what is personal data is important and, fortunately, straightforward under GDPR.

GDPR covers the definition of "personal data" in Article 4 of the regulation:

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

The list of potential identifiers under GDPR is short:

• name;
• identification number;
• location data; and
• an online identifier.

GDPR encourages the removal, or separation, of identifiers for personal data. These identifiers, through automated means, can be added back to data to make it identifiable.

GDPR does list special data categories of data that have specific rules for processing. These rules are detailed and beyond the chose of this training but the special categories are 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 shall be prohibited.

Another key principle of GDPR is data minimization. Article 5 states the the amount of personal data collected should be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed ('data minimisation'). The intent is only to collect the data that is absolutely necessary for the purpose of processing.

The best rule of thumb is to assume that your data contains personal data until proven otherwise.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Protection by Default and Design

One of the areas of GDPR that has gotten a lot of attention is the concept of Data Protection by Design and Default. This concept is outlined in outlined in Article 25 of GDPR.

The concept of data protection by default and design can be broken down into two areas.

1. Security by default. Paragraph 1 of Article 25 mandates that organizations implement the appropriate technical and organizational controls in order to meet the requirements of this Regulation and protect the rights of data subjects. This is the implementation requirement.
2. Privacy by default. Paragraph 2 of Article 25 mandates that organizations only collect, process, and store the personal information required for the specific purpose of processing.

There is overlap between the areas of privacy and security in how GDPR requires aspects of both. The overarching message is that organizations, in order to comply with GDPR, need to design a program to minimize data collection and processing to the minimum necessary data and then they need to implement security, both technical and organizational, to protect that minimum amount of data. These requirements are far reaching within an organization.

GDPR mandates privacy policies and procedures for personal data collection and security implementations to protect personal data.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Processing under GDPR

Data processing is the key function governed by GDPR. Simply put, processing personal data includes collecting, storing, and analyzing personal data.

Article 6 outlines what organizations are required to do before processing personal data. Aside from explicit consent from individuals, data processing is allowed under GDPR for legal obligations of the controller, to protect the vital interests of the data subject or another human, and for the public interest or for some official authority of the controller.

Article 29, 30, and 32 of GDPR detail the rules around data processing.

• Processing authority. No personal data can be processed without the explicit instructions from the controller.
• Records of data processing. Records of data processing are only required for organizations with 250 or more employees unless processing is likely to result in a risk to the rights and freedoms of data subjects. For all other organizations, records must be kept of processing activity. This record, which must be in written or electronic form, must contain certain elements such as types of processing, purpose of processing, any any relevant transfers of data to third parties.
• Security of processing. Article 32 is more explicit in mandating controllers and processors put technical and organizational controls in place. Example controls provided are:
• pseudonymisation (storing identifiers separately from the rest of personal data);
• encryption;
• ensure ongoing confidentiality, integrity, availability, and resilience of systems;
• ability to restore systems after an incident; and
• regular testing.
• The above rules about processing help add some teeth to the broader GDPR Articles.
• Only process data in ways approved by controller, implement best practice security, and test regularly.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Subject Rights under GDPR

Data subject rights are a huge part of GDPR. They grant end users, individuals, the right to perform certain actions on their data that is stored and processed by controllers and processors. Technically, controllers field data subject rights requests but processors are obligated to assist controllers with these requests.

• Right of access. Individuals can ask if organizations process personal data for the individual and, if the organization does process the individuals data, the individual can request their data, the purpose of the processing, and sources of data.
• Right to rectification. Individuals have the right to correct their personal data and make data complete incomplete personal data.
• Right to erasure. Also known as the right to be forgotten, individuals can request the deletion of their personal data and organizations must comply without "undue delay".
• Right to restrict processing. An individual can stop an organization from processing their personal data. In order to start processing said personal data again, the controller must notify the individual.
• Right to data portability. An individual can request their personal data in a structured, commonly used and machine-readable format . Where technically feasible, the individual can have data sent from one controller to another controller.
• Right to object. Individuals have a right to object to the processing of their personal data mostly based on the allowed conditions for processing outlined in Article 6.

Data subject rights are new under GDPR and organizations need to document and implement processes to ensure they are able to meet data subject requests.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Roles under GDPR

There is only explicitly defined role under GDPR - data protection officer (DPO). The role, duties, and requirements for the DPO are defined in Articles 37, 38, and 39.

Under GDPR, an organization must appoint a DPO if the organization is 1) a public body, 2) processing activities require regular monitoring of data subjects on a large scale, or 3) processing involves large scale of special categories of data. In practice, almost all organizations appoint a DPO and that DPO serves as the point person for GDPR related controls and practices.

The DPO can be a full time staff member at the organization or an external consultant. In any case, they are supposed to have some degree of autonomy and not be terminated for performing their responsibilities as a DPO.

The DPO has specific functions under GDPR as outlined in Article 39:

• Train those responsible for data processing about GDP;
• Monitor compliance with the GDPR rules;
• Provide input to data protection impact assessments;
• Cooperate, where necessary, with the supervising authority;
• Act as a contact point for matters related to GDPR; and
• Perform all duties using a risk-based framework.

Think of the DPO as the human interface between organizations and GDPR, both internally and externally.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Breaches and Security Incidents under GDPR

Data breaches and security incidents are often spoken of in the same context. While they are related, they are not the same. And the distinction between the two terms is very important.

• Security Incident is an event that puts corporate systems and data at risk. It is often, but not always, the result of not complying with security policies.
• A personal data breach is defined in Article 4 of GDPR to be "accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, personal data transmitted, stored or otherwise processed."

A security incident increases the risk of a personal data breach but it is not a data breach. An example might be a misconfigured server where a default account password might not have been changed. In order to determine if this security incident resulted in a data breach, an investigation must be conducted to assess if the vulnerable server account was used to gain unauthorized access to data on the server or accessible from the server.

As a best practice, every security incident and breach needs to be investigated, with the investigation and outcome well documented.

The big distinction between security incidents and data breaches under GDPR is in terms of notification requirements. GDPR has reporting requirements for the supervisory authority and the affected individual.

Personal data breaches must be reported to the supervisory authority within 72 hours. The data about the breach and remediation, can be shared in waves but the goal is to notify without "under delay".

Personal data breaches must be reported to the data subject without undue delay when the breach is likely to result in high risk to the data subject. In the case where the scale of the breach makes it unfeasible to contact each data subject, a public announcement can be done.

Every security incident must be investigated and, if it is determined that a data breach has occurred, the proper notifications should be done as fast as possible to both the supervisory authority and the impacted data subjects.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Protection Impact Assessments

Data protection impact assessments (DPIAs) are required by Article 35 of GDPR. It is up to the organization to determine when a DPIA as GDPR allows consideration based on the scope of processing and risk to data subjects.

One area where GDPR calls out the potential need for a DPIA is in regards to the use of new technologies. As a best practice, erring on the side of fast, regular DPIAs in the use of new technologies is a great way to capture risks and mitigations.

GDPR does define what goes into a DPIA and it is similar to a broader risk assessment.

1. Description of the processing.
2. Justification of the processing in regards to the purpose.
3. Assessment of the risks to individuals.
4. Mitigations, typically security and technical controls, to minimize the risks from the processing.

DPIAs should be centrally stored and easily accessible for future review internally as well as by supervisory authorities.

DPIAs are a structured way to assess the risk to personal data and should be performed in a standardized way within your organization.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Penalties under GDPR

GDPR clearly articulates the goal of penalties to be effective, proportionate and dissuasive. in Article 83. Fines under GDPR fall into two categories depending on the severity of the case.

1. Up to $10M Euro or 2% of global revenue, whichever is higher.
2. Up to $20M Euro or 4% of global revenue, whichever is higher.

The factors that determine which category fine is imposed are listed below.

• The scope and scale of the infringement. How many records and individuals were impacted?
• Intentional nature or neglect resulting in infringement. Was their clear neglect in the duties of the processor or controller? Did they know they were neglecting security of personal data?
• Actions taken to mitigate harm to individuals. Once discovered, did the controller or processor take steps to protect impacted individuals.
• The amount of responsibility for the breach that falls on the controller or processor. In some cases, an infringement can result wholly from the actions of 3rd parties or malicious actors, not employees of the controller or processor.
• Previous infringements of GDPR.
• Cooperation with the supervisory authority. Was the infringement promptly reported and how did the processor or controller work with the supervisory authority to manage it?
• Types of personal data affected. Some data, such as medical information, sexual orientation, data on minors, genetic data, as detailed in Article 9, are special categories of data.
• The way in which the infringement became known. Was it discovered by the processor or controller?
• If the processor or controller was ordered to take corrective actions previously, did they resolve those corrective actions?
• Adherence to a code of conduct or a certification. Did the controller or processor align and meet obligations of established frameworks such as ISO 27000.
• Were there positive outcomes from the infringement for the processor or controller?

There are many criteria above that are considered in assessing the size and extent of penalty under GDPR.

The best way to minimize the risk of a large fine is to implement privacy by design, starting with clear privacy policies and procedures, and consistently document the implementation of those policies.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Retention under GDPR

Personal data and data processing is at the heart of GDPR. GDPR Article 5 is black and white that data should only be collected and used as long as necessary for the purpose of processing.

In some instances, processing could be justified for longer periods of time, even after the individual does not have a relationship with the organization doing the processing. Below are some examples.

• Healthcare providers typically need to retain personal data for future care or legal reasons, in the case of a lawsuit or some other legal action.
• A bank may need to retain personal data for some period of time even after an individual ceases being a customer.
• A school may need to retain personal data to share with other schools in the form of transcripts.

These are three easy examples. If there is not a need to retain data for processing purposes, personal data can be de-identified, or fully anonymized, for future purposes.

Article 5 does go on to state personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, allowing for specific processing and longer term data retention.

Every organization should create and follow a data retention policy that takes into consideration the specific purpose and justification for data retention and processing.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Data Anonymization under GDPR

Personal data is data that can be used to identify an individual data subject. GDPR defines two terms of anonymization of personal data.

1. Anonymisation. Simply, this is data where identifiers have been removed and cannot be added back, rendering the data anonymous. This data does not fall under GDPR requirements.
2. Pseudonymisation. This is the process of stripping identifiers from personal data so the data cannot identify an individual. The identifiable elements are stored separately from the rest of data. Identifiers need to be combined with the data to make it personal data. This kind of data is still covered under GDPR but minimizes the risk and use of personal data.

If data is stripped of elements where it cannot be reasonably re-identified, then the data does not fall under GDPR.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

GDPR Training

GDPR defines explicit training requirements and implicit training requirements. The two explicit training requirements under GDPR are:

1. Article 39 - one of the defined tasks of a data protection officer is awareness-raising and training of staff involved in processing operation; and
2. Article 47 - **the appropriate data protection training to personnel having permanent or regular access to personal data.

The explicit GDPR training requirements apply to employees that access PII and processes that involve PII.

GDPR training should be conducted at onboarding for new employees when changes are made to compliance policies and procedures, and on a regular cadence, with annual being the longest acceptable interval.

Implicitly, Article 25 of GDPR defines the principle of Data protection by design and by default. The Article states - **The controller shall implement appropriate technical and organizational measures for ensuring that, by default, only personal data that are necessary for each specific purpose of the processing are processed.

The challenge in applying security by design and default today is that data is usually a core part of business, meaning most of your employees touch personal data in some way. These employees need to be educated and empowered to make decisions about data that align with GDPR and your policies and procedures.

Additionally, the tools that are used to power your privacy and compliance workflows, things like approving access to applications, onboarding, and training need to be simple to use. If not, employees won’t use them consistently and you will fall out of compliance with your own policies and procedures.

Article 25 goes on to state that this requirement can be met with a certification, which is still yet to be defined. In the experience of Haekka, having led or been involved in 1,000s of audits and security assessments, we have no seen a security certification that does not require training of all staff.

In order to implement security by design, privacy needs to be a part of the culture of an organization. Privacy and security training is an essential component of this.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

GDPR and Technology

GDPR does not offer a lot of specific guidance on how to secure technology, in particular modern technology. Given the speed at which technology, especially cloud-based technologies, are moving, this is a smart approach for GDPR.

GDPR, in Article 32, specifies that the controller and the processor shall implement appropriate technical ... measures to ensure a level of security appropriate to the risk. The paragraph also mentions state of the art. It is inferred and commonly accepted that this means current best practices for securing technology should be implemented.

In terms of specifics, GDPR does list the following technical controls:

• Pseudonymisation. Personal data should have identifiers stripped from personal data and stored separately whenever possible.
• Encryption. It is not specific on when to encrypt personal data but best practices mean encrypting personal data in transit and at rest.
• Backup and restore. Data must be backed up to ensure organizations are able to meet requirements for availability of data.
• Logging. This is essential to maintaining and proving the integrity of personal data.
• Disaster recovery. Recovering data and systems after a disaster or incident is necessary to meet availability requirements in GDPR.
• Regular testing. Using best practices, regular vulnerability testing and penetration testing should be performed against systems and networks that process personal data.

To meet the technical requirements of GDPR, current best practice security measures should be implemented and tested.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

Audits under GDPR

There are multiple forms of audits for GDPR. GDPR also has the notion of Certification, outlined in Article 42. A certification is also referenced in Article 25 and 32 as a means to demonstrate compliance with data protection by default and design and demonstrate technical and organizational security is in place to protect personal data.

The idea of an approved Certification is powerful as it is more standardized than one-off 3rd party GDPR audits. Unfortunately, there are not yet, as of June 2020, any approved Certification Bodies.

To attest and prove compliance with GDPR, the most common approach is to work with a 3rd party auditor that assess the compliance of an organizations against the Articles of GDPR. That, or an organization can complete a certification for ISO 27001 and use that as a stand-in for a GDPR certification.

GDPR is still relatively new and it is likely there will be approved certification bodies in the coming years.

In 2020, working a 3rd party, ideally one accredited by ISO or other data protection authorities, to document compliance with GDPR is the best step you can take.

Slides - Available via Haekka slack plugin. Coming soon!

Comprehension - Available via Haekka slack plugin. Coming soon!

© 2020 DayZero Inc. All rights reserved.

Questions? Reach out to us - hello@haekka.com

‍