Comments posted to this topic are about the item GDPR - A guide for the perplexed
That is a great article Dave, thank you.
I think one of the issues of GDPR is finding is that the lay person on the street doesn't fully understand the concept of "data".
This is terrifying. Any small business doing business within the European scope of influence should stop - now. There is no likelihood that a small businessman, especially one who sells computer software that has name-linked activation, could ever comply with these regulations. All the businessman could do is incur a MINIMUM fine of 10 million euros, or for my business, 50 years gross revenue - PER OFFENSE, which is impossible to understand what offends.
My business must withdraw from Europe.
SQLBlimp - Thursday, January 11, 2018 2:02 PM
Which bits do you think you'd have trouble complying with? If you've got difficulties then so have I and others. I'm in a position to ask a lot of questions and get a lot of answers
Interestingly, Brent Ozar has decided to stop selling in the EU for now, giving GDPR time to settle in. About 5% of his revenue is from the EU, so he doesn't believe it is worth his time and wants to wait and see how it develops.
This is a great article - thanks.
One key area that I keep bumping into and haven't found a satisfactory SQL solution for is encryption. It's my understanding that GDPR states all personal data must be stored using encryption. When applied to SQL server that becomes a challenge for those of us living in the SME world that can't afford the full enterprise version of SQL (enterprise version includes encryption). The best option I have seen so far has been BitLocker to encrypt the whole hard disk, but this isn't viable when you're using a hosted server. Azure is encrypted, but I find that too expensive compared to cloud hosted SQL boxes.
I would be very interested to hear any comments on the area of SQL Server encryption and GDPR.
The obvious problem is that most software systems developed are not built for all the intricacies of this. Changing an entire software product, that's been around for a few years, to not fall foul of any of this retrospectively is a massive amount of work. Who is going to pay for this work? Not the customer of your product that is for sure they'll go else where.
A bit like Brexit 99% of people are not in a position to take a logical action for this. As in the case of brexit an emotional action was taken and now it's a s$%t show.
Average person on the street as others have said won't understand the implications. It will introduce more complexity for those people. In otherwords now all software they interact with - if being full compliant - will have to ask explicitly - this website you are signing upto, can we have permission to store the details you just typed in? WTF? If you don't want it to be stored don't fill it in, if you don't think it's reasonable for that site/system to have that information don't fill it in. In some cases if you don't enter that information then you can't use the site/system.
Even if you take it on the chin and do all the work. Then you are going to lose even more time/money because if anybody says prove it, how can you? Once info has every been stored that information could leak in any number of ways - screenshots, shared with third party system before you revoked your permission. It is an admirable goal but ignores reality. Fines should scale to the size of the business since large businesses will have more money/resource to put into the required changes.
peter.row - Friday, January 12, 2018 3:37 AM
No, that's not what the regulations say. Under Article 6, the data processor can store the data you just typed in, because it needs to do so to carry out its obligations under the contract that it has just entered into with you. What it is likely to need your consent for is to use your data for other purposes, for example to send you marketing e-mails.
SQLBlimp - Thursday, January 11, 2018 2:02 PM
No, those are maximum fines. I'm not a lawyer, but I understand that fines will be commensurate with the scale of the offence, so if a small breach occurs despite your having robust procedures in place, you won't get fined anything close to the maximum.
a.crossley - Friday, January 12, 2018 2:12 AM
Not quite. Article 32 states that data must be stored with a "level of security appropriate to the risk ... including as appropriate ... pseudonymisation and encryption". I don't know who determines what level is "appropriate", but I think it's fair to infer that not all personal data will necessarily need to be encrypted.
There's a frightening amount of misinformation about this stuff. I suppose that's in part just the times we live in - fake news, social media, contempt for "experts" and so on.
As John Mitchell says there is a lot of misinformation out there. The guidance from the ICO in the UK is pretty straight forward. The act itself isn't unreadable legalese. It puts informed, voluntary consent and privacy at the heart of everything.
There are a couple of situations where you are likely to fall foul of GDPR.
This is not a s%^tstorm. This is a piece of regulation that has taken a long time to formulate, gain agreement from 27 member countries and has had a long running in period.
If you are doing things that cause your customers to complain to the supervisory authority then perhaps you need to look at your processes and the way you handle your customers. Surely that makes good business sense.
Should the supervisory authority choose to audit you then you need to show that you can respond to a customer requesting their data, corrections, erasures etc. You also need to demonstrate that you are taking sufficient steps to ensure that you take reasonable care in protecting your customer's data.
Brent Ozar's case is a bit of an oddity in that clients send him data sometimes unsolicited. In such a case Brent would be a Data Processor and the sender would be the Data Controller. The Data Controller should not be sending Brent personally identifiable without Brent being under contract, having representation in the EU and being sure that Brent has the facilities to ensure that the data is kept safe etc. Incidentally, if PII data is being sent to Brent in the US then existing laws are already being broken.
It is sad that Brent has decided not to continue to service the EU & UK but entirely understandable. I commend him for his politeness and professionalism in responding to responses to his article where those responses fall a long way short of both politeness and professionalism.
David.Poole - Friday, January 12, 2018 7:20 AM
Except that as you say even if you're amazing and no one has a bad word to say about you then if you are audited you could be tripped over by any one of a number of things.
You may be taking steps to protect things, but this new legislation potentially puts stricter rules in place, if you have a long running software product that costs you a lot of money if you want to escape fines.
A lot of thought may of gone into it, but have they actually tried to apply it to a real piece of software to see what that means. All these abstract terms they use require interpretation and could easily be interpreted in multiple ways when it comes to different components of a piece of software.
Isn't it also the case that someone could request that you remove all data about them, irrespective of whether they like what you're doing or not? And thus if you're found to not have complied to some governing bodies interpretation of this then again - fined. Plus there are all sorts of grey areas. For example:
- Customer gives you data, gives consent
- You use it in ways agreed, that could involve a third party.
- Customer asks you to remove data you store on them.
- You removal all data
- Third party contacts them - customer complains, blames you because X(you)-is-the-only-organisation-I-shared-that-with. You then get slapped with a fine because you can't prove that it wasn't you.
Regarding the regulation having taken a long time to formulate and 27 member countries agreeing - well what is the point here? this is governments we're talking about of course it took a long time. But how many of those countries agreed after consulting with software development experts; not many, if any, I'd wager - thus they agreed to something without much thought for what the reality of implementing that would mean, it just looks good on paper.
peter.row - Friday, January 12, 2018 8:15 AM
You have to make it clear to the customer that to fulfil the service they are asking of you then named 3rd party is used and for what facility. The customer has the choice to walk away or accept that this is so.
The customer comes back to blame you for a 3rd party's indiscretion then, if you can show that the conditions of service clearly stated that the 3rd party would be used, then if you took all reasonable steps you are likely to be OK. In the UK the ICO publishes a list of their judgements and in many cases they find in favour of the company. The purpose of the regulation is not to try and snare a business acting in good faith, it's to catch the Equifax's of this world and those that are genuinely cavalier in their data handling.
The fines are big so people take the regulation seriously. In the UK the GDPR is simply a ramp up and clarification of point in the 1992 Data Protection Act. Also in the UK there is nothing to stop a company asking the supervisory authority for their guidance. They won't give you a forensic point by point examination but they will give useful pointers as to where they think you might be vulnerable.
GDPR came into force on May 26, 2016. There have been 2 years to get ready for it to be fully enforced.
A friend pointed out that different organisations have different attitudes to regulation and some play rather fast and loose with their obligations. A bank will look at their regulatory obligations and schedule the stuff they want to do after the stuff they have to do. That may mean that 80% of their IT plan is on regulatory obligations. There are some marketing organisations whose approach is to focus on what they want to do and scream blue murder about red tape imposed by the government when they realise they can't fit in their obligations as well as the stuff they have chosen to do.
Wetherspoons took the nuclear option. http://www.decisionmarketing.co.uk/news/wetherspoons-deletes-entire-email-marketing-database.
On a positive note this could be the regulation that reins in Google and Facebook.
David.Poole - Friday, January 12, 2018 8:47 AM
The customer was made aware of third party usage when they agreed. BUT then afterwards asked you to remove all data. You complied but the third party obviously still has any data you shared with them. Since the customers point of contact was your software then they are going to blame you not the third party.
From what you are saying the company/software would be fine presuming you could show that no such data was being stored any more, is that correct?
peter.row - Friday, January 12, 2018 8:54 AM
Yes, and provided you can show you have the necessary procedures in place. As I said before, I'm not a lawyer, so my advice is worth what you paid for it! As David said, the purpose of the regulations isn't to trip organisations up.
John Mitchell-245523 - Friday, January 12, 2018 9:02 AM
The problem is with all these kind of things they might not be designed to trip you up - but they do. The world of technology is a massive place and thus no such legislation can prescribed any direct helpful advice of how you would update your software to comply. It's all down to millions of developers to interpret and re-factor as appropriate. The enormity of the work this involves is huge - and this lack of reality check is what often grates with such legislation.
The regulations for data use are equally complex in the U.S. just not as transparent or consumer friendly.
Viewing 15 posts - 1 through 15 (of 29 total)