Site icon ELEKS: Enterprise Software Development, Technology Consulting

GDPR Compliance Checklist for Businesses: Legal and Tech Aspects

GDPR Compliance Checklist
GDPR Compliance Checklist
Article

GDPR Compliance Checklist for Businesses: Legal and Tech Aspects

The GDPR requirements and deadlines have been a subject of heated discussion since their introduction in 2016. We have prepared a GDPR compliance checklist to make your GDPR preparation journey fast and smooth.

As GDPR enforcement is only weeks away, European businesses and organisations that deal with personal data covered by the GDPR should work hard to ensure appropriate processes are in place to avoid unprecedented fines. For those still struggling with the challenges of compliance, here is a GDPR compliance checklist to make your life easier. These five steps include some of the UK Data Protection Authority’s (ICO’s) guidance, as well as recommendations based on our experience, both at ELEKS and with our clients.

1. Data Inventory

As a starting point, you will need to take stock of the data you already hold, from location and lifecycles to current compliance status. Once the inventory is specified, you should move on to scoping, which involves clarifying:

  1. Which entities are involved in your processing activities (both internally and externally)?
  2. Which projects (internal or external) include personal data?
  3. What standards and frameworks (organisational and security) exist within your company?

When you start to feel like there’s no end in sight to this process, you should move on to analysing the data itself. There’s no need to get too deep into this just yet, at this point you should categorise the information according to the project, that should be enough for now.

Two essential factors to consider are: where did you get the data (source) and what’s your legal basis for having it and processing it? If data has been obtained or kept without solid legal ground, you should consult with a privacy professional as soon as possible to find a remedy.

In general, to perform data inventory, you need to take the following steps:

  • Start with scoping (entities involved, standards and frameworks in place, projects in scope)
  • Identify categories of personal data (sources, legal basis)
  • Identify existing security controls (processes surrounding access to personal data and change management. awareness training, etc.)
  • Decide on the next steps to align existing processes with GDPR.

2. Data Flow Audit

Now it’s time to dig deeper. Try moving step by step with each category of personal data in your inventory. For each category you need to be able to answer the following:

  1. What are the roles and responsibilities of the people conducting personal data processing activities?
  2. What kind of assets do these people deal with?
  3. Who can change access to this information? Who grants access to these assets, what does the process looks like, who is accountable for it?
  4. What can change the processing? Is the process stable or is it agile and to what extent can it change?
  5. How do you provide rights to your data subjects (living natural persons, whose data you process)? This is an essential check to find out if you are ready to grant data subjects the right to access his/her data, to get it rectified, deleted, etc.

3. A Risk-based Approach to Breaches

As an example, you wouldn’t hire a team of three security analysts and set up a 24/7 security operation centre to protect your in-house database if it contains few emails and isn’t connected to the Internet. However, if you process medical records for the whole state and those records are available online, well, you probably should consider this option.

"A practical, risk-based approach is at the core of building GDPR compliance".
Arsen Kulyk,
Legal and Privacy Counsel at ELEKS

How should you correctly determine the level of the privacy risk? Consider actions that could harm the integrity, confidentiality or availability of the personal data. Some examples include accidental or unlawful destruction, a data loss, an alteration, unauthorised disclosure of personal data or access to the private data being transmitted, stored or otherwise processed (remember the recent scandal with Facebook?).

The right tool for discovering and responding to privacy risks is Data Protection Impact Assessment (DPIA). In some cases, it is mandatory under GDPR to conduct such an assessment. The general rule is that if your planned data processing is likely to create high privacy risks, DPIA must be conducted beforehand.

Here are few examples of the high privacy risks:

  1. Collecting credit card details and storing them in a new payment system
  2. Processing children’s medical data on a large scale
  3. Searching for personal data of specific people through various online information systems.

We recommend running DPIA when the controller is processing based on his/her legitimate interest, rather than consent of the data subject. DPIA should describe the processing activities as well as their purpose and, most importantly, assess the necessity and proportionality of the processing. The fundamental purpose of any DPIA is to find out whether your processing activities will violate the rights of the data subjects.

4. Security Framework

The security framework is the basis of an organisation’s privacy framework. In addition to governance and legal requirements, Information Security Management System (ISMS) is also critical. To put it simply, governance means that the company and its management recognise privacy is a priority, and as such, has created and implement relevant policies. With respect to legal requirements, generally speaking, you should keep your focus on GDPR principles and data subjects’ rights.

5. Breach Notification

GDPR is believed to be the most advanced piece of privacy legislation that currently exists; however, there are a lot of GDPR myths circulating the Internet regarding data breach reporting. A quick Google search would throw up various sources claiming that any personal data breach should be reported to the Data Protection Authority (DPA) within 72 hours, regardless of whether you know about it. Well, that’s not true!

Here’s the correct breach reporting schema:

There are four main players here:

  1. The controller, who determines what data to process, and how to process it
  2. The processor, who handles the data on behalf of the controller
  3. The DPA, the privacy law enforcement body in one of the EU states
  4. Data subjects, the people to whom the personal data belongs

Let’s illustrate this process with a real-life example:

  • Imagine a data subject, Alex L, who bought a book through Amazon
  • The controller here is Amazon, who collected Alex’s address so that they could deliver his book
  • The processor is DHL, the company that works with Alex’s data to handle the delivery
  • The DPA is the UK’s ICO.

So, let’s imagine that some attackers hacked DHL's server; however, since the data has been protected with advanced encryption standard, the information is impossible to read. The scenario should look like this: DHL must notify Amazon as soon as the breach is detected. The processor shall always inform the controller as quickly as possible. Amazon then has two choices. Firstly, if Amazon is 100% sure that Alex’s personal data can’t be accessed, there is no sensitive data, appropriate measures were taken to terminate the breach and its consequences, etc., then they can decide not to notify the DPA.

Depending on the individual circumstances of the breach, this course of action may be fully compliant with GDPR. The controller shall notify the DPA only when there is a definite risk to a data subject’s rights. In such cases, the DPA should be notified no later than 72 hours from the moment the controller became aware of the breach. The DPA then may advise, if requested to do so by the controller, whether there is a need to inform the data subject of the incident. So, if Amazon decides to notify the ICO, ICO may instruct Amazon to get in touch with Alex as well. The general rule is that the controller must notify data subjects immediately, but only if there is high risk to data subjects’ rights. The risk is always initially assessed by the controller internally.

The below schema shows the process of responding to a data breach:

Conclusion

This is where a reliable security partner can be of great help, offering expert consulting and compliance services. At ELEKS we understand the key pain points of enterprise security management. Our security services focus on threat prevention, detection and incident response as the top security priorities. We engage the brightest security and legal experts to help you cut security costs, extend your endpoint visibility and prevent attacks in the future.

"To efficiently tackle the challenges of GDPR implementation, enterprises need to understand the full scope of the new processes and policies that need to be adopted, as well as have a clear, actionable strategy in place".
Iurii Garasym,
Director of Corporate Security at ELEKS

Tell us about your challenges, and we will help your organisation smoothly implement GDPR to ensure your data is protected around the clock.

Exit mobile version