Part I of this is here, if you haven’t read it yet please do so before reading this installment, it will help to establish context.

So, after geting the most repeated fallacies about the GDPR out of the way let’s take a long look at the real life impact of the GDPR and why it is worded the way it is, after that we’ll look at some of the more important ‘nuts and bolts’ that will help you to decide what to do.

What’s important with any law is - besides the letter of the law - what the spirit of the law is, the laws intent. In this case the intent is to curb some of the worst excesses in terms of privacy violation by corporate entities and to put control over their data back in the hands of the owners of that data: the private individuals that are the subject of the data (hence the term ‘data subjects’). There are countless examples a short search away of such violations, I’m not going to catalogue them here because there simply isn’t enough time in a day to do so but rest assured that the state of affairs is such that regulation could not come fast enough. Regular readers of my blog know that privacy is a subject that is dear to me and as such I welcome the GDPR and hope that the law will have its intended effect. Judging by the number of emails I’m receiving from companies that are almost begging me for consent to continue to spam me this is probably the only law ever that has a measurable positive impact in my life before it has become enforceable. (Ironically, these companies are breaking the law by sending these messages…)

Privacy is an important thing, it is so important that the framers of the Universal Declaration of Human Rights saw fit to include it in their short list of things that everybody should have. At the same time companies try to make money every way they can and if violating someone’s privacy is a quick way to make a buck then it sucks to be you. So it shouldn’t be a surprise that lawmakers have seen fit to put together a law that protects this right to privacy, and it isn’t a surprise that such legislation starts in Europe because we have some very good local examples of what a lack of privacy can do to people’s lives.

Depending on the kind of data, the size of your organization and the amount of data you process as well as your relationship vis-a-vis the owners of the data the impact of the GDPR can be anything from ‘nil’ to ‘huge’ with associated costs. I’m going to try to give a rough guide to how the new EU legislation will most likely impact your company and what your expsosure is.

First of all, let’s look a the kind of data that you are processing. I’m going to look at several different scenarios to gauge the impact of the GDPR on each of those.

Kinds of data

Data comes in many different kinds, there is data associated with a person (an individual) and there is data that is not associated with a particular individual. Data that is not associated with a particular individual is not ‘in scope’ when it comes to the GDPR unless that data can be re-associated with that individual. This means that to all intents and purposes you should focus on data associated with a particular individual. In the context of most businesses operating online this data will be stored in a ‘profile’, a record or series of records that contain an identifier that can be used to assign the record to a particular person. Examples of such profile data are your social media postings, your medical history including your x-rays, the data an advertising agency keeps on you and so on. What the GDPR clarifies (and which was already the law anyway, but which companies routinely ignored) is that you are not the owner of that data. You are merely the steward of the data, and that holding the data is a liability to your business. In other words: data is only an asset to your business if the value of that data outweighs the costs required to be a proper steward of that data. And being a proper steward of that data requires all kinds of processes to be in place (which you should have had anyway!), including a facility to delete the data at the first request of the user unless you are required to keep the data by law, to allow for corrections of the datai and to give the ‘data subjects’ (the individuals) access to the data that you hold on them.

If that sounds like a burden to you then yes, you are right, it is a burden. But then again, data life-cycle management makes good sense, after all if you are hanging on to data that you have no business having or if you refuse to correct wrong data or if you refuse to tell people what you have on them then your company is not acting in the interest of the people whose data it holds. And that is a key item: the EU legislation has been written from the perspective of the citizens of the EU, not from the perspective of those that happen to come in posession of data on those subjects. Their interests are legitimate, but secondary.

The kinds of data that companies hold will have a significant impact on the burden of the GDPR, as a rule, the more critical the data to the individual, the higher the burden. So the burden for data that is already public is relatively small or non-existent. The burden for data that is highly confidential, such as your medical records or your financial dealings is much higher. The good news is that this proportionality was already well known long before the GDPR took effect and that’s why banks tend to work harder to keep your data private than that e-commerce store where you bought a pair of socks last week. Of course not all banks were equally concerned with this and some banks will see a larger amount of work under the GDPR than before. And one hospital may have done a better job in the past than another. This goes for businesses just the same, those businesses that already had their house in order and that have automated procedures in place and that in general have put themselves in the position of being stewards rather than owners of the data they hold are likely in a good position when it comes to dealing with the GDPR.

So it’s clear that the kind of data you hold on your data subjects makes a big difference.

Then there is the kind of data that has special consideration: PII. PII is short for Personally Identifiable Information. It is everything that allows you to find out who the data is about. Examples of obvious PII are full names and social security numbers. Not so obvious: an IP address. Really not obvious: the fact that you have a rare disease coupled with the name of the small town where you live. And many more examples like that. The simplest solution is to deal with all data that you hold on an individual as though it is PII. Better safe than sorry. But if you feel you must treat some of your users data in a different way then you need to carefully weigh what data you treat as PII and what data you are more cavalier with.

Quantity of data

Companies that have thousands of records of data (for instance: an e-commerce company that holds a record of each sale) have a different exposure to risk than those that hold millions or even billions of records of data on their end users. For that reason such companies (which are most likely larger anyway) will have to expend more effort and will have face a larger burden to become compliant than the smaller ones. Yes, the aforementioned life-cycle management is going to be the same amount of work for a small company as it is for a large one, but if you could do the work to collect the data there is no excuse for not properly managing it. That’s simply a cost of business. But SaaS companies that handle large amounts of customer data will want to make extra sure that all the i’s are dotted and the t’s are crossed because they are much juicier targets for wannabe hackers and that increases the risks of having that data exposed. Note that there are exceptions for instance in order to keep your bookkeeping in order you will have to record a certain amount of data and your local tax office will have it’s own rules about how long you should keep such data. But that is your bookkeeping, which probably has little to no direct connection to your live web services, and is only concerned with actual sales and refunds.

Size of the organization

The burden of compliance on a small organization will be lower because having a dedicated DPO (data protection officer) or CCO (chief compliance officer) is not going to be required for SMEs unless they deal with very large volumes of data or deal with very sensitive data. And in those cases you probably want to have that dedicated person anyway so the law really doesn’t make much difference.

But very small companies (say a 1 person company) dealing with extremely high risk data would do well to consider at least hiring an outsider for a bit to ensure that they are not exposed to extreme risks. In some cases, for very small entities processing very small amounts of non-critical data a DPO may not be required at all. Even then, since it is free I would advise to assign the role. Better safe than sorry and like that you are also immediately covered when the business grows.

Taking that all together

So, if you’re a small company and you deal with limited amounts of non-critical data then the impact is very well manageable. Somewhere in the middle, say 20 FTE (full time equivalents) and highly critical data the burden will be proportionally much larger and if you run a very large company then you most likely already have people dedicated to compliance anyway. So it is true that the law is not hitting all parties exactly equally but at the same time given the importance of the issue the rights of the data subjects outweigh the commercial interests of the companies and if the data was worth collecting in the first place it is also worth protecting and properly disposing of when you are done with it. And this difference in impact is mostly a relative one, in an absolute sense large companies and companies with lots or critical data will expend more to ensure they are compliant than smaller ones, it’s just that for the smaller ones the impact will be larger relative to their total turnover. This is a well known phenomenon and applies to all aspects of running a business, it’s called ‘economy of scale’ and is one of the reasons why software and software based services are so lucrative: the economies of scale are enormous.

Things you can no longer do

• store all the data you can get your hands on forever

So far the norm for storing data on end users seems to have been ‘until we run out of diskspace’, and when that happened we found out that disks had gotten cheap enough to stop worrying about this altogether and simply append data without the possibility of ever removing anything. Yes, you read that right: up to the GDPR companies had a habit of never deleting anything. Even if you asked them to delete your data - which they grudgingly might have taken action on - the accepted solution was to mark the data as deleted but to leave the data itself in place. That’s going to go away now: if you request a deletion it can no longer be ignored and the data really has to be deleted. The only exception is if you are by law required to keep the data, but in that case I would advise to keep it in archival storage only.

The situation with backups is a little tricky - and this is one more of those areas where there is a lot of fearmongering saying you can’t possibly be compliant - but it is actually very simple: you keep the keys of the deleted records in a separate log which you back-up as it is written and if for any reason you want to restore a backup you simply re-play the deletion requests starting from the timestamp of the backup. That way backup restoration can not result in accidental revival of deleted records. If there are concerns with dangling foreign keys or there is the potential for key re-use you could choose to overwrite the relevant data with blanks. Note that this is similar to pseudonymization, which if only applied to PII is probably not enough to ensure compliance if other data that you do retain can be used to reconstruct the data that was erased. Real deletion is by far the most secure way of dealing with the deletion requirement. This all assumes that your backups are properly encrypted and that the keys are not recoverable without some kind of intervention from the people responsible for operations.

• ignore requests for deletion, correction or insight from your users

The burden of removal requests, correction or insight into the data you hold on your users (or ‘data subjects’) can be quite significant. This is where automation shines: self service and a one time investment in time and effort pays back manyfold over the years that follow. Ignoring such requests will sooner or later cause an upset individual (could be me) to contact their local Data Protection Authority to file a complaint. The first time this happens the DPA might ignore the complaint, because I suspect they will be quite busy in the near future. But they probably will start a file. And if that file gets thicker because more people complain about your company then sooner or later someone will be tasked with setting up a conversation with you. This conversation will be along the lines of ‘we have received multiple complaints that you are purposefully ignoring legitimate data subject requests, please explain yourself’, after which you - brazen as always - explain that you feel the law is too burdensome to be complied with and to hell with all DPAs. The DPA will respond along the lines of ‘we are very sorry this is how you feel, however, you too will comply ‘or else” where the ‘or else’ bit will be a warning about what kind of fine you can expect if you continue to ignore the law. Then, some time passes. A new user files a complaint. This gets added to your file. And while it is being added the clerk doing the filing notes that you have been warned already. This is where it gets interesting. This time the DPA will most likely issue a ‘binding warning’, they will issue a directive that you ignore at your peril.

A third time would be best avoided. You will be fined. You may choose to ignore the fine because your company is incorporated outside of the EU. But the EU regulators saw that one coming: you have to have something called a designated representative in the EU in order to do business there. Yes, you read it right. That’s probably the most invasive change the EU could have picked, you need to establish yourself through a legal proxy in the EU. If your business already has a presence there then that will be your designated representative. If not you’ll have to get one, there will - and already are - companies that will offer this service for a fee to the companies that it applies to. So as soon as you get fined the designated representative will be notified of this. They most likely will have a contract with you and will also have a representation in the country where you reside, and part of the contract you have with them is that you indemnify the representative for any and all fines collected through their representation of your legal entity. So then you have the choice of fighting your own representative in court in your home country or coughing up the fine.

• wipe breaches under the carpet and pretend they did not happen

People are usually shocked when I give them some stats on the number of reported breaches for the year to date. The numbers are simply scary and that’s before you come to the realization that the vast majority of data breaches is never reported so they are not counted in the statistics. There are two reasons for this, the first is that a large number of data breaches is never discovered, the second is that even those that are discovered are not always reported. That’s ‘Game Over’ territory as soon as the GDPR is enforceable, not reporting a breach is one of the worst things you could do. It’s both irresponsible towards the people whose data has been breached and it potentially makes matters worse because you are taking away an important tool from the regulators: their ability to measure how big the problem is so that they can spend their effort there where it has the most effect. Of course it is bad PR. But then, there was the option of spending some more resources on security and to reduce the possible haul of such a breach. And if you did all that then at least you have a good story to tell. Responsible disclosure in case of a breach will go a long way towards establishing good faith on your part. Wiping the breach under the carpet could work but if you are found out you can fully expect the book (and the lectern) to be thrown at you.

• pretend the data on your systems is yours rather than the end-users

The data you process on behalf of your users is their data. The GDPR is not ambiguos on this front at all, hence the consent/delete/correct/insight (and data portability) parts of the law. You at best are a steward of that data and if users consent to specific uses of the data then you are allowed to process it. But it isn’t yours and as soon as you start to think of it as yours it is only a matter of time before you will create some use case that is against the law. Don’t do that.

• treat data security like it is optional

Companies have a rather strange attitude towards security: it is treated entirely as a cost with zero upside and if possible it will be ignored. The GDPR has finally given the people tasked with security at least one stick to wave around in case their arguments are ignored, the GDPR fines are potentially so large they tend to get the undivided attention from management. Management of most companies is risk averse to the point that they would rather get their security in order than to face a possibly very large fine (even if the chances of that fine materializing are slim to none). So even if that isn’t a very large stick it is better than nothing and it seems to have the intended effect, the companies that I look at seem to have woken up to security no longer being an optional item to take care of when they have retired.

• sell end user data with abandon

Just like you can’t sell a car or a house that isn’t yours you can’t just go and sell the data that users entrust you with (or that you gather from their devices, such as location information and other good stuff). If you wish to sell your users data you are going to have to obtain consent. And that consent has to be freely given with the express purpose of the transaction you have in mind, in other words there is a specific purpose. If you feel like riding the line here you could try to argue that ‘selling your data to unspecified partners’ is a one time blanket consent that a user could give but if I were a user I would likely not give you that consent. But if - in the interest of keeping the lights on in your fine institution - you instead ask consent to sell my data to ‘Pathfinders Inc, a company that wishes to analyze my location data to determine where traffic jams occur’ then I might agree. So obtain consent if you intend to sell data and make that consent as explicit as you are comfortable with in order to optimize the number of people that ‘opt-in’ versus the amount of work you have to do to re-obtain consent. And always remember: consent once given can be withdrawn, so you will have to have a provision in place on how you and your data buyer will deal with the withdrawal of that consent.

The easiest way to deal with all this is of course simply not to sell data in the first place.

• fail to obtain consent

This is one of the areas where the GDPR is extremely pointy and clear: if you wish to process a users data for a new purpose you will need to obtain consent. It is almost comical how many companies seem to suddenly realize that they’ve been spamming large numbers of people without their consent and they now - sheepishly and rather belatedly - figured out that maybe they should ask for that consent before the clock runs out because even such an email would likely be seen as a violation of the law! (And rightly so imo.) So resist temptation and do not use data that you already have for entirely new purposes.

Things you will have to do

• enable data life-cycle management

Data has a live-cycle, just like everything else. Endless appending is not an option, you need to plan on how you will acquire the data, process it, store it, allow the owners of the data to modify and correct it and eventually on how you will delete it. To be fair to the creators of the GDPR: you should have already had this and if the law had not existed at all you still should have already had this. It’s a common sense thing and it shouldn’t take a law to make this happen. Think about it: at some point your data subjects will die. That would indicate that there is at least one valid reason why there should be an end to storing data on a particular individual no matter what.

• figure out what data you have that is in scope for the GDPR

  This sounds easy, but for large companies with lots of data and bad processes it can be a lot of work. If you have not started timely with this it is doubtful you will be ready with this in time before enforcement starts. Even so, you should still do this and for each data set that you have you will have to determine the following:

  • find out what is in the data
  • determine whether or not it is ‘in scope’ for the GDPR
  • determine if it is in scope if you want to keep the data
  • securely erase it if you do not want to keep the data (and update any software that relies on it)
  • alternatively, anonymize it in such a way that the data can no longer be used to identify individuals (this is a lot harder than it may seem at first glance)
  • document that you have it and how it gets processed if you want to keep it

• ensure your systems are secure

Do your level best to ensure that the computer systems that you use especially those directly facing the web are secure. Read up on security, find the person in your organization that is most experienced in this field and have them analyze your systems from a security point of view. Implement their advice and make security a part of your organzation from the top all the way down to the bottom.

• disclose all uses of the data you collect in your privacy policy

Try to make your privacy policy short, to the point and complete. If you plan on doing something with the data obtain consent and disclose all uses in the privacy policy so that someone can review it. If you make changes to your privacy policy publish a changelog.

• enter into DPA’s (data processing agreements) with all those that you farm out data processing to

Each and every firm that you farm out data processing to should be under a special contract with your organization called a DPA (confusing, this means Data Processing Agreement), no exceptions. If a party does not want to sign on the dotted line ditch them. If you don’t feel comfortable with giving them access to your crown jewels ditch them. If you feel that you could do without that particular service ditch them. By far the easiest way to deal with third party risks regarding the data that you administer is to ensure that it never leaves your premises. And if you have to make sure that DPA is executed properly. And make sure that your counterparty is able to deal with the withdrawal of consent after the data has already passed on and that they in turn do not under any circumstance pass the data on to others without your explicit consent (in writing!).

• disclose those companies that you have DPA’s with

Tell your end users about which companies process data on your behalf. A good place to disclose this is in your privacy policy.

• obtain consent from your users for the use of their data

Before you can use data supplied by individuals you have to obtain their consent. This is not just good manners, it is a hard requirement. This goes for the initial use of the data after it has been collected and all subsequent uses of the data.

So if you have a brilliant new idea that will result in a new use of the data that you already hold you will have to update your privacy policy and you will have to re-obtain consent for the data that you already have.

• plan for the withdrawal of consent

Consent can not only be given, it can also be withdrawn. And that withdrawal also affects your relationship with sub-processors, parties that process the data on your behalf. Withdrawing consent should be no harder than giving it.

• report breaches immediately if they cross the reporting threshold

If there is a breach of your system that is above the reporting threshold (which is quite low!) then report it immediately. You have 72 hours, if you establish a breach protocol it is much safer to do this on day one rather than to wait until the last moment, because any hickup in the reporting process will slow you down and will cause you to miss the deadline. If you deal with very sensitive data always report the breach, even if it is a small one, the damage to your data subjects could be substantial which increases the risks of them going to their local data protection authority and if they do not have a report from you about the breach you will have a fairly large problem.

Things you probably should do

• store data in off-line systems if you don’t need it on the live systems

If you don’t need data right now and on the live system (for instance, data that is historically important but not part of the current dataset) then you should move that data to off-line systems. That way if there is a breach of your system the damage is limited.

• act in good faith, try to respect the spirit of the law

I’ve seen lots of examples over the last year of people that were trying to be clever, to try to find a loophole in the GDPR that would allow them to continue with ‘business as usual’. Some of these examples were of the very worst and contrived variety, some were more reasonable but still clearly in violation of the spirit of the law. If you really insist on going to court over this by all means find that line but if your budget is limited and you’d rather not be fined or have an expensive court case to deal with then please act in good faith. That will go a very long way towards convincing regulators that you did not intend to do something bad and you were looking for ways to get away with it.

• keep your users (‘data subjects’, ‘individuals’) interests first

If you put your own interests over the interest of the data subjects and you make use of the data as if it is yours then you are doing it wrong. Consider the data that you hold borrowed and be a good steward of that data. Keeping your users interests first has other effects as well, for instance it makes for happy users, which is eventually good for business.

• delete data that you no longer use

If you have data that is no longer useful to you don’t keep it around ‘just in case’. Get rid of it. This vastly limits the amount of damage a breach can do and reduces the chances of data that you should no longer have being exposed in a breach. After all a breach is already a bad event, no need to make it worse by leaking data that you had no use for in the first place. Newspapers love large numbers, if you lose enough data you just might find yourself to be front page news in the worst possible way. Treat data as though it is nuclear waste: get rid of it as soon as you can.

• use the GDPR as an opportunity

If there are 10 parties offering the same service and only one of those 10 has decided to become compliant with the GDPR, and in fact treats all their customers (and their data) with the same level of care and respect then in the short term the other nine may have an advantage. They don’t have the costs associated with compliance and they can concentrate on expending those resources on features and marketing. But in the longer term I suspect the party that took the high road will win the race. Because that party will not be subject to fines, that party will be able to sell their product to 100’s of millions more individuals and that party will be able to use their GDPR compliance as an easy to recognize badge of approval. The chances of their data leaking (which causes substantial brand damage) is lower and the user trust in the brand will be correspondingly higher.

• do annual pentests / audits

It’s good practice to ask outsiders to try to ‘rattle the doors’ on your systems to ensure that they are secure. This is a relatively costly affair and probably out of reach for most reall small companies. But if you have a large enough business this will definitely help you to sleep well at night. After all, if your doors are locked better than your neighbors the chances are high you will be passed over. So don’t see this as an absolute affair (there is no such thing as perfect security), treat it as a relative one: you don’t have to be able to outrun the tiger, but you should try to outrun the guy next to you.

• if your company is large enough and the kind and quantities of data you store warrants it get ISO27001 certified

ISO27001 certification is not a proxy for GDPR certification. But absent GDPR certification (for now) it is a pretty good proxy because even if ISO27001 does not address privacy directly it does require you to have substantial processes in place around the theme of security and this in turn will vastly reduce the chances of exposure to a security breach and the associated reporting duty. On top of that those companies that I’ve looked at that were ISO27001 certified as a rule also had their house in order when it came to compliance with privacy legislation. It forces you to think about data as a liability, rather than an asset and that particular mindset is a good one to have when you are dealing with end user data.

• read the law at least once, or if you have employees, ask one of them to read the law at least once

Reading the law is actual work. If you’re not a lawyer it will probably cost you at least a day and maybe more. This is useful because the law contains a lot of things that are informative and that will help you to form a coherent picture about what the law really embodies and how it applies to you and your business, as well as to you in your capacity of private individual whose data is processed and stored by other companies. If you can’t afford the time (though I personally believe every business owner should be able to find the time to read a reasonably compact document that has the potential to impact their business) then delegate it or at least read the excellent WikiPedia page on the GDPR until you are familiar with the terms, the intention and the general scope of the GDPR. That will help you in your discussions with others and will help you in determining the impact for your business.

• cut down on the number of parties that you ship your users data to

The more parties that you ship you users’ data to the bigger the chance of a mishap. What goes for not having data that you don’t need goes doubly so for not shipping data to parties that are not essential in the kind of processing that you do. An example of such an instance would be a company that processes medical data for patients enrolled in hospital treatments. You could embed an analytics tag of some third party analytics provider on the pages where you collect the data. But your need to collect statistics is in no way outweighed by the patients’ needs for data confidentiality and so you’d be better of to remove that analytics tag on those pages. This may be a minor inconvenience but it is much prefered to leaking this data.

Like that you have a minimal version of a GDPR impact study in your head and you will be much better capable of figuring out if, where and how your business should adapt to the new legislative environment. In general this is good practice when a new major body of legislation that might impact you is launched. If your business is serious enough then you might want to engage the services of a professional with the required background (a lawyer specialized in privacy, for instance). Even then it is good to know the basics and you should probably still read the text of the law.

Things you probably should not do

• pretend you don’t know about the law and hope it goes away

Ignorance of the law is never a good defense. Besides making you look dumb and careless it would be the easiest way out of every law that you do not wish to comply with. Just pretend you don’t know about it and the problem goes away. Toddlers tend to do this when they close their eyes: “I can’t see you, so you can’t see me”. It doesn’t work for toddlers and it won’t work for you either.

• assume the law doesn’t apply to you without properly researching if it does

There are exceptions to rules and you can read up on them to figure out if the law applies to you (if your situation is ‘in scope’) or if it does not. By researching this properly you may find out that if you thought the law does not apply to you that it does, or the other way around. Either way, knowledge is power, in the one case you will be forewarned, in the other you will know you are in the clear.

• try to armchair lawyer your way out of having to comply with the law

I’ve seen lots of this: people who have not bothered to read the law or who are looking for that one line that they can use to justify their stance. This is silly and most likely will lead to some serious disappointment down the line. If you read the law and you gain some insight into it you will see that the law is written in a way that creates a lot of leeway for interpretation. This is a good thing, even if you would like to have things spelled out. The reason why it is good is because it allows the regulators to throw the book at those that would like to go for the narrowest interpretation possible whilst at the same time ignoring the spirit of the law.

This strategy works in some countries (notably: the USA), but it really does not work in Europe. This is probably the biggest clash between those two worlds to date and the frontier is one that matters a lot so take this from a European that has had a reasonably large exposure to both US and EU law: the systems are very different in this respect and if you comply with the spirit of the law but break the letter then in almost all cases you will be fine. If you try very hard to comply with the letter while at the same time ignoring the spirit of the law you will hit the wall, and probably quite hard.

• break the law knowingly

This is an obvious one, but I’m putting it here just to make sure: Do not break the law knowingly. If you do so you are setting yourself up for future failure. Either comply with the law or shut down your service for EU access (assuming you can realiably do so, which as I’ve already noted is hard).

If you have very deep pockets and are willing to go to court, and then eventually to the EU high court to challenge the law or aspects of it then more power to you, you will have to break the law knowingly to invite a challenge from the regulators. But for most ordinary companies this is not a viable path, this is best left to the Googles and the Facebooks of this world.

Things you could do to make your life easier

• apply GDPR principles globally

Note that all these make good sense even absent the law, it’s just that now that the law is there they can help you to reduce your exposure and will go a long way towards demonstrating that you are working to keep your users interests close to heart.

Frequently Asked Questions regarding the GDPR

Once more: what follows is not legal advice even though it suspiciously looks like it. If you are going to implement any of this think of my reading of the law as an 80% or so solution and you will likely need to get to 100% if you wish to minimize your risks and like all advice it is worth what you paid for it, in this case absolutely nothing. Even so I have done my best to not spout nonsense. Buyer beware!

• Do I need a (dedicated) Data Protection Officer?

That depends on the size of your organization, the kind of data and the amount of data that you have. If processing other people’s data is your bread and butter and the quantity and kind of data indicate that there is substantial risk in case of a breach and your organization is large enough then most likely the answer is ‘yes, you do’. So medical, financial and advertising companies of any size will almost certainly require having a dedicated DPO. If your company processes very little data (say thousands of records) and the data is not super critical (say you are selling clothing online) then you will need a designated DPO, in other words you need to assign the role of Data Protection Officer to an individual that most likely also does other stuff. It’s not ideal and in that situation you will have to take extra care to ensure that the DPO has sufficient independence in their role. If you do not process end user data at all then you wil not need a DPO.

• Do I need an EU designated representative?

  If you are doing business in the EU but you are located outside of the EU then yes, under the GDPR you will need a designated representative. This is definitely a burden and I sincerely hope that the free market will bring the cost of this down to a level that even the smallest businesses will be able to solve this in a cost effective way.

  The tasks of such a representative are:

  • The representative is an authorized agent to receive legal documents
  • can be subject to enforcement proceedings in the event of a company’s non-compliance with the regulation
  • to be a direct contact with the authorities
  • to be a direct contact for data subjects concerning their data processing

  If you feel this is unfair then keep in mind that it is only to level the playing field between foreign companies and EU players. The unfair part is that for EU companies there is no additional burden to have a registered representative, they represent themselves. The alternative is reciprocity, a bit like what happens with traffic violations within the EU. The members states have agreed to enforce each others speeding tickets and parking tickets and will collect for their foreign counterparts. But as long as only the EU has legislation at this level reciprocity is not an option. If in time there will be similar legislation elsewhere then a reciprocity agreement could be entered into and then the need for a local representative will go away.

• What is my exposure if I ignore the GDPR and just keep going as I used to?

  That is a very dangerous question. What your exposure is depends very much on what you do. If you are super concientious in how you deal with user data, already have all or most of the procedures in place but do not otherwise change your ways because of the GDPR you are obviously going to entertain some exposure under the law. The regulators will probably take a dim view of this if they are required to interact with you. If you are a really small entity (say a private bulletin board with a few 100 regular visitors) then you might even get away with it. But I would advise against this strategy. All it takes is a couple of angry users that report you to their respective DPA if you do not comply with legitimate requests and you will have a hard time explaining why you chose to ignore the law. You might spin a good yarn and you could try to bluff your way through this but if there is one thing that I’ve learned over the years by looking at lots of companies there is almost no strategy so dumb as to underestimate the competition.

  The burden of compliance is definitely non-zero for most somewhat serious businesses, but then again, the upside is access to a market of 300 odd million people. That’s got to be worth something on your end, and what better way to signal that you are a trustworthy business partner than to treat the data of your customers with respect.

• Can I store IP addresses?

Yes you can, but in quite a few instances they are considered PII and even if the norm is for any and all software to log this information if you don’t really need it you are better off without. But if you do need them ensure that you remove them or zero out the last octet once that need has passed, alternatively, rotate your logs fast enough that you can drop the logs before too much time has expired.

• Can I send marketing email?

Yes you can, provided you have obtained proper consent to do so. And no, you can’t mail your users to obtain consent after May 25th, you actually shouldn’t be doing that anyway. Any addresses that you have collected without consent should be considered lost. In general such messages, collectively classified as ‘SPAM’ are off limits when sent to private individuals.

• Can I have my users check a box that says they opt-out of their rights under the GDPR?

No, you can’t, full stop.

• Should I hire a privacy law specialist?

If you can afford it, by all means! But make sure you get some references first before you jump into a contractual relationship with anybody.

• Should I obtain ISO27001 certification?

ISO27001 is not directly related to the GDPR. However, it does take care of a lot of the question marks raised by the authorities in case of a breach: Have you done enough to ensure that it would not happen (even if it did, with hindsight). ISO27001 certification is essentially an outside party verifying that you did indeed do your homework. After that of course it is still possible that you will have to deal with a breach, it could be an inside job or an oversight. But at least you did your best to avoid it.

Another advantage of having ISO27001 certification is that it for the moment seems to have some proxy value, businesses will be more likely to do business with you in the new legal climate if you have obtained this certificate because they will assume you have your house in order.

The downside is that such an audit isn’t cheap (so it is only something that a certain sized business can afford) and that it is a repeating cost (annual audits are the norm).

• How do I reliably determine if someone is an EU resident?

The short version is that you can’t. The slightly longer version is that you could ask but someone could lie, you could use a geotargeting library but it could be faulty, someone could use a proxy or a satellite connection and so on. This is more than just a little bit annoying but you can not with 100% certainty determine where someone is located.

• Should I have two tracks in my website, one for EU residents and one for the rest of the world?

You could do this, but it would be a lot of work. And in the end, wouldn’t you want to extend the same courtesy to people from other places than the EU? It would seem like a complete waste of resources to have to maintain two separate tracks for similar data and similar users all so that you can withhold certain fairly normal features from people from outside of the EU. Personally I’d use it to my advantage and advertise loud and clear that people from other places get the same level of protection and the same level of control over their data. That would possibly also give you a leg up on the competition if they do not do this. And conversely, it could work against you if your competitor does decide to go that route.

• What about my ‘hobby business’?

The GDPR does not make a distinction between hobbies and businesses and it seems right to me that it does not. Whether it is a hobby to you - and hence not commercial in nature - makes no difference whatsoever. As soon as you start the collection of data on private individuals from the EU the directive kicks in and you will have to find a way to be compliant.

• What about my open source project?

Open source software is not a service, it is software. As long as you just write software and distribute it without recording anything about those that receive the software your operation is not ‘in scope’ for the GDPR. As soon as you run an online service using software you wrote yourself - even if you open source it - your project is in scope.

• How do I deal with - insert some wild edge case here?

There are many such wild edge cases, too many to list here but let’s take one that I’ve seen multiple times:

If you are worried at this point in time about how you should deal with the situation where an EU resident is visiting the United States and you are no longer able to accurately determine their location then you are probably worrying about the wrong thing. EU legislators and data protection authorities are not going to jump out of a bush near your house to fine you in such cases. But you should still treat removal, access and update requests from these users (and probably all others) as though they are legitimate, after all why would you want to ignore them?

There is a good chance there will be a part three to this series, I’m still mulling that over, these posts are a lot of work.