havkom

It will apply from 25 May 2018

Yes, this is important - GDPR is mainly about how you are allowed to use data, ie for what purposes you are processing the data (although collection and storage is also “processing” as a side point)

I believe this is true. In my country (Sweden) it appears like consent outside of offering internet services may require the data subject to be 18, not 13 (Sweden has made a local adjustment to 13 years of the 16-years old rule referred to). So this rule may actually be a relief of who can consent to what.

Thanks for commenting my comment.

2. Yes, up to the legal team and what types of processing you do. If you do processing that the data subject would not expect you to do or that is not in their interest you have to consider this carefully. Maybe allowed or not under legitimate interest but you have to be careful and do a proper assessment. I believe, and I have heard many EU data protection lawyers state, that consent is a last resort option. Probably not universally shared but many ppl appears to think in that way. Also, remember that consent bypasses important principles, such as the necessity test present for all other legal basis.

3. I agree, both RTBF and SAR rights under legitimate interest but no absolute requirement to automate the process in any case. Implementing voluntarily data portability good practice which could tip the balance when using legitimate interest, see below.

4. Yes, and concerning legitimate interest, if you implement these best practice measures this could “tip the balance” in your favor if you read the WP29 legitimate interest opinion.

What is “it”? GDPR is in large parts based on the Data Protection Directive from 1995 and “Convention 108” from 1981. There is ample of case law, data protection authority opinions, guidance, etc.

If you use “consent” as your “legal basis” and you are asking for consent that is related to the offering of services over the internet (such as a web shop, a social media web site, discussion forum, ...), you need to somehow verify age (16 years normally) or be very clear that under 18 years olds (“children”) are not to access your service (and not have evidence pointing to that this is undermined)

Note that the 16 years old rule applies to “consent” only. As I stated in a separate comment “consent” is often not the way to do things. I, and many EU data protection lawyers I have met, believe consent to be a “last resort” legal basis of processing personal data. Instead, the legal basis called “legitimate interest” should normally be used where you as a company decides what is resonable, you think is needed to achieve the purposes you are processing data for, and, what the data subject would reasonable expect.

There is no under 16 age limit or age verification requirement in general for “legitimate interest”

I just want to point out that a lot of the article is the authors own opinion on how the regulation should be implemented into software and a lot of things are probably not needed normally and would be a burden for businesses.

My own take (and the take of most European data protection lawyers I meet) is that consent is not needed, and also possibly is inappropriate in 90% of the cases - instead the “legal basis” called “legitimate interest” should be used instead. This is where you do your own judgement if your data processing is reasonable. Imagine if you yourself always had to consent to all common sense use of your personal data, what a hassle!

If you use legitimate interest, also skip the “under 16” part, consent checkboxes and re-request consent part of the article (Of course there is more to it, but I would not get in to that unless you are doing data processing you do not think the data subjects in general would approve of).

Functions that allow the users to delete and automatically download/access their own data is good practice for legitimate interest but not needed. You are anyway in general allowed to deal with these types of request on a case by case basis if you provide your data subjects with an email address.

What you should do though is automatically delete data that you do not need anymore, such as old logs, customers contact details of customers long gone, old backups etc.

The parts of encyption, you should create an api etc are not required but may be good practice. Just make sure you have normal OK data and data access security.

As discussed above, you SHOULD use data for purposes that the customer has not agreed/consented to. However, never use personal data for purposes that are not compatible with the purposes you informed your customers of when collecting the data (normally stated in your privacy notice on your web site). If you did not have a privacy notice at the time of collection pre-GDPR, what is an compatible purpose will be a judgement call from the context of collection.

Yes

And no, GDPR is from my own experience not easy to understand or apply in practice - except for PPT toy problems.

There is a lot of more behind the articles in GDPR since it is partly based on legal instruments on data protection from 1981(!), “Convention 108” and EU legislation from 1995. Case law, opinions from data protection authorities etc. are important.

In general though, I would not be worried about big fines or anything as long as you try to follow GDPR and you are not doing things the data subjects does not want you to do with their data.

In general, the best GDPR compliance test is how it feels in your gut, after learning the principles.

At the point in time you process personal data against the interests of the data subject (for example building marketing profiles, sharing data with third parties w/o request from the data subject, etc) it is time to start worrying and make sure you cross the i’s... GDPR is pretty permissive in general IMO but make sure you know the details.

Yes and no. One of the most important principles in GDPR is “purpose limitation” (Article 5.1b):

“Personal data shall be collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes“

If a company starts collecting IP addresses for DDoS protection purposes, and then figures out that the data could also be used for marketing - that is most certainly in violation with this principle and therefor forbidden.

A “lawful basis” for the marketing purpose will not save you from this principle.

This is also where the public privacy policy/notice plays a role - for the company to be able to prove that the IP addresses where also originally collected for marketing purposes and fair information was given about this purpose at the point of collection.

In terms of GDPR’s territorial scope I guess at the point in time you start to use the DDoS prevention IP logs for profiling you come into GDPR scope. You would also be immediately be in violation of the purpose limitation principle if it is for marketing purposes.

See GDPR recital 24 (http://www.privacy-regulation.eu/en/recital-24-GDPR.htm):

[...] In order to determine whether a processing activity can be considered to monitor the behaviour of data subjects, it should be ascertained whether natural persons are tracked on the internet including potential subsequent use of personal data processing techniques which consist of profiling a natural person, particularly in order to take decisions concerning her or him or for analysing or predicting her or his personal preferences, behaviours and attitudes.

It appears like monitoring is closely related to profiling, defined in Article 4 as:

‘profiling' means any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person, in particular to analyse or predict aspects concerning that natural person's performance at work, economic situation, health, personal preferences, interests, reliability, behaviour, location or movements

If you are trying to eg. predict preferences of data subjects by collecting the logs you are probably monitoring their behavior.

If you are doing this it should be pretty clear to you from the purposes you are collecting information for. Security purposes (such as preventing DDoS attacks) are probably not purposes of monitoring data subjects behavior or profiling.

Sounds like you have a legitimate interest in logging IP addresses for security purposes, it is an effective measure and that your legitimate interest on balance outweighs the interests of the data subject. If that is the case you could probably rely on the “legal basis” called legitimate interest and do not need consent or anything like that. Do:

- Make a link to a privacy policy clearly accessible (eg on your website footer) and make sure it contains all of the required elements of information (see Article 13)

- Do not store the data longer than reasonable

- Do not worry too much about logs/backups etc as long as what you do is reasonable and you do have a reasonable delete schedule - no lawyers I have met seems to worry about this.

- Worry instead about for what purposes you actually use data you collect (what other orgs do you share data with, why, what do you do with the data that produces an effect on the data subject (eg marketing) etc)

I could not have formulated this better myself.

All but a few programmers I have met have tried to understand the underlying reason for their employment and the businesses issues they are employed to solve.

This approach have caused programmers to loose a lot of influence and status.

10 years ago companies had developers develop their own customized CRMs, which can really benefit a company if their domain-specific needs and processes can be integrated to such core-business software.

Nowadays, Adobe Campaign have a cake walk selling their bloated, general and non-tailored “CRM” solution to business.

How can they Adobe etc do this? They approach the marketing and sales team and offer a nice slide show.

Why does not IT or programmers even get involved before the purchase? Because no one likes talking to the idiots in IT that does not understand the businesses needs. They only nag about some “technical debt” (that no matter how much money is poured on the teams never disappears) and the need for re-writes of fully functioning parts of the system that introduces new bugs.