Are you looking for a GDPR guide with clear steps towards implementing this mandatory data protection regulation? Well, you’ve come to the right place! Your win: it will take about 10 minutes to read and will save you days of research! If you stumbled upon this article and your first reaction to GDPR is “Isn’t that the name of the new Nintendo?” and you’re in software…you might want to stick around and continue reading.

Why this GDPR guide is a must read

• The main answer: prevent fines! These fines are serious and can have heavy impact. It can get your company in real financial trouble.
• Prevent more painful trouble You thought fines will be your only problem? Wrong. You didn’t add up the damage to customer reputation (data breaches need to be reported to users), branding, even more investigations and monitoring by regulators, etc.
• Not easy to implement If data processing or data security isn’t your core product, this can be a tough nut to crack. This will be part of your product operation and you might want some inspiration how to kickstart the process.
• And in the end…it can get you fired If you’re a CPO or in any position responsible for product (and data handling), your job can be on the line when you’re being held responsible for any damages.

This guide won’t explain all of GDPR. It will give you an overall good understanding of GDPR and how to start implementing this into your product.

What is GDPR?

GDPR stands for General Data Protection Regulation and is applicable to every business which has European customers. Even when you’re a not a EU business. If you deliver goods and/or services within the EU as a non-EU company, GDPR will be applied to you as well. The goal of GDPR: protect personal data of citizens of the European Union (EU) and regulate how it may be used. The GDPR regulation will be enforced from May 25th 2018.  EU regulators are very clear: They won’t accept any excuse for non-compliance after this date. Especially in cases like leaking sensitive data or personal data stolen from your system. This excludes United Kingdom from GDPR due to Brexit. They expect the UK will have their own version of GDPR. Be aware of this when you have a large customer base in the UK. …So this is the part you really want to know:

Why to be compliant: GDPR fines

By now, most of you are wondering about the actual GDPR fines can expect when things go wrong. These fines speak for themselves and show clear incentive why to become complaint:

• Up to €10 million or 2% (whichever is higher) of the company’s entire annual turnover. Based on the previous reported financial year when you violate Article 83(4).
• Up to €20 million or 4% (whichever is higher) of the company’s entire annual turnover. Based on the previous reported financial year when you violate Article 83(5).

Difference between these GDPR fine levels?

The difference is based on the articles mentioned. In overall terms:

• The first fine level is based on Article 83(4) and focuses on violating obligations as a processor or controller of data. Things like having the correct consent registered of the user, correct authoritative certifications to process sensitive data (like correct PCI-DSS level to process credit card information),

Example: You’ll need explicit parental consent registration when you run any social related service for children under the age of 13.

• The second fine level is based on Article 83(5) and focuses on violating rights and freedoms of data. Things like cross-border data transfers, handling and securing personal data, transparency on why/how you handle data.

Example: You can only acquire personal data for legitimate reasons and have stated the exact purpose of handling personal data transparently.

How will a GDPR fine be determined?

Fines will mostly be given when your violations result in any real damage. The fine is case specific. GDPR regulators will base the height of the fine on the following:

• Nature, impact and total duration of the violation Checking why you did process the affected data in the first place (nature). Also gets into how long and how much your users were damaged.
• Manner of notifying authority about violation If you have reported the violation yourself directly to the authority first or they found out through a Reddit post by BollywoodDancer15.
• Intentional or negligent character of the violation Basically if you were being a dumbass.
• Actions taken to mitigate the damage This will look at what specific actions you took to mitigate your users suffering any damages as a result of your violation.
• Degree of responsibility If you had correct technical and organisational measures already in place. If you really took every measure possible, it should be a given the regulator will lower this degree.
• Previous infringements Checking if you have any track record of being a ‘bad boy’.
• Level of cooperation with the authority How much effort you put into cooperating with any authorities involved to fix damages and effects as much as possible.
• Adherence to code of conduct and/or certification Checking if the applicable codes of conduct and provisioned certification requirements were followed.
• Data category affected The type of data that was affected. Personal financial information will be handled much differently than just a few middle names from users.
• Aggravating or mitigating factors Checking whether you’ve gained any (financial) benefits or prevented losses. Directly or indirectly of the violation.
• Corrective measures previously applied If you had a previous visit from the authority which imposed corrective measures for the same matter.

The full GDPR regulatory power

GDPR isn’t about only giving fines when the damage already has been done. The GDPR’s Supervisory Authority has a range of authoritative powers. Besides giving severe penalties, they’re able to knock on your business door and either investigate or correct any non-compliance. These measures are mostly there to prevent your business getting into real trouble.

What the authority can investigate

• Conduct security audits.
• Review all certifications.
• Demand to provide information required to perform your business tasks.
• Notify you about any GDPR infringement.
• Obtain access to any premises of yours including data hardware.
• Obtain access from your company to all (personal) data necessary to perform your company’s tasks.

What the authority can correct

• Give warnings to your business that their processing activities may result in GDPR infringement.
• Suspending data transfers to parties within any third country (= any country outside EU) or any international organisation (= an organisation which isn’t headquartered in the EU).
• Demand to get processing activities into GDPR compliance. This can include detailed instructions and implementation deadline.
• Impose administrative fines.
• Demand to communicate a personal data breach to the data subject (= user).
• Giving temporary or definitive limitations on processing or a total ban on processing.
• Demand a certification body to block giving you an intended certificate or retract a given certificate.
• Demand rectifying or restricting data.

Initial GDPR checklist

This initial step in this GDPR guide has one clear goal: figuring out your current state of compliance. I’ve chopped them up in categories which makes it easier to delegate when you need to:

GDPR management & organisation

---

1. Are all people in higher management aware of GDPR?

It’s mandatory that they have sufficient understanding of GDPR and it’s implications company-wide. Make a demo and introduce them in short what GDPR is to create awareness.

2. Who else should know about GDPR in our organisation? 

Data breaches do not only occur by hacking a computer or server. They can also happen when your support employee doesn’t pay attention to something called social engineering. It’s basically how a hacker gets sensitive information through manipulating human interaction. This requires certain managers to be educated on GDPR and create protocols for their staff. Example how a hacker uses social engineering to gain access to your system:

3. Do we need a Chief Data Protection Officer?

When the authority arrives at your doorstep, they first will ask who’s responsible for data security or privacy within your company. In some cases you’re required to appoint a Chief Data Protection Officer. This DPO role is mandatory if your company is involved in these activities (GDPR’s article 37):

• Data processing which require regular and systematic monitoring of data subjects on a large scale or monitoring of individuals.
• Processing a large scale of special categories of data (i.e. sensitive data such as health, religion, race, sexual orientation, etc).
• Data processing by a public authority or body processing personal data, except for courts operating in their judicial capacity.

If don’t need to appoint one, make sure the authority has one point-of-contact within your company which acts as the company’s GDPR guide and can cooperate whenever they ask for it. You can be fined if you fail to cooperate as described.

GDPR security

---

1. Do we have a full understanding what data security means?

There is an easy way to answer this question: if you find it hard to answer the remaining security questions in this GDPR guide below, it’s time to freshen up on understanding data security.

2. What is our current state on data security documentation? 

You’ll need proof what you did about security to show the authority when asked. All security measures and protocols need to be documented.

4. How are we going to determine that data is actually secured? 

You’ll need to be able to proof you’re actually secure by third-party testing. This can be done by audits, penetration testing, etc. The authority will not be convinced without this proof (= your words will mean nothing to them).

5. When was our last security audit? 

If you’re a larger company and the answer is ‘never’, you already have a serious problem.

6. When was our last penetration test? 

This one is suitable for all company sizes. Penetration testing gives a third-party permission to attempt breaking into your system. The goal is to find security holes and report back to you. They also advice how to fix them so your developers can go ahead and deploy the required fixes.

GDPR server infrastructure

---

Cloud Provider	GDPR compliant?	GDPR source (link)
Amazon AWS	YES	YES
Microsoft Azure	YES	YES
Google Cloud	YES	YES
IBM (Softlayer)	YES	YES
Alibaba Cloud (Aliyun)	YES	YES
Oracle	YES	YES
Linode	YES	YES
DigitalOcean	YES	YES
Scaleway (Online.net)	YES	YES

Updated: May 25th 2018

Note: Make sure the (cloud) servers with touching personal data are physically within EU region. This can be a requirement for some industry specific certifications. The most popular EU server locations are Amsterdam, Frankfurt and the region of Ireland. …Still want to prevent losing money? Here is how you can start:

Implement GDPR into product

No we got rid of the more higher-level topics, we can focus our GDPR guide on the actual product.

1. Make on overview of your data dependencies

You’ll first need to answer one question: where is my data at? We live in a world with cloud services and API’s. This gives a challenge concerning GDPR: data dependencies. Create a simple overview of all services your product is dependent on third-party data or you’re supplying them with data. It can look like this: Now we have a clear overview who we’re in business with and everyone in the organisation can understand it. The second thing you can add in this image is where personal data is transferred to and stored. All those third-parties doing that, will need to be GDPR complaint when you send them personal/sensitive data.

2. Run a scan for GDPR provider/supplier compliance

If you’re not sure about their compliance, time to act. You’ll need to contact them and make sure they confirm they’re GDPR complaint. That image needs to be 100% completed.

3. Run tech analyses: how much do we need to adapt?

Once you complete this image, you’ll have a clear picture if you need to adapt. There may be third-parties that won’t be complaint or can’t change their ways on time. You’ll need to make a decision to adapt your data flows or put restrictions to certain partners to become complaint. This can result in changing API’s, data layer modifications, etc.

4. Create a dedicated Epic for data security

Create an Epic in your backlog only for data security and start filling with stories and spikes for investigations you already discover from the previous point.

5. Review your SCRUM operations

Data security requires a lot of testing. Not mentioning the documentation required. You’ll need to be able to show the authority what you exactly did and when. Is your Definition of Done still meeting those requirements? Do you actually document? Do you have a certain degree of test coverage? Review all of this and adapt to make your SCRUM operation GDPR proof.

6. Start investigations for technical implementation

Once your SCRUM operation is clearly (re)defined and your Epic started to fill up nicely, it’s time to allocates the first spikes in your sprint. Spikes are time-based and their goal is to investigate technical solutions. The result should be stories to actually develop the solution. Complete all spikes first to get a full grasp of how much resources/time you’ll need to become GDPR complaint.

7. Plan your stories on an appropriate timeframe

Once those spikes turned stories, time to plan. By now you should know roughly how much resources you’ll need and how much time till the deadline remains. Don’t plan too lean, keep a buffer to cover any bumps on the road.

8. (optional) Inform third-parties

If you did any serious modifications on your data layer, you’ll probably also need to change request or callbacks to your system. This can lead to some pieces of the system being deprecated. If you haven’t heard of that term, read what it means in my technical dictionary. Inform your third-parties affected by those changes well in advance. This gives them the appropriate lead time to gracefully adapt.

Implement GDPR in SCRUM

Now it’s time to start running. This is just a simple example of how it can work in a SCRUM operation:

Some important elements:

• You’ll need to do more documentation. A good practice is to incorporate it as subtask within those stories. This keeps it proportionate and keeps documentation updated every sprint. A story can only be done once the documentation is proper.
• Documentation should be a living document. Create a living document with versioning. If you use Jira, might be worth it to consider using Confluence or anything similar. The versioning is done automatically. This makes it easy to backtrack what you did as proof. Also nice to link stories within the living document. Now it becomes really easy to create a history of proof without spending extra hours. It can become a invaluable GDPR guide for your organization.
• Testing, testing, testing. There is no such thing as data security without testing. You’ll need to make sure certain security requirements are met before deploying.

GDPR guide: final tips

1. Consult an expert if needed Recommended if this GDPR guide makes you want to delegate this to an expert. Those fines will make this investment make it worthwhile by default.
2. Adding technical debt might be ok. If you discover the full scale of GDPR implementation will have a serious impact on your product delivery, it might be worth it to raise the level of technical debt. This way you minimize the impact and still manage to become complaint on time. I would suggest to not elevate the debt level for more than 3-6 months. If you’re not sure what I mean by technical debt, read my article What is technical debt?.
3. Plan GDPR complaint audits or penetration tests Recommended to do at least an annual penetration test, more is better. Audits are heavier and the auditing party will give you a date until the audit expires to be valid.
4. And last but not least: have an emergency handbook For larger companies, you’ll need to be ready when things go wrong. Create a handbook how to respond to any incident concerning data breaches. This will save your company running into panic mode and create havoc.

Congrats, you’ve made it to the end of this GDPR guide longread! I hope this GDPR guide helped you create more understanding and take the first steps to become complaint. Something that can be added or improved to this GDPR guide? Comment or send me a message so we can make it better together for all readers.

---

Don’t mind sending it to your colleagues or business contacts if you think they can use a GDPR guide like this one.

---