Mark Hinely, Author at KirkpatrickPrice

As GDPR becomes a more and more prevalent data privacy law, we want to give organizations four actions to start with when working towards GDPR compliance. These areas should help organizations understand what kind of personal data of data subjects that they have, where it goes, and what role (data controller or data processor) they fit into under GDPR. I chose the areas of data mapping, contract management, documentation review, and security standards for a couple of reasons. First, because they are the most pressing areas upon an organization in terms of GDPR compliance and second, because they are the most universally applicable. No matter what role organizations fit into under GDPR, these areas will be useful places to start with for GDPR compliance.

Data Mapping

I recommend that all organizations start with data mapping when beginning their journey towards GDPR compliance. It is a critical area for data privacy. I don’t see how it’s possible to determine whether an organization is a data controller or data processor without a full knowledge of the personal data it holds, where the personal data comes from, and how the organization processes that personal data. One of the benefits of data mapping, I believe, is that it provides the greatest value in terms of multiple areas under the law. It can cover multiple roles in the law, plus it fulfills other aspects of GDPR compliance. Data Protection Impact Assessments, records of processing, facilitating data subjects’ rights, required information that controllers must give to data subjects and supervisory authorities – these areas all require a documented understanding of what personal data of data subjects that organizations have and where it goes.

In the diagram below, you can see a very rudimentary data map to give you a sense of why data mapping is beneficial. In this case, the data map represents a data subject who is a candidate for employment. That data subject provides their personal data to a third-party staffing or recruiting firm for assistance in finding employment. That third-party staffing firm then submits that personal data to an organization’s Human Resources Department. From there, you can see that Human Resources sends the personal data to other parts of the organization, as well as a third-party background screening provider. If that data subject were to find out about a negative mark on their background screening, tests the accuracy, and requests that the data be rectified, both of the third parties and the organization considering hiring the candidate would need to know where the data is flowing in order to determine what kind of activities they should take if the data request is a valid one.

A data map may be where an organization first uncovers that they are both a data controller and data processor. Let’s take SaaS providers who perform support activities, for example. If the SaaS provider is involved with support activities (live or remote support) that directly involve receiving personal data from a data subject, they may move from thinking they are just a data processor to understanding they are both a data controller and data processor.

I believe data mapping is a critical area in terms of GDPR compliance efforts. On your GDPR compliance journey, has your organization considered starting with data mapping?

Contract Management

The second area to start with when working towards GDPR compliance is contract management. Whatever role you play, but especially if you have both controller and processor responsibilities, contract management includes a review of all vendor/partner contractual agreements to ensure they are GDPR compliant. This includes controller-processor contractual agreements, contractual agreements between processors and sub-processors, and creating a process for reviewing all new contractual agreements before signing.

You need to review the agreements you have between data controllers and data processors for a few different reasons:

A written agreement is required to exist between data controllers and data processors in order to process personal data in a way that is GDPR compliant.
There are elements of contractual agreements that are specifically outlined and required by GDPR.
Processor discretion must be outlined.

Then, you must conduct a review of agreements between processors and sub-processors; these agreements must mirror the controller-processor contractual agreements. I recommend that your organization should conduct a one-time review of current contractual agreements with vendors and other partners to ensure that the agreements are appropriate for their role under GDPR. Going forward, you should create and implement a process for reviewing all new agreements before signing. This review should ensure that new agreements meet GDPR requirements.

What is your organization’s contract management process for GDPR compliance? With whom do you have contractual relationships and what kind of contractual relationship do you have? Do all vendors/partners have the appropriate contractual agreements for their role?

Documentation Review

The third area that I would recommend when beginning GDPR compliance efforts is an internal documentation review. This documentation review should cover information that controllers must share with data subjects, records of processing, and policies and procedures.

The law specifically requires documentation of information that data controllers must share with data subjects. Article 13 outlines when the personal data is directly received from the data subject and Article 14 outlines when the personal data is not directly received from the data subject.
Article 30 references records of processing. Many data controllers and data processors will meet the threshold for this, although there are some different levels of requirements. The law lays out what elements of those records that controllers and processors should maintain. If data mapping is completed, I think you’ll have a much better ability to meet the requirements for records of processing.
Policies and procedures must be reviewed and updated to address GDPR requirements. While some organizations may have to create new policies and procedures for things like data subject rights, most organizations should be able to just update current policies and procedures to include GDPR aspects.

How would your organization conduct a documentation review? Who would be involved? Who would update documentation to address GDPR requirements?

Security Standards

From my perspective, GDPR is a data protection law that is much more process-oriented and less technical in nature. The text of the law says both data controller and data processors have to have appropriate technical and organizational controls. The law does not specify what those technical and organization controls should be. In the future, supervisory authorities and other guidance from the EU may give us what those specifications are, but at this time, we don’t have it. Each organization must define what is “appropriate” based on the type of processing it’s engaged in and the type of data that it processes. Then, each organization must monitor that “appropriateness” going forward. If processing activities change, the controls that were once appropriate from a technical and organizational perspective may no longer be appropriate. If the processing changes but the type of data changes (like going into more sensitive categories of data), what was once appropriate may no longer be appropriate.

So, which security standards do you use? There are several ways to do this, your organization just needs to make a decision that defensible. You could use a third party to determine which security standards are appropriate for your organization, you could use a defined standard (like ISO 27000, NIST, or PCI), or you could develop an internal process.

Where to Start with GDPR Compliance

Data mapping, contract management, documentation review, and security standards are four key areas to start with for your GDPR compliance journey. We encourage you to follow the data, start the paper chase, perform thorough internal documentation review, and identify which security standards are appropriate for your organization. All of these activities will play off of one another and assist you in your GDPR compliance journey.

Want to take the next steps towards GDPR compliance? Contact us to speak with a data privacy expert.

About Mark Hinely

Mark Hinely, Esq., is a Regulatory Compliance Specialist with KirkpatrickPrice and a member of the Florida Bar, with 10 years of experience in data privacy, regulatory affairs, and internal regulatory compliance. His specific experiences include performing mock regulatory audits, creating vendor compliance programs and providing compliance consulting. He is also SANS certified in the Law of Data Security and Investigations.

More GDPR Resources

GDPR Readiness: What, Why and Who

GDPR Readiness: Whose Data is Covered by GDPR?

Auditor Insights: Are You a Data Controller or a Data Processor?

Appropriate Data Security Controls

While GDPR is primarily a data privacy law, it also includes elements of data security. But of course, GDPR is ambiguous so it’s not very prescriptive when it comes to data security requirements for processing personal data. The law requires each organization to evaluate its own data security based on risk, processing activities, and its organizational structure. By putting this in the hands of the organization, the organization can determine what’s an appropriate control. Organizations are also allowed to consider the ability and resources of an organization to implement a control. Just because a control is a possibility for mitigating risk doesn’t mean that it’s an appropriate control. What’s appropriate for one organization may be too expensive, impractical, or not secure enough for another organization. Appropriate organizational and technical data security controls include risk assessments, encryption, pseudonymization, and documented policies of things like business continuity, physical security, logical access, configuration management, human resources, and management oversight.

There should also be a process to monitor and test the effectiveness of data security controls, which is where internal and third-party auditing comes into play. These will serve as an effective way of demonstrating that thought and objectivity has been considered when it comes to what is appropriate for an organization. There have been unofficial attempts to map GDPR requirements to other information security frameworks, but they may be incomplete with respect to data security and privacy elements.

While GDPR is primarily a data privacy law, it also includes elements of data security and those requirements apply to both controllers and processors. GDPR is not prescriptive when it comes to security requirements for processing personal data. Instead, GDPR requires each organization to evaluate its own security based on risk, processing activities, and organizational structure. That’s because privacy needs evolve and privacy threats evolve, so GDPR is designed to evolve along with those needs and privacy threats. Some examples of appropriate organizational and technical controls include risk assessments, encryption, pseudonymization, and documented information security policies that cover things like business continuity, physical security, logical access, configuration management, human resources, and management oversight.

In addition to those particular controls and documentation around the policies and procedures of those controls, there should also be a process to monitor and test the effectiveness of those controls. This is where internal and third-party auditing comes into play. There have been some unofficial attempts to map GDPR requirements to ISO 27001 and SOC audits, and those are effective ways of monitoring organizational controls, but for GDPR purposes, they may be incomplete with respect to some of the data privacy elements.

Because GDPR is not prescriptive when it comes to the appropriate organizational and technical controls, there will be codes of conduct and certification standards that will provide some level of prescriptiveness when it comes to the security of processing. Until those codes come out, or if an organization decides to determine its own standards for what is appropriate, things like internal and third-party audits will serve as an effective way of demonstrating that thoughts and objectivity has been considered when it comes to what is appropriate for an organization.

In order to determine if a control is appropriate, whether it’s an organizational control or a technical control, it’s important to know what the goal is for the security of processing under GDPR. The goal is to prevent the unauthorized or accidental destruction, use, or disclosure of personal data. For almost any security threat, there is one or more tools or controls if your budget, time, and resources are unlimited. Fortunately, GDPR allows organizations to take into consideration the cost, practicality, and reasonableness of a control to mitigate risk. GDPR expects organizations to take what is appropriate for the organization, for the risk, and for the processing activity.

In addition to considering the processing risks to data subjects, organizations are also allowed to consider the ability and resources of an organization to implement a control. Just because a control is a possible control that would mitigate a risk doesn’t mean that it’s an appropriate control. It might be beyond the scope because it’s too expensive or not practical, or it might be insufficient because it’s not secure enough.

Most organizations who are required to comply with GDPR will have a Data Protection Officer (DPO). The requirement to have a DPO applies if you are a public authority, if your regular activities require large-scale and systematic monitoring, or if your core activities consist of large-scale processing of special categories of data.

Qualifications of a Data Protection Officer

When hiring a DPO, GDPR specifies that the individual must have the required expertise and experience not only in data protection, but in the corresponding processing activities. So, if an organization is a payment processor, their DPO should have familiarity with both financial transactions and the corresponding data protection regulations.

Responsibilities of a Data Protection Officer

GDPR describes several tasks for a DPO to perform, including:

Inform and advise its organization on how to involve employees with GDPR obligations
Monitor and review compliance with GDPR and other data protection laws
Advise and monitor Data Protection Impact Assessments
Be the primary point of contact for supervisory authorities
Cooperate with supervisory authorities in the course of an investigation or inquiry

What a Data Protection Officer Needs

From an organizational perspective, you must provide your DPO with a few things:

A DPO must have independence to perform their tasks. They cannot be unduly influenced to bring a specific outcome.
A DPO must be accessible both to internal employees and to data subjects.
DPOs must also have requisite resources to perform their tasks; this could mean time, money, training, or other resources.

So, what have we learned about DPOs? A DPO is an individual that has expert knowledge of data protection laws, is independent from an organizational perspective, cannot be told how to do their job, and cannot be penalized for doing their job. This could be a person who’s also fulfilling other roles within an organization (without a conflict of interest), but it could also be an outside contractor. Most organizations are going to require a DPO.

[av_toggle_container initial=’1′ mode=’accordion’ sort=” styling=” colors=” font_color=” background_color=” border_color=” custom_class=”]
[av_toggle title=’Video Transcript’ tags=”]

GDPR requires certain organizations to have Data Protection Officers. The requirement applies if you are a public authority or a body; your regular activities require large-scale, regular, and systematic monitoring of individuals (i.e. tracking online behavior); or your core activities consist of large-scale processing of special categories of data or data related to criminal convictions or offenses. For example, a hospital who’s processing large-scale quantities of healthcare data would require a Data Protection Officer. From a professional perspective, most organizations are going to require a Data Protection Officer.

GDPR specifies the qualifications of a Data Protection Officer in a limited capacity. The law says that Data Protection Officers should have the required expertise and experience with data protection laws. Guidance also indicates that Data Protection Officers should have experience and expertise that corresponds with the processing activities of their organizations. A couple of examples are: if an organization performs complex artificial intelligence review of advanced cybersecurity threats, then their Data Protection Officer should have familiarity with both artificial intelligence and cybersecurity threats and the corresponding laws. If an organization is a payment processor, then the Data Protection Officer should have experience with both financial transactions and the corresponding financial laws that govern those financial transactions.

GDPR specifies five tasks for a Data Protection Officer to perform. First, a Data Protection Officer must inform and advise its organization on including its employees on the company’s GDPR obligations. Second, a Data Protection Officer must monitor and review compliance with GDPR and other data protection laws. That includes reviewing an organization’s internal policies and procedures, as well as raising awareness of data protection issues, training staff, and conducting internal audits. Third, a Data Protection Officer should advise and monitor Data Protection Impact Assessments. Fourth, Data Protection Officers are a primary point of contact for supervisory authorities. Fifth, Data Protection Officers much cooperate with supervisory authorities in the course of an investigation or an inquiry.

A Data Protection Officer must have the requisite independence to perform their tasks. They cannot be unduly influenced by senior management to come out with a specific outcome regarding advice or a compliance review or input into a Data Protection Impact Assessment. A Data Protection Officer can be both an internal candidate or a contracted party. Either way, a Data Protection Officer must be accessible both to internal employees and to data subjects. One of the ways that an organization can make their Data Protection Officer available is to publish their contact information on a corporate web page, for example. The can also notify their supervisory authority about the identity of their Data Protection Officer.

Data Protection Officers must also have requisite resources to perform their tasks. That means that they have to have enough time to do any other job that they do along with enough time to perform their responsibilities as a Data Protection Officer. They may require financial resources; they may require hardware and software resources; they may require staff to perform their tasks. The Data Protection Officer responsibilities cannot be delegated among multiple individuals, but the Data Protection Officer can receive support form individuals within the organization to fulfill their responsibilities. Finally, a Data Protection Officer might require resources such as training and ongoing education around GDPR and other data protection laws. As I said at the beginning, most organizations are probably going to require a Data Protection Officer. For more guidance on the requirements and responsibilities of a Data Protection Officer, see the Article 29 Working Party guidance on Data Protection Officers.

[/av_toggle]

[/av_toggle_container]

GDPR divides responsibilities for organizations processing personal data based on their role, so determining which role your organization plays is one of the first steps towards GDPR compliance. You cannot know what your requirements or obligations under the law are until you do so. There are three major roles under GDPR: controllers, processors, and joint controllers. Let’s discuss what each of these roles mean and how your organization can determine which role it plays.

What is a Controller?

A controller is the organization who determines the purpose and means for processing. A controller has the most authority over processing activities and most likely has interaction with the data subject. A controller may determine things like:

What kind of personal data to collect and the legal basis for doing so
What the purpose of processing is
What methods will be used to collect personal data
How to store personal data
The detail of security surrounding the personal data
The means used to transfer personal data from one organization to another
The methodology behind data retention
The means used to delete or dispose of personal data

Some other responsibilities of controllers are handling data subjects’ rights requests through investigation, review, and response. Controllers are also responsible for performing Data Protection Impact Assessments, which is a formal process for reviewing and mitigating the risks of processing activities to data subjects. Controllers also have the responsibility of notifying supervisory authorities and data subjects in the event of a data breach.

What is a Processor?

A processor is organization that processes data on behalf of a controller. Processing is essentially anything done to the data, including storing, archiving, or reviewing. A processor helps the controller perform its obligations under GDPR but has no independent authority to determine what to do with the data or how to perform processing activities. Because processors can only act under the authority of a controller, their major responsibility is to support the controller.

What is a Joint Controller?

A joint controller is an organization who shares both personal data and decision-making authority with one or more other controllers. In a joint controller situation, the organizations must clearly define the responsibilities among joint controllers. The organizations must share authority over the data, not just share a data pool.

There are some responsibilities among controllers, processors, and joint controllers that are identical – the need for a data protection officer, documentation of processing activities, security over processing activities, designation of an EU representative, and liabilities under GDPR.

Are you subject to the responsibilities of controllers, processors, or joint controllers? Let’s find out today! Contact us to get in touch with a GDPR expert.

GDPR divides responsibilities for organizations processing personal data based on their role. There are three potential roles under the law: controllers, processors, and joint controllers. A controller is the organization who determines the means and the purposes for the processing. This is the organization that most likely has interaction with the data subject and will generally obtain the personal data from the data subject. A controller may also be a controller because it has independent legal obligations, such as an attorney or an accountant. A processor is a service organization that simply helps the controller perform its obligations under GDPR but has no independent authority to determine what to do with the data or how to perform a certain processing activity. A joint controller is an organization who shares both personal data and decision-making authority with another controller.

So, with those three roles identified under the law, let’s talk a little bit about what are some differences between a controller and processor. First, controllers are primarily responsible for handling data subjects’ rights requests. They are the ones that are responsible for investigating, reviewing, and responding to data subjects’ requests. Controllers are also responsible for performing Data Protection Impact Assessments. Those are processes for reviewing and mitigating the risks of processing activities to data subjects. Controllers also have the responsibility of notifying the supervisory authorities and data subjects in the event that there is a personal data breach. Processors, on the other hand, have the responsibility to only act under the authority of a controller, to notify a controller instead of a supervisory authority if there’s a breach, and to support rather than perform Data Protection Impact Assessments.

However, there are some responsibilities under GDPR that are identical between controller and processor. First, if applicable, both controllers and processors must have data protection officers. Second, if applicable, both controllers and processors must document their processing activities. Third, if applicable, both controllers and processors must designate a representative in the EU. Two additional identical responsibilities between controllers and processors are ensuring that their processing activities are secure and both controllers and processors are jointly and severely liable under GDPR for violations of the law.

Now, it’s already challenging to determine if an organization is a controller or a processor, but it should be noted that organizations may be both controllers and processors for different data subjects. For example, an organization that’s a software service provider may be a processor in its core activity of providing software; however, it may be a controller in its marketing efforts and as an employer. So, in that case an organization would have all of the responsibilities of a controller and all of the responsibilities of a processor.

[/av_toggle]

[/av_toggle_container]

6 Legal Bases for Processing Personal Data

One of the seven major data processing principles of GDPR is to ensure that personal data is processed lawfully, fairly, and transparently.

To comply this principle, Chapter 6 of the GDPR requires any organization processing personal data to have a valid legal basis for that personal data processing activity. Think of these as scenarios in which it would be lawful to process data. GDPR provides six legal bases for processing:

Consent
Performance of a Contract
Legitimate Interest
Vital Interest
Legal Requirement
Public Interest

Consent

The data subject has given permission for the organization to process their personal data for one or more processing activities. Consent must be freely given, clear, and easy to withdraw, so organizations need to be careful when using consent as their legal basis. For example, the age of automatically-checked consent boxes is coming to an end through GDPR.

Performance of a Contract

Self-explanatory, right? The data processing activity is necessary to enter into or perform a contract with the data subject. If the processing activity does not relate to the terms of the contract, then that data processing activity needs to be covered by a different legal basis.

Legitimate Interest

This is a processing activity that a data subject would normally expect from an organization that it gives its personal data to do, like marketing activities and fraud prevention. If legitimate interest is used as a legal basis for processing, the organization must perform a balancing test: is this processing activity necessary for the organization to function? Does the processing activity outweigh any risks to a data subject’s rights and freedoms? If the answer to either of those questions is “no,” then the organization cannot use legitimate interest as its legal basis for processing.

Vital Interest

A rare processing activity that could be required to save someone’s life. This is most commonly seen in emergency medical care situations.

Legal Requirement

The processing activity is necessary for a legal obligation, such as an information security, employment or consumer transaction law.

Public Interest

A processing activity that would occur by a government entity or an organization acting on behalf of a government entity.

Challenges for Choosing a Legal Basis

Choosing the appropriate legal basis for processing is extremely important for several reasons, including:

There must be only one legal basis for processing at a time, and that legal basis must be established before the processing begins. Under GDPR, organizations cannot establish the legal basis after processing personal data or alternate between legal bases.
Whichever legal basis is chosen must be demonstrable at all times. An organization must be able to show internally, to data subjects, and to regulatory entities what legal basis it uses for each data subject. For example, organizations must be able to demonstrate when and how a data subject provided consent or executed a contract.
The legal basis for processing has a significant impact on the way that an organization responds to data subject rights requests because there are conditions, exceptions, and limitations on requests depending on the legal basis for processing.
If an organization uses multiple bases to process different data processing activities, the organization should be able to distinguish between which legal bases is being used for which data set and respond correctly to data subject rights requests.
Special categories of data (such as race, ethnic origin, religion, trade union membership, biometrics, and health data) have unique legal bases for processing that includes preventive or occupational medicine, public health, collective bargaining agreements, and the legitimate activities of non-profit organizations.

It’s important to note that one legal basis for processing isn’t universally superior to another legal basis for processing. The most effective legal basis for processing depends on the purpose for processing, the type of personal data being processed, and the relationship with the data subject. Choosing which legal basis is appropriate for processing activities is incredibly important; if the wrong legal basis is chosen, it could result in unlawful processing, noncompliant response to data subject rights, and inadequate organizational and technical data processing controls.

More GDPR Resources

GDPR requires any organization processing personal data to have a valid legal basis for that processing activity. The law provides six legal bases for processing: consent, performance of a contract, a legitimate interest, a vital interest, a legal requirement, and a public interest. First, most organizations ask if they have to have consent to process data. The answer is, not necessarily. As I mentioned, consent is just one of six legal grounds for processing data. If you do use consent, you should know that consent must be freely given, clear, and it must be as easy to withdraw consent as it is to give consent.

Legitimate interest, for example, is something like a marketing activity. That’s a processing activity that a data subject would normally expect an organization that it gives its personal data to do. However, if an organization uses legitimate interest as its valid legal basis for processing, it has to perform a balancing test. Is the processing activity necessary for the organization to function? Does the processing activity outweigh any objection or risks to a data subject’s rights and freedoms? The contract is pretty self-explanatory. Public interest is a processing activity that would occur by a government entity or an organization acting on behalf of a government entity. Vital interest would be a rare occasion where processing data would be required to save someone’s life.

The reason why the legal basis for processing is so important is because the legal basis must be demonstrable at all times. An organization must be able to show internally, to data subjects, and to regulatory entities what legal basis it uses for each individual whose data it processes. If a data subject gives its consent to an organization, the organization must be able to demonstrate when and how that data subject gave consent.

Because consent must be freely given, organizations can no longer use automatically checked boxes to demonstrate that data subjects gave consent for the organization to use their data. The consent process must be clear and sometimes it must be separate. For example, if an organization is going to use email to send marketing messages to a data subject, then an organization might choose to have a separate box for email than it does for other forms of communication or text messages or phone calls.

The legal basis for processing is also important because it has a significant impact on the way that an organization responds to data subject rights requests. There are some rights that may be granted if consent is the legal basis for processing or if performance of a contract is the legal basis for processing. There are other implications for legal basis of processing as well. For example, the processing of special kinds of data which include: race, ethnicity, healthcare data, biometric data, among other sensitive pieces of information requires certain bases for processing.

Another challenge for the legal bases for processing is if an organization uses multiple bases to process different data sets. For example, an organization might process the personal data of EU data subjects who are employees of the organization and also of customers who its selling services to and is also marketing to. The legal basis for processing employee data may be different than the legal basis for processing customer data. An organization should make sure that they can distinguish between which legal bases is being used for processing to ensure that they respond correctly to data subject rights and to ensure that they perform any balancing tests related to legitimate interests. Finally, it should be noted that organizations can’t select which legal basis they are using to process data and then later change the legal basis if they use both consent and contract. There must be only one basis for processing personal data at a time.

Here are some more notes on the legal bases for processing personal data. First, the legal basis for processing personal data must be established before processing begins. Organizations can’t start processing personal data and then go back and try to execute contract, obtain consent, or claim legitimate interest. Second, one legal basis for processing isn’t necessarily superior to other legal bases for processing. The most effective legal basis for processing depends on the purpose for processing and the relationship with the data subject.

[/av_toggle]

[/av_toggle_container]