cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
leroux
Community Champion

Getting Started on the Basics: The EU General Data Protection Regulation (GDPR)

 

This document was prepared by members of the (ISC)2 EMEA Advisory Council GDPR Task Force. Lead Contributors: Yves Le Roux, CISSP, CISM; Paul Lanois, CCSK, CIPM, CIPT, CIPP (A, E, US and C), FIP, CISMP and LLM.
Reviewed by Dr. Adrian Davis, MBA, FBCS CITP, CISSP; Sam Berger, CISSP; Michael Christensen, CISSP, CSSLP, CISM, CRISC, CIS LI, EU-GDPR-P; CCM, CCSK, CPSA, ISTQB, PRINCE2, ITIL, COBIT5; Ramon Codina, CISSP; Santosh Krishna Putchala, CISSP

37 Replies
planois
Newcomer III


@Sholaremu wrote:

I have read so much about The EU General Data Protection Regulation (GDPR) and the coming into effect in may 2018...its appeared, this is specifically for European ( i stand to be corrected) my question is what role does this play for Africa if at all its might affect it


If you are offering products or services to individuals in the EU, whether for free or against payment, or if you are monitoring the behaviour of EU individuals (e.g. Profiling), then you would be required to comply with the GDPR even if you do not have a presence in the EU and even if all processing in relation to data is done outside the EU. See article 3 of the GDPR. Since many companies nowadays have international clientbase and are acrively targeting EU prospects or clients, they have to comply with the GDPR.

planois
Newcomer III


@EUGDPR wrote:

A good paper, which takes a complex regulation and presents it simply.

 

I would like to comment on a couple of points:  It is stated that:

 

“It will become mandatory (Article 33 of the GDPR) for an organisation to report any data breach to its

DPA within 72 hours of becoming aware of it”.

 

It should be noted that the Data Controllers should conduct an assessment of the impact on the data subjects, and if there is no IMPACT, they do not need to report the data breach. For example, if, say, a laptop is lost that contains personal data, that is a data breach. If however the laptop has appropriate encryption, GDPR deems that there will be no impact to the data subjects, and as such the breach does not need to be reported.

 

The section on the data register quotes the regulation as saying the register must include:

 

“The name and contact details of the controller and, where applicable, the joint controller, the

controller's representative and the data protection officer”.

 

The phrase “where applicable” should be emphasised, as not all organisations are required to have a Data Protection Officer (DPO). Without getting bogged down in details, there are many liabilities to having a Data Protection Officer, and if an organisation wanted to have one man in charge, then my suggestion would be now, with GDPR, to give him any title you wish, except calling him the Data Protection Officer.

 

This rather brings me to agreeing with planois and Heinrich, that quality of resource is an issue, but in some ways “Privacy Professionals” may not offer the complete skillset necessary to implement GDPR.

 

Consider the reality that in 1984 when the Data Protection Act (DPA) was written into UK law, there was not a lot of computer data about. Organisations by and large regarded the DPA as the digital equivalent to Health&Safety, and I remember, when I first conducted such a project, the absence of executive support. Consequently DPOs were appointed with no real authority to engage their businesses. Even when the EU directive in 95 caused the UK to roll the 84 Act and the 87 Access to Files Act into, what was to become the so-called 98 Act, little really changed.

 

In my opinion, to implement GDPR compliance, requires a knowledge of GDPR, a knowledge of information security, a knowledge of business continuity, and a knowledge of data architecture, and Privacy Enhanced Technologies (PETS). As this is not likely to be found in one person, the real requirement is excellence in Project and/or Programme management in general, and transformation project management in particular, and only after Executive support is gained.

 

Best regards,

 

John McGill


The problem is, how can you say with certainty that there is NO IMPACT following a data breach and how can you confidently do so within 72 hours? If you say that there is no impact whatsoever, you must be sure of that assessment because if, after conducting an investigation, it is revealed that the breach was more extensive than you suspected (for example, the stolen laptop had login credentials which were then used to access the network and access unencrypted data, then you have a real problem). I doubt the regulators would look kindly on companies who are quick to say there is NO IMPACT without having anything to back up that claim. Can you safely say that you will finish the investigation within 72 hours? If we look at the data breaches that have made the headlines recently, the companies affected took weeks if not months to assess and understand the full extent of the breach. It took Yahoo 3 years to discover and disclose the data breach.

 

As for your example on laptop encryption, you are reading article 34 of the GDPR. However article 34 says 

"The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:

(a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption".

 

Notice the first line - it says that the communication to the data subject is not required, it does not say that you do not need to notify the data supervisory authority. The exception that you are referring to in relation to encryption is only an exception to paragraph 1 of article 34 of the GDPR, it is not written that it is an exception to article 33 which is the notification to the authorities within 72 hours.

 

 

EUGDPR
Newcomer I

Hi,

 

Good to hear your comments.

 

The issue you raise takes me to one of the main basis for any GDPR compliance transformation project. It should comply with any published code of conduct applicable to the organisation and where possible should be certified against any relevant standard (ISO 27001, BS 10012 etc). All of this takes one to documenting the Privacy Information Management System (PIMS), in which, amongst many other things, should be the documented process for data breach identification, escalation, invocation, evaluation, and response. That process should conform to best practice (say ISO 22301) and whatever is documented should be followed, with an audit trail of the activities, decisions taken, and reasoning for the decisions. This should include documented policies on such issues as encryption. This will form the evidence should it be needed with the InfoComm.

 

In many ways, it is not a matter of whether there was, or was not, an impact to the data subjects, rather that the reasoning, which must appear logical and reasonable, shows that the Data Controller(s) operated responsibly and in compliance with documented processes and polices, which themselves conform to best practice.

In terms of your comment about the lost laptop, I would refer you to Article 33, which states that:

 

Art. 33 GDPR Notification of a personal data breach to the supervisory authority:

 

In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.

 

In terms of an encrypted laptop not risking the rights and freedoms of natural persons, we have to look to the ICO, and I quote the existing comment:

 

ICO on encryption: “The Information Commissioner has formed the view that in future, where such losses occur and  where encryption software has not been used to protect the  data, regulatory action may be pursued.”. The current acceptable encryption standards are: FIPS 140-2, FIPS 197. N.B. Hashing is not encryption, as the underlying data can be rebuilt

 

The original guidance was:

 

https://ico.org.uk/for-organisations/guide-to-data-protection/encryption/implementing-encryption/

 

I hope that clarifies the issue, or have I just made things muddier?

 

Best regards,

 

John McGill

planois
Newcomer III

The problem that I have is that, as you mentioned, the ICO simply stated : "where encryption software has not been used to protect the data, regulatory action may be pursued". They said they may take action if no encryption has been used. They did not say that no action would be taken if encryption is used. I do not feel comfortable making such a leap and assuming that the reverse is automatic. 

 

In its Opinion 03/2014 on breach notification23, the WP29 (which is the group of EU data protection authorities) explained that a confidentiality breach of personal data that were encrypted with a state of the art algorithm is still a personal data breach, and has to be notified. However, if the confidentiality of the key is intact – i.e., the key was not compromised in any security breach, and was generated so that it cannot be ascertained by available technical means by any person who is not authorised to access it – then the data are in principle unintelligible. Thus, in such specific situation, the breach is unlikely to adversely affect individuals and therefore would not require communication to those individuals.

 

However, the WP29 stated earlier this month that "However, even where data is encrypted, a loss or alteration can have negative consequences for data subjects where the controller has no adequate backups. In that instance communication to data subjects would be required, even if the data itself was subject to adequate encryption measures."

 

In light of all of the above, I think it would be a mistake to assume that encryption is the magic formula which will automatically shield an organization from all liability. After all, there are encryption standards which evolve over time. WPA2 – the encryption standard that secures all modern wifi networks – has recently been cracked. SSL and TLS 1.0, which are encryption standards for data transfers, are no longer deemed satisfactory to meet PCI-DSS requirements. I would assume that the ICO would require up to date and appropriate encryption to be used for them not to take any action.

 

After all, on the link you provided, the ICO writes:

Data controllers should therefore regularly assess whether their encryption keys remain sufficiently large to prevent a brute force or other method of attack. They should also assess the risks and likelihood of an attack given the amount of personal data they hold.

 

The ICO further states:

Rather than develop a custom algorithm it is recommended that a data controller uses a trusted and verified algorithm.

Accredited products (see ‘Choosing the right software’ below) can provide an assurance of suitability and also permit data controllers to demonstrate a level of compliance with legal obligations. However, it is important to review regularly the products being used due to the nature of technical development over time.

 

The ICO also writes

However, if the laptop user’s username and password were written on a piece of paper stored alongside the laptop the thief has all the necessary information in order to decrypt the data and gain full access to it, thereby rendering the encryption ineffectual.

 

Earlier this month, WP29 wrote: "Controllers should also be familiar with the specifics of how their encryption product functions. For instance, a device may be encrypted once it is switched off, but not while it is in stand-by mode. Some products using encryption have “default keys” that need to be changed by each customer to be effective. The encryption may also be considered currently adequate by security experts, but may become outdated in a few years’ time, meaning it is questionable whether the data would be sufficiently encrypted by that product and provide an appropriate level of protection."

 

I am sure that is what you meant, i.e. that up-to-date encryption standards need to be used and if that is the case, it is likely that no enforcement action would be taken.

 

However considering the wide range of persons reading this community site, coming from different backgrounds, I think that it is important to stress on these points. Maybe it is just me but I am afraid that people jump on the conclusion "just encrypt everything" without digging deeper and without understanding the above mentioned points. That would probably not fly, even with the ICO. I have heard from too many people that encryption is the silver bullet yet they do not understand that it needs to be up to date or that software vulnerabilities must be patched. And like you said, hashing is not encryption and therefore would not help here. 

planois
Newcomer III

According to the Article 29 Working Party, "it should be noted that if there is a breach where there are no backups of the encrypted personal data then there will have been an availability breach, which could pose risks to individuals and therefore may require notification. Similarly, where a breach occurs involving the loss of encrypted data, even if a backup of the personal data exists this may still be a reportable breach, depending on the length of time taken to restore the data from that backup and the effect that lack of availability has on individuals. As Article 32(1)(c) states, an important factor of security is the “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident”.

EUGDPR
Newcomer I

Yes that's what I said before, the Data Controllers should conduct an assessment of the impact on the data subjects, and if there is no impact, they do not need to report the data breach.

EUGDPR
Newcomer I

Steve E,

 

The e-privacy Regulation will the primary authority on this subject, but it looks to me to be at the same stage in the development of the Directive as GDPR was in 2012. Now, I doubt it will take as long to become a Regulation, but I can’t see it coming into force for 1 or 2 years, and then there will be a two year period of grace before it’s actioned.

For the time being, we should focus on GDPR, or the UK Data Protection Act, which I guess will be written into law in 2018.

 

Consent is a hotly debated subject as it is unclear in GDPR, so really we need to wait for a Code of Conduct to be issued, after which guidance will come from case law.

 

John McGill

EUGDPR
Newcomer I

Steve E,

 

Further to my last post, yesterday,  the full plenary of the European Parliament voted today in Strasbourg to move forward with the draft of the ePrivacy Regulation and enter into negotiations with the EU Council and EU Commission on a final text of the legislation.

 

There has been intense lobbying resulting from the text of the draft voted out of the LIBE Committee last week, the final vote was 318 in favor, 280 opposed, with 20 abstentions. The vote in LIBE was 31 for, 24 against; other committees that asked for opinion also had tight votes, with JURI voting 11-10 and IMCO 19-13. The ITRE Committee, however, endorsed the draft 50-5.So it looks more like 2 years than 1 to coming into force.

 

The url below gives the full report from Rapporteur MEP Marju Lauristin, which includes side-by-side comparisons of the original Commission draft and the current Parliament draft.

 

http://www.europarl.europa.eu/sides/getDoc.do?type=REPORT&reference=A8-2017-0324&language=EN&mkt_tok...

Davismh
Viewer II

Yes a good GDPR operational needs overview, whereas all these user data based requirements need to be translated into technical specifications to map capabilities to, conduct a gap analysis and provide a roadmap to leadership.

What does it take to “be erased” for example? Most of those requirements listed in the paper need to be technically supported beyond just policy and process changes needed operationally.

We need to have a collective ISC2 approach to the GDPR technical requirements, beyond just calling out and listing the numerous items stated in the law... I am using the CIS CSC top 20 controls privacy addendum as my technical “specifications” and the NIST 800-53a privacy recommendations as my higher level technical requirements to get started on my gap analysis.

This will at least set my technical GDPR capabilities baseline, whereas I can then map to the key operational requirements in this guide to assess any further functions needed.

Be glad to share what I have and collaborate on this technical approach with other ISC2 folks, send me an email and let’s roll as they say. I also run a GDPR support Meetup for solutions we can use
Ciao
Mike.Davis.SD@gmail.com
flyingboy
Newcomer III

Good effort, summarising the 88 pages regulation into a 5-page document.