OK – so GDPR applies to your organisation, what now?
The first thing you must do, is make sure that you have the consent of the Data Subject (the person to whom the data refers).
There are further twists regarding consent that you need to be aware of with GDPR.
So, if you have got this far and still aren’t sure what Consent and Legality in GDPR means to you, here’s a few simple pointers to help get you started:
This is week two of our 8 week GDPR walkthrough – hopefully having completed week one, you managed to look at the data your organisation holds and understand the changes that your organisation needs to make around consent to comply with GDPR.
This week is quite straightforward – but it will be time consuming. The objective is to get to the next level of detail on the data held through an exercise called ‘Data Mapping’ which is a GDPR requirement – Article 30 for anyone who is interested. Data Mapping will document the lifecycle of the Personal Identifiable Information (PII) through your organisation – who owns the data, where it is held and importantly and who can access it.
Having this information documented will help your organisation to not just understand the vulnerabilities, but also to respond more efficiently to data subject requests as you will know where their data is processed and held.
A good way to start the exercise is with a whiteboard. Get everyone to contribute to what data they hold and what systems they use – for example HR will hold sensitive employee data, staff performance information and even candidate CV. Sales will have CRM data containing sensitive data. Operations may have bank account details and credit cards. Get it all down on paper and then find an owner. You should also understand where this information is passed from system to system as part of the process flow and start to look for vulnerabilities.
At the end of the Data Mapping exercise you will have a lot of information and more than likely, a load of actions to look at. There will be surprises as well – did anyone ask for consent before recording customer’s wives’ birthdays in the CRM system? HR may think they are the only ones with access to their data, but did they know that IT are able to view the database where it is kept, or another team can access it through another system? Did Operations know that their data is being used by Sales to cross sell products?
Importantly you will now know all the PII held in the organisation, where it is, who owns it and who can access it. Once you have that information you are in a strong position to start implementing controls and planning what needs to be done to secure the data that you now know you are dealing with.
According to GDPR, the DPO must:
From this it is easy to see how it could quickly become a full-time role, especially given the requirement for cooperation and liaison with the SA. They want someone available to them to work with, especially if something goes wrong
The other specification of the DPO position in the GDPR is that of where the position should sit and report to and, how the position should be protected. As the DPO role is about ensuring compliance, it should not sit within the delivery functions of the business or IT. The rationale behind that is the role should be impartial and be able to call out risk associated with change and therefore not be part of the team delivering the change, so if an internal staff member is delegated as the DPO, they would normally sit within a Risk, Compliance or Governance function to ensure the required independence. The GDPR states that the data protection officer shall be designated on the basis of professional qualities and, in particular, expert knowledge of data protection law and practices, so make sure you get the right person.
There are also stipulations about reporting lines – the DPO should have ‘direct access’ to the board. This doesn’t necessarily mean they need to report to the CEO or one of the senior team, but they need to be able to escalate directly without needing to go through multiple go-betweens, risking the dilution or loss of the message. Following from that the DPO will ensure that Data Protection is on the board agenda. Lastly, the DPO position should be ‘protected’ and not risk losing their job, career prospects or bonus just because they called out a risk.
If this all sounds a little daunting, don’t worry, help is available…keep reading.
GDPR states that the DPO does not need to be a permanent employee of the organisation, so if you are concerned that either you do not have someone with the required skills and experience, Intersys Compliance offer a Contract DPO service which will give you an assigned, experienced DPO who will act as the dedicated, named and communicated DPO for your organisation.
The contract DPO service can be tailored to meet the requirements of the organisation, but the standard service offering includes the following components:
Articles 15 to 21 of GDPR lay down the rights of the data subject regarding the processing of their PII. These include the below rights, which must be met free of charge for the Data Subjects:
While it cannot be relied upon wholesale, there are certain situations where a request from a Data Subject can be declined. I’m sure that got your attention, so let’s explore that a little further.
Where requests are ‘manifestly unfounded or excessive’, in particular because they are repetitive, you can charge a reasonable fee taking into account the administrative costs of providing the information; or refuse to respond. Now it is a open to interpretation as to what is ‘manifestly unfounded or excessive’, but if you can make a strong case that, for example, someone wanting to have all data erased, but you know there are calls recorded and stored in backup tapes that would mean that all calls would need to be deleted in order to meet on Data Subject’s request, then that would warrant push back. The problem here however is that while it may save a massive piece of work retrieving or deleting data, pushing back on requests could also be time consuming and can’t be relied upon to close the request. A persistent Data Subject has every right to contact the Supervisory Authority and escalate the request, which could overturn the rejection.
The GDPR does not introduce an exemption for requests that relate to large amounts of data, but you may be able to consider whether the request is manifestly unfounded or excessive.
Practically speaking, the best approach to take is to make sure that any future systems are compliant regarding the requests – if you are buying or developing a new system make sure that all GDPR requests can be processed at the touch of a button. But that is the future and may not be in place ahead of May 2018. So regarding the existing systems, first you need to know what you can do now (or implement easily) to meet the new requests. Once you have that information, you’ll know what you cannot respond to and that needs to be documented. Depending on what those requests are and the mitigating factors may be then they can be considered on a case-by-case basis. Using the earlier example of voice recordings, if you can demonstrate that you are holding the recordings to meet existing customer obligations and that the recordings are locked away and not actively being processed, then there may be a case to have a conversation with the Supervisory Authority to explain the known shortfall. No guarantees, but at least it shows your organisation has done its homework and is keeping an eye on the risks.