Mr. EU-wide (Information Security): GDPR: The EU's answer to data privacy
23 replies, posted
They will have to focus on technical security, including the use of encryption and the robust application of security patches.
But they will also have to use data minimisation techniques, including pseudonymisation - a technique that replaces some identifiers with fictitious entries to protect people's privacy.
The watchdog responsible for all this in the UK will be information commissioner Elizabeth Denham.
"We will have more powers to stop companies processing data, but we only take action where there has been serious and sustained harm to individuals," she explained.
"What this new fining power gives us is the ability to go after larger, global and sometimes multi-national companies where the old £500,000 fine would just be pocket change."
All of which means that the GDPR should make our personal data safer and less easily obtained by those we don't want to have it.
But there will be teething pains and some organisations that do not adapt in time will suffer.
And forget the idea that this could all become moot post-Brexit.
Interesting, but I have a feeling a lot of companies are gonna skirt this as hard as possible. If they skirted the rules before, what's to stop them this time?
well something is better than nothing I guess?
The fines are huge for non-compliance, to be honest these laws are what companies should really be doing anyway. Compartmentalising data and requiring consent for mailing lists is a great step.
A good first step, but I can almost guarantee that big companies like Facebook and Google will try to find any sort of loophole and skirt around these new rules in an effort to keep doing what they always have.
A lot of the rules are way, way overdone IMO.
Trying to get my company to deal with this has been like pulling teeth.
As a developer it's a nightmare. I've yet to find a concise list of exactly what the law requires me to change is impossible.
It's just pages and pages of legalese to read through, using very vague terms.
It's been kinda fun/ terrifying watching various companies go from "lmao we'll just record everything ever in case we need it" to "oh shit our databases will literally fall apart if we delete things like we're meant to".
From what I've researched there's a few key points:
Only process data you have a legal basis to process. Processing is pretty much anything you can think of. The legal basises can be the users consent, because it's required to fulfil your contract with the user (e.g. to provide the service), or it's in the businesses legitimate interest (that doesn't include marketing). There's a few more but that's all I can think of off the top of my head.
The ability to easily find all the personal information your organisation holds on a person.
The ability to erase all your personal information about a user if requested. You don't have to delete it from backups but you do have to ensure that the data is removed again if you restore from a backup.
Employ relevant technological measures (such as encryption) to minimize the impact to the user if data is stolen.
Notify the ICO within 72 hours of a breach, although if the data is encrypted I don't believe you have to. Notify users within a "timely manner" if it's likely to impact them.
These are all just my personal notes, and don't take them as straight up legal advice. This should be dealt with at the organizational level rather than at the developer / operations level.
Sadly, as 3-man company I am both director and developer haha. That's roughly what I've surmised, too.
Pretty sure all I actually need to change is clarify the ToS users agree to on sign up a little bit.
The identifying and proving the user agreed part is confusing though, we currently store signup IP and date which I assume is enough.
Regarding consent you should make sure it's clear to the user, don't use pre ticked boxes, and be able to refer to exactly what the user agreed to. What most companies are doing for simplicity is just storing the text not to the checkbox.
I think you can reasonably say that the user agreed to it if you stored that, some companies are using double opt in though. So they sign-up and then get an email to confirm with a link.
Yeah, we also confirm emails before sending them anything email-wise, but we don't require that to use the website. So they could use a fake email, but if they lost their password they're fucked really.
I've been working quite a lot with GDPR recently and have done some consultant work with customers. We've also partnered up with lawyers to get the data controller and data processor agreements templated that we can sell.
As far as the consent stuff goes, what I've been told by the lawyers is that, at this point it's a bit of a grey area and there's no case laws for it yet, obviously. The conclusion we arrived at, is that, it's enough to basically have a boolean in your database representing the yes/no, some way of referring directly to the agreed text, I.E. when you update your privacy statement you still need the original text and something uniquely identifying the user (i.e. their username, IP + date, whatever you want). I personally also save CreatedBy and ModifiedBy as part of all of my database operations to be able to point to "this guy did something last, at this date", but it's not strictly necessary.
The only remaining part is that you need to be able to argue for who has access to modify that data. As few as possible obviously and only those strictly necessary.
I think this is a fairly good foundation, but a few really important points that needs to be added:
All data needs to be timed, I.E. there has to be procedures in place (and documented!) for deletion of data at the appropriate times. For example in Denmark, you have legal precedence to store all accounting data for 5 years, because that's the accounting law. But you must have a process in place, automated or not, for deleting that data after 5 years, as by then you can no longer legally store it, unless you have some other form of consent. (Article 5)
All your data processes must be documented and added to a 'Records of processing activities'-document. This must be able to be handed, physically, to the authorities in case they show up at your door step (Article 30).
Everything must be backed up, or atleast, possible for you to recreate in case the data is lost. We have a lot of accounting customers and they have a bit of a problem with all their physical receipts from their customers. Because, technically, they need to photo copy them and have them stored seperately, in case their building is destroyed or something. (Article 32)
You must have a signed document from your data processors as well as being able to provide the same to all your data controllers. (Article 28)
Companies with less than 250 (iirc) employees are exempted from this bit unless they are handling a large amount of sensitive data I believe.
I work in education sector at the moment, and they enforced us to do online training and test on GDPR, which I just finished mine. It is becoming serious for companies as €20M or giving %4 of worlwide turnover (whichever is higher) is quite a hefty fine. It is here to replace Data Protection Act (1998). It becomes complicated when they store this data/servers outside of EU.
According to Article 30, subsection 5, then yes. However, the important bit is the "...the processing is not occasional..." AND the Article 5, subsection 2, that states "The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability')."
Both of these are interesting as far as the recording of processing activities goes, and are clearly up for interpretation. Personally, I've advised all my customers to make this document, since you're clearly able to demonstrate your compliance with the basic principles of data processing, which you need to be able to for all of your data controllers anyways.
Besides, it's been really fun helping them optimise their daily procedures at the same time, since all of a sudden they need to consider what it is they're actually doing. GDPR might be trouble for companies if they only look at the negative sides, but a lot of our customers have been very pleased with all the value that has been created indirectly, as part of becoming GDPR compliant. I mean, one customer ended up starting a whole new business venture based on data he didn't even know he had.
There's a lot of room for optimisation in firm's daily procedures, and GDPR is forcing everyone to reconsider their approaches to data and processing of data, pushing them further towards digitalisation of old procedures.
I've had a huge amount of push back from senior management on this, and I doubt anything serious will be done about it until they get in trouble. My CEO actually said he expects this to be "one of those policies that just costs us a fee every year, and then we just stick it in a drawer" so ¯\_(ツ)_/¯
4% is a hefty "fee", anyhow gotta love when management people disregard shit until it hits them where it hurts.
I definitely understand where you're coming from. That's the view on GDPR I've heard the most of. It's a shame though, because here's a perfect opportunity to be ahead of the curve, while following official policy and even having a good excuse for combating a lot of old procedures and maybe even optimising existing ones.
Alas, we still live in a world of ignorance and 60+ people being management knowing nothing about what it is they're managing.
I remember a shitty antitrust suit against Microsoft happened but they didn't target Apple too. I have to say that this seemed extremely hypocritical and clearly motivated by a desire to hit the larger company in that sector. Still, I think supporting encryption is an extremely good idea. Lack of encryption is often used by governments to spy on us (see Patriots Act & The Snoopers Charter.
If only it were that simple.
This shit is ridiculous
It does add one more layer of protection to free speech though, despite the EU having, let's say, an amorphous idea of that right.
I agree that the cookies legislation was silly. Every website ever telling you that it had cookies wouldn't have needed much of any work at all, just some JQuery, but think of what could have been accomplished in all those hours?
GDPR otherwise known as that thing you've been getting daily emails about from every website you have an account with
We had a lot of workshops for this in our company.
Get your wesite disclaimers in order, this poses a big big chance for scummy lawyers
Sorry, you need to Log In to post a reply to this thread.