Marie Murphy
I have heard GDPR compared to Y2K a couple of times this week. Mostly by people who don’t remember Y2K and who also don’t really understand GDPR. I am (sadly) old enough to have been there for Y2K and (happily) have developed a pretty good understanding of the operational impacts of GDPR.
I can confirm once and for all – GDPR is not another Y2K.
Apart from the fact that I will never, ever earn the same rate per hour for working on GDPR that I earned for my very memorable Y2K duties on New Year’s Eve 2000 here are another 5 good reasons why GDPR is not Y2K.
Despite the fact that many companies spent two of three years preparing for Y2K – reviewing code, patching systems and testing scenarios, Y2K was over almost before it started. I was on duty in China – 8 hours behind Greenwich meantime. We were on the coal face chiming midnight mere hours after the first major population centres in Australasia. We knew by about 2 in the morning that we were likely to find nothing. By 5 in the morning, we had briefed our colleagues in the UK and US, breathed a huge sigh of relief and gone home.
GDPR is a regime change. A necessary case of regulations and operations catching up with some very fast paced technological changes that have altered the relationship of businesses and governments with our personal data. GDPR will not be all over by 5 am on the 25th May 2018. Perhaps some of the hype will die down. We will all breathe a sigh of relief that its finally here and then we will get on with the very long-term business of becoming and staying compliant.
Y2K was caused by a bad format in a date field. While it potentially affected every piece of software, finding code that used two digits instead of four digits when formatting dates was reasonably straightforward. Fixing it was a bit more complex but still a fairly well contained problem.
GDPR goes to the heart of how personal data is processed. It affects every piece of personal data across the entire data lifecycle and it requires organisations who handle personal data to consider multiple aspects of their data processing operations at every stage of the data lifecycle.
Y2K was a problem in code. It required a technical solution. Software engineers and testers had to figure out if the problem was in their code and to remove it if they discovered it. It required some ingenuity in coming up with workable solutions in many cases but at no point did it move beyond the bounds of being a technical problem that required a technical solution.
GDPR, on the other hand, is everyone’s problem. It requires legal team to work on legal aspects of data processing – contracts, policy statements and data processing agreements. It also requires operational experts to assess data processing risk and compliance, review and renew organisational processes and manage the resulting organisational change. Technical teams need to implement solutions to enable compliant processing of personal data and to keep the data secure. Finally, everyone in the organisation has a role to play in the organisation’s compliance.
Everyone was very nervous of Y2K at the time. What if – despite all our best efforts - we had missed something? We only had one shot at this and the consequences of getting it wrong were potentially disastrous. However, the solution existed in tried and tested techniques. We could carry out code reviews, we could simulate the data rollover, we could code and test the problem and the solution. Those techniques were tried and tested and what was required was the resources to analyse and address the problem.
GDPR is to a large extent untested. It’s a big piece of legislation and with that will come nuances and unforeseen consequences. We need to analyse the articles and interpret them into operational, legal or technical solutions. This can be time consuming and there are the inevitable differences of opinion on how to interpret or how to operationalise some of the text.
Y2K posed a huge potential risk to organisations. If the bug was not properly contained systems could misbehave or simply not function at all. However, everyone was in the same boat. Every business faced the same costs, the same disruption and the same consequences. It was a shared problem and therefore there were shared solutions. There was a huge potential cost to businesses but it was a once off operational cost that would be absorbed and forgotten once resolved.
GDPR will test organisations capability to collect, process, secure and destroy personal data with minimal risk and maximum compliance. Organisations that fail to rise to the challenge will face potential fines and much has been made of the headline figures. However, the experience of organisations that have faced data breaches in the past is that reputational damage is far costlier and longer lasting that any fines.
Y2K was a legacy problem. A technical challenge. Containable. Resolvable. Expensive. Scary! Y2K was over on the 1st January 2000.
GDPR is the future. An updated approach. With far reaching consequences. It requires long term commitment from everyone in the organisation. GDPR is just starting on the 25th May 2017.
GDPR is not the next Y2K*
Sign-up to receive news and information from Fort Privacy
Fort Privacy processes your personal data in order to respond to your query and provide you with information about our products and services. Please see our Data Protection Statement for further information
As a technologist, I am both excited and appalled at the developments in AI and it seems from various surveys that I am not alone. My greatest wish is that we can harness its power for good while dampening its power for misuse. It is early days yet – let’s hope this wish comes true!
Everyone loves a quiz so we decided we would kick-off the new year with a bit of tongue-in-cheek fun.
Continuing the tradition of the Fort Privacy Christmas blog this year we are thinking about Santa and AI. Well, we need to keep these articles topical after all!
