PC PORTAL

Experienced. Trusted. Solutions.

GDPR

By

Dublin Information Sec 2018: take note of this advice to embed lessons from a data breach

When assembling an incident response team, it’s worth including someone whose job is to take notes. It might seem like a small point, but it’s a big help for communicating during a breach, and learning lessons afterwards.

Maybe it’s because I write things down for a living, but for me, that was one of the key takeaways from Brian Honan’s presentation at Dublin Information Sec 2018 this week. “Have someone on your team who is a scribe, who will take notes of timelines, of who did what, and who will brief senior management about what’s happening,” he said.

All the president’s men

Brian made the remarks during a presentation about how to manage data breaches in light of GDPR’s stringent reporting regime. Organisations that suffer a breach involving personal data must report it to the designated data protection authority within 72 hours. Such a tight timeframe puts incredible pressure on incident response teams. It’s important to plan ahead, and identify the key roles and responsibilities in advance. The team could include specialists in data protection, information security, operations, human resources, legal, public relations and facilities management.

The designated note-taker can be an invaluable buffer between the technical teams scrambling to investigate the incident, and management who will want regular progress reports. Without that buffer, the need for regular updates might distract the investigation team from their work. Accurate notes can form the basis of open communication to an organisation’s staff, customers, media or other stakeholders. “Communicate throughout every part of this process,” Brian said.

Total recall

Having contemporaneous notes also provides a valuable record for when it’s time to take a fresh look at what happened. “Always review and measure, see where you can improve and how you can make things better,” Brian said.

He recommended conducting a review within 24 hours of an incident. That’s the ideal timeframe because memories fade – we’re only human after all. The longer the time lag between the incident and the review, the less reliable everyone’s recollection will be. But if the review stage is postponed for any reason, good notes are the next best thing.

Brian Honan, speaking at Dublin Information Sec 2018 conference at the RDS

 

The post Dublin Information Sec 2018: take note of this advice to embed lessons from a data breach appeared first on BH Consulting.

By

Busting myths and misconceptions around GDPR and security

For better or worse, GDPR and security are often wedded together, when the relationship in fact is slightly more complicated. Sarah Clarke, a specialist in privacy, security, governance risk and compliance with BH Consulting, has picked apart some myths and misconceptions around the subject. She kindly gave us permission to use material she published in her excellent Infospectives blog. It’s well worth reading for anyone whose role involves data protection or security.

In part one, she outlines the media backdrop (clickbait headlines and all). She then goes into detail about what the GDPR really says about security and covers security as a source of privacy risks.

Confusion and misunderstanding

Sarah decided to write the blog partly out of frustration from seeing discussions about privacy, GDPR, and the role of security, where facts were in short supply. “Confusion stems from security vendors and security experts misunderstanding the GDPR, not filtering out their security bias, or willingly leveraging GDPR furore to drive a security-centric agenda,” she wrote.

Privacy experts often note that just one principle in GDPR specifically references security. As Sarah argues, the picture is more nuanced. In the daily reality of many organisations, this works a little differently. Security and data protection intersect where people, process, or technical controls are necessary to minimise the risk of harm to data subjects resulting from a personal data breach – or business as usual processing. The two also meet where a security function’s own people, process, or technical controls involve processing personal data. What’s more, both need to work together when security teams must assess, oversee, and/or pay for GDPR-related change.

Minimising risk to data subjects

“If I had to draw out one fact from everything above that needs to be drilled into the heads of many security practitioners (including me in the early days), it’s this: Data Protection is NOT just about minimising the probability and impact of breaches. Data Protection IS about minimising the risk of unfair impact on data subjects resulting from historical data processing, processing done today, and processing you and your third parties might do in future.”

The second part of Sarah’s blog looks at three myths about GDPR. First, is that the regulation makes encryption mandatory, or whether using the technology negates other controls. Secondly, she tackles the assumption that being certified to ISO27001 effectively ensures compliance with GDPR. Third, she asks whether existing security-related risk management is fit for privacy purposes.

Encryption mandated nowhere

Expanding on the first point, Sarah says encryption is a vital tool but not a mandatory one. “The GDPR doesn’t mandate ANY specific controls. It mentions a couple, like pseudonymisation and encryption, but it is all about control selection based upon your local risks… Rendering data unintelligible is an incredibly effective mitigation for post breach data related harm to both data subjects and the organisation, but it in no way negates the need to apply other security and data protection controls.”

Next, she dismisses the idea that becoming certified to the information security standard ISO27001 is the same as GDPR compliance. However she adds that certification helps this way. “The Information Security Management System (ISMS), described in ISO27001, represents a robust way to scope, assess, articulate, document, and manage risks associated with all aspects of organisational security, including personal data security.

Assessing security risk from a privacy perspective

Lastly, Sarah debunks the misconception that security-related risk management is suitable for privacy purposes. The reason being that “the assessment of security related risk is pretty poor in general”. Outside certain fields like the military, healthcare, or energy, few consider the impact on individuals or groups of data subjects. As we’ve seen above, this consideration is central to GDPR.

Sarah outlines “unavoidable and critical steps” to determining the rights and freedoms of data subjects. Finally, she wraps up the post with seven practical steps for organisations to review where security, data processing, and privacy meet. Whether you work in a security role or on the privacy side, we encourage you to read the full posts. Both go into great detail and include helpful external links to other resources and discussion points. Our thanks to Sarah for sharing the material with us. You can read her blogs at www.infospectives.co.uk or follow her on Twitter.

The post Busting myths and misconceptions around GDPR and security appeared first on BH Consulting.

By

Using ISO 27001 to guide your GDPR breach response plan

Among the many changes GDPR will usher in, one of the biggest for many organisations will be mandatory breach reporting. From May 25, all organisations holding personal data about European Union residents must disclose a breach if it is “likely to result in risk to personal data”.

What’s more, organisations must report such breaches within 72 hours of discovering one. Reacting in such a short timeframe calls for a robust response plan. Unfortunately, experience to date suggests such plans tend to be conspicuously absent. The ISO 27001 Information Security Standard can help.

ISO 27001 can enable organisations to map an incident response plan that covers not just IT, but also people and processes. A good plan will cover the following steps:

  • Detect
  • Contain
  • Eradicate
  • Remediate
  • Recover
  • Review
  • Communicate.

Who implements the plan?

Incident response often falls solely – and unfairly – on the shoulders of the IT team. “It can’t just be the IT person’s job. It has to involve the whole business: this is a business risk and a business issue,” said Brian Honan. He added that GDPR applies to physical information, not just data on IT systems. Brian was speaking as part of a panel discussion on GDPR at the ISO 27001 Ireland event last week.

He recommended that a security response team should include representatives from information security, operations, HR, legal, PR, and facilities management. HR should be involved because if it’s an internal breach, the organisation may need to discipline a member of staff. Recovering from a breach often creates a fraught, high-pressure environment. HR can also play a role by helping to coach employees and manage their time. “Breaches don’t just happen between the hours of 9 and 5,” Brian said.

Involving a legal team is also important because organisations will probably need to deal with the appropriate data protection authority. “Speak the right language to the right people. You don’t want to open a can of worms by saying wrong thing to the regulator,” Brian said.

Sending the right message

Too often, organisations fall back on stock answers like “a sophisticated breach” when there’s little evidence to support the claim. Having PR expertise on the incident response team helps to ensure the organisation’s public statements are consistent, timely and truthful.

Brian also recommended including a representative from facilities management on the team. That’s particularly useful if a breach involved a break-in where CCTV cameras and physical security could prove vital.

“The key thing is, engage early with the business, find out what is important to them. Find out what you need to have in place. Establish relationships. Know who you need to contact in the regulator’s office or the supervisory office, find out what way you will contact them. And other relevant bodies you may need to contact. And think about what external expertise you may need. It’s important that you have those contact details already,” Brian said.

Ensuring transparency

To make sure the response process is repeatable, Brian recommended documenting all policies and procedures. “Transparency is important… It’s very easy to get caught in heat of moment in a breach, but then afterwards, can you recall what happened?”

Data breach notification also brings suppliers under its umbrella since many organisations now outsource their data hosting to third parties. “If your data is in a data centre or with a hosting provider, do you have an agreement in place so that they will let you know if they have had a breach? That’s a new thing to worry about. You may have to report a breach because one of your suppliers has had a breach,” Brian said.

Alerting mechanisms are vital because they can provide the information a response team needs to react appropriately to a breach. The 72-hour reporting window means that you don’t need detailed forensic analysis to start with. That can happen at a later stage. Teams should identify tools or software they will need both to detect possible breaches and to manage the response process. Brian suggested using examples like last year’s Equifax breach as the scenario for a desktop exercise to practice breach response. “If your vulnerability scanner didn’t work, how would you act? Use it as a learning mechanism,” he said.

People power

Staff training can also strengthen an organisation’s ability to spot potential breaches as well as responding to them. Brian referred to the Verizon Data Breach Investigations Report which found that many breaches come to light not via tools but through people noticing something strange. “The number one detection tool we have is our staff,” he said.

The last reason for implementing a breach response plan is simply reputation management. “It’s not that you’ve had a security breach that will damage your brand, it’s how well you respond,” Brian concluded.

The post Using ISO 27001 to guide your GDPR breach response plan appeared first on BH Consulting.

By

Permission slip: what consent means and where it really applies to GDPR

As data protection and privacy professionals, we use terms from data protection legislation daily and they roll off the tongue as if we were born knowing what the words mean. The problem is, GDPR contains words that have both a legal meaning and a different semantic meaning.

Talking with consumers and clients, I realise that we must temper our language carefully. As practitioners, we understand the legal meaning and frequently we don’t account for clients only understanding the semantic meaning.

You say consent, I say ‘consent’

The domain of GDPR where I have felt this disparity most strongly is with the legal instrument referred to in the GDPR as ‘consent ’. Beyond GDPR’s ‘consent as legal basis for processing data’, many other forms of consent exist in our society . I recently gave a talk to a group of executives on GDPR and when I discussed ‘consent’ as a legal basis for processing, one individual in the audience noted how horrified he was that Ireland was reducing the age of consent from 16 to 13. Realising his confusion, I quickly reaffirmed that the ‘consent’ I was referring to was as a legal instrument for certain types of processing such as e-marketing – and no other kind.

Recent media coverage of the Ulster Rugby   players trial made me realise how clear we must be with clients and others when expressing ourselves about ‘consent’.  So, if you aren’t doing so already, I encourage you to explain to your clients not just the differences between consent and the other legal instruments in the GDPR, but the actual meaning of consent under GDPR.

Consent and permission ≠ the same

The second issue I have encountered is that I so frequently encounter people who do not understand ‘consent‘ in GDPR terms and who confuse it in that context with ‘consent’ in its literal sense.

It is an understandable confusion, as consent in its literal sense means ‘permission for something to happen or agreement to do something’. In GDPR, consent can only be provided and revoked from processing that is undertaken using consent as the legal basis for processing. I have found that organisations (and data subjects) often discuss how they will facilitate ‘revoking consent’ from processing of information that is processed under a  legal basis other than consent.

Lawful bases for processing data

Elizabeth Denham, the UK Information Commissioner, summarised this issue succinctly when she noted that headlines about consent often lack context or understanding about all the different lawful bases that organisations will have for processing personal information under the GDPR. For processing to be lawful under the GDPR, at least one lawful basis is required.

Consider the following  examples: a government body processing property tax information; banks sharing data for fraud protection purposes; or insurance companies processing claims information. All these examples require a different lawful basis for processing personal information that isn’t ‘consent’. Each legal instrument has its own set of requirements. If the legal basis for processing is, for example, legitimate interest, the GDPR outlines a completely different set of requirements. In such cases, you do not need consent. This also means that the rules for ‘consent’, such as positive affirmative opt-ins, and freedom to change preferences etc. are only mandatory for consent-based processing.

With less than a month to go until GDPR , some organisations may still be grappling with the issue of ‘consent’ and the related implications for data processing under a misunderstanding of the meaning and where it applies. For our part, privacy professionals can help by being completely clear in how we communicate – while watching for signs that our intended audience understands what we mean. The regulation will be with us for a long time to come after 25 May. It is always worthwhile to ensure privacy policies apply ‘consent’ only where it’s legally necessary to do so.

The post Permission slip: what consent means and where it really applies to GDPR appeared first on BH Consulting.

By

GDPRubbish: seven common data protection myths debunked

I have been evangelising about GDPR for almost two years, professionally and personally. It’s a powerful piece of legislation designed to empower citizens of Europe and to deter the inappropriate information management practices of the past. It aims to rebalance a data subject’s control over information with the organisation’s need to maximise use and profit from that information.

During the various communication sessions which I have been privileged to run as a member of the BH team, I have been asked many questions. Some have been easy: the yes and no kind with reference to the article in GDPR. Others have been really challenging. You know the kind…the type of questions that make you dig deep inside you and go rooting for the answer.

For example, one wonders if, in fact, GDPR will negatively affect customer service, given the onerous challenges now facing organisations in continuing to provide excellent customer service that complies with the regulation. Only time will tell. I foresee a big problem with misinformation, where customer service personnel, afraid they might process data in a way that results in damage to the data subject, will incorrectly cite ‘data protection legislation’ and refuse to provide a certain service that they used to.

False facts

In listening to organisations like these and discussing their challenges, I have repeatedly heard ‘things-GDPR’ that are mythical and inaccurate. The formation of these myths reminds me of the old joke of Chinese whispers in World War I trenches, where the commander of the troop sends a message to be communicated, man to man verbally, to the communications officer at the far end of the trench. The message starts as ‘send reinforcements we are going to advance’ and finally reaches the communications officer as ‘send three and fourpence we are going to a dance’. These GDPR myths too seem to form like Chinese whispers and end up as ‘facts’ communicated to the organisation or the data subject. So, I decided to pool these myths together and communicate them so that we can address them in business and as a society.

Myth 1: “We are not a European Organisation and therefore don’t have to worry about GDPR compliance and there is no way for the fines to be imposed on us”

This is untrue. It doesn’t matter whether your organisation is based in an EU state or not. If it processes, stores or transmits personal data belonging to EU residents, then you will almost certainly be required to comply with it.

Myth 2: “We have only four employees and therefore don’t have to worry about GDPR compliance”

There is no ‘all-out’ clause in the GDPR for small companies. The GDPR applies to natural entities – which can range from individuals all the way up to governments and multinational corporations.

Myth 3: “We have less than 250 employees so the GDPR does not apply to us”

Again, another frequently cited myth. The GDPR does indeed mention exemptions for entities with fewer than 250 employees, but it does not state that these organisations are completely exempt. The GDPR broadly expects all small and medium-sized enterprises (SMEs) to comply in full with the Regulation, but it makes some exceptions for organisations that have fewer than 250 employees. The Regulation acknowledges that many SMEs pose a smaller risk to the privacy of data subjects than larger organisations. For example, Article 30 of the Regulation states that organisations with fewer than 250 employees are not required to maintain a record of processing activities under its responsibility, unless “the processing it carries out is likely to result in a risk to the rights and freedoms of data subjects, the processing is not occasional, or the processing includes special categories of data […] or personal data relating to criminal convictions and offences”.

Myth 4: “We have to appoint a DPO”

Virtually all public sector bodies will be required to designate a DPO under the GDPR. When it comes to the private sector, the GDPR introduces a limited mandatory DPO requirement. Controllers and processors will only be required to designate a DPO if their core activities consist of either of the following:

  • Processing and systematic monitoring of data subjects on a large scale
  • Processing on a large scale of special categories of data or data relating to criminal convictions and offences.

Each Member State is free to introduce broader national DPO requirements. Larger organisations operating across the EU would be well advised to consider appointing a DPO on a voluntary basis as this might be the most effective and efficient way to discharge their comprehensive GDPR compliance obligations.

Myth 5: “We don’t do transactions or undertake ‘profit’-related activity as we are a charity/club, so the GDPR does not apply”

This myth is a frequent one. To fall within the remit of the GDPR, the processing has to be part of an “enterprise”. Article 4(18) of the Regulation defines this as any legal entity that’s engaged in “economic activity”. Economic activity essentially translates into ‘not personal’ e.g. people processing personal data in the course of exclusively personal or household activity. This means you wouldn’t be subject to the Regulation if you keep personal contacts’ information on your computer or you have CCTV cameras on your house to deter intruders.

Myth 6: “When relying on consent to process personal data, consent must be explicit”

The GDPR requires that where consent is the legal instrument for processing data,  consent must be “unambiguous” (Art 4(11)).  “Explicit” consent is required only for processing sensitive personal data – in this context, nothing short of explicitly expressed “opt in” will suffice (Art 9(2)).  But for non-sensitive data, “unambiguous” consent suffices.

Myth 7: “GDPR is all about encryption, pseudonymisation and privacy enhancing tools”

GDPR is in fact a ‘technology neutral’ piece of legislation that advocates reviewing data in light of the six key principles of data protection. Only one of these principles addresses securing data. Although the regulation advises that there are some compliance advantages to encrypting personal information (such as possibly not having to inform data subjects in the event that there is a breach), the GDPR focuses equally on all six data protection principles:

  • 1. Lawfulness, fairness and transparency Organisations need to make sure their data collection practices are fair to data subjects, and compliant with rules for collection and processing. They should also state in their privacy policy the type of data they collect and process, and the reasons for doing so.
  • 2. Purpose limitation Organisations should only collect personal data for a specific purpose, clearly state what that purpose is, and only collect data for as long as necessary to complete that purpose.
  • 3. Data minimisation Organisations must only process the personal data that they need to achieve its processing purposes.
  • 4. Accuracy The GDPR states that “every reasonable step must be taken” to erase or rectify data that is inaccurate or incomplete.
  • 5. Storage limitation Similarly, organisations need to delete personal data when it’s no longer necessary.
  • 6. Integrity and confidentiality This is the only principle that deals directly with security. The GDPR states that personal data must be “processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures”. The GDPR is deliberately vague about what measures organisations should take, because technological and organisational best practices are constantly changing.

The GDPR is a serious piece of legislation, and organisations need to have certainty about their obligations and responsibilities as outlined in it. Certainty can only be achieved by reading the legislation (it is very well written) and reading interpretations – or paying someone to do it for you.

In my view, we can lend organisations some slack if they genuinely misunderstood this new legislation, but service providers engaged by clients to understand and advise on GDPR cannot be forgiven for misleading clients. And many of the myths I have encountered originated from professionals operating in the GDPR space. Just like when we need to find a person to service a gas boiler, we go to a registered operator. The same applies for GDPR advisors: organisations should determine the privacy and data protection qualifications of those they engage for GDPR advice.

The post GDPRubbish: seven common data protection myths debunked appeared first on BH Consulting.