With less than 2 months before the General Data Protection Regulations (GDPR) come into force on the 25th May, tens of thousands of businesses are woefully underprepared, and many businesses outside of the EU do not realize that GDPR also applies to them. Passed by the European Union (EU) to protect the privacy of Europeans’ data, the laws apply to anyone, from Pittsburgh to Pretoria, involved in the collection, storage, or handling of that data. The pan-European approach is designed to protect European data, but the global nature of the web means GDPR establishes the standard for data privacy worldwide. The financial penalties of non-compliance are exceptionally steep: up to €20million, or 4% of global turnover (whichever is higher) per infraction. But GDPR should not be seen as an obstruction to business, rather a set of sorely-needed best practices for how we collect and handle data. [pullquote]the global nature of the web means GDPR establishes the standard for data privacy worldwide[/pullquote] GDPR provides protection for an individual’s data, such as a name; it provides even greater protection for sensitive data, such as religion or politics. That might sound overly officious in a country where freedom of religion is constitutionally mandated, but there are numerous jurisdictions in which a person can be imprisoned, tortured, and executed, for holding the ‘wrong’ beliefs. Closer to home it is looking increasingly likely that the exploitation of Facebook data by firms including Cambridge Analytica was a determining factor in several shock election results; if GDPR had been introduced two years earlier there might be a woman in the Oval Office, and the UK might be continuing as an EU member state. Whatever your motivation for GDPR-compliance, ensuring that your website meets these best practices is substantially simpler, and cheaper, than non-compliance. The nature of GDPR means that different businesses are affected in different ways, there is no one-size-fits-all route to compliance. This article is not legal advice, and should not be construed as such. If in any doubt, consult your regulator, or a qualified legal practitioner in your jurisdiction.

What is GDPR?

The modern web runs on data, not just site generated content, but user information. It powers everything from social media posts to ecommerce charts. As web professionals we desperately need a comprehensive set of best practices that ensure that human beings aren’t swept aside by the advance of technology. Those best practices are what GDPR gives us. Part of the reason that GDPR-compliance appears burdensome to business is that we’ve previously been very lax when advocating for users’ privacy. Many of the current laws are a quarter of a century old. GDPR brings privacy laws into the 21st century. By ensuring that your site, SaaS, or app is GDPR-compliant you’re demonstrating that you take your users’ privacy seriously. GDPR helps you establish trust with your users, and once your users trust you, they will be willing to divulge more data; strengthening the bond between your brand and your customers. GDPR is an intelligently constructed set of regulations that make everyone’s data safer, create a happier, less paranoid web, and help lay the groundwork for future data handling.

What Data is Protected?

There are two main types of data that GDPR requires us to protect: personal, and sensitive. Personal data is any data that relates to an identifiable person. Your name, email address, location, biometric data, online identifiers such as usernames, all qualify as personal data. Sensitive data is anything that the EU judges to be more private than a name. Your ethic origin, religion, sexual preferences, politics, any criminal history, are all considered sensitive data. Sensitive data is more protected under GDPR and the penalties for failing to protect it are much higher. What’s not yet clear, is when personal data becomes sensitive data. That decision is likely to be made by the regulators on a case-by-case basis. For example, an email address is personal data, but if your email address is “hilaryfan65915795@…” then it’s possible to infer your politics, which upgrades it to sensitive data. GDPR makes provisions for data that can be inferred or collated from different sources. If a malicious entity can use the data you hold, such as an IP address, to link sensitive data held on another site to a particular individual, then you have contributed to compromising that user’s sensitive data, even if you do not hold the sensitive data yourself. The best practice is to never ask for more data than you require—the less data you hold, the less there is to lose.

User Rights Under GDPR

GDPR prioritizes the rights of data owners. In any situation that you are considering requesting user data, first ask yourself: how will this affect the rights of the owner? GDPR specifies the following formal rights that data owners have:

1. The right to be informed;
2. The right to access;
3. The right to corrections;
4. The right to delete data;
5. The right to limit processing;
6. The right to data portability;
7. The right to object;
8. The right not to be subjected to automated decision-making.

However, data collectors also have rights. For example, imagine a user has subscribed to your newsletter. Later, that user decides they no longer wish to receive the newsletter and unsubscribes. You must, without exception, permanently erase that user’s email address. However, if when the user subscribed you recorded their IP address to verify their consent (as you should), you are entitled to retain that data to demonstrate your business’ GDPR-compliance.

To Whom Does GDPR Apply?

GDPR applies to data that is collected, processed, and/or stored in Europe, regardless of where the data is gathered. If you have a newsletter, and a single European subscribes to it, then GDPR applies to you. [pullquote]If you are transferring personal data outside of the EU…then you must obtain explicit consent to do so[/pullquote] One significant complication of GDPR is that it prohibits transferring data outside of the EU to any country that the EU does not deem to have adequate data protection laws. At the time of writing, several countries including Argentina and New Zealand meet this standard; the United States and Canada are deemed to have partially adequate privacy laws. If you are transferring personal data outside of the EU for processing, or storage, then you must obtain explicit consent to do so from the user who owns the data. Given the multi-jurisdictional nature of the web, and technology like CDNs, it is wise to assume that at some point in time, data you collect and store, will be transferred outside of the EU and its approved countries. Therefore whatever other permissions you ask from your users, it is advisable to always obtain permission to hold their data outside of the EU.

Practical Steps to GDPR Compliance

It’s important to understand that it is not the EU regulator’s responsibility to prove your non-compliance—they do not have to catch you red-handed. It is your legal duty to prove that you are compliant, and failing to do so is in itself non-compliance. (The simplest way to demonstrate GDPR compliance is to meet the ISO 27001 standard. However, meeting that standard involves a far higher level of security than most small businesses will be able to meet.)

Adopting Privacy By Design

The fundamentals of GDPR are defined by the Privacy By Design (PBD) approach. PBD takes the attitude that privacy is not ensured by legal compliance, but rather must be adopted as an organization’s default approach. PBD was first proposed by the Information and Privacy Commissioner of Ontario, Dr Ann Cavoukian over twenty years ago. In 2010 the International Data Protection and Privacy Commissioners voted unanimously to recognize PBD as an essential component of privacy policy. In 2012 the US Federal Trade Commission recognized PBD as a recommended practice. PBD holds that privacy, once lost, cannot be regained, and therefore threats to privacy must be anticipated and prevented. PBD is defined by seven principles:

1. Be proactive: PBD is preventative, not remedial. In short, it’s pointless locking the stable door once the horse has bolted.
2. Privacy by default: A user should not have to take any action to ensure privacy. If a user does nothing, then their data is treated as private.
3. Embed privacy in design: Privacy isn’t added to a system as an afterthought, it is an integral component of any product or system.
4. Privacy doesn’t limit functionality: PBD rejects the idea that any legitimate use of data needs to compromise privacy.
5. Full life privacy: PBD covers the entire lifecycle of a piece of data, from the point it is collected, during its storage, and until it is destroyed permanently.
6. Transparent privacy: Privacy standards are fully transparent, so anyone using the product or system clearly understands how their data is protected.
7. Privacy is user-centric: PBD is about respecting the privacy of the individual, the owner of the data should be the first priority.

One of the core concepts of GDPR is that not only should PBD be implemented, but that you fully document your PBD process. If you’re unlucky enough to have to report a data breach to your regulator, the documentation of your PBD approach is the basis for the regulator’s investigation, and its decision regarding your culpability. A substantial portion of that documentation is your Privacy Impact Assessment.

Writing a Privacy Impact Assessment

A core component of PBD, and a requirement of GDPR compliance is a Privacy Impact Assessment (PIA). Any digital product should have a PIA. Ideally the PIA is a living document that grows as a product is devised (in accordance with the third principle of PBD), but you can write them retrospectively for existing products. The purpose of the PIA is to document the threats to privacy in your system, and the steps you have taken to combat them. It is essentially a personalized checklist of privacy issues and can be seen as a roadmap for protecting your users’ privacy. There’s no standard checklist for a PIA, because each project is unique, but there are some recommended practices you can follow. Don’t be afraid to add extra detail if your project warrants it.

1. Identify the need for a PIA: Why are you writing a PIA? Describe the scope of your project. Describe what data is likely to be required. Describe how sensitive you expect that data to be.
2. Document the expected data flows: How will users disclose data, how will it be transmitted and stored, will it be processed and if so how? Identify anyone who will be using the data, including management and developers. Speculate on future uses for the data, what might it possibly be used for in future? How long will the data be stored? How can the user modify or remove their data?
3. Document consent processes: How will you record the user’s consent? How will you verify consent? If consent is not expressly given, is there a legally justifiable basis for collecting the data?
4. Identify risks: What is the risk to individuals from the data? Is any unnecessary data collected? Is the data backed up, do the backups have the same level of security? Who has access to the data, what about interns, what about third-parties? What if the data is lost, modified, disclosed, misused? Assess any risks including legal complications and loss of reputation.
5. Identify solutions: Devise ways to reduce, and if possible eliminate, privacy risks. Assess the cost of solutions in terms of time and investment. How do the solutions impact user privacy, and the project? Are there proper procedures in place to handle a data breach? Are there proper procedures in place to comply with legal processes such as a court order to disclose information?
6. Document the solutions’ integration in the project: Ensure that solutions identified are built into the project. Update the PIA to reflect any technical changes this required.

Continue to build on and expand the PIA throughout the life of your product. As per principle four of PBD, privacy protection will not compromise any legitimate use of user data. If through the development of the PIA an unacceptable, or unsolvable risk to privacy emerges, then you should question the viability of the project. Appointing a Data Protection Officer Large organizations, and any processing certain types of data (banks for example) are required to appoint a Data Protection Officer (DPO) whose role is to ensure that the organization is GDPR compliant. Smaller companies are exempt from appointing a formal DPO. For example, if you run a restaurant, you do not normally need to appoint a formal DPO, however, if you run a delivery business from that restaurant, and you keep on file sensitive data such as allergies (which constitutes medical data) or dietry preferences (especially if those preferences are religious) you will almost certainly require a DPO. Different member states in the EU describe the requirements for a DPO differently, so it is wise to check. Regardless of the legal requirement it is always advisable to have a single point of contact who can coordinate privacy efforts across your organization.

GDPR is All About Consent

It seems extraordinary to have to say this in 2018, but a lack of a ‘no’ does not mean ‘yes’. As per principle 2 of PBD, the desire for privacy should be assumed by default. As per principle 4 of PBD, you cannot say that a user may only use the system if they consent to compromise their right to privacy. Users are entitled to consent, but they are also entitled to not consent. Never trick users into consent. Those woeful double, triple, and quadruple negative lines of microcopy designed to confuse users into checking one box and unchecking another, are not acceptable under GDPR; users must understand exactly what they’re being asked to disclose, why they’re being asked to disclose it, how it will be secured, and how they can consent (or not). Under GDPR, consent is carefully defined to ensure that users’ rights are protected:

1. Consent should be explicit, verifiable, and freely given: You cannot trick or pressure a user to consent. A pre-ticked checkbox does not constitute consent.
2. Consent must be requested in plain language: You must have reasonable grounds to believe that your users will understand the consent they are being asked to give.
3. Consent for digital services from a child under 16 requires parental consent: Some EU states will reduce this to 13, but err on the side of caution. Note that if you are gaining consent from children the request for consent must be written in language both the child, and their guardian understand.
4. Consent must be granular: Users may be willing for you to retain and use their data, but not be willing for you to pass it on to third-parties. Never require blanket permissions. You cannot employ the classic “By visiting this site you agree…” text.

If the consent that you obtain from your users fails any of these requirements, then it will be deemed that you do not have consent, regardless of your users’ intentions.

Writing a Public Privacy Statement

Most websites include a general privacy statement, but GDPR compliance requires a much more specific privacy statement than one that you may have published previously. In order to comply with principles 6 and 7 of PBD, your site, app, or service must have a Public Privacy Statement (PPS) that is written in plain-language that you can reasonably expect your users to understand. Your PPS should include the following information:

1. What data you are collecting: Ensure you include all of the data you’re collecting, not just the obvious; include IP addresses, timezones, default languages, everything.
2. Why you are collecting that data: For each piece of data, explain why you are collecting it, and why you consider collecting it to be both reasonable and necessary.
3. What data is required: List any data that is required, either contractually or practically. For example, if the user’s email address is required in place of a username, then say so.
4. Which third-parties are you sharing data with: Under GDPR you cannot post a general statement about sharing with third parties, you must specify which third-parties, and what data is shared with each third-party, and for what purpose.
5. Where else you are getting data from: If you’re collating data from elsewhere, what are you importing, where from, and how are you using it?
6. How long you will hold the data: Be specific about how long the data will exist on your system. Will you remove the data as soon as the user ceases to be a customer? If you intend to hold the data indefinitely, say so.
7. How the user can invoke their rights: Explain how the user can discover what data you hold, and how the user can request the data be updated or removed.

It’s common to provide reassurances such as “We will not share your data with any third party” but that is untrue for most companies. Whether it be analytics, or third-party hosting, we share an extraordinary amount of data on behalf of our users, GDPR requires us to take responsibility for it. Don’t make promises you can’t keep.

What GDPR Means for Web Designers

There are numerous small ways in which we can improve GDPR-compliance, without radically altering our sites. In many cases, it is simply a change in mindset.

1. Introduce just-in-time notices. This is the habit of telling users about the data you’re collecting, at the point of collection. For example, beneath your newsletter subscription field, explain that you’re collecting their email address to send marketing material and you’ll also record their IP address to verify their consent. This ensures that, in keeping with principle 6 of PBD, users are aware of what data you hold, for what purpose, and don’t have to go hunting for a privacy policy. (Always include a link to a full Public Privacy Statement in case the user wants more information.)
2. In order to comply with principle 2 of PBD, when gathering consent, checkboxes must not be pre-selected.
3. Reduce the data you are recording. For example, location data is often recorded with greater precision than required. If you need to know the state someone is located in, it does not follow that you need to know the city, or the suburb. If you’re collecting longitude and latitude data, truncate a few digits before recording it.
4. When you record user data, ensure that you record the manner in which consent was given, the date and time. Include the option to mark the consent as rescinded, in case you need to remove the data in future.
5. Pseudonymize data where possible by replacing identifiable data such as a name, or email address, with an anonymous ID.
6. Compartmentalize data where possible, so that personal data such as application preferences, are not stored alongside security data such as usernames and passwords.
7. It’s been standard practice for some years to rely on an email address as a username. Think carefully about whether this design pattern makes sense for your users. It will certainly simplify your login, but it also exposes private data to potential disclosure or misuse.
8. Ensure that no part of your UI displays personal data. If your UI indicates someone is logged in with a welcome message, then use the least sensitive data you can. For example, an avatar of the user is less sensitive than their name, which is less sensitive than their email address. Assume that someone is reading the user’s screen over their shoulder, without their knowledge; what data are you giving away that you don’t need to?
9. Could a malicious user compromise data by triggering an error? For example, if a user enters email addresses in a “Forgot Email” form, will the form confirm that the password reminder has been sent (and by inference confirm that the user has an account)?
10. UX is all about research. If you’re conducting research into your users, how are you storing that data? Is the data sensitive? Are you profiling them?

First Steps to GDPR Compliance

The first step in GDPR compliance for small to medium businesses is to ensure that all stakeholders are aware of, and engaged with the process; it is far easier to implement procedural changes when you have management buy-in. The next step is to establish which member state is your regulator. If you’re operating within the EU, this will normally be the member state in which your HQ is located. If you’re in the UK, then GDPR applies to you as an EU regulation up until the end of the Brexit transition period in December 2020, after which the UK government expects to enshrine GDPR in British law—at the time of writing it is unclear whether the UK regulator will continue as a member state regulator after March 2019. If you’re operating outside of the EU then it makes sense to select a member state that speaks the same language as you, for English-speaking countries the obvious choice would be Ireland. Next, carry out a full audit of the data that you currently hold. Where did it come from? Is it current? Who do you share it with? Is it necessary? Is it safe? If you can’t answer all of these questions to all of your stakeholders’ satisfaction (or your DPO if you’ve appointed one), then delete the data. Do your house-keeping. If a user hasn’t logged into your site since 1997, it’s a fair bet they’re no longer a customer, and the data you hold for them is neither necessary, nor current. Send them a polite email asking if they’d like their account to remain open, if you don’t hear back, then close the account for them and delete their data. Speak to any third-party you share data with and ensure that they are aware of, and committed to meeting the 25th May 2018 deadline. Large companies, including Google and Twitter, and more niche companies like MailChimp and Intercom, are all committed to GDPR compliance. [pullquote]it’s a common misconception that GDPR means wiping your mailing list and asking people to resubscribe[/pullquote] Check your mailing list—it’s a common misconception that GDPR means wiping your mailing list and asking people to resubscribe. This is not necessarily the case—if you’ve been building it ethically it may already be compliant; if you have explicit consent to retain an email address for everything you use it for (such as marketing) the user’s consent was opt-in and not assumed, you have a timestamp recording the time of the consent, the email address was not required as part of a transaction (as payment for a ‘free’ PDF for example), and there is a mechanism to withdraw consent, then you may be legitimately able to keep that address in your database. Some companies will find that it is less onerous to wipe their mailing list and start again, even if they could demonstrate proper consent. Lastly check with whomever hosts your site to ensure that their infrastructure is suitably secure for storing your users’ data.

Conclusion

GDPR is a long-overdue set of best practices for privacy in business, and particularly on the web. It instructs us to treat our users’ data with the same care and respect we treat our own. The penalties for non-compliance with GDPR are tiered. Tier one is €10m, or 2% of global turnover (whichever is higher); Tier two is €20m, or 4% of global turnover (whichever is higher). These penalties will depend on factors such as whether you have attempted to comply, whether you have taken action to mitigate any data loss, and the types of data involved. In addition, GDPR gives individuals the right to be compensated for any material and/or non-material breach of GDPR. Although this might seem draconian, the severe penalties facilitate our role as advocates for our users. It is far easier to get management buy-in with the threat of financial penalties. GDPR-compliance is about protecting your users; become their advocate, fight for their privacy, enshrine their rights in every product you build. It will result in better products, loyal users, and a more trusting—and trustworthy—web.