Chapter 9: Final Steps to Take for GDPR Compliance

Final Steps to Take for GDPR Compliance

Having read this far, you know a lot about the GDPR. You should understand the law, your obligations under it, and know how to facilitate your users' rights.

Throughout the book, we've been focused on the practical steps you can take to implement the law.

Now we're going to take a look at some remaining things you can do to ensure that your project is GDPR-compliant.

Do You Know What Personal Data You Process?

Whether you're planning a new development project or trying to bring an existing project in-line with the GDPR, one of your first steps towards compliance should be to try to get a full picture of how personal data is processed within your company.

Mapping Data In-Flows

It's important to determine how data enters your company's systems. Consider the sources of personal data in your operation and the means by which data flows in.

For example, for data controllers:

For data processors, all personal data flowing into your company (except for situations where you are the data controller) will be arriving from third parties, unless you are collecting it on a controller's behalf. Consider the different means by which you receive this data - how is it transferred to you?

Once you have identified all your sources of personal data, you can erase any:

• Personal data you don't need
• Duplicate personal data
• Personal data that you don't have a legal basis to process

Transferring Personal Data Out of the EU

There are strict conditions that apply to the transfer of personal data to non-EU countries.

This could apply in the following situations:

• Where personal data is collected by a non-EU company from a person in the EU. For example, a U.S. company asks a person in the UK to enter personal data in a web form. The data from the web form is to be stored on a server based in the United States.
• Where an EU company sends personal data to a non-EU location. For example, a UK data controller sends personal data to a data processor based in the United States.

There are a number of rules around transferring personal data to third countries, which we'll look at below.

Complying with these rules can take considerable effort. But the rules don't apply if the recipient of the personal data is based in an "approved" non-EU country which has a current adequacy decision from the European Commission (such companies include Canada, Israel, and New Zealand).

If this doesn't apply, you must have one of the following safeguards in place:

• If the transfer is taking place between two separate companies, for example, a data controller and a data processor, a contract containing standard data protection clauses can be put in place.
• If the transfer takes place within a multinational company, it can implement binding corporate rules.

There are also some exceptions to the rule, such as where the transfer is required to fulfill a contractual obligation. And as a "last resort," a person can consent to their personal data being transferred to a non-EU country without any of the above safeguards in place.

Do You Have a GDPR-Compliant Consent Solution?

We've talked a lot about consent throughout this book. You should now know when you need to request consent, and when you can rely on another legal basis such as legitimate interests.

It's important to make sure that, where you have identified consent as the appropriate legal basis, you also ask for consent in a GDPR-compliant way.

The Six Conditions of Consent

Here's the GDPR's main definition of consent at Article 4:

Here's another important insight from Article 7:

We can distill these requirements down into six conditions. Consent must be:

1. Freely given
2. Specific
3. Informed
4. Unambiguous
5. Given via a clear, affirmative action
6. Easy to withdraw

This is a high bar. But remember that it only applies if you're asking for consent.

Problematic Consent Solutions

There are some common ways of (supposedly) earning consent that are no longer valid under the GDPR. Here are some methods of requesting consent that you might be wise to avoid, or remove from your website, when becoming GDPR-compliant.

Cookie Walls

A cookie wall prevents users from accessing a website unless they consent to have cookies placed on their device. This is highly problematic in the light of the GDPR's requirement that consent is "freely given."

Here's what the European Data Protection Board recommends regarding cookie walls:

"In order for consent to be freely given as required by the GDPR, access to services and functionalities must not be made conditional on the consent of a user to the processing of personal data [...] meaning that cookie walls should be explicitly prohibited."

Admittedly, this might seem a little draconian. Why shouldn't you be allowed to govern the terms of access to your own website? Well, there's no rule against charging people money for access - the rule simply prohibits the "commodification" of people's personal data. You may consider this unreasonable, but remember that this is the law as it stands.

Here's an older example of what appears to be a cookie wall from Datanyze. The dialog box is displayed over Datanyze's website. There is no option to close the dialog or consent:

When you tick all three boxes, you're only then allowed to close the dialog and access the site:

It's only possible to access Datanyze's site if you agree to cookies, and all the information present in its Privacy Policy and Terms. This is not freely-given consent as conceived by the GDPR.

Pre-Checked Boxes

Pre-checked boxes are a classic example of how a consent request can fall short of the requirements to be "unambiguous" and "given via a clear, affirmative action." Neglecting to refuse consent is not the same thing as giving consent.

When developing your front-end consent requesting mechanism, do not include a box that's already been checked. There should be no situation where this is necessary.

Here's an example of a pre-checked box, from an old version of a form from One Moorgate Place (note that the form has since been updated to be compliant):

This is an inquiry form. When people make an inquiry via your company's website, it's ok to ask them if they also consent to receive marketing communications from you. But this should be a proactive decision on their part. There should be no mistaking that they want to receive marketing communications.

Presumption of Consent

Because of the strict standards of consent required under the GDPR, you'll want to remove (or avoid adding) any wording on your website which implies that you "assume" users are giving consent.

This is a very common feature of cookie banners. Here's an example from EAIE:

It may be that these are essential cookies that do not require consent. In which case, there should be no implication that consent has been granted.

Or it may be that these are targeted advertising cookies. In which case, it cannot be assumed that the user has consented merely because they continue to browse your website.

Compliant Consent Solutions

It's not that difficult to implement a GDPR-compliant consent process, both for cookies usage (a cookie consent notice), or for general data processing (such as implementing an "I Agree" checkbox).

Just keep the six conditions of consent in mind, and do not take action until you have received consent.

Clickwrap v Browsewrap

As we've seen, it's not appropriate to assume that someone has granted consent to cookies simply because they visit your website. Such an approach is sometimes known as "browsewrap."

A more appropriate solution under the GDPR would involve having the user give a "clear, affirmative action" to confirm their consent. For example, clicking "I accept" or "OK." This is known as "clickwrap."

Here's an unclear, not so robust cookie consent banner from eBay (note that it has since been updated):

Here's an updated version with more options for customization and the option to decline all cookies:

Specific Consent

The requirement that consent is "specific" means that you should not "bundle" requests for consent. Consent should be requested for one specific thing at a time. This means that where a person consents, for example, to receive your newsletter, they aren't consenting to also receive special offers or third-party marketing.

Here's an example of how you can make your consent requests specific, from TTI Europe:

Here's another example of how to request specific consent to both first- and third-party direct marketing, from the WeSwap Android app:

Setting Cookies After You Have Consent

We've seen that if you have identified a need to request consent, you have to ask for it in the proper way. But that's not all - you also have to properly implement your response to this request.

If you're asking for consent for cookies, the proper thing to do is to only set cookies after you've received consent.

This can be achieved in a number of ways. For example, in Google Tag Manager, tags fire by default as a result of a PageView event. If you have a tag associated with setting non-essential cookies, you should set up a custom trigger which fires only once consent has been granted.

Do You Have the Right Policies in Place?

Having appropriate policies in place can improve the efficiency, accountability, and reputation of your company.

There are certain written documents are mandatory under certain conditions, for example:

• A Privacy Policy. This is only mandatory for data controllers. But if your company primarily acts as a data processor, you'll still need a Privacy Policy that covers any data processing activities for which you are a data controller (for example, processing the personal data of your own staff and customers).
• Data processing records. You may not be required to produce these if you are a small or medium-sized company, and you only process non-sensitive personal data occasionally.
• An EU Representative Appointment Letter. This only applies if your company is not established in the EU.

There are a number of other policies that can help contribute toward your compliance with the GDPR. Depending on the context of the project you're developing, you may or may not need to produce all of these policies.

You can consider:

• The sensitivity of the personal data you process
• The amount of personal data you process
• The extent to which processing personal data is a core activity of your company
• The size of your company

Data Protection Policy

A Data Protection Policy is an internal document which sets out the principles, standards, and practices of data protection within your organization. Even if your company is very small, it can still be helpful to have this sort of policy in place.

A Data Protection Policy can include information about:

• Who is primarily responsible for data protection matters in your company
• Your procedures for facilitating data subject rights requests
• The safeguards you have in place for facilitating international data transfers
• Data security standards and practices
• Other policies such as your Data Retention Schedule and Data Breach Policy

Your Data Protection Policy should function as a guide, used by everyone in your company, that explains what to do when a data protection issue comes up.

Data Breach Policy

If a serious data breach occurs, companies are obliged to report it to their Data Protection Authority within 72 hours.

A Data Protection Authority can issue fines and other penalties to a company that is responsible for a data breach. When deciding on what penalties to issue, Recital 148 states that the Data Protection Authority can consider how the company responded when the breach occurred.

This is why it's important to have a Data Breach Policy in place that provides information about:

• Who within your company should be informed about a data breach
• What should be done to contain the breach (e.g. taking systems offline, resetting passwords)
• What investigation should occur into the nature of the breach (e.g. who is affected, what data was lost, what caused the breach)
• How to assess whether the breach is sufficiently serious to warrant reporting to your Data Protection Authority, and/or the individuals that are affected
• Where to find your company's template Data Breach Notice Letter;
• The post-breach evaluation process (i.e. how to avoid a recurrence)

Data processors should also have such a policy in place. However, a data processor is required to inform their data controller about a breach, rather than their Data Protection Authority.

GDPR Compliance Statement

A GDPR Compliance Statement is a public-facing document, written in your company's brand voice.

This is your opportunity to tell the world about all your efforts to become GDPR-compliant. You can include information about:

• The GDPR, why it is important, and why your company is committed to it
• The safeguards you have in place around data security, data sharing and international data transfers
• Your policies and procedures
• How you'll be facilitating data subject rights
• Whether you have appointed a Data Protection Officer and/or EU Representative

This is reassuring for your customers, whether they are consumers or other businesses.

GDPR Compliance Checklist

Below is a checklist of the things you need to know and to do in an effort to become GDPR-compliant. You'll want to consider all of these factors, no matter how big or small your development project is.

The list isn't exhaustive, and there may be additional considerations in particular contexts (for example, if you're offering services to children, or processing sensitive data).

Data controllers are required to consider all of these points, but only certain points apply to data processors.